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: 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

reply via email to

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