Why transcode when tsmuxer will do?

[coolhand]

I've been playing around with manually re-muxing some of my .mkv files to try to satisfy the conditions for UMS to play the file (to a PS3) using tsmuxer, rather than transcoding to MPEG-2 using ffmpeg (default configuration). This has predominantly meant removing English subtitles from files where they aren't required, or just re-muxing the .mkv file with a newer version of MKVToolNix (to get around issues like compression set on AC3 audio tracks by default in older .mkv files).

I've stumbled across a file that I just cannot get UMS to re-mux by default, instead always choosing to transcode to MPEG-2. I've stripped all but the AVC/MPEG4 video (level 4.1) and DTS audio track (English). To get it to use tsmuxer, I have to go thru the #TRANSCODE# menu and manually select the last option "[tsMuxer] [Audio: DTS/English]".

Is anyone familiar with UMS' log output, and the logic that selects whether transcoding is required, able to explain this?
Debug logs for the default playback (transcode) and forced tsmuxer playback are attached below.

debug.zip

Debug logs

(26.74 KiB) Downloaded 499 times

.

Any help would be greatly appreciated.

[coolhand]

Tickling thread

[ExSport]

Switch log to TRACE mode. Your log is missing critical parts to see why transcoding is forced.
Check red part above your post

[coolhand]

TRACE logging attached, as requested. My apologies for not reading the Problem Reporting Guidelines properly.
Files are attached for the default case (transcoded to MPEG-2) and the case where i forced remuxing using TSMuxer from the #TRANSCODE# menu (which works perfectly).

[ExSport]

Don't have much time to browse your log deeply but I spotted two weird things.
Log where tsMuxeR is not used shows log differently against the other log with same UMS version where tsMuxeR is forced:

TRACE 2015-11-08 13:32:50.525 [New I/O worker #8] net.pms.encoders.FFMpegVideo

Don't know why one log has CLASS shown (red part) and other not
Anyway in log where tsMuxeR should be used but it is not I can see:

Code: Select all

TRACE 2015-11-08 13:32:50.525 [New I/O worker #8] Not muxing the video stream with tsMuxeR via FFmpeg because the video stream is not muxable to this renderer

I don't know if there were any changes in code regarding this check so can't say what is the root cause without looking into code:

Code: Select all

DEBUG 2015-11-08 13:32:50.447 [New I/O worker #8] Reading ffmpeg_mux_tsmuxer_compatible: true (default: false)
TRACE 2015-11-08 13:32:50.447 [New I/O worker #8] Format "mpegts" failed to match supported line f:mpegps     v:mpeg1|mpeg2|mp4|h264   a:ac3|lpcm           m:video/mpeg
TRACE 2015-11-08 13:32:50.447 [New I/O worker #8] Matched support line f:mpegts     v:mpeg1|mpeg2|mp4|h264   a:ac3|lpcm|mpa       m:video/mpeg
DEBUG 2015-11-08 13:32:50.447 [New I/O worker #8] Starting C:\Program Files (x86)\Universal Media Server\win32\ffmpeg64.exe -i D:\Incoming\HD Movies\Kung.Fu.Panda.2008.mkv -vframes 1 -c:v copy -f h264 -bsf h264_mp4toannexb -an -y pipe:
TRACE 2015-11-08 13:32:50.447 [New I/O worker #8] Successfully initialized buffer to 1,048,576 bytes.
DEBUG 2015-11-08 13:32:50.447 [New I/O worker #8] Attaching thread: ffmpeg64.exe-4
DEBUG 2015-11-08 13:32:50.509 [ffmpeg64.exe-4-2] ffmpeg version N-74645-g4c39892 Copyright (c) 2000-2015 the FFmpeg developers
DEBUG 2015-11-08 13:32:50.509 [ffmpeg64.exe-4-2]   built with gcc 4.9.3 (GCC)
...stripped...
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2] Input #0, matroska,webm, from 'D:\Incoming\HD Movies\Kung.Fu.Panda.2008.mkv':
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]   Metadata:
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]     title           : Kung Fu Panda
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]   Duration: 01:32:09.46, start: 0.000000, bitrate: 9012 kb/s
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]     Stream #0:0(eng): Video: h264 (High), yuv420p, 1920x810, SAR 1:1 DAR 64:27, 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]     Metadata:
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]       BPS             : 7500320
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]       BPS-eng         : 7500320
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]       DURATION        : 01:32:09.436000000
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]       DURATION-eng    : 01:32:09.436000000
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]       NUMBER_OF_FRAMES: 132574
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]       NUMBER_OF_BYTES : 5184067860
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]     Stream #0:1(eng): Audio: dts (DTS), 48000 Hz, 5.1(side), fltp, 1536 kb/s (default)
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]     Metadata:
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]       BPS             : 1509747
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]       DURATION        : 01:32:09.461000000
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]       NUMBER_OF_FRAMES: 518386
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]       NUMBER_OF_BYTES : 1043511018
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2] Output #0, h264, to 'pipe:':
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]   Metadata:
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]     title           : Kung Fu Panda
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]     encoder         : Lavf56.40.101
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]     Stream #0:0(eng): Video: h264, yuv420p, 1920x810 [SAR 1:1 DAR 64:27], q=2-31, 23.98 fps, 23.98 tbr, 23.98 tbn, 23.98 tbc (default)
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]     Metadata:
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]       BPS             : 7500320
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]       DURATION        : 01:32:09.436000000
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]       NUMBER_OF_FRAMES: 132574
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]       NUMBER_OF_BYTES : 5184067860
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2] Stream mapping:
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2]   Stream #0:0 -> #0:0 (copy)
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2] Press [q] to stop, [?] for help
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2] frame=    1 fps=0.0 q=-1.0 Lsize=       1kB time=-00:00:00.04 bitrate=N/A    
DEBUG 2015-11-08 13:32:50.525 [ffmpeg64.exe-4-2] video:1kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%
TRACE 2015-11-08 13:32:50.525 [New I/O worker #8] EOF
TRACE 2015-11-08 13:32:50.525 [New I/O worker #8] Ready to Stop: true
TRACE 2015-11-08 13:32:50.525 [New I/O worker #8] Not muxing the video stream with tsMuxeR via FFmpeg because the video stream is not muxable to this renderer

[/size]If problem is with any file you tested and also with latest UMS (sub)version then definitely it is bug somewhere
FFmpeg and MediaInfo doesn't show anything weird with video track:

Code: Select all

FFmpeg:
Stream #0:0(eng): Video: h264 (High), yuv420p, 1920x810, SAR 1:1 DAR 64:27, 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)

Code: Select all

MediaInfo:
container: mkv, bitrate: 9012419, size: 6229227273, video tracks: 1, audio tracks: 1, video codec: h264, duration: 01:32:09.00, width: 1920, height: 810, frame rate: 23.976, thumb size: 2032, mime type: video/x-matroska, attached fonts: false, file title from metadata: Kung Fu Panda	Audio track id: 0, lang: en, audio codec: DTS, sample frequency:48000, number of channels: 6, bits per sample: 24

[/size]
@SubJunk, valib, infidel, Nadahar, SharkHunter: Did you reproduce similar behavior or remember any change in code which should be the culprit without need to check the code?

[Nadahar]

There's not much I can answer here, but..

Don't know why one log has CLASS shown (red part) and other not

When I did the log system overhaul I made a rule for forced trace only, where the "full" log pattern is also forced. That includes class. It is not activated simply by using "trace" log level, it is activated only when UMS is started in "forced trace" mode like when you choose to restart in trace mode from the Logs tab or when you start UMS with the "trace" argument.

[valib]

Try to change in the Sony-PlayStation3.conf line

Code: Select all

Supported = f:mpegts     v:mpeg1|mpeg2|mp4|h264   a:ac3|lpcm|mpa       m:video/mpeg

to

Code: Select all

Supported = f:mpegts     v:mpeg1|mpeg2|mp4|h264   a:ac3|lpcm|mpa|dts       m:video/mpeg

[ExSport]

What I saw in log was that video was detected as supported and also audio but at last UMS decided that video is not muxable.
Also in log I spotted that DTS audio is copied as is, video transcoded and all together muxed with rsMuxeR so it seems to me audio is not the culprit

[coolhand]

The change to Sony-Playstation3.conf suggested by @valib resulted in no audio being sent to the PS3, and the video still be transcoded to MPEG-2 by default.

[coolhand]

Retested with UMS 5.3.0 and the same issue occurs.