CPU usage at 100% while transcoding; stops and starts

[JamboUK]

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]

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]

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]

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]

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]

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.