@MovieFan.Plex said:
1 - Sorry. Reading too fast. You are correct, it is trying to transcode the video, not just a remux. I’m not positive, but it looks like the transcoding might be trigerred by the anamorphic flag in the file. Even though the flag is enabled, the resolution is already at the appropriate ratio so it doesn’t need to do anything. I need to check if PMS should ignore this setting if the resolution is already correct.
Oct 24, 2016 21:03:34.551 [0xe6d77400] DEBUG - Here I Go - video.anamorphic limitation applies: 1 == 1
2 - When syncing, the DP/DS options are not used, so you cannot force it to sync as-is.
In that case I would suggest that DP/DS options most definitely should be considered when sync-ing.
3 - The first -h264 mention is for the decoder. libxh264 is the encoder.
I cannot say I have ever seen ffmpeg not auto-detect the file contents correctly, so unless there is an example of a massively popular application producing consistently broken files, specifying the input codecs should probably be omitted entirely.
Another thing I see in your XML file, although it doesn’t appear to be involved in this case, is that the profile level for your file is listed as “level=12”, which would be 1.2. You cannot have a 720x576 video at profile level 1.2, that is out of spec.
What profile is this referring to? All of my media is encoded to h.264 Level 4 high.
Mediainfo reports the following on the file:
General
Complete name : Bing - s01e12 - Here I Go.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom/iso2/avc1/mp41)
File size : 108 MiB
Duration : 7mn 20s
Overall bit rate : 2 063 Kbps
Encoded date : UTC 1904-01-01 00:00:00
Tagged date : UTC 1904-01-01 00:00:00
Writing application : Lavf56.25.101
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings, CABAC : Yes
Format settings, ReFrames : 16 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 7mn 20s
Bit rate : 1 609 Kbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.155
Stream size : 84.5 MiB (78%)
Writing library : x264 core 142 r2495 6a301b6
Encoding settings : cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / 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=36 / lookahead_threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=16.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=10000 / vbv_bufsize=10000 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00
Encoded date : UTC 1904-01-01 00:00:00
Tagged date : UTC 1904-01-01 00:00:00
Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 7mn 20s
Bit rate mode : Constant
Bit rate : 448 Kbps
Channel(s) : 2 channels
Channel(s)_Original : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Frame rate : 46.875 fps (1024 spf)
Compression mode : Lossy
Stream size : 23.5 MiB (22%)
Language : English
Default : Yes
Alternate group : 1
Encoded date : UTC 1904-01-01 00:00:00
Tagged date : UTC 1904-01-01 00:00:00
And ffmpeg reports this:
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from ‘Bing - s01e12 - Here I Go.mp4’:
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf56.25.101
Duration: 00:07:20.49, start: 0.042667, bitrate: 2062 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 720x576 [SAR 64:45 DAR 16:9], 1608 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)
Metadata:
handler_name : VideoHandler
Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, 5.1, fltp, 447 kb/s (default)
Metadata:
handler_name : SoundHandler
Plex Transcoder reports:
Guessed Channel Layout for Input Stream #0.1 : 5.1
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from ‘/zfs/media/Animated/Series/Bing/Season 01/Bing - s01e12 - Here I Go.mp4’:
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf56.25.101
Duration: 00:07:20.49, start: 0.000000, bitrate: 2062 kb/s
Stream #0:0(und): Video: h264 (avc1 / 0x31637661), none, 720x576, 1608 kb/s, SAR 64:45 DAR 16:9, 25 fps, 25 tbr, 12800 tbn (default)
Metadata:
handler_name : VideoHandler
Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, 6 channels (default)
Metadata:
handler_name : SoundHandler
I still cannot see anything about a profile version 12 or 1.2 anywhere.
@ChuckPa You were right about perms! It was mmap()-ing the codec .so that was failing, not reading them. The permissions are correct, as are the SELinux contexts, but for some reason it looks like when the container was originally created, docker set the noexec permission on the additional mounted (non-root) file systems, so it wouldn’t have mattered if it was in /var/lib/rather than /home. Turns out there are a number of similar looking mmap() failing bug reports on docker’s github. I tore the container down and re-created it, re-attached the file systems (the docker packages were updated several times since I originally built the container), and lo and behold, it can now mmap() the codec .so files, despite the contents or permissions on the underlying /home/plex not having changed at all.
My bad - you were right. Kudos for spotting it and apologies.
Summary:
- Binaries weren’t the problem, QNAP x31+ binaries work just fine on X-Gene with CentOS 7 armv7hl userspace.
- 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).
Thanks for your help guys. Who’d have thought that it is possible to repeat the same process and end up with a different result.
I’ll mark this thread as answered and open a new one about the feature to skip transcoding of DP content based on the DP force flag in the app configuration.