[x264-devel] Opaque pointer for nalu processing?

[Killian De Smedt]

On 7 August 2012 19:53, Jason Garrett-Glaser <jason at x264.com> wrote:

> On Tue, Aug 7, 2012 at 9:06 AM, Killian De Smedt <killiands at gmail.com>
> wrote:
> >
> > On 7 August 2012 18:00, Jason Garrett-Glaser <jason at x264.com> wrote:
> >>
> >> On Tue, Aug 7, 2012 at 4:59 AM, Killian De Smedt <killiands at gmail.com>
> >> wrote:
> >> > Hello,
> >> >
> >> > Today I tried to setup my encoding system using nalu_process to handle
> >> > NAL
> >> > unit encoding and transmission. However, my application can handle
> >> > multiple
> >> > (dynamic) streams, but I have no way to differentiate between them in
> >> > the
> >> > actual nalu_process call. After some discussion on IRC it turned out I
> >> > could
> >> > only do this by creating a new function per stream. While I can use
> this
> >> > as
> >> > a workaround (nr of streams = low), this does seem like a dirty
> solution
> >> > and
> >> > it leads to code bloat because I have to create systems to allocate
> >> > streams
> >> > to a static callback.
> >>
> >> Have you tried using the x264_t pointer to indicate, or is that too
> >> hacky? I'd be happy to add an extra way if that wasn't enough, but I'd
> >> like to know why that isn't sufficient first.
> >>
> >
> > I thought of this also (mapping the x264 pointer to my stream), but
> someone
> > on IRC (BugMaster) told me that the x264_t pointer I receive in
> nalu_process
> > could differ from the main one used to call encoder_encode, due to worker
> > threads. If this is not the case and this value uniquely identifies my
> > stream, this solution would be sufficient for me.
>
> You're right, that's a problem. It could be solved by violating the
> encapsulation and looking inside x264_t, but that's not a pretty
> solution and violates the ABI. How would you prefer I modify the
> callback so that you know which one it is? I could pass the original
> x264_t as an argument, for example.
>
>
Ideally, it would be great if the `x264_nal_t` structure gets expanded with
a `void* opaque` pointer, that gets copied over from the pic_in (which is
also copied to fenc). In this case the callback interface itself would stay
the same and 'any" data can be passed.

But if that's not possible, any field I can consistently use as a key
suffices and the original x264_t pointer is as good as any in that case.

Thank you,

Killian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20120807/069b5dcc/attachment.html>