[x264-devel] [patch] control of maximum nalu size (multi-sclicing)

[Simon Morlat]

Hello,

Find attached a new patch for controlling size of nalus. 
When the maximum nalu size parameter is set, x264 generates as many nalus as 
necessary to code the entire frame.
The patch is small and simple. I validated it against the ffmpeg decoder.

I would be very glad if it could be merged.
You might wonder why this patch is important.
Let me explain:
When doing real time streaming of H264, for example for a SIP video call, 
video packets are put into RTP packets that fits into UDP packets.
Of course in the internet the MTU is often at most 1500 bytes. So even a small 
QCIF video has no chance of getting its compressed frames packed into one UDP 
packet.
RFC3984 (H.264 over RTP) defines two mode of operations:
* packetization-mode=0 : exactly one NAL in one RTP/UDP packet
* packetization-mode=1 : by using an extension of NAL header, this mode allows 
splitting of H264 nal at arbitrary points so that they get transported over 
several UDP packets.

So we could live with packetization-mode=1. But unfortunately this mode makes 
a lot of problem:
1/ it is not widely supported by exsting communication equipements and phones.
Thus only packetization-mode=0 is possible in practice. Since x264 doesn't 
allow this because it does not have the capability of mult-slicing, open 
source video software (linphone/ekiga, perhaps others) can't interoperate with 
the real world equipments.
2/ packetization-mode=1 is a low cost, low quality solution. Indeed it splits 
nalus at arbitrary point, without knowledge of the h264 bitstream. As a 
result, in case of UDP packet loss, the entire frame gets damaged. In the 
other case (packetization-mode=0), only the picture portion coded by the lost 
nalu would be unrefreshed.
By accepting this patch, you would solve a big issue for open source real-time 
communications softwares.

Thanks,

Simon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: x264_max_nalu_size.patch
Type: text/x-patch
Size: 4837 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20090703/d07b2837/attachment.bin>