Hi,all<br> what's the reason for splitting slice nalu? to transport H.264 bitstream over the ip network?<br>I think splitting slice nalu will make packetizing bitstream into rtp packets easier. If so, do we should<br>
consider packet loss?<br><br>Regards<br>Jogging<br><br><div><span class="gmail_quote">On 5/3/07, <b class="gmail_sendername">Sergey A. Sablin</b> <<a href="mailto:sergey.sablin@elecard.ru">sergey.sablin@elecard.ru</a>> wrote:
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">basically standard compliant streams doesn't contain last mb number<br>inside - only the number of first mb in slice.
<br><br>Sergey.<br><br><br>Alex Izvorski wrote:<br>> On Tue, 2007-05-01 at 14:25 -0700, Tom Harper wrote:<br>><br>>> Dear X264 maintainers,<br>>><br>>> This is a new patch that uses the existing API to start a new
<br>>> NAL when a NAL exceeds a given size threshold.<br>>><br>>> Haven't tested it with threading but it should work as it doesn't<br>>> change anything in the threading pathway. I have an adjoining
<br>>> patch in ffmpeg for setting the threshold there also but I will<br>>> wait and see what happens here first.<br>>><br>>> Thanks!<br>>><br>>> Tom<br>>><br>><br>> Hi Tom,
<br>><br>> This is great! A very nice feature addition (or is it re-addition? ;)<br>><br>> Could you modify the patch to do a fixed number of slices of the same<br>> number of mb's/rows of mb's, as well as what it does now?
<br>><br>> Also, could you make x264_slice_write() write only one slice at a time?<br>> Single calls would have to be replaced with something along the lines of<br>> while (! done) { x264_slice_write() } loop. Alternately, just move the
<br>> body of that routine into x264_slices_write(). I know this is splitting<br>> hairs but it is weird that both x264_slices_write and x264_slice_write<br>> do in fact write multiple slices right now ;) The old slice code had
<br>> x264_slice_write do just one slice at a time, and x264_slices_write do<br>> an entire frame.<br>><br>> Lastly, correct me if I'm wrong, but it seems at a glance that all<br>> slices written will have
sh.i_last_mb equal to the last mb of the whole<br>> frame? Since the header gets written first and only some time later<br>> does the termination condition (by size) get met. I haven't examined an<br>> output stream in detail to see if that is indeed the case, but it looks
<br>> that way from the source. If so, for a standards compliant stream the<br>> order would have to be reversed, write the slice body first (perhaps to<br>> a temp buffer), then the header, so the header can list the correct last
<br>> mb number.<br>><br>> Regards,<br>> --Alex<br>><br>><br>><br><br>--<br>This is the x264-devel mailing-list<br>To unsubscribe, go to: <a href="http://developers.videolan.org/lists.html">http://developers.videolan.org/lists.html
</a><br><br></blockquote></div><br>