Opened 20 months ago

Last modified 9 months ago

#13230 assigned Bug Report - General

Android green line when watching certain videos

Reported by: Peter Bennett Owned by: mspieth
Priority: minor Milestone: 30.1
Component: Ports - Android Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description (last modified by Peter Bennett)

When watching videos that are resized there is a green line along the botton and right of the picture.

The green line only occurs if it is using texture format YV12. There are two texture formats used for most systems - YV12 and UYVY. The logic for choosing which to use is rather obscure. It is choosing UYVY on regular Linux and choosing YV12 on Android. Testing shows that both formats work for Linux as well as for Android, but YV12 is causing the green line on Android.

Changing to use UYVY on Android solves the problem in most cases. However, watching interlaced SD content shows the problem again at the bottom of the screen, even using UYVY.

There seems to be a problem with resizing and deinterlacing.

Attachments (9)

20180227_1100_android_greenline_workaround.patch (960 bytes) - added by Peter Bennett 20 months ago.
Workaround by forcing texture format
greenline.patch (2.3 KB) - added by Mark Spieth 20 months ago.
greenline patch v1. invert needs checking.
android_screenshot.jpg (694.7 KB) - added by Peter Bennett 20 months ago.
Photo of android screen with greenline.patch
Linux_screenshot.png (640.7 KB) - added by Peter Bennett 20 months ago.
Screenshot from Linux with greenline.patch
greenline-precision.patch (2.7 KB) - added by Mark Spieth 20 months ago.
Precision + YV12 color
13207-debug4.patch (8.9 KB) - added by gigem 20 months ago.
20180402-yuv-greenline-interlaced.patch (2.4 KB) - added by Mark Spieth 19 months ago.
gl4.patch (10.5 KB) - added by mspieth 10 months ago.
Latest android gl attempted fixes with debugging code included
openglvideo.cpp (62.4 KB) - added by mspieth 10 months ago.
my opengl video with modsfor reference

Download all attachments as: .zip

Change History (37)

comment:1 Changed 20 months ago by Peter Bennett

Description: modified (diff)
Status: newaccepted

comment:2 Changed 20 months ago by Peter Bennett

I believe that this may be caused by a difference between OpenGL as used on Linux and OpenGL ES as used on Android. For now the only solution I have is the patch to change texture format used. To gain enough understanding of OpenGL to fix this will take some time.

With the texture format patch, the only problem I see is a very thin green line appearing intermittently at the bottom of SD interlaced (480i) content on a 1080p screen. You can hide this using the zoom feature if it is distracting.

Changed 20 months ago by Peter Bennett

Workaround by forcing texture format

comment:3 Changed 20 months ago by Mark Spieth

I think the root cause for this problem is the use of QRect(F) setCoords and setBottom. The numbers for bottom are the last coord in the rect, not top + height. May also affect any any explicit right edge sets.

This will cause the view rect to be 1 higher (wider) than intended.

See openglvideo.cpp PrepareFrame?() especially.

comment:4 Changed 20 months ago by Mark Spieth

Tested my theory, green line is gone!

Not sure about inversion maths if someone can check this.

This will go for all opengl as its a fundamental flaw in rect usage.

Changed 20 months ago by Mark Spieth

Attachment: greenline.patch added

greenline patch v1. invert needs checking.

comment:5 Changed 20 months ago by Peter Bennett

Thanks Mark! I will try this out (without my workaround patch). I am confused by the fact that it works fine on Linux and others, only fails on Android. I will try it on both.

comment:6 Changed 20 months ago by Peter Bennett

I tested greenline.patch on Linux and NVidia Shield (without the workaround patch).

On Shield I still see a green line on right and bottom with a 720p recording on a 1080p TV. The green line at the bottom looks like more than 1 pixel. It could be 2 or 3 pixels. The one on the right could be 1 or 2 pixels. This is the same as without any patch.

On Linux I now see a 1 pixel multi-colored line at the top of the video under certain circumstances. It happens on a 1280x1024 screen when watching 720p content or 640p content. I do not see it on a system that has a 1920x1080 display.

comment:7 Changed 20 months ago by Mark Spieth

What that does mean is that there is another bug or the invert part is wrong. or both.

The main fix for the default rect is logically correct.

probably something to do with the filters and how those rects are used.

I have tested quite a bit of stuff with the shield and the h96pro and haven't seen one yet.

Thanks for the test.

comment:8 Changed 20 months ago by Mark Spieth

If any testers can provide their deinterlacing settings, display res, and media format, that would assist in figuring out whats wrong.

I would like to test more before releasing some changes.

I used linear x1 HW deinterlacer and it was all good on the shield.

Changed 20 months ago by Peter Bennett

Attachment: android_screenshot.jpg added

Photo of android screen with greenline.patch

Changed 20 months ago by Peter Bennett

Attachment: Linux_screenshot.png added

Screenshot from Linux with greenline.patch

comment:9 Changed 20 months ago by Peter Bennett

The video is a 720p h264 recording, recorded from Comcast. Let me know if you need me to post a video sample.

The android device is a Shield.

The display is a 1080p Television set. Since the video is progressive, interlacing settings should not be relevant. I am using profile OpenGL slim. It has deinterlacers as "Linear Blend 2X (HW)" and "Linear Blend (HW)". I also tried with both set at "Linear Blend (HW)". Same result.

There is a green line at the bottom and right. See attachment "android_screenshot.jpg". This is a photo of the screen.

The same video on Mythfrontend on Linux with a 1280x1024 screen, also using OpenGL Slim, shows a line across the top. See attachment "Linux_screenshot.png​".

All is not good :(

Last edited 20 months ago by Peter Bennett (previous) (diff)

comment:10 Changed 20 months ago by Mark Spieth

The bit where it says 'invert if first filter' concerns me too.

I think this is the current problem, esp for linux.

  1. height is being used to do maths on top and bottom. Should be height - 1.
  2. visible height is being used in one place and display in the other branch. This should be consistent I would have though.

comment:11 Changed 20 months ago by Peter Bennett

Here is a sample file that shows these problems. The pictures attached to the ticket come from this sample.

https://www.dropbox.com/s/8ghchmvbkxignij/720p_sample.ts?dl=0

Changed 20 months ago by Mark Spieth

Attachment: greenline-precision.patch added

Precision + YV12 color

comment:12 Changed 20 months ago by Mark Spieth

Give this one a try.

It looks like the root cause was medium precision for gl2es mode. high precision fixes the artefacts.

There are 3 items addressed.

  • high precision fixes incorrect U/V plane addressing (green line)
  • extra precision for certain values, helps with yuyv mode pixel addressing issues (original patch)
  • YV12 to RGB decode was taking the color for the next line for the 2nd half of which causes line artefacts above high color contrast horizontal edges.

Enable any of these one at a time or together to see their individual effects.

I have a heavily instrumented patch too if you would like that.

That said, the color artefacts are less in YUYV mode so I think we should enable the original patch to not use YV12 because it looks uglier esp. when 30cm away from a large screen.

Also the 720p sample is mislabeled, should be 720i as some of the adds have classic herringbone effects but cant be canceled because it cant enable the deinterlacer.

Tested with no and linear x1 deinterlacer on a variety of streams incl 720p (real), 1080i, 576i and other resolution prog streams.

comment:13 Changed 20 months ago by gigem

The new patch looks good so far. I'll use it a lot more the rest of the day.

Changed 20 months ago by gigem

Attachment: 13207-debug4.patch added

comment:14 Changed 20 months ago by gigem

Please try the debug4 patch. This one might actually improve things. It's by no means finished, though. There are still race condition and locking issues to resolve.

comment:15 Changed 20 months ago by gigem

Disregard the last attachment and comment. They are intended for a different ticket.

comment:16 Changed 20 months ago by Mark Spieth

Ive now tested on my h96pro s912 box and 1080i does not work in YV12 mode so I now have the original YUYV mode and it does work.

still no green lines in anything Ive tried.

comment:17 Changed 20 months ago by Peter Bennett

greenline-precision.patch looks good for most videos. Linux playback seems to be fine with the patch. I still have a couple of videos that do not work well with this on the shield:

  • The Glass Castle (mkv video) - With greenline-precision.patch there is a green line at the top and bottom of the picture. This is very fine, probably 1 pixel so maybe that is OK. With both greenline-precision.patch and 20180227_1100_android_greenline_workaround.patch​ it is perfect.
  • The Bold and the Beautiful (ts SD recording) - With greenline-precision.patch it is perfect. With both greenline-precision.patch and 20180227_1100_android_greenline_workaround.patch​ there is a fat green line at the bottom.

Video Links -

comment:18 Changed 20 months ago by Mark Spieth

Which deinterlacer did you use for B&B?

comment:19 Changed 20 months ago by Mark Spieth

If you disable the deinterlacer, the green line is not there so it's a problem in the deinterlacer.

comment:20 Changed 20 months ago by Peter Bennett

For me, the first patch (20180227_1100_android_greenline_workaround.patch​) still works the best. I do not have enough understanding of OpenGL at this time to propose anything else.

comment:21 Changed 19 months ago by Mark Spieth

I still like your original patch and run it too. except for that green line which Im trying to figure out.

The other fixes for YV12 are good to but since ffmpeg outputs less res on chroma, the picture quality is not as good.

YV12 has the benefit that it doesn't use as much mem bandwidth to get into the GPU as YUYV so that may be a consideration esp with no PBO support in es2.

Commit the original patch as a good start.

comment:22 Changed 19 months ago by Peter Bennett <pbennett@…>

In 51d6fdf7c554ede09fc2025dff86255ac61e5146/mythtv:

Android: Workaround for green line on some videos

Some videos show a green line at the bottom and right. Avoiding
YV12 texture format eliminates most of the problem.

Refs #13230

Changed 19 months ago by Mark Spieth

comment:23 Changed 19 months ago by Mark Spieth

New patch to solve yuv upscaling green line for sample video. also works for 720x576 sources (many channels here)

Fixed onefield, linear and kernel gl hw deint for yuv.

Things to check for.

  • quality of deinterlacing at low res (not sure if better or worse)
  • HD deinterlacing quality
  • HD green lines (havent seen any)
  • test with other devices (not done yet with my S912)
  • test on PC version (not done yet)

The root problem is that the image is first inverted as GL has 0,0 at bottom left. That means the first line is NLines-1 on bottom field of frame.

This may or not be the same depending on whether the deinterlacer is the first shader or other ones. I dont understand this properly yet. TBD.

It may be better to flip the last field instead of the first, then the algos will process the line in forward instead of reverse order.

I cant see why this would not be an issue for non ES version.

comment:24 Changed 18 months ago by Peter Bennett

Owner: changed from Peter Bennett to Peter Bennett
Status: acceptedassigned

comment:25 Changed 13 months ago by Peter Bennett

Owner: changed from Peter Bennett to mspieth

Changed 10 months ago by mspieth

Attachment: gl4.patch added

Latest android gl attempted fixes with debugging code included

comment:26 Changed 10 months ago by mspieth

Added current patch with debugging code left in.

Tests were done with a low(er) res YV12 video. Some parts of the patch have been replaced by a recent rebase anticipating great things from markk :-)

Interlacing was found to be reversed line order due to origin being bottom left which means the image is processed upside down until the last stage where its reversed.

comment:27 Changed 10 months ago by Peter Bennett

I don't think this is needed. I tested the latest master with Shield and Fire TV. There is no situation where I get the green line, it seems to be fixed. I tried videos of all different resolutions with YV12 on the shield. All look good. The fire tv 4k never had a green line problem and still does not.

Changed 10 months ago by mspieth

Attachment: openglvideo.cpp added

my opengl video with modsfor reference

comment:28 Changed 9 months ago by Stuart Auchterlonie

Milestone: 30.030.1
Note: See TracTickets for help on using tickets.