@rossinior said:
Anvergo … never heard of it. Do you mean there are chances that it gets fixed for Amazon Fire TV boxes also?
Anvergo is the codename for the FireTV client. It runs on Android, but has the user interface of PMP (which was codenamed Konvergo). Android + Konvergo = Anvergo
You can see that name pop up in your client logs.
@rossinior said:
If I have These embedded subtitle tracks, adding SRT does not help. SRT does not get displayed in this case.
It ‘does not get displayed’ as in
‘the subtitle text does not appear on screen’
or
‘the SRT subtitle is not selectable’
?
@rossinior said:
Anvergo … never heard of it. Do you mean there are chances that it gets fixed for Amazon Fire TV boxes also?
Anvergo is the codename for the FireTV client. It runs on Android, but has the user interface of PMP (which was codenamed Konvergo). Android + Konvergo = Anvergo
You can see that name pop up in your client logs.
@rossinior said:
If I have These embedded subtitle tracks, adding SRT does not help. SRT does not get displayed in this case.
It ‘does not get displayed’ as in
‘the subtitle text does not appear on screen’
or
‘the SRT subtitle is not selectable’
?
You can select it on Plex Web and during playback in the settings menu of the player on FireTV, but the subtitles do not appear on the screen in the case of further embedded VOBSUB subtitles being present embedded. The subtitles appear on the screen if the embedded VOBSUB subtitle tracks get ripped out (ie. are not present).
Test D in the first post (only SRT: D-logs.txt ; with embedded subtitle tracks present: combined-AD-logs.txt).
As a side note: I just contacted the “Amazon port of ExoPlayer” developer Team - their first reaction:
Please discuss this with the Plex developers… :neutral:
I just followed @ChuckPA s suggestion and checked if the VOBSUB subtitle tracks had header compression enabled - and indeed they had (zlib compression).
I remuxed the original movie in order to ONLY disable header compression on those (bitmap) subtitle tracks. And it worked like a charm.
Why is this happening and can something be done other than copying and remuxing (plus copying back again) hundreds of files?
Who’s to blame? Can the Amazon Fire TV v2 not handle those (standard-encoded) VOBSUB subtitle tracks or is the internally used Exoplayer (by Plex Fire TV app) the one not able to handle zlib compressed VOBSUB subtitle tracks in HVEC movies?
@ChuckPA said:
For reference, Header compression has been in Matroska files since 2002.
Exoplayer is a tightly controlled. (IIRC, only the binary is available)
I think so. But Plex is not using the most actual version of Exoplayer for playback of PMS library content (ie. non-Live TV).
IMHO, give it (HEVC) time to mature. The small amount of space is insignificant and not worth the headaches.
Thank you for your thoughts on that. But I have around 1250 arguments (still growing) against that.
Coaches compared to automobile technology. Versatile coach drivers would have told me the same about solid coach technology and horse power… I don’t want arguing over HEVC, I’d like to have up-to-date technology with perfect support for embedded subtitles… And that - of course - is IMHO.
@ChuckPA said:
How "up to date’ is that qnap’s processor ?
My “current” QNAP i7-6700 SkyLake will crash and burn trying to decode 10 bit HEVC.
Just my humble thoughts.
I don’t get what you are trying to tell me? Has this anything to do with Plex’ missing support on proper embedded VOBSUB support for HEVC on FireTV2 which is fully capable of decoding and playing HEVC?
It direct plays there… no need for any QNAP processor to decode it.
This is getting less problem-oriented now. Any thoughts on why Plex is not getting proper VOBSUB support here? The embedded subtitles are compressed (standard behaviour) and I cannot understand why we are not trying to track the bug further.
@rossinior said:
This is getting less problem-oriented now. Any thoughts on why Plex is not getting proper VOBSUB support here? The embedded subtitles are compressed (standard behaviour) and I cannot understand why we are not trying to track the bug further.
“Proper” and “Standard” are hard words here. Player hardware/software teams and the matroska team have historically had very different views on what those terms mean. This has been an ongoing thing for various matroska settings/options/features since the beginning.
AFAIK exoplayer doesn’t support zlib compressed tracks at all (regardless of video codec). Probably because the google pushed WebM container, which is a subset of matroska, doesn’t have any compression in it’s standard and exoplayer uses the same extractor for WebM/Matroska (in fact, looking through other bits of code, WebM seems to have been the desired support vector while matroska is just a consequence).
At any rate, in MatroskaExtractor.java you can find this (exoplayer source is available on google’s github github.com/google/ExoPlayer): case ID_CONTENT_COMPRESSION_ALGORITHM: // This extractor only supports header stripping. if (value != 3) { throw new ParserException("ContentCompAlgo " + value + " not supported"); }
Clearly stating the only compression algorithm being supported is 3 (zlib is 0). The CONTENT_COMPRESSION_SETTINGS handler also only pulls header stripping details, and has nothing to deal with zlib headers…
If you wish to script removal of track compression, a variant of this command is your friend: mkvmerge --compression -1:none -o "output.mkv" "input.mkv"
“–compression -1:none” placed before the input file sets a compression value of none to all tracks (-1 is the catch-all wildcard for track selection), and leaving all the other options unspecified leaves all other settings/options at their current values.
@tobytl
That’s extremely helpful, man. I did no know the Details and due to the given details in your post, I was able to cross-check and verify this. This part of the code is the same in Google’s Exoplayer v2 (!) and Amazon’s port of ExoPlayer v2.
A few questions are still there…
As we are talking about MKV subtitle playback via Plex of Amazon Fire TV, info given to me earlier is, that a Exoplayer v1 is being used for library content.
I was also able to verify this in the latest release of Google/Amazon ExoPlayer v1.5.16 though the name of the MKV extractor is different (WebmExtractor.java).
In order to play these files, Plex would need to transcode the (zLib compressed) subtitle tracks “only”. I don’t know if that is possible with an update of PMS…
I am starting to understand more and more of this… thank you, folks.
And that - of course - is IMHO.
