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

[Michael Niedermayer]

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. 


> 
> 
> >> (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).

try:
ffmpeg -i matrixbench_mpeg2.mpg -pix_fmt +bgr0 test.avi
it will fail ad bgr0 us unsupported, this case should print a list
of supported pixel formats by the encoder but doesnt
a patch fixing this is welcome

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120908/5cc84340/attachment.asc>