webm dash encoding… What are the correct ffmpeg parameters?

Question

I'm stumped with encoding videos into a dash compliant format. I'm going from .mp4 to .webm

Firstly, I am running OS X and ffmpeg 2.5.4.

Here's the encoding commands I am using in my test (I got these from here):

ffmpeg -i IMG_0113.mp4 -c:v libvpx-vp9 -s 160x90 -b:v 25k -g 1 -tile-columns 4 -frame-parallel 1 -an -f webm -dash 1 video_160x90_25k.webm

ffmpeg -i IMG_0113.mp4 -c:v libvpx-vp9 -s 160x90 -b:v 50k -g 1 -tile-columns 4 -frame-parallel 1 -an -f webm -dash 1 video_160x90_50k.webm

ffmpeg -i IMG_0113.mp4 -vn -acodec libvorbis -ab 128k  -dash 1 audio_128k.webm

ffmpeg -f webm_dash_manifest -i video_160x90_25k.webm -f webm_dash_manifest -i video_160x90_50k.webm -f webm_dash_manifest -i audio_128k.webm -c copy -map 0 -map 1 -map 2 -f webm_dash_manifest -adaptation_sets "id=0,streams=0,1 id=1,streams=2" manifest.mpd

Secondly, the problem is not with my server, as I have downloaded the samples from here, and they work 100% on the dash.js player when served from my local server.

Please could someone out there point me in the right direction? Or provide a sample of the ffmpeg commands used to get the output format correct.

Thanks, Dean.

Answer 1

Ok, here goes, managed to solve this. Hopefully this will save someone else some hassles.

Firstly, here's the solution.

Step 1: (strip audio from video, and create single audio file)

ffmpeg -i IMG_0113.mp4 -c:v libvpx -s 160x90 -threads 4 -b:v 25k -tile-columns 4 -frame-parallel 1 -an -keyint_min 30 -g 30 -f webm video_160x90_25k.webm

ffmpeg -i IMG_0113.mp4 -c:v libvpx -s 160x90 -threads 4 -b:v 50k -tile-columns 4 -frame-parallel 1 -an -keyint_min 30 -g 30 -f webm video_160x90_50k.webm

ffmpeg -i IMG_0113.mp4 -vn -acodec libvorbis -ab 128k audio_128k.webm

Step 2: (using sample_muxer from the libwebm project available here, to create the video cue points)

sample_muxer -i video_160x90_25k.webm -o video_160x90_25k_cued.webm

sample_muxer -i video_160x90_50k.webm -o video_160x90_50k_cued.webm

Step 3: (Use ffmpeg to create the audio cue points)

ffmpeg -i audio_128k.webm -vn -acodec libvorbis -ab 128k -dash 1 audio_128k_cued.webm

Step 4: (Use ffmpeg to create the webm dash manifest file .mpd)

ffmpeg -f webm_dash_manifest -i video_160x90_25k_cued.webm -f webm_dash_manifest -i video_160x90_50k_cued.webm -f webm_dash_manifest -i audio_128k_cued.webm -c copy -map 0 -map 1 -map 2 -f webm_dash_manifest -adaptation_sets "id=0,streams=0,1 id=1,streams=2" manifest.mpd

Secondly, here's the explanation.

ffmpeg (my version atleast), was not creating the cue points in the video files correctly (when adding the -dash 1) param. I determined this by probing the video files, and by understanding the webm file format (read this, if you'd like to know more).

I then stumbled upon sample_muxer from reading this page, and decided to see if it would better handle the video cue points that ffmpeg wasn't getting right. Whoop Whoop, it did!

I noticed that the cue points in the extracted audio file from ffmpeg (using the -dash 1 param), were being created correctly!

The ffmpeg generation of the webm dash manifest is also working nicely!

For playing back the video, I found shaka-player worked best but I could not use it as I required video playback from a cefpython container and the shaka-player did not work on the latest cef (chromium embedded framework) included in the cefpython release.

I then wrote my own player based off of this helpful site from google

Anyway, hope this helps someone

Answer 2

I had similar issue. When I converted mpeg2 to vp9 with ffmpeg v3.4.2, the output video was not seekable in VLC player (seeking took long time). When I tried ffmpeg v4.0.2, the video was seekable in VLC player. So it seems, that it is fixed in ffmpeg v4.0.2