https://bugs.kde.org/show_bug.cgi?id=503474
--- Comment #4 from Arjen Hiemstra <ahiems...@heimr.nl> --- 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: > If this flag is set, it indicates that usage of the MPEG-4 AVC/H.264 Codec in > any mode is not supported in the > RDPGFX_WIRE_TO_SURFACE_PDU_1 (section 2.2.2.1) message. If the flag is not > set, the client MUST be capable of processing: > 1. The MPEG-4 AVC/H.264 Codec in YUV444 mode in the > RDPGFX_WIRE_TO_SURFACE_PDU_1 message. > 2. The MPEG-4 AVC/H.264 Codec in YUV420 mode in the > RDPGFX_WIRE_TO_SURFACE_PDU_1 message in the same frame as other codecs. Note point 2 here, which strongly implies that servers are fine to send YUV420, though it is never specified what *servers* are supposed to do, only *clients*. For earlier CAPSETs, the specification isn't very clear, only stating that if not disabled, the client is required to support decoding YUV444. The current code even has a more explicit interpretation and only supports the CAPSETs where YUV420 is explicitly supported. 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: > VAProfileH264ConstrainedBaseline/VAEntrypointEncSlice > VAConfigAttribRTFormat : VA_RT_FORMAT_YUV420 > VAConfigAttribRateControl : VA_RC_CBR > VA_RC_VBR > VA_RC_CQP > VA_RC_QVBR > VAConfigAttribEncPackedHeaders : VA_ENC_PACKED_HEADER_SEQUENCE > VA_ENC_PACKED_HEADER_PICTURE > VA_ENC_PACKED_HEADER_SLICE > VA_ENC_PACKED_HEADER_MISC > VA_ENC_PACKED_HEADER_RAW_DATA > VAConfigAttribEncMaxRefFrames : l0=1 > l1=1 > VAConfigAttribEncMaxSlices : 128 > VAConfigAttribEncSliceStructure : > VA_ENC_SLICE_STRUCTURE_ARBITRARY_MACROBLOCKS > VA_ENC_SLICE_STRUCTURE_EQUAL_ROWS > VAConfigAttribMaxPictureWidth : 4096 > VAConfigAttribMaxPictureHeight : 4096 > VAConfigAttribEncQualityRange : number of supported quality > levels is 32 > VAConfigAttribEncIntraRefresh : > VA_ENC_INTRA_REFRESH_ROLLING_COLUMN > VA_ENC_INTRA_REFRESH_ROLLING_ROW > VA_ENC_INTRA_REFRESH_P_FRAME > VAConfigAttribEncROI : num_roi_regions=32 > roi_rc_priority_support=0 > roi_rc_qp_delta_support=1 > VAConfigAttribEncRateControlExt : max_num_temporal_layers_minus1=3 > temporal_layer_bitrate_control_flag=1 > VAConfigAttribMaxFrameSize : max_frame_size=1 > multiple_pass=0 Note the bit where it says "VAConfigAttribRTFormat: VA_RT_FORMAT_YUV420" and no other formats. So even if we wanted to support YUV444. it would mean forcing software encoding which is not a good tradeoff. -- You are receiving this mail because: You are watching all bug changes.
