On Fri, Jun 12, 2015 at 9:01 PM, Andreas Cadhalpun <andreas.cadhal...@googlemail.com> wrote: > On 12.06.2015 21:51, Hendrik Leppkes wrote: >> On Fri, Jun 12, 2015 at 9:23 PM, Andreas Cadhalpun >>> I agree that it is not really elegant, but removing the assumption that >>> the avctx width/height/pix_fmt are from the last decoded frame instead >>> of the last returned frame from the h264 decoder is beyond me. >>> If someone more familiar with the h264 decoder could do that, it would >>> be great. >>> But until then, having this workaround is better than the current state. >>> So I've pushed this. >>> >> >> This patch is super ugly and a mega hack. > > Maybe. ;) > >> Just inform consumers that only AVFrame has the actual up-to-date >> values when a change in the bitstream happens and stop doing such >> crap. > > That's not currently documented, so it would effectively be an API change. > And since the h264 decoder is the only one misbehaving in this way, > fixing it is the better alternative.
Not necessarily, a lot of parameters are valid only in the avframe while in the context they might not be completely updated. The first that comes to mind is interlaced_frame -- there are 3 places this might (or might not) be signalled (context, frame and stream or parser iirc) but the RightWay is to check it from the frame only. Do you have a test case where using the API exposes some kind of problem? -- Vittorio _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel