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

[Peter B.]

On 09/08/2012 12:37 PM, Michael Niedermayer wrote:
> On Sat, Sep 08, 2012 at 12:02:14PM +0200, Peter B. wrote:
>> 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?
> I really dont understand what is so hard on simply downloading 10
> files from a page and not messing with them before encoding.
> no other tools, no capture, no A/D nothing.
> you want to test 4:2:0 you select a 4:2:0 file and test with it
> you want to test 4:4:4 you select a 4:4.4 file and test with it
> you dont select a 4:4:4 file and convert it to rgb to test rgb
> if you can avoid it
>
> all the "correct capture, A/D ..." is long done already for these
> standard videos. 
>
Ah, ok!
I just didn't understand what you meant. Perfectly clear now!
No objections from my side.

Pb