Re: Adaptation field

[Dr G Fairhurst <gorry@erg.abdn.ac.uk>]

Sorry, I missed your posting in my mail box.  Here's a belated reply.

"Surtees, Abigail" wrote:
> 
> Hi,
> 
> I've just started looking ip-over-dvb and have a question about part of 
> draft-clausen-ipdvb-enc-00.txt which I hope someone can answer.
> 
> On page 10 there is a table showing the meaning of the PUSI and AFC bits in 
> the TS packet header, followed by 2 paragraphs of explanation.  
> The second paragraph says:
> "
>         The TS Packet that carries the last byte of a SNDU MUST always have
>         an adaptation field. In case this was the last SNDU (0/11 PUSI/AFC)
>         the TS Packet is filled with stuffing bytes. In case another SNDU
>         starts in this TS Packet, another 4-byte adaptation field is
>         inserted before the next SNDU. "
> 
> I think this means that the adaptation field is used as stuffing bytes 
> when there are no more SNDUs, so there will be 184 - x bytes of stuffing 
> where x is the length of the last part of 
> the SNDU.  Is this correct?

Yes, the adaption field could also be used as a part of the framing, to tell
the receiver that an MPEG-2 TS Packet contains the start of a new SNDU. If
the receiver happens to loose synch this is how it resynchs. 

> 
> If there is another SNDU does 'another 4-byte adaptation field' mean the 
> one that is always carried or another one on top of that?  In other words, do you get
>   ________________ ____________ ______________
>   ... end of SNDU | adap field | next SNDU ...
>   ________________ ____________ ______________
> 
> or
>   ________________ ____________ ____________ _____________
>   ... end of SNDU | adap field | adap field | next SNDU...
>   ________________ ____________ ____________ _____________
> 
> ?
 
Well, neither really.  The adpoation field comes directly after the
MPEG-2 TS Packet 
header. So, Bernhard has drawn some diagrams in the latest version of
this draft,
to try and get things clearer.


> Thanks,
> 
> Abbie
> 
> Abbie Surtees
> Engineer
> Internet Applications and Mobility
> Roke Manor Research Ltd
> Tel:   +44 (0) 1794 833131
> 
> Permission is hereby granted to pass the contents of this communication to third 
> parties and any restrictions regarding confidentiality do not apply.
> 
>   ------------------------------------------------------------------------
>                           Name: RMRL-Disclaimer.txt
>    RMRL-Disclaimer.txt    Type: Plain Text (text/plain)
>                       Encoding: 7bit


The new rev of the draft will hopefully be clearer, but I'd still like
you to follow
up on your question and reply, if it applies also to the new rev of the
draft (-01).

Gorry