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

[Jan Ekström]

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
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.

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).


Best regards,
Jan