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. Regards Peter
pgpOGQYlx22fg.pgp
Description: OpenPGP digital signature
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
