Exploring Software-Encode h.264 Options for Mobile Atom-Based Solution

[azcoder]

Exploring Software-Encode h.264 Options for Mobile Atom-Based Solution

For a mobile surveillance application, we have traditionally relied upon hardware encoders, for speed and power/heat reasons. But with the advent of the Atom CPU, a 1.6 GHz device 64 but device w/ at least SSE3 is available at a very attractive price. Is there any reasonable implementation of x264 or any other h.264 software codec that might support real time software encoding on this kind of platform, for a single channel (by reasonable, I mean Baseline CIF of at least 25 fps).

If not, given the above, what kind of through would be achievable w/o pushing the CPU past 80%, as determined by fps, let's say.

Cheers,

- Michael

[Dark Shikari]

Even on an Atom, I suspect x264 could easily do realtime High Profile CIF with good settings. If it can't, not much else can, given that x264 is one of the fastest software encoders available.

Of course, I wonder exactly how much they've butchered the IPC on that chip.

[azcoder]

Toss me a few worthwhile settings (compile flags if appropriate and run time options), and I will get a board and test it out and report back how it does. I just did not want to dive in if the thing was doomed from the get-go to hit 3 fps or something.

-mg

[Dark Shikari]

For basic ultra-fast baseline, try --subme 1 --no-cabac --me dia --partitions none. If that won't run realtime nothing will

[Inventive Software]

Add --bframes 0 if you can sacrifice the quality.

[Dark Shikari]

Originally Posted by Inventive Software

Add --bframes 0 if you can sacrifice the quality.

That's the default

[Inventive Software]

--ref 0 then. I couldn't remember whether it was refs or bframes that were enabled by default. Refs I find slow encoding down, no matter what number's used between 1 and 16.

[Dark Shikari]

Originally Posted by Inventive Software

--ref 0 then. I couldn't remember whether it was refs or bframes that were enabled by default. Refs I find slow encoding down, no matter what number's used between 1 and 16.

"Ref 0" is completely meaningless; you can't have less than 1. The only way to actually not use any reference frames is --keyint 1.

[azcoder]

I am getting fairly good results with the following in a single core ATOM just now:

/usr/bin/nice --16 /usr/local/bin/ffmpeg -y -threads 2 -f oss -i /dev/dsp -ab 22k -ac 1 -ar 22050 \
-f video4linux2 \
-s cif -r ntsc -i /dev/video0 \
-t 180 -vcodec libx264 -bufsize 30000k -r 15 -b 300k -f mp4 \
-coder 1 -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 \
-me hex -subq 5 -me_range 16 -g 250 -keyint_min 25 -sc_threshold 40 \
-i_qfactor 0.71 -b_strategy 1 -crf 22 \
-bt 300k -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4

However, I have three things I am hoping to do better with:

1.) I do not understand all the above settings, some may be dumb for this kind of real time encoding...

2.) The resulting video has little or no color, I think some setting above may be messing that up...

and finally

3. ) I am getting some small artifacts with the above settings when people move, what would be a good way to tackle that?

Here is an example of the current result (mp4, plays in MPC, at least, about 8MB): Sample Vid

Any ideas are appreciated!

- Cheers

Michael

[Comatose]

The artifacts look like interlacing.
If the camera shoots at 704x576 then you should try and see if ffmpeg can do something like Avisynth's ReduceBy2() on Linux, which should produce deinterlaced 352x288.
Otherwise I don't think you have a choice other than encoding interlaced and deinterlacing later.

(or see if you can get the camera to shoot progressive)

As for the colors, I really don't know.

[Dark Shikari]

Originally Posted by azcoder

2.) The resulting video has little or no color, I think some setting above may be messing that up...

Perhaps a colorspace issue?

[nm]

Originally Posted by Comatose

The artifacts look like interlacing.
If the camera shoots at 704x576 then you should try and see if ffmpeg can do something like Avisynth's ReduceBy2() on Linux, which should produce deinterlaced 352x288.

I don't think ffmpeg includes such a filter (MEncoder does), but you'll get almost the same effect by simply downscaling to 320x240 (QVGA) or 352x240 instead of CIF since the source seems to be 480i30 NTSC video. CIF would be an appropriate target for interlaced PAL sources.

Originally Posted by azcoder

2.) The resulting video has little or no color, I think some setting above may be messing that up...

Are you getting colors with some other tool? I'd suspect the V4L2 driver or its settings first. MPlayer/MEncoder might be a better tool to test these things since it allows setting V4L(2) parameters on the command line.

[Comatose]

Originally Posted by Dark Shikari

Perhaps a colorspace issue?

I thought so too, but then if x264 treated whatever as YV12 wouldn't it just look really messed up?

[Dark Shikari]

Originally Posted by Comatose

I thought so too, but then if x264 treated whatever as YV12 wouldn't it just look really messed up?

There are multiple forms of YV12, represented by varying color conversion matrices (BT.709, BT.601, etc).

[Comatose]

Yeah, but then it wouldn't be completely devoid or color. There should be SOMETHING, right? :X

[azcoder]

Originally Posted by nm

Are you getting colors with some other tool? I'd suspect the V4L2 driver or its settings first.

I think you are onto something here -- there does appear to be some strangeness with the ffmpeg v4l2 capture, and the Kodicom 4400R video capture card / bttv driver in use.

I will collect more data and report back.

[Schrade]

Nice to see this thread. Anyone know of Win32 based ffmpeg versions that can use DirectShow capture?

[nm]

Originally Posted by azcoder

I think you are onto something here -- there does appear to be some strangeness with the ffmpeg v4l2 capture, and the Kodicom 4400R video capture card / bttv driver in use.

The same problem has been reported on the video4linux mailing list:
http://threebit.net/mail-archive/vid.../msg04762.html

[azcoder]

Originally Posted by nm

MPlayer/MEncoder might be a better tool to test these things since it allows setting V4L(2) parameters on the command line.

I am going to dive into MEncoder now, to see if it can do a better job working with x264 and the bttv/V4l2 handoffs. One question before I get too far into it -- I had the impression after working with both MEncoder and FFMPEG for a few years, that FFMPEG had a bit more speed and functionality than MEncoder. I am missing the boat here? Is MEncoder as good and flexible a tool as FFMPEG, at least for this kind of capture-and-encode work?

Cheers and thanks,

- Michael

[nm]

Originally Posted by azcoder

I am going to dive into MEncoder now, to see if it can do a better job working with x264 and the bttv/V4l2 handoffs. One question before I get too far into it -- I had the impression after working with both MEncoder and FFMPEG for a few years, that FFMPEG had a bit more speed and functionality than MEncoder. I am missing the boat here? Is MEncoder as good and flexible a tool as FFMPEG, at least for this kind of capture-and-encode work?

I'd say MEncoder is better in your case, unless you are going to extend the encoder or include it within a custom application. FFmpeg's codebase is much cleaner, so using it as a basis for a custom encoding tool is probably a better idea than trying to modify MEncoder. But, if you are only calling the encoder separately (within a script, for example), MEncoder is a good choice too.

Speed is practically the same with both tools, but mencoder has much more features: video and audio filters, supported input devices and formats etc.. Also x264 encoding parameters are easier to handle with mencoder's command-line syntax (they are the same as in x264 itself). Mencoder should be able to do almost everything that ffmpeg does, and a lot more.