Chunked DASH using $Bandwidth$ in segment templates results in broken .mpd files

[danapplegate]

Hi there,

I'm trying to convert videos into chunked MPEG-DASH using the Dash muxer. I'm using Segment Templates with the format chunk-stream$RepresentationID$-$Bandwidth$-$Number%05d$.m4s. According to the ​ISO Standard, section 5.3.9.4.4 "Template-based Segment URL construction", it seems that clients are intended to use the Representation@bandwidth attribute to construct each chunk filename from the template:

$Bandwidth$
This identifier is substituted with the value of Representation@bandwidth attribute value.

However, running the below ffmpeg command, specifying a target bitrate of e.g. 100000 results in chunk files:

chunk-stream0-100000-00001.m4s
chunk-stream0-100000-00002.m4s
chunk-stream0-100000-00003.m4s
...

But the relevant stream representation has a weird value of 101681 for the bandwidth:

<Representation id="0" mimeType="video/mp4" codecs="avc1.64000b" bandwidth="101681" width="160" height="90" frameRate="24/1">

So, when my client downloads the .mpd file and constructs the init segment, or any subsequent segment, it's requesting init-stream0-101681.m4s, which obviously fails because that file doesn't exist.

I took a look at the source code and it seems that we're adding something called muxer_overhead to the representation's bandwidth at ​libavformat/dashenc.c#L614:

        if (os->bit_rate > 0)
            snprintf(bandwidth_str, sizeof(bandwidth_str), " bandwidth=\"%d\"",
                     os->bit_rate + os->muxer_overhead);

Whereas down below, when we ​construct the chunk filename from the template, we just use bit_rate:

ff_dash_fill_tmpl_params(os->initfile, sizeof(os->initfile), c->init_seg_name, i, 0, os->bit_rate, 0);
...
        ff_dash_fill_tmpl_params(os->filename, sizeof(os->filename),
                                 c->media_seg_name, pkt->stream_index,
                                 os->segment_index, os->bit_rate, os->start_pts);

What do you think? Am I missing something here? Perhaps we should be including the muxer_overhead adjustment to all bitrate calculations, so that the same value is reflected in both the Representation@bandwidth attribute and the chunk filenames?

How to reproduce:

% ffmpeg -report -i /private/var/folders/1n/y7g1b1g95lsc37wxx7wh3vth0000gq/T/9d0a3d8d593c3858500d08ebf62f541b/big_buck_bunny_720p_surround.mp4 -map 0:v -map 0:v -map 0:a -c:v libx264 -c:a aac -s:v:0 160:90 -b:v:0 100000 -s:v:1 320:180 -b:v:1 300000 -use_template 1 -init_seg_name "init-stream$RepresentationID$-$Bandwidth$.m4s" -media_seg_name "chunk-stream$RepresentationID$-$Bandwidth$-$Number%05d$.m4s" -adaptation_sets "id=0,streams=v id=1,streams=a" -dash_segment_type mp4 -f dash /private/var/folders/1n/y7g1b1g95lsc37wxx7wh3vth0000gq/T/9d0a3d8d593c3858500d08ebf62f541b/big_buck_bunny_720p_surround/manifest-mpeg.mpd

[danapplegate]

ffmpeg report

[danapplegate]

Replying to cehoyos:
Thanks for the clarifications on the ticket! Sorry, my first bug report here, still unfamiliar with the procedure.

[Karthick Jeyapal]

Have sent a patch to devel to fix this.
​http://ffmpeg.org/pipermail/ffmpeg-devel/2018-September/233933.html

[Karthick Jeyapal]

Pushed the fix. I think this ticket can be closed now.

[Carl Eugen Hoyos]

44ee858b6df0f3f350abd56bd18340c1d8d94ee8