@MovieFan.Plex said:
@gordan79 said:
What profile is this referring to? All of my media is encoded to h.264 Level 4 high.
This is in your xml you posted before.
<Stream id="15294" streamType="1" default="1" codec="h264" index="0" bitrate="1161" anamorphic="1" cabac="1" codecID="avc1" duration="440480" frameRate="25.000" frameRateMode="cfr" hasScalingMatrix="0" height="576" level="12" pixelAspectRatio="64:45" refFrames="1" requiredBandwidths="2737,2737,2737,2737,2737,2737,2737,2737" scanType="progressive" streamIdentifier="1" width="720"/>
I just noticed that the title for that xml is “Atchoo!”. Did you possibly post the wrong xml so we are looking at different things?
Yes and no.
Yes - it looks like at some point down the thread I may have been testing with two different files (allbeit with the same results).
No - there is no difference in the encoding of the files, they both came off the same DVD and were transcoded using the exact same parameters (I have a shell script that transcodes DVDs for me into a consistent universally compatible format).
I just looked at both files, and they are both listing level 12 (attached both XMLs). No idea how the Plex indexer is coming up with level=12.
Summary:
- Binaries weren’t the problem, QNAP x31+ binaries work just fine on X-Gene with CentOS 7 armv7hl userspace.
That’s good to hear, but be aware that this has not been tested by Plex so there is no guarantee it will continue to work in the future.
And if I hit a problem with the binaries throwing invalid instructions, I will not expect any support toward that end. But that wasn’t the problem here.
- Problem seems to have been a since-fixed docker bug that caused non-root paths to be mounted noexec (no, the noexec wasn’t showing up in mount output on the host)
- Transcoding direct-playable content still isn’t sensible, or even workable in some use cases (for example, to quickly hoard 200GB of a small child’s cartoon collection for consumption on a long flight that is departing in less time than it would take to transcode the entirety of the content on an ARM server).
That mediainfo you posted above is out of spec. You have a 720x576 video encoded at profile level 4.0 and 16 RefFrames, which is why PMS wants to transcode the video.
Interesting. Why is this deemed out of spec? The command I use to transcode is pretty standard ffmpeg without any unusual preset overrides:
ffmpeg -n
-probesize 10000000
-analyzeduration 600000000
-i “$mpg”
-movflags +faststart
-c:v libx264 -crf 16 -pix_fmt yuv420p -profile:v high -level 4.0 -preset veryslow
-maxrate:v 10M -bufsize:v 10M
$RESAMPLE -c:a libfdk_aac -b:a ${AUDIOR}k
-map $VIDEOT -map $AUDIOT
-metadata:s:a:0 language=eng
“$mp4”
where:
$mpg: raw DVD dump as produced by mplayer -dumpstream
$mp4: MP4 target file name
$RESAMPLE: Blank most of the time (and would have been in case of transcoding the videos used as examples in this thread), used only if the input stream is 7.1 spec because most AAC encoders don’t support more than 6.1 channel spec.
$AUDIOR: Audio bit rate, same as what was detected in the input stream to ensure minimal losses
$VIDEOT: Video track #
$AUDIOT: Audio track #
While certainly not unheard of, it seems unlikely that with the basic parameters above ffmpeg would produce an out of spec video file, but I’d certainly like to hear more about the spec it violates (and will be happy to file a bug upstream with ffmpeg if it indeed does so).
There have been requests to force a sync as-is regardless of the media. I can see the desire for this, but then also see the issues that can pop up if people unknowning sync things that won’t playback.
Indeed, but surely this is the exact same problem as setting DirectPlay to “Forced” (in the Android app under Settings, Advanced, Player, Direct play). If this is set on the device to “Forced”, then I would imagine it should be obeyed both for playback and syncing. Or at a push, have a similar setting in the sync section of the options.
Also, not sure if you are aware but you can cast synced media to other Plex devices or turn your device into a mini-server and other Plex clients can pull the synced content. These other devices may not be able to direct play the file. By transcoding the file ahead of time to a compatible format, that video should be playable on all clients.
I never managed to get sync to work before so I never tested this (yet). However - having started with a QNAP x21 model which never had transcoding capability in the first place, I always made sure that I encode all of my media into a format that everything I have can direct play in all recent, current and future devices (Chromecasts, Android devices, Firefox/gstreamer, Chrome), which turned out to be H.264/AAC/MP4. It took nearly a year of transcoding on my 12-core Xeon workstation to convert my familial DVD and BR collection, which is perhaps why I find it disproportionally frustrating when Plex decides it knows better and second guesses me without any option to override it to do as it’s told without questioning the operator.
With the recently announced Plex Cloud offering, you guys may increasingly find yourselves sharing this frustration due to the astronomical amount of CPU consumption I foresee arising from it, majority of it completely unnecessarily.
