Recherche avancée

Sur d’autres sites (13888)

• Updated(reproducible) - Gaps when recording using MediaRecorder API(audio/webm opus)

  25 mars 2019, par Jack Juiceson

  ----- UPDATE HAS BEEN ADDED BELOW -----

  I have an issue with MediaRecorder API (https://www.w3.org/TR/mediastream-recording/#mediarecorder-api).

  I’m using it to record the speech from the web page(Chrome was used in this case) and save it as chunks.
  I need to be able to play it while and after it is recorded, so it’s important to keep those chunks.

  Here is the code which is recording data :

  navigator.mediaDevices.getUserMedia({ audio: true, video: false }).then(function(stream) {
 recorder = new MediaRecorder(stream, { mimeType: 'audio/webm; codecs="opus"' })
 recorder.ondataavailable = function(e) {
   // Read blob from `e.data`, decode64 and send to sever;
 }
 recorder.start(1000)
})

  The issue is that the WebM file which I get when I concatenate all the parts is corrupted(rarely) !. I can play it as WebM, but when I try to convert it(ffmpeg) to something else, it gives me a file with shifted timings.

  For example. I’m trying to convert a file which has duration 00:36:27.78 to wav, but I get a file with duration 00:36:26.04, which is 1.74s less.

  At the beginning of file - the audio is the same, but after about 10min WebM file plays with a small delay.

  After some research, I found out that it also does not play correctly with the browser’s MediaSource API, which I use for playing the chunks. I tried 2 ways of playing those chunks :

  In a case when I just merge all the parts into a single blob - it works fine.
  In case when I add them via the sourceBuffer object, it has some gaps (i can see them by inspecting buffered property).
  697.196 - 697.528 ( 330ms)
  996.198 - 996.754 ( 550ms)
  1597.16 - 1597.531 ( 370ms)
  1896.893 - 1897.183 ( 290ms)

  Those gaps are 1.55s in total and they are exactly in the places where the desync between wav & webm files start. Unfortunately, the file where it is reproducible cannot be shared because it’s customer’s private data and I was not able to reproduce such issue on different media yet.

  What can be the cause for such an issue ?

  ----- UPDATE -----
  I was able to reproduce the issue on https://jsfiddle.net/96uj34nf/4/

  In order to see the problem, click on the "Print buffer zones" button and it will display time ranges. You can see that there are two gaps :
  0 - 136.349, 141.388 - 195.439, 197.57 - 198.589

  1. 136.349 - 141.388
  2. 195.439 - 197.57

  So, as you can see there are 5 and 2 second gaps. Would be happy if someone could shed some light on why it is happening or how to avoid this issue.

  Thank you

• Gaps when recording using MediaRecorder API(audio/webm opus)

  9 août 2018, par Jack Juiceson

  ----- UPDATE HAS BEEN ADDED BELOW -----

  I have an issue with MediaRecorder API (https://www.w3.org/TR/mediastream-recording/#mediarecorder-api).

  I’m using it to record the speech from the web page(Chrome was used in this case) and save it as chunks.
  I need to be able to play it while and after it is recorded, so it’s important to keep those chunks.

  Here is the code which is recording data :

  navigator.mediaDevices.getUserMedia({ audio: true, video: false }).then(function(stream) {
 recorder = new MediaRecorder(stream, { mimeType: 'audio/webm; codecs="opus"' })
 recorder.ondataavailable = function(e) {
   // Read blob from `e.data`, decode64 and send to sever;
 }
 recorder.start(1000)
})

  The issue is that the WebM file which I get when I concatenate all the parts is corrupted(rarely) !. I can play it as WebM, but when I try to convert it(ffmpeg) to something else, it gives me a file with shifted timings.

  For example. I’m trying to convert a file which has duration 00:36:27.78 to wav, but I get a file with duration 00:36:26.04, which is 1.74s less.

  At the beginning of file - the audio is the same, but after about 10min WebM file plays with a small delay.

  After some research, I found out that it also does not play correctly with the browser’s MediaSource API, which I use for playing the chunks. I tried 2 ways of playing those chunks :

  In a case when I just merge all the parts into a single blob - it works fine.
  In case when I add them via the sourceBuffer object, it has some gaps (i can see them by inspecting buffered property).
  697.196 - 697.528 ( 330ms)
  996.198 - 996.754 ( 550ms)
  1597.16 - 1597.531 ( 370ms)
  1896.893 - 1897.183 ( 290ms)

  Those gaps are 1.55s in total and they are exactly in the places where the desync between wav & webm files start. Unfortunately, the file where it is reproducible cannot be shared because it’s customer’s private data and I was not able to reproduce such issue on different media yet.

  What can be the cause for such an issue ?

  ----- UPDATE -----
  I was able to reproduce the issue on https://jsfiddle.net/96uj34nf/4/

  In order to see the problem, click on the "Print buffer zones" button and it will display time ranges. You can see that there are two gaps :
  0 - 136.349, 141.388 - 195.439, 197.57 - 198.589

  1. 136.349 - 141.388
  2. 195.439 - 197.57

  So, as you can see there are 5 and 2 second gaps. Would be happy if someone could shed some light on why it is happening or how to avoid this issue.

  Thank you

• Split mp4 video from URL (stored on AWS s3) with ffmpeg without re-encode, causes an issue with the start point

  25 avril 2023, par DArkO

  I am building an API endpoint as part of which i am signing an AWS s3 url to a video file encoded with mp4, then using ffmpeg to split the provided video by url to a time range (for example from second 4.0 to second 12.0), and pipe it to a stream which is directly returned to the user.

  


  I am running into an issue where the video is split starting on the 10 second mark. In the command below it is splitting from 0-14 sec instead of 6-14. if i specify 12-18 it will split from 10-18 etc..

  


  As part of this process this is the ffmpeg command i am using to split the video (omitting the full signed S3 url and writing to a file instead of a pipe).

  


  ffmpeg -protocol_whitelist file,http,https,tcp,tls,crypto -ss 6.0 -to 14.0 -i https://XXXXXXXX.s3.amazonaws.com/stopwatch.mp4 -movflags +frag_keyframe+separate_moof+omit_tfhd_offset+empty_moov -f mp4 -c copy output.mp4


  


  If i try to re-encode the video instead of using -c copy splitting works perfectly well, but is quite a lot slower.

  


  This is the command i use to initially encode the videos and make them uniform as I upload them to AWS S3. I can control the encoding process and change if needed to be able to do the splits correctly.

  


  ffmpeg -i video.mp4 -vf scale=1280:-2 -c:v libx264 -movflags faststart -preset slow -crf 24 -r 25 -c:a aac -b:a 128k


  


  From the ffmpeg docs :

  


  -ss position (input/output)
When used as an input option (before -i), seeks in this input file to position. Note that in most formats it is not possible to seek exactly, so ffmpeg will seek to the closest seek point before position. When transcoding and -accurate_seek is enabled (the default), this extra segment between the seek point and position will be decoded and discarded. When doing stream copy or when -noaccurate_seek is used, it will be preserved.


  


  So this looks like intended behaviour, I also found out that mp4 will have IFrames set on every 10 seconds (250 frames on 25fps in my case) where the fastseek (-ss) option will seek on remote videos to the nearest Iframe and use that as a starting point.

  


  Is there a way to change this behavior ? Add IFrames to at least 1 second so i can split accurately at least to 1 second ? If so are there any drawbacks to doing that ? Is there another option to avoid re-encoding the segments ?

  


  I was thinking i can do multiple splits and a concat where i split-re-encode 6-10sec then split-copy 10-14 then concat the 2 segments to get 6-14sec video.

  


  What i find strange is that with the same video provided as a local file reference to ffmpeg it splits it correctly if i simply do :

  


  ffmpeg -ss 6.0 -to 14.0 -i stopwatch.mp4 -c copy output.mp4