[FFmpeg-devel] evaluating the experimental status of ffv1 version 3

[Peter B.]

On 09/08/2012 02:50 AM, Michael Niedermayer wrote:
> On Fri, Sep 07, 2012 at 03:41:21PM +0200, Peter B. wrote:
>> On 09/06/2012 08:49 PM, Michael Niedermayer wrote:
>>> I think if i didnt miss any tests then theres still a significnat lack
>>> of tests that where run to have sufficient information on what the
>>> default should be
>>>
>>> I think that at a minimum 10 samples that cover every combination of
>>> 8bit, >8bit and RGB,4:2:0,4:4:4 should be tested
>>> all tests should be done in 1pass, 2pass, and 2pass with a 1pass from
>>> another file of same type.
>>> all compressed file sizes should be posted here nicely formated in a
>>> table, with average, best and worst differences highlighted
>>> What it is to test, is gop=1 vs gop=300 for FFV1.3
>> The combination of pix_fmts you mention above, is already done in my
>> tests, if I understood you correctly (Except for RGB).
>> I'm encoding the source into each available YUV pix_fmt supported by
>> FFv1.
> We really have to test with unconverted material or material that has
> been converted externally. That is the input to the decoder has to be
> trusted to be good not the input to our converter. We want to
> exclude all variables that could affect any tests
I'm not really sure what you mean...
Here's how I understood it:

1) Use unconverted material or material converted externally:
Examples:
*) Direct capture of e.g. SD-SDI stream?
*) other material which has been recorded using other (non-ffmpeg)
tools. As most free-software video tools are based on ffmpeg, this might
mean capturing using proprietary applications?

2) I do not understand  this one:

"That is the input to the decoder has to be trusted to be good not the input to our converter."

The input to the decoder has to be trusted: acknowledged.
"Not the input to our converter": Which part exactly is considered "our
converter"?
The A/D converter?


>> (btw: Is there any way to list which pix_fmts are supported by a
>> certain codec? I kind of found it out by brute-force encoding - and
>> reading the sourcecode)
> I dont think so, a patch improving this is welcome, especially when
> the choosen pixel format isnt supported, the supported ones should
> be printed
>
The current behavior is that it automatically (=silently) falls back to
a supported pix_fmt. Of course, this is written to the console, but for
automatic processing it's not detectable (I guess).

Pb