[MPlayer-dev-eng] [PATCH] Fix vd_ffmpeg.c::get_format() to actually query format

Gwenole Beauchesne gbeauchesne at splitted-desktop.com
Thu Feb 19 13:40:37 CET 2009


On Thu, 19 Feb 2009, Reimar Döffinger wrote:

> On Thu, Feb 19, 2009 at 11:40:24AM +0100, Gwenole Beauchesne wrote:
>> - init_vo() was never actually testing the fmt[i] since it turned out to
>> unconditionnally test the best_csp previously set.
>
> ?? I can't see that.

Neither can I, now with the file fully open wide. ;-)

> Width/height being 0 is an issue indeed though, but I think it needs to
> be fixed in FFmpeg, because whether a certain image format works can
> well depend on the size (e.g. directx uses a different path for RGB
> which is not restricted by the maximum overlay dimensions, the YV12 path
> is though).

AFAICS, MPEG-1/2 is fine. Probably is H.263/MPEG-4 too.

H.264 is problematic. Depending on the bitstream, avctx->{width,height} 
could be already be valid at decode_init() time... or not. You can try 
e.g. Lizzie^WGrey.ts (zero size) vs. NeroAVC sample (valid size).

For VC-1, it may be necessary to move the pix_fmt selection down after 
vc1_common_init(). And anyway, without hwaccel pix_fmts, I think VC-1 init 
code is probably wrong already. i.e. we unconditionnaly reset pix_fmt in 
ff_h263_decode_init() just after it was set in vc1_decode_init(): 
PIX_FMT_GRAY8 vs. PIX_FMT_YUV420P. I don't think it was expected.


More information about the MPlayer-dev-eng mailing list