[FFmpeg-devel] [RFC] av_decode_video and CODEC_CAP_DR1

Reimar Döffinger Reimar.Doeffinger
Mon Jun 7 22:50:42 CEST 2010


On Mon, Jun 07, 2010 at 10:38:52PM +0200, Michael Niedermayer wrote:
> On Mon, Jun 07, 2010 at 04:44:45PM +0200, Cyril Russo wrote:
> >   From the documentation, it's not possible to prevent av_decode_video2 
> > from reusing allocated frame, unless these two conditions are set:
> > 1) Codec support CAP_DR1 capability
> > 2) codecContext's get_buffer et al are overridden
> >
> > As I understand it, some codec might not have the flag set and in that 
> > case, one must copy/duplicate the frame if it's stored for later 
> > consumption (like in another thread)
> >
> > I've checked all source tree to find out which video decoder doesn't have 
> > this flag set, and only libschrodinger & libdirac doesn't.
> > So what about inverting/dropping the flag, and thus simplifying the code ?
> > Precisely, I think about adding some code in libschro&dirac like this:
> > // Pseudo code
> > int decode_frame(...)
> > {
> >     [... Previous decoding code...]
> >     if (codecContext.get_buffer != default_get_buffer)
> >     {
> >         // If user overriden get_buffer, let's call it and copy the data in 
> > the generated buffer
> >        frame = codecContext.get_buffer(...)
> >        copyFrame(frame, frameFromOriginalCode);
> >     }
> > }
> > This would result in easier documentation, and less complexity in user 
> > code.
> 
> it would lead to slower code and unneeded copying, this is not how lavc
> is designed.

That was my first thought as well, but I think there may be a misunderstanding.
I think the idea is to only change the currently invalid case (no DR1 and
overridden get_buffer), so it would not cause any slowdown per se.
However I still have my doubts, since users might inadverdently trigger
this slow copy case, particularly since when built against share libraries,
doing
codecContext.get_buffer = default_get_buffer;
can lead to
codecContext.get_buffer != default_get_buffer
when evaluated inside the library.
(not to mention applications that just set get_buffer to a wrapper around
default_get_buffer that does some logging, or "garbage collection" in case
the allocation fails or...)



More information about the ffmpeg-devel mailing list