-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add block additional mapping for generic type/value #353
base: master
Are you sure you want to change the base?
Add block additional mapping for generic type/value #353
Conversation
fa0db41
to
2c716ac
Compare
2c716ac
to
3184d65
Compare
3184d65
to
e247a99
Compare
|
||
### Key Value Pair Description | ||
|
||
The Block Additional Mapping for a `Key Value Pair` provides a generic method store data with a label in association with a Block. The label (referred to here as the `Key`) is stored within the `BlockAddIDExtraData` Element and the associate `Value` is stored within the corresponding BlockMore Element. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
method to store ?
|
||
### BlockAddIDType | ||
|
||
The BlockAddIDType value reserved for timecode is 107. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it related to timecodes only of it could be used for anything ? If so which timecode format can use this ?
We can only have one Block Additional mapping with the BlockAddIDType
(107) per track. Otherwise it would be impossible to tell the to which the BlockMore
data belong to. So this format makes a loosely typed Block Addition but with a single possible use per track. And yet it doesn't tell how to interpret the data. So I'm not sure it's really useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Poke on this.
If I understand this PR correctly, there would not be a way to associate more than a single key/value pair with each frame. That I definitely don't like. Additionally we don't have a way of associating a |
In FFmpeg packets can have AV_PKT_DATA_STRINGS_METADATA side data, a list of zero terminated key/value strings. The whole side data is externally framed. Putting such a thing (or something similar; i.e. the strings could be length-prefixed (probably with EBML numbers)) in a Another way to overcome this restriction would be to allow several |
IMO the FFmpeg usage sounds like the "key/value" type is too broad. It's a way to store the data, but it doesn't say what the data correspond to. There might be different systems using the same key. It should be a |
…ttps://github.com/Matroska-Org/matroska-specification into add-block-additional-mapping-for-generic-type/value
This is based upon the timecode branch, but this offers a generic key/value structure for side data. For discussion.