WebM segment size

[Tincho Rodríguez]

Hi, I'm looking for transcoding a mp4 video to WebM using ffmpeg. My idea is to have as a result a WebM video with 10 seconds as segment size, in order to achieve a streaming really similar as HLS does with the ts chunks.

I read some ffmpeg documentation and tried several times to transcode the video but didn't succeed at it. I tried the following options:

ffmpeg -i trailer.webm -minrate 1M -maxrate 1M -c:v libvpx -c:a libvorbis -quality best -qmin 0 -qmax 50 -crf 5 -b:v 1M -segment_time 10 trailer2.webm

I'm also looking for a script or program that shows the inner properties of the webm files, in order to check at the timecode result, offset of segments, size, etc. I tried mse tools but it has no documentation. What would you suggest me?

Thanks!

Martin

[Ralph Giles]

On 2014-04-28 7:45 PM, Tincho Rodríguez wrote:
> I'm also looking for a script or program that shows the inner properties
> of the webm files, in order to check at the timecode result, offset of
> segments, size, etc.

You might try 'mkvinfo -v' from
http://www.bunkus.org/videotools/mkvtoolnix/ or 'webminspector.py' from
https://chromium.googlesource.com/webm/webminspector

I'm not sure if that will tell you want you're interested in though?
Streamability/DASH-compatibility with WebM is different from mp4.

HTH,
-r

[Aaron Colwell]

Hi Martin,

You should be able to do what you want with ffmpeg and mse tools. I believe you need to add a -g option to your ffmpeg command-line to force keyframes to be placed at 10 second intervals. For 30 fps content you would need to use -g 300. Once you have done this, you should be able to use "mse_webm_remuxer -cm 10000 in.webm out.webm" to remux the file so that it has a minimum cluster size of 10 seconds. The -cm option specifies the minimum cluster duration in milliseconds. You can also use "webm_dump out.webm" to inspect the output file if you'd like. You can also use the mse_json_manifest tool on the output webm file to generate a simple JSON manifest that tells you where all the segment boundaries in the file and the associated start timecode.

Sorry there is no documentation for mse tools right now. I just haven't invested the time in docs yet because I didn't think anyone but me was using them. :) I'll find some time to improve the docs. Let me know if you run into any other problems.

Aaron

--
You received this message because you are subscribed to the Google Groups "WebM Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webm-discuss...@webmproject.org.
To post to this group, send email to webm-d...@webmproject.org.
Visit this group at http://groups.google.com/a/webmproject.org/group/webm-discuss/.
For more options, visit https://groups.google.com/a/webmproject.org/d/optout.

[Tincho Rodríguez]

Hi guys, thanks for the suggestions. I'll try transcoding again

[Tincho Rodríguez]

Aaron,

I was able to transcode and remux the file succesfully. Anyway, when inspecting the remuxed video using the mse_json_manifest I see that the timecodes are not equal to 10,000. Some of them vary from 9,000 to 14,000.  I tried remuxing the webm to 4 second segments as another test, and the JSON result is even weariest. I get timecodes that vary from 4 seconds to 10. The first segment seems to always a timecode of 10,000.

Am I doing something wrong?

Thanks,

Martin

[Aaron Colwell]

This sounds like a bug to me. Please send me the file so that I can take a look.

Aaron

[Tincho Rodríguez]

Aaron,

I uploaded the video to my Drive:

https://drive.google.com/folderview?id=0B4hLwm2ZBFo2aU52ZjZDTU1HMDA&usp=sharing

Thanks again!

Martin

[Aaron Colwell]

Whoa! You might want to be careful about publically sharing long encodings of copyrighted works like this. Consider using Creative Commons content like Big Buck Bunny or Tears of Steel in the future. 

Anyways... I think you need to use the following command lines if you want to force segments that are as close as possible to 10 seconds long.

ffmpeg -i toTranscode.mp4 -g 300 -keyint_min 300 transcoded.webm 

mse_webm_remuxer -cm 10000 transcoded.webm remuxed.webm

mse_json_manifest remuxed.webm

This should result in segment lengths that are very close to 10 seconds long. They are usually only off  by a little because of the audio frames.

You can also use the following command-line to see where ffmpeg happens to place the keyframes in the transcoded file.

webm_dump transcoded.webm  | grep 'trackNum="1"' | grep 'flags="80"'

The remuxer is only able to start clusters on the timestamps output by that command.  If ffmpeg is outputing keyframes at intervals shorter than your desired segment duration, the remuxer may start a new cluster in a position you didn't expect. That is likely why you were seeing odd intervals. 

I think there still might be a bug in my code somewhere, but I don't have time today to dig deeper. This info should be enough to unblock you though.

Hope this helps,

Aaron

[Tincho Rodríguez]

Yup, I forgot about that legal issue. Already removed the videos from my Drive. Thanks a lot for your help, now the JSON returns the segments with timecode difference really close to 10 seconds! Last question, what if I want to have segments of size 4 seconds, what values should I modify?

Thanks again!

Martin

[Aaron Colwell]

On Tue, May 6, 2014 at 6:08 PM, Tincho Rodríguez <merodrig...@gmail.com> wrote:

Yup, I forgot about that legal issue. Already removed the videos from my Drive. Thanks a lot for your help, now the JSON returns the segments with timecode difference really close to 10 seconds! Last question, what if I want to have segments of size 4 seconds, what values should I modify?

Glad I could help. For 4 seconds you'd want to use -g 120 -keyint_min 120  and -cm 4000   Basically the -g option indicates the max number of frames in a "group of pictures" which means how many non-keyframes can be between keyframes. Your content is ~30 frames per second so 4*30 gives you the 120. The -keyint_min options indicates the minimum number of non-keyframes that must exist between keyframe. This prevents the encoder from generating keyframes earlier than your desired segment interval. The -cm option is in milliseconds so that is why it changes to 4000 for 4 seconds.

You'll have to play with these parameters to figure out what works best for your use case. Constraining keyframe locations too much can result in lower quality encodes because you are restricting the options that the encoder can explore. If these settings work for you then great. If not, then you can just use the default encoder settings or look into using the -force_key_frames FFmpeg option to create fancy keyframe forcing rules.

Aaron