mp4ra / mp4ra.github.io Goto Github PK

14496-12 defines aux_info_type (in saio, and saiz) as a 4CC defining the type of auxiliary information. It is used by the Common Encryption specification, which reserves schemes like cenc. It'd be good to have an entry in the MP4RA for tracking all values that are used.

We need to add a TravisCI script that checks when someone makes a PR to make sure that the PR cannot be merged if one of the following criteria applies:

• it's touching the JS or HTML
• it's removing something from a CSV
• there's already an entry with that value in the CSV

The TravisCI integration is easy. The writing of the checks needs work.

This would avoid warning from GitHub that the CNAME is alreay taken when commits are pushed.

'iloc' is listed in the "track reference" category (https://mp4ra.org/#/track_references#) as follows:

iloc Item data location (item reference) ISO

It is not defined as a track reference. Either the ISOBMFF should list it explicitely as a possible track reference, or it should be removed from this list. It already correctly listed in the item reference list (https://mp4ra.org/#/item_references).

Describe the bug

specifications.csv and hence the references page cite ISO/IEC 14496-12:2004 (and 15444-12:2004) for the ISO base media file format and note that they are available as a publicly available standard from ISO. MPEG-4 Part 12 has been updated several times since 2004, the last time in December 2020, and it is not a Publicly Available Standard either yet or anymore. JPEG 2000 Part 12 has been withdrawn in 2015.

To Reproduce

Steps to reproduce the behavior:

1. Go to https://mp4ra.org/#/references
2. Go to the row with name column entry ISO
3. Click on the second link provided there, leading to http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
4. Try to find any edition of ISO/IEC 14496-12 (MPEG-4) or ISO/IEC 15444-12 (JPEG 2000) there
5. Find no result

Expected behavior

If the standard should still be available freely to the public, ISO or the respective Maintenance Agency (which is Apple Inc. in this case) should actually list and publish it on the linked page.
Otherwise the link and note should be removed.

The RA is almost certainly out of date wrt 14496-15

There is no category on the MP4RA for Track Group Types. We currently have 3 types:

• 'msrc' (part 12)
• 'cstg' (part 15)

Since June 15th, 2021, the building on travis-ci.org is ceased so the automatic deployments do not work anymore.

Looks like we have 2 options to solve this:

• Switch to travis-ci.com
• Switch to GitHub actions

Any ideas?

For example, search for auxv or sdsm, it returns an empty category instead of 'handler'.

We should probably get started adding the CMAF brands. In addition to the ones in the published 23000-19, we have the amendments and 3rd party ones that will be starting to queue up with increasing probability of collision. Is it worth organizing them in a CMAF subsection under brands? A subsection for CMAF Supplemental Data? Or are they all just "brands"?

In some parts of the page WG11 (MPEG) is mentioned and we should fix that.

But vue.js has stolen the fragment part of the URL...

JKS$20
jpvs
jpvi
jxpl
bmdm
dmon
jptp
Exif
jxsH

as sent to the RA

These OTI's are not actually defined and not in use. They should be deprecated.

Some suggestions for a README...

1. Note that everything is under "CSV".
2. Note that if there if a new reference spec is needed for a new entry, then add that first in "specifications.csv"
3. Make the CSV filenames match the website labels exactly.
4. Clarify the specification linkage field (see #5 )

All DECE specifications are no longer available at www.uvvu.com and any contact information is no longer valid.

Name

MPEG

Address

No response

URL

No response

Kind

Sample Entry Types

Identifier (four-character code)

ipcm,fpcm

Specification

No response

Abstract

From: #167

"Information technology — MPEG audio technologies — Part 5: Uncompressed audio in MPEG-4 file format" specifies several code points that should be registered:
sample entry box:

• pcmC
  codecs:
• ipcm
• fpcm

Name, Title, Organization

MPEG

Email

No response

Phone

No response

Address

No response

Date of Definition

No response

Statement of Intention

No response

The colr entry at CSV/item-properties.csv duplicates that at CSV/sample-entries-boxes.csv. The defining specification for the former explicitly states that The colour information 'colr' descriptive item property has the same syntax as the ColourInformationBox as defined in [the latter]

This spec is correct and was updated not terribly long ago: http://mp4ra.org/specs.html#MLP
This spec is not correct (an old version): https://mp4ra.github.io/mp4ra/specs.html#MLP
This can be updated of course in github, but it implies that the two databases are not in sync.

We have not entered HEIF code points in the RA yet

mvdr is regisered and described as MVDDepthResolutionBox. However, in Part 15 there is no mvdr defined and MVDDepthResolutionBox is defined as:

class MVDDepthResolutionBox extends Box('3dpr') {...}

I guess we should change mvdr to 3dpr.

Name

Alliance for Open Media

Address

No response

URL

https://aomedia.org/

Kind

Sample Entry Types

Identifier (four-character code)

iamf

Specification

https://aomediacodec.github.io/iamf/

Abstract

Immersive Audio Model and Formats - Encapsulated IA Sequence

Name, Title, Organization

Thomas Daede, Vimeo, Inc.

Email

No response

Phone

No response

Address

No response

Date of Definition

3 October 2023

Statement of Intention

A reference implementation exists, and implementors intend to ship in products.

find a better way to capture specifications. use non-dated version of specs, use JSON and group specs by SDO. This info can be useful in combination with the conformance framework.

Describe the bug
Search results for entity groups return results where the specification link is OK, but the category link is broken.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'https://mp4ra.org'
2. Click on 'Search'
3. Enter altr
4. Click on 'Entity Groups' in the search result
5. Note the empty page

Expected behavior
Clicking on 'Entity Groups' should take you to the entity groups results

Screenshots
N/A

Desktop (please complete the following information):

• OS: Linux
• Browser: Firefox
• Version: 104.0

Additional context
It might also be nice to have https://mp4ra.org/#/entity_group be a working link.

1. Name of the organization making the request: Dolby

Please send contact information for that organization, should questions arise at application time or in future, in email to mp4reg at group.apple.com.

2. statement of an intent to apply the code-points in practice: Currently in use.

3. For each code-point requested:

3.1 The type of value requested: Codecs

identify the table on the site in which your value should appear

3.2 The desired value (typically a four-character code): 'dav1'

This should not conflict with any existing or pending code-point visible at the publication site

3.3 Short description of the code-point's meaning: "AV1-related Dolby Vision consistent with ‘av01’"

example descriptions are on the site

3.4 Link to the documentation/specification: existing "Dolby Vision"

link to the place where more information about the code-point can be found (ideally, identification of a published defining specification or other document). If you link to contact information for requesting documentation, please be as specific as possible.

3.5 Any other values needed to complete the request: none

notably, any other data needed for the row of the table into which the code-point will be placed.

It seems that some of the 4CCs related to SVC and MVC do not belong to sample groups:

• svpr - PriorityRangeBox, containers=[scif, mvif]
• svdr - SVCDependencyRangeBox, containers=[scif]
• svip - InitialParameterSetBox, containers=[scif, mvif]
• rrgn - RectRegionBox, containers=[scif]
• ldep - TierDependencyBox, containers=[scif, mvif]
• iroi - IroiInfoBox, containers=[scif]
• tran - TranscodingInfoBox, containers=[scif]

All of those are actually boxes and not sample groups. They appear in actual sample groups scif or mvif VisualSampleGroupEntries. I guess these should be moved to boxes.csv?

Sort by spec, by 4CC, by handler type ...

it seems to be only half-integrated?

and have its code-points added (notably brands)

But removing the blank line at the end of the CSV file doesn't stick and doesn't work

The RA is almost certainly behind on 14496-12

Following protected sample entry codes are not yet registered:

• encu - XMLSubtitleSampleEntry
• encp - HapticSampleEntry
• enc3 - VolumetricVisualSampleEntry

as per request sent to the RA

The three DTS brands, dts1, dts2 and dts3 don't specifically mention that they are CMAF brands. This was always the intention. I would like to fix this with the following text update:
dts1: Indicates a CMAF compliant MP4 track with audio codecs dtsc, dtsh or dtse
dts2: Indicates a CMAF compliant MP4 track with audio codec dtsx
dts3: Indicates a CMAF compliant MP4 track with audio codec dtsy

Some boxes might be defined in one specification, and extended by other specifications.

For example, the Colour Specification box specified in ISO/IEC 15444-1 is extended by ISO/IEC 15444-2 and ISO/IEC 15444-15.

Suggest allowing multiple defining specifications.

"Information technology — MPEG audio technologies — Part 5: Uncompressed audio in MPEG-4 file format" specifies several code points that should be registered:
sample entry box:

• pcmC
  codecs:
• ipcm
• fpcm

As discussed during MPEG#140 we should consider adding links to other resources which are relevant, e.g.: conformance spec/files/github

While the RA has entries for MPEG-H 3D Audio sample entry types (e.g. mha1, mha2), it does not have an entry for the configuration box mhaC, while it has for other video codecs (avcC, vvcC, av1C). This seems like it should be added.

The current email submission template includes contact and other information not part of the public facing database. It is desirable I think to create a private section of the database that retains this information external to Apple.

See:

M4A$20 | iTunes MPEG-4 audio protected or not, | iTunes
  | can contain audio + video + 3g text track + chapter track |  
M4B$20 | iTunes AudioBook protected or not | iTunes
  | can contain audio + video + 3g text track + chapter track |  

These are defined in ETSI.

As discussed during MPEG 140:

We update the guidelines to ask for a (draft) Pull Request additional to the email when request a new code point

OK, but then what is the linkname field for?

I have a question.
Where are track references of types adda and adrc defined? mp4ra points to 23003-4 but I can not find them there.

Also note that AMD1 of 23003-4 mentions those being defined in Part 12. But this seems not to be true as there are no definitions for those in clauses 6.x.x.

In Part 12 adda is mentioned in clause 12.2.6 though. Is it considered to be defined in Part 12? If yes, we should probably add an entry in clause 8.3.3.3. And what about adrc?

There are a lot of metadata boxes in current use for audio and video files that apparently have never been registered, or are at least missing not documented at the MP4RA site (and in this repository). Many of them originate in Apple iTunes (or Quicktime), but are supported by other software as well, based upon reverse-engineered documentation I suppose. Some of these start with the copyright symbol, e.g. ©ART or ©nam, to mark them as private-use obviously, but others are not, e.g. stik, hdvd, tves or purl.

The following points are not clear to me:

1. Should all of these be registered, or just ones not starting with $a9?
2. Would registering them be possible at all without a formal and publicly available specification?
3. If a public specification is needed, but the vendor is not willing to release one, would it be acceptable to create and publish one elsewhere?
4. If so, would this require backing from a formal standardization body or a company, or could it be done as a collaborative open-source effort?

The MP4RA should be clearer about what is expected of boxes that are contained in a registered box.

For example, if a spec defines a box 'fooC' that can contain other boxes like 'barX' should you register only 'fooC' or also 'barX'. I think all boxes should be registered.

Some people seem to think that 'barX' does not need to be registered because it's only used inside 'fooC'. I don't think that's the right practice as then you risk having two 'barX' boxes with different content and parsers will have to carry context (am I parsing a barX box inside the fooC context or outside?).

1. Name of the organization making the request: Dolby

Please send contact information for that organization, should questions arise at application time or in future, in email to mp4reg at group.apple.com.

2. statement of an intent to apply the code-points in practice: This will be deployed shortly.

3. For each code-point requested:

3.1 The type of value requested: brand

identify the table on the site in which your value should appear

3.2 The desired value (typically a four-character code) 'cdm1'

This should not conflict with any existing or pending code-point visible at the publication site

3.3 Short description of the code-point's meaning: CMAF Media Profile - HEVC HDR10 w SCTE Dynamic Metadata App #1

example descriptions are on the site

3.4 Link to the documentation/specification: www.scte.org (SCTE 215-1-1)

link to the place where more information about the code-point can be found (ideally, identification of a published defining specification or other document). If you link to contact information for requesting documentation, please be as specific as possible.

3.5 Any other values needed to complete the request

notably, any other data needed for the row of the table into which the code-point will be placed.