PDA

View Full Version : FFMPEG fails to shut down process after transcoding M2TS on Sony KDL-50w829



ripstop
02-12-2015, 10:52 PM
I have had this issue with a few other applications that use transcoding but I thought I might ask the question here. All of the displaying of pictures and music from the WHS2011 platform to my Sony TV work fine. The actual playing of transcoded bluray material like the M2TS files does struggle a bit with very stuttering playback. Connection is by direct Ethernet and 1GBit connection. I have tried 100MBit and its slightly better. I am also using the correct profile Sony Bravia KDL W.

Also I notice that if I stop the playback the ffmpeg process still carries on and consumes a fair amount of CPU. Is there a way to verify that it shuts down properly after sending the "Stop" signal to the TV?

I have upgraded the server (HP EX490) with an Intel Xeon quad core L5420 (Modded LGA-771 socket) and so CPU power isn't really an issue but as I said playback is not that smooth. So the question is why the ffmpeg process doesn't stop and why does it stutter? Any help appreciated.

Example movie

ffmpeg version N-66094-gbb8b752 Copyright (c) 2000-2014 the FFmpeg developers
built on Sep 4 2014 16:23:51 with gcc 4.8.2 (GCC)
configuration: --enable-memalign-hack --arch=x86_64 --target-os=mingw32 --cross-prefix=x86_64-w64-mingw32- --enable-static --disable-shared --enable-zlib --disable-postproc --prefix=/home/peter/ffmpeg/build/gpl64 --enable-libmp3lame --enable-libx264 --enable-gpl --extra-libs='-lx264 -lpthread' --enable-runtime-cpudetect --extra-cflags=-I/home/peter/cc32/include --extra-ldflags=-L/home/peter/cc64/lib --pkg-config=pkg-config --disable-w32threads --enable-libvpx --enable-libvorbis
libavutil 54. 7.100 / 54. 7.100
libavcodec 56. 1.100 / 56. 1.100
libavformat 56. 4.100 / 56. 4.100
libavdevice 56. 0.100 / 56. 0.100
libavfilter 5. 0.103 / 5. 0.103
libswscale 3. 0.100 / 3. 0.100
libswresample 1. 1.100 / 1. 1.100
[mpegts @ 00000000002debe0] Failed to open codec in av_find_stream_info
Input #0, mpegts, from 'F:\ServerFolders\Movies2011\9\9.bluray.M2TS':
Duration: 01:19:24.26, start: 4200.000000, bitrate: 35412 kb/s
Program 1
Stream #0:0[0x1011]: Video: vc1 (Advanced) (VC-1 / 0x312D4356), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 23.98 tbr, 90k tbn, 47.95 tbc
Stream #0:1[0x1100](eng): Audio: dts (DTS-HD MA) ([134][0][0][0] / 0x0086), 48000 Hz, 5.1(side), fltp, 1536 kb/s
At least one output file must be specified

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


---> DB Level Info: 3, 3
---> Frame rate: 23.98
---> Aspect ratio: 16:9 PAR=1:1
---> Duration: 01:19:24


Cheers
Rip.

Paul
02-13-2015, 08:51 AM
Hi Rip,

By default, Mezzmo server will continue to transcode the file you are streaming even when you stop playing the video. It does this so that the fully transcoded video is available the next time you play it. Mezzmo stores your transcoded files in the transcoding folder (see Transcoding Settings dialog to set the location of this folder and the maximum size of this folder).

If you want to stop transcoding the file when you stop playing it on your device, then you can set this in Mezzmo. Go to the Transcoding Settings dialog and uncheck the "Complete partially transcoded audio/video files in background" checkbox. When you stop playing the video on your device, Mezzmo server will stop transcoding it after a few minutes.

If you are getting stuttering when playing your ripped Blu-rays, then the most likely reason is due to the high video bitrate (35Mb/sec). See this FAQ for possible reasons and solutions - http://forum.conceiva.com/showthread.php/6538-Tutorial-How-to-reduce-excessive-stuttering-or-buffering-when-streaming-videos.

ripstop
02-14-2015, 02:53 AM
Hiya,

Ok so now I know a little more how to tweak things, thanks for that, and have played around with a number of M2TS files. Although the bitrates are variable and *could* be as high as 30000 to 40000kb/s maximum as seen in the file details, often the ffmpeg shows its only streaming at around 6000 or 8000kb/s . Some play much better than others but the problem seems to occur after the file has been playing for a short time. This time could be anything from 45 seconds to 10 minutes. I checked the ffmpeg file output and it seems there is an artificial *glass* ceiling of 10000 kb/s at which point it can't transcode any faster.

I did see these in the ffmpeg log file and the bitrate wouldn't go any higher.

frame= 786 fps= 21 q=2.1 size= 36114kB time=00:00:32.88 bitrate=8995.6kbits/s
frame= 795 fps= 21 q=4.8 size= 37032kB time=00:00:33.20 bitrate=9135.4kbits/s
frame= 805 fps= 21 q=7.7 size= 37572kB time=00:00:33.65 bitrate=9145.3kbits/s
[truehd @ 0000000002c95340] too many audio samples in frame
Error while decoding stream #0:1: Invalid data found when processing input
[truehd @ 0000000002c95340] too many audio samples in frame
Error while decoding stream #0:1: Invalid data found when processing input
[truehd @ 0000000002c95340] substream 1 length mismatch
Error while decoding stream #0:1: Invalid data found when processing input
Last message repeated 4 times
[truehd @ 0000000002c95340] too many audio samples in frame
Error while decoding stream #0:1: Invalid data found when processing input
Last message repeated 2 times
[truehd @ 0000000002c95340] too many audio samples in frame
Error while decoding stream #0:1: Invalid data found when processing input
Last message repeated 4 times

I have pretty good Xeon quad core 2.5Ghz processor which runs about 60 to 70% loaded and manages fine initially but after the ffmpeg bit rate hits around 9000 to 10kb/s the streaming starts to fail. At some points the file stops streaming and loads the next file in the Mezzmo listing.

Do I still have a CPU processing issue or something else? I have tried all combinations of H264, VC1 and TrueHD abd DTS-MA. The VC1 files tend to be worse but all get worse the longer the streaming runs.

Cheers
Rip.

Paul
02-14-2015, 11:12 AM
I suggest you pre-transcode one of your video files that is sometimes stuttering and then stream it. In this case, Mezzmo will stream the already transcoded file directly to your device without any transcoding taking place. You will then be able to determine if the stuttering is caused by transcoding on-the-fly. If the transcoded file still stutters, then it could be due to a high video bitrate where you device's firmware cannot decode & play the video fast enough. See this FAQ for notes about pre-transcoding - http://forum.conceiva.com/showthread.php/6025-Tutorial-Pre-transcoding-Files. Let us know the results.