#7386 closed defect (fixed)

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

Reported by: danapplegate Owned by:
Priority: normal Component: avformat
Version: unspecified Keywords: dash
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


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 "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:

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:


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

Attachments (1)

ffmpeg-report.zip (528.8 KB) - added by danapplegate 22 months ago.
ffmpeg report

Download all attachments as: .zip

Change History (6)

Changed 22 months ago by danapplegate

ffmpeg report

comment:1 follow-up: Changed 22 months ago by cehoyos

  • Component changed from ffmpeg to avformat
  • Keywords dash added
  • Priority changed from important to normal

comment:2 in reply to: ↑ 1 Changed 22 months ago by danapplegate

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

comment:3 Changed 21 months ago by j_karthic

comment:4 Changed 21 months ago by j_karthic

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

comment:5 Changed 21 months ago by cehoyos

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.