Transcoding too slow and doesn't make sense

[bloodstar23]

So I've started using Meezmo because my TV won't recognize the .mkv files I'm trying to play. That's good and all, so why is it that the transcoding process is trying to trancode an MKV file...into a matroska media file (an mkv file)? It appears to work, but that just doesn't make a whole lot of sense to me. That aside, when I first installed the program and started transcoding the files, it was running at 80-120 FPS, which was good. Then suddenly, out of the blue, the rate dropped to around 16 FPS, which is worthless. I can't stream movies at that rate. If I can't get this thing working properly, I have no reason to buy it. I'd just as well convert the files to a usable format myself.

I have an i7 2600K 3.4GHz CPU and 16 GB of high performance RAM. My system should be more than enough to transcode at streaming pace, and yet it doesn't work.

This is the ffmpeg info for the file I'm trying to transcode currently:

ffmpeg version N-46003-gfa48da1 Copyright (c) 2000-2012 the FFmpeg developers
built on Oct 25 2012 12:37:27 with gcc 4.6.2 (GCC)
configuration: --enable-memalign-hack --arch=x86 --target-os=mingw32 --cross-prefix=i686-w64-mingw32- --enable-static --disable-shared --enable-zlib --disable-postproc --prefix=/home/peter/ffmpeg/build/gpl --enable-libmp3lame --enable-libx264 --enable-gpl --extra-libs='-lx264 -lpthread' --enable-runtime-cpudetect --extra-cflags=-I/home/peter/cc/include --extra-ldflags=-L/home/peter/cc/lib --pkg-config=pkg-config --disable-w32threads --enable-zlib
libavutil 52. 0.100 / 52. 0.100
libavcodec 54. 69.100 / 54. 69.100
libavformat 54. 34.100 / 54. 34.100
libavdevice 54. 3.100 / 54. 3.100
libavfilter 3. 20.105 / 3. 20.105
libswscale 2. 1.101 / 2. 1.101
libswresample 0. 16.100 / 0. 16.100
Input #0, matroska,webm, from 'You don't need my directory:\[ANE] Bakemonogatari [BDRip 1080p x264 FLAC]\[ANE] Bakemonogatari - Ep05 [BDRip 1080p x264 FLAC].mkv':
Metadata:
title : Mayoi Snail - Part 3
creation_time : 2011-10-29 15:05:07
Duration: 00:26:11.07, start: 0.000000, bitrate: 5030 kb/s
Chapter #0.0: start 0.000000, end 37.037000
Metadata:
title : Prologue
Chapter #0.1: start 37.037000, end 127.044000
Metadata:
title : Opening
Chapter #0.2: start 127.044000, end 737.070000
Metadata:
title : Part A
Chapter #0.3: start 737.070000, end 1417.499000
Metadata:
title : Part B
Chapter #0.4: start 1417.499000, end 1525.023000
Metadata:
title : Epilogue
Chapter #0.5: start 1525.023000, end 1571.070000
Metadata:
title : Preview
Stream #0:0(eng): Video: h264 (High 10), yuv420p10le, 1920x1080, SAR 1:1 DAR 16:9, 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
Stream #0:1(jpn): Audio: flac, 48000 Hz, stereo, s16 (default)
Stream #0:2(eng): Subtitle: ssa (default)
Metadata:
title : gg/qIIq
Codec 0x18000 is not in the full list.
Stream #0:3: Attachment: unknown_codec
Metadata:
filename : BellGothic-Black.otf
mimetype : application/x-truetype-font
Codec 0x18000 is not in the full list.
Stream #0:4: Attachment: unknown_codec
Metadata:
filename : BlissProOT-Regular.otf
mimetype : application/x-truetype-font
Codec 0x18000 is not in the full list.
Stream #0:5: Attachment: unknown_codec
Metadata:
filename : cac-moose.ttf
mimetype : application/x-truetype-font
Codec 0x18000 is not in the full list.
Stream #0:6: Attachment: unknown_codec
Metadata:
filename : calibri.ttf
mimetype : application/x-truetype-font
Codec 0x18000 is not in the full list.
Stream #0:7: Attachment: unknown_codec
Metadata:
filename : CHANC__.TTF
mimetype : application/x-truetype-font
Codec 0x18000 is not in the full list.
Stream #0:8: Attachment: unknown_codec
Metadata:
filename : Complete in Him.ttf
mimetype : application/x-truetype-font
Codec 0x18000 is not in the full list.
Stream #0:9: Attachment: unknown_codec
Metadata:
filename : erasdust.ttf
mimetype : application/x-truetype-font
Codec 0x18000 is not in the full list.
Stream #0:10: Attachment: unknown_codec
Metadata:
filename : fansubBlock.ttf
mimetype : application/x-truetype-font
Codec 0x18000 is not in the full list.
Stream #0:11: Attachment: unknown_codec
Metadata:
filename : GaramondPremrPro-Capt.otf
mimetype : application/x-truetype-font
Codec 0x18000 is not in the full list.
Stream #0:12: Attachment: unknown_codec
Metadata:
filename : JacobyICG-Light.otf
mimetype : application/x-truetype-font
Codec 0x18000 is not in the full list.
Stream #0:13: Attachment: unknown_codec
Metadata:
filename : LT.TTF
mimetype : application/x-truetype-font
Codec 0x18000 is not in the full list.
Stream #0:14: Attachment: unknown_codec
Metadata:
filename : LT_1.ttf
mimetype : application/x-truetype-font
Codec 0x18000 is not in the full list.
Stream #0:15: Attachment: unknown_codec
Metadata:
filename : LT_70142.ttf
mimetype : application/x-truetype-font
Codec 0x18000 is not in the full list.
Stream #0:16: Attachment: unknown_codec
Metadata:
filename : moonp.ttf
mimetype : application/x-truetype-font
Codec 0x18000 is not in the full list.
Stream #0:17: Attachment: unknown_codec
Metadata:
filename : Profile-Regular.otf
mimetype : application/x-truetype-font
Codec 0x18000 is not in the full list.
Stream #0:18: Attachment: unknown_codec
Metadata:
filename : take_out_the_garbage.ttf
mimetype : application/x-truetype-font
Codec 0x18000 is not in the full list.
Stream #0:19: Attachment: unknown_codec
Metadata:
filename : AbyssEPTitleFont.ttf
mimetype : application/x-truetype-font
Codec 0x18000 is not in the full list.
Stream #0:20: Attachment: unknown_codec
Metadata:
filename : AbyssTSFont.ttf
mimetype : application/x-truetype-font
Codec 0x18000 is not in the full list.
Stream #0:21: Attachment: unknown_codec
Metadata:
filename : AntiqueOliveOil.ttf
mimetype : application/x-truetype-font
Codec 0x18000 is not in the full list.
Stream #0:22: Attachment: unknown_codec
Metadata:
filename : BAARS___.TTF
mimetype : application/x-truetype-font
Codec 0x18000 is not in the full list.
Stream #0:23: Attachment: unknown_codec
Metadata:
filename : BAKESBR.TTF
mimetype : application/x-truetype-font
At least one output file must be specified

<MEZZMO>: Child process ended with code: 109, ExitCode=1


---> DB Level Info: 50, 110
---> Frame rate: 23.98
---> Aspect ratio: 16:9


Also, I can't be sure until I'm done with one transcode, but from the little bit that did stream to the TV before it crashed, it doesn't look like the subtitles were working either.

Oh and one more thing. Whenever I try to tell it to pre-transcode a single folder, it instead queues up every single folder in the parent directory, which is really annoying given that the said directory has over 570 video files.

Edit: The Device I'm transcoding to is named [HTS]E6500 by the program, and is an AQUOS C8470U.

Edit2: I also noticed that it's running multiple instances of ffmpeg.exe*32. There's one that remains fairly solid and uses about a gig of RAM, and then another instance that pops up and goes away randomly, eating up about 200MB of ram and then vanishing a second later.

[bloodstar23]

So, as expected, after spending all night to transcode the series, the subtitles don't work either. So far this software is looking just fantastic. Nothing in it works as described.

EDIT: Did not mean to quote that first post. Anyway, I may have figured out how to force the subtitles to work (even though I shouldn't have to do a workaround, the software should be able to figure it out itself), but my main fear is that extracting the subtitles and them burning them is going to remove the formatting, causing the subtitles to look awful. This particular anime has subtitles all over the screen and it's probably going to be a mess now. I'll let you know in two hours. Because, you know, it's still transcoding at a snail's pace.

[bloodstar23]

So yeah, I figured out how to force subtitles to work, but as I feared, it completely removes all formatting of the subtitles and just shoves everything at the bottom of the screen. It's livable, but certainly not ideal. Now the problem that persists is the ridiculously slow speed, it makes it impossible for me to actually stream these. Although I suppose the subtitle issue makes it impossible to stream them anyway.

[Paul]

...so why is it that the transcoding process is trying to trancode an MKV file...into a matroska media file (an mkv file)?

The device profile that is assigned to your DLNA device in the Media Devices dialog in Mezzmo says that MKV is supported. Your original MKV may be transcoded into another MKV for many reasons - the codecs within your original MKV may not be compatible on your device, the video bitrate may be too high, an external subtitle may be embedded into the MKV file, etc.

What is the device profile assigned to your device in the Media Devices dialog? What is the device's manufacturer and model?


...removes all formatting of the subtitles and just shoves everything at the bottom of the screen.

The current version of Mezzmo does place subtitles at the bottom. We'll certainly look at the positional data for subtitles in a future version of Mezzmo. Please email us one of your subtitle files with the positional data and we'll look into it.


...slow speed

Try this: Right-click on a video in Mezzmo that you have not yet pre-transcoded and click 'Pre-transcode File'. Pre-transcode the video for your device. As it is pre-transcoding, go to the Transcoding pane and right-click on the transcoding file and click View FFmpeg Output. Email us this information to support [at] conceiva [dot] com & we'll see why it may be so slow.

[bloodstar23]

The device profile is Samsung C, and email sent.

Note: The subtitle file I sent you is an extracted subtitle file from the anime with the proper formatting. If your extraction process automatically rips out formatting, you won't see the formatting in that file. If that's the case, I wouldn't know how to extract the embedded subtitle file without disrupting the integrity of the formatting.

[Paul]

Thanks - got your email & subtitle file. When you extract an embedded subtitle from your MKV file using Mezzmo (to do this, click Extract Subtitles button on Properties dialog (Subtitles tab)), your embedded subtitle channel is extracted and saved as an external subtitle file without any changes (i.e. the positional data is kept as-is). Then, if your device supports displaying that external subtitle format, Mezzmo will stream that external subtitle file as-is (i.e. with positional data) and your device can display the subtitles as you expect.

If your device does not support that external subtitle format, then you can let Mezzmo burn the subtitles into the video. In the current version of Mezzmo (v3.0.2.0), Mezzmo does not (yet) use the positional data for formatting the burnt subtitles into the video. We understand the importance of the positional data for displaying subtitles and we may look at implementing this in a future version.

[bloodstar23]

Will the Samsung C profile recognize streaming of external subtitles? I just burned them to the video by default because I assume if the embedded subtitles didn't work, the same embedded subtitles that were then extracted wouldn't work either. If so, that means I'll have to delete everything I already pre-transcoded though and re-do the pre-transcode without the subtitles being burned in...also, is the default location of the subtitles where they need to be for them to be loaded as external subtitles, or do they need to be in a different location?

[Paul]

The Samsung C device profile has support for srt, subviewer, sami, mpg4 & microdvd external subtitle formats.

By default, Mezzmo will pick up your external subtitle files when they are alongside your video files in the same folder with the same name - e.g. c:\videos\inception.mkv, c:\videos\inception.smi, c:\videos\inception.en.srt, etc. You can specify an alternate folder for storing/finding external subtitle files in the Options dialog (Subtitles -> Advanced page).

[bloodstar23]

Alright, and any progress on why it's so slow yet?

[Paul]

...any progress on why it's so slow yet?

A few reasons: Your original video was an 1920x1080 MKV (h264, flac) HD Video. (i) You chose to burn your subtitles into it for streaming. As such, Mezzmo must re-encode your h264 video channel in order to burn the subtitles into the video frames, (ii) flac is not supported by your TV, so Mezzmo re-encodes your flac audio channel to AC3, and (iii) the h264 level (High 10) is not supported by your TV, so Mezzmo lowers it so it is supported.

The slowest part of this process is (i), so if you stream your external subtitles rather than burning them, then transcoding should be faster.

[bloodstar23]

A few reasons: Your original video was an 1920x1080 MKV (h264, flac) HD Video. (i) You chose to burn your subtitles into it for streaming. As such, Mezzmo must re-encode your h264 video channel in order to burn the subtitles into the video frames, (ii) flac is not supported by your TV, so Mezzmo re-encodes your flac audio channel to AC3, and (iii) the h264 level (High 10) is not supported by your TV, so Mezzmo lowers it so it is supported.

The slowest part of this process is (i), so if you stream your external subtitles rather than burning them, then transcoding should be faster.

Even without burning subtitles, I'm still seeing 20 FPS, too slow to stream. When it comes to II and III, isn't that what your program is made to do? If I didn't need to convert the file to something the TV can use, I wouldn't need to use Mezzmo. Mezzmo never uses more than 30% of my CPU and never more then 10% of memory, even though it's set to very high priority. More or less, the program isn't doing its job. It's transcoding very slowly when it has more than enough resource to transcode quickly.

Also I just tested it, and using an extracted subtitle as an external subtitle file does NOT keep the positional data. It rips all the formatting and shoves everything to the bottom of the screen. It looks like the moment you hit the "convert" button on the extraction page, it kills the formatting completely, and if I try to leave it as the extracted .ass file without converting, it simply doesn't stream it. No subtitles show up.

[Paul]

Hi bloodstar23,

It's best we see what's happening when transcoding is taking place. Please turn on logging (see http://forum.conceiva.com/showthread.php/419-FAQ-How-to-turn-on-diagnostic-logging) and restart your Mezzmo server. Transcode the video you mention and, when it finishes, stop your Mezzmo server and exit Mezzmo. Zip up all the logs and email them to us at support [at] conceiva [dot] com.

When you convert your .ass subtitle to .srt, then you will lose positional data since .srt does not support positional data.

[bloodstar23]

Alright transcoding with logging on now. And if that's the case, how do I make it work with the .ass subtitles? It won't recognize them as external subtitles, it only recognizes them once I convert them to .srt subtitles.

[Paul]

Thanks for sending us the logs. We'll check them out and report back shortly.

Given your TV does not streaming & displaying external .ass subtitle files, then in the current version of Mezzmo (v3.0.2.0) you are left with either converting them to .srt (but .srt has no positional data) or burning them into the video (but the current version of Mezzmo burns subtitles at the bottom). Sorry :(

[bloodstar23]

Sooo any word on why it's so slow?

[Paul]

Not as yet - sorry for the delay. We've been analyzing and fixing a few other issues that have taken longer than expected to track down. We'll get to your issue very soon & report back. Thanks for your patience.