Re: [Bino-list] raw_height glitch

[Martin Lambers]

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

bino-frame-size-workaround.patch
Description: Text Data