[FFmpeg-devel] [PATCH] h264: update avctx width/height when flushing

[Andreas Cadhalpun]

On 10.06.2015 21:50, Michael Niedermayer wrote:
> On Wed, Jun 10, 2015 at 09:10:31PM +0200, Andreas Cadhalpun wrote:
>> On 10.06.2015 12:01, Michael Niedermayer wrote:
>>>> also avctx->pix_fmt would then still potentially not match the last
>>>> output frame, also pix_fmt has the same problem as above
>>
>> Yes, pix_fmt should also be updated. Attached patch does this, but
> 
>> this caused changes in some h264 reinit fate tests. Is that a problem?
> 
> looking at the testfile with ffplay shows heavy artifacts after the
> patch and no artifacts before

Yes, that's bad...

>>>> ive fixed one use of width/height not to depend on the AVCodecContext
>>>> value but a 2nd remains
>>>
>>> actually theres more code that uses it
>>> ff_h264_draw_horiz_band() and its callers use h->avctx->height too
>>
>> Could these be fixed to use a new H264Context field instead?
> 
> i think it might be possible for them to use the AVFrame height
> but the code should be tested

I tried a few things, but couldn't get it to work that way.
In the end I decided to work around the differing expectations of the h264
decoder and the API users by backing up and restoring the internally
used values. See attached patch.
I tested this extensively and it fixes the problem without introducing
another one as far as I can tell.
One can see the effect, when using -loglevel debug, e.g. for the
reinit-small_422_9-to-small_420_9.h264 sample:
 * Without the patch:
[...]
[h264 @ 0x196e320] Reinit context to 240x208, pix_fmt: yuv420p9le
Frame parameters mismatch context 240,196,80 != 240,196,70
    Last message repeated 1 times
Input stream #0:0 frame changed from size:240x196 fmt:yuv422p9le to size:240x196 fmt:yuv420p9le
[...]

 * With the patch:
[...]
[h264 @ 0x2707320] Reinit context to 240x208, pix_fmt: yuv420p9le
Input stream #0:0 frame changed from size:240x196 fmt:yuv422p9le to size:240x196 fmt:yuv420p9le
[...]

The messages about the parameter mismatch for the two frames disappear.

> especially with a file that uses croping and some application that
> uses these codepathes
> iam not sure this codepath works currently with files using croping
> and using the AVFrame height and if needed an adjusted pointer
> offset might fix that or might break it depending on what applications
> expect

I don't know, whether or not this currently works, but it shouldn't
be affected by attached patch.

Best regards,
Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-h264-update-avctx-width-height-pix_fmt-when-returnin.patch
Type: text/x-diff
Size: 3654 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150612/4b87b371/attachment.bin>