[x264-devel] Opaque pointer for nalu processing?

[Jason Garrett-Glaser]

> Now I am trying to do the reordering of the nalu's, I assume this is
> necessary (annex b used)?

Technically yes, but some decoders might work anyways.  I don't think
libavcodec does, but it shouldn't be horribly difficult to improve it
to support that.

Even if you don't reorder them server-side, for example, you could
send out the NALUs one by one, then reorder them on the client and
send the whole frame to decode at once. Some example guessy numbers:

Example without nalu_process: 20ms encode, 30ms network send, 5ms decode (55ms)
Example with nalu_process: 2ms encode before NALUs are output, 30ms
network send, 5ms decode (37ms)
Example with nalu_process, no reordering: 2ms encode before NALUs are
output, 30ms network send (decode done at the same time) 0.5ms decode
finish after network send (32.5ms)

> Currently (for debugging) I am doing this in the
> same app and write the final stream to a file that i try to play with the
> totem movie player. This works fine for the encoder_encode version.
>
> My current algorithm is as follows:
> if type is not 1,2,3,4,5 (slices) : write to file immediately, I assume
> headers are sent synchronously in-order before other nalu's, otherwise this
> could not work, because the mb_start/finish values make no sense for them.
> Otherwise, buffer until all chunks are received, order by i_mb_start and
> write away to file in that order.

Are you sure all the slices are for the same frame?  If you end up
with slices from two different frames, this could happen.

Jason