[Ffmpeg-devel] looking for a robust way of checking settings in advance ... possible RFE?

Karl H. Beckers karl.h.beckers
Fri Oct 27 21:15:28 CEST 2006


Hi all,

<standard RFE disclaimer>
If what I'm talking about is already implemented and I just didn't find
it, I apologize and will gladly follow whatever rtfms I get.
</standard RFE disclaimer>

I'm working on a GUI application where I would like make it easy for
users to captures smth. click together some settings and save their
stuff to a video of various formats and codecs. 

Now, I'm lacking a robust but generic way of checking the settings
selected for plausibility. Part of the information needed is certainly
available (like pix formats a codec supports, audio/video codecs
supported by an output format), but not all. With DV for example, only
certain frame sizes are supported and the supported frame sizes differ
depending on the pix fmt you use. And there is (I think) no way of
checking that other than trying and watching the failure of a wrong
setting, sometimes watch it segfault if you try to use a feature that
the selected combination of format and codec(s) does not implement.

I know it's not Xmas yet, but I would very much prefer it the
application using the API did not have to know that DV is a special case
but that knowledge was encapsulated in the API.

I'd imagine smth. along the lines of:

boolean 
av_codec_context_validate(
	AVCodecContext check_this, 
	boolean strict);

boolean
av_output_format_validate(
	AVOutputFormat check_this, 
	boolean strict, 
	boolean deep);

... perhaps there are more.

Even more, for a GUI application I'd like to have a consistent way of
getting a complete set of everything that's not supported to present
only the supported options to the user for selection.

I suppose it's going to be complicated for cases where you can't just
say "codec X supports pix fmt Y" but need constructions like "codec X
supports pix fmt Y at size Z and pix fmt A at size B" ... and then each
of those might only be valid at certain frame rates, or such.
Nevertheless, I think it would be a great plus.

Does this sound at all feasible (or am I missing smth. and just flogging
a dead horse)?

Regards,

Karl.









More information about the ffmpeg-devel mailing list