https://bugs.kde.org/show_bug.cgi?id=503474
--- Comment #5 from armin.no...@thincast.com --- > The RDGFX extension specification does not state that the server MUST send > YUV444 frames. In fact, for `RDPGFX_CAPSET_VERSION104` and > up, it > explicitly states that the `RDPGFX_CAPS_FLAG_AVC_DISABLED` is defined as: yes, and `AVC444` is supported for all of the 10.x caps whereas `AVC420` is not. >Now, the entire reason we send YUV420 is that we prefer using hardware >encoding for the video stream, which guarantees the highest >throughput for >video. However, hardware encoders often do not support encoding YUV444, only >YUV420. For example, this is the output of `>vainfo` for my AMD gpu: off topic for this issue. we're talking about frame format here. If you read the spec for AVC444 you will realize there is no H264 YUV444 involved, only YUV420 on the content side. (2 YUV420 frames with can be recombined to a full YUV444 image), but as said, off topic for *this* issue you can just check the patch, it is just wrapping the data in the corresponding container. As a sidenote: The AVC420 mode is not used *at all* for windows 10 and derivates (at least not to my knowledge), so this is the same as other legacy paths that tend to be buggy. you also fail to implement the required progressive codec that is required by quite a lot of clients up to this date. -- You are receiving this mail because: You are watching all bug changes.
