Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
* 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