| The same problem was reported to me when viewing these videos: http://huberbuam.zdf.de/ZDFde/inhalt/7/0,1872,8352935,00.html
IMHO, 1.2.1 should be released ASAP.
fred Le 10 oct. 2011 à 12:38, Vittorio Giovara a écrit : 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
|