[x264-devel] Opaque pointer for nalu processing?

[Jason Garrett-Glaser]

On Tue, Aug 7, 2012 at 3:00 PM, Killian De Smedt <killiands at gmail.com> wrote:
>
>
> On 7 August 2012 22:24, Jason Garrett-Glaser <jason at x264.com> wrote:
>>
>> 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.
>>
>
> It seems that the opaque pointer I get passed is always set to NULL. I saw
> in the diff that you get the opaque from fdec, but when I take a look at how
> opaque is propagated, I only find these two calls:

Whoops, thanks for catching that, fixed.

Jason