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

[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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160812/84cc7685/attachment.sig>