Re: [Bino-list] raw_height glitch

[Vittorio Giovara]

Dear Martin,
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!
Vittorio

Nella citazione in data lun 03 ott 2011 10:17:33 CEST, Martin Lambers 
ha scritto:
> Hi Vittorio!
>
> On 20/09/11 15:10, Vittorio Giovara wrote:
>> I'm using bino to decode some hd stereo file and I believe bino is
>> reporting a wrong video size.
>> In fact, in a 1920x1080 video raw_width and raw_height are reported
>> respectively as 1920 and 1088.
>> Those additional 8 lines are due to the fact that 1080 is not a multiple
>> of the macroblock size (16) and they shouldn't be presented to the video
>> surface (at leat for h264); most likely this is a bug in ffmpeg/libav,
>> but is there any workaround we could apply to bino?
>
> I now stumbled on a video file that shows this problem, and I noticed
> that FFmpeg originally knows the correct size and later reports the
> wrong size. (Try bino with --log-level=debug to see the output of
> av_dump_format(), which lists the correct video size).
>
> 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?
>
> Martin