<br><br><div class="gmail_quote">On 7 August 2012 22:24, Jason Garrett-Glaser <span dir="ltr"><<a href="mailto:jason@x264.com" target="_blank">jason@x264.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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


<br>
By the way, thanks for doing testing with this feature -- I only got<br>
to do basic functionality testing because I never got to use it in a<br>
real application, so it's really good to see it actually getting used<br>
and improved to do what people need.<br><br></blockquote><div><br>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:<br>

<br>    dst->opaque     = src->opaque; // in x264_frame_copy_picture, which is only called for fenc and pic_in<br>    pic_out->opaque = h->fenc->opaque; // in x264_encoder_frame_end<br><br>So it looks like the opaque pointer will never even be in fdec, only in pic_in, fenc, pic_out.<br>

<br>I'm happy to test this, it seems like a feature I could use in my application, so debugging it a little is worth it.<br><br>Killian<br></div></div>