* Re: [FFmpeg-devel] [PATCH] avformat/mov: Store trak > udta metadata on each stream
[not found] <20250115104018.3605561-1-rbernon@codeweavers.com>
@ 2025-02-04 13:49 ` Martin Storsjö
2025-02-11 14:47 ` Martin Storsjö
0 siblings, 1 reply; 2+ messages in thread
From: Martin Storsjö @ 2025-02-04 13:49 UTC (permalink / raw)
To: FFmpeg development discussions and patches; +Cc: Rémi Bernon, jamrial
Hi Rémi,
On Wed, 15 Jan 2025, Rémi Bernon wrote:
> Some files keep extra metadata such as 'name' fields within udta, and
> it is useful for Wine to access them with the "export_all" option so
> they can then be exposed to Windows applications.
>
> Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
> ---
> libavformat/mov.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index c016ce8e41..f067ca4905 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -354,6 +354,12 @@ static int mov_read_udta_string(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> int (*parse)(MOVContext*, AVIOContext*, unsigned, const char*) = NULL;
> int raw = 0;
> int num = 0;
> + AVDictionary **metadata;
> +
> + if (c->trak_index >= 0 && c->trak_index < c->fc->nb_streams)
> + metadata = &c->fc->streams[c->trak_index]->metadata;
> + else
> + metadata = &c->fc->metadata;
>
> switch (atom.type) {
> case MKTAG( '@','P','R','M'): key = "premiere_version"; raw = 1; break;
> @@ -572,10 +578,10 @@ retry:
> str[str_size] = 0;
> }
> c->fc->event_flags |= AVFMT_EVENT_FLAG_METADATA_UPDATED;
> - av_dict_set(&c->fc->metadata, key, str, 0);
> + av_dict_set(metadata, key, str, 0);
> if (*language && strcmp(language, "und")) {
> snprintf(key2, sizeof(key2), "%s-%s", key, language);
> - av_dict_set(&c->fc->metadata, key2, str, 0);
> + av_dict_set(metadata, key2, str, 0);
> }
> if (!strcmp(key, "encoder")) {
> int major, minor, micro;
> --
> 2.45.2
So instead of storing metadata on the demuxer level, it is stored on the
stream level, to avoid clobbering metadata if multiple streams provide
metadata with the same name.
I guess that sounds reasonable. However, wouldn't this be a notable change
for consumers that currently expect to see such metadata on the demuxer
level?
I guess we don't have any firm guarantees about such things, and if the
metadata specifically is for a track, it is the more correct thing to do
anyway.
I don't have all the usual cases around mov/mp4 metadata fresh in mind
though. CCing James to hear his opinion on this.
// Martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [FFmpeg-devel] [PATCH] avformat/mov: Store trak > udta metadata on each stream
2025-02-04 13:49 ` [FFmpeg-devel] [PATCH] avformat/mov: Store trak > udta metadata on each stream Martin Storsjö
@ 2025-02-11 14:47 ` Martin Storsjö
0 siblings, 0 replies; 2+ messages in thread
From: Martin Storsjö @ 2025-02-11 14:47 UTC (permalink / raw)
To: FFmpeg development discussions and patches; +Cc: Rémi Bernon, jamrial
On Tue, 4 Feb 2025, Martin Storsjö wrote:
> Hi Rémi,
>
> On Wed, 15 Jan 2025, Rémi Bernon wrote:
>
>> Some files keep extra metadata such as 'name' fields within udta, and
>> it is useful for Wine to access them with the "export_all" option so
>> they can then be exposed to Windows applications.
>>
>> Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
>> ---
>> libavformat/mov.c | 10 ++++++++--
>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index c016ce8e41..f067ca4905 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -354,6 +354,12 @@ static int mov_read_udta_string(MOVContext *c,
>> AVIOContext *pb, MOVAtom atom)
>> int (*parse)(MOVContext*, AVIOContext*, unsigned, const char*) = NULL;
>> int raw = 0;
>> int num = 0;
>> + AVDictionary **metadata;
>> +
>> + if (c->trak_index >= 0 && c->trak_index < c->fc->nb_streams)
>> + metadata = &c->fc->streams[c->trak_index]->metadata;
>> + else
>> + metadata = &c->fc->metadata;
>>
>> switch (atom.type) {
>> case MKTAG( '@','P','R','M'): key = "premiere_version"; raw = 1; break;
>> @@ -572,10 +578,10 @@ retry:
>> str[str_size] = 0;
>> }
>> c->fc->event_flags |= AVFMT_EVENT_FLAG_METADATA_UPDATED;
>> - av_dict_set(&c->fc->metadata, key, str, 0);
>> + av_dict_set(metadata, key, str, 0);
>> if (*language && strcmp(language, "und")) {
>> snprintf(key2, sizeof(key2), "%s-%s", key, language);
>> - av_dict_set(&c->fc->metadata, key2, str, 0);
>> + av_dict_set(metadata, key2, str, 0);
>> }
>> if (!strcmp(key, "encoder")) {
>> int major, minor, micro;
>> --
>> 2.45.2
>
> So instead of storing metadata on the demuxer level, it is stored on the
> stream level, to avoid clobbering metadata if multiple streams provide
> metadata with the same name.
>
> I guess that sounds reasonable. However, wouldn't this be a notable change
> for consumers that currently expect to see such metadata on the demuxer
> level?
>
> I guess we don't have any firm guarantees about such things, and if the
> metadata specifically is for a track, it is the more correct thing to do
> anyway.
>
> I don't have all the usual cases around mov/mp4 metadata fresh in mind
> though. CCing James to hear his opinion on this.
I discussed this with James on irc, and he pointed out that udta can exist
both on the top level and within the track boxes. And this patch does the
right thing wrt that, as trak_index is >= 0 while parsing a trak,
otherwise it's < 0.
So this patch seems correct here, so I'll go ahead and push it.
// Martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2025-02-11 14:48 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20250115104018.3605561-1-rbernon@codeweavers.com>
2025-02-04 13:49 ` [FFmpeg-devel] [PATCH] avformat/mov: Store trak > udta metadata on each stream Martin Storsjö
2025-02-11 14:47 ` Martin Storsjö
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git