How to make x264 realtime stream more stable?

[Fredrum]

Hi All,

I'm making a prototype piece of software to do 'realtime' low latency x264 streaming a'la http://x264dev.multimedia.cx/archives/249

It works and I can send and view a 640x480 stream without too much compression deterioration when testing on the loopback, using a bit rate of about 1Mb.

I then started using a piece of software to test different network conditions, one called Netbalancer (for PC). Streaming just over ethernet to my laptop.

My problem is that the image gets some major deterioration to the point of being porridge after dialling in just 0.1-0.5% of packet loss. This software seems quite popular so I think it should be ballpark correct?

The above article(link) mentions that a x264 stream could take as much as 25% without getting destroyed.

I have also done a more real-to-life test streaming to my brother on the other side of the planet over UDP and in this test too the image gets severely broken and glitchy. (Not 100% sure if in the same way though, or for the same reason)


So I am wondering what I can do to make my stream more robust without sacrificing any latency?
Are there any particular parameters that influence this when doing realtime streaming?

Cheers
Fred

[Cornucopia]

h.264 is not just one format, but a family of formats (profiles) that have different needs. "Robustness" and "Latency" may, in some of those profiles, be mutually exclusive, and the "25%" figure may only apply to a particular profile, meaning NOT the low latency types.

It may or may not be possible to do what you want. Sorry, I don't have the time to check.

Scott

[Fredrum]

The article I mention is written by a guy who was one of the people that implemented the different things in x264 that enables it to do 'realtime' streaming.
That's why when he says it should take 25% packet loss I think he must be right. And since I get problems at 0.5 I was wondering if anyone had any ideas about that?

Cheers
Fred

[newpball]

My problem is that the image gets some major deterioration to the point of being porridge after dialling in just 0.1-0.5% of packet loss. This software seems quite popular so I think it should be ballpark correct?

This is 'solved' often by simply discarding frames that are too bad.
Supposedly people prefer stuttering over porridge.

[Fredrum]

Hmm...I am using ffmpeg libavcodec (in c code) to decode the stream. Maybe there's some way to do things different on that side or use some different options? I don't know all about that yet so maybe I can try and see if there's something I'm missing on that side.

If anyone has any tips to share please shout out and I'll try them.

Cheers, Fred