Why transcode when tsmuxer will do?

For help and support with Universal Media Server in general
Forum rules
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
Post Reply
coolhand
Posts: 8
Joined: Sat Jul 18, 2015 8:39 pm

Why transcode when tsmuxer will do?

Post by coolhand » Sat Jul 18, 2015 9:07 pm

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 113 times
.

Any help would be greatly appreciated.

coolhand
Posts: 8
Joined: Sat Jul 18, 2015 8:39 pm

Re: Why transcode when tsmuxer will do?

Post by coolhand » Wed Aug 12, 2015 11:41 pm

Tickling thread

ExSport
Posts: 596
Joined: Wed Oct 10, 2012 1:57 am

Re: Why transcode when tsmuxer will do?

Post by ExSport » Fri Aug 14, 2015 12:29 am

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

coolhand
Posts: 8
Joined: Sat Jul 18, 2015 8:39 pm

Re: Why transcode when tsmuxer will do?

Post by coolhand » Sun Nov 08, 2015 2:25 pm

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).
Attachments
ums_dbg_transcode_by_default.zip
(88.68 KiB) Downloaded 99 times
ums_dbg_forced_tsmuxer.zip
(150.23 KiB) Downloaded 89 times

ExSport
Posts: 596
Joined: Wed Oct 10, 2012 1:57 am

Re: Why transcode when tsmuxer will do?

Post by ExSport » Wed Nov 11, 2015 4:47 am

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 :roll:
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? :mrgreen:

Nadahar
Posts: 1576
Joined: Tue Jun 09, 2015 5:57 pm

Re: Why transcode when tsmuxer will do?

Post by Nadahar » Wed Nov 11, 2015 5:00 am

There's not much I can answer here, but..
Don't know why one log has CLASS shown (red part) and other not :roll:
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.

User avatar
valib
Developer
Posts: 663
Joined: Fri Feb 08, 2013 3:11 am

Re: Why transcode when tsmuxer will do?

Post by valib » Wed Nov 11, 2015 9:07 am

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
Posts: 596
Joined: Wed Oct 10, 2012 1:57 am

Re: Why transcode when tsmuxer will do?

Post by ExSport » Wed Nov 11, 2015 10:52 am

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 8-)

coolhand
Posts: 8
Joined: Sat Jul 18, 2015 8:39 pm

Re: Why transcode when tsmuxer will do?

Post by coolhand » Tue Nov 17, 2015 7:53 pm

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
Posts: 8
Joined: Sat Jul 18, 2015 8:39 pm

Re: Why transcode when tsmuxer will do?

Post by coolhand » Sun Nov 22, 2015 1:06 pm

Retested with UMS 5.3.0 and the same issue occurs.

Post Reply