bino-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bino-list] raw_height glitch


From: Martin Lambers
Subject: Re: [Bino-list] raw_height glitch
Date: Fri, 07 Oct 2011 07:00:44 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]