5.3Action Points
6MPEG-4 Conformance (14496-4) 6.1Topics
6.2Contributions
None
6.3Action Points
7MPEG-4 Reference Software (14496-5) 7.1Topics 7.1.1ISO/IEC 14496-5:2007 AMD 23 Sythesized Texture Reference Software
7.2Contributions
None
7.3Action Points
8MPEG-4 BIFS (14496-11) 8.1Topics 8.1.1ISO/IEC 14496-11:2002 AMD X Digital Radio Profile
8.2Contributions
Session
|
Number
|
Title
|
Source
|
General
|
m16465
|
BiFS-based solution and its deployment within the FP7 MobiThin project: event handling and streaming
|
Bojan JOVESKI
Mihai MITREA
Pieter SIMOENS
Iain-James MARSHALL
Françoise PRETEUX
|
m16465 Not presented.
8.3Action Points
9MPEG-4 ISO Base File Format (14496-12) 9.114496-12/COR 2 Usage of brands and box order in sample entry 9.1.1ISO/IEC 14496-12:2008 COR 2 Usage of brands and box order in sample entry 9.1.3ISO/IEC 14496-12:2008 COR 3 Minor Corrections
9.2Contributions
Session
|
Number
|
Title
|
Source
|
|
File Format
|
m16263
|
Summary of Voting on ISO/IEC 14496-12:2008/FPDAM 1
|
SC 29 Secretariat
|
File Format
|
m16359
|
Minor or editorial errors in the Part 12 amendment
|
David Singer
|
File Format
|
m16367
|
Clarification of track header in ISO media file format
|
Teruhiko Suzuki
|
File Format
|
m16392
|
Adaptive Progressive Download
|
Per Fröjdh
Torbjörn Einarsson
Clinton Priddle
|
File Format
|
m16393
|
File format sub-track selection and switching
|
Per Fröjdh
Andrey Norkin
Clinton Priddle
| 9.2.1m16263 Summary of Voting on ISO/IEC 14496-12:2008/FPDAM 1
Thank you to the NBs for these detailed, helpful, comments.
We also reviewed the editor’s comments, notes, and other arcana in the document.
9.2.2m16367 Clarification of track header in ISO media file format
Thank you, but we hope that this was covered in DCOR3, which is out for ballot. Comments on DCOR3 to improve its clarity would, of course, be welcome.
9.2.3m16359 Minor or editorial errors in the Part 12 amendment
Thank you, the editors will deal with these.
9.2.4m16392 Adaptive Progressive Download
Thank you. This seems to relate to Modern Media Transport. There are some concerns here: for example, this presumes an intelligent HTTP server (really, an adaptive media server that happens to use HTTP for transport, rather than a general HTTP server). This proposal isn’t oriented towards the client choosing which parts it wants, and doing byte-range requests for the areas of the file it wants (as covered in academic papers, such as http://www.zju.edu.cn/jzus/2006/A06S1/A06S118.pdf). When doing byte-range requests, there is of course the (minor?) issue that the byte-range read by the client issues for the moov and each moof box has to be estimated. Also, under this proposal the bytes received could be written as a file and constitute a valid MP4 file, whereas byte-range scatter-gather results in an incomplete (unrecordable) file, or at least a file that would need padding bytes to keep everything in the same place. Do we need to add functionality to the ISO file format for HTTP-streaming, or is it time for a stream format that is ISO file friendly (which we’ll discuss tomorrow)? 3GPP SA4 is working in this area as well; we should make sure we communicate appropriately.
On this and the following contribution, some delegates asked for time to study both the use cases and the proposal, and the proponent graciously agreed to re-present these in the next meeting.
Dostları ilə paylaş: |
