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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
