RE: [MEDIA_PIPELINE_TF] Minutes teleconference call 2011-10-06

Hi all,

Might I ask a question or give my opinion regarding R6?
According to the meeting minutes, Adaptive bitrate format is dropped out.
Does it mean we no more discuss on the format, so called manifest? I'm
confused that dropping off is equivalent to there being no discussion
anymore on this. we don't have to start from the scratch as some candidate
formats are available outside W3C, for example, the famous DASH, and even
some proprietary solutions. we can adapt video tag to support adaptive
streaming without making new one.
I guess some discussion is necessary such as what technology will be the
main framework of video tag extension. Manifest could be represented by xml
format or JavaScript friendly JSON or whatever. To what extent the manifest
should support is also a good discussion topic.

What we want to achieve here in W3C is to have browser based single
streaming solution that is available to TV platform. The keyword here is
browser and single. From the standpoint of TV manufacturers and content
owners, we need single solution because we are strayed among too many
seemingly same solutions.

As a start, it does not necessarily to have complicated use cases. Starting
from the very small, very fundamental thing is reasonable. For example,
free VOD content will be a good starting point. After successful migration
from normal video tag to adaptive streaming video tag, we can add more rich
features to the media.

Can I hear from other's viewpoint? I would like to listen to other's
opinion as much as possible.

Best regards,
HJ


-----Original Message-----
From: 
Sent: 없음
To: public-web-and-tv@w3.org
Subject: [MEDIA_PIPELINE_TF] Minutes teleconference call 2011-10-06

Hi,

The minutes of yesterday's Media Pipeline Task Force call are available at:
  http://www.w3.org/2011/10/06-webtv-minutes.html

... and copied as raw text below.

Discussions covered requirements R3 to R9, both included. A possible quick
summary:
- R6 and R9 are already covered with existing technologies, so are probably
going to be dropped.
- R10/R11, R7/R8, and R4/R5 would benefit from parallelization. Clarke will
work on it.

Please check minutes for details I managed to capture.

Thanks,
Francois.

-----
Media Pipeline Task Force Teleconference

06 Oct 2011

    See also: [2]IRC log

       [2] http://www.w3.org/2011/10/06-webtv-irc

Attendees

    Present
           John_Simmons, Franck_Denoual, Eric_Winkelman, Hiroyuki_Aizu,
           Clarke_Stevens, Jan_Lindquist, Duncan_Rowden, Kaz_Ashimura,
           Francois_Daoust, Mark_Watson, Mark_Vickers, Bob_Lund,
           Russell_Berkoff, Steven_Wright, Paul_Caporn

    Regrets
    Chair
           Clarke

    Scribe
           francois

Contents

      * [3]Topics
          1. [4]R3. Midstream Modification of Track Elements
          2. [5]R4. Content Authorization Parameters
          3. [6]R5. Content Authorization Failure
          4. [7]R6. Adaptive Bit Rate Format Support
          5. [8]R7. Adaptive Bit Rate Parameters (and R8. Adaptive Bit
             Rate Feedback)
          6. [9]R9. Security and Digital Rights Management
             Identification
      * [10]Summary of Action Items
      _________________________________________________________

    Clarke: got to requirement 2 last week. Let's move on from there.
    ... We can get through the rest of the less controversial ones
    today.
    ... Next week, we can get to adaptive streaming, then the week after
    that to the digital rights requirements.
    ... Then that's TPAC.
    ... Less concerned that we're not ready by TPAC. We want to show
    that we have requirements at TPAC. From the F2F, we do have general
    agreement about use cases and requirements even it not perfect.
    ... Main goal of TPAC is to bring these to WG.

    John: is the intent to take all of them to TPAC or some of them?

    Clarke: We only want to have standardized those things that can't be
    done today.

R3. Midstream Modification of Track Elements

    <Clarke> R3:
    [11]http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Requirements#R3._Mid
    stream_Modification_of_Track_Elements

      [11]
http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Requirements#R3._Midstream_Modif
ication_of_Track_Elements

    Clarke: ability to change, add, remove track element in the middle
    of a stream.
    ... From some discussion, maybe removing them is not necessary.

    Bob: Changes are going into HTML5 spec as we speak to add this
    capability.
    ... Ian Hickson is leaving the door open to track removal if a use
    case comes for that.
    ... We agree that it's difficult to a) know when a track is gone,
    and b) do something useful with it.

    markW: Potential problem if a track comes back?

    Bob: It wouldn't get added as a new one.

    markW: How would you know it's come back?

    Bob: you'd look at cues.

    markW: What about audio?
    ... [example with English track]
    ... Was planning to comment to HTML WG about that.

    Russell: Similar comment, if you don't know when a track's gone,
    hard to see when a track comes back.
    ... The argument goes that in order for you to rewind, you need to
    have them available. Broadcast does not support rewind, so they
    should reflect what is available.

    Bob: Didn't see anything in the bug's response that it was
    specifically about seeking.

    Russell: maybe I read through the lines here.
    ... How do I have my default language, and over time want to switch
    to another default. If I don't know when a track is removed, I can't
    implement a selection mechanism based on preferences.

    MarkW: valid points. Not quite sure what Ian proposes works in the
    end.
    ... What about track numbers when you remove a track?
    ... It has to be treated in a different way. A track that gets
    removed has to remain in the list.

    Bob: I think that's right, otherwise you can't reorder track.

    Russell: dealt with in OIPF, whether array of tracks is dynamic.
    Ended up with a static array parsed again and again.

    Clarke: in the user agent, you then have to "track" which track maps
    to which index.

    Russell: Yes.

    Clarke: We don't need to change the requirement here necessarily.
    Checking that Jan and Mark's comments are recorded in that bug seems
    the appropriate way to go.

R4. Content Authorization Parameters

    R4:
    [12]http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Requirements#R4._Con
    tent_Authorization_Parameters

      [12]
http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Requirements#R4._Content_Authori
zation_Parameters

    Clarke: Does this one have a bug?

    Bob: No. It is my opinion that this can already be done.
    ... There are a bunch of other issues about parental issues that are
    not covered by the use case.

    Clarke: could be covered by the requirement 2 on being able to
    distinguish types of metadata

    R2:
    [13]http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Requirements#R2._Key
    _Metadata_Types

      [13]
http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Requirements#R2._Key_Metadata_Ty
pes

    John: I took an action item to identify ways to document metadata
    conventions. Two options inside W3C for this kind of documentation:
    community and business groups.

    [14]Community and Business Groups

      [14] http://www.w3.org/community/

    John: this could be the way to get together and work on this kind of
    specification.

    Clarke: Do people agree that a community/business group would be the
    place to work on metadata mapping?

    Bob: I'll be able to share a few things with this group.

R5. Content Authorization Failure

    R5:
    [15]http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Requirements#R5._Con
    tent_Authorization_Failure

      [15]
http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Requirements#R5._Content_Authori
zation_Failure

    Clarke: There are a number of reasons that could explain why you
    cannot play a content.

    MarkW: This seems to be a narrow example of a more generic problem
    for an error reporting mechanism.
    ... It's a real requirement, but I wonder if we could report on the
    generic error reporting mechanism and enumerate the examples we have
    here as part of it.

    Clarke: It may just be the addition of an error, or if the error
    reporting mechanism is not efficient enough.

R6. Adaptive Bit Rate Format Support

    R6:
    [16]http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Requirements#R6._Ada
    ptive_Bit_Rate_Format_Support

      [16]
http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Requirements#R6._Adaptive_Bit_Ra
te_Format_Support

    MarkW: question here is what do we want to normatively specify here?
    That different solutions be supported?

    Bob: We had a couple of specific requests (going through)

    Clarke: we have to be able to tell when it is an adaptive streaming
    format.

    <mav> I don't think R6 is a gap

    <mav> Suggest delete R6 & leave R7 & R8

    MarkW: We need to be clear what we're requesting. If it is something
    that can already be satisified with no changes, it doesn't make
    sense to list that as a requirement.

    JanL: I'm having the same comment as Mark. Could we flag the
    requirement as needed but nothing needs to be done?

    MarkW: If there had been a RF codec, then they would have made a
    requirement. The same applies for adaptive streaming format. If we
    can have DASH be that format, then good. Unclear we can, though.

    MarkV: I think it's going to evolve in the next couple of years.
    Even if we have a RF format, I don't think we should put it forward
    yet.

    John: HTML WG is being format agnostic to let the market decide
    which format to use.

    Clarke: I'm not seeing any strong push to keep that requirement in
    there.
    ... I propose to leave it for a few days. If somebody has some
    strong argument, please make them. Otherwise, I propose to drop it.

R7. Adaptive Bit Rate Parameters (and R8. Adaptive Bit Rate Feedback)

    R7:
    [17]http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Requirements#R7._Ada
    ptive_Bit_Rate_Parameters

      [17]
http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Requirements#R7._Adaptive_Bit_Ra
te_Parameters

    Clarke: Requirement we captured at the F2F.

    JanL: I don't believe there's any mechanism today, e.g. to specify
    the max.

    Clarke: Could we say we have a preference of a way to do this?

    JanL: My preference would be to have a dialog with WG who will pick
    up this requirement.
    ... I don't have a solution. Many times, you come to W3C with a
    proposal. Here I don't have that, so that's why I suggest a dialog.

    MarkV: R7 and R8 are the counterparts of R4 and R5. Parameters in
    the media pipeline, one way for R4 and R7, or the other way for R5
    and R8

    JanL: I note we could change "failure" into "feedback", as we need a
    generic feedback mechanism, not only for failures. I agree with
    MarkV that it's a good parallel.

    Clarke: suggest to merge them?

    JanL: no.

    MarkV: I agree on keeping them separate, just adjust the wording to
    use same words.

    Clarke: ok, so we covered R8 as well. Going on to security.

R9. Security and Digital Rights Management Identification

    R9:
    [18]http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Requirements#R9._Sec
    urity_and_Digital_Rights_Management_Identification

      [18]
http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Requirements#R9._Security_and_Di
gital_Rights_Management_Identification

    Clarke: Parallel with R6. Is the conclusion the same?
    ... For instance, if I am to use UltraViolet, can I do it already?

    Bob: I don't know for UltraViolet. I think that, in general,
    anything can be encoded as mime type parameters.

    Clarke: Do we have anyone from DECE who knows what we might need?

    John: DECE does define a very specific encoding format, not just
    down to the container, also pixel details.
    ... Encoding works fine with downloading and adaptive streaming.
    ... Both DASH on-demand and live demand can be encrypted for
    instance. Not DRM specific.
    ... It's a part 12 compliant encoding (ISO base file format).
    ... I don't see additional requirement for HTML
    ... You may want to know whether the device supports a given
    encryption mechanism.

    JanL: I was a bit confused as to how it worked in a streaming world
    where you keep sending authentication information.

    John: you can have information in the MPD telling if it's DASH,
    where to get the key.
    ... It's just not a file.
    ... In terms of key rotation and things of that nature, that's also
    supported in adaptive streaming as well.
    ... [example of things to do on the production side]
    ... From a browser's point of view, there are lots of reasons why
    you will fail to play content, in particular while dealing with one
    of the DRM subsystems.
    ... Even if you may be able to require a key, you may still end up
    not being able to play the content.

    Clarke: Two basic questions. R9, I haven't heard anything here that
    says we cannot do it today.
    ... Second, I hear more stuff to expose parameters in R10.

    Bob: Second point, similar issue as adaptive bitrate, but different
    information that needs to be conveyed.

    Clarke: Are there some additional security functionalities that need
    to be added beyond being able to expose parameters and provide
    feedback?

    MarkW: [scribe missed that]

    John: [missed beginning] It's a piece of piece process. You can pick
    up one, such as device identification we're talking right now.

    JanL: I just sent a bug proposal based on Hollywood meeting.
    ... If people can comment. ISSUE-18. I'll pick it up next week in
    any case.

    John: We have to be very concise in the requirements for 9 and 10.
    For example, DECE Utlraviolet is too vague, because you might have
    different systems that support different functionalities.

    JanL: Points I raised previously, retrieval of ? and device
    identification, are these precise enough?

    John: I think so.
    ... For some, it's more a matter of user experience issue, where you
    don't want to discover you cannot play after having tried.

    JanL: As I presented in Hollywood, this is something Open IPTV Forum
    touched upon.

    Clarke: Any work that we can reference is useful, yes.
    ... I'm going to suggest that R6 and R9 are already covered, and
    then I'll try to parallelize R10/R11 with R7/R8 and R4/R5.
    ... Thanks everyone, be active online and talk to you next week!

    [Call adjourned]

Summary of Action Items

    [End of minutes]

Received on Tuesday, 11 October 2011 01:51:53 UTC