[x264-devel] Opaque pointer for nalu processing?

[Jason Garrett-Glaser]

On Tue, Aug 7, 2012 at 12:07 PM, Killian De Smedt <killiands at gmail.com> wrote:
>
>
> 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

Try this: https://github.com/DarkShikari/x264-devel/commit/e4b8ee321131c5da61569ae538b69bfc6aa9404d

By the way, thanks for doing testing with this feature -- I only got
to do basic functionality testing because I never got to use it in a
real application, so it's really good to see it actually getting used
and improved to do what people need.

Jason