> 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

Reply via email to