Commits on Source (12)
-
Steve Lhomme authored
BI_RGB is 0, no need to set it again to 0 later.
066e235f -
Steve Lhomme authored
We may want to use BI_BITFIELDS with it too.
22e26729 -
Steve Lhomme authored
With the follwing code change in mock, the planes end up matching the XRGB order when playing the file with the Windows player. There is no mask involved here. * The first bar is black for 32-bit color [0xFF 0x00 0x00 0x00] * The second bar is red for 32-bit color [0x00 0xFF 0x00 0x00] * The third bar is green for 32-bit color [0x00 0x00 0xFF 0x00] * The fourth bar is blue for 32-bit color [0x00 0x00 0x00 0xFF] mock://video_track_count=1;length=6000000;video_chroma=XRGB --sout=#transcode{vcodec=XRGB}:std{access=file,dst=xrgb.avi,mux=avi} unsigned lines_per_color = pic->p[0].i_visible_lines / pic->p[0].i_pixel_pitch; for (int bar = 0; bar < pic->p[0].i_pixel_pitch; bar++) { uint8_t colors[pic->p[0].i_pixel_pitch]; memset(colors, 0, sizeof(colors)); colors[bar] = 0xFF; for (unsigned y=bar*lines_per_color; y < (bar+1)*lines_per_color; y++) for (int x=0; x < pic->p[0].i_visible_pitch; x += pic->p[0].i_pixel_pitch) { memcpy(&pic->p[0].p_pixels[x + y*pic->p[0].i_pitch], colors, pic->p[0].i_pixel_pitch); } } memset(pic->p[0].p_pixels, pixel, block_len);
3f41da4a -
Steve Lhomme authored
We know BI_RGB corresponds to XRGB, so we should match it with the corresponding mask.
a8212280 -
Steve Lhomme authored
RGB32 with the same mask as XRGB ends up using a the wrong mask. In both case the mask is 0xff0000/0x00ff00/0x0000ff and needs to go through hton32. RGB32 with default mask encoded as BI_BITFIELDS correctly play in the Windows player after this patch.
6bf7babd -
Steve Lhomme authored
When patching mock with the following code and forcing BI_RGB, to not use any mask, the Windows player render Blue, Green, Red planes in that order. The 16-bit color values have to be written as Little-Endian (SetWLE). int bars = __MAX(3, pic->p[0].i_pixel_pitch); uint8_t colors[4]; unsigned lines_per_color = pic->p[0].i_visible_lines / bars; for (int bar = 0; bar < bars; bar++) { memset(colors, 0, sizeof(colors)); if (pic->p[0].i_pixel_pitch == 2) { if (bar == 0) SetWLE(colors, 0x1F << 11); else if (bar == 1) SetWLE(colors, 0x3F << 5); else if (bar == 2) SetWLE(colors, 0x1F << 0); } for (unsigned y=bar*lines_per_color; y < (bar+1)*lines_per_color; y++) for (int x=0; x < pic->p[0].i_visible_pitch; x += pic->p[0].i_pixel_pitch) { memcpy(&pic->p[0].p_pixels[x + y*pic->p[0].i_pitch], colors, pic->p[0].i_pixel_pitch); } } memset(pic->p[0].p_pixels, pixel, block_len);
050937a0 -
Steve Lhomme authored
When patching mock with the following code and forcing BI_RGB, to not use any mask, the Windows player render Blue, Green, Red planes in that order. The 16-bit color values have to be written as Little-Endian (SetWLE). int bars = __MAX(3, pic->p[0].i_pixel_pitch); uint8_t colors[4]; unsigned lines_per_color = pic->p[0].i_visible_lines / bars; for (int bar = 0; bar < bars; bar++) { memset(colors, 0, sizeof(colors)); if (pic->p[0].i_pixel_pitch == 2) { if (bar == 0) SetWLE(colors, 0x1F << 10); else if (bar == 1) SetWLE(colors, 0x1F << 5); else if (bar == 2) SetWLE(colors, 0x1F << 0); } for (unsigned y=bar*lines_per_color; y < (bar+1)*lines_per_color; y++) for (int x=0; x < pic->p[0].i_visible_pitch; x += pic->p[0].i_pixel_pitch) { memcpy(&pic->p[0].p_pixels[x + y*pic->p[0].i_pitch], colors, pic->p[0].i_pixel_pitch); } } memset(pic->p[0].p_pixels, pixel, block_len);
177bff83 -
Steve Lhomme authored
When using BI_BITFIELD with the data written as R5G5B5LE/B5G6R5LE the only mask accepted by the Windows player is our default mask passed through hton32.
6bab8418 -
Steve Lhomme authored
BI_BITFIELDS can only be used with 32-bit and 16-bit RGB. So it's always applied anyway.
4ae5f3ed -
Steve Lhomme authored
We do a first hton32 on the mask and then SetDWBE does it again. What we really want is to store the mask as Little-Endian. This is also coherent with the GetDWLE() used for reading the masks in ParseBitmapInfoHeader(). The corresponds to the 3 colors in extra data after the VLC_BITMAPINFOHEADER for BI_BITFIELD [1]: > If biCompression equals BI_BITFIELDS, the bitmap uses three DWORD color > masks (red, green, and blue, respectively), which specify the byte layout > of the pixels. The 1 bits in each mask indicate the bits for that color > within the pixel. The "bitmap" being the data after the "bitmap header". [1] https://learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-bitmapinfoheader
7028356f -
Steve Lhomme authored
Even if we don't keep masks internally, some system still need to set RGB(A) masks. We can handle all our RGB chroma as we know the proper component position.
d50370ee -
Steve Lhomme authored2aeea3cf