Opened 6 months ago

Closed 3 months ago

Last modified 2 months 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 Changed 5 months ago by cehoyos

  • Component changed from undetermined to avformat
  • Keywords mov added; qtrle animation quicktime removed
  • Priority changed from normal to wish
  • Type changed from defect to enhancement
  • Version changed from unspecified to git-master

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

comment:2 Changed 3 months ago by cehoyos

  • Resolution set to fixed
  • Status changed from new to closed

I believe this was fixed by Gyan Doshi in 830695be366ff753a3f7b8dd97c10d3e6187d41c

comment:3 follow-up: Changed 3 months ago by Gyan

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 months ago by Gyan (previous) (diff)

comment:4 in reply to: ↑ 3 Changed 3 months ago by cehoyos

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 follow-up: Changed 3 months ago by Gyan

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

comment:6 in reply to: ↑ 5 Changed 3 months ago by cehoyos

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 Changed 3 months ago by Gyan

Ok, will send one this weekend. Thanks.

Note: See TracTickets for help on using tickets.