Looking for settings for fast realtime 1080 x264 encoding

[((( atom )))]

Hi,

I have a rather difficult task to fullfill: Realtime-encoding of a 1080i Signal, wich is coming from a little Sony Blockcamera via SDI.

OS is Linux (Ubuntu). I managed to get the SDI-Signal into Gstreamer, wich will first deinterlace the signal and then encode it using x264.

I have a Core2 Quad processor. Running some test under Windows using MEGui I can't seem to get anywhere over 12-15 fps, no matter what settings I try. Well to be honest, since switching to x264 I kind of lost track of the encoder internals, due to it's lovely presets. :)

Surely of importance: The Video is taken from underneath a plane flying over fields and villages in some 1000-1500 ft height, so there is no crazy motion in the details, just the movement of the plane over ground. I would compare it to an endless pan over a landscape with houses.

The target-bitrate is as low as possible, since I want to send the video over a long-range wireless link using multicast.

So the actual question is: Can anyone help me finding the right parameters for the given situation? I would greatly appreciate it!

Thanks upfront!

[Dark Shikari]

Just use the slowest preset that gets you the speed you want.

[nurbs]

If your encoding speed doesn't increase when you use faster settings that means your input is too slow, so either the decoder can't keep up or the processing you do in avisynth is too slow. Deinterlacing generally is slow, especially if you use a good deinterlacer. I have no experience with gstreamer so I don't know how fast or good it's deinterlacer is. You could try encoding interlaced, or store a lossless intermediate file and deinterlace later, but since you want realtime encoding this is probably not an option for you.

[((( atom )))]

Dark Shikari, I don't understand.. I don't get the speed I want in the first place.

nurbs, that is a good point. I will think about interlaced encoding. t's better than switching the camera to 720p.
Still, what would be good settings for my scenario?

[nm]

Dark Shikari, I don't understand.. I don't get the speed I want in the first place.

If even the ultrafast preset is too slow, your problem is not about the settings. Most likely your input or preprocessing pipeline is simply too slow.

nurbs, that is a good point. I will think about interlaced encoding. t's better than switching the camera to 720p.

Are you sure about that? If you are limited by both bandwidth and processing power, wouldn't it be better to use a lower resolution? How much more actual resolution are you getting in 1080i mode anyway with that camera?

Still, what would be good settings for my scenario?

DS already answered to this.

[nurbs]

I'd also be thinking about using 720p in your situation. Interlaced encoding in x264 isn't that great, although there is someone working on it as part of this years Summer of Code. The framerates your camera handles would be interesting to know. I'd probably take 720p50 over 1080i25 simply because it's less of a hassle to work with.

[((( atom )))]

Yeah, I tried some interlaced encoding and things didn't get better, so I guess I will have to stick with 720p and discard every other frame. Theat should be easy to handle.

The camera is a Sony FBDH10, nice little thing: http://www.pro.sony.eu/biz/view/ShowProduct.action?product=FCB-H10&site=biz_en_EU&pageType=Overview&category=BlockCams

[mp3dom]

Interlaced encoding in x264 isn't that great
It's not that bad either. There are other payware encoders which have worst support on interlaced encoding even if they offer full MBAFF (and other encoders too which works better on interlaced encoding than x264)

[nurbs]

Well, I'm prejudiced against interlacing in general so I'm not up do date on encoder performance. For me interlacing is simply an extra problem I have to fix before encoding.

[Mug Funky]

post workflow is smoother with 1080i. i'd prefer interlaced encoding (even at x264's current point) over deinterlacing.

i'm thinking that with the amount of features you'll be turning off to get realtime, you might as well encode interlaced and turn off a couple more features from that.

[audyovydeo]

regardless of intelacing etc, 1080p seems like a lot of bytes to stuff down a wireless link.

Depending on what you final usage is, are you sure you're not better off with high-quality 720p material that encodes easily /vs/ lower quality, harder-to-encode 1080p ?

cheers
a/v

[((( atom )))]

Well, I did some more testing and I am only able to get 720p/25 to encode realtime, anyway.. Qualitywise I guess it will be rather bitrate-friendly, since exept for the constant slow panning there is practically no motion. I went down until 1 mbit with a similar scene (slow pan over the rooftops I have outside my window) before quality got unacceptable. I guess it is a good starting-point and in some time a standard-cpu will do the job with deinterlacing and all. Also I will switch to 64 bit Linux in the next step and see what that brings..

Still I'd like to know what I am doing, so can anyone point me to any easy to understand documentation of all the features of the encoder? Sadly in Linux using Gstreamer the plugin that calls x264 does not know of any presets, so I will have to rebuilt the equivalents by hand. That is good for learning what I am doing, anyway..

[nm]

Still I'd like to know what I am doing, so can anyone point me to any easy to understand documentation of all the features of the encoder?

This is usually up to date: http://mewiki.project357.com/wiki/X264_Settings
Avidemux wiki also has a good article: http://www.avidemux.org/admWiki/doku.php?id=tutorial:h.264

[nurbs]

If you don't have an executabl you could look at the source code. The the description of the presets and tunings can be found in x264.c. Your can look at the file on videolan.org.

[((( atom )))]

If you don't have an executabl you could look at the source code. The the description of the presets and tunings can be found in x264.c. Your can look at the file on videolan.org.
perfect, thx!

[((( atom )))]

This is usually up to date: http://mewiki.project357.com/wiki/X264_Settings
Avidemux wiki also has a good article: http://www.avidemux.org/admWiki/doku.php?id=tutorial:h.264
..and for that, too!

[popper]

why don't you simply get a better CPU than that Core2 Quad processor, any i7 should do.

"Surely of importance: The Video is taken from underneath a plane flying over fields and villages in some 1000-1500 ft height"

looking at that cams Dimensions (w x h x d) 47.2 x 43.1 x 72.2 mm (1 7/8 x 1 3/4 x 2 7/8 inches) and its now low 2 Megapixel (5.0 Megapixel Sensor's are more common now apparently) sensor.

i take it you mean a model air plane, and are also using some form of perhaps slower and under-clocked SBC (Single-Board Computer) mounted to it with this current Core2 Quad processor doing the work, the devils in the details and all that to get the best option's open to you?

there are if you look hard enough SBC and OC MINI ITX boards such as the http://www.taiwanpcsources.com/intel_core_i7_motherboard.htm for i7 if your model plane's big enough to take their larger size....

define *long range wireless link speed, but that's beside the point right now and just one more solvable potential problem.

*generic fast 11n can be made to transmit longer range too with a directional aerial, but in this case OC, your in a mobile assumed model air plain, so you have a hight and assumed clear line of sight advantage, but Not the directional stability required even if your flying in the direction of the base station router to point directly at it OC

[Dark Shikari]

why don't you simply get a better CPU than that Core2 Quad processor, any i7 should do.Core 2 quads are plenty fast enough for realtime encoding.

[popper]

OC with a low 2 Megapixel cam is it even worth using 1080 over 720 realtime encoding, and if he is using a SBC, then they are usually using slower board parts, and under clocked CPU to reduce power and heat....

i just found an intermediate-sized embedded single-board computer (SBC)
as in the 6.5 x 4.5-inch EPIC (Embedded Platform for Industrial Computing) form factor http://www.linuxfordevices.com/c/a/News/Avalue-EPIQM57/?kc=rss
dual-core Core i7 clocked at a basic clock speed of 1.06GHz, a TurboBoost speed of 2.13GHz, and an 18-Watt TDP for instance....

[((( atom )))]

popper, you got quite close. Here's what there is: An Ultralight Airplane http://www.flaemingair.de/tl/tl_files/images/Flugzeuge/l3.jpg with two pods underneath the wings, carrying the camera systems and Mini-ITX computers.

The Sony camera module is amazingly good for it's size and price, especially the zoom-lens and we have an SDI-output module to access the uncompressed image data. Very nice :)

Long range wireless link.. Well, we succeeded getting a link for 29 km when we first tested the equipment and I am building the encoder, so that we can see what data rate we can transmit. Of course I could have simply built something that shovels some data over the link, but since we want to transmit video, we decided to test it with that, right away.

Sadly, something went wrong yesterday at the airport, and the encoder didn't multicast the packets and we couldn't make any progress..

Strangely the linux pc seems to encode much faster, then my Core2 Quad at the office using XP and MEGui. It might have to do with the stream coming from a live-source instead of an avisynth script, but that looked very promising. Still I decided to go for 720p in the beginning and work my way up from there. That should lead to less dissapointment..