Opened 3 years ago

Last modified 3 years ago

#4661 reopened enhancement

swscale support for V210 as a pixel format

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

Description

Currently V210 is only supported as an encoder/decode, not as a pixel format. That makes special cases necessary in applications using libavformat/libavcodec that deal with this format, where for other pixel formats the code works in a generic fashion. An example of where this is required is feeding the native Apple Prores 422 codec with input data.

Change History (15)

comment:1 Changed 3 years ago by compn

we need a sample, or a way to produce prores 422 with v210 colorspace for us to fix this.

comment:2 Changed 3 years ago by cehoyos

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

From FFmpeg pov, yuv422p10 == v210, I don't think we will implement more packed formats.

Feel free to explain your use case in more details, currently it seems you want a special case for v210 (instead of doing it as for everything else with libavformat).

comment:3 Changed 3 years ago by rmk

On the contrary, I consider V210 being an encoder the special case. In my case there is a piece of software that uses ffmpeg and other libraries for transcoding (among others Apple libs) and they happily coexist and work well together in a generic way, except for cases where there is no pixel format in ffmpeg like in the described cases in this ticket and 4662.

but if opinions are so strong in this regard, I will have to live with that. I just don't understand the reason (also see my last comment on 4662).

comment:4 follow-up: Changed 3 years ago by cehoyos

  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Version changed from unspecified to git-master

I strongly suggest we fix your issues with the Prores encoder instead, this will be less work and help more people.

comment:5 Changed 3 years ago by gjdfgh

Pixel formats in FFmpeg are required to be easily processable, which is not the case with V210. It thus isn't suitable to be added as a pixel format.

comment:6 follow-up: Changed 3 years ago by gjdfgh

PS: you can use the V210 raw encoder. V210 is treated as a codec because it is so relatively complex.

(A similar pattern can be seen on PCM audio: we don't support s24 etc., they're done as codecs.)

comment:7 in reply to: ↑ 4 ; follow-up: Changed 3 years ago by rmk

Replying to cehoyos:

I strongly suggest we fix your issues with the Prores encoder instead, this will be less work and help more people.

Would love to do that but not possible due to legal reasons.

comment:8 in reply to: ↑ 6 Changed 3 years ago by rmk

Replying to gjdfgh:

PS: you can use the V210 raw encoder. V210 is treated as a codec because it is so relatively complex.

(A similar pattern can be seen on PCM audio: we don't support s24 etc., they're done as codecs.)

OK, I am probably underestimating the problems this would cause in swscale and then will have to live with the special case in our code. Not a big problem. I just hadn't expected this. By that logic Y416 support (4662) would then have to be done by an encoder as well, I suppose.

comment:9 follow-up: Changed 3 years ago by richardpl

The Y416 can be done as pixel format.

comment:10 in reply to: ↑ 9 Changed 3 years ago by rmk

Replying to richardpl:

The Y416 can be done as pixel format.

Just out of curiosity: What is the difference here?

comment:11 follow-up: Changed 3 years ago by gjdfgh

With Y416 the pixels are easily addressable, while V210 is a packed nightmare.

comment:12 in reply to: ↑ 7 ; follow-up: Changed 3 years ago by cehoyos

Replying to rmk:

Replying to cehoyos:

I strongly suggest we fix your issues with the Prores encoder instead, this will be less work and help more people.

Would love to do that but not possible due to legal reasons.

Legal issues forbid you to report issues with our Prores encoder?

comment:13 in reply to: ↑ 12 ; follow-up: Changed 3 years ago by rmk

Replying to cehoyos:

Replying to rmk:

Replying to cehoyos:

I strongly suggest we fix your issues with the Prores encoder instead, this will be less work and help more people.

Would love to do that but not possible due to legal reasons.

Legal issues forbid you to report issues with our Prores encoder?

No, sorry, I should have been more specific. Legal issues forbid me to use the ffmpeg prores encoder at all because Apple is very touchy about companies claiming prores support and then using anything but an officially licensed encoder. I know that there are companies taking that risk but we will not.

Of course I will continue to report all ffmpeg issues I run into :-).

comment:14 in reply to: ↑ 11 Changed 3 years ago by rmk

Replying to gjdfgh:

With Y416 the pixels are easily addressable, while V210 is a packed nightmare.

So, how complicated it is to implement determines what it is api-wise (an encoder or a pixel format). OK, obviously a decision the maintainers have to make and then I will live with that, if that is their view on it, i.e. the final verdict. I can only say that for an api/library user this is something that makes their lives harder but of course it can be worked around, which is what I will continue to do then.

Thanks for the explanation.

comment:15 in reply to: ↑ 13 Changed 3 years ago by cehoyos

Replying to rmk:

Replying to cehoyos:

Replying to rmk:

Replying to cehoyos:

I strongly suggest we fix your issues with the Prores encoder instead, this will be less work and help more people.

Would love to do that but not possible due to legal reasons.

Legal issues forbid you to report issues with our Prores encoder?

No, sorry, I should have been more specific. Legal issues forbid me to use the ffmpeg prores encoder at all because Apple is very touchy about companies claiming prores support and then using anything but an officially licensed encoder. I know that there are companies taking that risk but we will not.

Thank you for the explanation!

Of course I will continue to report all ffmpeg issues I run into :-).

Thank you!

My suggestion is that you implement yuv4220p10 -> yuv422packed10 in libswscale and send a patch if you think this feature is missing.

Note: See TracTickets for help on using tickets.