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

[Michael Niedermayer]

On Sun, Aug 14, 2016 at 05:02:03PM +0200, Jens Ziller wrote:
> 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

>  mmaldec.c |   20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> e1e1ab964f9024ea523085fe7ddca4549601d51a  0001-v5-fill-AVFrame-interlaced_frame-and-top_field_first.patch
> From 66f0e12eb3e7d83113b76d8e0a71d0da328de195 Mon Sep 17 00:00:00 2001
> From: Jens Ziller <zillevdr at gmx.de>
> Date: Sun, 14 Aug 2016 16:44:39 +0200
> Subject: [PATCH] v5 fill AVFrame->interlaced_frame and top_field_first with
>  MMAL_PARAMETER_VIDEO_INTERLACE_TYPE_T and AVCodecContext->framerate from
>  MMAL_ES_FORMAT_T for deinterlacer and renderer

applied

thanks

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- 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/20160912/ee74a939/attachment.sig>