Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#7104 closed enhancement (fixed)

Can't set video stream handler_name on qtrle : compat broblem with broadcast hardware

Reported by: NNois Owned by:
Priority: wish Component: avformat
Version: git-master Keywords: mov
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

ffmpeg N-90414-gabf35afb6f

Hi, some broadcast hardware require the handler_name to be "Apple Alias Data Handler"

setting handler_name or just handler doesn't make it

example of metadata

-c:v qtrle -pix_fmt bgra -g 1 -filter_complex "setfield=tff" -flags +ildct -acodec pcm_s16le -metadata major_brand="qt" -metadata compatible_brands="qt" -metadata:s:v:0 encoder="Animation" -metadata:s:v:0 handler_name="Apple Alias Data Handler" -metadata:s:v:0 handler_name="Apple Alias Data Handler"

Change History (9)

comment:1 by Carl Eugen Hoyos, 3 years ago

Component: undeterminedavformat
Keywords: mov added; qtrle animation quicktime removed
Priority: normalwish
Type: defectenhancement
Version: unspecifiedgit-master

Which hardware needs this?
How did you verify that the handler_name is the only issue?

comment:2 by Carl Eugen Hoyos, 3 years ago

Resolution: fixed
Status: newclosed

I believe this was fixed by Gyan Doshi in 830695be366ff753a3f7b8dd97c10d3e6187d41c

comment:3 by Gyan, 3 years ago

There's a hitch when writing MOVs. Two hdlr atoms are written. Once, within mdia and then within minf. The specified handler name is correctly written in the mdia child atom, as can be confirmed with any atom parser, like movdump. But when writing hdlr within minf, the track object isn't passed on* and hence the metadata isn't used. So the generic value of DataHandler gets written.

When ffmpeg demuxes a MOV, the minf is processed after mdia and so the handler name metadata key is reset with the generic value.

*this has been the case since the original code was added in 2003. I thought of changing it, but close to 100 FATE references would need to be updated. That's tedious but I'm ready to carry that out (will take some time) if other devs don't object.

Last edited 3 years ago by Gyan (previous) (diff)

in reply to:  3 comment:4 by Carl Eugen Hoyos, 3 years ago

Replying to Gyan:

I thought of changing it, but close to 100 FATE references would need to be updated. That's tedious but I'm ready to carry that out (will take some time) if other devs don't object.

Why is it tedious?

comment:5 by Gyan, 3 years ago

I'll have to confirm that all affected refs have changed hash just due to changes in that string and nothing else.

in reply to:  5 comment:6 by Carl Eugen Hoyos, 3 years ago

Replying to Gyan:

I'll have to confirm that all affected refs have changed hash just due to changes in that string and nothing else.

No, it is sufficient to send a patch for review.

comment:7 by Gyan, 3 years ago

Ok, will send one this weekend. Thanks.

Note: See TracTickets for help on using tickets.