Sur d’autres sites (6879)

• How can I correctly provide a fake webcam input to Chrome ?

  30 août 2018, par doppelgreener

  I’m trying to run end-to-end testing in Chrome for a product that requires a webcam feed halfway through to operate. From what I understand this means providing a fake webcam video to Chrome using the --use-file-for-fake-video-capture="/path/to/video.y4m" command line argument. It will then use that as a webcam video.

  However, no matter what y4m file I provide, I get the following error from Chrome running under these conditions :

  DOMException: Could not start video source
  
  {
  
    code: 0,
  
    message: "Could not start video source",
  
    name: "NotReadableError"
  
  }

  Notably I can provide an audio file just fine using --use-file-for-fake-audio-capture and Chrome will work with it well. The video has been my sticking point.

  This error comes out of the following straightforward mediaDevices request :

  navigator.mediaDevices.getUserMedia({ video: true, audio: true })
  
    .then(data => {
  
      // do stuff
  
    })
  
    .catch(err => {
  
      // oh no!
  
    });

  (This always hits the “oh no !” branch when a video file is provided.)

  What I’ve tried so far

  I’ve been running Chrome with the following command line arguments (newlines added for readability), and I’m using a Mac hence the open command :

  open -a "Google Chrome" --args
  
    --disable-gpu
  
    --use-fake-device-for-media-stream
  
    --use-file-for-fake-video-capture="~/Documents/mock/webcam.y4m"
  
    --use-file-for-fake-audio-capture="~/Documents/mock/microphone.wav"

  webcam.y4m and microphone.wav were generated from a video file I recorded.

  I first recorded a twenty-second mp4 video using my browser’s MediaRecorder, downloaded the result, and converted it using the following command line commands :

  ffmpeg -y -i original.mp4 -f wav -vn microphone.wav
  
  ffmpeg -y -i original.mp4 webcam.y4m

  When this didn’t work, I tried the same using a twenty-second movie file I recorded in Quicktime :

  ffmpeg -y -i original.mov -f wav -vn microphone.wav
  
  ffmpeg -y -i original.mov webcam.y4m

  When that also failed, I went straight to the Chromium file that explains fake video capture, went to the example y4m file list it provided, and downloaded the grandma file and provided that as a command line argument to Chrome instead :

  open -a "Google Chrome" --args
  
    --disable-gpu
  
    --use-fake-device-for-media-stream
  
    --use-file-for-fake-video-capture="~/Documents/mock/grandma_qcif.y4m"
  
    --use-file-for-fake-audio-capture="~/Documents/mock/microphone.wav"

  Chrome provides me with the exact same error in all of these situations.

  The only time Chrome doesn’t error out with that mediaDevices request is when I omit the video completely :

  open -a "Google Chrome" --args
  
    --disable-gpu
  
    --use-fake-device-for-media-stream
  
    --use-file-for-fake-audio-capture="~/Documents/mock/microphone.wav"

  Accounting for C420mpeg2

  TestRTC suggests Chrome will “crash” if I give it a C420mpeg2 file, and recommends that simply replacing the metadata fixes the issue. Indeed the video file I generate from ffmpeg gives me the following header :

  YUV4MPEG2 W1280 H720 F30:1 Ip A1:1 C420mpeg2 XYSCSS=420MPEG2

  Chrome doesn’t actually crash when run with this file, I just get the error above. If I edit the video file to the following header though per TestRTC’s recommendations I get the same situation :

  YUV4MPEG2 W1280 H720 F30:1 Ip A1:1 C420 XYSCSS=420MPEG2

  The video file still gives me the above error in these conditions.

  What can/should I do ?

  How should I be providing a video file to Chrome for this command line argument ?

  How should I be recording or creating the video file ?

  How should I convert it to y4m ?

• How can I correctly provide a mock webcam video to Chrome ?

  15 décembre 2022, par doppelgreener

  I'm trying to run end-to-end testing in Chrome for a product that requires a webcam feed halfway through to operate. From what I understand this means providing a fake webcam video to Chrome using the --use-file-for-fake-video-capture="/path/to/video.y4m" command line argument. It will then use that as a webcam video.

  



  However, no matter what y4m file I provide, I get the following error from Chrome running under these conditions :

  



  DOMException: Could not start video source
{
  code: 0,
  message: "Could not start video source",
  name: "NotReadableError"
}


  



  Notably I can provide an audio file just fine using --use-file-for-fake-audio-capture and Chrome will work with it well. The video has been my sticking point.

  



  This error comes out of the following straightforward mediaDevices request :

  



  navigator.mediaDevices.getUserMedia({ video: true, audio: true })
  .then(data => {
    // do stuff
  })
  .catch(err => {
    // oh no!
  });


  



  (This always hits the “oh no !” branch when a video file is provided.)

  



  What I've tried so far

  



  I've been running Chrome with the following command line arguments (newlines added for readability), and I'm using a Mac hence the open command :

  





  open -a "Google Chrome" --args
  --disable-gpu
  --use-fake-device-for-media-stream
  --use-file-for-fake-video-capture="~/Documents/mock/webcam.y4m"
  --use-file-for-fake-audio-capture="~/Documents/mock/microphone.wav"


  



  webcam.y4m and microphone.wav were generated from a video file I recorded.

  



  I first recorded a twenty-second mp4 video using my browser's MediaRecorder, downloaded the result, and converted it using the following command line commands :

  



  ffmpeg -y -i original.mp4 -f wav -vn microphone.wav
ffmpeg -y -i original.mp4 webcam.y4m


  



  When this didn't work, I tried the same using a twenty-second movie file I recorded in Quicktime :

  



  ffmpeg -y -i original.mov -f wav -vn microphone.wav
ffmpeg -y -i original.mov webcam.y4m


  



  When that also failed, I went straight to the Chromium file that explains fake video capture, went to the example y4m file list it provided, and downloaded the grandma file and provided that as a command line argument to Chrome instead :

  



  open -a "Google Chrome" --args
  --disable-gpu
  --use-fake-device-for-media-stream
  --use-file-for-fake-video-capture="~/Documents/mock/grandma_qcif.y4m"
  --use-file-for-fake-audio-capture="~/Documents/mock/microphone.wav"


  



  Chrome provides me with the exact same error in all of these situations.

  



  The only time Chrome doesn't error out with that mediaDevices request is when I omit the video completely :

  



  open -a "Google Chrome" --args
  --disable-gpu
  --use-fake-device-for-media-stream
  --use-file-for-fake-audio-capture="~/Documents/mock/microphone.wav"


  



  Accounting for C420mpeg2

  



  TestRTC suggests Chrome will “crash” if I give it a C420mpeg2 file, and recommends that simply replacing the metadata fixes the issue. Indeed the video file I generate from ffmpeg gives me the following header :

  



  YUV4MPEG2 W1280 H720 F30:1 Ip A1:1 C420mpeg2 XYSCSS=420MPEG2


  



  Chrome doesn't actually crash when run with this file, I just get the error above. If I edit the video file to the following header though per TestRTC's recommendations I get the same situation :

  



  YUV4MPEG2 W1280 H720 F30:1 Ip A1:1 C420 XYSCSS=420MPEG2


  



  The video file still gives me the above error in these conditions.

  



  What can/should I do ?

  



  How should I be providing a video file to Chrome for this command line argument ?

  



  How should I be recording or creating the video file ?

  



  How should I convert it to y4m ?

  


• ffmpeg stops capturing whole hour of HTTP stream after some time

  7 juillet 2020, par CompuChip

  First of all, sorry if I'm using the wrong terminology. I've been playing around with nginx and I'm still a bit confused about RTMP and HLS and other acronyms.

  


  I've managed to setup OBS to stream to an nginx server, which takes the RTMP stream and chops it into pieces for HLS. Here's the relevant part of the nginx configuration file.

  


  rtmp {
    server {
        listen 1935;
        chunk_size 4000;
        ping 30s;
        deny play all;

        application live {
            live on;
            hls on;
            hls_nested on; # Create a new folder for each stream
            hls_path /mnt/hls/live;
            hls_fragment 3s;
            hls_fragment_naming timestamp;
            hls_playlist_length 60s;
        }
    }
}

http {
    server {
        listen 81 ssl;

        #creates the http-location for our full-resolution (desktop) HLS stream - "http://localhost:8080/live/test/index.m3u8"
        location /live {
            # Elided caching and CORS for brevity

            alias /mnt/hls/live;
            add_header Cache-Control no-cache;
            index index.m3u8;
        }
    }
}


  


  This works well, I can view the stream in VLC or on a website and it looks smooth. Now I wanted to add some logging : I'd like to write full hours (starting at xx:00:00 and ending at xx:59:59) to a file named log_yyyymmdd_hh.mp4, e.g. log_20200707_18.mp4 for the files of 7 July 2020, 18:00 - 19:00 hrs. So I've set up an hourly cron job with the following ffmpeg command :

  


  ffmpeg -i https://stream.example.com:81/live/<streamkey> -preset veryfast -maxrate 2000k \&#xA;    -bufsize 2000k -g 60 -t 3600 -y /var/video/log/$(date &#x2B;\%Y\%m\%d_\%H00).mp4 >/dev/null 2>&amp;1&#xA;</streamkey>

  


  At first this seemed to work well, so I left it running happily for about 24 hours. When I checked, most of my hourly files were small ( 100MB) files of about 10 to 15 minutes long. It seems like any small delay in the stream will cause ffmpeg to stop writing to the file. I suspect such hiccups may for example be caused by an OBS plugin and I'll need to look into that, but I would prefer that ffmpeg will retry for some time before giving up. What arguments should I be passing to ffmpeg to make it not break when the stream is down for, say, up to a second every now and then ?.

  


  When I view back the HLS files there don't seem to be any noticeable gaps, so eventually all the data arrives. I went for the crontab solution with ffmpeg because when recording from nginx I could not figure out how to start recording at the start of the whole hour.