PMS - M1 Mac - Optimise Versions - Original Quality Setting - Bad Results

[Robbie_UK]

Server Version#: 1.25.7.5604
Player Version#: 1.41.0.2876-e960c9ca

My usual workflow for DVR tasks on Freeview (UK DVB) is to record them via an HD-HomeRun as MP4/h.264/TS. If I intend to keep the recording I use the PMS Optimise - Original Quality setting on PMS running on an M1 Mac mini with the files themselves residing on a Synology NAS.

This workflow turns the Transport Stream (TS) into a regular MP4/h.264 file which is easier to manage or edit as required. I’ve been doing this for a number of years and, unsurprisingly, it produces a file size almost identical to the original.

Starting several weeks ago the normal MP4-TS to regular MP4 optimise process started to churn out very large file sizes. Taking a bad movie as a test file (Rambo: Last Blood):

The original MP4-TS Recording = 3.56GB

Summary

General
ID : 1 (0x1)
Complete name : /Volumes/Video/Recordings/Rambo Last Blood (2019)/Rambo Last Blood (2019).ts
Format : MPEG-TS
File size : 3.31 GiB
Duration : 2 h 2 min
Overall bit rate mode : Variable
Overall bit rate : 3 859 kb/s

Video
ID : 256 (0x100)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 4 frames
Codec ID : 27
Duration : 2 h 2 min
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Optimised Version, Original Quality, Auto, Fast = 18.68GB

Summary

General
Complete name : /Volumes/Video/Recordings/Rambo Last Blood (2019)/Rambo_ Last Blood (2019) [fast].mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom/iso2/avc1/mp41)
File size : 17.4 GiB
Duration : 2 h 2 min
Overall bit rate : 20.3 Mb/s
Writing application : Lavf58.65.101

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings : CABAC / 1 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 1 frame
Format settings, GOP : M=1, N=6
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 2 h 2 min
Bit rate : 20.0 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.386
Stream size : 17.2 GiB (99%)
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Codec configuration box : avcC

I also tried modifying the transcode presets to Auto/Slow, Auto/Very Fast, PHSE, PHQE and was very surprised to find that they all produced an identical 18.68GB file, as if the transcode selections were making no difference to the actual transcode.

I am not sure if the change in behaviour was linked to a macOS PMS update or not, I just noticed the rapidly increasing file sizes.

Is this a bug with PMS or have I messed-up somewhere?

Regards to all.

[Volts]

The Transcoder quality setting doesn’t affect Optimize... tasks at all. It only affects realtime/playback transcoding.

The text stating Slower values will result in ... smaller file sizes ... is completely inaccurate. Slower x264 presets have access to more compression methods. This generally improves quality but doesn’t reduce size. Slower presets can even produce larger files.

Original Quality is very high quality (CRF 18) and doesn’t put any limits on size. An 18GB file is 0.5% of the original and isn’t unexpectedly large.

Optimized for TV is similar but constrains the video to 8 Mbps. The Custom option provides more choices.

---

I don’t think the Optimize... tasks use hardware encoding, but I’m curious. The Apple M1 hardware VideoToolbox encoder is known to be very fast, but also produces large files. While an Optimize ... task is active, can you share the output of this Terminal command?

ps uaxww | grep -i "Plex Transcoder"

If it’s easier, sharing server logs after starting an Optimize... task would contain the same information.

[Robbie_UK]

@Volts Thanks for the feedback - always helpful.

I find the file size surprising as it is many times larger than the original and until this point optimisation didn’t change the size at all. A 3.56GB broadcast would still be a 3.56GB file (give-or-take) post-optimisation, rather than increasing by over 5x. I have around 600 movie examples still on my server that were processed this way.

The output of the grep, as requested:

Summary

rob@Smaug ~ % ps uaxww | grep -i “Plex Transcoder”
rob 7465 130.7 1.2 35533056 195852 ?? R 7:24pm 3:03.69 /Applications/Plex Media Server.app/Contents/MacOS/Plex Transcoder -codec:#0x100 h264 -hwaccel:#0x100 videotoolbox -hwaccel_fallback_threshold:#0x100 10 -codec:#0x101 aac_latm -analyzeduration 20000000 -probesize 20000000 -i /Volumes/Video/Recordings/Rambo Last Blood (2019)/Rambo Last Blood (2019).ts -filter_complex [0:#0x100]scale=w=1920:h=1080:force_divisible_by=4[0] -map [0] -codec:0 h264_videotoolbox -b:0 20000k -r:0 25 -filter_complex [0:#0x101] aresample=async=1:ocl=‘stereo’:rematrix_maxval=0.000000dB:osr=48000[1] -map [1] -metadata:s:1 language=eng -codec:1 aac_at -b:1 256k -f mp4 -map_metadata -1 -map_chapters -1 -movflags +faststart /Volumes/Video/Recordings/Rambo Last Blood (2019)/Plex Versions/Original Quality/.inProgress/Rambo_ Last Blood (2019).mp4.824 -y -nostats -loglevel quiet -loglevel_plex error -progressurl http://127.0.0.1:32400/video/:/transcode/session/73348160-b935-471b-a5da-05b8e5ee7d6a/770f275d-267b-492a-868b-43605d42852e/progress
rob 7548 0.0 0.0 408637584 1792 s000 S+ 7:26pm 0:00.00 grep -i Plex Transcoder
rob@Smaug ~ %

[Volts]

Ahahaha, didn’t that say TB before? GB makes more sense.

OK … that’s using Apple’s VideoToolbox, which is super fast, and makes big files.

If you disable Use hardware acceleration when available and/or Use hardware-accelerated video encoding do you get smaller files?

[Robbie_UK]

Yep, I managed to fat-finger a couple of G & Ts… thirsty now.

Running the test as suggested.

Grep output:

Summary

rob@Smaug ~ % ps uaxww | grep -i “Plex Transcoder”
rob 8786 689.6 2.6 35606672 428788 ?? RN 8:13pm 17:01.80 /Applications/Plex Media Server.app/Contents/MacOS/Plex Transcoder -codec:#0x100 h264 -codec:#0x101 aac_latm -analyzeduration 20000000 -probesize 20000000 -i /Volumes/Video/Recordings/Rambo Last Blood (2019)/Rambo Last Blood (2019).ts -filter_complex [0:#0x100]scale=w=1920:h=1080:force_divisible_by=4[0];[0]format=pix_fmts=yuv420p|nv12[1] -map [1] -codec:0 libx264 -crf:0 16 -r:0 25 -preset:0 fast -level:0 4.0 -x264opts:0 subme=0:me_range=4:rc_lookahead=10:me=hex:8x8dct=0:partitions=none -filter_complex [0:#0x101] aresample=async=1:ocl=‘stereo’:rematrix_maxval=0.000000dB:osr=48000[2] -map [2] -metadata:s:1 language=eng -codec:1 aac_at -b:1 256k -f mp4 -map_metadata -1 -map_chapters -1 -movflags +faststart /Volumes/Video/Recordings/Rambo Last Blood (2019)/Plex Versions/Original Quality/.inProgress/Rambo_ Last Blood (2019).mp4.825 -y -nostats -loglevel quiet -loglevel_plex error -progressurl http://127.0.0.1:32400/video/:/transcode/session/8d6e8aec-17ee-435b-bbec-8712162e6a49/0151a9ce-bc84-4671-aade-c3c49439fc01/progress
rob 8867 0.0 0.0 408638608 1872 s000 S+ 8:15pm 0:00.00 grep -i Plex Transcoder
rob@Smaug ~ %

[Robbie_UK]

Hits the CPU cores quite hard without the HW encoding comfort blanket.

[Robbie_UK]

The end result of the test was a more manageable 6.35GB file but that is still approaching double the size of the original 3.56GB.

[Volts]

I think this all makes sense. Your original file at 3.56GB is a pretty reasonable size for movie-length 1080p H.264.

Video gets bigger if re-encoded using “bigger” settings, and these are all “bigger” settings.

When hardware transcoding is enabled, Plex uses Apple’s VideoToolbox. VideoToolbox doesn’t have speed or quality knobs, just a bitrate knob. VideoToolbox is very fast, but it isn’t space-efficient. So for Original Quality, Plex is simply throwing bits at it (the -b:0 20000k setting) to achieve high quality.

Because VideoToolbox is fast-but-fat, I don’t think it makes sense to use it for offline encoding or Optimize... jobs. (Plex should offer a way to disable hardware encoding for background jobs!)

If hardware transcoding is not enabled, Plex uses x264. For Original Quality, Plex sets a very high quality target, with no limit on bitrate - so this could still be larger than the original.

For smaller files, have you tried different Optimize... settings? Optimize for TV limits the file to 8000 kbps peaks, or the Custom options allow lower settings.

Another option would be a standalone tool like HandBrake, where x264 or x265 quality knobs are exposed. I suspect the file could be significantly smaller encoded with x265 and a slightly higher (lower quality) CRF.

[Robbie_UK]

Selecting a different bitrate option is probably the best way forward now.

What still isn’t clear to me is why the original quality option is now making such large files. This was part of my original question - it used to produce a file that matched the original quality and did not artificially seek an arbitrary bitrate. It does not produce a better transcode, only a larger file. Indeed, if there was a magic preset that turned a h254 TS file into a regular h264 MP4 without any transcoding I would be selecting that.

This remains a new and unexplained behaviour, distinct to that of many years to date. It still feels like a bug or an undesirable change.

[Volts]

If it has started using the VideoToolbox for transcodes, where previously it didn’t, that would explain at least part of the increased size. Whether it was using x264 before, or if it was avoiding transcoding entirely.

If you think Plex’s behavior is different now, you could temporarily try an older version of PMS. I would be curious to see if the Plex Transcoder commands have changed recently.

I do agree; In some cases Optimize → Original should simply remux into MP4 without transcoding. Maybe something has gone wrong with that logic? You could share server logs and we could look at the MDE entries.

Is there any possibility that the HDHomeRun-produced file has itself changed?

[Robbie_UK]

The HDHomeRun file looks to be the same as always. I’ve reset Plex back to default settings and restarted it and will run a few more Optimise sessions to see if that changes the behaviour. If not, I will try some older versions.

I did try the Custom option though and, for example, limiting the file to 8 Mbps peaks just produced a file that was set at 8Mbps throughout, much like the Original Quality setting producing a fixed 20 Mbps file. So for whatever reason my PMS is setting a fixed value when it should be at-or-below that value.

[Robbie_UK]

Ok, ran a few more test files and the results are the same - Plex ‘Original Quality’ preset is producing a fixed 20 Mbps transcode, whatever the quality level of the original:

Example:

American Ultra (2015), MPEG-TS, 4.517 Mbps, variable bit rate

Summary

General
Complete name : /Volumes/Video/Recordings/American Ultra (2015)/Plex Versions/Original Quality/American Ultra (2015).mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom/iso2/avc1/mp41)
File size : 16.7 GiB
Duration : 1 h 57 min
Overall bit rate : 20.3 Mb/s
Writing application : Lavf58.65.101

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings : CABAC / 1 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 1 frame
Format settings, GOP : M=1, N=6
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 1 h 57 min
Bit rate : 20.0 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.386
Stream size : 16.5 GiB (99%)
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Codec configuration box : avcC

Audio
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : mp4a-40-2
Duration : 1 h 57 min
Source duration : 1 h 57 min
Source_Duration_LastFrame : -20 ms
Bit rate mode : Constant
Bit rate : 256 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 216 MiB (1%)
Source stream size : 216 MiB (1%)
Language : English
Default : Yes
Alternate group : 1
mdhd_Duration : 7077483

I guess there is a bug in PMS.

[Robbie_UK]

Encoding details on ‘Optimised For TV’ setting shown below. To my eyes it looks like PMS is setting a Constant Rate Factor (CRF 16.0 in this case) and only constrained by the upper maximum bit rate (vbv_maxrate=8000 in this case). This is exactly what then happens as the encoder dutifully completes its instructions:

cabac=1 / ref=1 / deblock=1:0:0 / analyse=0x1:0 / me=hex / subme=0 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=4 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast _pskip=1/ chroma_qp_offset=0 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=10/
rc=crf / mbtree=1 / crf=16.0 / qcomp=0.60 / qpmin=0 / apmax=69 / apstep=4 / vbv_maxrate=8000 / vbv_bufsize=16000 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00

How do we submit bug reports?