Re: [Cellar] FFV1 Version 4

[Michael Niedermayer <[e-mail]>]

On Tue, Jan 05, 2016 at 05:55:55PM +0100, Jerome Martinez wrote:
> Le 05/01/2016 17:34, Michael Niedermayer a écrit :
> >On Tue, Jan 05, 2016 at 11:08:16AM -0500, Dave Rice wrote:
> >[...]
> >
> >>Some Header Adjustments
> >>- currently some values such as bit depth, display aspect ratio, and chroma subsampling are set per slice rather than per frame. Perhaps there is a reason I am not considering, but possibly some adjustment could improve the logic of the frame and slice headers.
> >the reason behind these being in slices is that slices should be
> >independantly decodable
> >If these would be in a single frame header and that frame header
> >is lost then none of the slices would be decodable (unless the
> >information is not needed to decode them)
> 
> We have problem about resilience in:
> - the ConfigurationRecord(). Very important, and not duplicated. So

the global header / extradata / ConfigurationRecord can and should
be duplicated at the container level.
repeating it at the codec level would make finding a duplicate element
relativly hard as one probably would have to scan the whole file.
A container could contain something like an index to point to
redundant copies, while at codec level this would not work so easily


> if we want resilience, we should first focus in it.
> - if the slice_size of the last slice is corrupted, we lose all
> slices (ok, we could decode each slice, let say slice_sizeof last
> slice and first byte of first slice). So there is not a so good
> resilience anyway.

its not hard to scan for slices with valid CRCs without knowing their
start/end. for each assumed end the size is just stored in 3 bytes
there which gives the start, and the crc is there easy to check
(Checking all these potential slice crcs can be done efficiently if
 iam not missing something)


> So I am not sure it helps so much to have display aspect ratio, and
> picture_structure in a slice header, without more work on resilience
> (slice synchro? something else?).

> If keep them per slice, maybe we
> should say in spec that all slices must have the exact same display
> aspect ratio and picture_structure per frame

agree (per frame all must match)


> (does the decoder
> support different picture_structures in a frame?)

different picture_structures in 1 frame dont make sense or do i
misunderstand ?


> 
> Additionally, picture_structure, sar_num, sar_dem (and other?) do
> not use to change (or they change as often as  chroma_planes,
> h_chroma_subsample, alpha_plane...), so we may consider to put them
> in the ConfigurationRecord() too (and we may need to take care of
> duplicating it in the container?)

they could optionally be put in the global ConfigurationRecord
but it should stay possible for them to change if thats what the
source video we encode is doing

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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato