Subject: [AVT] Marker bit in H.264 SVC Payload

From: Jonathan Lennox <[email-masked]>
Date: Mon, 06 Nov 2006 15:31:15 -0500

While implementing the RTP packetization of SVC (the H.264 Scalable Video
extention), an issue occurred to us.

Right now SVC packetization draft defers to RFC 3984 to define the marker
bit, and so the marker bit in the RTP packetization of SVC indicates the
last packet of a frame.  Should it be redefined instead to indicate the last
packet of a single layer of a frame?

While most video codecs do the former, it seems like it would be useful to
do the latter.  In particular, it would mean that the RFC 3984 (base H.264)
compatibile subset of the bitstream still has properly-set marker bits in
it.  It also allows marker bits to be set properly for the bitstream
emerging from a MANE that's dropping some of a stream's dependency layers,
without the MANE having to re-construct which packets should be marked.
(The latter could also be an issue for SRTP, since marker bits are
authenticated.)

Thoughts?

-- 
Jonathan Lennox -- Layered Media
[email-masked]

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

---

From: "Jaehwan Kim" <[email-masked]>
Date: Mon, 13 Nov 2006 13:10:28 +0900

Hi Jonathan,
Maybe you want this resolution. In IMTC, last year, we faced at the
similar question. In case of H.264, packetization has marker bit
concept, both 0 and 1 market bit can be used. After that, many 3GP
streaming phone players and servers start to ignore it. Old rules
occasionally seem not matched with new codecs in many places.

I feel we need to make a note somewhere if the question is reproducible
and if our understanding in IMTC is correct.

Cheers,
Jaehwan

-----Original Message-----
From: Jonathan Lennox [mailto:[email-masked]] 
Sent: Tuesday, November 07, 2006 5:31 AM
To: 'AVT WG'; 'Stephan Wenger'; [email-masked]; 'Thomas Schierl'
Subject: [AVT] Marker bit in H.264 SVC Payload

While implementing the RTP packetization of SVC (the H.264 Scalable
Video
extention), an issue occurred to us.

Right now SVC packetization draft defers to RFC 3984 to define the
marker
bit, and so the marker bit in the RTP packetization of SVC indicates the
last packet of a frame.  Should it be redefined instead to indicate the
last
packet of a single layer of a frame?

While most video codecs do the former, it seems like it would be useful
to
do the latter.  In particular, it would mean that the RFC 3984 (base
H.264)
compatibile subset of the bitstream still has properly-set marker bits
in
it.  It also allows marker bits to be set properly for the bitstream
emerging from a MANE that's dropping some of a stream's dependency
layers,
without the MANE having to re-construct which packets should be marked.
(The latter could also be an issue for SRTP, since marker bits are
authenticated.)

Thoughts?

---

From: "Anand Ammundi" <[email-masked]>
Date: Tue, 14 Nov 2006 11:18:15 -0800

Hi,
 I'm trying to get some information regarding Streaming using HTTP ( I
know!! it's
absurd!!). However, is this covered under any standards activity
(especially the control channel) or is this vendor specific, proprietary
etc for the moment? 
Any pointers (and or redirects) are appreciated
	Thanks
 	Anand

---

From: Ralph Giles <[email-masked]>
Date: Tue, 14 Nov 2006 11:49:25 -0800

> (especially the control channel) or is this vendor specific, proprietary

As far as I know it's not been standardized beyond the HTTP spec itself 
(which really ought to be sufficient :P)

But, as far as our icecast server software goes, for many streams HTTP 
streaming is just that, HTTP. There is an extension in use for mp3 
metadata transmission, where an id3-tag-like metadata block is 
interleaved with the mpeg stream at fixed intervals. This interval is 
given by a ice-* or icy-* headers, which can contain stream-level 
metadata as well.

Additionally, some shoutcast servers seem to replace the HTTP/<version> 
in the initial response like with ICY, so you need to be liberal about 
accepting this.

The "source client" protocol used to feed streams to server software 
like icecast and shoutcast for is more complicated. icecast uses a 
variant HTTP method called SOURCE (which I'm not sure has a good 
justification). Shoutcast uses two adjacent ports, one for control and 
one for data.

As far as I know there's no real documentation of any of this, but 
reading the source code of various open source implementations explains 
most active practice. For example:

http://downloads.xiph.org/releases/libshout/libshout-2.2.2.tar.gz
http://downloads.xiph.org/releases/icecast/icecast-2.3.1.tar.gz
http://xmms.org/files/1.2.x/xmms-1.2.10.tar.gz

Hope that helps,
 -r

---

From: "Anand Ammundi" <[email-masked]>
Date: Tue, 14 Nov 2006 12:51:36 -0800

Hi Ralph,
 Thanks for your response.
  I was wondering how a proxy-cache for HTTP streaming would need to
behave ? It appears that the stream control, not being part of the spec,
is being used in all sorts of ways in order to acheive an "RTSP like"
functionality...
	Anand

-----Original Message-----
From: Ralph Giles [mailto:[email-masked]] 
Sent: Tuesday, November 14, 2006 11:49 AM
To: Anand Ammundi
Cc: AVT WG
Subject: Re: [AVT] HTTP Streaming

> know!! it's absurd!!). However, is this covered under any standards 
> activity (especially the control channel) or is this vendor specific, 
> proprietary etc for the moment?

Hope that helps,
 -r

---

From: Ralph Giles <[email-masked]>
Date: Tue, 14 Nov 2006 14:53:43 -0800

> is being used in all sorts of ways in order to acheive an "RTSP like"

Can you be more specific about what streaming software you're talking 
about?

My experience with HTTP streaming is that the server takes a "live" 
audio stream and does what it can to make it look like a regular file 
retrieved over HTTP. Our Ogg container format (RFC 3533) was designed 
specifically with this in mind, so I may have a biased point of view.

Anyway, stream URLs provide dynamic content (effectively a different 
byte stream every time you request them, although there's higher-level 
order between requests) that is delivered a a fixed average bitrate.

So a proxy could do replication, but since it's takes days for most
streams to "complete" a transfer it would halve to be able to serve 
files to clients while they are still downloading. I've no idea how 
common that is in implementation. As far as caching, I would think
that's generally not what you want, since the information may be
live data. In any case, Icecast doesn't set any cache control headers.

Now, it's certainly possible to use an out-of-band channel to control 
the output of an http stream. Is that what you mean? It's more common
to do a new query with a modified URL (or Range request) I think.

 -r