* Enforcing color profile
@ 2020-08-17 12:09 Stefan Witzel
2020-08-17 13:34 ` Hans Verkuil
0 siblings, 1 reply; 6+ messages in thread
From: Stefan Witzel @ 2020-08-17 12:09 UTC (permalink / raw)
To: linux-media
Hello,
I am not a V4L developer so if this is not the right place to bring up
the issue please tell me who to contact instead.
The page [1] documents a problem with a particular device "Elgato Cam
Link 4K" which provides various format options among which most software
does not consciously pick the one which it implicitly expects leading to
problems. There is a software workaround, transcoding and looping
through a virtual device and a hardware fix flashing the problematic
profiles away.
However it appears to me that the most satisfactory solution is hinted
at in the sentence
> I couldn't find any option in V4L to force selection of 'YUYV 4:2:2', so instead
So my question is: what changes would be necessary to allow v4l2-ctl to
enforce a particular format and who would be the right person to ask to
make such changes?
Best regards,
Stefan
[1] https://assortedhackery.com/patching-cam-link-to-play-nicer-on-linux/
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Enforcing color profile 2020-08-17 12:09 Enforcing color profile Stefan Witzel @ 2020-08-17 13:34 ` Hans Verkuil 2020-08-17 14:50 ` Stefan Witzel 0 siblings, 1 reply; 6+ messages in thread From: Hans Verkuil @ 2020-08-17 13:34 UTC (permalink / raw) To: Stefan Witzel, linux-media On 17/08/2020 14:09, Stefan Witzel wrote: > Hello, > > I am not a V4L developer so if this is not the right place to bring up > the issue please tell me who to contact instead. > The page [1] documents a problem with a particular device "Elgato Cam > Link 4K" which provides various format options among which most software > does not consciously pick the one which it implicitly expects leading to > problems. There is a software workaround, transcoding and looping > through a virtual device and a hardware fix flashing the problematic > profiles away. > However it appears to me that the most satisfactory solution is hinted > at in the sentence > >> I couldn't find any option in V4L to force selection of 'YUYV 4:2:2', so instead > > So my question is: what changes would be necessary to allow v4l2-ctl to > enforce a particular format and who would be the right person to ask to > make such changes? It's there already: v4l2-ctl -v pixelformat=YUYV That will do the trick. If you plug in the device and run 'v4l2-ctl -V', which pixelformat does it report? I would expect it to be YUYV since that's first in the list. If apps like Discord pick YU12 instead, then that's weird. That's something that the application does, and v4l2-ctl won't help with that. I.e., it appears to be an application bug. One other alternative is that the device has broken 4:2:0 support, i.e. it reports these formats, but they don't actually work. You can use qv4l2 or qvidcap to test if these 4:2:0 formats are working. Regards, Hans > > Best regards, > Stefan > > > [1] https://assortedhackery.com/patching-cam-link-to-play-nicer-on-linux/ > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Enforcing color profile 2020-08-17 13:34 ` Hans Verkuil @ 2020-08-17 14:50 ` Stefan Witzel 2020-09-01 13:37 ` Stefan Witzel 0 siblings, 1 reply; 6+ messages in thread From: Stefan Witzel @ 2020-08-17 14:50 UTC (permalink / raw) To: Hans Verkuil, linux-media Hi Hans, I suppose it is ultimately an application bug. I was just hoping that the v4l driver cold somehow artificially restrict the device's feature list so as to make the buggy application (which seems to be pretty much any existing web conference app) work. That would be like the hardware workaround but on driver level. I do not yet have the device myself, so I'm relying on information from the website I quoted. I very much appreciate that you took the time to reply! I might come back with more concrete questions once I have the device. Thanks a lot! Best, Stefan Am 17. August 2020 15:34:00 MESZ schrieb Hans Verkuil <hverkuil@xs4all.nl>: >On 17/08/2020 14:09, Stefan Witzel wrote: >> Hello, >> >> I am not a V4L developer so if this is not the right place to bring >up >> the issue please tell me who to contact instead. >> The page [1] documents a problem with a particular device "Elgato Cam >> Link 4K" which provides various format options among which most >software >> does not consciously pick the one which it implicitly expects leading >to >> problems. There is a software workaround, transcoding and looping >> through a virtual device and a hardware fix flashing the problematic >> profiles away. >> However it appears to me that the most satisfactory solution is >hinted >> at in the sentence >> >>> I couldn't find any option in V4L to force selection of 'YUYV >4:2:2', so instead >> >> So my question is: what changes would be necessary to allow v4l2-ctl >to >> enforce a particular format and who would be the right person to ask >to >> make such changes? > >It's there already: > >v4l2-ctl -v pixelformat=YUYV > >That will do the trick. > >If you plug in the device and run 'v4l2-ctl -V', which pixelformat does >it >report? I would expect it to be YUYV since that's first in the list. > >If apps like Discord pick YU12 instead, then that's weird. That's >something that >the application does, and v4l2-ctl won't help with that. I.e., it >appears to be >an application bug. > >One other alternative is that the device has broken 4:2:0 support, i.e. >it reports >these formats, but they don't actually work. You can use qv4l2 or >qvidcap to test >if these 4:2:0 formats are working. > >Regards, > > Hans > > >> >> Best regards, >> Stefan >> >> >> [1] >https://assortedhackery.com/patching-cam-link-to-play-nicer-on-linux/ >> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Enforcing color profile 2020-08-17 14:50 ` Stefan Witzel @ 2020-09-01 13:37 ` Stefan Witzel 2020-09-01 14:33 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 6+ messages in thread From: Stefan Witzel @ 2020-09-01 13:37 UTC (permalink / raw) To: linux-media Hello, Just in case someone should stumble across this thread: An appropriate solution is available here: https://github.com/xkahn/camlink As pointed out by Hans before the described problem is technically an application bug, so one might say it should be fixed on application level, which is what the solution above does. Best, Stefan On 17.08.20 16:50, Stefan Witzel wrote: > Hi Hans, > > I suppose it is ultimately an application bug. I was just hoping that the v4l driver cold somehow artificially restrict the device's feature list so as to make the buggy application (which seems to be pretty much any existing web conference app) work. That would be like the hardware workaround but on driver level. > > I do not yet have the device myself, so I'm relying on information from the website I quoted. I very much appreciate that you took the time to reply! I might come back with more concrete questions once I have the device. > > Thanks a lot! Best, > Stefan > > Am 17. August 2020 15:34:00 MESZ schrieb Hans Verkuil <hverkuil@xs4all.nl>: >> On 17/08/2020 14:09, Stefan Witzel wrote: >>> Hello, >>> >>> I am not a V4L developer so if this is not the right place to bring >> up >>> the issue please tell me who to contact instead. >>> The page [1] documents a problem with a particular device "Elgato Cam >>> Link 4K" which provides various format options among which most >> software >>> does not consciously pick the one which it implicitly expects leading >> to >>> problems. There is a software workaround, transcoding and looping >>> through a virtual device and a hardware fix flashing the problematic >>> profiles away. >>> However it appears to me that the most satisfactory solution is >> hinted >>> at in the sentence >>> >>>> I couldn't find any option in V4L to force selection of 'YUYV >> 4:2:2', so instead >>> >>> So my question is: what changes would be necessary to allow v4l2-ctl >> to >>> enforce a particular format and who would be the right person to ask >> to >>> make such changes? >> >> It's there already: >> >> v4l2-ctl -v pixelformat=YUYV >> >> That will do the trick. >> >> If you plug in the device and run 'v4l2-ctl -V', which pixelformat does >> it >> report? I would expect it to be YUYV since that's first in the list. >> >> If apps like Discord pick YU12 instead, then that's weird. That's >> something that >> the application does, and v4l2-ctl won't help with that. I.e., it >> appears to be >> an application bug. >> >> One other alternative is that the device has broken 4:2:0 support, i.e. >> it reports >> these formats, but they don't actually work. You can use qv4l2 or >> qvidcap to test >> if these 4:2:0 formats are working. >> >> Regards, >> >> Hans >> >> >>> >>> Best regards, >>> Stefan >>> >>> >>> [1] >> https://assortedhackery.com/patching-cam-link-to-play-nicer-on-linux/ >>> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Enforcing color profile 2020-09-01 13:37 ` Stefan Witzel @ 2020-09-01 14:33 ` Mauro Carvalho Chehab 2020-09-21 14:43 ` Stefan Witzel 0 siblings, 1 reply; 6+ messages in thread From: Mauro Carvalho Chehab @ 2020-09-01 14:33 UTC (permalink / raw) To: Stefan Witzel; +Cc: linux-media Em Tue, 1 Sep 2020 15:37:23 +0200 Stefan Witzel <s.witzel@gmx.de> escreveu: > Hello, > > Just in case someone should stumble across this thread: An appropriate > solution is available here: > > https://github.com/xkahn/camlink > > As pointed out by Hans before the described problem is technically an > application bug, so one might say it should be fixed on application > level, which is what the solution above does. Hmm... let me try to understand something. I don't have this device. I'm just curious about what's happening here ;-) After looking at the patches and at: https://assortedhackery.com/patching-cam-link-to-play-nicer-on-linux/ it sounded to me that the UVC driver reports support for 3 different fourccs: Pixel Format: 'YUYV' # V4L2_PIX_FMT_YUYV Pixel Format: 'NV12' # V4L2_PIX_FMT_NV12 Pixel Format: 'YU12' # V4L2_PIX_FMT_YUV420 all of them at 1080 p resolution. It is very common that devices would support multiple video formats. So, the above looks fine on my eyes, provided that the device has support for those 3 YUV format variants. - If I understood well, YUYV works fine (with is a variant of 4:2:2). The problem is with 4:2:0 formats (NV12 and YU12): https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/pixfmt-nv12.html https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/pixfmt-yuv420.html that don't work properly with Discord. Is that right? Btw, are both NV12 and YU12 broken there? Did you try using those formats with a different application, like qv4l2 or qvidcap? > > Best, > Stefan > > On 17.08.20 16:50, Stefan Witzel wrote: > > Hi Hans, Please don't top-post! > > > > I suppose it is ultimately an application bug. I was just hoping that the v4l driver cold somehow artificially restrict the device's feature list so as to make the buggy application (which seems to be pretty much any existing web conference app) work. That would be like the hardware workaround but on driver level. > > > > I do not yet have the device myself, so I'm relying on information from the website I quoted. I very much appreciate that you took the time to reply! I might come back with more concrete questions once I have the device. > > > > Thanks a lot! Best, > > Stefan > > > > Am 17. August 2020 15:34:00 MESZ schrieb Hans Verkuil <hverkuil@xs4all.nl>: > >> On 17/08/2020 14:09, Stefan Witzel wrote: > >>> Hello, > >>> > >>> I am not a V4L developer so if this is not the right place to bring > >> up > >>> the issue please tell me who to contact instead. > >>> The page [1] documents a problem with a particular device "Elgato Cam > >>> Link 4K" which provides various format options among which most > >> software > >>> does not consciously pick the one which it implicitly expects leading > >> to > >>> problems. There is a software workaround, transcoding and looping > >>> through a virtual device and a hardware fix flashing the problematic > >>> profiles away. > >>> However it appears to me that the most satisfactory solution is > >> hinted > >>> at in the sentence > >>> > >>>> I couldn't find any option in V4L to force selection of 'YUYV > >> 4:2:2', so instead > >>> > >>> So my question is: what changes would be necessary to allow v4l2-ctl > >> to > >>> enforce a particular format and who would be the right person to ask > >> to > >>> make such changes? > >> > >> It's there already: > >> > >> v4l2-ctl -v pixelformat=YUYV > >> > >> That will do the trick. > >> > >> If you plug in the device and run 'v4l2-ctl -V', which pixelformat does > >> it > >> report? I would expect it to be YUYV since that's first in the list. > >> > >> If apps like Discord pick YU12 instead, then that's weird. That's > >> something that > >> the application does, and v4l2-ctl won't help with that. I.e., it > >> appears to be > >> an application bug. > >> > >> One other alternative is that the device has broken 4:2:0 support, i.e. > >> it reports > >> these formats, but they don't actually work. You can use qv4l2 or > >> qvidcap to test > >> if these 4:2:0 formats are working. > >> > >> Regards, > >> > >> Hans > >> > >> > >>> > >>> Best regards, > >>> Stefan > >>> > >>> > >>> [1] > >> https://assortedhackery.com/patching-cam-link-to-play-nicer-on-linux/ > >>> Thanks, Mauro ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Enforcing color profile 2020-09-01 14:33 ` Mauro Carvalho Chehab @ 2020-09-21 14:43 ` Stefan Witzel 0 siblings, 0 replies; 6+ messages in thread From: Stefan Witzel @ 2020-09-21 14:43 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: linux-media Hello, Sorry for replying so late. All you say is correct. I tried qv4l2 now and it confirms what you are suggesting: YUYV works fine, NV12 and YU12 show strangely distorted variants of the actual image. I would have sent you a picture but qv4l2 crashed when I tried (even for YUYV). Best, Stefan On 01.09.20 16:33, Mauro Carvalho Chehab wrote: > Em Tue, 1 Sep 2020 15:37:23 +0200 > Stefan Witzel <s.witzel@gmx.de> escreveu: > >> Hello, >> >> Just in case someone should stumble across this thread: An appropriate >> solution is available here: >> >> https://github.com/xkahn/camlink >> >> As pointed out by Hans before the described problem is technically an >> application bug, so one might say it should be fixed on application >> level, which is what the solution above does. > > Hmm... let me try to understand something. I don't have this device. > I'm just curious about what's happening here ;-) > > After looking at the patches and at: > https://assortedhackery.com/patching-cam-link-to-play-nicer-on-linux/ > > it sounded to me that the UVC driver reports support for 3 different > fourccs: > > Pixel Format: 'YUYV' # V4L2_PIX_FMT_YUYV > Pixel Format: 'NV12' # V4L2_PIX_FMT_NV12 > Pixel Format: 'YU12' # V4L2_PIX_FMT_YUV420 > > all of them at 1080 p resolution. > > It is very common that devices would support multiple video > formats. So, the above looks fine on my eyes, provided that the > device has support for those 3 YUV format variants. > > - > > If I understood well, YUYV works fine (with is a variant of 4:2:2). > > The problem is with 4:2:0 formats (NV12 and YU12): > > https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/pixfmt-nv12.html > https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/pixfmt-yuv420.html > > that don't work properly with Discord. Is that right? > Btw, are both NV12 and YU12 broken there? > > Did you try using those formats with a different application, > like qv4l2 or qvidcap? > >> >> Best, >> Stefan >> >> On 17.08.20 16:50, Stefan Witzel wrote: >>> Hi Hans, > > Please don't top-post! > >>> >>> I suppose it is ultimately an application bug. I was just hoping that the v4l driver cold somehow artificially restrict the device's feature list so as to make the buggy application (which seems to be pretty much any existing web conference app) work. That would be like the hardware workaround but on driver level. >>> >>> I do not yet have the device myself, so I'm relying on information from the website I quoted. I very much appreciate that you took the time to reply! I might come back with more concrete questions once I have the device. >>> >>> Thanks a lot! Best, >>> Stefan >>> >>> Am 17. August 2020 15:34:00 MESZ schrieb Hans Verkuil <hverkuil@xs4all.nl>: >>>> On 17/08/2020 14:09, Stefan Witzel wrote: >>>>> Hello, >>>>> >>>>> I am not a V4L developer so if this is not the right place to bring >>>> up >>>>> the issue please tell me who to contact instead. >>>>> The page [1] documents a problem with a particular device "Elgato Cam >>>>> Link 4K" which provides various format options among which most >>>> software >>>>> does not consciously pick the one which it implicitly expects leading >>>> to >>>>> problems. There is a software workaround, transcoding and looping >>>>> through a virtual device and a hardware fix flashing the problematic >>>>> profiles away. >>>>> However it appears to me that the most satisfactory solution is >>>> hinted >>>>> at in the sentence >>>>> >>>>>> I couldn't find any option in V4L to force selection of 'YUYV >>>> 4:2:2', so instead >>>>> >>>>> So my question is: what changes would be necessary to allow v4l2-ctl >>>> to >>>>> enforce a particular format and who would be the right person to ask >>>> to >>>>> make such changes? >>>> >>>> It's there already: >>>> >>>> v4l2-ctl -v pixelformat=YUYV >>>> >>>> That will do the trick. >>>> >>>> If you plug in the device and run 'v4l2-ctl -V', which pixelformat does >>>> it >>>> report? I would expect it to be YUYV since that's first in the list. >>>> >>>> If apps like Discord pick YU12 instead, then that's weird. That's >>>> something that >>>> the application does, and v4l2-ctl won't help with that. I.e., it >>>> appears to be >>>> an application bug. >>>> >>>> One other alternative is that the device has broken 4:2:0 support, i.e. >>>> it reports >>>> these formats, but they don't actually work. You can use qv4l2 or >>>> qvidcap to test >>>> if these 4:2:0 formats are working. >>>> >>>> Regards, >>>> >>>> Hans >>>> >>>> >>>>> >>>>> Best regards, >>>>> Stefan >>>>> >>>>> >>>>> [1] >>>> https://assortedhackery.com/patching-cam-link-to-play-nicer-on-linux/ >>>>> > > > > Thanks, > Mauro > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-09-21 14:49 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-08-17 12:09 Enforcing color profile Stefan Witzel 2020-08-17 13:34 ` Hans Verkuil 2020-08-17 14:50 ` Stefan Witzel 2020-09-01 13:37 ` Stefan Witzel 2020-09-01 14:33 ` Mauro Carvalho Chehab 2020-09-21 14:43 ` Stefan Witzel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).