WIP: libavformat/matroskadec.c: export profile container metadata #21787

Draft

toots wants to merge 1 commit from toots/matroska-webm-profile into master AGit

pull from: toots/matroska-webm-profile

merge into: FFmpeg:master

FFmpeg:master

FFmpeg:release/8.1

FFmpeg:release/8.0

FFmpeg:release/4.4

FFmpeg:release/7.0

FFmpeg:release/7.1

FFmpeg:release/4.3

FFmpeg:release/5.0

FFmpeg:release/5.1

FFmpeg:release/6.0

FFmpeg:release/6.1

FFmpeg:release/4.2

FFmpeg:release/3.4

FFmpeg:release/2.8

FFmpeg:release/4.1

FFmpeg:release/4.0

FFmpeg:release/3.2

FFmpeg:release/3.3

FFmpeg:release/3.0

FFmpeg:release/3.1

FFmpeg:release/2.4

FFmpeg:release/2.7

FFmpeg:release/2.6

FFmpeg:release/2.5

FFmpeg:release/2.0

FFmpeg:release/2.1

FFmpeg:release/2.2

FFmpeg:release/2.3

FFmpeg:release/1.2

FFmpeg:release/0.5

FFmpeg:release/0.6

FFmpeg:release/0.7

FFmpeg:release/0.8

FFmpeg:release/0.9

FFmpeg:release/0.10

FFmpeg:release/0.11

FFmpeg:release/1.0

FFmpeg:release/1.1

FFmpeg:oldabi

Conversation 7 Commits 1 Files changed 9 +23 -4

toots commented 2026-02-18 17:42:21 +00:00

Member

Copy link

It looks like it is not currently possible to distinguish between matroska and webm when working with AVFormatContext and AVInputFormat.

This PR adds a "doctype" metadata to the demuxer's metadata that can be used to make such distinction at runtime.

It looks like it is not currently possible to distinguish between `matroska` and `webm` when working with `AVFormatContext` and `AVInputFormat`. This PR adds a `"doctype"` metadata to the demuxer's metadata that can be used to make such distinction at runtime.

toots requested review from Gyan Doshi 2026-02-18 17:42:22 +00:00

ffmpeg-devel added the

avformat

new

labels 2026-02-18 17:42:35 +00:00

toots changed title from libavformat/matroskadec.c: export profile container metadata to to libavformat/matroskadec.c: export profile container metadata 2026-02-18 17:42:40 +00:00

mkver commented 2026-02-18 18:08:19 +00:00

Contributor

Copy link

What is this information supposed to be good for?

Exporting this as metadata is problematic, because simply remuxing a matroska/webm file into a container (like Matroska) that supports the "profile" metadata (i.e. writes it) will add a such metadata from the demuxer, although it is likely wrong for the muxer. This is likely why fate doesn't pass for your commit.

What is this information supposed to be good for? Exporting this as metadata is problematic, because simply remuxing a matroska/webm file into a container (like Matroska) that supports the "profile" metadata (i.e. writes it) will add a such metadata from the demuxer, although it is likely wrong for the muxer. This is likely why fate doesn't pass for your commit.

toots force-pushed toots/matroska-webm-profile from 518aaeb592 to 9271f9ca75 2026-02-18 18:19:42 +00:00 Compare

toots commented 2026-02-18 18:23:37 +00:00

Author

Member

Copy link

@mkver wrote in #21787 (comment):

What is this information supposed to be good for?

Exporting this as metadata is problematic, because simply remuxing a matroska/webm file into a container (like Matroska) that supports the "profile" metadata (i.e. writes it) will add a such metadata from the demuxer, although it is likely wrong for the muxer. This is likely why fate doesn't pass for your commit.

Yes this is the reason. I just pushed a change to exclude it from the muxer.

In the application I'm looking at, we want to be able to know the exact format to initialize a new output from a AVFormatContext and be specific regarding the underlying container.

The same issue exists with mov,mp4 etc. In this case, the metadata major_brand can be used so it felt natural to also use a metadata in this case.

Happy to consider other methods.

@mkver wrote in https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21787#issuecomment-26231: > What is this information supposed to be good for? > > Exporting this as metadata is problematic, because simply remuxing a matroska/webm file into a container (like Matroska) that supports the "profile" metadata (i.e. writes it) will add a such metadata from the demuxer, although it is likely wrong for the muxer. This is likely why fate doesn't pass for your commit. Yes this is the reason. I just pushed a change to exclude it from the muxer. In the application I'm looking at, we want to be able to know the exact format to initialize a new output from a `AVFormatContext` and be specific regarding the underlying container. The same issue exists with `mov,mp4` etc. In this case, the metadata `major_brand` can be used so it felt natural to also use a metadata in this case. Happy to consider other methods.

toots force-pushed toots/matroska-webm-profile from 9271f9ca75 to ae24bfcf33 2026-02-18 18:34:33 +00:00 Compare

ffmpeg-devel added the

swscale

label 2026-02-18 18:34:47 +00:00

toots force-pushed toots/matroska-webm-profile from ae24bfcf33 to e49c3fcb1a 2026-02-18 18:40:40 +00:00 Compare

toots force-pushed toots/matroska-webm-profile from e49c3fcb1a to 84b5740fb0 2026-02-18 19:04:12 +00:00 Compare

toots commented 2026-02-18 19:06:14 +00:00

Author

Member

Copy link

@mkver and, yes, the same metadata leak happens when re-encoding to e.g. ogg from mp4:

% ffprobe /tmp/bla.ogg                                                                                                                                13:04:41
...
Input #0, ogg, from '/tmp/bla.ogg':
  Duration: 00:00:03.00, start: 0.000000, bitrate: 227 kb/s
  Stream #0:0(und): Video: theora, yuv420p, 854x480 [SAR 1:1 DAR 427:240], 30 tbr, 30 tbn
    Metadata:
      encoder         : Lavc62.11.100 libtheora
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
      major_brand     : isom
      minor_version   : 512
      compatible_brands: isomiso2avc1mp41

If you have any suggestion for a better approach, I'd be interested to hear.

@mkver and, yes, the same metadata leak happens when re-encoding to e.g. `ogg` from `mp4`: ```shell % ffprobe /tmp/bla.ogg 13:04:41 ... Input #0, ogg, from '/tmp/bla.ogg': Duration: 00:00:03.00, start: 0.000000, bitrate: 227 kb/s Stream #0:0(und): Video: theora, yuv420p, 854x480 [SAR 1:1 DAR 427:240], 30 tbr, 30 tbn Metadata: encoder : Lavc62.11.100 libtheora handler_name : VideoHandler vendor_id : [0][0][0][0] major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 ``` If you have any suggestion for a better approach, I'd be interested to hear.

James Almer commented 2026-02-19 01:07:12 +00:00

Owner

Copy link

Metadata may be the only feasible way to export this, but not as a "profile" key. Maybe "doctype" instead, much like mp4/mov export handler_name and *_brand.

Metadata may be the only feasible way to export this, but not as a "profile" key. Maybe "doctype" instead, much like mp4/mov export handler_name and *_brand.

👍 1

ffmpeg-devel removed the

new

label 2026-02-19 01:07:26 +00:00

toots force-pushed toots/matroska-webm-profile from 84b5740fb0 to 187818d7a6 2026-02-19 12:01:24 +00:00 Compare

toots force-pushed toots/matroska-webm-profile from 187818d7a6 to 72eaca523d 2026-02-19 12:01:41 +00:00 Compare

toots force-pushed toots/matroska-webm-profile from 72eaca523d to dcb82456c4 2026-02-19 12:45:28 +00:00 Compare

mkver commented 2026-02-19 12:55:22 +00:00

Contributor

Copy link

a) Run FATE locally and send patches that actually pass FATE.
b) Using "doctype" is still unacceptable: It makes it impossible to write a doctype tag into Matroska and doctype tags will leak into other containers.

a) Run FATE locally and send patches that actually pass FATE. b) Using "doctype" is still unacceptable: It makes it impossible to write a doctype tag into Matroska and doctype tags will leak into other containers.

James Almer commented 2026-02-19 12:57:46 +00:00

Owner

Copy link

@mkver wrote in #21787 (comment):

b) Using "doctype" is still unacceptable: It makes it impossible to write a doctype tag into Matroska and doctype tags will leak into other containers.

Then a proper way to signal this kind of information is needed, and implemented in mp4 too in order to also not leak the aforementioned tags into other containers.

@mkver wrote in https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21787#issuecomment-26307: > b) Using "doctype" is still unacceptable: It makes it impossible to write a doctype tag into Matroska and doctype tags will leak into other containers. Then a proper way to signal this kind of information is needed, and implemented in mp4 too in order to also not leak the aforementioned tags into other containers.

👍 1

toots commented 2026-02-19 12:58:52 +00:00

Author

Member

Copy link

@mkver wrote in #21787 (comment):

a) Run FATE locally and send patches that actually pass FATE.

This is proving difficult on mac but I'll have another pass.

b) Using "doctype" is still unacceptable: It makes it impossible to write a doctype tag into Matroska and doctype tags will leak into other containers.

Tags already leak into other containers as exemplified above.

I'm not attached to any particular name but doctype works great for me because it is actually a technically accurate description of the value that's exported.

Re: tag leak, I think that it should be a different effort. I wrote on IRC about maybe using tags attached to dictionary values, somthing like: AV_DICT_INTERNAL that would prevent values with such tags from being re-exported.

Happy to get feedback on that!

@mkver wrote in https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21787#issuecomment-26307: > a) Run FATE locally and send patches that actually pass FATE. This is proving difficult on mac but I'll have another pass. > b) Using "doctype" is still unacceptable: It makes it impossible to write a doctype tag into Matroska and doctype tags will leak into other containers. Tags already leak into other containers as exemplified above. I'm not attached to any particular name but `doctype` works great for me because it is actually a technically accurate description of the value that's exported. Re: tag leak, I think that it should be a different effort. I wrote on IRC about maybe using tags attached to dictionary values, somthing like: `AV_DICT_INTERNAL` that would prevent values with such tags from being re-exported. Happy to get feedback on that!

toots changed title from libavformat/matroskadec.c: export profile container metadata to WIP: libavformat/matroskadec.c: export profile container metadata 2026-02-21 01:34:51 +00:00

mkver referenced this pull request 2026-03-15 11:59:40 +00:00

Add myself as maintainer to the various ogg files. #20961

Some checks failed

Hide all checks

Lint / Pre-Commit (pull_request) Successful in 29s

Required

Details

Test / Fate (linux-aarch64, static, 64 bit) (pull_request) Failing after 7m29s

Required

Details

Test / Fate (linux-amd64, shared, 64 bit) (pull_request) Failing after 11m19s

Required

Details

Test / Fate (linux-amd64, static, 32 bit) (pull_request) Failing after 11m53s

Required

Details

Test / Fate (Full, wine) (pull_request) Failing after 25m26s

Required

Details

Autolabel / Labeler (pull_request_target) Has been skipped

Details

This pull request has changes conflicting with the target branch.

• doc/APIchanges

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin +refs/pull/21787/head:toots/matroska-webm-profile

git switch toots/matroska-webm-profile

Sign in to join this conversation.

Reviewers

No reviewers

Gyan Doshi

Labels

Clear labels   

avcodec

libavcodec related issues and PRs

  

avdevice

libavdevice related issues and PRs

  

avfilter

libavfilter related issues and PRs

  

avformat

libavformat related issues and PRs

  

avutil

libavutil related issues and PRs

  

CLI

ffmpeg, ffprobe or ffplay related issues and PRs

  

doc

documentation-related

  

swresample

libswresample related issues and PRs

  

swscale

libswscale related issues and PRs

  

vulkan

Vulkan related issues and PRs

  

API

Introduces new API that warants a minor bump

  

API major

Changes the API in a major way, likely needing a major bump

  

bug

Issue reports a bug, i.e. something is not working the way it should

  

duplicate

This issue or pull request already exists

  

enhancement

New feature

  

fix/bug

Fixes a bug

  

fix/regression

Fixes a regression

  

GSoC

Google Summer of Code

  

GSoC-Qualification

Google Summer of Code Qualification Task

  

help wanted

Need some help

  

important

Important issue/PR that needs attention

  

invalid

Something is wrong

  

LGTM

Looks good to merge

  

meta

Non code-related issue/PR

  

needs backport

Pull request needs to be backported

  

needs docs

More documentation is needed

  

needs fate test

Patch needs additional fate tests

  

needs sample

Issue/PR requires additional samples

  

needs testing

Further manual testing is needed

  

new

New issue/PR, needs developer review

  

question

More information is needed

  

regression

Issue reports a regression

  

security

Security related issue/PR

  

wontfix

This won't be fixed

No labels

avcodec

avdevice

avfilter

avformat

avutil

CLI

doc

swresample

swscale

vulkan

API

API major

bug

duplicate

enhancement

fix/bug

fix/regression

GSoC

GSoC-Qualification

help wanted

important

invalid

LGTM

meta

needs backport

needs docs

needs fate test

needs sample

needs testing

new

question

regression

security

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

3 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

FFmpeg/FFmpeg!21787

No description provided.