[x264-devel] Re: [patch] split slice nal unit when it exceeds size x

[Alex Izvorski]

On Tue, 2007-05-01 at 14:25 -0700, Tom Harper wrote: 
> Dear X264 maintainers,
> 
> This is a new patch that uses the existing API to start a new
> NAL when a NAL exceeds a given size threshold.
> 
> Haven't tested it with threading but it should work as it doesn't
> change anything in the threading pathway.  I have an adjoining
> patch in ffmpeg for setting the threshold there also but I will
> wait and see what happens here first.
> 
> Thanks!
> 
> Tom

Hi Tom,

This is great!  A very nice feature addition (or is it re-addition? ;)

Could you modify the patch to do a fixed number of slices of the same
number of mb's/rows of mb's, as well as what it does now?

Also, could you make x264_slice_write() write only one slice at a time?
Single calls would have to be replaced with something along the lines of
while (! done) { x264_slice_write() } loop.  Alternately, just move the
body of that routine into x264_slices_write().  I know this is splitting
hairs but it is weird that both x264_slices_write and x264_slice_write
do in fact write multiple slices right now ;)  The old slice code had
x264_slice_write do just one slice at a time, and x264_slices_write do
an entire frame.

Lastly, correct me if I'm wrong, but it seems at a glance that all
slices written will have sh.i_last_mb equal to the last mb of the whole
frame?  Since the header gets written first and only some time later
does the termination condition (by size) get met.  I haven't examined an
output stream in detail to see if that is indeed the case, but it looks
that way from the source.  If so, for a standards compliant stream the
order would have to be reversed, write the slice body first (perhaps to
a temp buffer), then the header, so the header can list the correct last
mb number.

Regards,
--Alex


-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html