H264 10bit transcoding problem

[ORevelat]

When I watch an anime that uses 10bit encoding, a nice green screen replaces the video for few seconds or more, several time .

I tested with 0.5.1 and 0.6.0 with both my RPI B+ 512GB and RPI2 1GB. Plex server version is currently 0.9.12.3 but I always had the issue whatever the version.

The issue is annoying because I have no problem using OSMC or XBMC/KODI with the PlexBMC addon (current 4.0 beta4) or using my Chromecast - but I prefer to use the Rasplex distribution as I like it a lot more - especially using plex android app !

So is there a way to update settings used by Rasplex / Plex Server when H264 video using 10bits depth are requested ?

If additional information are mandatory, please let me know.

VisualC

Here are information of a video causing trouble, but I have plenty of them, almost all anime are now using 10 bits encoding ...

General
Unique ID : 242625869347342528122905833630224084861 (0xB6880AEEC629A74397FA7954E8C3EF7D)
Complete name : 1x23 - Doom.mkv
Format : Matroska
Format version : Version 2
File size : 446 MiB
Duration : 23mn 59s
Overall bit rate : 2 600 Kbps
Encoded date : UTC 2015-03-22 12:08:20
Writing application : mkvmerge v5.0.1 ('Es ist Sommer') built on Oct 9 2011 11:55:43
Writing library : libebml v1.2.2 + libmatroska v1.3.0
Attachements : BenguiatGothicCTT_0.ttf / QuaySansMdITCTT Italic.ttf / QuaySansMdITCTT.ttf / Artifikerned.ttf / Balthazar-Regular.ttf

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 10@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 16 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 23mn 59s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Scan type : Progressive
Writing library : x264 core 129 r2245+729M 1a52e03
Encoding settings : cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=11 / psy=1 / fade_compensate=0.00 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=18 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / fgo=0 / bframes=6 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=30 / rc=crf / mbtree=1 / crf=17.0 / qcomp=0.60 / qpmin=0 / qpmax=81 / qpstep=4 / ip_ratio=1.40 / aq=1:0.80
Language : Japanese
Default : Yes
Forced : No

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 23mn 59s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : 8ms
Language : Japanese
Default : Yes
Forced : No

Text
ID : 3
Format : ASS
Codec ID : S_TEXT/ASS
Codec ID/Info : Advanced Sub Station Alpha
Compression mode : Lossless
Language : English
Default : Yes
Forced : No

[gillesdemey]

I've been having the exact same issues on both of my Pi devices (RPi B+ and RPi 2). I've played around with some settings, but nothing that seems to counter the bug.

The issue does not occur with other software, like mentiond before (Kodi, Plex iOS app, et al.). Only happens with 10-bit color depth video.

If I can contribute any more useful info or metrics, let me know :-)

[MuffinCollector]

I've experienced the same green screen issue on RasPlex 0.6.0 running on a Raspberry Pi 2 while playing back videos with a bit depth of 10-bits. I've also noticed that though RasPlex tells me my video will be transcoded when beginning playback, Plex Web shows that the video is being direct played. My PMS Version is 0.9.12.4.

[NedtheNerd]

There's a known bug in PMS that shows direct play for everything even though it is actually transcoding. Anything above 8 bit will always be transcoded by PMS at the moment. Plex Inc will fix the bug in the next release of PMS. They seem to be a bit busy at the moment due to the forums being hacked.

[gillesdemey]

@NedtheNerd You're talking about the bug where it always reports direct play, correct?

[NedtheNerd]

Can you please check this issue in the latest release 0.7.0 (released today) and advise.

[ORevelat]

Hi,

No problem, i'll install the new version asap and i'll give you the feedback.
Thank you.

[ORevelat]

@NedtheNerd
Good evening, I just checked with the new 0.7.0 on my RPI 2 and i'm sorry to say that the problem is still present.

Do you need specific information in order to track this issue ? , please let me know.

[NedtheNerd]

Can you make a sample of the problem file available on Dropbox or similar and I can try to see what this issue is, if you can't create a sample PM me a link to the full file in the Plex Forums.

Regards

[MuffinCollector]

@NedtheNerd I've sent a sample file your way in the Plex Forums.

[ORevelat]

@NedtheNerd

Hi,

Yep for sure, I have uploaded a complete episode (I've got the problem 5 or 6 times with this one) onto dl.free.
Here are the information for the file - http://dl.free.fr/nsjwAfREK, user "whatever" and password "rasplex" (the .7z file has no pwd).

Regards

[gillesdemey]

It happens consistently for me at around 02:15 in the sample @VisualC06 uploaded.

[ORevelat]

Hi @NedtheNerd,

Do you have any clues that may explain the problem ? or maybe a solution :) ? If you need additional materials, please let us know.

Regards

[NedtheNerd]

Can you check this issue in latest release 1.0.0 and advise.

[ORevelat]

Hello,
yes for sure, I will give a try this weekend. Nevertheless, it seems someone has already reported the problem on the forum for Hi10 while he's using 1.0.0 version.

[ORevelat]

Hi @NedtheNerd ,

so I quickly tested the new 1.0 version but unfortunately I've the same issue (not exactly on the same timestamp with the 0.7 version it seems ?).
I just saw that someone on the rasplex forum has reported the issue also using 1.0.

Best regards

[ghost]

@NedtheNerd ,
I'm still having the same problems with 1.0.1 and 1.0.2 PreRelease. I saw Kwiboo noted this as a milestone for 2.0, so should I assume that this won't be addressed until a much later release? It's not an insurmountable problem, but certainly frustrating, especially if I don't know that the media is 10-bit before I start watching it.

Thanks a lot!
Dylan

[NedtheNerd]

Surely you notice this when you rip the media.

[ghost]

Yes for myself, but I also have media shared with a few friends through Plex as well, and they don't necessarily screen for 10-bit media. Like I said not an insurmountable problem, but clearly effecting several people. Was just more curious if there were any updates since we haven't heard anything since November.

Thanks again!

[karurosu]

Still happening with 1.6.0

[TinSuitDragoncar]

I'm finding this issue quite frequently with the latest versions of PMS (1.0.3.2461) and Rasplex (1.6.2). Would it be incorrect to assume that this problem just isn't going to get fixed at this point? It is becoming quite bothersome to constantly work around the issue.

[evlo]

Same here, but maybe it is server issue?

[karurosu]

I've tried with the same server and different clients (web, iOS, PHT) and the issue only happens on Rasplex. I haven't tested on PMP though...

[TheDukeofErl]

Has anybody tested if this also occurs with transcoded HEVC?

[evlo]

I noticed it very rarely happens in other then "hi10p" content. I guess it may be HEVC, i will look for it next i notice it. But generally i can confirm it is not limited to only "hi10p".

[TheDukeofErl]

That's good to know. In that case, it might be less an issue with hi10p but more an issue with what the transcoder target is. In the digging I've done, the transcode target is 20 Mbps for video, 1 Mbps for audio (max for both). While the RPI3 should be capable of playing this, I wonder if this is maybe the issue.

For now, I'm trying to make a custom build of RasPlex which allows for 10-bit video to play directly. In the case that I can get the image running properly and 720p hi10p plays back smoothly or smoothly enough, I'll look into adding a GUI menu option much like is available for HEVC direct play.

Past that, time permitting, I might look into lowering the transcoder target maxes to see if that helps either.

[karurosu]

I want to add that its not random. If it happens with a file, it will happen every time on the exact same spot, and it usually coincides with a sudden picture change or some other sort of effect.
For example, lets say that it happens at the 12:01 mark, if you skip to 12:02 it won't happen. Also, after the green screen, the video slowly "composes back" usually in less than a minute.

[g1t-dlanor]

@TheDukeofErl:
If the bitrate really is at max for both video and audio, with a combined rate of 21 Mbps, then we may also need to consider the effective (as opposed to theoretical) network speed available. If you use one of the lower-speed WiFi variants, it might not be up to transferring such a bitstream well, as the effective bitrate may be lowered by various forms of interference. (Other nearby WiFi sources as well as unrelated electric hardware generating interference.)

[TheDukeofErl]

@karurosu
I usually have it happen on large flashes of light, which seems to coincide with your description.

@g1t-dlanor
I just tested this now on WiFi as well as a 1 Gbit LAN network. The greenscreen effect occurred at the same time regardless of the connection.

[TheDukeofErl]

Okay, I've made a couple discoveries:

1. 720p hi10p kind of works on a stock RPi3. It's perfect by no means, however, there is no full screen tearing or any other incredibly undesirable effects. Regardless, there are still issues with this, as there is boxing as well as clear shifts in colors in a scene. As one would expect, this gets worse with higher bitrates and would most likely be unwatchable at 1080p.
2. There is a correlation between the video transcoded bitrate and the "green screen" effect occurring. In the transcoder profile, the highlighted line controls the maximum bitrate of the encoded stream. This line is <UpperBound name="video.bitrate" value="20000" /> and by setting this value to 1500 I have positive results: there is no more green screening. This can be set in Ubuntu at /usr/lib/plexmediaserver/Resources/Profiles/Plex\ Home\ Theater-RaspberryPi.xml. If anybody tries to play with this value a little bit, let me know if any good results are achieved, as I would like to confirm that this does have an effect across multiple user environments.

For the time being, I am planning on setting this value on my own PMS, as it seems to yield good results at a minor cost of quality. If anybody would like me to, I would be more than happy to upload the build I made which does not transcode 10-bit or even look into adding a menu option much is like for HEVC. For reference, I made one change to allow this, which can be viewed here.

With this in mind, does anybody have any more insight into this issue?

[karurosu]

The issue is still present on 1.7.1

I tried @TheDukeofErl suggestion but I did not seem to change the correct file, I could not play anything. This is in a PMS running on OSX.

[TheDukeofErl]

@karurosu Could you give me the path to the file you edited? IIRC the OS X implementation and file structuring should be relatively similar to the Linux one. I haven't updated RasPlex nor my Plex server in a while but I can make sure this fix still works at some point, though that might not be for a week or two.

[wridgers]

I also have this issue. What can I do to help debug the problem?

[cristiancll]

This issue still happenso 1.8.0