Skip to content
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

Open
wants to merge 11 commits into
base: master
Choose a base branch
from

Conversation

dericed
Copy link
Contributor

@dericed dericed commented Oct 27, 2019

This is based upon the timecode branch, but this offers a generic key/value structure for side data. For discussion.

@robUx4 robUx4 added format addition spec_codecs Codec Matroska spec document target labels Nov 3, 2019
@dericed dericed force-pushed the add-block-additional-mapping-for-generic-type/value branch from fa0db41 to 2c716ac Compare November 21, 2019 15:13
@robUx4 robUx4 force-pushed the add-block-additional-mapping-for-generic-type/value branch from 2c716ac to 3184d65 Compare March 1, 2020 14:48
@robUx4 robUx4 force-pushed the add-block-additional-mapping-for-generic-type/value branch from 3184d65 to e247a99 Compare June 7, 2020 11:33

### 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.
Copy link
Contributor

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.
Copy link
Contributor

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Poke on this.

@robUx4 robUx4 mentioned this pull request Apr 4, 2021
@robUx4 robUx4 linked an issue Apr 4, 2021 that may be closed by this pull request
@mbunkus
Copy link
Contributor

mbunkus commented May 30, 2021

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 BlockMore with a certain frame inside the BlockGroup. Either we add one (via a new frame-number-in-block element inside BlockMore), or we mention explicitly that a BlockMore applies to all frames in the BlockGroup's Block, and that writers that want to associate the BlockMore with a specific frame only would need to limit the number of frames in the Block to 1. Or we could spec that the BlockMore is always associated with the first frame only.

@mkver
Copy link
Contributor

mkver commented Aug 23, 2021

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 BlockAdditional would overcome the restriction to a single key-value pair; but it would have the downside that key would have to repeated every time.

Another way to overcome this restriction would be to allow several BlockAdditionalMappings with the same BlockAddIDType, but different BlockAddIDValue. Each of these would have its own key.

@robUx4
Copy link
Contributor

robUx4 commented Aug 24, 2021

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 BlockAddIDType per usage (one would be for FFmpeg) and then saying it's using key/value storage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
format addition spec_codecs Codec Matroska spec document target
Projects
None yet
Development

Successfully merging this pull request may close these issues.

support frame side data
4 participants