Subject: Re: [video-codec] Proposed charter

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sun, 4 Nov 2012 23:47:37 +0000

On Aug 20, 2012, at 18:15 , Timothy B. Terriberry <[email-masked]> wrote:

> 3. Specification of a codec that meets the agreed-upon requirements, in
> the form of an Internet-Draft that defines the codec algorithm along
> with source code for a reference implementation. The text description
> of the codec shall describe the mandatory, recommended, and optional
> portions of the encoder and decoder. It is envisioned that this dappropriateocument
> shall be a Proposed Standard document.

So of course I like the ice of an open source reference implementations, but is there any reasons it needs to be in this RFC? I think that will lead to lots of problems of how to update the reference implementation.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sun, 4 Nov 2012 23:47:41 +0000

On Aug 20, 2012, at 18:15 , Timothy B. Terriberry <[email-masked]> wrote:

> 4. Specification of a storage format for non-interactive (HTTP)
> streaming or file transfer of the codec. It is envisioned that this
> document shall be a Proposed Standard document.

I think I would prefer to see this say something a little more specific like do a storage format appropriate for use with DASH. If folks want to propose something other than DASH, sure, replace DASH with whatever, but my point is, I don't want this WG to be charter to do a DASH equivalent just as one of the sides topics. That is enough work it would need it's own WG.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 05 Nov 2012 00:05:05 -0500

On 11/4/12 6:47 PM, Cullen Jennings (fluffy) wrote:
>> streaming or file transfer of the codec. It is envisioned that 
>> this document shall be a Proposed Standard document.
> 
> I think I would prefer to see this say something a little more 
> specific like do a storage format appropriate for use with DASH.
> If folks want to propose something other than DASH, sure, replace
> DASH with whatever, but my point is, I don't want this WG to be
> charter to do a DASH equivalent just as one of the sides topics.
> That is enough work it would need it's own WG.

Given the proposed use cases, I would have expected to see something
about packetization rather than storage; but we can discuss in the BoF
tomorrow if there's time, or on the list if not.

Peter (*not* as BoF co-chair)

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 05 Nov 2012 16:46:28 +0100

> I think I would prefer to see this say something a little more specific like do a storage format appropriate for use with DASH. If folks want to propose something other than DASH, sure, replace DAS…
should we say that it needs to have a storage form that can be chunked, 
stored and reconstructed from chunks?

I think that is the requirement to fit into DASH, and also for things 
like the MediaSource API in W3C; with some more constraints on what 
"chunking" means, it's probably also good enough to fit into Matroska 
and Ogg.

(whether chunks are measured in milliseconds or 10s-of-seconds is 
another discussion topic, and more fit for discussing the format draft 
than for discussing the charter.)

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 5 Nov 2012 15:55:58 +0000

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Monday, November 5, 2012 11:46 AM
To: "[email-masked]" <[email-masked]>
Subject: [video-codec] Storage format (Re:  Proposed charter)

>> I think I would prefer to see this say something a little more specific
>>like do a storage format appropriate for use with DASH. If folks want to
>>propose something other than DASH, sure, replace DASH with whatever, but
>>my point is, I don't want this WG to be charter to do a DASH equivalent
>>just as one of the sides topics. That is enough work it would need it's
>>own WG.
>>

If you want http streaming support, rather than a simple progressive
download session, it has to be chunked anyway. Maybe the charter should
actually clarify whether we need just progressive download support or a
bit more advanced streaming support.

>"chunking" means, it's probably also good enough to fit into Matroska

Could be, but see above. Chunking or not chunking is  fundamental question
regardless of you want dash support or not.

>than for discussing the charter.)

Sure, that is something dependent on the desired coding and storage
efficiency, playback capabilities and things like that. Not specifically a
charter level discussion.

>
>
>
>_______________________________________________
>video-codec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/video-codec

---

From: Ralph Giles <[email-masked]>
Date: Mon, 05 Nov 2012 09:46:45 -0800

> bit more advanced streaming support.

Can you elaborate on the requirement you're proposing here? HTTP
streaming, in the sense that media can be encoded and sent out in a
single pass, works fine with WebM and Ogg containers.

I've heard chunking into discrete files is necessary for some CDN-based
delivery schemes, because the CDN won't pipeline file delivery. Is that
what you're referring to?

 -r

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 5 Nov 2012 18:04:50 +0000

-----Original Message-----
From: Ralph Giles <[email-masked]>
Date: Monday, November 5, 2012 1:46 PM
To: "Ali C. Begen" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [video-codec] Storage format (Re:  Proposed charter)

>Can you elaborate on the requirement you're proposing here? HTTP

I am not proposing any requirement. Just thought it would be nice for the
charter to clarify this bullet. If you want simple progressive download,
you just need a file format like a container that can use with the new
codec. But, if you want a streaming functionality with trick modes, etc.,
the format has to support chunkability somehow.

The file that holds the content on the server could be one huge file or
several smaller files where each file holds one or more chunks. Dash
really does not care about that. IOW, chunking does not have to be
physical chunking. It could be all "virtual".

>single pass, works fine with WebM and Ogg containers.

Sure.

>delivery schemes, because the CDN won't pipeline file delivery. Is that

Correct. 

>what you're referring to?

Nope. I hope what I meant is clear now from above.

-acbeen

---

From: Ralph Giles <[email-masked]>
Date: Mon, 05 Nov 2012 10:51:39 -0800

> physical chunking. It could be all "virtual".

Ok, thanks for clarifying.

I don't think this needs to be in the charter, although I have no
objection to Harald's suggested wording change. This should certainly be
part of the requirements or technical discussion when writing storage
format drafts.

Defining a common format for on-disk and http delivery is important for
interoperability. Objective 3 of the charter covers packet-based
transmission via RTP, but the corresponding payload draft may be
primarily discussed in other areas of the IETF, like avt. That's not
obviously the case for a storage format, so it's helpful to have a
separate deliverable for this in the videocodec charter.

 -r

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 5 Nov 2012 19:07:41 +0000

-----Original Message-----
From: Ralph Giles <[email-masked]>
Date: Monday, November 5, 2012 2:51 PM
To: "Ali C. Begen" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>

>part of the requirements or technical discussion when writing storage

Well, I just commented on Cullen's email which was commenting on something
in the charter. If it were not there, I would not shout ;)

>primarily discussed in other areas of the IETF, like avt. That's not

Yeah, I happen to co-chair the payload wg.

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Mon, 05 Nov 2012 14:12:19 -0500

> separate deliverable for this in the videocodec charter.

Right. This item was primarily there to justify something like the  
current draft-terriberry-oggopus being discussed in the codec WG. Such  
a deliverable is needed to allow Opus to be served in the HTML5  
<audio> tag. After consultation with various ADs concluded that they  
wanted that work done in codec, we were able to add a deliverable for  
it based on some implicit language in the charter, but I wanted to be  
more explicit about it this time. The HTML5 <video> tag is still an  
important use case to me, DASH or no DASH.

Whether that file format (or formats) should support live streaming (a  
la WebM, Ogg, and MPEG-TS) or chunked delivery or any of a number of  
other possible container features is probably a subject for  
requirements, as Ralph said, and not for the charter, in my personal  
opinion.