Fix gtk color-space conversion in peerconnection_client
Bug: webrtc:6857 Change-Id: I3fc95237cc699569d165a3286e96422c77913cbf Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/158080 Reviewed-by: Kári Helgason <kthelgason@webrtc.org> Commit-Queue: Niels Moller <nisse@webrtc.org> Cr-Commit-Position: refs/heads/master@{#29585}
This commit is contained in:
@ -504,7 +504,7 @@ void GtkMainWnd::OnRedraw() {
|
|||||||
|
|
||||||
void GtkMainWnd::Draw(GtkWidget* widget, cairo_t* cr) {
|
void GtkMainWnd::Draw(GtkWidget* widget, cairo_t* cr) {
|
||||||
#if GTK_MAJOR_VERSION != 2
|
#if GTK_MAJOR_VERSION != 2
|
||||||
cairo_format_t format = CAIRO_FORMAT_RGB24;
|
cairo_format_t format = CAIRO_FORMAT_ARGB32;
|
||||||
cairo_surface_t* surface = cairo_image_surface_create_for_data(
|
cairo_surface_t* surface = cairo_image_surface_create_for_data(
|
||||||
draw_buffer_.get(), format, width_ * 2, height_ * 2,
|
draw_buffer_.get(), format, width_ * 2, height_ * 2,
|
||||||
cairo_format_stride_for_width(format, width_ * 2));
|
cairo_format_stride_for_width(format, width_ * 2));
|
||||||
@ -554,13 +554,14 @@ void GtkMainWnd::VideoRenderer::OnFrame(const webrtc::VideoFrame& video_frame) {
|
|||||||
}
|
}
|
||||||
SetSize(buffer->width(), buffer->height());
|
SetSize(buffer->width(), buffer->height());
|
||||||
|
|
||||||
// The order in the name of libyuv::I420To(ABGR,RGBA) is ambiguous because
|
// TODO(bugs.webrtc.org/6857): This conversion is correct for little-endian
|
||||||
// it doesn't tell you if it is referring to how it is laid out in memory as
|
// only. Cairo ARGB32 treats pixels as 32-bit values in *native* byte order,
|
||||||
// bytes or if endiannes is taken into account.
|
// with B in the least significant byte of the 32-bit value. Which on
|
||||||
// This was supposed to be a call to libyuv::I420ToRGBA but it was resulting
|
// little-endian means that memory layout is BGRA, with the B byte stored at
|
||||||
// in a reddish video output (see https://bugs.webrtc.org/6857) because it
|
// lowest address. Libyuv's ARGB format (surprisingly?) uses the same
|
||||||
// was producing an unexpected byte order (ABGR, byte swapped).
|
// little-endian format, with B in the first byte in memory, regardless of
|
||||||
libyuv::I420ToABGR(buffer->DataY(), buffer->StrideY(), buffer->DataU(),
|
// native endianness.
|
||||||
|
libyuv::I420ToARGB(buffer->DataY(), buffer->StrideY(), buffer->DataU(),
|
||||||
buffer->StrideU(), buffer->DataV(), buffer->StrideV(),
|
buffer->StrideU(), buffer->DataV(), buffer->StrideV(),
|
||||||
image_.get(), width_ * 4, buffer->width(),
|
image_.get(), width_ * 4, buffer->width(),
|
||||||
buffer->height());
|
buffer->height());
|
||||||
|
Reference in New Issue
Block a user