Re: [video-codec] Storage format (Re: Proposed charter)

"Ali C. Begen (abegen)" <> Mon, 05 November 2012 18:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6079321F84BA for <>; Mon, 5 Nov 2012 10:04:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UvVVCxViHQl3 for <>; Mon, 5 Nov 2012 10:04:51 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7423121F84AB for <>; Mon, 5 Nov 2012 10:04:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1730; q=dns/txt; s=iport; t=1352138691; x=1353348291; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=IHvN5g23oaRpBMw9Ha1uHf8/yikzxH4ZUTyqucpV/Po=; b=E6egcfdDxCLBrXt2hbd9HqWzISVJWDFObzlb3nxn3ZY+l69klxq6Nqrh 1JN4SCDWyJZaejibS1nQrID6I3kqvWFUhzaNlXM0eNj1O9P5maOYznPlQ w832RIQ/Ehyee1jK9xyhbjYqz1kvcXT0DnZV+5aXnVWpmt8AAxODW1J62 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAEz+l1CtJXHB/2dsb2JhbABEgmzARoEIgh4BAQEEEgEnPwwGAQgRAwECAQoUQh0IAgQOBQgah2gBmwigAYwBIIU7YQOkVIFrgm+BXB8e
X-IronPort-AV: E=Sophos;i="4.80,715,1344211200"; d="scan'208";a="138980874"
Received: from ([]) by with ESMTP; 05 Nov 2012 18:04:51 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id qA5I4ov8026412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 18:04:50 GMT
Received: from ([fe80::747b:83e1:9755:d453]) by ([]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 12:04:50 -0600
From: "Ali C. Begen (abegen)" <>
To: Ralph Giles <>
Thread-Topic: [video-codec] Storage format (Re: Proposed charter)
Thread-Index: AQHNu2zCd3g8s8763UOLsAWGakbei5fbyc+AgAAe94CAAAULAA==
Date: Mon, 05 Nov 2012 18:04:50 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--41.393200-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Harald Alvestrand <>, "" <>
Subject: Re: [video-codec] Storage format (Re: Proposed charter)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Video codec BoF discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Nov 2012 18:04:55 -0000

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

>On 12-11-05 7:55 AM, Ali C. Begen (abegen) wrote:
>> 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.
>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".

>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?

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


> -r