On Fri, 27 Jan 2017, Peter Große wrote:
On Fri, 27 Jan 2017 15:21:20 +0200 (EET)
Martin Storsjö <[email protected]> wrote:
On Fri, 27 Jan 2017, Peter Große wrote:
Bandwidth information is required in the manifest, but not always
provided by the demuxer. If not available via metadata calculate
bandwith based on the size and duration of the first segment.
This probably is fine with me.
We can have $Bandwidth$ as part of the segment filename template - I guess
this is too late to get it right for those cases? Although I don't mind if
we don't support that case when we don't have a nominal bitrate set and
try to use it in the template.
Than we have to postpone opening any file handle until the first call to
dash_flush, right?
Which should be possible, but requires some code to be moved. Using a dyn_buf
(patch 10) might also help here, so writing to files happens as late a possible.
Hmm, indeed. If we postpone this patch until after that, this should be
easier to handle right. (The alternative would be to just count the
bitrate of the codec payload as we pass into the chained muxer; the
bit_rate value we use otherwise also refers to only the codec payload data
not including the container, but since we're probably doing the dyn_buf
stuff anyway, that's even simpler.)
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
