<br><br><div class="gmail_quote">On 7 August 2012 19:53, 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 9:06 AM, Killian De Smedt <<a href="mailto:killiands@gmail.com">killiands@gmail.com</a>> 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 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 I<br>
>> > could<br>
>> > only do this by creating a new function per stream. While I can use this<br>
>> > as<br>
>> > a workaround (nr of streams = low), this does seem like a dirty 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 someone<br>
> on IRC (BugMaster) told me that the x264_t pointer I receive in nalu_process<br>
> could differ from the main one used to call encoder_encode, due to 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>
</div></div>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>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br>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.<br>

<br>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.<br><br>Thank you,<br><br>Killian<br></div></div><br>