Re: [Gstreamer-openmax] Repeat Mode of Totem Player

[Clark, R. <ro...@ti...>]

But, I guess the part I'm still not following is that g_omx_port_release_buffer() will still be called that will be doing an EmptyThisBuffer/FillThisBuffer (input/output port).  So the buffer should not be lost.  The OMX component should still pass the buffer back at some stage.

BR,
-R

On Aug 16, 2010, at 9:00 PM, Mickey Kim wrote:

> 
> 
> Whether the buffer with the eos flag has the actual data is not important.
> 
> My component(h.264) have only two buffer in queue for output buffer.
> 
> At first, gst-openmax push this two buffers into queue.
> 
> And it execute the dedcoing with pop-push operation
> 
> When my component meet the buffer with eos flag, gst-openmax pop buffer from queue. (only pop, not push)
> So only one buffer is remained in the queue.
> 
> 
> 
> In next loop (second play time),
> 
> gst-openmax execute pop-push operation with only one buffer in queue.
> 
> When my component meet the buffer with eos flag, gst-openmax pop buffer from queue. (only pop, not push)
> 
> 
> 
> Finally,
> 
> there in no buffer in queue at third loop.
> 
> 
> 
> 
> 
> Regards,
> 
> Mickey
> 
> 
> 
> 
> 
> 
> 
> ------- Original Message -------
> Sender : Clark, Rob<ro...@ti...>
> Date : 2010-08-16 23:53 (GMT+09:00)
> Title : Re: [Gstreamer-openmax] Repeat Mode of Totem Player
> 
> Just so I understand properly, is the issue that in the case of your OMX IL component, the buffer with the EOS flag set is containing actual data that should not be thrown out?  If not, then I'm not entirely sure that I understand. 
> 
> Is the buffer lost from the (n+1)'th playback? 
> 
> Perhaps if possible, sharing a log w/ GST_DEBUG="*omx*:5" would be helpful 
> 
> 
> BR, 
> -R 
> 
> 
> 
> On Aug 15, 2010, at 11:02 PM, Mickey Kim wrote: 
> 
>> 
>> I'm using Totem Player on Ubuntu. 
>> When I check repeat mode option in totem, player stops after only two time repeatation. 
>> 
>> I could find that totem doesn't change the state, when it meet the end of stream. 
>> But I also could find gst-openmax code doesn't consider this case. 
>> When gst-openmax meet EOS, it throw output buffer of queue (in output_loop()). 
>> So there is one buffer loss during one time repeatation. 
>> 
>> 
>> To resolve this issue, I have modified two function as below. 
>> 
>> output_loop () 
>> { 
>> ... 
>>       if (G_UNLIKELY (omx_buffer->nFlags & OMX_BUFFERFLAG_EOS)) 
>>       { 
>>           GST_DEBUG_OBJECT (self, "got eos"); 
>>           gst_pad_push_event (self->srcpad, gst_event_new_eos ()); 
>>           ret = GST_FLOW_UNEXPECTED; 
>>           // by Mickey 
>>           // for repeat mode of totem player 
>>           // In original code, 
>>           // When gst-omx detect EOS buffer, this buffer are popped from queue and not pushed to queue. 
>>           // This lead to empty queue in repeat mode. 
>> #if 1 
>>           g_omx_port_push_buffer (out_port, omx_buffer); 
>> #endif 
>>           goto leave; 
>>       } 
>> ... 
>> } 
>> 
>> g_omx_port_flush() 
>> { 
>>   if (port->type == GOMX_PORT_OUTPUT) 
>>   { 
>>       OMX_BUFFERHEADERTYPE *omx_buffer; 
>>       while ((omx_buffer = async_queue_pop_forced (port->queue))) 
>>       { 
>>           // by Mickey 
>>           // for repeat mode of totem player 
>>           // When gst-omx detect EOS, output_loop push buffer with EOS (to queue). 
>>           // Then, g_omx_port_flush() push this buffer with no EOS flag (to queue). 
>> #if 1 
>>           if(omx_buffer->nFlags & OMX_BUFFERFLAG_EOS) 
>>           { 
>>               omx_buffer->nFlags = 0; 
>>               g_omx_port_push_buffer (port, omx_buffer); 
>>               break; 
>>           } 
>>           else 
>>           { 
>>               omx_buffer->nFilledLen = 0; 
>>               g_omx_port_release_buffer (port, omx_buffer); 
>>           } 
>> #else 
>>           omx_buffer->nFilledLen = 0; 
>>           g_omx_port_release_buffer (port, omx_buffer); 
>> #endif 
>>       } 
>>   } 
>> .... 
>> } 
>> 
>> 
>> Please give your opinion. 
>> 
>> Regards, 
>> Mickey 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------ 
>> This SF.net email is sponsored by  
>> 
>> Make an app they can't live without 
>> Enter the BlackBerry Developer Challenge 
>> http://p.sf.net/sfu/RIM-dev2dev  
>> _______________________________________________ 
>> Gstreamer-openmax mailing list 
>> Gst...@li... 
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax 
> 
> 
> 
>