ug_input seems to reconfigure incoming streams to UYVY

[mikekoetter]

ug_input seems to reconfigure incoming streams to UYVY where I would expect it to pass through the incoming codec.

If for example I am captureing from a decklink and I send it to the local host, I can see that the capture picks up the RGB 444 signal and sends it on:

uv -t decklink:device=0 -m 8000 -s embedded --param bmd-r10k-full-range,decoder-use-codec=R10K -c none --verbose=6 -P 51000 localhost

[1698431851.567] [DeckLink capture] Format change detected (display mode, color space - RGB444, 10bit).
[1698431851.567] [DeckLink capture] Detected 10-bit signal, use ":codec=UYVY" to enforce 8-bit capture (old behavior).
[1698431851.567] [DeckLink capture] Using codec: R10k
[1698431851.567] [DeckLink capture] Enable video input: 1080p24

However when I pick it up with ug_input it seems to only be able to decode to UYVY, where I was hoping it would pass the raw stream through to the compressor, with the end result being a J2KR stream

uv -t ug_input:51000 --param bmd-r10k-full-range -m 8000 -f rs -c cmpto_j2k:quality=1:mem_limit=1000000000:rate=100M  --verbose=6 192.168.1.65 -P 30000
[1698432125.989] [video dec.] New incoming video format detected: 1920x1080 @24.00p, codec R10k
[1698432125.989] [display] Successfully reconfigured display to 1920x1080 @24.00p, codec UYVY

I understand this is probably not a supported use case, but I'm just curious if I am missing something here or if thats a limitation of the input

Also am I right to infer that the reconfigured display that it is referring to is what is being passed to the compress process?

[alatteri]

Why not do everything in a single process, and compress within the same capture session?

[mikekoetter]

yeah that definitely works, but this is for a very specific alternate use case

[mikekoetter]

The example I posted was distilled down to be easy to reproduce

[MartinPulec]

Hi,

I understand this is probably not a supported use case, but I'm just curious if I am missing something here or if thats a limitation of the input

Just FYI, primarily the transcoding reflector is meant to achieve such a task. But if you prefer _uginput, I think we can support this as well (it has some advantages, eg. that it's code is more simple and maybe it is also easier to use). Anyways, both _uginput and the transcoding reflector behave currently the same – decode to UYVY.

To your question – I don't see now any particular reason, why other pixel formats couldn't be supported. It is just now hard-coded to UYVY ¹, as you noticed, because it used to be the "prominent" pixel format (when there was the weak support for higher bit-depth compressions) and perhaps no-one needed otherwise (or at least didn't let us know).

Also am I right to infer that the reconfigured display that it is referring to is what is being passed to the compress process?

yes (as it also follows from the above)

I believe that we can extend it quite easily to support transcode via arbitrary codec (either specified or auto-selected as it for regular displays).

¹ pipe (pseudo)display actually passes the data back to pipeline, so it's its decision what to decode to

[mikekoetter]

I believe that we can extend it quite easily to support transcode via arbitrary codec (either specified or auto-selected as it for regular displays).

That would fantastic! Support for higher bitrate uncompressed codecs coming from the BMD and AJA in both the ug_input and hd-rum-transcode could be very helpful. I'm doing some R&D around that as well as using the file display (.nut format) and being able to pass the R10K codec through would clear some stuff up for me.

[MartinPulec]

For the time being, I've just added at least option :codec=<c> to _uginput to enforce decoding pixfmt. Default is still UYVY but as I said, I believe that auto-selecion will be quite easy as well so I believe that it will be soon as well.

[mikekoetter]

yeah auto detect would be great. I just compiled this in and on initial testing seems to work as advertised! Thanks!

[MartinPulec]

I believe that it should be implemented by the commit c3d2b158 for both _uginput and the transcoding reflector.

[mikekoetter]

Awesome! Just pulled this in and the ug_input is auto detecting and setting the R10K codec as expected. :) Cheers!