[FFmpeg-devel] [PATCH 2/2] avformat/dashenc: Set mp4 as the default format for VP9

Jeyapal, Karthick kjeyapal at akamai.com
Thu Apr 19 07:19:46 EEST 2018

On 4/19/18 12:23 AM, Jan Ekström wrote:
>On Wed, Apr 18, 2018 at 3:03 PM, Karthick J <kjeyapal at akamai.com> wrote:
>> From: Karthick Jeyapal <kjeyapal at akamai.com>
>> There is a separate muxer(webmdashenc.c) for supporting VP9+webm output in DASH.
>> Hence in this muxer we will focus on supporting VP9 in MP4
>> Have verified playout support of VP9+MP4 in Chrome and Firefox.
>> ---
>>  libavformat/dashenc.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>> index 5443e31..301ea1a 100644
>> --- a/libavformat/dashenc.c
>> +++ b/libavformat/dashenc.c
>> @@ -1016,11 +1016,10 @@ static int dash_init(AVFormatContext *s)
>>          if (!ctx)
>>              return AVERROR(ENOMEM);
>> -        // choose muxer based on codec: webm for VP8/9 and opus, mp4 otherwise
>> +        // choose muxer based on codec: webm for VP8 and opus, mp4 otherwise
>>          // note: os->format_name is also used as part of the mimetype of the
>>          //       representation, e.g. video/<format_name>
>>          if (s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VP8 ||
>> -            s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VP9 ||
>>              s->streams[i]->codecpar->codec_id == AV_CODEC_ID_OPUS ||
>>              s->streams[i]->codecpar->codec_id == AV_CODEC_ID_VORBIS) {
>>              snprintf(os->format_name, sizeof(os->format_name), "webm");
>> --
>> 2.7.4
> I was thinking of adding a muxing mode myself (making the mode an enum
> so it can be easily compared, and then make into an AVOption with two
> alternatives - "mp4" and "webm"), as the webm muxing in dashenc.c
If you can send a patch for the same, then I will hold of this patch. Please let me know.
> seems to be completely broken. This just hides that fact completely
> (at least for VP9, which probably is the most popular of those
> formats). I'd prefer we either fix it, or just remove the WebM support
> altogether if nobody wants to maintain it.
I am also not keen on supporting for WebM in dashenc.c
Because there is a separate muxer webmdashenc.c meant for this purpose,
actively maintaining the same feature here is a waste of time and effort. 
But instead of removing the feature altogether, I would prefer to keep the 
options open so that, in future if someone wishes to provide a fix for 
WebM and add an AVoption as you suggested we could have a single 
muxer that supports both WebM and mp4.
> To drive the point through, in that very function it will attempt to
> write something in the webm mode with `flush_init_segment`, which then
> calls `mkv_write_flush_packet` in matroskaenc, which in turn then
> calls `end_ebml_master_crc32`, which then tries to calculate CRC on
> seemingly nothing because the mode is not yet set in `mkv_init` to
> MODE_WEBM, and thus `mkv->mode != MODE_WEBM` is true. The result is a
> fabulous segfault. Not sure if just adding a call to
> `mkv_write_header` would do it to fix this (through the write_header
> lavf function).
Well, I fixed the segfault. But still I couldn't get it working in any dash.js or shaka player.
If you are aware of an older ffmpeg version's commit where webm is working with
current dash.js or shaka player in either firefox or chrome I can relook into it.
> Best regards,
> Jan
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

More information about the ffmpeg-devel mailing list