Subject: [video-codec] Charter update

From: "Timothy B. Terriberry" <[email-masked]>
Date: Tue, 01 Jan 2013 22:36:49 -0800

Slightly later than I'd hoped, here is an updated version of the 
proposed charter, based on feedback from the list and during the BoF. 
The major changes are

- Clarify that HTTP streaming should support both progressive and 
chunked downloads.
- Added some examples of what "optimized for the Internet" means.
- Clarified that the we only intend to produce one codec.
- Added a goal to be suitable for use with various Internet applications 
and Web APIs.
- Unified language about the ITU and ISO.
- Removed the suggestion that we would ask other SDOs if one of their 
existing codecs satisfies all of our requirements and goals.
- Added a statement that we should not produce an RFC if there is 
consensus that the codec cannot "be widely implemented and easily 
distributed among application developers, service operators, and end users."
- Moved the reference implementation into a separate deliverable
- Added a deliverable for a test results document
- Minor editorial changes.

I think there is still work to do on the language about interacting with 
other SDOs. However, I have not gotten any response to my Nov. 6th 
request [1] for specific language that people want to see here. Rob, any 
suggestions would be welcome.

[1] http://www.ietf.org/mail-archive/web/video-codec/current/msg00064.html

The full text of the proposed charter follows. A full diff from the 
previous version is attached.

Problem Statement

According to reports from developers of Internet video applications and 
operators of Internet video services, there is no standardized, 
high-quality video codec that meets all of the following three conditions:

1. Is optimized for use in interactive Internet applications.

2. Is published by a recognized standards development organization (SDO) 
and therefore subject to clear change control and IPR disclosure rules.

3. Can be widely implemented and easily distributed among application 
developers, service operators, and end users.

There exist codecs that provide high quality encoding of video 
information, but that are not optimized for the actual conditions of the 
public, consumer-level, best-effort Internet. Such optimizations might 
include fast and flexible congestion control, such as the ability to 
change resolution without sending a keyframe; a simple means of handling 
packet loss in the face of reference frame re-ordering; the ability to 
join broadcast streams without waiting for a keyframe; special coding 
tools for screen captures to support remote services and desktop 
sharing; and many more. According to reports, this mismatch between 
design and deployment has hindered performance and interoperability of 
such codecs in Internet applications.

There exist codecs that can be widely implemented, but were not 
developed under the IPR rules of any SDO; according to reports, the lack 
of clarity in their IPR status has hindered adoption of such codecs in 
Internet applications.

There exist codecs that are standardized, but that cannot be widely 
implemented and easily distributed; according to reports, the presence 
of various usage restrictions (e.g., in the form of requirements to pay 
royalty fees, obtain a license, enter into a business agreement, or meet 
other special conditions imposed by a patent holder) has hindered 
adoption of such codecs in Internet applications.

According to application developers and service operators, a video codec 
that meets all three of these conditions would: (1) enable protocol 
designers to more easily specify a mandatory-to-implement codec in their 
protocols and thus improve interoperability; (2) enable developers to 
more easily build innovative applications for the Internet; (3) enable 
service operators to more easily deploy affordable, high-quality video 
services on the Internet; and (4) enable end users of Internet 
applications and services to enjoy an improved user experience.

Objectives

The goal of this working group is to ensure the existence of a single 
high-quality video codec that can be widely implemented and easily 
distributed among application developers, service operators, and end 
users. At present it appears that ensuring the existence of such a codec 
will require a development effort within the working group.

The core technical considerations for such a codec include, but are not 
necessarily limited to, the following:

1. Designing for use in interactive applications (examples include, but 
are not limited to, point-to-point video calls, multi-party video 
conferencing, telepresence, teleoperation, and in-game video chat).

2. Addressing the real transport conditions of the Internet, such as the 
flexibility to rapidly respond to changing bandwidth availability and 
loss rates, or as otherwise identified and prioritized by the working group.

3. Ensuring interoperability and clean integration with the Real-time 
Transport Protocol (RTP), including secure transport via SRTP.

4. Ensuring interoperability with Internet signaling technologies such 
as Session Initiation Protocol (SIP), Session Description Protocol 
(SDP), and Extensible Messaging and Presence Protocol (XMPP). However, 
the result should not depend on the details of any particular signaling 
technology.

5. Ensuring suitability for use in Internet applications and Web APIs, 
such as the HTML5 <video> tag, live streaming (e.g., via icecast), 
adaptive streaming (e.g., Dynamic Adaptive Streaming over HTTP (DASH), 
HTTP Live Streaming (HLS), etc.), the MediaSource API, the WebRTC APIs, 
proposed web recording APIs, and so on. However, the result should not 
depend on the details of any particular API.

Optimizing for very low bit rates (typically below 64 kbps) is out of 
scope because such work might necessitate specialized optimizations.

In addition to the technical objectives, there is one process goal, which is

6. Ensuring the work is done under the IPR rules of the IETF.

Although a codec produced by this working group or another standards 
organization might be used as a mandatory-to-implement technology by 
designers of particular Internet protocols, it is explicitly not a goal 
of the working group to produce a codec that will be mandated for use 
across the entire IETF or Internet community nor would their be any 
expectation that this would be the only mandatory-to-implement codec.

Based on the working group's analysis of the design space, the working 
group might determine that it needs to produce a codec with multiple 
modes of operation. However, it is not the goal of working group to 
produce more than one codec.

In completing its work, the working group should collaborate with other 
IETF working groups to complete particular tasks. These might include, 
but would not be limited to, the following:

- Within the AVT WG, define the codec's payload format for use with the 
Real-time Transport Protocol (RTP).

- Collaborate with RMCAT and any other appropriate working groups in the 
Transport Area to identify important aspects of packet transmission over 
the Internet.

- Collaborate with RMCAT to understand the degree of rate adaptation 
desirable, and to reflect that understanding in the design of a codec 
that can adjust its transmission in a way that minimizes disruption to 
the video.

- Collaborate with working groups in the RAI Area to ensure that 
information about and negotiation of the codec can be easily represented 
at the signaling layer.

- Collaborate with working groups in the RAI Area such as CLUE and 
RTCWEB to ensure the codec can satisfy all of their video-related use cases.

The working group will coordinate with the ITU-T (Study group 16) and 
ISO/IEC (JTC1/SC29 WG11), with the intent of submitting the completed 
codec RFC for co-publication by the ITU-T and ISO if they find that 
appropriate. Information about codecs being standardized, including a 
detailed description of the requirements and goals, will be available to 
other SDOs in the form of Internet-Drafts and the working group welcomes 
technical feedback from other SDOs and experts from other organizations.

The Guidelines for Development of an Audio Codec within the IETF (RFC 
6569) will form the starting point for guidelines and requirements for 
achieving the forgoing objectives for video. The working group will 
modify them as necessary with lessons learned during that process (for 
example, specifying the use of English text as the normative definition 
of the codec instead of source code), refining them into a new document 
in accordance with the usual IETF procedures once consensus has been 
achieved.

A codec that can be widely implemented and easily distributed among 
application developers, service operators, and end users is preferred. 
Many existing codecs that might fulfill some or most of the technical 
attributes listed above are encumbered in various ways. For example, 
patent holders might require that those wishing to implement the codec 
in software, deploy the codec in a service, or distribute the codec in 
software or hardware need to request a license, enter into a business 
agreement, pay licensing fees or royalties, or attempt to adhere to 
other special conditions or restrictions.

Because such encumbrances have made it difficult to widely implement and 
easily distribute high-quality video codecs across the entire Internet 
community, the working group prefers unencumbered technologies in a way 
that is consistent with BCP 78 and BCP 79. In particular, the working 
group shall heed the preference stated in BCP 79: "In general, IETF 
working groups prefer technologies with no known IPR claims or, for 
technologies with claims against them, an offer of royalty-free 
licensing." Although this preference cannot guarantee that the working 
group will produce an unencumbered codec, the working group shall follow 
BCP 79, and adhere to the spirit of BCP 79. The working group cannot 
explicitly rule out the possibility of adopting encumbered technologies; 
however, the working group will try to avoid encumbered technologies 
that require royalties or other encumbrances that would prevent such 
technologies from being easy to redistribute and use. The working group 
should not proceed with publication of a codec RFC if there is consensus 
that it cannot "be widely implemented and easily distributed among 
application developers, service operators, and end users."

Deliverables

1. A set of Codec Standardization Guidelines that define the work 
processes of the working group. This document shall be Informational.

2. A set of technical Requirements. This document shall be Informational.

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

4. A reference implementation of a software encoder and decoder. This 
will be in a separate document from the text description to allow it to 
be updated independently. It does not need to be standards-track.

5. Specification of a storage format for file transfer of the codec, to 
support non-interactive (HTTP) streaming, including live encoding and 
both progressive and chunked downloads. It is envisioned that this 
document shall be a Proposed Standard document.

6. A collection of test results, either from tests conducted by the 
working group or made publicly available elsewhere, characterizing the 
performance of the codec. This document shall be informational.

Goals and Milestones
TBD  WGLC on codec standardization guidelines
TBD  WGLC on requirements, liaise to other SDOs
TBD  Requirements to IESG (Informational)
TBD  Liaise requirements RFC to other SDOs
TBD  Codec standardization guidelines to IESG (Informational)
TBD  WGLC on codec specification, liaise to other SDOs
TBD  WGLC on reference implementation, liaise to other SDOs
TBD  Submit codec specification to IESG (Standards Track)
TBD  Submit reference implementation to IESG (Informational)
TBD  WGLC on storage format specification
TBD  Submit storage format specification to IESG (Standards Track)
TBD  WGLC on Testing document
TBD  Testing document to IESG
--- video-codec-charter-20120924.txt	2013-01-01 21:59:28.530611669 -0800
+++ video-codec-charter-20130101.txt	2013-01-01 22:11:37.726358250 -0800
@@ -16,9 +16,15 @@
 
 There exist codecs that provide high quality encoding of video
 information, but that are not optimized for the actual conditions of the
-Internet; according to reports, this mismatch between design and
-deployment has hindered interoperability of such codecs in interactive
-Internet applications.
+public, consumer-level, best-effort Internet. Such optimizations might
+include fast and flexible congestion control, such as the ability to
+change resolution without sending a keyframe; a simple means of handling
+packet loss in the face of reference frame re-ordering; the ability to
+join broadcast streams without waiting for a keyframe; special coding
+tools for screen captures to support remote services and desktop
+sharing; and many more. According to reports, this mismatch between
+design and deployment has hindered performance and interoperability of
+such codecs in Internet applications.
 
 There exist codecs that can be widely implemented, but were not
 developed under the IPR rules of any SDO; according to reports, the lack
@@ -47,9 +53,10 @@
 high-quality video codec that can be widely implemented and easily
 distributed among application developers, service operators, and end
 users. At present it appears that ensuring the existence of such a
-codec will require a development effort within the working group. The
-core technical considerations for such a codec include, but are not
-necessarily limited to, the following:
+codec will require a development effort within the working group.
+
+The core technical considerations for such a codec include, but
+are not necessarily limited to, the following:
 
 1. Designing for use in interactive applications (examples include, but
 are not limited to, point-to-point video calls, multi-party video
@@ -65,32 +72,36 @@
 
 4. Ensuring interoperability with Internet signaling technologies such
 as Session Initiation Protocol (SIP), Session Description Protocol
-(SDP), and Extensible Messaging and Presence Protocol (XMPP); however,
+(SDP), and Extensible Messaging and Presence Protocol (XMPP). However,
 the result should not depend on the details of any particular signaling
 technology.
 
+5. Ensuring suitability for use in Internet applications and Web APIs,
+such as the HTML5 <video> tag, live streaming (e.g., via icecast),
+adaptive streaming (e.g., Dynamic Adaptive Streaming over HTTP (DASH),
+HTTP Live Streaming (HLS), etc.), the MediaSource API, the WebRTC APIs,
+proposed web recording APIs, and so on. However, the result should not
+depend on the details of any particular API.
+
 Optimizing for very low bit rates (typically below 64 kbps) is out of
 scope because such work might necessitate specialized optimizations.
 
 In addition to the technical objectives, there is one process goal,
 which is
 
-5. Ensuring the work is done under the IPR rules of the IETF.
+6. Ensuring the work is done under the IPR rules of the IETF.
 
 Although a codec produced by this working group or another standards
 organization might be used as a mandatory-to-implement technology by
 designers of particular Internet protocols, it is explicitly not a goal
-of the working group to produce or select a codec that will be mandated
-for use across the entire IETF or Internet community nor would their be
-any expectation that this would be the only mandatory-to-implement
-codec.
+of the working group to produce a codec that will be mandated for use
+across the entire IETF or Internet community nor would their be any
+expectation that this would be the only mandatory-to-implement codec.
 
 Based on the working group's analysis of the design space, the working
-group might determine that it needs to produce more than one codec, or
-a codec with multiple modes; however, it is not the goal of working
-group to produce more than one codec, and to reduce confusion in the
-marketplace the working group shall endeavor to produce as few codecs
-as possible.
+group might determine that it needs to produce a codec with multiple
+modes of operation. However, it is not the goal of working group
+to produce more than one codec.
 
 In completing its work, the working group should collaborate with other
 IETF working groups to complete particular tasks. These might include,
@@ -118,20 +129,21 @@
 
 The working group will coordinate with the ITU-T (Study group 16) and
 ISO/IEC (JTC1/SC29 WG11), with the intent of submitting the completed
-codec RFC for co-publication if they find that appropriate. The working
-group will communicate a detailed description of the requirements and
-goals to other SDOs including the ITU-T and MPEG to help determine if
-existing codecs meet the requirements and goals. Information about
-codecs being standardized will be available to other SDOs in the form
-of Internet-Drafts and the working group welcomes technical feedback
-from other SDOs and experts from other organizations.
+codec RFC for co-publication by the ITU-T and ISO if they find that
+appropriate. Information about codecs being standardized, including a
+detailed description of the requirements and goals, will be available
+to other SDOs in the form of Internet-Drafts and the working group
+welcomes technical feedback from other SDOs and experts from other
+organizations.
 
 The Guidelines for Development of an Audio Codec within the IETF (RFC
 6569) will form the starting point for guidelines and requirements for
 achieving the forgoing objectives for video. The working group will
-modify them as necessary with lessons learned during that process,
-refining them into a new document in accordance with the usual IETF
-procedures once consensus has been achieved.
+modify them as necessary with lessons learned during that process (for
+example, specifying the use of English text as the normative definition
+of the codec instead of source code), refining them into a new document
+in accordance with the usual IETF procedures once consensus has been
+achieved.
 
 A codec that can be widely implemented and easily distributed among
 application developers, service operators, and end users is preferred.
@@ -156,7 +168,10 @@
 explicitly rule out the possibility of adopting encumbered technologies;
 however, the working group will try to avoid encumbered technologies
 that require royalties or other encumbrances that would prevent such
-technologies from being easy to redistribute and use.
+technologies from being easy to redistribute and use. The working group
+should not proceed with publication of a codec RFC if there is consensus
+that it cannot "be widely implemented and easily distributed among
+application developers, service operators, and end users."
 
 Deliverables
 
@@ -167,16 +182,24 @@
 Informational.
 
 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
+the form of an Internet-Draft that defines the codec algorithm. The text
+description of the codec shall describe the mandatory, recommended, and
+optional portions of the encoder and decoder. It is envisioned that this
 document shall be a Proposed Standard document.
 
-4. Specification of a storage format for non-interactive (HTTP)
-streaming or file transfer of the codec. It is envisioned that this
+4. A reference implementation of a software encoder and decoder. This
+will be in a separate document from the text description to allow it to
+be updated independently. It does not need to be standards-track.
+
+5. Specification of a storage format for file transfer of the codec,
+to support non-interactive (HTTP) streaming, including live encoding
+and both progressive and chunked downloads. It is envisioned that this
 document shall be a Proposed Standard document.
 
+6. A collection of test results, either from tests conducted by the
+working group or made publicly available elsewhere, characterizing the
+performance of the codec. This document shall be informational.
+
 Goals and Milestones
 TBD  WGLC on codec standardization guidelines
 TBD  WGLC on requirements, liaise to other SDOs
@@ -184,7 +207,9 @@
 TBD  Liaise requirements RFC to other SDOs
 TBD  Codec standardization guidelines to IESG (Informational)
 TBD  WGLC on codec specification, liaise to other SDOs
+TBD  WGLC on reference implementation, liaise to other SDOs
 TBD  Submit codec specification to IESG (Standards Track)
+TBD  Submit reference implementation to IESG (Informational)
 TBD  WGLC on storage format specification
 TBD  Submit storage format specification to IESG (Standards Track)
 TBD  WGLC on Testing document

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Wed, 02 Jan 2013 05:10:04 -0500

This is my first time reading through the proposed charter, and I think 
it's quite good as is (for whatever value that has coming from me).  
However, and I know this was hinted at in its existing form, I would 
like to propose language that would explicitly include a goal of 
enabling support within free and open-source software implementations, 
as opposed to the more general language from BCP 79, which states it 
must "be widely implemented and easily distributed among application 
developers, service operators, and end users."  I believe there there 
could exist solutions that satisfy the condition quoted from BCP 79 and 
yet would not be implementable in free software applications.

The beauty of this kind of a stipulation is that it does not rule out 
the usage of the produced codec in non-free applications, as qualifying 
as free software doesn't have to include exclusion from less-open 
software applications.

I know that that is what is intended by using the language above as a 
guideline, and attempts to address known barriers to free software 
implementation, such as following IETF's IPR guidelines, are already 
being explicitly invoked.  But I think it is not a remote possibility 
that a solution can be found that could theoretically pose problems to 
implementations in free software projects and applications.  Having 
explicit language making that as a goal would protect from exactly such 
a scenario.  I believe it can be placed in the explanative text for the 
above-quoted line as part of the WG's understanding of the phrase, 
"...be widely implemented and easily distributed...".

I propose something along the lines of what follows (changed as 
appropriate for charter-worthiness):

- A successful codec must be permitted, whether legally or otherwise, to 
be implemented in free and open source software applications without 
compromising the licenses under which such applications are distributed.

I know that that is rather clunky, but the meaning of what I was trying 
to get across is conveyed, hopefully.  At the very least, I hope further 
discussion on whether this is even needed to ensure the stated goals can 
occur.

-- 
Libre Video
http://librevideo.org

---

From: Rob Glidden <[email-masked]>
Date: Fri, 04 Jan 2013 17:53:05 -0800

> I think there is still work to do on the language about interacting 
with other SDOs. However, I have not gotten
 > any response to my Nov. 6th request [1] for specific language that 
people want to see here.
 > Rob, any suggestions would be welcome.

Suggested new version of paragraph:

"The working group will coordinate with the ITU-T (Study group 16) and 
ISO/IEC (JTC1/SC29 WG11), with the intent of submitting the completed 
codec RFC for co-publication by the ITU-T and ISO if they find that 
appropriate. To facilitate the potential for co-publication, and 
recognizing other SDOs like ISO/IEC (JTC1/SC29 WG11) are assessing video 
codec technologies for potential royalty-free standardization, the 
working group will seek on an ongoing basis where feasible to 
communicate through existing liaison channels and meetings, evaluate and 
share in-process proposals, test results, code bases, and IPR 
information, and facilitate parallel consideration of the working 
group's work-in-progress for royalty-free standardization under 
processes like the Common Patent Policy for ITU-T/ITU-R/ISO/IEC."

(Old version: The working group will coordinate with the ITU-T (Study 
group 16) and ISO/IEC (JTC1/SC29 WG11), with the intent of submitting 
the completed codec RFC for co-publication by the ITU-T and ISO if they 
find that appropriate. Information about codecs being standardized, 
including a detailed description of the requirements and goals, will be 
available to other SDOs in the form of Internet-Drafts and the working 
group welcomes technical feedback from other SDOs and experts from other 
organizations. )

Rob

On 1/1/2013 10:36 PM, Timothy B. Terriberry wrote:
> - Added a goal to be suitable for use with various Internet 
> applications and Web APIs.
> users."
> I think there is still work to do on the language about interacting 
> with other SDOs. However, I have not gotten any response to my Nov. 
> 6th request [1] for specific language that people want to see here. 
> Rob, any suggestions would be welcome.
>
> [1] 
> http://www.ietf.org/mail-archive/web/video-codec/current/msg00064.html
>
> According to reports from developers of Internet video applications 
> and operators of Internet video services, there is no standardized, 
> 2. Is published by a recognized standards development organization 
> (SDO) and therefore subject to clear change control and IPR disclosure 
> rules.
>
> information, but that are not optimized for the actual conditions of 
> the public, consumer-level, best-effort Internet. Such optimizations 
> might include fast and flexible congestion control, such as the 
> ability to change resolution without sending a keyframe; a simple 
> means of handling packet loss in the face of reference frame 
> re-ordering; the ability to join broadcast streams without waiting for 
> a keyframe; special coding tools for screen captures to support remote 
> services and desktop sharing; and many more. According to reports, 
> this mismatch between design and deployment has hindered performance 
> and interoperability of such codecs in Internet applications.
>
> developed under the IPR rules of any SDO; according to reports, the 
> lack of clarity in their IPR status has hindered adoption of such 
> codecs in Internet applications.
>
> of various usage restrictions (e.g., in the form of requirements to 
> pay royalty fees, obtain a license, enter into a business agreement, 
> or meet other special conditions imposed by a patent holder) has 
> hindered adoption of such codecs in Internet applications.
>
> According to application developers and service operators, a video 
> codec that meets all three of these conditions would: (1) enable 
> protocol designers to more easily specify a mandatory-to-implement 
> codec in their protocols and thus improve interoperability; (2) enable 
> developers to more easily build innovative applications for the 
> Internet; (3) enable service operators to more easily deploy 
> affordable, high-quality video services on the Internet; and (4) 
> enable end users of Internet applications and services to enjoy an 
> improved user experience.
>
> Objectives
>
> codec will require a development effort within the working group.
>
> The core technical considerations for such a codec include, but are 
> not necessarily limited to, the following:
>
> 1. Designing for use in interactive applications (examples include, 
> but are not limited to, point-to-point video calls, multi-party video 
> 2. Addressing the real transport conditions of the Internet, such as 
> the flexibility to rapidly respond to changing bandwidth availability 
> and loss rates, or as otherwise identified and prioritized by the 
> working group.
>
> the result should not depend on the details of any particular 
> signaling technology.
>
> HTTP Live Streaming (HLS), etc.), the MediaSource API, the WebRTC 
> APIs, proposed web recording APIs, and so on. However, the result 
> should not depend on the details of any particular API.
>
> designers of particular Internet protocols, it is explicitly not a 
> goal of the working group to produce a codec that will be mandated for 
> use across the entire IETF or Internet community nor would their be 
> any expectation that this would be the only mandatory-to-implement codec.
>
> In completing its work, the working group should collaborate with 
> other IETF working groups to complete particular tasks. These might 
> include, but would not be limited to, the following:
>
> - Within the AVT WG, define the codec's payload format for use with 
> the Real-time Transport Protocol (RTP).
>
> - Collaborate with RMCAT and any other appropriate working groups in 
> the Transport Area to identify important aspects of packet 
> transmission over the Internet.
>
> information about and negotiation of the codec can be easily 
> represented at the signaling layer.
>
> detailed description of the requirements and goals, will be available 
> to other SDOs in the form of Internet-Drafts and the working group 
> welcomes technical feedback from other SDOs and experts from other 
> organizations.
>
> example, specifying the use of English text as the normative 
> definition of the codec instead of source code), refining them into a 
> new document in accordance with the usual IETF procedures once 
> consensus has been achieved.
>
> Because such encumbrances have made it difficult to widely implement 
> and easily distribute high-quality video codecs across the entire 
> Internet community, the working group prefers unencumbered 
> technologies in a way that is consistent with BCP 78 and BCP 79. In 
> particular, the working group shall heed the preference stated in BCP 
> 79: "In general, IETF working groups prefer technologies with no known 
> IPR claims or, for technologies with claims against them, an offer of 
> royalty-free licensing." Although this preference cannot guarantee 
> that the working group will produce an unencumbered codec, the working 
> group shall follow BCP 79, and adhere to the spirit of BCP 79. The 
> working group cannot explicitly rule out the possibility of adopting 
> encumbered technologies; however, the working group will try to avoid 
> encumbered technologies that require royalties or other encumbrances 
> that would prevent such technologies from being easy to redistribute 
> and use. The working group should not proceed with publication of a 
> codec RFC if there is consensus that it cannot "be widely implemented 
> and easily distributed among application developers, service 
> operators, and end users."
>
> Deliverables
>
> 3. Specification of a codec that meets the agreed-upon requirements, 
> in the form of an Internet-Draft that defines the codec algorithm. The 
> text description of the codec shall describe the mandatory, 
> recommended, and optional portions of the encoder and decoder. It is 
> envisioned that this document shall be a Proposed Standard document.
>
> will be in a separate document from the text description to allow it 
> to be updated independently. It does not need to be standards-track.
>
> 5. Specification of a storage format for file transfer of the codec, 
> to support non-interactive (HTTP) streaming, including live encoding 
> and both progressive and chunked downloads. It is envisioned that this

---

From: Christian Kurz <[email-masked]>
Date: Thu, 3 Jan 2013 22:38:45 +0100

Hello,
I have been attending this mailinglist for a few months and although i
neither am a developer nor any kind of expert, i would like to make a
suggestion i didn't see around here:
I think that it might be favourable to explicitly support p2p-applications
with the new codec. I strongly believe, that p2p-streaming will become more
important in the future.
In order to support p2p-streaming i think, that it might be wise to support
scaleable-video coding as described in this
paper<ftp://130.83.198.178/papers/APKS09.paper.pdf>by Osama Abboud,
Konstantin Pussep, Aleksandra Kovacevic and Ralf Steinmetz.

I am sorry if my suggestions are dumb or have been made before, but i
thought that this kind of decision should be made early in the development
phase.

Kind regards
Christian Kurz

2013/1/2 Basil Mohamed Gohar <[email-masked]>

>  However, and I know this was hinted at in its existing form, I would like
> to propose language that would explicitly include a goal of enabling
> support within free and open-source software implementations, as opposed to
> the more general language from BCP 79, which states it must "be widely
> implemented and easily distributed among application developers, service
> operators, and end users."  I believe there there could exist solutions
> that satisfy the condition quoted from BCP 79 and yet would not be
> implementable in free software applications.
>
> The beauty of this kind of a stipulation is that it does not rule out the
> usage of the produced codec in non-free applications, as qualifying as free
> software doesn't have to include exclusion from less-open software
> applications.
>
> implementation, such as following IETF's IPR guidelines, are already being
> explicitly invoked.  But I think it is not a remote possibility that a
> solution can be found that could theoretically pose problems to
> explicit language making that as a goal would protect from exactly such a
> scenario.  I believe it can be placed in the explanative text for the
> above-quoted line as part of the WG's understanding of the phrase, "...be
> widely implemented and easily distributed...".
>
> I know that that is rather clunky, but the meaning of what I was trying to
> get across is conveyed, hopefully.  At the very least, I hope further
> ______________________________**_________________
> video-codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/video-codec<https://www.ietf.org/mailman/listinfo/video-codec>
>