Subject: [AVT] MPEG2 TS preamle: another angle

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Tue, 23 Mar 2010 18:05:13 +0100

Hi,
 
The last emails clarified the two proposed MPEG2 TS preamble solutions.
I see no real difference between the two solutions, in a sense that I
believe both mechanisms require dedicated post processing at the
receiver side (which was initially contested by the Xiang draft
proponents, using a RFC 2250 approach), but the begen draft proponents
believe their mechanism (TOLV elements) is more easy to implement.
 
One item that I think was not touched upon is how these two mechanisms
compare in the absence of RAMS, but still expecting the RTP receivers to
do some pre-processing, because as explained several times jamming MPEG2
TS premable (i.e.. ordering all relevant MPEG2 TS info, other than the
PES with RAP info,  back-to-back and insert this periodically, for
instance aligned with the RAP data ) to (existing) receivers will not
always work.
 
The 1st assumption I make here is that providing condensed MPEG2 TS data
to an RTP receiver without a RAMS client but with a post processing
stage, results in less delay compared to  just absorbing an MPEG2 TS
stream where no specific attention was made on how the preamble info is
put inside the stream (but still conformant with RFC 2250)
 
If this assumption holds, then would it not make sense to have a single
post processing code in a client that work both in a RAMS and a non-RAMS
environment? With non-RAMS, no retransmission server would be involved
and hence for SSM the Head-end (or Distribution Source)  can arrange the
TS packets  with sequences of MPEG2 TS preamble info that possibly are
only of benefit to clients that have the (post processing) means to
handle these. In this use case I think  it makes sense to stick to the
MPEG2 TS packet format, and by extension, use the same packaging also in
a RAMS environment.  
 
If a DS is generating the MPEG2 TS as described above, it even requires
the retransmission server to get less involved for the sake of
delivering MPEG2 TS preamble, or not involved at all, as all packets
(RAP and MPEG TS preamble)  can be sent/forwarded efficiently as
retransmission packets. This even results in the largest scalable
solution, and honors the very valid statement made before on this list
by Bill:  
 
As a general rule for processing Audio/Video flows, best practices
dictate that stream-specific functions occur "upstream" and device
specific functions occur "downstream". There are very good reasons for
this, some of which are discussed in the previous emails. Let's discuss
it in detail and come up with the right answer.
 
Tom

---

From: [email-masked]
Date: Wed, 24 Mar 2010 10:26:02 +0100

Hello,

Decoders have all the information to work in the TS stream, and
additional information is usefull only for intermediate functions. My fundamental
question is about "what MPEG2 preamble can bring to services?", and I
guess that services may be other than RAMS.

Is there something that describe what functions could benefit from TS
preamble? This could be a response on how to format this preamble.

Regards,

Gérard BABONNEAU

VAN CAENEGEM Tom a écrit :

Hi,

The
last emails clarified the two proposed MPEG2 TS preamble solutions. I
see no real difference between the two solutions, in a sense that I
believe both mechanisms require dedicated post processing at the
receiver side (which was initially contested by the Xiang draft
proponents, using a RFC 2250 approach), but the begen draft proponents
believe their mechanism (TOLV elements) is more easy to implement.

One
item that I think was not touched upon is how these two mechanisms
compare in the absence of RAMS, but still expecting the RTP receivers
to do some pre-processing, because as explained several times jamming
MPEG2 TS premable (i.e.. ordering all relevant MPEG2 TS info, other
than the PES with RAP info,  back-to-back and insert this periodically,
for instance aligned with the RAP data ) to (existing) receivers will
not always work.

The
1st assumption I make here is that providing condensed MPEG2 TS data to
an RTP receiver without a RAMS client but with a post processing stage,
results in less delay compared to  just absorbing an MPEG2 TS stream
where no specific attention was made on how the preamble info is put
inside the stream (but still conformant with RFC 2250)

If this
assumption holds, then would it not make sense to have a single post
processing code in a client that work both in a RAMS and a non-RAMS
environment? With non-RAMS, no retransmission server would be involved
and hence for SSM the Head-end (or Distribution Source)  can arrange
the TS packets  with sequences of MPEG2 TS preamble info that possibly
are only of benefit to clients that have the (post processing) means to
handle these. In this use case I think  it makes sense to stick to the
MPEG2 TS packet format, and by extension, use the same packaging also
in a RAMS environment.

If
a DS is generating the MPEG2 TS as described above, it even requires

As a general rule for processing Audio/Video
flows, best practices dictate that stream-specific functions occur
"upstream" and device specific functions occur "downstream". There are
very good reasons for this, some of which are discussed in the previous
emails. Let's discuss it in detail and come up with the right answer.

Tom

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

--

BABONNEAU Gerard RD-MAPS-REN

REN/MAPS/DPC

Tel : +33 299124008

Email:
[email-masked]

R&D Rennes 4, rue du Clos-Courtel - BP 91226 - 35512 Cesson-Sevigne
Cedex - France

---

From: Frank Xia <[email-masked]>
Date: Wed, 24 Mar 2010 11:54:04 -0500

Dear Gérard,

Thank you very much for concerning the preamble drafts.

I take an example for your question based on the following video frame
sequence

|........GoP1........|..........GoP2..........|....GoP3......

IBBP.................IBBP.....................|I....

             ^               ^       ^

             |               |       |

           PAT PMT          PAT PMT  |

                                     |

                                    RAMS-R If you request RAMS-R at the one
of parts of GoP2, RS will transmit unicast burst from I-frame of GoP2. If
there is no preamble information(e.g. PAT PMT) in GoP1, a Receiver cannot
demultiplex and decode correctly so that the Receiver only plays the video
until I-frame of GoP3.

if RS transmit the preamble information before I-frame of GoP2, the Receiver
plays the video until I-frame of GoP2. I don't know if I describe it
clearly.

I have a tool to show this if you like it. but i don't know where you are.

Frank & Peilin 

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, March 24, 2010 4:26 AM
To: VAN CAENEGEM Tom
Cc: MARJOU Xavier RD-CORE-LAN; [email-masked]
Subject: Re: [AVT] MPEG2 TS preamle: another angle

Hello,

Decoders have all the information to work in the TS stream, and additional
information is usefull only for intermediate functions. My fundamental
question is about "what MPEG2 preamble can bring to services?", and I guess
that services may be other than RAMS.

Regards,

Gérard BABONNEAU

Hi,

The last emails clarified the two proposed MPEG2 TS preamble solutions. I
see no real difference between the two solutions, in a sense that I believe
both mechanisms require dedicated post processing at the receiver side
(which was initially contested by the Xiang draft proponents, using a RFC
2250 approach), but the begen draft proponents believe their mechanism (TOLV
elements) is more easy to implement.

One item that I think was not touched upon is how these two mechanisms
compare in the absence of RAMS, but still expecting the RTP receivers to do
some pre-processing, because as explained several times jamming MPEG2 TS
premable (i.e.. ordering all relevant MPEG2 TS info, other than the PES with
RAP info,  back-to-back and insert this periodically, for instance aligned
with the RAP data ) to (existing) receivers will not always work.

The 1st assumption I make here is that providing condensed MPEG2 TS data to
an RTP receiver without a RAMS client but with a post processing stage,
results in less delay compared to  just absorbing an MPEG2 TS stream where
no specific attention was made on how the preamble info is put inside the
stream (but still conformant with RFC 2250)

If this assumption holds, then would it not make sense to have a single post
processing code in a client that work both in a RAMS and a non-RAMS
environment? With non-RAMS, no retransmission server would be involved and
hence for SSM the Head-end (or Distribution Source)  can arrange the TS
packets  with sequences of MPEG2 TS preamble info that possibly are only of
benefit to clients that have the (post processing) means to handle these. In
this use case I think  it makes sense to stick to the MPEG2 TS packet
format, and by extension, use the same packaging also in a RAMS environment.

If a DS is generating the MPEG2 TS as described above, it even requires the
retransmission server to get less involved for the sake of delivering MPEG2
TS preamble, or not involved at all, as all packets (RAP and MPEG TS
preamble)  can be sent/forwarded efficiently as retransmission packets. This
even results in the largest scalable solution, and honors the very valid
statement made before on this list by Bill:  

As a general rule for processing Audio/Video flows, best practices dictate
that stream-specific functions occur "upstream" and device specific
functions occur "downstream". There are very good reasons for this, some of
which are discussed in the previous emails. Let's discuss it in detail and
come up with the right answer.

Tom

  _____  

 

-- 

BABONNEAU Gerard RD-MAPS-REN
REN/MAPS/DPC
Tel : +33 299124008 
Email: <mailto:[email-masked]>
[email-masked]
R&D Rennes 4, rue du Clos-Courtel - BP 91226 - 35512 Cesson-Sevigne Cedex -
France 

 <http://web2000.rd.francetelecom.fr>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 24 Mar 2010 10:59:51 -0700

Hi Tom,

> The last emails clarified the two proposed MPEG2 TS preamble
solutions. I see no real difference
> between the two solutions, in a sense that I believe both mechanisms
require dedicated post processing
> at the receiver side (which was initially contested by the Xiang draft
proponents, using a RFC 2250
> approach), but the begen draft proponents believe their mechanism
(TOLV elements) is more easy to
> implement.
compare in the absence of RAMS,
> but still expecting the RTP receivers to do some pre-processing,
because as explained several times
> jamming MPEG2 TS premable (i.e.. ordering all relevant MPEG2 TS info,
other than the PES with RAP
> info,  back-to-back and insert this periodically, for instance aligned
with the RAP data ) to
> (existing) receivers will not always work.

RAMS is the main motivation for both drafts as stated in the abstracts.
If the sources managed to have a preamble-like data in the SSM stream in
the first place, we would not need to discuss this problem.
 
> The 1st assumption I make here is that providing condensed MPEG2 TS
data to an RTP receiver without a
> RAMS client but with a post processing stage, results in less delay
compared to  just absorbing an
> MPEG2 TS stream where no specific attention was made on how the
preamble info is put inside the stream
> (but still conformant with RFC 2250)

Correct.
 
> If this assumption holds, then would it not make sense to have a
single post processing code in a
> client that work both in a RAMS and a non-RAMS environment? With
non-RAMS, no retransmission server
> would be involved and hence for SSM the Head-end (or Distribution
Source)  can arrange the TS packets
> with sequences of MPEG2 TS preamble info that possibly are only of
benefit to clients that have the
> (post processing) means to handle these. In this use case I think  it
makes sense to stick to the
in a RAMS environment.

Right, but as I mentioned RAMS is the main scenario.

If the SSM sources (encoders, or whatever) could arrange the TS packets
more handsomely, our job would be easier. But, they cannot make every
client happy and this will still require post-processing on the client
side as you suggested. But, now the post processing would require TS
parsing logic, which is more complicated than simple TLV parsing.
Remember that RAMS clients already do have TLV parsing logic for the
mandatory RAMS control messages.

-acbegen
 
> If a DS is generating the MPEG2 TS as described above, it even
requires the retransmission server to
> get less involved for the sake of delivering MPEG2 TS preamble, or not
involved at all, as all packets
> (RAP and MPEG TS preamble)  can be sent/forwarded efficiently as
retransmission packets. This even
> results in the largest scalable solution, and honors the very valid
statement made before on this list
> As a general rule for processing Audio/Video flows, best practices
dictate that stream-specific
> functions occur "upstream" and device specific functions occur
"downstream". There are very good
> reasons for this, some of which are discussed in the previous emails.
Let's discuss it in detail and

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Wed, 24 Mar 2010 13:01:03 -0500

Gerard-

In order to decrypt/decode the video data, the end device must first process the meta-data for that flow. The meta-data includes the information about which PIDs are in use, which encryption is in use, etc. A certain amount of data prior to the Group Of Pictures is required.  If the burst is sent in its natural order (just faster), a certain amount of data prior to the I-frame is required. If we extract the crucial information and send just that ( in the pre-amble ), we get a more efficient use of the network resources.

I hope this brief summary helps.

Bill VerSteeg

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, March 24, 2010 2:26 AM
To: VAN CAENEGEM Tom
Cc: MARJOU Xavier RD-CORE-LAN; [email-masked]
Subject: Re: [AVT] MPEG2 TS preamle: another angle

Hello,

Decoders have all the information to work in the TS stream, and additional information is usefull only for intermediate functions. My fundamental question is about "what MPEG2 preamble can bring to services?", and I guess that services may be other than RAMS.

Is there something that describe what functions could benefit from TS preamble? This could be a response on how to format this preamble.

Regards,

Gérard BABONNEAU

Hi,

The last emails clarified the two proposed MPEG2 TS preamble solutions. I see no real difference between the two solutions, in a sense that I believe both mechanisms require dedicated post processing at the receiver side (which was initially contested by the Xiang draft proponents, using a RFC 2250 approach), but the begen draft proponents believe their mechanism (TOLV elements) is more easy to implement.

One item that I think was not touched upon is how these two mechanisms compare in the absence of RAMS, but still expecting the RTP receivers to do some pre-processing, because as explained several times jamming MPEG2 TS premable (i.e.. ordering all relevant MPEG2 TS info, other than the PES with RAP info,  back-to-back and insert this periodically, for instance aligned with the RAP data ) to (existing) receivers will not always work.

The 1st assumption I make here is that providing condensed MPEG2 TS data to an RTP receiver without a RAMS client but with a post processing stage, results in less delay compared to  just absorbing an MPEG2 TS stream where no specific attention was made on how the preamble info is put inside the stream (but still conformant with RFC 2250)

If this assumption holds, then would it not make sense to have a single post processing code in a client that work both in a RAMS and a non-RAMS environment? With non-RAMS, no retransmission server would be involved and hence for SSM the Head-end (or Distribution Source)  can arrange the TS packets  with sequences of MPEG2 TS preamble info that possibly are only of benefit to clients that have the (post processing) means to handle these. In this use case I think  it makes sense to stick to the MPEG2 TS packet format, and by extension, use the same packaging also in a RAMS environment.  

If a DS is generating the MPEG2 TS as described above, it even requires the retransmission server to get less involved for the sake of delivering MPEG2 TS preamble, or not involved at all, as all packets (RAP and MPEG TS preamble)  can be sent/forwarded efficiently as retransmission packets. This even results in the largest scalable solution, and honors the very valid statement made before on this list by Bill:  

As a general rule for processing Audio/Video flows, best practices dictate that stream-specific functions occur "upstream" and device specific functions occur "downstream". There are very good reasons for this, some of which are discussed in the previous emails. Let's discuss it in detail and come up with the right answer.

Tom

________________________________

 

-- 
 
BABONNEAU Gerard RD-MAPS-REN
REN/MAPS/DPC
Tel : +33 299124008 
Email: [email-masked] <mailto:[email-masked]> 
R&D Rennes 4, rue du Clos-Courtel - BP 91226 - 35512 Cesson-Sevigne Cedex - France