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

[jogging song]

Hi,all
     what's the reason for splitting slice nalu? to transport
H.264bitstream over the ip network?
I think splitting slice nalu will make packetizing bitstream into rtp
packets easier. If so, do we should
consider packet loss?

Regards
Jogging

On 5/3/07, Sergey A. Sablin <sergey.sablin at elecard.ru> wrote:
>
> basically standard compliant streams doesn't contain last mb number
> inside - only the number of first mb in slice.
>
> Sergey.
>
>
> Alex Izvorski wrote:
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20070508/b4b95d2f/attachment.htm