[FFmpeg-trac] #7386(ffmpeg:new): Chunked DASH using $Bandwidth$ in segment templates results in broken .mpd files

FFmpeg trac at avcodec.org
Wed Aug 29 10:32:39 EEST 2018


#7386: Chunked DASH using $Bandwidth$ in segment templates results in broken .mpd
files
-------------------------------------+-------------------------------------
             Reporter:               |                     Type:  defect
  danapplegate                       |                 Priority:  important
               Status:  new          |                  Version:
            Component:  ffmpeg       |  unspecified
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 Hi there,

 I'm trying to convert videos into chunked MPEG-DASH using the
 [https://ffmpeg.org/ffmpeg-formats.html#dash-2 Dash muxer]. I'm using
 Segment Templates with the format `chunk-
 stream$RepresentationID$-$Bandwidth$-$Number%05d$.m4s`. According to the
 [https://www.iso.org/standard/65274.html 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 at 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:

 {{{
 #!xml
 <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
 [https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/dashenc.c#L614
 libavformat/dashenc.c#L614]:

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

 Whereas down below, when we
 [https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/dashenc.c#L1035
 construct the chunk filename] from the template, we just use `bit_rate`:

 {{{#!c
 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
 }}}

--
Ticket URL: <https://trac.ffmpeg.org/ticket/7386>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker


More information about the FFmpeg-trac mailing list