[vlc-devel] [RFC PATCH 12/13] omxil: new way to wait for omxbuffers to be returned

[Thomas Guillem]

Yes, it's for the patch 13/13. I explained in the cover letter (PATCH
00/13) but I should have explained it in this commit message too.

This solution is the simpler and the more understandable for me. I tried to
do it without it but it was really too confusing.

The thing I don't like about that patch is that it adds an other mutex/cond
couple on one port. (there are 3 mutex for the output port if you have
hwbuf activated)
The more you have mutex, bigger are the chance of a deadlook, although here
it feels safe.

Maybe we should have only one mutex/cond for one port and use pointers of
mutex/cond for FIFO and COUNTER.


2014-06-29 23:00 GMT+02:00 Martin Storsjö <martin at martin.st>:

> On Thu, 26 Jun 2014, Thomas Guillem wrote:
>
>  Add OMX_BUFFER_COUNT_* macro: Increment count when we send a buffer to OMX
>> (FillThisBuffer/EmptyThisBuffer). Decrement count on
>> FillBufferDone/EmptyBufferDone callback. On FreeBuffers, wait for buffer
>> count
>> to be zero.
>>
>
> Why? To me, this just makes the code much more complicated. Is this
> required for patch 13/13 in some way? Is it impossible to implement patch
> 13/13 without this?
>
> A commit message should not only explain _what_ you do, but more
> importantly, why (in case that is not obvious, which it is not here).
>
> // Martin
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
>

-- 


This email and any files transmitted with it are confidential and are 
intended solely for the use of the individual or entity to which they are 
addressed. Access to this e-mail by anyone else is unauthorised. If you are 
not the intended recipient, any disclosure, copying, distribution or any 
action taken or omitted to be taken in reliance on it, is prohibited. 
E-mail messages are not necessarily secure. Archos does not accept 
responsibility for any changes made to this message after it was sent.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20140629/1824ed7f/attachment.html>