[FFmpeg-devel] FFV1.3

[Dave Rice]

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

This reminds me a bit of the DIF Block status values in a DV stream. When the deck fails to properly read a DIF block from tape (mismatch to the parity data on the tape), then the deck will conceal the misread data by copying data from a neighboring frame (among other tactics), but the deck also notes the concealment in the corresponding DIF block when it pipes out a DV stream. Thus the error (and resulting concealment) can be detected.

>>> 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?

One example is that some containers cannot contain this type for data. For instance the AVI container doesn't clearly specify how to store display aspect ratio, so the codec can do this, for instance like with DV in AVI.

Another example is jpeg2000 which is not self-descriptive enough to declare it's own colorspace and relies on the container to do this (for instance with a 'colr' chunk. In the case of jpeg2000 in MXF, the MXF doesn't have a colr chunk, so a new specification was written to specify how to store jpeg2000 technical information in an MXF container (SMPTE 422M). Because of this it's possible to have a application that supports MXF and supports jpeg2000 (like ffmpeg) but that doesn't support jpeg2000 in MXF in the case that it doesn't support S422M.

> 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
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel