On Sat, 28 Jan 2017, Peter Große wrote:
On Fri, 27 Jan 2017 22:24:35 +0200 (EET)
Martin Storsjö <[email protected]> wrote:
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.)
Mh, after thinking about this a bit more, I'm not sure the complexity is worth
it.
I'd have to store the contents of the dyn_buf containing the init data somewhere
until the first packet is ready to be flushed so I can calculate the average
bitrate to be used in the filenames. Only then I know the init segment filename.
This might be ok for mp4, since everything happens within the first call to
dash_flush. But for webm this doesn't work that easy.
So maybe the patch is ok for now.
Ok - it's not worth complicating the code too much just for that
pathological case.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
