[FFmpeg-devel] [PATCH] libavcodec/mmaldec.c: add interlaced_frame and format struct to AVFrame for deinterlacing]

[Jens Ziller]

Am Freitag, den 12.08.2016, 17:12 +0200 schrieb Michael Niedermayer:
> On Sun, Jul 31, 2016 at 07:09:26PM +0200, Jens Ziller wrote:
> > 
> > Am Sonntag, den 31.07.2016, 16:33 +0100 schrieb Mark Thompson:
> > > 
> > > On 31/07/16 15:51, Jens Ziller wrote:
> > > > 
> > > > 
> > > > Am Samstag, den 30.07.2016, 17:30 +0100 schrieb Mark Thompson:
> [...]
> > 
> > > 
> > > Consider this sequence, where we want to decode a single image
> > > and
> > > then do something with it:
> > > 
> > > open decoder
> > > decode frame
> > > close decoder
> > > open <some other component>
> > > give it the frame we got from the decoder
> > > 
> > > To me that looks like it will invoke undefined behaviour
> > > (segfault or
> > > read garbage) when trying to access data[2] in the second
> > > component,
> > > because the pointer appears to be to the MMAL_ES_FORMAT_T in the
> > > MMAL_PORT_T on the decoder which we just destroyed.  If not,
> > > where is
> > > the reference which keeps that pointer valid living?
> > With MMAL decoder it works:
> > 
> > - configure decoder
> > - send many frames (in my tests between 5 and 20+) to decoder
> > - decoder give MMAL_ES_FORMAT_T
> > - configure decoder output port with given struct <- here we have
> > the
> > pointer
> > - decoder send the first decoded frame
> > 
> > The struct lives before the first frame is available. Decode a
> > single
> > frame is a spezial thing. The MMAL decoder is not made for this.
> > 
> > A
> > local copy from format struct make no sense for me.
> well, it makes sense to us for the code to work and not have
> undefined
> behavior.
> Please correct me if iam wrong but Hendrik, Mark and me are saying
> the same thing more or less, i think you should change the patch
> 
> also additionally, its nice if we can keep data[0..2] available for
> the raw 3 YUV planes, it might one day somewhere be nice to download
> the raw data into [0..2], using up the 2nd for this struct is not
> pretty
For YUV planes AV_PIX_FMT_YUV420P are the better choice
not AV_PIX_FMT_MMAL. 
But you have me convinced that I write a new patch, test it and send it
to the ml.

regards jens