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: > > > > > > Does this also do the right thing if the decoder is reconfigured > > > with > > > frames outstanding? To me (without really knowing the code) it > > > looks > > > like it will overwrite the old format (line 702) and therefore > > > mess > > > with existing frames, though there are multiple levels of > > > indirection > > > so the frame could be holding onto a reference by some route I'm > > > not > > > seeing. > > MMAL_EVENT_FORMAT_CHANGED is set before the first decoded frame > > give > > out. I have never seen that this flag is set twice between > > start/stop > > decoder. > Try the test stream h264/reinit-large_420_8-to-small_420_8.h264 in > FATE? I don't test it. I tested with MPEG2 and H264 DVB-S streams. Where can I find this test stream? > > > > > > > > > Similarly for stopping the decoder - there may be output frames > > > which > > > are still valid, and it looks to me like the format structure > > > will > > > have disappeared. (Is there some internal reference via the > > > MMAL_BUFFER_HEADER_T which solves both of these cases, maybe? If > > > so, > > > it might be clearer if you could use that internal reference to > > > set > > > the value rather than going via the decoder.) > > The struct MMAL_ES_FORMAT_T will copied in the MMAL_PORT_T struct > > to > > configure the component. There it lives until the application > > change > > anything. > Hmm, that's not quite what I meant to ask; apologies because the > question wasn't very clear. Sorry, english is not my mother language. > > 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. Regards, Jens _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
