MAX_SLICES value too low for a number of RTP endpoints

[Tom Greenwood]

When running a stream with RTP endpoints you may receive MAX_SLICES errors. Increasing the value to 64 seems to work without errors on RTP endpoints that my colleagues and I have tested.

You may also notice that this issue is reported by a number of others across the internet and 3 bugs have been reported that also note that MAX_SLICES was too low among other issues.

I hope that increasing the value to remove the error messages "increase MAX_SLICES and recompile if there are artifacts" is worth it in itself, but increasing the value also seems to reduce artefacts. Unfortunately I've not captured streams which show artefacts as they occur infrequently and our software is not setup to capture streams, this makes it difficult to prove that the MAX_SLICES value is the cause.

The value is found in libavcodec/h264.h and is currently set to 16. I have reported against master, but I know that this value has been 16 in previous versions.

The one client that consistently produces these errors in CounterPath Bria and it is the only one I am aware of that ever exceeds 32.

Please let me know if there is anything further I can do to help. If there is any downside to increasing MAX_SLICES to 64 I'd like to understand that as well - Thanks

[Carl Eugen Hoyos]

Replying to tgreenwood:

Please let me know if there is anything further I can do to help.

Send a patch to ffmpeg-devel

If there is any downside to increasing MAX_SLICES to 64 I'd like to understand that as well

It will have a negative performance impact.

[Carl Eugen Hoyos]

Replying to tgreenwood:

You may also notice that this issue is reported by a number of others across the internet

Please point us to the reports.

and 3 bugs have been reported that also note that MAX_SLICES was too low among other issues.

Two of them used artificial samples (no matter how high we set MAX_SLICES you can always produce a file with a higher number), the third one was fixed without increasing MAX_SLICES.

Please provide at least the complete, uncut console output when decoding such a stream.

[...]

The one client that consistently produces these errors in CounterPath Bria and it is the only one I am aware of that ever exceeds 32.

Please capture such a stream.

[Tom Greenwood]

Here are some of the people who have seen this from what I've found. Some have recompiled to fix this. Two of the causes seem to correlate with what I've seen (Cisco and CounterPath equipment) - interestingly one person had seen x264 get to 17.

Linphone
​http://atiur-here.blogspot.co.uk/2012/02/too-many-slices-increase-maxslices-and.html ​http://lists.gnu.org/archive/html/linphone-developers/2009-11/msg00060.html

FFMPEG on windows
​http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=112 ​https://groups.google.com/forum/?fromgroups=#!topic/winff/RaYl29D2vsU%5B1-25-false%5D

Wowza
​http://www.wowza.com/forums/showthread.php?20248-Live-Streaming-Issues-with-Artifacts-amp-Jerkiness

MythTV
​http://www.mythtv.org/pipermail/mythtv-users/2010-July/292506.html

FFMPEG
​http://ffmpeg.org/pipermail/ffmpeg-devel/2011-July/113574.html

I will capture a stream and create a patch file when I get the time. Thank you for your help.

[Carl Eugen Hoyos]

The MythTV issue is due to receiving quality (packet loss), the message on ffmpeg-devel is from someone who intentionally encodes with a (too) high value for slices, the remaining reports unfortunately lack a failing sample;-(

If you can provide short captures of Cisco and CounterPath equipment, I will produce a patch.

[Carl Eugen Hoyos]

If this is still reproducible, please provide a sample.