Michael Niedermayer | 20 Apr 15:50 2012
Picon
Picon

FFV1.3

Hi

Ive just commited some changes to the ffv1 codec v1.3

Whats new:

mandatory CRC on the global header

optional CRC on slices (The optionality is for discussion, we can make
it mandatory if theres consens that this would be better, it would
slow the encoder down a bit, bitrate wise it probably is negligible)

many fields have been moved from the frame header to the slice header,
this is needed so one slice can be decoded when the others are damaged
or lost

aspect ratio, top field first and interlace fields added, these could
be droped again but i think they are better in ffv1 than the container
because not all containers have these fields and thouse which do
cant always change them mid file while mixed progressive/interlaced
content exists and we want to support losslessly preserving it

Comments welcome

--

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 3
"Rare item" - "Common item with rare defect or maybe just a lie"
"Professional" - "'Toy' made in china, not functional except as doorstop"
(Continue reading)

Tim Nicholson | 23 Apr 14:04 2012
Picon

Re: FFV1.3

On 20/04/12 14:50, Michael Niedermayer wrote:
> Hi
> 
> Ive just commited some changes to the ffv1 codec v1.3
> 
> Whats new:
> 
> mandatory CRC on the global header
> 

Sounds good.

> optional CRC on slices (The optionality is for discussion, we can make
> it mandatory if theres consens that this would be better, it would
> slow the encoder down a bit, bitrate wise it probably is negligible)
> 
> many fields have been moved from the frame header to the slice header,
> this is needed so one slice can be decoded when the others are damaged
> or lost
> 

This all sounds good from the point of robustness, and if ffv1 is
considered as a good archiving format (which is what I presume has
prompted these tweaks) then I would opt for per slice CRC and live with
the encoder overhead. However an option would give other users the
choice, so how about the default being on with the option to disable it?

> aspect ratio, top field first and interlace fields added, these could
> be droped again but i think they are better in ffv1 than the container
> because not all containers have these fields and thouse which do
(Continue reading)

Peter B. | 24 Apr 13:22 2012

Re: FFV1.3

Quoting Tim Nicholson <nichot20 <at> yahoo.com>:

> On 20/04/12 14:50, Michael Niedermayer wrote:
>> Hi
>>
>> Ive just commited some changes to the ffv1 codec v1.3
>>
>> Whats new:
>>
>> mandatory CRC on the global header
>>
>
> Sounds good.

Definitely. Thanks Michael!
One question about that: For which content-parts (frames?) are CRCs  
stored in there?

>> many fields have been moved from the frame header to the slice header,
>> this is needed so one slice can be decoded when the others are damaged
>> or lost
>>
>
> This all sounds good from the point of robustness, and if ffv1 is
> considered as a good archiving format (which is what I presume has
> prompted these tweaks) then I would opt for per slice CRC and live with
> the encoder overhead.

I partially agree with Tim, although I'm a bit sceptic if the "holy  
grail of robustness" might be mistakenly perceived as replacement for  
(Continue reading)

Dave Rice | 24 Apr 14:15 2012
Picon

Re: FFV1.3

Hi Peter,

On Apr 24, 2012, at 7:22 AM, Peter B. wrote:

> Quoting Tim Nicholson <nichot20 <at> yahoo.com>:
> 
>> On 20/04/12 14:50, Michael Niedermayer wrote:
>>> Hi
>>> 
>>> Ive just commited some changes to the ffv1 codec v1.3
>>> 
>>> Whats new:
>>> 
>>> mandatory CRC on the global header
>>> 
>> 
>> Sounds good.
> 
> Definitely. Thanks Michael!
> One question about that: For which content-parts (frames?) are CRCs stored in there?
> 
> 
>>> many fields have been moved from the frame header to the slice header,
>>> this is needed so one slice can be decoded when the others are damaged
>>> or lost
>>> 
>> 
>> This all sounds good from the point of robustness, and if ffv1 is
>> considered as a good archiving format (which is what I presume has
>> prompted these tweaks) then I would opt for per slice CRC and live with
(Continue reading)

Michael Niedermayer | 24 Apr 21:18 2012
Picon
Picon

Re: FFV1.3

On Tue, Apr 24, 2012 at 01:22:23PM +0200, Peter B. wrote:
> Quoting Tim Nicholson <nichot20 <at> yahoo.com>:
> 
> >On 20/04/12 14:50, Michael Niedermayer wrote:
> >>Hi
> >>
> >>Ive just commited some changes to the ffv1 codec v1.3
> >>
> >>Whats new:
> >>
> >>mandatory CRC on the global header
> >>
> >
> >Sounds good.
> 
> Definitely. Thanks Michael!
> One question about that: For which content-parts (frames?) are CRCs
> stored in there?

They are on the global header and slices
each frame is split into several slices. These slices also allow
multithreaded decoding and encoding.

[...]
> FFv1's strength and major field of application seems to be in the
> archival domain rather than production or on-site recording.
> Therefore, its requirements to be able to support mid-stream changes
> seems questionable from my point of view.
> Information like TFF/BFF, aspect ratio, etc. must be provided
> somehow - and I am not sure where this information could be gathered
(Continue reading)

Laurent Aimar | 25 Apr 21:58 2012

Re: FFV1.3

Hi,

On Tue, Apr 24, 2012 at 01:22:23PM +0200, Peter B. wrote:
> FFv1's strength and major field of application seems to be in the  
> archival domain rather than production or on-site recording. Therefore, 
> its requirements to be able to support mid-stream changes seems 
> questionable from my point of view.
> Information like TFF/BFF, aspect ratio, etc. must be provided somehow - 
> and I am not sure where this information could be gathered from  
> automatically (except field-order, maybe).
 With MPEG codecs (MPEG-1/2, MPEG-4 ASP, MPEG-4 AVC), theses informations
(aspect ratio, field order and informations to create telecine streams)
are contained in the bitstream (some at the picture level, some at the
sequence level). As such, they can be extracted by the decoder and
provided to the encoder.

 One use case for AR changes is for TV streams. On some TV channels, 16:9
was used for movies, and 4:3 for somes ads/old reportages.

Regards,

--

-- 
fenrir
Peter B. | 25 Apr 22:39 2012

Re: FFV1.3

On 04/25/2012 09:58 PM, Laurent Aimar wrote:
>  With MPEG codecs (MPEG-1/2, MPEG-4 ASP, MPEG-4 AVC), theses informations
> (aspect ratio, field order and informations to create telecine streams)
> are contained in the bitstream (some at the picture level, some at the
> sequence level). As such, they can be extracted by the decoder and
> provided to the encoder.
>
>  One use case for AR changes is for TV streams. On some TV channels, 16:9
> was used for movies, and 4:3 for somes ads/old reportages.
>
Yes, for broadcast-, production and web *streams* this makes perfect
sense (MPEG-*, DV, HDV, ...).

Only some "born digital" material should be converted to lossless. With
some, on the other hand I'm not sure if it's a good idea (or necessary)
to transcode to lossless.
This would be like converting a collection of recordings made directly
to MP3 to WAV: There would be no gain, except for a more homogeneous
format collection in the archive. For video the current size
consummation is a major factor for favoring not to do so.

For analog material, AR information, as well as field-order cannot
automatically be detected in a reasonable way. Maybe if it contains WSS
(Widescreen signaling [1]) information, but I'm not sure if that can be
stored on e.g. (S)VHS tapes.

Some other material which already has a digital source (like DigiBeta)
cannot be recorded without transcoding. So, mid-stream changes like
AR,etc can also not be recorded in order to provide the information
needed if using FFv1.3's in-stream properties.
(Continue reading)

Michael Niedermayer | 24 Apr 21:22 2012
Picon
Picon

Re: FFV1.3

On Mon, Apr 23, 2012 at 01:04:15PM +0100, Tim Nicholson wrote:
> On 20/04/12 14:50, Michael Niedermayer wrote:
> > Hi
> > 
> > Ive just commited some changes to the ffv1 codec v1.3
> > 
> > Whats new:
> > 
> > mandatory CRC on the global header
> > 
> 
> Sounds good.
> 
> > optional CRC on slices (The optionality is for discussion, we can make
> > it mandatory if theres consens that this would be better, it would
> > slow the encoder down a bit, bitrate wise it probably is negligible)
> > 
> > many fields have been moved from the frame header to the slice header,
> > this is needed so one slice can be decoded when the others are damaged
> > or lost
> > 
> 
> This all sounds good from the point of robustness, and if ffv1 is
> considered as a good archiving format (which is what I presume has
> prompted these tweaks) then I would opt for per slice CRC and live with
> the encoder overhead. However an option would give other users the
> choice, so how about the default being on with the option to disable it?

ive added a todo item to add a no_crc flag to our encoder.
but if you want to help, a patch adding AVOptions support and an
(Continue reading)

Dave Rice | 25 Apr 02:05 2012
Picon

Re: FFV1.3

Hi,

On Apr 20, 2012, at 9:50 AM, Michael Niedermayer wrote:

> Hi
> 
> Ive just commited some changes to the ffv1 codec v1.3

I downloaded from git-master and changed line 900 of ffv1.c to "    s->version=3;" in order to start some
testing. So far I haven't gotten any files to encode and have been getting an error on the slice number
regarding of the source content. Here's an example output using testsrc as an input.

 ./ffmpeg -y -t 5 -f lavfi -i testsrc -c:v ffv1 -strict experimental testsrc_ffv1.mov 
ffmpeg version N-40099-g2b336df Copyright (c) 2000-2012 the FFmpeg developers
  built on Apr 24 2012 17:20:15 with llvm_gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
  configuration: --enable-gpl
  libavutil      51. 47.100 / 51. 47.100
  libavcodec     54. 15.100 / 54. 15.100
  libavformat    54.  3.100 / 54.  3.100
  libavdevice    53.  4.100 / 53.  4.100
  libavfilter     2. 72.100 /  2. 72.100
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 11.100 /  0. 11.100
  libpostproc    52.  0.100 / 52.  0.100
[testsrc  <at>  0x7f9843418440] size:320x240 rate:25/1 duration:-1.000000 sar:1/1
Input #0, lavfi, from 'testsrc':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 320x240 [SAR 1:1 DAR 4:3], 25 tbr, 25 tbn, 25 tbc
[buffer  <at>  0x7f98434197c0] w:320 h:240 pixfmt:rgb24 tb:1/1000000 sar:1/1 sws_param:flags=2
[buffersink  <at>  0x7f9843419a80] auto-inserting filter 'auto-inserted scale 0' between the filter 'src'
(Continue reading)

Michael Niedermayer | 25 Apr 02:35 2012
Picon
Picon

Re: FFV1.3

On Tue, Apr 24, 2012 at 08:05:27PM -0400, Dave Rice wrote:
> Hi,
> 
> On Apr 20, 2012, at 9:50 AM, Michael Niedermayer wrote:
> 
> > Hi
> > 
> > Ive just commited some changes to the ffv1 codec v1.3
> 
> I downloaded from git-master and changed line 900 of ffv1.c to "    s->version=3;" in order to start some
testing. So far I haven't gotten any files to encode and have been getting an error on the slice number
regarding of the source content. Here's an example output using testsrc as an input.

it need something like -slices 4 

[...]
--

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel <at> ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Dave Rice | 25 Apr 03:07 2012
Picon

Re: FFV1.3


On Apr 24, 2012, at 8:35 PM, Michael Niedermayer wrote:

> On Tue, Apr 24, 2012 at 08:05:27PM -0400, Dave Rice wrote:
>> Hi,
>> 
>> On Apr 20, 2012, at 9:50 AM, Michael Niedermayer wrote:
>> 
>>> Hi
>>> 
>>> Ive just commited some changes to the ffv1 codec v1.3
>> 
>> I downloaded from git-master and changed line 900 of ffv1.c to "    s->version=3;" in order to start some
testing. So far I haven't gotten any files to encode and have been getting an error on the slice number
regarding of the source content. Here's an example output using testsrc as an input.
> 
> it need something like -slices 4 

Thanks that worked. With ffv1 version 1.3 and -slices 4 I'm getting 81 fps encoding whereas version 1.0 on
the same content gave 31 fps.
On my Mac files encoded with ffv1 version 1.3 cause crashes with the latest releases of QuickTime with
Perian, VLC, and but works with with ffplay when the version of ffv1.c is set to 0 or to 3.

So far with sampling various source content at various bits I've found that both the resulting ffv1 version
1 and version 3 produce the same framemd5s.

In ffv1.c I noticed that a CRC mismatch warning could be given but wasn't able to find a situation to actually
produce this warning.
Dave Rice
(Continue reading)

Michael Niedermayer | 25 Apr 13:23 2012
Picon
Picon

Re: FFV1.3

On Tue, Apr 24, 2012 at 09:07:54PM -0400, Dave Rice wrote:
> 
> On Apr 24, 2012, at 8:35 PM, Michael Niedermayer wrote:
> 
> > On Tue, Apr 24, 2012 at 08:05:27PM -0400, Dave Rice wrote:
> >> Hi,
> >> 
> >> On Apr 20, 2012, at 9:50 AM, Michael Niedermayer wrote:
> >> 
> >>> Hi
> >>> 
> >>> Ive just commited some changes to the ffv1 codec v1.3
> >> 
> >> I downloaded from git-master and changed line 900 of ffv1.c to "    s->version=3;" in order to start some
testing. So far I haven't gotten any files to encode and have been getting an error on the slice number
regarding of the source content. Here's an example output using testsrc as an input.
> > 
> > it need something like -slices 4 
> 
> Thanks that worked. With ffv1 version 1.3 and -slices 4 I'm getting 81 fps encoding whereas version 1.0 on
the same content gave 31 fps.
> On my Mac files encoded with ffv1 version 1.3 cause crashes with the latest releases of QuickTime with
Perian, VLC, and but works with with ffplay when the version of ffv1.c is set to 0 or to 3.

1.3 support needs latest ffmpeg of course. perian and vlc probably
use a too old version of ffmpegs libavcodec.

> 
> So far with sampling various source content at various bits I've found that both the resulting ffv1
version 1 and version 3 produce the same framemd5s.
(Continue reading)

Peter B. | 25 Apr 15:03 2012

Re: FFV1.3

On 04/25/2012 03:07 AM, Dave Rice wrote:
> Thanks that worked. With ffv1 version 1.3 and -slices 4 I'm getting 81 fps encoding whereas version 1.0 on
the same content gave 31 fps.
That matches my initial tests from early versions of ffv1.2: It's more
than twice as fast if it can use multithreading.

 <at> Dave:
Could you tell me on which machine (CPU/MHz/cores), and which which
video-properties you got these numbers (source,resolution,bit-depth)?

Thank you very much.

Pb
Dave Rice | 26 Apr 16:02 2012
Picon

Re: FFV1.3


On Apr 25, 2012, at 9:03 AM, Peter B. wrote:

> On 04/25/2012 03:07 AM, Dave Rice wrote:
>> Thanks that worked. With ffv1 version 1.3 and -slices 4 I'm getting 81 fps encoding whereas version 1.0 on
the same content gave 31 fps.
> That matches my initial tests from early versions of ffv1.2: It's more
> than twice as fast if it can use multithreading.
> 
>  <at> Dave:
> Could you tell me on which machine (CPU/MHz/cores), and which which
> video-properties you got these numbers (source,resolution,bit-depth)?

Macbook Pro 2.3 GHz intel core i7
720x486 29.97 fps v210 -> ffv1 at same specs and pixel format

Ultimately I'd like to use the blackmagic path to allow direct capture from analog source to ffv1 (similar
to what you're doing with ffmpeg-tryouts).
Dave

> Thank you very much.
> 
> Pb
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel <at> ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Peter B. | 16 May 20:35 2012

Re: FFV1.3

Maybe a stupid question, but what is the right commandline call for
selecting the FFv1 version to use for encoding?

Thanks,
Pb
Michael Bradshaw | 16 May 20:43 2012

Re: FFV1.3

On Wed, May 16, 2012 at 12:35 PM, Peter B. <pb <at> das-werkstatt.com> wrote:
> Maybe a stupid question, but what is the right commandline call for
> selecting the FFv1 version to use for encoding?

ffmpeg -i input.mov -vcodec ffv1 -acodec copy output.mp4
?

Or do you mean something else?

FYI, this mailing list is primarily for the development of ffmpeg
itself. For help using ffmpeg, ffmpeg-user mailing list is probably
better.

--Michael
Peter B. | 16 May 21:01 2012

Re: FFV1.3

On 05/16/2012 08:43 PM, Michael Bradshaw wrote:
> On Wed, May 16, 2012 at 12:35 PM, Peter B. <pb <at> das-werkstatt.com> wrote:
>> Maybe a stupid question, but what is the right commandline call for
>> selecting the FFv1 version to use for encoding?
> ffmpeg -i input.mov -vcodec ffv1 -acodec copy output.mp4
> ?
>
> Or do you mean something else?
Yes, I'd like to validate/test FFv1's new versions 2 and 3. When v2 had
been developed, I had to modify a variable in the source to enable it,
but I've seen a commit-msg by Michael [1], which sounded to me like
selecting the version was now possible as parameter?

> FYI, this mailing list is primarily for the development of ffmpeg
> itself. For help using ffmpeg, ffmpeg-user mailing list is probably
> better.
>
I know, I'm sorry - I just thought that it might make sense to connect
it to the "FFv1.3" thread...

Pb

== References:
[1] http://patches.libav.org/patch/20071/
Michael Niedermayer | 16 May 22:11 2012
Picon
Picon

Re: FFV1.3

sOn Wed, May 16, 2012 at 09:01:46PM +0200, Peter B. wrote:
> On 05/16/2012 08:43 PM, Michael Bradshaw wrote:
> > On Wed, May 16, 2012 at 12:35 PM, Peter B. <pb <at> das-werkstatt.com> wrote:
> >> Maybe a stupid question, but what is the right commandline call for
> >> selecting the FFv1 version to use for encoding?
> > ffmpeg -i input.mov -vcodec ffv1 -acodec copy output.mp4
> > ?
> >
> > Or do you mean something else?
> Yes, I'd like to validate/test FFv1's new versions 2 and 3. When v2 had
> been developed, I had to modify a variable in the source to enable it,
> but I've seen a commit-msg by Michael [1], which sounded to me like
> selecting the version was now possible as parameter?
> 
> > FYI, this mailing list is primarily for the development of ffmpeg
> > itself. For help using ffmpeg, ffmpeg-user mailing list is probably
> > better.
> >
> I know, I'm sorry - I just thought that it might make sense to connect
> it to the "FFv1.3" thread...

-level 3

and thanks for validating testing

if you need help have questions ask me ...

[...]

--

-- 
(Continue reading)

Peter B. | 21 May 12:01 2012

Re: FFV1.3

Quoting Michael Niedermayer <michaelni <at> gmx.at>:

> sOn Wed, May 16, 2012 at 09:01:46PM +0200, Peter B. wrote:
>> On 05/16/2012 08:43 PM, Michael Bradshaw wrote:
>> > On Wed, May 16, 2012 at 12:35 PM, Peter B. <pb <at> das-werkstatt.com> wrote:
>> >> Maybe a stupid question, but what is the right commandline call for
>> >> selecting the FFv1 version to use for encoding?
>
> -level 3
>
> and thanks for validating testing
>
> if you need help have questions ask me ...

Thanks!
I've started writing a bash-script for automated transcoding tests. My  
first focus is to confirm losslessness, and get a rought overview  
about the filesizes generated, related to their encoding options  
(slices, gop-size, ...)

So far, everything looks good! :)

I'd be open (and grateful) for suggestions about which features to  
include in these tests. The bash-script will be published and is  
intended to allow easy reproduction of the test-suite in different  
environments, so others can verify and repeat the tests in the future.

How could I test the new ffv1.3 bitstream-goodies like aspect-ratio,  
CRC and field-order?

(Continue reading)

Michael Niedermayer | 22 May 04:40 2012
Picon
Picon

Re: FFV1.3

On Mon, May 21, 2012 at 12:01:05PM +0200, Peter B. wrote:
> Quoting Michael Niedermayer <michaelni <at> gmx.at>:
> 
> >sOn Wed, May 16, 2012 at 09:01:46PM +0200, Peter B. wrote:
> >>On 05/16/2012 08:43 PM, Michael Bradshaw wrote:
> >>> On Wed, May 16, 2012 at 12:35 PM, Peter B. <pb <at> das-werkstatt.com> wrote:
> >>>> Maybe a stupid question, but what is the right commandline call for
> >>>> selecting the FFv1 version to use for encoding?
> >
> >-level 3
> >
> >and thanks for validating testing
> >
> >if you need help have questions ask me ...
> 
> Thanks!
> I've started writing a bash-script for automated transcoding tests.
> My first focus is to confirm losslessness, and get a rought overview
> about the filesizes generated, related to their encoding options
> (slices, gop-size, ...)
> 
> So far, everything looks good! :)
> 
> I'd be open (and grateful) for suggestions about which features to
> include in these tests. The bash-script will be published and is

2 pass mode should be used, also its probably interrestimg to try
to generate the 2 pass statistics with one file and use them for
another in the 2nd pass (this should work well, and we may use
something like these statistics as default for 1 pass mode
(Continue reading)

Peter B. | 22 May 18:50 2012

Re: FFV1.3

On 05/22/2012 04:40 AM, Michael Niedermayer wrote:
> 2 pass mode should be used, also its probably interrestimg to try to
> generate the 2 pass statistics with one file and use them for another
> in the 2nd pass (this should work well, and we may use something like
> these statistics as default for 1 pass mode [...]
Oh, yes: I'm also looking forward to see how 2-pass mode performs
compression-wise.

Just so I understood you correctly:
Are you saying to generate pass-statistics for one file (e.g.
video_01.avi) and then use these statistics for *another* (?) file (e.g.
video_02.avi)?

From how I understand multi-pass encoding, I was assuming that each
2nd-pass requires the statistics for exactly the file to be encoded, but
your message sounds like these stats could be re-used generally somehow?
If so: How does that work? These stats are generated from the content,
so I thought they are highly content-specific?

Thanks,
Pb
Michael Niedermayer | 23 May 03:32 2012
Picon
Picon

Re: FFV1.3

On Tue, May 22, 2012 at 06:50:59PM +0200, Peter B. wrote:
> On 05/22/2012 04:40 AM, Michael Niedermayer wrote:
> > 2 pass mode should be used, also its probably interrestimg to try to
> > generate the 2 pass statistics with one file and use them for another
> > in the 2nd pass (this should work well, and we may use something like
> > these statistics as default for 1 pass mode [...]
> Oh, yes: I'm also looking forward to see how 2-pass mode performs
> compression-wise.
> 
> Just so I understood you correctly:
> Are you saying to generate pass-statistics for one file (e.g.
> video_01.avi) and then use these statistics for *another* (?) file (e.g.
> video_02.avi)?

yes

[...]
--

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel <at> ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Peter B. | 22 May 18:51 2012

Re: FFV1.3

Oh, and: how can I test the new features of ffv1.3's bitstream, like CRC
and so?

Thanks again,
Pb
Michael Niedermayer | 23 May 12:36 2012
Picon
Picon

Re: FFV1.3

On Tue, May 22, 2012 at 06:51:29PM +0200, Peter B. wrote:
> Oh, and: how can I test the new features of ffv1.3's bitstream, like CRC
> and so?

slice crcs can be enabled/disabled with
-slicecrc 1/0
(and -g 1 is highly recommanded)

you can then try a fuzzer of your choice to damage resulting files
and then try to play them to see how ffv1 handles that

currently it just displays things as is with damage and prints the
crc mismatches
in the future we might try to do better than just showing the known to
be damaged parts as is

also if you use more slices the damage will become more localized

and if you find a case that crashes or something else please send me
the damaged file that causes a crash

[...]

--

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
(Continue reading)

Peter B. | 23 May 20:23 2012

Re: FFV1.3

On 05/23/2012 12:36 PM, Michael Niedermayer wrote:
> and if you find a case that crashes or something else please send me
> the damaged file that causes a crash
>
I in fact did! :)

I've manually edited the ffv1.avi with the hexeditor "Bless" and damaged
some byte blocks by copy/pasting garbage. I've left some space between
the pastes/overwrites to spread the "error".
The resulting file plays (using ffplay), then throws CRC errors and
ill-colored blocks in the video - and then the video halts, while the
playback counter is still running.

Should I upload you the file on my FTP?

Thanks,
Pb
Michael Niedermayer | 23 May 22:30 2012
Picon
Picon

Re: FFV1.3

On Wed, May 23, 2012 at 08:23:54PM +0200, Peter B. wrote:
> On 05/23/2012 12:36 PM, Michael Niedermayer wrote:
> > and if you find a case that crashes or something else please send me
> > the damaged file that causes a crash
> >
> I in fact did! :)
> 
> I've manually edited the ffv1.avi with the hexeditor "Bless" and damaged
> some byte blocks by copy/pasting garbage. I've left some space between
> the pastes/overwrites to spread the "error".
> The resulting file plays (using ffplay), then throws CRC errors and
> ill-colored blocks in the video - and then the video halts, while the
> playback counter is still running.
> 
> Should I upload you the file on my FTP?

If theres significant additional video that isnt played, it surely
makes sense to look at why it isnt
if ffplay behaves very different from how it does on the undamaged
file it might be interrestin too

[...]
--

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
_______________________________________________
ffmpeg-devel mailing list
(Continue reading)

Peter B. | 24 May 10:28 2012

Re: FFV1.3

Quoting Michael Niedermayer <michaelni <at> gmx.at>:

> On Wed, May 23, 2012 at 08:23:54PM +0200, Peter B. wrote:
>> Should I upload you the file on my FTP?
>
> If theres significant additional video that isnt played, it surely
> makes sense to look at why it isnt
> if ffplay behaves very different from how it does on the undamaged
> file it might be interrestin too

Unfortunately, I'm not sure if I can access the file until Tuesday  
(long story), but I'll check if the duration of the not-played-part is  
sufficient in order to link the file.

I've also tried to use "zzuf" [1] for fuzzing the file, but even with  
a small value of "r=0.001", the .avi is so broken that ffplay outputs  
about 2-3 CRC errors, but doesn't show a single image.
Using "vbindiff" [2], I've taken a look at how much impact zzuf had on  
the file, but I'm still looking for a tool to do a binary-diff and  
count number of mismatching bytes. But that's still work in  
progress... :)

Greetings and Thanks,
Pb

== References:
[1] http://caca.zoy.org/wiki/zzuf
[2] http://www.cjmweb.net/vbindiff/
Peter B. | 30 May 22:29 2012

Re: FFV1.3

On 05/23/2012 10:30 PM, Michael Niedermayer wrote:
> If theres significant additional video that isnt played, it surely
> makes sense to look at why it isnt
> if ffplay behaves very different from how it does on the undamaged
> file it might be interrestin too
>
I've checked it again, and it seems that "ffplay" in general does not
stop playback at the end of *any* videofile I'm playing: The video just
stops, but the counter in the commandline is running as if it'd still be
playing...

However, I've found something interesting:
When disabling Slice-CRCs, the resulting file may be corrupted afterwards:

// ----------------------------------------
$ ffplay output/test-off.avi
// ----------------------------------------
ffplay version N-41161-ga1fc1d2 Copyright (c) 2003-2012 the FFmpeg
developers
  built on May 30 2012 21:26:47 with gcc 4.6.1
  configuration: --prefix=/usr/local
  libavutil      51. 55.100 / 51. 55.100
  libavcodec     54. 23.100 / 54. 23.100
  libavformat    54.  6.101 / 54.  6.101
  libavdevice    54.  0.100 / 54.  0.100
  libavfilter     2. 77.100 /  2. 77.100
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 15.100 /  0. 15.100
[avi  <at>  0x166f240] non-interleaved AVI
[ffv1  <at>  0x1670100] slice count 0 is invalid
(Continue reading)

Lou Logan | 30 May 22:35 2012

Re: FFV1.3

On Wed, 30 May 2012 22:29:04 +0200, Peter B. wrote:

> On 05/23/2012 10:30 PM, Michael Niedermayer wrote:
> > If theres significant additional video that isnt played, it surely
> > makes sense to look at why it isnt
> > if ffplay behaves very different from how it does on the undamaged
> > file it might be interrestin too
> >
> I've checked it again, and it seems that "ffplay" in general does not
> stop playback at the end of *any* videofile I'm playing: The video just
> stops, but the counter in the commandline is running as if it'd still be
> playing...

The -autoexit option will allow ffplay to exit at the end of the video.
Dave Rice | 30 May 22:47 2012
Picon

Re: FFV1.3


On May 30, 2012, at 4:35 PM, Lou Logan wrote:

> On Wed, 30 May 2012 22:29:04 +0200, Peter B. wrote:
> 
>> On 05/23/2012 10:30 PM, Michael Niedermayer wrote:
>>> If theres significant additional video that isnt played, it surely
>>> makes sense to look at why it isnt
>>> if ffplay behaves very different from how it does on the undamaged
>>> file it might be interrestin too
>>> 
>> I've checked it again, and it seems that "ffplay" in general does not
>> stop playback at the end of *any* videofile I'm playing: The video just
>> stops, but the counter in the commandline is running as if it'd still be
>> playing...
> 
> The -autoexit option will allow ffplay to exit at the end of the video.

I'm curious why this behavior isn't the default.
Lou Logan | 30 May 23:02 2012

Re: FFV1.3

On Wed, 30 May 2012 16:47:15 -0400, Dave Rice wrote:

> 
> On May 30, 2012, at 4:35 PM, Lou Logan wrote:
> >
> > The -autoexit option will allow ffplay to exit at the end of the video.
> 
> I'm curious why this behavior isn't the default.

At the risk of diverging any FFV1.3 discussion I prefer the current
behavior because I seek often (ffplay is actually my preferred media
player most of the time), and it's annoying to have the window
automatically close if I seek past the end.
Peter B. | 30 May 23:07 2012

Re: FFV1.3

On 05/30/2012 11:02 PM, Lou Logan wrote:
> At the risk of diverging any FFV1.3 discussion I prefer the current
> behavior because I seek often (ffplay is actually my preferred media
> player most of the time), and it's annoying to have the window
> automatically close if I seek past the end.
I agree with Lou about the closing of the window, *but* I find it rather
confusing that the playback counter is still running.

Pb
Michael Niedermayer | 31 May 01:06 2012
Picon
Picon

Re: FFV1.3

On Wed, May 30, 2012 at 11:07:53PM +0200, Peter B. wrote:
> On 05/30/2012 11:02 PM, Lou Logan wrote:
> > At the risk of diverging any FFV1.3 discussion I prefer the current
> > behavior because I seek often (ffplay is actually my preferred media
> > player most of the time), and it's annoying to have the window
> > automatically close if I seek past the end.
> I agree with Lou about the closing of the window, *but* I find it rather
> confusing that the playback counter is still running.

i suggest you ask marton about that.
(i suspect he might miss it in this ffplay unrelated thread ...)

[...]

--

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel <at> ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Michael Niedermayer | 31 May 01:01 2012
Picon
Picon

Re: FFV1.3

On Wed, May 30, 2012 at 10:29:04PM +0200, Peter B. wrote:
> On 05/23/2012 10:30 PM, Michael Niedermayer wrote:
> > If theres significant additional video that isnt played, it surely
> > makes sense to look at why it isnt
> > if ffplay behaves very different from how it does on the undamaged
> > file it might be interrestin too
> >
> I've checked it again, and it seems that "ffplay" in general does not
> stop playback at the end of *any* videofile I'm playing: The video just
> stops, but the counter in the commandline is running as if it'd still be
> playing...
> 
> However, I've found something interesting:
> When disabling Slice-CRCs, the resulting file may be corrupted afterwards:

fixed

thanks for the report

[...]
--

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
_______________________________________________
ffmpeg-devel mailing list
(Continue reading)

Peter B. | 4 Jun 01:28 2012

Re: FFV1.3

On 05/31/2012 01:01 AM, Michael Niedermayer wrote:
> fixed
>
> thanks for the report
>
Verified and it works properly now.
Thanks!

Pb
Peter B. | 23 May 20:37 2012

Re: FFV1.3

Oh, and is there a way to "analyze" the whole stream, for example with
"ffprobe", and get some kind of logfile about CRC checks, Aspect-ratio
and field-order information?

Just curious... :)

Thanks,
Pb
Michael Niedermayer | 23 May 22:31 2012
Picon
Picon

Re: FFV1.3

On Wed, May 23, 2012 at 08:37:00PM +0200, Peter B. wrote:
> Oh, and is there a way to "analyze" the whole stream, for example with
> "ffprobe", and get some kind of logfile about CRC checks, Aspect-ratio
> and field-order information?

not currently, but it could be implemented

[...]
--

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel <at> ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Dave Rice | 23 May 03:22 2012
Picon

Re: FFV1.3

Hi Michael,

On May 16, 2012, at 4:11 PM, Michael Niedermayer wrote:

> sOn Wed, May 16, 2012 at 09:01:46PM +0200, Peter B. wrote:
>> On 05/16/2012 08:43 PM, Michael Bradshaw wrote:
>>> On Wed, May 16, 2012 at 12:35 PM, Peter B. <pb <at> das-werkstatt.com> wrote:
>>>> Maybe a stupid question, but what is the right commandline call for
>>>> selecting the FFv1 version to use for encoding?
>>> ffmpeg -i input.mov -vcodec ffv1 -acodec copy output.mp4
>>> ?
>>> 
>>> Or do you mean something else?
>> Yes, I'd like to validate/test FFv1's new versions 2 and 3. When v2 had
>> been developed, I had to modify a variable in the source to enable it,
>> but I've seen a commit-msg by Michael [1], which sounded to me like
>> selecting the version was now possible as parameter?
>> 
>>> FYI, this mailing list is primarily for the development of ffmpeg
>>> itself. For help using ffmpeg, ffmpeg-user mailing list is probably
>>> better.
>>> 
>> I know, I'm sorry - I just thought that it might make sense to connect
>> it to the "FFv1.3" thread...
> 
> -level 3
> 
> and thanks for validating testing
> 
> if you need help have questions ask me ...
(Continue reading)

Michael Niedermayer | 23 May 12:24 2012
Picon
Picon

Re: FFV1.3

On Tue, May 22, 2012 at 09:22:14PM -0400, Dave Rice wrote:
> Hi Michael,
> 
> On May 16, 2012, at 4:11 PM, Michael Niedermayer wrote:
> 
> > sOn Wed, May 16, 2012 at 09:01:46PM +0200, Peter B. wrote:
> >> On 05/16/2012 08:43 PM, Michael Bradshaw wrote:
> >>> On Wed, May 16, 2012 at 12:35 PM, Peter B. <pb <at> das-werkstatt.com> wrote:
> >>>> Maybe a stupid question, but what is the right commandline call for
> >>>> selecting the FFv1 version to use for encoding?
> >>> ffmpeg -i input.mov -vcodec ffv1 -acodec copy output.mp4
> >>> ?
> >>> 
> >>> Or do you mean something else?
> >> Yes, I'd like to validate/test FFv1's new versions 2 and 3. When v2 had
> >> been developed, I had to modify a variable in the source to enable it,
> >> but I've seen a commit-msg by Michael [1], which sounded to me like
> >> selecting the version was now possible as parameter?
> >> 
> >>> FYI, this mailing list is primarily for the development of ffmpeg
> >>> itself. For help using ffmpeg, ffmpeg-user mailing list is probably
> >>> better.
> >>> 
> >> I know, I'm sorry - I just thought that it might make sense to connect
> >> it to the "FFv1.3" thread...
> > 
> > -level 3
> > 
> > and thanks for validating testing
> > 
(Continue reading)

Peter B. | 8 Aug 02:08 2012

Re: FFV1.3

On 04/20/2012 03:50 PM, Michael Niedermayer wrote:
> Ive just commited some changes to the ffv1 codec v1.3
Sorry it took so incredibly long.
Funny video-archivist's "everyday adventures" to master and
video-mysteries to solve! - that's what stole my time! :)

----------------------------------------------------------
Here's a quick summary of my FFv1.3 tests:
----------------------------------------------------------

1) YUV Colorspaces:
Script tries to create files in any colorspace supported by ffmpeg. The
logs then show which pix_fmts actually got encoded.

2) Losslessness:
A set of reference framemd5 files for each colorspace is generated once.
Afterwards, all video files created with different options for
ffv1-encoding are then framemd5-compared to those references: So far,
all match as they should!

3) Performance:
I haven't summarized the transcoding performance in numbers yet, because
I did my tests on an external USB drive, so the numbers aren't
representative, as I expect disk I/O to be a factor for the fps count.
The test-setup was to have different options for threads, slices and
colorspaces.

Here are some rough results from my machine:
(NOTE: All values apply to a VHS PAL yuv422p source and transcoding
running on an Intel Quadcore i7-2600K  <at>  3.40 GHz)
(Continue reading)

David Rice | 8 Aug 03:24 2012
Picon

Re: FFV1.3

On Aug 7, 2012, at 8:08 PM, Peter B. wrote:

> On 04/20/2012 03:50 PM, Michael Niedermayer wrote:
>> Ive just commited some changes to the ffv1 codec v1.3
> Sorry it took so incredibly long.
> Funny video-archivist's "everyday adventures" to master and
> video-mysteries to solve! - that's what stole my time! :)
> 
> 
> ----------------------------------------------------------
> Here's a quick summary of my FFv1.3 tests:
> ----------------------------------------------------------

I've run some tests as well and am including results and process inline where it aligns with yours.

> 1) YUV Colorspaces:
> Script tries to create files in any colorspace supported by ffmpeg. The
> logs then show which pix_fmts actually got encoded.
> 
> 2) Losslessness:
> A set of reference framemd5 files for each colorspace is generated once.
> Afterwards, all video files created with different options for
> ffv1-encoding are then framemd5-compared to those references: So far,
> all match as they should!

For your steps 1 and 2 I created a shell script to use ffmpeg to pull from /dev/random to produce 1 second
rawvideo files at different combinations of frame size and pixel format. Each random source file is then
decoded to produce an md5. Then the random source is encoded with ffv1 version 1 and 3 which are then each
used to produce a framemd5 output.
My shell script is here: https://gist.github.com/3291078.
(Continue reading)

Michael Niedermayer | 8 Aug 20:29 2012
Picon
Picon

Re: FFV1.3

On Tue, Aug 07, 2012 at 09:24:55PM -0400, David Rice wrote:
> On Aug 7, 2012, at 8:08 PM, Peter B. wrote:
> 
> > On 04/20/2012 03:50 PM, Michael Niedermayer wrote:
> >> Ive just commited some changes to the ffv1 codec v1.3
> > Sorry it took so incredibly long.
> > Funny video-archivist's "everyday adventures" to master and
> > video-mysteries to solve! - that's what stole my time! :)
> > 
> > 
> > ----------------------------------------------------------
> > Here's a quick summary of my FFv1.3 tests:
> > ----------------------------------------------------------
> 
> I've run some tests as well and am including results and process inline where it aligns with yours.
> 
> > 1) YUV Colorspaces:
> > Script tries to create files in any colorspace supported by ffmpeg. The
> > logs then show which pix_fmts actually got encoded.
> > 
> > 2) Losslessness:
> > A set of reference framemd5 files for each colorspace is generated once.
> > Afterwards, all video files created with different options for
> > ffv1-encoding are then framemd5-compared to those references: So far,
> > all match as they should!
> 
> For your steps 1 and 2 I created a shell script to use ffmpeg to pull from /dev/random to produce 1 second
rawvideo files at different combinations of frame size and pixel format. Each random source file is then
decoded to produce an md5. Then the random source is encoded with ffv1 version 1 and 3 which are then each
used to produce a framemd5 output.
(Continue reading)

Dave Rice | 8 Aug 20:40 2012
Picon

Re: FFV1.3


On Aug 8, 2012, at 2:29 PM, Michael Niedermayer wrote:

> On Tue, Aug 07, 2012 at 09:24:55PM -0400, David Rice wrote:
>> On Aug 7, 2012, at 8:08 PM, Peter B. wrote:
>> 
>>> On 04/20/2012 03:50 PM, Michael Niedermayer wrote:
>>>> Ive just commited some changes to the ffv1 codec v1.3
>>> Sorry it took so incredibly long.
>>> Funny video-archivist's "everyday adventures" to master and
>>> video-mysteries to solve! - that's what stole my time! :)
>>> 
>>> 
>>> ----------------------------------------------------------
>>> Here's a quick summary of my FFv1.3 tests:
>>> ----------------------------------------------------------
>> 
>> I've run some tests as well and am including results and process inline where it aligns with yours.
>> 
>>> 1) YUV Colorspaces:
>>> Script tries to create files in any colorspace supported by ffmpeg. The
>>> logs then show which pix_fmts actually got encoded.
>>> 
>>> 2) Losslessness:
>>> A set of reference framemd5 files for each colorspace is generated once.
>>> Afterwards, all video files created with different options for
>>> ffv1-encoding are then framemd5-compared to those references: So far,
>>> all match as they should!
>> 
>> For your steps 1 and 2 I created a shell script to use ffmpeg to pull from /dev/random to produce 1 second
(Continue reading)

Boštjan Strojan | 24 Aug 10:56 2012
Picon

Re: FFV1.3

Dave:

Could you add UT-video, huffyuv and x264 lossless to this test script?
(And whatever else lossless/usefull in ffmpeg)

Usage could be:

lossless_test.sh file.mov
or
lossless_test (without parameters it would use random noise)

Thanks,

Boštjan

On Wed, Aug 8, 2012 at 8:40 PM, Dave Rice <daverice <at> mac.com> wrote:
>
> On Aug 8, 2012, at 2:29 PM, Michael Niedermayer wrote:
>
>> On Tue, Aug 07, 2012 at 09:24:55PM -0400, David Rice wrote:
>>> On Aug 7, 2012, at 8:08 PM, Peter B. wrote:
>>>
>>>> On 04/20/2012 03:50 PM, Michael Niedermayer wrote:
>>>>> Ive just commited some changes to the ffv1 codec v1.3
>>>> Sorry it took so incredibly long.
>>>> Funny video-archivist's "everyday adventures" to master and
>>>> video-mysteries to solve! - that's what stole my time! :)
>>>>
>>>>
>>>> ----------------------------------------------------------
(Continue reading)

Peter B. | 30 Aug 07:03 2012

Re: FFV1.3

On 08/24/2012 10:56 AM, Boštjan Strojan wrote:
> Dave:
>
> Could you add UT-video, huffyuv and x264 lossless to this test script?
> (And whatever else lossless/usefull in ffmpeg)
>
> Usage could be:
>
> lossless_test.sh file.mov
> or
> lossless_test (without parameters it would use random noise)
>

This would actually go towards a lossless-codec comparison.

The FFv1 test script (at least mine, not 100% sure about Dave's) is
intended to make sure that FFv1 functions and behaves correctly and to
automatically check for possible regressions, etc.

Size and performance comparisons are a side-product of this test-suite.

Pb
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel <at> ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
David Rice | 6 Sep 01:44 2012
Picon

Re: FFV1.3


On Aug 30, 2012, at 1:03 AM, Peter B. wrote:

> On 08/24/2012 10:56 AM, Boštjan Strojan wrote:
>> Dave:
>> 
>> Could you add UT-video, huffyuv and x264 lossless to this test script?
>> (And whatever else lossless/usefull in ffmpeg)
>> 
>> Usage could be:
>> 
>> lossless_test.sh file.mov
>> or
>> lossless_test (without parameters it would use random noise)
>> 
> 
> This would actually go towards a lossless-codec comparison.
> 
> The FFv1 test script (at least mine, not 100% sure about Dave's) is
> intended to make sure that FFv1 functions and behaves correctly and to
> automatically check for possible regressions, etc.
> 
> Size and performance comparisons are a side-product of this test-suite.

Michael pointed out a flaw in my script where it produced invalid raw yuv422p9 and yuv422p10 files because I
was using data from /dev/random which isn't appropriate for these pixel formats. When producing
accurate test files of random data ffv1 version 3 worked (as your test also indicated).

Dave Rice
(Continue reading)


Gmane