[FFmpeg-devel] Before I *fix this*, please confirm that it is in fact a *bug*

[Chris Stones]

>
>
> > What I would consider a *bug* here, is the need for us to specify
> > the input pixel format of the images.. png's could be bgra or rgb24.
> > The user needs to know detailed information about the source images, even
> > though ffmpeg is completely able to figure it out for itself.
> >
> > What do you guys think? Bug?
>
> bug
>
>
> >
> > Secondly, if you agree that there is anything here to fix, how would
> > you prefer i go about it ???
> >
> > I see 3 solutions.
> >
> > 1) Make yuv420p default for the snow video codec... don't error out if
> > pix_fmt is not specified
> >
>
> > 2) Prevent a user supplied -pix_fmt from taking effect outside of its
> > context.. for example, in this case, when supplied as part of the first
> > encode option, it should not take effect on the following image2 import
> > options.
>
> this
> [...]
> --
>

Looks like the global frame_pix_fmt is to blame.
new_video_stream seems to ignore it if it is not compatible with the codec.
opt_input_file will set it to the input file pixel format if it is set to
PIX_FMT_NONE, and will cause a failure if it is not set to the inputs actual
format at a later stage.

Unless Im mistaken, the opt_input_file function should completely ignore
global frame_pix_fmt ????

Attached is a patch which *fixes it for me(tm)*

I'm very un-familiar with the ffmpeg source, let me know if I'm being
stupid.

THANKS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pix_fmt.patch
Type: application/octet-stream
Size: 550 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100225/287ec2a2/attachment.obj>