Hi Carl Eugen, I applied all suggested changes, but I still cannot reach higher than 16 FPS. This is my CPU: http://www.cpu-world.com/CPUs/K10/AMD-Athlon%20II%20X4%20631%20-%20AD631XWNZ... I believe a single 2.6 GHz core should be able to decode the stream (1920x1080@50FPS), and another one to encode it. So the 4 cores should be more, than enough. Please correct me if I am wrong. I am thinking about the following questions: - Is there a more robust tool than ffmpeg? - Am I using wrong parameters for ffmpeg? - Is this hardware not strong enough to do the job? I appreciate any suggestion. Best regards, Marton ________________________________ From: Carl Eugen Hoyos <cehoyos@ag.or.at> To: mencoder-users@mplayerhq.hu Sent: Friday, February 10, 2012 10:11 AM Subject: Re: [MEncoder-users] How to transcode MTS files recorded by Panasonic HDC-SD100 camera? Marton Sigmond <marton_sigmond <at> yahoo.com> writes:

The command that works so far is this: ffmpeg -y -i %in -threads 4 -deinterlace -f mpegts -r 25 -vcodec mpeg2video -s vga -aspect 16:9 -maxrate 1800k -b 1500k -qmin 3 -qmax 5 -buf size 4096k -mbd 2 -bf 2 -flags +4mv -trellis -aic -cmp 2 -subcmp 2 -g 300 -acodec libmp3lame -ar 48000 -ab 128k -ac 2 %out

Use a significantly higher value for threads (~10, higher if you have HT), try to remove 4mv (if that makes encoding faster), remove deinterlace (that is probably expensive), if you really need de-interlacing, use yadif, it should be optimised more. Carl Eugen _______________________________________________ MEncoder-users mailing list MEncoder-users@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mencoder-users

Thanks for the tips, now I am at 18 FPS with the following command: ffmpeg -y -threads 16 -i %in -f mpegts -r 25 -vcodec mpeg2video -s vga -aspect 16:9 -maxrate 1800k -b 1500k -bufsize 4096k -mbd 0 -acodec libmp3lame -ar 48000 -ab 128k -ac 2 %out Getting closer. :) Best regards, Marton ________________________________ From: Reimar Döffinger <Reimar.Doeffinger@gmx.de> To: Marton Sigmond <marton_sigmond@yahoo.com>; MEncoder usage discussions <mencoder-users@mplayerhq.hu> Sent: Monday, February 13, 2012 9:38 PM Subject: Re: [MEncoder-users] How to transcode MTS files recorded by Panasonic HDC-SD100 camera? On Tue, Feb 07, 2012 at 12:56:39PM -0800, Marton Sigmond wrote:

The command that works so far is this: ffmpeg -y -i %in -threads 4 -deinterlace -f mpegts -r 25 -vcodec mpeg2video -s vga -aspect 16:9 -maxrate 1800k -b 1500k -qmin 3 -qmax 5 -buf\ size 4096k -mbd 2 -bf 2 -flags +4mv -trellis -aic -cmp 2 -subcmp 2 -g 300 -acodec libmp3lame -ar 48000 -ab 128k -ac 2 %out

Why are you using all those options? At least half of them make no sense to me. For example specifying a bitrate but limiting the quantizer between 3 and 5 seems unlikely to give sensible results. And I didn't think that 4mv or aic actually exists for MPEG-2? And a keyframe interval of 300 I think is more than what is allowed for MPEG-2? Why using -mbd 2 (high quality) for a realtime encode? Why -threads 4 after -i, doesn't that mean that threading will only be used for the encode, but not the decode?

That is above 80 FPS. Following command is executed at 39 FPS: ffmpeg -threads 1 -i %out -f null -s vga -aspect 16:9 - This one is 42 FPS: ffmpeg -threads 1 -i %out -f null -r 25 - However when I combine the two it is only 19 FPS: ffmpeg -threads 1 -i %out -f null -r 25 -s vga -aspect 16:9 - Is it possible to run multiple ffmpeg instances in cascade (redirecting the output of one into the input of the next one)? I suppose each instance would naturally be running on a different CPU core. One could decode the input stream and convert to 25 fps (1), a second one could resize the stream (2), and a third one could encode the final mpeg stream. Or is there a mencoder alternative that automagically achieve this? Best regards, Marton ________________________________ From: Carl Eugen Hoyos <cehoyos@ag.or.at> To: mencoder-users@mplayerhq.hu Sent: Tuesday, February 14, 2012 1:26 AM Subject: Re: [MEncoder-users] How to transcode MTS files recorded by Panasonic HDC-SD100 camera? Marton Sigmond <marton_sigmond <at> yahoo.com> writes:

Thanks for the tips, now I am at 18 FPS with the following command: ffmpeg -y -threads 16 -i %in -f mpegts -r 25 -vcodec mpeg2video -s vga -aspect 16:9 -maxrate 1800k -b 1500k -bufsize 4096k -mbd 0 -acodec libmp3lame -ar 48000 -ab 128k -ac 2 %out

Getting closer. :)

How fast is ffmpeg -threads n -i file -f null - ? If that isn't fast enough you have to add skiploopfilter all (I don't know the exact ffmpeg command), the next step would be skipframe nonref (which skips all B-frames). Carl Eugen _______________________________________________ MEncoder-users mailing list MEncoder-users@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mencoder-users

You are the man, -sws_flags fast_bilinear works like a charm! I finally got 28-30 FPS. Strangely, the number of threads does not make any difference. Probably because of this:

[h264 @ 0x759d00]Cannot parallelize deblocking type 1, decoding such frames in sequential order

This is why I  had the three separate process idea. perf report dumped out this (just the head of it): # Samples: 1781874 # # Overhead         Command                       Shared Object  Symbol # ........  ..............  ..................................  ...... #     67.34%          ffmpeg  /usr/lib/libavcodec.so.52.72.2      [.] 0x00000000295472     13.97%          ffmpeg  /usr/lib/libswscale.so.0.11.0       [.] 0x000000000409b5      5.51%          ffmpeg  /usr/lib/libavcodec.so.52.72.2      [.] ff_h264_decode_mb_cabac      2.08%          ffmpeg  /usr/lib/libmp3lame.so.0.0.0        [.] 0x0000000002a9a1      1.65%          ffmpeg  /usr/lib/libavcodec.so.52.72.2      [.] ff_emulated_edge_mc      1.19%          ffmpeg  /usr/lib/libmp3lame.so.0.0.0        [.] L3psycho_anal_ns      0.78%          ffmpeg  /usr/lib/libavcodec.so.52.72.2      [.] ff_h264_pred_direct_motion      0.76%          ffmpeg  /lib/libc-2.11.1.so                 [.] memcpy      0.71%          ffmpeg  /usr/lib/libavcodec.so.52.72.2      [.] ff_epzs_motion_search      0.70%          ffmpeg  /usr/lib/libavcodec.so.52.72.2      [.] ff_estimate_p_frame_motion Thank you very much for the many useful hints you shared with me. Best regards, Marton ________________________________ From: Reimar Döffinger <Reimar.Doeffinger@gmx.de> To: Marton Sigmond <marton_sigmond@yahoo.com>; MEncoder usage discussions <mencoder-users@mplayerhq.hu> Sent: Tuesday, February 14, 2012 10:16 PM Subject: Re: [MEncoder-users] How to transcode MTS files recorded by Panasonic HDC-SD100 camera? On Tue, Feb 14, 2012 at 12:12:30PM -0800, Marton Sigmond wrote:

That is above 80 FPS.

Following command is executed at 39 FPS: ffmpeg -threads 1 -i %out -f null -s vga -aspect 16:9 -

This one is 42 FPS: ffmpeg -threads 1 -i %out -f null -r 25 -

However when I combine the two it is only 19 FPS: ffmpeg -threads 1 -i %out -f null -r 25 -s vga -aspect 16:9 -

You said your input is 50 fps. So the scaling halves the speed, and -r 25 halves it once more (because with -r 25 you need to decode 2 frames to encode one, and the fps value is in encoded frames). However it would have been more interesting to see the -threads 8 (or similar) results. perf record ffmpeg ... perf report might give an idea where most time is spent, too. Most likely you should start by choosing a simpler scaler. For mencoder/mplayer that is set with the -sws option, and the default is fast bilinear. Use -sws_flags fast_bilinear to choose the same for FFmpeg. For 720p input and on a dual-core Phenom changing -threads 1 and no sws_flags to -threads 8 -sws_flags fast_bilinear resulted in 80 fps -> 125 fps. Going to -sws_flags neighbor gave 130 fps.

One could decode the input stream and convert to 25 fps (1), a second one could resize the stream (2), and a third one could encode the final mpeg stream.

A large enough -threads value should cause decode to run on different cores than the rest. _______________________________________________ MEncoder-users mailing list MEncoder-users@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mencoder-users

On Wed, 15 Feb 2012, Reimar Döffinger wrote:

On Wed, Feb 15, 2012 at 12:30:05PM -0800, Marton Sigmond wrote:

...

    67.34%          ffmpeg  /usr/lib/libavcodec.so.52.72.2      [.] 0x00000000295472

The current version is libavcodec.so.54.

The 52 probably isn't a problem, but the 72 might be. There are really, really, really good reasons for not having 0.9 libraries and headers lying around where they can easily be found. I'd suggest upgrading to a 0.7.x release for general use, as relatively little can cope with the new API/ABI as yet, and trying a static 0.9 build (however, I've had problems recently with git versions...most notably an utter inability to decode H264). Note that my information concerning 0.9 is a few weeks old, so hopelessly out-of-date. YMMV, and all that.

On Fri, 17 Feb 2012, Carl Eugen Hoyos wrote:

R.L. Horn <lists <at> eastcheap.org> writes:

...

(however, I've had problems recently with git versions...most notably an utter inability to decode H264)

Are you really sure you posted this to ffmpeg-user or trac?

I'm quite sure I didn't. I don't follow ffmpeg-user for a start. What I was trying to do was get a new mplayer built. I tried a few git ffmpegs over two or three days (just letting the configure script grab them) without success, then, eventually, managed to make it work by building against the old 0.9 release. Even then, I had to correct some nonsensical #ifdefs in the ffmpeg source. At this point, I'd spent Grud knows how many hours on the project and was pretty disgusted. I figured I'd wait a couple of days, get new ffmpeg sources and, if that was a bust, submit a bug report. Then, I completely forgot about it until yesterday. I wrote, "utter inability," but that's not quite true. I had some YouTube .mp4s lying around that decoded fine, but everything else I tried resulted in thousands of "Concealing...errors" lines. The same was true for both mplayer and ffplay. Oh, and as for the not having 0.9 headers and libraries around, that's just about the API; nothing to do with any ffmpeg 0.9 deficiencies. Obviously, there's no harm in installing the versioned shared libraries.

On Fri, 17 Feb 2012, Carl Eugen Hoyos wrote:

Are you sure you did "svn up && ./configure && make"?)

C'mon, don't try to teach your grandma how to suck eggs. Of course I got new mplayer sources. I started over from scratch, in fact, because the old ones wouldn't update (it had been a while). It was pretty obvious that the problem was mine (such a gross defect simply couldn't go unnoticed). Reminded of the whole business, I went back and had another go (mplayer r34734). Same thing. As it turns out, my gcc was just too darned old to build the newest ffmpeg. Using gcc-4.6.2 worked like a charm. I reckon I'll make a lukewarm-priority bug report about it, but I somehow doubt that anyone's going to be too concerned.

...

then, eventually, managed to make it work by building against the old 0.9 release.

This is not supported and ...

...

Even then, I had to correct some nonsensical #ifdefs in the ffmpeg source.

will most certainly break soon without allowing such an easy fix.

I'm not suggesting that anyone else do it, just saying what happened. Look -- all of this is over a, largely inconsequential, aside. The only point I was trying, unsuccessfully it seems, to get across in the first place is that it's almost certainly not a good idea yet to get the latest ffmpeg and simply do a "./configure && make && make install" because you likely still need a 0.6 or 0.7 version to build other things.