From: Tim B. <tim...@rd...> - 2006-02-03 17:09:36
|
At 19:23 27/01/2006, Ralph Giles wrote: >In light of this, have you considered removing the End of Sequence >parse code as well? Having an end-of-data marker is nice for detecting >truncation, but a well-written reader should warn and continue if >it is missing. The idea is that the sequence parameters will remain constant during a sequence. This allows a decoder to build up confidence over a channel with errors and reject erroneous sequence parameters. This doesn't mean that all the frames could be replayed but it should stop gross errors in decoding and help prevent decoder crashes. We did toy with the idea of simply having two different type of Access Unit Header, a "New" Access unit Header (allowing the sequence parameters to change) and a "Repeat" Access Unit Header ( sequence parameters remain constant). If we did this then no end of sequence code would be necessary. However when I looked at this it didn't seem to lead to a very logical structure of the byte stream. So instead we still have and end of sequence code. Following this the decoder can, indeed, continue, in which case, since it is a new sequence, it can have new sequence parameters. The idea is that most of the sequence parameters (e.g. image size, active area, colour matrix, primaries etc) would remain constant in any rational sequence. In long broadcast sequences parameters like whether the sequence is intended to be displayed interlaced or progress, or the aspect ratio, might chnage. However in these cases it is probably sensible to start a new stream only. The only case I can think of where the parameters might, conceivably change relatively frequently, would be the case when a programme contains both film and interlaced sections. in practice this is uncommon. Also, in practice, the likely result is that the whole programme would be flagged as either interlaced or progressive - i.e. the display meta data is unlikely to change within a programme. So keeping all sequence parameters constant within a sequence seemed the most sensible thing to do. > > Since sending the proposal I realised that the list of fixup offsets > > as proposed would need to be sorted (whatever reads the byte stream > > has to know the first byte to invert). One could just mandate that > > the list of fixup offsets were sorted at the encoder. But rather than > > do this is seems better to specify the offsets differentially > > (reference for the first still being the start of the parse info). > >Making the offsets relative is a better solution. It makes it impossible >for the encoder to sort the fixup table incorrectly. This takes care of >the ordering issue I raised, you still need to specify what happens if >the fixup table tries to modify bytes within the Parse Info block. Good, we'll specify this. >Because of the padding mechanisms available it does not need to; should >it be allowed to? I don't think so. One option is just to move the >reference for the fixup_offsets to the end of the Parse Info. I agree > > One question I would appreciate comments on is whether, as suggested, > > there should be separate Parse Codes for info units that do and that > > do not include fixup tables. I'm inclining to the view that only one > > parse code is need for both and that allowing a fixup table length of > > zero would be sufficient. > >I don't have a strong feeling either way. Using a bit of the parse >code saves 3 bytes in the no-table case, and doesn't add much code >complexity. Cutting the length of the parse code table in half does >reduce conceptual complexity and gives you another reserved bit for >the future. > >How common are escape sequences in current dirac streams? If more than >a quarter would have a fixup table, I think dropping the flag would >clearly be better. Escape sequence are rare. I would expect most fixup table to include no more than a single entry. (There may be exception of untypical, pathological sequences). So I guess, maybe, it is worth keeping two different parse codes (for with and without fixup tables) to save bitrate for low resolutions. But I'm still undecided (I like the simplicity of always having a fixup table) and have had no other feedback on this. Best Tim P.S. Sorry for slow reply |