[x264-devel] Opaque pointer for nalu processing?

[Jason Garrett-Glaser]

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.

Jason