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

[Jens Ziller]

Am Samstag, den 13.08.2016, 13:16 +0200 schrieb 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.
> 
Here are the new version. No data[2] pointer more. For this AVFrame
top_field_first and AVCodecContext->framerate is used.

regards jens
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-v5-fill-AVFrame-interlaced_frame-and-top_field_first.patch
Type: text/x-patch
Size: 3156 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160814/7b244752/attachment.bin>