[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