[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bino-list] raw_height glitch
From: |
Vittorio Giovara |
Subject: |
Re: [Bino-list] raw_height glitch |
Date: |
Mon, 10 Oct 2011 12:38:02 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 |
Works like a charm!
thanks
Vittorio
Nella citazione in data ven 07 ott 2011 07:00:44 CEST, Martin Lambers
ha scritto:
> On 04/10/11 12:53, Vittorio Giovara wrote:
>> Nella citazione in data lun 03 ott 2011 10:17:33 CEST, Martin Lambers
>> ha scritto:
>>> I found out that the frame size reported for a video stream can change
>>> after the call to avcodec_open(). Before it was 1920x1080, afterwards it
>>> was 1920x1088.
>>>
>>> Attached is an experimental patch that uses the originally reported size
>>> in such a case. But I'm not sure that this is the correct way to do it.
>>>
>>> There are also coded_width and coded_height entries in AVCodecContext,
>>> and I don't know what they are used for. FFplay does not seem to look at
>>> them, so I guess we should not either.
>>>
>>> Can you test the patch? Does it work for you?
>>>
>> I tested the patch and indeed it works fine. I noticed
>> coded_width/height in the API as well and I remember trying using them
>> but the reported size was always the wrong one. I'm sure there is a bug
>> inside ffmpeg/libav about how they handle the sps information for
>> detecting the video size.
>>
>> Anyways, now I can see the full video at 1920x1080, thanks for spending
>> some time on this!
>
> I now added an additional sanity check and committed the patch. Since we
> only use the older width/height values if they are valid, this change
> should not break other video types, and it should also work with future
> versions of FFmpeg that might fix/change the current behaviour.
>
> Martin