Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 27th May 2008, 19:19   #1  |  Link
azcoder
AZ-Coder
 
Join Date: May 2007
Posts: 5
Exploring Software-Encode h.264 Options for Mobile Atom-Based Solution

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
azcoder is offline   Reply With Quote
Old 27th May 2008, 19:20   #2  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,667
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.

Last edited by Dark Shikari; 27th May 2008 at 19:23.
Dark Shikari is offline   Reply With Quote
Old 27th May 2008, 19:26   #3  |  Link
azcoder
AZ-Coder
 
Join Date: May 2007
Posts: 5
Toss me a few worthwhile settings, and I will get a board and test it out and report

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
azcoder is offline   Reply With Quote
Old 27th May 2008, 19:46   #4  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,667
For basic ultra-fast baseline, try --subme 1 --no-cabac --me dia --partitions none. If that won't run realtime nothing will
Dark Shikari is offline   Reply With Quote
Old 29th May 2008, 17:22   #5  |  Link
Inventive Software
Turkey Machine
 
Join Date: Jan 2005
Location: Lowestoft, UK (but visit lots of places with bribes [beer])
Posts: 1,953
Add --bframes 0 if you can sacrifice the quality.
__________________
On Discworld it is clearly recognized that million-to-one chances happen 9 times out of 10. If the hero did not overcome huge odds, what would be the point? Terry Pratchett - The Science Of Discworld
Inventive Software is offline   Reply With Quote
Old 29th May 2008, 17:29   #6  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,667
Quote:
Originally Posted by Inventive Software View Post
Add --bframes 0 if you can sacrifice the quality.
That's the default
Dark Shikari is offline   Reply With Quote
Old 29th May 2008, 19:16   #7  |  Link
Inventive Software
Turkey Machine
 
Join Date: Jan 2005
Location: Lowestoft, UK (but visit lots of places with bribes [beer])
Posts: 1,953
--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.
__________________
On Discworld it is clearly recognized that million-to-one chances happen 9 times out of 10. If the hero did not overcome huge odds, what would be the point? Terry Pratchett - The Science Of Discworld

Last edited by Inventive Software; 29th May 2008 at 19:18.
Inventive Software is offline   Reply With Quote
Old 29th May 2008, 19:21   #8  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,667
Quote:
Originally Posted by Inventive Software View Post
--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.
Dark Shikari is offline   Reply With Quote
Old 7th September 2008, 20:45   #9  |  Link
azcoder
AZ-Coder
 
Join Date: May 2007
Posts: 5
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

Last edited by azcoder; 9th September 2008 at 05:34. Reason: added video link
azcoder is offline   Reply With Quote
Old 9th September 2008, 15:43   #10  |  Link
Comatose
Registered User
 
Join Date: Dec 2007
Posts: 639
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.

Last edited by Comatose; 9th September 2008 at 15:45.
Comatose is offline   Reply With Quote
Old 9th September 2008, 16:23   #11  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,667
Quote:
Originally Posted by azcoder View Post
2.) The resulting video has little or no color, I think some setting above may be messing that up...
Perhaps a colorspace issue?
Dark Shikari is offline   Reply With Quote
Old 9th September 2008, 17:03   #12  |  Link
nm
Registered User
 
Join Date: Mar 2005
Location: Finland
Posts: 2,642
Quote:
Originally Posted by Comatose View Post
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.

Quote:
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.
nm is offline   Reply With Quote
Old 9th September 2008, 18:54   #13  |  Link
Comatose
Registered User
 
Join Date: Dec 2007
Posts: 639
Quote:
Originally Posted by Dark Shikari View Post
Perhaps a colorspace issue?
I thought so too, but then if x264 treated whatever as YV12 wouldn't it just look really messed up?
Comatose is offline   Reply With Quote
Old 9th September 2008, 18:56   #14  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,667
Quote:
Originally Posted by Comatose View Post
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).
Dark Shikari is offline   Reply With Quote
Old 9th September 2008, 19:16   #15  |  Link
Comatose
Registered User
 
Join Date: Dec 2007
Posts: 639
Yeah, but then it wouldn't be completely devoid or color. There should be SOMETHING, right? :X
Comatose is offline   Reply With Quote
Old 10th September 2008, 05:29   #16  |  Link
azcoder
AZ-Coder
 
Join Date: May 2007
Posts: 5
Quote:
Originally Posted by nm View Post


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.
azcoder is offline   Reply With Quote
Old 10th September 2008, 06:44   #17  |  Link
Schrade
Registered User
 
Schrade's Avatar
 
Join Date: Mar 2004
Posts: 339
Nice to see this thread. Anyone know of Win32 based ffmpeg versions that can use DirectShow capture?
Schrade is offline   Reply With Quote
Old 10th September 2008, 07:04   #18  |  Link
nm
Registered User
 
Join Date: Mar 2005
Location: Finland
Posts: 2,642
Quote:
Originally Posted by azcoder View Post
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
nm is offline   Reply With Quote
Old 10th September 2008, 17:07   #19  |  Link
azcoder
AZ-Coder
 
Join Date: May 2007
Posts: 5
Quote:
Originally Posted by nm View Post
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
azcoder is offline   Reply With Quote
Old 10th September 2008, 18:38   #20  |  Link
nm
Registered User
 
Join Date: Mar 2005
Location: Finland
Posts: 2,642
Quote:
Originally Posted by azcoder View Post
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.
nm is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 17:29.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.