vlc 3.0.2 broken for input device stk1160

Bug #1774119 reported by Bernd Späth on 2018-05-30
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
vlc (Ubuntu)
Undecided
Unassigned

Bug Description

Release: Xubuntu 18.04
Package: vlc
Version: 3.0.2-0ubuntu0.1

Starting vlc from the command line via "vlc v4l2:///dev/video1 :input-slave=alsa://hw:1,0 --aspect-ratio=16:9" before version 3.0.2 I was able to watch input from a connected stk1160 device without any distortions.

Since version 3.0.2 only the upper part of the input is displayed with distortion.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in vlc (Ubuntu):
status: New → Confirmed
Colin Hemming (b-ubuntuone14) wrote :

I have the exact same problem. I know the hardware device still works fine because booting into my 16.04 system with the older software still displays and records perfectly.

Bernd Späth (bspaeth) wrote :
Download full text (3.6 KiB)

Fiddling around I was able to gather some further information.

Good news first.

Only the OpenGL video output module seems to be affected by the bug.
Switching 'Output' via 'Tools->Preferences->Video' from 'Automatic' to 'XVideo (XCB)' as a workaround restores video output to the full frame image.

Not using the OpenGL output module with any source working in single-plane mode such as the mentioned stk1160 seems to be advisable anyways.

Digging around in the sources revealed there is not only an issue with the way textures are uploaded to the GPU leading to the "only upper half showing" syndrome.
The algorithm implemented in the OpenGL output module also discards half of the luminance resolution leading to an output quality effectively cutting the luminance resolution down by a factor of two.

@Colin: I hope this information is enough to get video output running with VLC version 3.0.2. for you again.

Just in case the package maintainer or anybody involved in VLC development happens to come across this bug report, I will add more detailed information about the problem below.

Using the official VLC development git repository I was able to track down the problem to commit 2599e2f7394972ec595b2f14d03bf0fb8f808c46 .

The file affected is modules/video_output/opengl/converter_sw.c .

Here the PIXEL_UNPACK_ROWLENGHT of textures transfered to the GPU got changed replacing the calculation "i_pitch / i_pixel_pitch" with "i_pitch * tex_width / i_visible_pitch".

I strongly doubt the new version ever worked correctly except for corner-cases in which i_pitch and i_visible_pitch are the same essentially cancelling out each other in the calculation leaving just tex_width still working in multi-plane mode.

However for hardware running single-plane mode such as my stk1160 using UYVY 4:2:2 encoding the calculated rowlength will be off by a factor of i_pixel_pitch.

Yet this doesn't seem to be the only issue with the code.
Again talking about single-plane 4:2:2 encoded data, buffer data gets uploaded to a RGBA texture.
As the coresponding comment in fragment_shaders.c correctly states "Y1 U Y2 V fits in R G B A".
Unfortunately the generated fragment shader never makes use of the Y2 value stored in the alpha component, reducing luminance resolution by a factor of 2.

IMHO it could be a good idea to just store the buffer handed over by hardware twice.
Once to a 4 component RGBA texture and once to a 2 component say RG texture.

This way we could get both Y values from our RG texture. And corresponding Cb and Cr values from our RGBA texture.
Meaning our fragment shader would look something like this.

---
uniform sampler2D Texture0;
uniform sampler2D Texture1;

smooth in vec2 TexCoord0;

void main() {
     float y = texture2D(Texture0, TexCoord0).g * 255;

     float cb = texture2D(Texture1, TexCoord0).r * 255;
     float cr = texture2D(Texture1, TexCoord0).b * 255;

     float r = y + 1.402 * (cr - 128);
     float g = y - 0.34 * (cb - 128) - 0.71 * (cr - 128);
     float b = y + 1.77 * (cb - 128);

      gl_FragColor = vec4(r/255, g/255, b/255, 1);
}
---

I quick-hacked together a stand-alone program using this strategy to verify the mentionend algorithm sh...

Read more...

Simon Quigley (tsimonq2) wrote :

Is the fix included in the 3.0.x branch upstream? Could you please try using a live instance (virtual machine; whatever works) of the 18.10 dailies and trying it there?

Changed in vlc (Ubuntu):
status: Confirmed → Incomplete
Bernd Späth (bspaeth) wrote :

Switching the video output module to anything else but OpenGL as a workaround has always been possible and still is up to the current version.

The VLC OpenGL video output module is still broken as it ever was since commit 2599e2f7394972ec595b2f14d03bf0fb8f808c46 without any fix at the moment at all.

Simon Quigley (tsimonq2) wrote :

In that case, could you please report it upstream and give the URL here so I can follow it?

Thanks.

Bernd Späth (bspaeth) wrote :

As the problem involves a bug report and an enhancement proposal as well, I split the report in two parts.

The corresponding tickets are the following ones:

https://trac.videolan.org/vlc/ticket/20799#ticket
https://trac.videolan.org/vlc/ticket/20800#ticket

Changed in vlc (Ubuntu):
status: Incomplete → Confirmed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package vlc - 3.0.4-1

---------------
vlc (3.0.4-1) unstable; urgency=medium

  * New upstream release.
    - Fix OpenGL output for single plane devices. (LP: #1774119)
    - Decode AV1 streams. (LP: #1789715)
  * debian/patches: Drop patches merged upstream.

 -- Sebastian Ramacher <email address hidden> Fri, 31 Aug 2018 19:35:02 +0200

Changed in vlc (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.