Subject: Re: [AVT] MPEG2 preamble - comparison of mechanisms

From: Peilin YANG <[email-masked]>
Date: Sat, 13 Mar 2010 11:08:25 +0800

Dear Art,

Thank you very much for being interested in two preamble drafts and giving comments.

As for the problem of PCR, unless Ali's draft calculates a new PCR to replace the original PCR(I haven't found such description in Ali's draft), otherwise, as Roni said in both cases the problem is the same because both of drafts get the PCR information from the lastest PCR TS packet near Random Access Point. 
In fact, normally PCR information is far earlier than the PTS information of Random Access Point(in most cases I found they are approximate 500ms), and PCR inverval is short(in most cases I found PCR inverval is approximate 40ms)). Please see two MPEG2-TS reports(http://www.w6rz.net/sbp.txt, http://www.w6rz.net/parkrun1920_18mbps.txt).The PCR information in the preamble is only a initial reference. When a Receiver begin to play the Random A
ccess Point, actually it uses subsequent PCR infromation.  Therefore, normally there is no synchronization question of audio and video. I can show some MPEG-TS streams when we discsuss in the IETF meeting. (I don't know if I clarify it clearly).

As for the problem of discontinuity as Sandy said, I also agree. It will casue the problem of demultiplexing if it isn't solved. Xia's draft descibes it in section 5.3.3. Discontinuity indicator information. Sandy, thank you very much for presenting the discontinuity issue. 

Best regards,

Peilin

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email
 immediately and delete it!
 *****************************************************************************************

Subject: Re: [AVT] MPEG2 preamble - comparison of mechanisms
From: "Sandy (Alexander) MacInnis" <[email-masked]>
To: "Allison, Art" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 12 Mar 2010 14:50:02 -0800
List-Id: Audio/Video Transport Working Group <avt.ietf.org>

Art has a very good point.

Also, consider the continuity counter, which might not be continuous when TS packets that used to be widely separated are placed contiguously in the stream sent to the TS parser in the receiver.

Explicitly signaling a discontinuity between the preamble and the start of the normal TS packets might be worth considering.

--Sandy MacInnis
Broadcom Corporation

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Allison, Art
Sent: Friday, March 12, 2010 1:06 PM
To: [email-masked]
Subject: Re: [AVT] MPEG2 preamble - comparison of mechanisms

I agree a careful, perfect reader should not have a problem. 
Implementation complexity and variability seems to me to be a valid
criteria for comparison - especially when alternatives are so close.   I
saw only a tiny corner. 

Consider the exposure to the PCR processor (which according to good
layering should not have to know a packet came from a different
structure). This processor subroutine gets handed the values from that
field after the packets are no longer in their special wrapper.

I read that that it might not be clear that the parser subroutine might
need to be adjusted somewhat, as this field is not incrementing
'normally' in this case.
Setting the PCR discontinuity may be worth considering to explicitly
signal this state - and that triggers a already defined behavior.  The
receiver implementation could use the fact that it arrived in the
preamble and set that so that no change was needed in the PCR
subroutine. Or maybe just flywheel through and accept a glitch while
catching up as a small cost to enable getting started sooner.

Perhaps someone else will find a more substantive difference  -- but a
humm loudness meter might be needed. 

Art Allison

Senior Director Advanced Engineering, Science and Technology

National Association of Broadcasters
1771 N Street NW
Washington, DC 20036
Phone  202 429 5418 
Fax  202 775 4981

www.nab.org

Advocacy  Education  Innovation

|-----Original Message-----
|From: Roni Even [mailto:[email-masked]] 
|Sent: Friday, March 12, 2010 2:53 PM
|To: Allison, Art; [email-masked]
|Subject: RE: [AVT] MPEG2 preamble - comparison of mechanisms
|
|Hi Art,
|I think that in both cases the problem is the same. What you 
|are saying is the it is identified easier in begen draft since 
|it is a special construct, this is true also in the xia draft 
|since it is obvious from the announcement that the rfc 2250 
|stream is a preamble stream. In both cases it is a specific 
|reciver implementation enhancement if required
|BTW: I am not sure what is the use case when you have  two 
|separate MPEG2-TS streams using different RTP sessions 
|carrying the audio and video separately. I would assume that a 
|program will carry both multiplexed. Also I assume that if 
|audio and video are separated you will need the RTP time stamp 
|to synchronize between them.
|
|Roni Even
|As individual
|
|> -----Original Message-----
|> From: [email-masked] [mailto:[email-masked]] On 
|Behalf Of 
|> Allison, Art
|> Sent: Friday, March 12, 2010 9:12 PM
|> To: [email-masked]
|> Subject: Re: [AVT] MPEG2 preamble - comparison of mechanisms
|> 
|> In response to is there any other difference?
|> 
|> Perhaps for a corner case:
|> 
|> If an implementation were to attempt synchronization of audio and 
|> video by using the PCR in the MPEG-2 TS packets (as 
|contrasted with an 
|> implementation relying completely on the RTP/RTCP time stamps); then 
|> perhaps the Xia method may have a tiny bit larger risk of being 
|> misimplemented.
|> 
|> MPEG-2 TS implementations have been known to establish an internal 
|> clock from the first PCR received and adjust that timing reference 
|> upon receipt of later PCRs when the value is not quite that 
|expected. 
|> The time between preamble PCR and the first 'real' PCR may present a 
|> larger than expected delta, and the adjustment process to 
|get back in 
|> step is undefined (as I was not able to find that signaling a 
|> discontinuity in PCR was required.)
|> 
|> While MPEG-2 TS implementation variants of either method may need to 
|> take account of differences between the pre-amble PCR and the steady 
|> incrementing PCR once decoding gets underway; it may less apparent 
|> that special handling of the PCR is needed when it is in 
|what appears 
|> to be a well understood packet (but is actually slightly 
|different due 
|> to its being provided 'early' for the special purpose here).
|> 
|> This need is somewhat more obvious with a special construct.
|> 
|> 
|> Art Allison
|> 
|> Senior Director Advanced Engineering, Science and Technology
|> 
|> 
|> 
|> National Association of Broadcasters
|> 1771 N Street NW
|> Washington, DC 20036
|> Phone  202 429 5418
|> Fax  202 775 4981
|> 
|> www.nab.org
|> 
|> Advocacy  Education  Innovation
|> 
|> 
|> 
|> |-----Original Message-----
|> |From: [email-masked] [mailto:[email-masked]] On 
|Behalf Of 
|> |DRAGE, Keith (Keith)
|> |Sent: Friday, March 12, 2010 11:44 AM
|> |To: [email-masked]
|> |Subject: [AVT] MPEG2 preamble - comparison of mechanisms
|> |
|> |(As WG co-chair)
|> |
|> |More actions on the MPEG2 preamble:
|> |
|> |The two drafts are:
|> |
|> |http://tools.ietf.org/id/draft-begen-avt-rtp-mpeg2ts-preamble-04.txt
|> |http://tools.ietf.org/id/draft-xia-avt-mpeg2ts-preamble-02.txt
|> |
|> |At the last meeting, there was an ad-hoc which reported that:
|> |
|> |
|> |"The idea expressed in the Begen draft is to extract the 
|data needed 
|> |for the preamble from the media stream, cache it on the server, and 
|> |send it to the receiver on request in the form of one (or 
|> |occasionally a small number of) RTP packets using a new RTP payload 
|> |format. That RTP payload format is organised as a set of 
|TLV-encoded 
|> |blocks, where each block represents a particular piece of preamble 
|> |data, extracted from the MPEG2-TS. The use of TLV-encoded blocks 
|> |provides extensibility.
|> |
|> |The idea expressed in the Xia draft is to extract the 
|MPEG2-TS frames 
|> |needed for the preamble from the media stream, cache them on the 
|> |server, and send them to the receiver on request in the form of 
|> |MPEG2-TS frames encapsulated in an RTP packet representing an RFC 
|> |4588 retransmission of a synthetic RFC 2250 RTP packet 
|encapsulating 
|> |those MPEG2-TS frames (note that only the frames required for the 
|> |preamble are sent, not the complete RTP packets that contain them).
|> |
|> |After much discussion, it was understood that both proposals send 
|> |essentially the same data as the preamble. The key 
|difference between 
|> |them is the way in which that data is
|> |encapsulated: the Began draft extracts the preamble data from the 
|> |MPEG2-TS and wraps it into a TLV-encoded form for transmission; the 
|> |Xia draft extracts the preamble data from the MPEG2-TS and sends it 
|> |as a sequence of new MPEG2-TS frames wrapped in an RTP 
|retransmission 
|> |packet.
|> |
|> |We discussed compatibility of the two approaches with the RTP 
|> |standards. The Began draft is clearly compatible. The Xia draft is 
|> |not compatible as it stands, since the preamble is sent as an RTP 
|> |retransmission packet but contains a synthetic packet that is not a 
|> |retransmission. This issue with the Xia draft can be solved by 
|> |formatting the preamble packets as RFC 2250 packets, rather 
|than the 
|> |current approach that uses an RFC 4588 retransmission of an 
|RFC 2250 
|> |packet.
|> |
|> |We discussed overheads, in terms of the number of packets sent, and 
|> |vulnerability to packet loss. The two drafts generally send 
|the same 
|> |information in the same number of RTP packets in the 
|preamble, and so 
|> |have essentially the same overhead and resilience to loss. 
|> |Acquisition delays are also the same, since both send the same 
|> |information.
|> |
|> |The Began draft includes TLV headers which may provide extra 
|> |flexibility, but will slightly increase the packet size compared to 
|> |the Xia draft which sends raw MPEG2-TS frames.
|> |
|> |The meeting concluded with an understanding that the two proposals 
|> |have essentially identical overheads and behaviour.
|> |The key difference between then, assuming the Xia proposal 
|is updated 
|> |to use RFC 2250 packets rather than RFC 4588 retransmissions of RFC 
|> |2250 packets to conform to the RTP specifications, is that 
|the Begen 
|> |draft includes additional TLV-headers to provide additional 
|> |flexibility and extensibility, at the expense of a slightly larger 
|> |packet. "
|> |
|> |
|> |So this report essentially says the two drafts are 
|equivalent, and it 
|> |comes down to a matter of preferences (i.e. does one prefer 
|the blue 
|> |one to the red one).
|> |
|> |ACTION TO WG MEMBERS
|> |---------------------
|> |
|> |Is there anything the WG members wish to add to this 
|comparison that 
|> |may influence the decision?
|> |
|> |Please respond to the list (and ideally to this thread) in 
|advance of 
|> |the face to face meeting, as again due to limited (and valuable) 
|> |meeting time; we will not have time in Anaheim for people 
|to present 
|> |these ideas afresh at the microphone.
|> |
|> |regards
|> |
|> |Keith
|> |
|> |
|> |_______________________________________________
|> |Audio/Video Transport Working Group
|> [email-masked]
|> |https://www.ietf.org/mailman/listinfo/avt
|> |
|> _______________________________________________
|> Audio/Video Transport Working Group
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/avt
|
|
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Eric Friedrich <[email-masked]>
Date: Sun, 14 Mar 2010 19:37:03 -0400

Hi Peilin-
   Ali's draft sends the PCR corresponding to the beginning of the  
unicast burst in the PCR TOLV element. This element is then sent  
through a post-processing module on the client. The post-processing is  
able to adjust the given PCR value to more closely match the actual  
PCR value at that point in the stream. For example, if the unicast  
burst starts at PCR_0, the client can adjust the first PCR sample  
given to the decoder to be some PCR_1. PCR_1 < PCR_0 by the amount  
that PCR_1 is earlier in the stream than PCR_0. This depends on a) the  
rate of the stream and b) the number of packets between PCR_1 and PCR_0.

In the draft, we do not explicitly describe the post-processing  
mechanism used to fixup the continuity counters and discontinuity  
indicator as these are implementation specific. However, in our  
reference implementation, we ensure that the continuity_counter value  
of all PIDs in the preamble is contiguous with that of the unicast  
burst (Section 5.2.4) Similarly, the first packet of the preamble sent  
into the decoder is marked with the discontinuty_indicator on the  
PCR_PID. As described in the MPEG2-TS spec, this indicates a jump in  
PCR values.

The two actions I described above are enabled by the TOLV signaling of  
Ali's draft and the flexibility given by the post processing.

Thanks,
Eric

On Mar 12, 2010, at 10:08 PM, Peilin YANG wrote:

> As for the problem of PCR, unless Ali's draft calculates a new PCR  
> to replace the original PCR(I haven't found such description in  
> Ali's draft), otherwise, as Roni said in both cases the problem is  
> the same because both of drafts get the PCR information from the  
> lastest PCR TS packet near Random Access Point.
> In fact, normally PCR information is far earlier than the PTS  
> information of Random Access Point(in most cases I found they are  
> approximate 500ms), and PCR inverval is short(in most cases I found  
> PCR inverval is approximate 40ms)). Please see two MPEG2-TS reports(http://www.w6rz.net/sbp.txt 
> , http://www.w6rz.net/parkrun1920_18mbps.txt).The PCR information in  
> the preamble is only a initial reference. When a Receiver begin to  
> play the Random A
> ccess Point, actually it uses subsequent PCR infromation.   
> Therefore, normally there is no synchronization question of audio  
> and video. I can show some MPEG-TS streams when we discsuss in the  
> IETF meeting. (I don't know if I clarify it clearly).
>
> As for the problem of discontinuity as Sandy said, I also agree. It  
> will casue the problem of demultiplexing if it isn't solved. Xia's  
> draft descibes it in section 5.3.3. Discontinuity indicator  
> information. Sandy, thank you very much for presenting the  
> discontinuity issue.
>
> Best regards,
>
> Peilin
>
> This email and its attachments contain confidential information from  
> HUAWEI, which is intended only for the person or entity whose  
> address is listed above. Any use of the information contained here  
> in any way (including, but not limited to, total or partial  
> disclosure, reproduction, or dissemination) by persons other than  
> the intended recipient(s) is prohibited. If you receive this email  
> in error, please notify the sender by phone or email
> Date: March 12, 2010 5:50:02 PM EST
> Also, consider the continuity counter, which might not be continuous  
> when TS packets that used to be widely separated are placed  
> contiguously in the stream sent to the TS parser in the receiver.
>
> Explicitly signaling a discontinuity between the preamble and the  
> start of the normal TS packets might be worth considering.
>
> --Sandy MacInnis
> Broadcom Corporation
>
> Also, consider the continuity counter, which might not be continuous  
> when TS packets that used to be widely separated are placed  
> contiguously in the stream sent to the TS parser in the receiver.
>
> Explicitly signaling a discontinuity between the preamble and the  
> start of the normal TS packets might be worth considering.
>
> --Sandy MacInnis
> Broadcom Corporation
>