[FFmpeg-devel] FFV1.3

[Peter B.]

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  
proper redundant archive copies.
That's another discussion. More about that below.


> However an option would give other users the
> choice, so how about the default being on with the option to disable it?

I also think that it should be optional.
If, in the near future, FFv1 can be used for realtime encoding of HD  
material, it's still an open question how much CPU headroom there will  
be.

Having the possibility to detect errors in the stream is great.
If FFv1 decoding should however silently correct these errors, this  
would mean that problems would be obfuscated.


>> 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
>>
>
> I think having this information in the stream, rather than the
> container, is preferable for all the reasons you outline.

@Tim (and others):
Could you provide example use cases where this in-stream information  
makes sense?

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).
So, if there is a mid-stream change of e.g. aspect ratio, who, when,  
and especially *how* should this information be provided to the encoder?

I still have to think about the use cases where this might make sense.

None the less: Thank you very much Michael!

Pb