Re: [httpstreaming] httpstreaming Digest, Vol 3, Issue 1

[Hasnaa Moustafa <[e-mail]>]

Would you please precise which room exactly?


>
>>  ---------- Forwarded message ----------
>> From: Qin Wu <[e-mail]>
>> To: [e-mail]
>> Date: Mon, 01 Nov 2010 09:02:52 +0800
>> Subject: [httpstreaming] Time and location for HTTP streaming bar BoF
>> Hi, experts:
>> We have got one IESG room for our Bar BOF with the AD's kind help. Thank
>> Alex for arranging this for us.
>> As we voted before through Doodle, the Bar BoF is scheduled on
>> Wednesday(10th,Nov) evening
>> from 19:30PM to 21:00PM.
>> If you are interested in this work or would like to contribute, please
>> join our discussion.
>> If you have any other suggestions, please let us know.
>>
>> Regards!
>> -Qin
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Qin Wu <[e-mail]>
>> To: [e-mail]
>> Date: Mon, 01 Nov 2010 11:19:58 +0800
>> Subject: [httpstreaming] Meeting Agenda preparation for Bar BOF of HTTP
>> Streaming
>>  Hi, Folks:
>> This is just a quick note to let you know that preparations are proceeding
>> for
>> HTTP Streaming Bar BOF meeting.
>> Based on what we have on the table and some suggestions from experts on
>> this list, we think at least three topics should be covered in the meeting
>> agenda:
>> a. Goal and Scope Discussion
>> b. Use Case discussion
>> c. Gap Analysis
>> if you have any questions or comments, please feel free to ping the list.
>> We will soon create meeting agenda based on your feedbacks.
>>
>> Regards!
>> -Qin
>>
>>
>> ---------- Forwarded message ----------
>> From: Qin Wu <[e-mail]>
>> To: Mark Watson <[e-mail]>
>> Date: Mon, 01 Nov 2010 15:54:27 +0800
>> Subject: Re: [httpstreaming] Efficient manifest push (Re: FW: New Version
>> Notification for draft-zong-httpstreaming-gap-analysis-01)
>> Hi,
>> ----- Original Message -----
>> From: "Mark Watson" <[e-mail]>
>> To: "Qin Wu" <[e-mail]>
>> Cc: <[e-mail]>
>> Sent: Friday, October 29, 2010 12:30 PM
>> Subject: Re: [httpstreaming] Efficient manifest push (Re: FW: New Version
>> Notification for draft-zong-httpstreaming-gap-analysis-01)
>>
>>
>>
>> On Oct 28, 2010, at 8:02 PM, Qin Wu wrote:
>> >
>> > [Qin]: Sounds like a good idea to me. I think this is one way to build
>> the interoperable solution for concurrent live streaming viewing with
>> backwards compability to existing cache and client, which may bring the
>> advantage of alleviating server load.  But I am not sure the MIME subtype
>> has the right semantic to do this.
>>
>> [MW] Can you elaborate ?
>>
>> [Qin]: That's what I intepret from what you propose for efficient manifest
>> delivery.
>> As you said, we may need to define new MIME type for manifest push, I
>> agree.
>> Futhermore, I think it will be a good idea to use such feature also for
>> media stream efficient delivery when
>> concurrent streams needs to be served by the same web server and the old
>> chunk that has been playout and in aging conditions
>> need to be dropped.
>>
>> The idea would be if the smart cache in between knows the semantics of new
>> MIME type, this smart
>> caches can choose to replace/update the previous chunk with the new chunk
>> and
>> only serve the newest chunk to all the concurrent live streaming viewers.
>>
>> For details, we may discuss this in Beijing meeting.
>>
>> > We may need some new MIME subtype and new behaviors on how to process
>> it.
>> >
>> > ...Mark
>> >
>> >
>> >
>> >
>> > On Oct 27, 2010, at 11:51 PM, Thomas Stockhammer wrote:
>> >
>> >> Ning,
>> >>
>> >> thanks ....
>> >>
>> >> I recognized that you only replied to some of my comments.
>> >> Does this mean that you agree/disagree with the remaining ones?
>> >>
>> >> Inline some more with [T] ... [\T]
>> >>
>> >> Thomas
>> >>
>> >>> - I am not sure I understand the term "is encrypted into files"
>> >>> [ZN]: I mean "use file with media container" here.
>> >>
>> >> [T]  I do not understand this either! [\T]
>> >>
>> >>> - What do you mean "normal text file"?
>> >>> [ZN]: traditional web page (e.g. html file).
>> >>
>> >> [T] we should be much more careful with terminology [\T]
>> >>
>> >>> - The intelligence in the Adaptive Streaming over HTTP is almost
>> >>> exclusively in the client, there is no negotiation
>> >>> [ZN]: Sorry for confusion, "negotiation" should be "massage exchange".
>> >>
>> >> [T]
>> >> First I hope this is a typo, otherwise I get more curious ...!
>> >> Secondly, I am still not clear what needs to be done beyond regular
>> >> http connections
>> >> [\T]
>> >>
>> >>> 5.2)
>> >>> - It is not correct that the 3GPP MPD needs to be updated even for
>> >>> live. If you use a template mode, the MPD stays static until some
>> >>> "unforeseen" event occurs. Client and Content Preparation have agreed
>> >>> on rules to construct URIs.
>> >>> - If necessary, the MPD update happens asynchronously to the media
>> >>> decoding, so this is not considered to be a problem.
>> >>> [ZN]: I didn't intend to state that pull model doesn't work. My
>> >>> point is,
>> >>> why not investigating the possible usage of push model in certain
>> >>> cases
>> >>> without experiencing the above mentioned "unforeseen" event or
>> >>> asynchronous
>> >>> updates?
>> >>
>> >> [T]
>> >> "Push" is a very very broad term. In Web applications you can for
>> >> example use AJAX or RSS/ATOM like techniques for push-like updates. If
>> >> you use conditional GET for regular polling, this is very efficient.
>> >> The MPD updates in 3GPP work in a similar manner. If you use polling,
>> >> conditional GETs and templates, you are extremely efficient. We should
>> >> really understand what we mean by push model? HTTP-based delivery is
>> >> rich and provides many successfully deployed options.
>> >>
>> >> Should you really refer to something completely different such as IP
>> >> multicast, then I would feel very very uncomfortable.
>> >> [\T]
>> >>
>> >>> - There is for sure mechanisms to deliver important packets more
>> >>> reliably in HTTP - you just request it earlier. In anticipation of
>> >>> switching a smart client may also prepare such data. The client is
>> >>> intelligent.
>> >>> [ZN]: Well, I think this startup issue doesn't like the pre-fetch
>> >>> which is
>> >>> of course still valuable to improve playback. IMO, it is hard to
>> >>> predict
>> >>> which channel the user will switch to in the next moment, hence it
>> >>> is not
>> >>> reasonable to request important packets for other channels. Did I
>> >>> misunderstand you?
>> >>
>> >> [T]
>> >> I would not be worried to have the MPD and the initialization segment
>> >> of the two neighboring channels ready in my device. Again, the client
>> >> can be very smart, especially as it does have access to all the
>> >> information.
>> >>
>> >> In general, I do not disagree that we can create more detailed use
>> >> cases for environments in which we envision that HTTP streaming will
>> >> be used. This may include live multi-channel environments. However, we
>> >> should not conclude per se that the existing technologies do have a
>> >> problem.
>> >> [\T]
>> >>
>> >>> - 3GPP defines QoE metrics that can reused also for HTTP Streaming.
>> >>> there will also be efforts in MPEG in including QoE.
>> >>> [ZN]: I am not proposing to focus on defining QoE metrics, but
>> >>> looking on
>> >>> the protocols to report such metrics, like RTCP. We will support the
>> >>> work in
>> >>> 3GPP/MPEG and cooperate with them to see how to capsulate the
>> >>> metrics in a
>> >>> series of messages.
>> >>
>> >> [T]
>> >> What do you mean with "capsulate"?
>> >> Also, can you be more specific what metrics there are in RTCP that can
>> >> also be used in HTTP Streaming. I consider that anything dealing with
>> >> packet loss is irrelevant. I also do not see the relevance of sending
>> >> regular 5 seconds receiver reports as the content is static and
>> >> adaptation will not happen. Some reporting on Media Presentation level
>> >> may be sufficient, for example when the presentation has been
>> completed.
>> >> [\T]
>> >>
>> >>
>> >> ---
>> >> Dr. Thomas Stockhammer (CEO) || [e-mail] || phone +49 89
>> >> 978980 02 || cell [phone] || http://www.nomor-research.com
>> >> Nomor Research GmbH  -  Sitz der Gesellschaft: München -
>> >> Registergericht: München, HRB 165856 – Umsatzsteuer-ID: DE238047637 -
>> >> Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> httpstreaming mailing list
>> >> [e-mail]
>>
>> >> https://www.ietf.org/mailman/listinfo/httpstreaming
>> >>
>> >
>> > _______________________________________________
>> > httpstreaming mailing list
>> > [e-mail]
>>
>> > https://www.ietf.org/mailman/listinfo/httpstreaming
>>
>>
>> ---------- Forwarded message ----------
>> From: Qin Wu <[e-mail]>
>> To: Mark Watson <[e-mail]>, "Severa, Michael J (Mike)" <
>> [e-mail]>
>> Date: Mon, 01 Nov 2010 16:51:45 +0800
>> Subject: Re: [httpstreaming] Efficient manifest push (Re: FW: New Version
>> Notification for draft-zong-httpstreaming-gap-analysis-01)
>> Hi,
>> ----- Original Message -----
>> From: "Mark Watson" <[e-mail]>
>> To: "Severa, Michael J (Mike)" <[e-mail]>
>> Cc: "Qin Wu" <[e-mail]>; <[e-mail]>
>> Sent: Friday, October 29, 2010 12:32 PM
>> Subject: Re: [httpstreaming] Efficient manifest push (Re: FW: New Version
>> Notification for draft-zong-httpstreaming-gap-analysis-01)
>>
>>
>> Server-sent events defines a stream format for a sequence of DOM events.
>> Essentially each is a set of name/value pairs. It's a very simple text
>> syntax. Not really suitable for manifest updates or video stream segments.
>> But mainly it does not carry any semantics that would enable cache
>> optimizations.
>>
>> [Qin]: I think it is possible to use server-sent event over HTTP or using
>> dedicated server-push protocol to push text based manifest or some metadata
>> for current playlist to the client since the manifest can be in different
>> format.
>> But it is true, server push event has no semantics to carry video
>> streaming segments, since video streaming segement is binary data rather
>> than textual data.
>>
>> ...Mark
>>
>> On Oct 28, 2010, at 8:56 PM, Severa, Michael J (Mike) wrote:
>>
>> > Hi. Check out server-sent events in HTML5. Essentially what is described
>> here, though intended more for the application layer than the media layer.
>> With a decoder interface at the application layer it would probably be
>> possible to do this now by using that feature.
>> >
>> > Mike
>> > ________________________________________
>> > From: [e-mail] [[e-mail]]
>> On Behalf Of Qin Wu [[e-mail]]
>> > Sent: Thursday, October 28, 2010 8:02 PM
>> > To: Mark Watson; [e-mail]
>> > Subject: Re: [httpstreaming] Efficient manifest push (Re: FW: New
>> Version Notification for      draft-zong-httpstreaming-gap-analysis-01)
>> >
>> > Hi,
>> > ----- Original Message -----
>> > From: "Mark Watson" <[e-mail]>
>> > To: <[e-mail]>
>> > Sent: Friday, October 29, 2010 3:17 AM
>> > Subject: [httpstreaming] Efficient manifest push (Re: FW: New Version
>> Notification for draft-zong-httpstreaming-gap-analysis-01)
>> >
>> >
>> > Here is an idea sparked by Thomas' mention below of AJAX and RSS push
>> services.
>> >
>> > In these services the client establishes a long-lived HTTP connection to
>> a server on which it sends a single request. The response comes back in
>> chunks, over time, enabling the server to "push" new content as it becomes
>> available. Generally caches and proxies are transparent to this, although I
>> think it does not work with some older proxies which expect to receive the
>> whole response from upstream before returning anything to the client.
>> Perhaps these are all gone by now. But anyway, the "chunks" cannot really be
>> cached as the proxy has no idea what they are.
>> >
>> > In the case of a document, such as a manifest, which is being
>> periodically updated, or a sequence of different files, one could very
>> simply expose these semantics in a standard way, which would enable caches
>> to do their thing.
>> >
>> > For example, suppose we define a new MIME type, multipart/versions,
>> where each part of the multipart MIME response is a different version of the
>> originally requested resource. A smart cache receiving a request for this
>> resource can cache the "parts" as they arrive, each replacing the previously
>> cached version. It can serve multiple incoming persistent connections with
>> one upstream persistent connection, providing scalability. It would be
>> transparent to existing caches. Clients would indicate their support in the
>> Accept header and clients which did not support this mode would just poll
>> the resource in the usual way with conditional GET requests.
>> >
>> > All that would be required from a standards perspective would be
>> definition of the multipart/versions MIME type.
>> >
>> > Maybe this is not new. I could easily imagine CDNs do this kind of thing
>> internally already.
>> >
>> > Similarly, one could imagine a multipart/sequence MIME type where the
>> parts form a sequence of objects. The client requests an object and (if it
>> indicates support of the multipart/sequence MIME type) gets back that object
>> and subsequent ones in the sequence (with their file names). Again, smart
>> caches could optimise for scalability, caching the parts as separate
>> objects. This could help with delivery of segments in the live case, but
>> again maintaining backwards-compatibility. Again, perhaps CDNs already do
>> something like this internally.
>> >
>> > I'm not proposing to progress these ideas, just thought they were
>> interesting.
>> >
>> > [Qin]: Sounds like a good idea to me. I think this is one way to build
>> the interoperable solution for concurrent live streaming viewing with
>> backwards compability to existing cache and client, which may bring the
>> advantage of alleviating server load.  But I am not sure the MIME subtype
>> has the right semantic to do this. We may need some new MIME subtype and new
>> behaviors on how to process it.
>> >
>> > ...Mark
>> >
>> >
>> >
>> >
>> > On Oct 27, 2010, at 11:51 PM, Thomas Stockhammer wrote:
>> >
>> >> Ning,
>> >>
>> >> thanks ....
>> >>
>> >> I recognized that you only replied to some of my comments.
>> >> Does this mean that you agree/disagree with the remaining ones?
>> >>
>> >> Inline some more with [T] ... [\T]
>> >>
>> >> Thomas
>> >>
>> >>> - I am not sure I understand the term "is encrypted into files"
>> >>> [ZN]: I mean "use file with media container" here.
>> >>
>> >> [T]  I do not understand this either! [\T]
>> >>
>> >>> - What do you mean "normal text file"?
>> >>> [ZN]: traditional web page (e.g. html file).
>> >>
>> >> [T] we should be much more careful with terminology [\T]
>> >>
>> >>> - The intelligence in the Adaptive Streaming over HTTP is almost
>> >>> exclusively in the client, there is no negotiation
>> >>> [ZN]: Sorry for confusion, "negotiation" should be "massage exchange".
>> >>
>> >> [T]
>> >> First I hope this is a typo, otherwise I get more curious ...!
>> >> Secondly, I am still not clear what needs to be done beyond regular
>> >> http connections
>> >> [\T]
>> >>
>> >>> 5.2)
>> >>> - It is not correct that the 3GPP MPD needs to be updated even for
>> >>> live. If you use a template mode, the MPD stays static until some
>> >>> "unforeseen" event occurs. Client and Content Preparation have agreed
>> >>> on rules to construct URIs.
>> >>> - If necessary, the MPD update happens asynchronously to the media
>> >>> decoding, so this is not considered to be a problem.
>> >>> [ZN]: I didn't intend to state that pull model doesn't work. My
>> >>> point is,
>> >>> why not investigating the possible usage of push model in certain
>> >>> cases
>> >>> without experiencing the above mentioned "unforeseen" event or
>> >>> asynchronous
>> >>> updates?
>> >>
>> >> [T]
>> >> "Push" is a very very broad term. In Web applications you can for
>> >> example use AJAX or RSS/ATOM like techniques for push-like updates. If
>> >> you use conditional GET for regular polling, this is very efficient.
>> >> The MPD updates in 3GPP work in a similar manner. If you use polling,
>> >> conditional GETs and templates, you are extremely efficient. We should
>> >> really understand what we mean by push model? HTTP-based delivery is
>> >> rich and provides many successfully deployed options.
>> >>
>> >> Should you really refer to something completely different such as IP
>> >> multicast, then I would feel very very uncomfortable.
>> >> [\T]
>> >>
>> >>> - There is for sure mechanisms to deliver important packets more
>> >>> reliably in HTTP - you just request it earlier. In anticipation of
>> >>> switching a smart client may also prepare such data. The client is
>> >>> intelligent.
>> >>> [ZN]: Well, I think this startup issue doesn't like the pre-fetch
>> >>> which is
>> >>> of course still valuable to improve playback. IMO, it is hard to
>> >>> predict
>> >>> which channel the user will switch to in the next moment, hence it
>> >>> is not
>> >>> reasonable to request important packets for other channels. Did I
>> >>> misunderstand you?
>> >>
>> >> [T]
>> >> I would not be worried to have the MPD and the initialization segment
>> >> of the two neighboring channels ready in my device. Again, the client
>> >> can be very smart, especially as it does have access to all the
>> >> information.
>> >>
>> >> In general, I do not disagree that we can create more detailed use
>> >> cases for environments in which we envision that HTTP streaming will
>> >> be used. This may include live multi-channel environments. However, we
>> >> should not conclude per se that the existing technologies do have a
>> >> problem.
>> >> [\T]
>> >>
>> >>> - 3GPP defines QoE metrics that can reused also for HTTP Streaming.
>> >>> there will also be efforts in MPEG in including QoE.
>> >>> [ZN]: I am not proposing to focus on defining QoE metrics, but
>> >>> looking on
>> >>> the protocols to report such metrics, like RTCP. We will support the
>> >>> work in
>> >>> 3GPP/MPEG and cooperate with them to see how to capsulate the
>> >>> metrics in a
>> >>> series of messages.
>> >>
>> >> [T]
>> >> What do you mean with "capsulate"?
>> >> Also, can you be more specific what metrics there are in RTCP that can
>> >> also be used in HTTP Streaming. I consider that anything dealing with
>> >> packet loss is irrelevant. I also do not see the relevance of sending
>> >> regular 5 seconds receiver reports as the content is static and
>> >> adaptation will not happen. Some reporting on Media Presentation level
>> >> may be sufficient, for example when the presentation has been
>> completed.
>> >> [\T]
>> >>
>> >>
>> >> ---
>> >> Dr. Thomas Stockhammer (CEO) || [e-mail] || phone +49 89
>> >> 978980 02 || cell [phone] || http://www.nomor-research.com
>> >> Nomor Research GmbH  -  Sitz der Gesellschaft: München -
>> >> Registergericht: München, HRB 165856 – Umsatzsteuer-ID: DE238047637 -
>> >> Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> httpstreaming mailing list
>> >> [e-mail]
>>
>> >> https://www.ietf.org/mailman/listinfo/httpstreaming
>> >>
>> >
>> > _______________________________________________
>> > httpstreaming mailing list
>> > [e-mail]
>>
>> > https://www.ietf.org/mailman/listinfo/httpstreaming
>> > _______________________________________________
>> > httpstreaming mailing list
>> > [e-mail]
>>
>> > https://www.ietf.org/mailman/listinfo/httpstreaming
>> >
>>
>>
>> _______________________________________________
>> httpstreaming mailing list
>> [e-mail]
>>
>> https://www.ietf.org/mailman/listinfo/httpstreaming
>>
>>
>>
>