> On May 9, 2016, at 08:28, Hendrik Leppkes <h.lepp...@gmail.com> wrote: > > On Mon, May 9, 2016 at 3:26 PM, Derek Buitenhuis > <derek.buitenh...@gmail.com> wrote: >> On 5/9/2016 2:22 PM, Paul B Mahol wrote: >>> Once st->codec is gone, how would this lossless info be gathered back? >> >> As myself and others have said above: decode a frame. > > And before people argue that avformat does this anyway today - one of > the hopes is to make it stop doing that for many "simple" codecs where > this is just not necessary, and say a parser could extract all the > important information with much less overhead.
(necroing old thread because this came up elsewhere) I can understand the argument that lavf shouldn't return all of this by _default_, but not providing a mechanism at all forces a lot of additional boilerplate onto the consumer. It'd be convenient to have an API that does the equivalent of what avformat_find_stream_info currently does (determine all relevant stream information for all streams, either using parsers or decoders as necessary, running through as many frames as necessary to gather the info, up to timestamp- and size-based limits). If you don't think this fits well in lavf, there could be a higher-level lib on top of lavf+lavc that handles this sort of thing (potentially the "ffmpeg.c-as-a-library" concept I've thought about for a while, with ffprobe-like functionality as well), but the simplest way to do it is just to have avformat_find_stream_info continue to perform that function, perhaps behind a "gather more info than what lavf itself needs" flag. > > - Hendrik > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
