Opened 6 years ago
Closed 4 years ago
#13230 closed Bug Report - General (Fixed)
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 )
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)
Change History (39)
comment:2 Changed 6 years ago by
Changed 6 years ago by
Attachment: | 20180227_1100_android_greenline_workaround.patch added |
---|
Workaround by forcing texture format
comment:3 Changed 6 years ago by
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 6 years ago by
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 6 years ago by
Attachment: | greenline.patch added |
---|
greenline patch v1. invert needs checking.
comment:5 Changed 6 years ago by
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 6 years ago by
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 6 years ago by
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 6 years ago by
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 6 years ago by
Attachment: | android_screenshot.jpg added |
---|
Photo of android screen with greenline.patch
Changed 6 years ago by
Attachment: | Linux_screenshot.png added |
---|
Screenshot from Linux with greenline.patch
comment:9 Changed 6 years ago by
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 :(
comment:10 Changed 6 years ago by
The bit where it says 'invert if first filter' concerns me too.
I think this is the current problem, esp for linux.
- height is being used to do maths on top and bottom. Should be height - 1.
- 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 6 years ago by
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
comment:12 Changed 6 years ago by
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 6 years ago by
The new patch looks good so far. I'll use it a lot more the rest of the day.
Changed 6 years ago by
Attachment: | 13207-debug4.patch added |
---|
comment:14 Changed 6 years ago by
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 6 years ago by
Disregard the last attachment and comment. They are intended for a different ticket.
comment:16 Changed 6 years ago by
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 6 years ago by
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:19 Changed 6 years ago by
If you disable the deinterlacer, the green line is not there so it's a problem in the deinterlacer.
comment:20 Changed 6 years ago by
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 6 years ago by
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.
Changed 6 years ago by
Attachment: | 20180402-yuv-greenline-interlaced.patch added |
---|
comment:23 Changed 6 years ago by
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 6 years ago by
Owner: | changed from Peter Bennett to Peter Bennett |
---|---|
Status: | accepted → assigned |
comment:25 Changed 5 years ago by
Owner: | changed from Peter Bennett to mspieth |
---|
Changed 5 years ago by
Latest android gl attempted fixes with debugging code included
comment:26 Changed 5 years ago by
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 5 years ago by
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.
comment:28 Changed 5 years ago by
Milestone: | 30.0 → 30.1 |
---|
comment:29 Changed 4 years ago by
Is this bug still relevant given comments 26 and 27. Can it be closed?
comment:30 Changed 4 years ago by
Resolution: | → Fixed |
---|---|
Status: | assigned → closed |
This is fixed by Mark Kendall's changes. The OpenGL changes in Mark Kendall's 2019-render project will change the code further, rendering this bug moot.
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.