PDA

View Full Version : CPU usage at 100% while transcoding; stops and starts



dpetr
08-16-2010, 07:38 AM
Hello Dennis. I've followed a thread on CPU usage but my circumstances are slightly different.

While transcoding a video, at times the CPU usage hits 100 % and the video playback stalls. Is this normal? When it hits 100%, ffmeg.exe is at 65% which appears to be normal, but then MezzmoMediaServer goes from 3 to 5% up to 27 to 30% and stays that way for anywhere between 3 to 15 seconds, thus maxing out the CPU near %100 and consequently playback stops. Again, would this be normal or is there a tweak I can apply? Once the transcoded video is complete, and saved to disk, the video plays normal so I might presume this to be normal while generating the file.

Thanks in advance.

Paul
08-16-2010, 09:24 AM
No, it's not normal to hit 100%, even when transcoding, unless you've got a single-core CPU. It's possible that you're experiencing one issue we've fixed here. Can you please send a message to support and I'll send you a patch to try.

dpetr
08-18-2010, 12:28 AM
Well Dennis, here's some more information. On a THIRD PC with very little software installed (Same OS Windows 7 x64) , using just the trial version, there's significantly less CPU usage. With the patched MediaServer.exe and the revised SonyBravia.prf file you had previously sent me, everything plays great and get this, the m2ts file that would not play goes straight to the TV with no transcoding, virtually no CPU usage! So I have no idea what's hosing those other two PC's. Maybe in the log files I sent, you can give me some ideas.

Paul
08-18-2010, 08:45 AM
Thanks for letting me know about it :) I'll get back to you via e-mail regarding the logs. We're working on fixing an issue at the moment and so I'm a bit slower to respond to support at this point unfortunately.

dpetr
08-18-2010, 09:18 AM
Just when things were going great. I shut down the computer that was working fine. 4 hours later, turn it back on, wouldn't you know it. Same condition: "File not found." I'm convinced something is happening with Mezzmo. It's beyond explanation. If you want, I can send you the log files from THAT computer, but I don't see the point. 3 PC's, all not working after reboot with the new prf file.

Here's what's happening. Any file that ffmpeg reports as mpeg4 video format, the vast majority of my movies (AVI mostly), will not play (Error "File Not found"). One video file I have, ffmpeg reports the video format as msmpeg4. It requires transcoding and it plays fine. The m2ts file that had no picture is a h264 video, that isn't transcoded and plays fine. Anything else I have in the h264 format works great, no transcoding. So apparently whatever is in that prf file you sent me doesn't like the mpeg4 format! This is the case on all 3 PC's.

I look forward to a resolution. Thanks. Dale.

RMerlin
08-18-2010, 12:10 PM
MPEG4 can be different codecs. For example, Xvid is considered an MPEG4 compliant codec. DivX is also considered MPEG-4, although it deviates slightly (if my memory's right, it's been a while since I've read on this) from the MPEG4 standard.

And to make matters even more confusing, MPEG4 is also referred to as a container (files with the .mp4 extension). Gotta love the Windows codec landscape :(

Can you post more details on files that don't work in addition to what ffmpeg reports, mention which MPEG4 codec they are using (Xvid, DivX, etc...)? This could help the folks at Conceiva pinpointing the issue. If you're not sure how, you can check the codec details using a tool such as MediaInfo (http://mediainfo.sourceforge.net/en).

Paul
08-18-2010, 12:37 PM
Yes, please post FFmpeg information on that file (in Mezzmo right-click on the file and use the "Get FFmpeg Information" command).

dpetr
08-19-2010, 03:33 AM
Hi Dennis. The latest Sony Bravia profile and server you sent have fixed the problem with MPEG4 format files. They now all get transcoded fine. No ffmpeg.exe crashes.

They all get transcoded into the exact same dimensions that the video in the file has and the Bravia displays them in those dimensions; that is, not full screen (like the AVC format that doesn't get transcoded) but bars top and bottom and somethines both sides. Perhaps this was intended. For me it's not an issue. I suppose it would be next to impossible to specify transcoding dimensions at the file properties level.

Thanks for fixing this Dennis! Great work.

Paul
08-19-2010, 08:57 AM
Thanks for letting me know - glad it works :)

(I'll repeat my reply to you that I've sent via e-mail here, just for the benefit of everyone)

The transcoded dimensions are controlled by the device profile (in the .prf file you’ll see <dimensions> that list all possible combinations) – I’ve found that the Bravia TVs sometimes don’t keep the correct aspect ratio on transcoded files, if the file does not fit into one of those dimensions. However, this is still under testing, so may change. If you wish, just remove all <dimensions> from the <format> in the .prf file, restart the server and now it should transcode to the native file's dimensions. It may or may not be better :) Please let me know how it goes, if you do try it.

dpetr
08-19-2010, 09:23 AM
Hello once again Dennis. Commenting out the <dimension> lines really didn't make any difference as far as I can see. One movie is in letterbox and has a very wide bar top and bottom, with or without <dimension>. Another has bars around all sides with or without. So evidently in my case, it's not making any difference. I left them in there based on your experience.

Paul
08-19-2010, 09:24 AM
Just one quick question - did you restart the server after changing the .prf file? If not, then you'll need to restart the server for the changes to take effect. Sorry that I didn't mention that originally.

dpetr
08-19-2010, 11:47 AM
I restarted the server and cleared out the transcoded files as well, to make sure it rebuilt them. I'll probably convert the most popular files to h264 and leave the rest alone. Playback of h264 files seems to be full screen. It's really not a problem for the rest of them.

By the way, transcoding seems quite a bit quicker as well for some reason. I've noticed that toward the end of a movie the sound slightly loses sync with the video by about a 1/2 second or so. When this happens on non-transcoded files, I can stop the playback and then start it again which resyncs everything. However, this doesn't seem to work as well with transcoded files. 1/2 second is not really a big deal and I only mentioned it so that you folks might want to check it out for a future version of the software.

It sure is good to know that the software you've just purchased has got some excellent support. By comparison, most software these days doesn't even come close.

Paul
08-19-2010, 01:19 PM
Does the audio synch issue appear on all transcoded files, or only on certain audio/video codec combination?

Another reason why dimensions may not change is if you have the same video codec in your original and transcoded files (e.g. only remuxing is taking place to change the container or convert the audio stream) - in this case the dimensions will stay as original. If you use the zoom/display feature on your TV's remote, does it make it properly fill the full screen?

dpetr
08-20-2010, 04:03 AM
The little that I have tested is insufficient to draw any conclusions. Not all transcoded files lose audio/video sync. Over the next few weeks or so, I'll try to write down my findings on some specific files and try to compile some sort of summary. It's not a big deal really. If the sync difference was say 3 seconds, that would be different.

I have another question for you though. I'd like to ask you if you have any profile planned for the Sony Home Theatre Model BDV-E570 or similar? It's DLNA capable but comes up Unknown Device on the Media Devices list. It seems to work with the "Generic 4" profile. Most everything seems to work fine except the non transcoded video files start and stop quite often, but I think this is likely because the unit is connected to a wireless network---I've just run out of ports on the back of the netwrok switch!

Paul
08-20-2010, 08:49 AM
Maybe you'll want to try the Sony BDP profile for it (with the latest patched server 2.1.8.13) - please send me an e-mail to support about it and I'll send the files to you.

caijv
03-06-2011, 11:10 AM
I also have a bdv-e570 running on XP PRO V 2001 SP3 and ffmpeg drives the CPU to 100% after about 1/2 minute of transcoding an avi file(ffmpeg stuff) below. I am using "SONY BDP (NTSC, NoDIVX) as the BPR. The movie keeps on going bac to the beginning, and if I have others in the same folder, then it begins to play the others, and the issue repeats, since I see ffmepg at 100%.
FFmpeg version git-c3897d7, Copyright (c) 2000-2011 the FFmpeg developers
built on Feb 28 2011 10:03:54 with gcc 4.4.2
configuration: --enable-memalign-hack --arch=x86 --target-os=mingw32 --cross-prefix=i686-mingw32- --enable-static --disable-shared --enable-zlib --disable-ffprobe --disable-ffplay --prefix=/media/windows/ffmpeg --extra-cflags=-U__STRICT_ANSI__ --enable-libmp3lame --enable-libx264 --enable-gpl --extra-libs='-lx264 -lpthread' --enable-runtime-cpudetect
libavutil 50. 39. 0 / 50. 39. 0
libavcodec 52.113. 2 / 52.113. 2
libavformat 52.102. 0 / 52.102. 0
libavdevice 52. 2. 3 / 52. 2. 3
libavfilter 1. 76. 0 / 1. 76. 0
libswscale 0. 12. 0 / 0. 12. 0
Input #0, avi, from 'D:\downloads\[ www.Speed.cd ] Agora 2009 DVDRip Xvid-DiVERSiTY\Agora 2009 DVDRip Xvid-DiVERSiTY.avi':
Metadata:
encoder : AVI-Mux GUI 1.17.8.3, Feb 16 201019:42:50
JUNK :
Duration: 02:01:39.80, start: 0.000000, bitrate: 812 kb/s
Stream #0.0: Video: mpeg4, yuv420p, 640x272 [PAR 1:1 DAR 40:17], 25 tbr, 25 tbn, 25 tbc
Stream #0.1: Audio: mp3, 48000 Hz, stereo, s16, 122 kb/s
Metadata:
title : VTS_01_1 T80 3_2ch 448Kbps DELAY 0ms
At least one output file must be specified


---> DB Level Info: -99

JamboUK
03-06-2011, 05:36 PM
I upgraded yesterday and although I haven't tested properly I noticed a couple of files stop and pause and the CPU sit at 100%. This wasn't happening before where the processor was normally around 60 - 70 (even on an older lower CPU spec'd - my processor has recently had an upgrade).

My machine is dual core and this is the first time I have seen transcoding struggle in this way. Is the problem back with the new version? Has the new build of FFmpeg introduced a problem? I noticed this using the Sony Bravia TV profile.

Paul
03-07-2011, 03:55 PM
Thanks for this feedback. A few other users have reported similar findings with v2.2 and we are looking into now.

mathew
03-24-2011, 11:50 AM
Dennis, I hope this thread isn't getting lost, because I am having the exact same problem with my Sony tv. Any solution yet?

Paul
03-24-2011, 12:33 PM
This has been fixed (and is available as a patch) for the Sony BDPs, but I wasn't aware that the TVs have the same/similar issue. If you wish, please send a message to support (at) conceiva (dot) com and I'll send you that patch and we'll see if it fixes your issue as well or if it's some other issue.

JamboUK
04-10-2011, 07:44 AM
It is the Sony Bravia TV I am having 100% CPU problems with too. I am using the Sony KDL profile. I can do a side by side comparison when transcoding a MP4 file as I also have a Sony BDP.

The file when transcoded for the Sony Bravia KDL TV has my server (which is adequately spec'd) sitting at 100% CPU and video play backs stops, stammers and skips as it struggles to transcode in time.

Same file. Same server but transcoded to my Sony BDP the CPU sits at 43% and playback works like a dream !

Why should this be so? Thanks.

Paul
04-11-2011, 09:10 AM
Most probably because for the BDP the file is remuxed (video is copied into a new container, as compared to fully recoding it for the TV). What sort of CPU do you have and what is FFmpeg information on that stuttering file? Generally, remuxing should take 10-25% of the CPU.

JamboUK
04-11-2011, 08:36 PM
Most probably because for the BDP the file is remuxed (video is copied into a new container, as compared to fully recoding it for the TV). What sort of CPU do you have and what is FFmpeg information on that stuttering file? Generally, remuxing should take 10-25% of the CPU.


I have noticed it on a few files now. Since the January/February upgrade really. That CPU use seems to be a more intensive but this file is the worst I have seen it on for a while. Answers to your questions below.

1.Pentium Dual Core 3.2GHz

2.FFmpeg version git-c3897d7, Copyright (c) 2000-2011 the FFmpeg developers
built on Feb 28 2011 10:03:54 with gcc 4.4.2
configuration: --enable-memalign-hack --arch=x86 --target-os=mingw32 --cross-prefix=i686-mingw32- --enable-static --disable-shared --enable-zlib --disable-ffprobe --disable-ffplay --prefix=/media/windows/ffmpeg --extra-cflags=-U__STRICT_ANSI__ --enable-libmp3lame --enable-libx264 --enable-gpl --extra-libs='-lx264 -lpthread' --enable-runtime-cpudetect
libavutil 50. 39. 0 / 50. 39. 0
libavcodec 52.113. 2 / 52.113. 2
libavformat 52.102. 0 / 52.102. 0
libavdevice 52. 2. 3 / 52. 2. 3
libavfilter 1. 76. 0 / 1. 76. 0
libswscale 0. 12. 0 / 0. 12. 0
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'H:\videos\films\************.mp4':
Metadata:
major_brand : isom
minor_version : 1
compatible_brands: isomavc1
creation_time : 2011-03-29 20:07:43
Duration: 02:26:05.29, start: 0.000000, bitrate: 3320 kb/s
Stream #0.0(und): Video: h264 (High), yuv420p, 1920x800 [PAR 1:1 DAR 12:5], 2999 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 47.95 tbc
Metadata:
creation_time : 2011-03-29 20:07:43
Stream #0.1(eng): Audio: aac, 48000 Hz, 5.1, s16, 317 kb/s
Metadata:
creation_time : 2011-03-29 20:10:28
At least one output file must be specified


---> DB Level Info: 40

Paul
04-12-2011, 08:41 AM
Yes, a dual-core is not enough for high-def transcoding in real-time. We recommend (it's a must, actually) a minimum of a quad-core, or even better an i5 or i7 with 8 threads (4 cores).

Another thing to try is to remove dimensions from the device profile - that will then remux the video, but the device may not display it in proper aspect ratio.

JamboUK
04-12-2011, 04:50 PM
Yes, a dual-core is not enough for high-def transcoding in real-time. We recommend (it's a must, actually) a minimum of a quad-core, or even better an i5 or i7 with 8 threads (4 cores).

Another thing to try is to remove dimensions from the device profile - that will then remux the video, but the device may not display it in proper aspect ratio.

So although sharing a large number of similarities the Sony KDL Bravia TV's and the Sony BDP Blu-ray player handle this file entirely differently?

How come an MP4 carrier is more prone to this than other Hi Def carriers where I have a greater degree of success (virtually 100% in fact)?

Paul
04-13-2011, 09:35 AM
Yes, the TV and BDP are a bit different. What we found in our testing is that the TV (at least some models) are more picky about video dimensions and thus require a full re-transcode more often to fit within the expect dimensions (and aspect ratio). The BDP is more forgiving and will adjust the video better, so less full transcoding is needed and more remuxing can be done, which is a lot quicker and requires virtually no CPU at all.

I wouldn't say that the MP4 container is more prone, probably just the set of files that you have with those dimensions.