From: Mickey K. <jih...@sa...> - 2010-08-17 01:54:55
|
<HTML><HEAD><TITLE>Samsung Enterprise Portal mySingle</TITLE> <META content="text/html; charset=windows-1252" http-equiv=Content-Type> <STYLE id=mysingle_style>P { MARGIN-TOP: 5px; FONT-FAMILY: Times New Roman, arial; MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt } TD { MARGIN-TOP: 5px; FONT-FAMILY: Times New Roman, arial; MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt } LI { MARGIN-TOP: 5px; FONT-FAMILY: Times New Roman, arial; MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt } BODY { FONT-FAMILY: Times New Roman, arial; FONT-SIZE: 9pt } </STYLE> <META name=GENERATOR content=ActiveSquare></HEAD> <BODY> <P> </P> <P>Whether the buffer with the eos flag has the actual data is not important.</P> <P>My component(h.264) have only two buffer in queue for output buffer.</P> <P>At first, gst-openmax push this two buffers into queue.</P> <P>And it execute the dedcoing with pop-push operation</P> <P>When my component meet the buffer with eos flag, gst-openmax pop buffer queue. (only pop, not push)<BR>So only one buffer is remained in the queue.</P> <P> </P> <P>In next loop (second play time),</P> <P>gst-openmax execute pop-push operation with only one buffer in queue.</P> <P>When my component meet the buffer with eos flag, gst-openmax pop buffer queue. (only pop, not push)</P> <P> </P> <P>Finally,</P> <P>there in no buffer in queue at third loop.</P> <P> </P> <P> </P> <P>Regards,</P> <P>Mickey</P> <P> </P> <P> </P> <P> </P> <P> </P><BR><BR>------- <B>Original Message</B> -------<BR><B>Sender</B> : Clark, Rob<ro...@ti...><BR><B>Date</B> : 2010-08-16 23:53 (GMT+09:00)<BR><B>Title</B> : Re: [Gstreamer-openmax] Repeat Mode of Totem Player<BR><BR>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. <BR><BR>Is the buffer lost from the (n+1)'th playback? <BR><BR>Perhaps if possible, sharing a log w/ GST_DEBUG="*omx*:5" would be helpful <BR><BR><BR>BR, <BR>-R <BR><BR><BR><BR>On Aug 15, 2010, at 11:02 PM, Mickey Kim wrote: <BR><BR>> <BR>> I'm using Totem Player on Ubuntu. <BR>> When I check repeat mode option in totem, player stops after only two time repeatation. <BR>> <BR>> I could find that totem doesn't change the state, when it meet the end of stream. <BR>> But I also could find gst-openmax code doesn't consider this case. <BR>> When gst-openmax meet EOS, it throw output buffer of queue (in output_loop()). <BR>> So there is one buffer loss during one time repeatation. <BR>> <BR>> <BR>> To resolve this issue, I have modified two function as below. <BR>> <BR>> output_loop () <BR>> { <BR>> ... <BR>> if (G_UNLIKELY (omx_buffer->nFlags & OMX_BUFFERFLAG_EOS)) <BR>> { <BR>> GST_DEBUG_OBJECT (self, "got eos"); <BR>> gst_pad_push_event (self->srcpad, gst_event_new_eos ()); <BR>> ret = GST_FLOW_UNEXPECTED; <BR>> // by Mickey <BR>> // for repeat mode of totem player <BR>> // In original code, <BR>> // When gst-omx detect EOS buffer, this buffer are popped from queue and not pushed to queue. <BR>> // This lead to empty queue in repeat mode. <BR>> #if 1 <BR>> g_omx_port_push_buffer (out_port, omx_buffer); <BR>> #endif <BR>> goto leave; <BR>> } <BR>> ... <BR>> } <BR>> <BR>> g_omx_port_flush() <BR>> { <BR>> if (port->type == GOMX_PORT_OUTPUT) <BR>> { <BR>> OMX_BUFFERHEADERTYPE *omx_buffer; <BR>> while ((omx_buffer = async_queue_pop_forced (port->queue))) <BR>> { <BR>> // by Mickey <BR>> // for repeat mode of totem player <BR>> // When gst-omx detect EOS, output_loop push buffer with EOS (to queue). <BR>> // Then, g_omx_port_flush() push this buffer with no EOS flag (to queue). <BR>> #if 1 <BR>> if(omx_buffer->nFlags & OMX_BUFFERFLAG_EOS) <BR>> { <BR>> omx_buffer->nFlags = 0; <BR>> g_omx_port_push_buffer (port, omx_buffer); <BR>> break; <BR>> } <BR>> else <BR>> { <BR>> omx_buffer->nFilledLen = 0; <BR>> g_omx_port_release_buffer (port, omx_buffer); <BR>> } <BR>> #else <BR>> omx_buffer->nFilledLen = 0; <BR>> g_omx_port_release_buffer (port, omx_buffer); <BR>> #endif <BR>> } <BR>> } <BR>> .... <BR>> } <BR>> <BR>> <BR>> Please give your opinion. <BR>> <BR>> Regards, <BR>> Mickey <BR>> <BR>> <BR>> <BR>> <BR>> <BR>> <BR>> <BR>> ------------------------------------------------------------------------------ <BR>> This SF.net email is sponsored by <BR>> <BR>> Make an app they can't live without <BR>> Enter the BlackBerry Developer Challenge <BR>> http://p.sf.net/sfu/RIM-dev2dev <BR>> _______________________________________________ <BR>> Gstreamer-openmax mailing list <BR>> Gst...@li... <BR>> https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax <BR><BR><BR> <TABLE id=confidentialsignimg> <TBODY> <TR> <TD NAMO_LOCK> <P><IMG border=0 src="cid:QKN...@na..." width=520></P></TD></TR></TBODY></TABLE> <P></P></BODY></HTML> |
From: Mickey K. <jih...@sa...> - 2010-08-17 02:00:44
|
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 |
From: Clark, R. <ro...@ti...> - 2010-08-17 15:13:51
|
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 > > > > |
From: Mickey K. <jih...@sa...> - 2010-08-19 00:26:16
|
Yes, buffer is back to gst-omx from openmax component. (by FillBufferDone) (This issue is for only output buffer, input buffer is ok.) At initial time, 2 output buffer are pushed into gst-omx queue. Then 2 buffers are pushed and poped using g_omx_port_release_buffer, g_omx_port_request_buffer. But eos buffer is only poped (not called g_omx_port_release_buffer). After that g_omx_port_flush is called. So only one buffer is remained in queue. And then play from the start of stream using this one buffer in queue. At third time playback, there is no buffer in queue. So g_omx_port_request_buffer is waiting infinitly in output loop. Please remember that omx component always return buffer, gst-omx queue mechanism is not proper. Regards, Mickey |
From: Rob C. <ro...@ti...> - 2010-08-20 01:19:37
|
ok, I think I'm managing to understand the sequence.. and btw, I'm not doubting you.. I'm just trying to make sure I understanding the issue properly.. we are using a branch of gst-openmax that significantly refactors the buffer passing for all GstOmxBase{Src,Filter,Sink} classes into g_omx_port_{send,recv}() so I'm getting a bit forgetful about the original logic. (fwiw, in our case we pass the buffer back to the OMX component (FTB) rather than returning it directly to the queue on EOS.) So I guess either a _release_buffer() or _push_buffer() in the case of EOS could work. Although really I need to find some time to clean up and start pushing some patches again, because I believe there could be a lot of cleanup and simplification by pushing more of the common buffer/event passing logic to GOmxPort (which should perhaps be renamed to GstOmxPort). Would you care to send a git patch to the list, and perhaps Felipe could review and push? one note: in the future a git patch, so we could be sure of the parts of code that you are suggesting to change, and a gst log w/ *omx*:5 (or at least the relevant snippet of the log) so I can follow the program flow would make understanding easier. BR, -R On Aug 18, 2010, at 7:26 PM, Mickey Kim wrote: > > > Yes, buffer is back to gst-omx from openmax component. (by FillBufferDone) > (This issue is for only output buffer, input buffer is ok.) > > At initial time, 2 output buffer are pushed into gst-omx queue. > Then 2 buffers are pushed and poped using g_omx_port_release_buffer, g_omx_port_request_buffer. > > But eos buffer is only poped (not called g_omx_port_release_buffer). > After that g_omx_port_flush is called. > So only one buffer is remained in queue. > > And then play from the start of stream using this one buffer in queue. > At third time playback, there is no buffer in queue. > So g_omx_port_request_buffer is waiting infinitly in output loop. > > Please remember that omx component always return buffer, gst-omx queue mechanism is not proper. > > Regards, > Mickey |
From: Mickey K. <jih...@sa...> - 2010-08-19 05:35:21
|
Yes, buffer is back to gst-omx from openmax component. (by FillBufferDone) (This issue is for only output buffer, input buffer is ok.) At initial time, 2 output buffer are pushed into gst-omx queue. Then 2 buffers are pushed and poped using g_omx_port_release_buffer, g_omx_port_request_buffer. But eos buffer is only poped (not called g_omx_port_release_buffer). After that g_omx_port_flush is called. So only one buffer is remained in queue. And then play from the start of stream using this one buffer in queue. At third time playback, there is no buffer in queue. So g_omx_port_request_buffer is waiting infinitly in output loop. Please remember that omx component always return buffer, gst-omx queue mechanism is not proper. Regards, Mickey |
From: Mickey K. <jih...@sa...> - 2010-08-21 02:23:48
|
I cannot clone "git://anongit.freedesktop.org/gstreamer/gst-openmax". Could you please other methods to access gst-openmax git. I'm currently using "gst-openmax-0.10.0.5.tar.bz2" (it is downloaded form "http://cgit.freedesktop.org/gstreamer/gst-openmax/") Regards, Mickey |
From: Felipe C. <fel...@gm...> - 2010-08-23 14:31:41
|
On Sat, Aug 21, 2010 at 5:23 AM, Mickey Kim <jih...@sa...> wrote: > I cannot clone "git://anongit.freedesktop.org/gstreamer/gst-openmax". Works fine here. Are you sure it's not blocked in your network? > Could you please other methods to access gst-openmax git. How about my github one? (I just sync'ed it) http://github.com/felipec/gst-openmax -- Felipe Contreras |
From: Mickey K. <jih...@sa...> - 2010-08-24 02:36:45
|
Please find the attached file for patch. |
From: Rob C. <ro...@ti...> - 2010-08-29 20:50:02
|
The patch looks basically ok with a minor formatting tweak.. if you could send it inline with git-send-email[1], it makes it easier to review. > diff --git a/omx/gstomx_util.c b/omx/gstomx_util.c > index 283c32d..3ff88d8 100644 > --- a/omx/gstomx_util.c > +++ b/omx/gstomx_util.c > @@ -697,8 +697,17 @@ g_omx_port_flush (GOmxPort *port) > OMX_BUFFERHEADERTYPE *omx_buffer; > while ((omx_buffer = async_queue_pop_forced (port->queue))) > { > - omx_buffer->nFilledLen = 0; > - g_omx_port_release_buffer (port, omx_buffer); > + if(omx_buffer->nFlags & OMX_BUFFERFLAG_EOS) should have a space between "if" and "(" > + { > + 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 > (I guess that is easy enough to fix when pushing the patch, but Felipe would have to push the patch) Also, it's preferred to keep the commit comment at less than 80 columns. BR, -R [1] the following link may be helpful to send patches via gmail account.. I use this when sending patches from behind the firewall http://nishanthmenon.blogspot.com/2009/05/setting-up-email-forwarding-system-for_26.html On Aug 23, 2010, at 9:36 PM, Mickey Kim wrote: > > Please find the attached file for patch.<0001-gst-openmax-Fix-repeate-mode-issue-of-totem-player.patch>------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d_______________________________________________ > Gstreamer-openmax mailing list > Gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax |
From: Felipe C. <fel...@gm...> - 2010-08-30 10:37:41
|
On Sun, Aug 29, 2010 at 11:49 PM, Rob Clark <ro...@ti...> wrote: > (I guess that is easy enough to fix when pushing the patch, but Felipe > would have to push the patch) Yes, but I don't want to do it without testing that it's in fact needed, e.g. on libomxil-bellagio. Also, I think we should complain on gstreamer-devel on the account creation process. I also had to wait a completely unreasonable amount of time to get my account. Cheers. -- Felipe Contreras |
From: Felipe C. <fel...@gm...> - 2010-09-09 22:55:12
|
On Mon, Aug 30, 2010 at 1:37 PM, Felipe Contreras <fel...@gm...> wrote: > On Sun, Aug 29, 2010 at 11:49 PM, Rob Clark <ro...@ti...> wrote: >> (I guess that is easy enough to fix when pushing the patch, but Felipe >> would have to push the patch) > > Yes, but I don't want to do it without testing that it's in fact > needed, e.g. on libomxil-bellagio. Great. Apparently bellagio is completely broken. I can't use any openmax component on my laptop. -- Felipe Contreras |
From: Mickey K. <jih...@sa...> - 2010-08-30 10:40:05
|
<HTML><HEAD><TITLE>Samsung Enterprise Portal mySingle</TITLE> <META content="text/html; charset=utf-8" http-equiv=Content-Type> <STYLE id=mysingle_style>P { MARGIN-TOP: 5px; FONT-FAMILY: Times New Roman, arial; MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt } TD { MARGIN-TOP: 5px; FONT-FAMILY: Times New Roman, arial; MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt } LI { MARGIN-TOP: 5px; FONT-FAMILY: Times New Roman, arial; MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt } BODY { FONT-FAMILY: Times New Roman, arial; FONT-SIZE: 9pt } </STYLE> <META name=GENERATOR content=ActiveSquare></HEAD> <BODY> <P>From 794a96ffdbb7c1a4451ff0e0e14a7e2fad337c45 Mon Sep 17 00:00:00 2001<BR>From: mickey <<A href="mailto:mickey@avatar.(none">mickey@avatar.(none</A>)><BR>Date: Mon, 30 Aug 2010 15:44:00 +0900<BR>Subject: [PATCH] [gst-openmax] Fix repeate mode issue of totem player</P> <P>When totem play single file in playlist in repeat mode, single file is played for 2times.<BR>Totem stops at third time, only plays when seek button is pressed.<BR>When totem player detects EOS (end of stream) in repeat mode, it doesn't change the statete.<BR>gst-openmax, libomx source code are implemented without consideration of this case.<BR>The repeate mode without state change causes a buffer loss in gst-openmax queue for one repeatation.</P> <P>Singed-off-by: Mickey Kim <<A href="mailto:jih...@sa...">jih...@sa...</A>><BR>---<BR> omx/gstomx_base_filter.c | 1 +<BR> omx/gstomx_util.c | 13 +++++++++++--<BR> 2 files changed, 12 insertions(+), 2 deletions(-)</P> <P>diff --git a/omx/gstomx_base_filter.c b/omx/gstomx_base_filter.c<BR>index a16cb5f..40d4c4c 100644<BR>--- a/omx/gstomx_base_filter.c<BR>+++ b/omx/gstomx_base_filter.c<BR>@@ -504,6 +504,7 @@ output_loop (gpointer data)<BR> GST_DEBUG_OBJECT (self, "got eos");<BR> gst_pad_push_event (self->srcpad, gst_event_new_eos ());<BR> ret = GST_FLOW_UNEXPECTED;<BR>+ g_omx_port_push_buffer (out_port, omx_buffer);<BR> goto leave;<BR> }<BR> <BR>diff --git a/omx/gstomx_util.c b/omx/gstomx_util.c<BR>index 283c32d..ce226e0 100644<BR>--- a/omx/gstomx_util.c<BR>+++ b/omx/gstomx_util.c<BR>@@ -697,8 +697,17 @@ g_omx_port_flush (GOmxPort *port)<BR> OMX_BUFFERHEADERTYPE *omx_buffer;<BR> while ((omx_buffer = async_queue_pop_forced (port->queue)))<BR> {<BR>- omx_buffer->nFilledLen = 0;<BR>- g_omx_port_release_buffer (port, omx_buffer);<BR>+ if (omx_buffer->nFlags & OMX_BUFFERFLAG_EOS)<BR>+ {<BR>+ omx_buffer->nFlags = 0;<BR>+ g_omx_port_push_buffer (port, omx_buffer);<BR>+ break;<BR>+ }<BR>+ else<BR>+ {<BR>+ omx_buffer->nFilledLen = 0;<BR>+ g_omx_port_release_buffer (port, omx_buffer);<BR>+ }<BR> }<BR> }<BR> else<BR>-- <BR>1.7.0.4</P> <P><BR><BR> </P> <P></P></BODY></HTML> |
From: Mickey K. <jih...@sa...> - 2010-08-30 11:25:18
|
From 794a96ffdbb7c1a4451ff0e0e14a7e2fad337c45 Mon Sep 17 00:00:00 2001 From: mickey <mickey@avatar.(none)> Date: Mon, 30 Aug 2010 15:44:00 +0900 Subject: [PATCH] [gst-openmax] Fix repeate mode issue of totem player When totem play single file in playlist in repeat mode, single file is played for 2times. Totem stops at third time, only plays when seek button is pressed. When totem player detects EOS (end of stream) in repeat mode, it doesn't change the statete. gst-openmax, libomx source code are implemented without consideration of this case. The repeate mode without state change causes a buffer loss in gst-openmax queue for one repeatation. Singed-off-by: Mickey Kim <jih...@sa...> --- omx/gstomx_base_filter.c | 1 + omx/gstomx_util.c | 13 +++++++++++-- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/omx/gstomx_base_filter.c b/omx/gstomx_base_filter.c index a16cb5f..40d4c4c 100644 --- a/omx/gstomx_base_filter.c +++ b/omx/gstomx_base_filter.c @@ -504,6 +504,7 @@ output_loop (gpointer data) GST_DEBUG_OBJECT (self, "got eos"); gst_pad_push_event (self->srcpad, gst_event_new_eos ()); ret = GST_FLOW_UNEXPECTED; + g_omx_port_push_buffer (out_port, omx_buffer); goto leave; } diff --git a/omx/gstomx_util.c b/omx/gstomx_util.c index 283c32d..ce226e0 100644 --- a/omx/gstomx_util.c +++ b/omx/gstomx_util.c @@ -697,8 +697,17 @@ g_omx_port_flush (GOmxPort *port) OMX_BUFFERHEADERTYPE *omx_buffer; while ((omx_buffer = async_queue_pop_forced (port->queue))) { - omx_buffer->nFilledLen = 0; - g_omx_port_release_buffer (port, omx_buffer); + 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 -- 1.7.0.4 |
From: Felipe C. <fel...@gm...> - 2010-09-09 23:06:05
|
On Mon, Aug 30, 2010 at 2:25 PM, Mickey Kim <jih...@sa...> wrote: > >From 794a96ffdbb7c1a4451ff0e0e14a7e2fad337c45 Mon Sep 17 00:00:00 2001 > From: mickey <mickey@avatar.(none)> > Date: Mon, 30 Aug 2010 15:44:00 +0900 > Subject: [PATCH] [gst-openmax] Fix repeate mode issue of totem player > When totem play single file in playlist in repeat mode, single file is played for 2times. > Totem stops at third time, only plays when seek button is pressed. > When totem player detects EOS (end of stream) in repeat mode, it doesn't change the statete. > gst-openmax, libomx source code are implemented without consideration of this case. > The repeate mode without state change causes a buffer loss in gst-openmax queue for one repeatation. > Singed-off-by: Mickey Kim <jih...@sa...> > --- > omx/gstomx_base_filter.c | 1 + > omx/gstomx_util.c | 13 +++++++++++-- > 2 files changed, 12 insertions(+), 2 deletions(-) > diff --git a/omx/gstomx_base_filter.c b/omx/gstomx_base_filter.c > index a16cb5f..40d4c4c 100644 > --- a/omx/gstomx_base_filter.c > +++ b/omx/gstomx_base_filter.c > @@ -504,6 +504,7 @@ output_loop (gpointer data) > GST_DEBUG_OBJECT (self, "got eos"); > gst_pad_push_event (self->srcpad, gst_event_new_eos ()); > ret = GST_FLOW_UNEXPECTED; > + g_omx_port_push_buffer (out_port, omx_buffer); > goto leave; > } > > diff --git a/omx/gstomx_util.c b/omx/gstomx_util.c > index 283c32d..ce226e0 100644 > --- a/omx/gstomx_util.c > +++ b/omx/gstomx_util.c > @@ -697,8 +697,17 @@ g_omx_port_flush (GOmxPort *port) > OMX_BUFFERHEADERTYPE *omx_buffer; > while ((omx_buffer = async_queue_pop_forced (port->queue))) > { > - omx_buffer->nFilledLen = 0; > - g_omx_port_release_buffer (port, omx_buffer); > + 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 > -- > 1.7.0.4 I don't think this is the right approach. Buffers marked with EOS should not be any different from other buffers; they should be returned with OMX_FillThisBuffer(). However, it does seem true that the EOS is not handled correctly as the buffers are lost. What do you think about this instead? --- a/omx/gstomx_base_filter.c +++ b/omx/gstomx_base_filter.c @@ -499,14 +499,6 @@ output_loop (gpointer data) GST_WARNING_OBJECT (self, "empty buffer"); } - 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; - goto leave; - } - if (self->share_output_buffer && !omx_buffer->pBuffer && omx_buffer->nOffset == 0) @@ -542,6 +534,14 @@ output_loop (gpointer data) GST_ERROR_OBJECT (self, "no input buffer to share"); } + 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 ()); + omx_buffer->nFlags &= ~OMX_BUFFERFLAG_EOS; + ret = GST_FLOW_UNEXPECTED; + } + omx_buffer->nFilledLen = 0; GST_LOG_OBJECT (self, "release_buffer"); g_omx_port_release_buffer (out_port, omx_buffer); -- Felipe Contreras |
From: Clark, R. <ro...@ti...> - 2010-09-11 17:08:28
|
On Thu, Sep 9, 2010 at 6:06 PM, Felipe Contreras <fel...@gm...> wrote: > > On Mon, Aug 30, 2010 at 2:25 PM, Mickey Kim <jih...@sa...> wrote: > > diff --git a/omx/gstomx_util.c b/omx/gstomx_util.c > > index 283c32d..ce226e0 100644 > > --- a/omx/gstomx_util.c > > +++ b/omx/gstomx_util.c > > @@ -697,8 +697,17 @@ g_omx_port_flush (GOmxPort *port) > > OMX_BUFFERHEADERTYPE *omx_buffer; > > while ((omx_buffer = async_queue_pop_forced (port->queue))) > > { > > - omx_buffer->nFilledLen = 0; > > - g_omx_port_release_buffer (port, omx_buffer); > > + 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 > > -- > > 1.7.0.4 > > I don't think this is the right approach. > > Buffers marked with EOS should not be any different from other > buffers; they should be returned with OMX_FillThisBuffer(). but then I think you could loose the EOS (if the IL client clears the flags before again returning the buffer).. I guess this is probably more of a theoretical hole, because it would require an eos event followed by flush-start/flush-stop.. BR, -R |
From: Felipe C. <fel...@gm...> - 2010-09-13 08:53:45
|
On Sat, Sep 11, 2010 at 7:36 PM, Clark, Rob <ro...@ti...> wrote: > On Thu, Sep 9, 2010 at 6:06 PM, Felipe Contreras > <fel...@gm...> wrote: >> >> On Mon, Aug 30, 2010 at 2:25 PM, Mickey Kim <jih...@sa...> wrote: >> > diff --git a/omx/gstomx_util.c b/omx/gstomx_util.c >> > index 283c32d..ce226e0 100644 >> > --- a/omx/gstomx_util.c >> > +++ b/omx/gstomx_util.c >> > @@ -697,8 +697,17 @@ g_omx_port_flush (GOmxPort *port) >> > OMX_BUFFERHEADERTYPE *omx_buffer; >> > while ((omx_buffer = async_queue_pop_forced (port->queue))) >> > { >> > - omx_buffer->nFilledLen = 0; >> > - g_omx_port_release_buffer (port, omx_buffer); >> > + 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 >> > -- >> > 1.7.0.4 >> >> I don't think this is the right approach. >> >> Buffers marked with EOS should not be any different from other >> buffers; they should be returned with OMX_FillThisBuffer(). > > but then I think you could loose the EOS (if the IL client clears the > flags before again returning the buffer).. We are the IL client. We are not clearing the flags anywhere. > I guess this is probably more of a theoretical hole, because it would > require an eos event followed by flush-start/flush-stop.. Yes, but in my approach I'm clearing the flag only after pushing the EOS. If this problem really exists, it would be with Mickey's approach. -- Felipe Contreras |
From: Mickey K. <jih...@sa...> - 2010-09-13 04:27:56
|
<HTML><HEAD><TITLE>Samsung Enterprise Portal mySingle</TITLE> <META content="text/html; charset=utf-8" http-equiv=Content-Type> <STYLE id=mysingle_style>P { MARGIN-TOP: 5px; FONT-FAMILY: Times New Roman, arial; MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt } TD { MARGIN-TOP: 5px; FONT-FAMILY: Times New Roman, arial; MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt } LI { MARGIN-TOP: 5px; FONT-FAMILY: Times New Roman, arial; MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt } BODY { FONT-FAMILY: Times New Roman, arial; FONT-SIZE: 9pt } </STYLE> <META name=GENERATOR content=ActiveSquare></HEAD> <BODY> <P>But EOS buffer is still lost in your apporoach.</P> <P>We need to decide how popped eos buffer is processed. (currently this buffer is lost).</P> <P> </P> <P>Anyway I cannot resolve repeatation problem using your patch.</P><BR><BR>------- <B>Original Message</B> -------<BR><B>Sender</B> : Felipe Contreras<fel...@gm...><BR><B>Date</B> : 2010-09-10 08:06 (GMT+09:00)<BR><B>Title</B> : Re: [Gstreamer-openmax] Repeat Mode of Totem Player<BR><BR>On Mon, Aug 30, 2010 at 2:25 PM, Mickey Kim <jih...@sa...> wrote: <BR>> >From 794a96ffdbb7c1a4451ff0e0e14a7e2fad337c45 Mon Sep 17 00:00:00 2001 <BR>> From: mickey <mickey@avatar.(none)> <BR>> Date: Mon, 30 Aug 2010 15:44:00 +0900 <BR>> Subject: [PATCH] [gst-openmax] Fix repeate mode issue of totem player <BR>> When totem play single file in playlist in repeat mode, single file is played for 2times. <BR>> Totem stops at third time, only plays when seek button is pressed. <BR>> When totem player detects EOS (end of stream) in repeat mode, it doesn't change the statete. <BR>> gst-openmax, libomx source code are implemented without consideration of this case. <BR>> The repeate mode without state change causes a buffer loss in gst-openmax queue for one repeatation. <BR>> Singed-off-by: Mickey Kim <jih...@sa...> <BR>> --- <BR>> omx/gstomx_base_filter.c | 1 + <BR>> omx/gstomx_util.c | 13 +++++++++++-- <BR>> 2 files changed, 12 insertions(+), 2 deletions(-) <BR>> diff --git a/omx/gstomx_base_filter.c b/omx/gstomx_base_filter.c <BR>> index a16cb5f..40d4c4c 100644 <BR>> --- a/omx/gstomx_base_filter.c <BR>> +++ b/omx/gstomx_base_filter.c <BR>> @@ -504,6 +504,7 @@ output_loop (gpointer data) <BR>> GST_DEBUG_OBJECT (self, "got eos"); <BR>> gst_pad_push_event (self->srcpad, gst_event_new_eos ()); <BR>> ret = GST_FLOW_UNEXPECTED; <BR>> + g_omx_port_push_buffer (out_port, omx_buffer); <BR>> goto leave; <BR>> } <BR>> <BR>> diff --git a/omx/gstomx_util.c b/omx/gstomx_util.c <BR>> index 283c32d..ce226e0 100644 <BR>> --- a/omx/gstomx_util.c <BR>> +++ b/omx/gstomx_util.c <BR>> @@ -697,8 +697,17 @@ g_omx_port_flush (GOmxPort *port) <BR>> OMX_BUFFERHEADERTYPE *omx_buffer; <BR>> while ((omx_buffer = async_queue_pop_forced (port->queue))) <BR>> { <BR>> - omx_buffer->nFilledLen = 0; <BR>> - g_omx_port_release_buffer (port, omx_buffer); <BR>> + if (omx_buffer->nFlags & OMX_BUFFERFLAG_EOS) <BR>> + { <BR>> + omx_buffer->nFlags = 0; <BR>> + g_omx_port_push_buffer (port, omx_buffer); <BR>> + break; <BR>> + } <BR>> + else <BR>> + { <BR>> + omx_buffer->nFilledLen = 0; <BR>> + g_omx_port_release_buffer (port, omx_buffer); <BR>> + } <BR>> } <BR>> } <BR>> else <BR>> -- <BR>> 1.7.0.4 <BR><BR>I don't think this is the right approach. <BR><BR>Buffers marked with EOS should not be any different from other <BR>buffers; they should be returned with OMX_FillThisBuffer(). <BR><BR>However, it does seem true that the EOS is not handled correctly as <BR>the buffers are lost. <BR><BR>What do you think about this instead? <BR><BR>--- a/omx/gstomx_base_filter.c <BR>+++ b/omx/gstomx_base_filter.c <BR>@@ -499,14 +499,6 @@ output_loop (gpointer data) <BR> GST_WARNING_OBJECT (self, "empty buffer"); <BR> } <BR><BR>- if (G_UNLIKELY (omx_buffer->nFlags & OMX_BUFFERFLAG_EOS)) <BR>- { <BR>- GST_DEBUG_OBJECT (self, "got eos"); <BR>- gst_pad_push_event (self->srcpad, gst_event_new_eos ()); <BR>- ret = GST_FLOW_UNEXPECTED; <BR>- goto leave; <BR>- } <BR>- <BR> if (self->share_output_buffer && <BR> !omx_buffer->pBuffer && <BR> omx_buffer->nOffset == 0) <BR>@@ -542,6 +534,14 @@ output_loop (gpointer data) <BR> GST_ERROR_OBJECT (self, "no input buffer to share"); <BR> } <BR><BR>+ if (G_UNLIKELY (omx_buffer->nFlags & OMX_BUFFERFLAG_EOS)) <BR>+ { <BR>+ GST_DEBUG_OBJECT (self, "got eos"); <BR>+ gst_pad_push_event (self->srcpad, gst_event_new_eos ()); <BR>+ omx_buffer->nFlags &= ~OMX_BUFFERFLAG_EOS; <BR>+ ret = GST_FLOW_UNEXPECTED; <BR>+ } <BR>+ <BR> omx_buffer->nFilledLen = 0; <BR> GST_LOG_OBJECT (self, "release_buffer"); <BR> g_omx_port_release_buffer (out_port, omx_buffer); <BR><BR>-- <BR>Felipe Contreras <BR><BR> <TABLE id=confidentialsignimg> <TBODY> <TR> <TD NAMO_LOCK> <P><IMG border=0 src="cid:QKN...@na..." width=520></P></TD></TR></TBODY></TABLE> <P></P></BODY></HTML> |
From: Felipe C. <fel...@gm...> - 2010-09-13 08:57:36
|
On Mon, Sep 13, 2010 at 7:27 AM, Mickey Kim <jih...@sa...> wrote: > But EOS buffer is still lost in your apporoach. And is that a problem in your omx implementation or my approach? > We need to decide how popped eos buffer is processed. (currently this buffer is lost). > > Anyway I cannot resolve repeatation problem using your patch. If my patch is working, then the EOS buffer should have the flag cleared, and they returned to the component with OMX_FillThisBuffer(). If the buffer is lost, could it be because the component is dropping it? Anyway, I have no way to test this right now, but my guess is that it would work fine on other omx implementations. -- Felipe Contreras |
From: Mickey K. <jih...@sa...> - 2010-09-13 05:15:11
|
<HTML><HEAD><TITLE>Samsung Enterprise Portal mySingle</TITLE> <META content="text/html; charset=utf-8" http-equiv=Content-Type> <STYLE id=mysingle_style>P { MARGIN-TOP: 5px; FONT-FAMILY: Times New Roman, arial; MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt } TD { MARGIN-TOP: 5px; FONT-FAMILY: Times New Roman, arial; MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt } LI { MARGIN-TOP: 5px; FONT-FAMILY: Times New Roman, arial; MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt } BODY { FONT-FAMILY: Times New Roman, arial; FONT-SIZE: 9pt } </STYLE> <META name=GENERATOR content=ActiveSquare></HEAD> <BODY> <P>If I add,</P> <P>When gstomx meet the buffer with EOS, it doesn't call OMX_FillThisBuffer(). (because it doesn't call g_omx_port_release_buffer()).</P> <P>So below your opinion is not valid in case of EOS buffer.</P> <P> </P> <P><SPAN style="COLOR: #ff0000">Buffers marked with EOS should not be any different from other <BR>buffers; they should be returned with OMX_FillThisBuffer(). </SPAN></P> <P> </P> <P> </P> <P>Regards,</P> <P>Mickey</P><BR><BR>------- <B>Original Message</B> -------<BR><B>Sender</B> : 김지훈<jih...@sa...> E5(책임)/책임/S/W Solution개발팀(S.LSI)/삼성전자<BR><B>Date</B> : 2010-09-13 13:27 (GMT+09:00)<BR><B>Title</B> : Re: [Gstreamer-openmax] Repeat Mode of Totem Player<BR><BR> <META name=GENERATOR content=ActiveSquare><X-BODY> <P>But EOS buffer is still lost in your apporoach.</P> <P>We need to decide how popped eos buffer is processed. (currently this buffer is lost).</P> <P> </P> <P>Anyway I cannot resolve repeatation problem using your patch.</P><BR><BR>------- <B>Original Message</B> -------<BR><B>Sender</B> : Felipe Contreras<fel...@gm...><BR><B>Date</B> : 2010-09-10 08:06 (GMT+09:00)<BR><B>Title</B> : Re: [Gstreamer-openmax] Repeat Mode of Totem Player<BR><BR>On Mon, Aug 30, 2010 at 2:25 PM, Mickey Kim <jih...@sa...> wrote: <BR>> >From 794a96ffdbb7c1a4451ff0e0e14a7e2fad337c45 Mon Sep 17 00:00:00 2001 <BR>> From: mickey <mickey@avatar.(none)> <BR>> Date: Mon, 30 Aug 2010 15:44:00 +0900 <BR>> Subject: [PATCH] [gst-openmax] Fix repeate mode issue of totem player <BR>> When totem play single file in playlist in repeat mode, single file is played for 2times. <BR>> Totem stops at third time, only plays when seek button is pressed. <BR>> When totem player detects EOS (end of stream) in repeat mode, it doesn't change the statete. <BR>> gst-openmax, libomx source code are implemented without consideration of this case. <BR>> The repeate mode without state change causes a buffer loss in gst-openmax queue for one repeatation. <BR>> Singed-off-by: Mickey Kim <jih...@sa...> <BR>> --- <BR>> omx/gstomx_base_filter.c | 1 + <BR>> omx/gstomx_util.c | 13 +++++++++++-- <BR>> 2 files changed, 12 insertions(+), 2 deletions(-) <BR>> diff --git a/omx/gstomx_base_filter.c b/omx/gstomx_base_filter.c <BR>> index a16cb5f..40d4c4c 100644 <BR>> --- a/omx/gstomx_base_filter.c <BR>> +++ b/omx/gstomx_base_filter.c <BR>> @@ -504,6 +504,7 @@ output_loop (gpointer data) <BR>> GST_DEBUG_OBJECT (self, "got eos"); <BR>> gst_pad_push_event (self->srcpad, gst_event_new_eos ()); <BR>> ret = GST_FLOW_UNEXPECTED; <BR>> + g_omx_port_push_buffer (out_port, omx_buffer); <BR>> goto leave; <BR>> } <BR>> <BR>> diff --git a/omx/gstomx_util.c b/omx/gstomx_util.c <BR>> index 283c32d..ce226e0 100644 <BR>> --- a/omx/gstomx_util.c <BR>> +++ b/omx/gstomx_util.c <BR>> @@ -697,8 +697,17 @@ g_omx_port_flush (GOmxPort *port) <BR>> OMX_BUFFERHEADERTYPE *omx_buffer; <BR>> while ((omx_buffer = async_queue_pop_forced (port->queue))) <BR>> { <BR>> - omx_buffer->nFilledLen = 0; <BR>> - g_omx_port_release_buffer (port, omx_buffer); <BR>> + if (omx_buffer->nFlags & OMX_BUFFERFLAG_EOS) <BR>> + { <BR>> + omx_buffer->nFlags = 0; <BR>> + g_omx_port_push_buffer (port, omx_buffer); <BR>> + break; <BR>> + } <BR>> + else <BR>> + { <BR>> + omx_buffer->nFilledLen = 0; <BR>> + g_omx_port_release_buffer (port, omx_buffer); <BR>> + } <BR>> } <BR>> } <BR>> else <BR>> -- <BR>> 1.7.0.4 <BR><BR>I don't think this is the right approach. <BR><BR>Buffers marked with EOS should not be any different from other <BR>buffers; they should be returned with OMX_FillThisBuffer(). <BR><BR>However, it does seem true that the EOS is not handled correctly as <BR>the buffers are lost. <BR><BR>What do you think about this instead? <BR><BR>--- a/omx/gstomx_base_filter.c <BR>+++ b/omx/gstomx_base_filter.c <BR>@@ -499,14 +499,6 @@ output_loop (gpointer data) <BR> GST_WARNING_OBJECT (self, "empty buffer"); <BR> } <BR><BR>- if (G_UNLIKELY (omx_buffer->nFlags & OMX_BUFFERFLAG_EOS)) <BR>- { <BR>- GST_DEBUG_OBJECT (self, "got eos"); <BR>- gst_pad_push_event (self->srcpad, gst_event_new_eos ()); <BR>- ret = GST_FLOW_UNEXPECTED; <BR>- goto leave; <BR>- } <BR>- <BR> if (self->share_output_buffer && <BR> !omx_buffer->pBuffer && <BR> omx_buffer->nOffset == 0) <BR>@@ -542,6 +534,14 @@ output_loop (gpointer data) <BR> GST_ERROR_OBJECT (self, "no input buffer to share"); <BR> } <BR><BR>+ if (G_UNLIKELY (omx_buffer->nFlags & OMX_BUFFERFLAG_EOS)) <BR>+ { <BR>+ GST_DEBUG_OBJECT (self, "got eos"); <BR>+ gst_pad_push_event (self->srcpad, gst_event_new_eos ()); <BR>+ omx_buffer->nFlags &= ~OMX_BUFFERFLAG_EOS; <BR>+ ret = GST_FLOW_UNEXPECTED; <BR>+ } <BR>+ <BR> omx_buffer->nFilledLen = 0; <BR> GST_LOG_OBJECT (self, "release_buffer"); <BR> g_omx_port_release_buffer (out_port, omx_buffer); <BR><BR>-- <BR>Felipe Contreras <BR><BR> <P></P></X-BODY><BR> <TABLE id=confidentialsignimg> <TBODY> <TR> <TD NAMO_LOCK> <P><IMG border=0 src="cid:QKN...@na..." width=520></P></TD></TR></TBODY></TABLE> <P></P></BODY></HTML> |
From: Felipe C. <fel...@gm...> - 2010-09-13 09:00:17
|
On Mon, Sep 13, 2010 at 8:14 AM, Mickey Kim <jih...@sa...> wrote: > When gstomx meet the buffer with EOS, it doesn't call OMX_FillThisBuffer(). (because it doesn't call g_omx_port_release_buffer()). That's what my patch is supposed to fix; g_omx_port_release_buffer() is called now. P.S. Please read http://en.wikipedia.org/wiki/Posting_style, we use interleaved style, not top-posting. -- Felipe Contreras |
From: Mickey K. <jih...@sa...> - 2010-09-13 10:28:14
|
Felipe Contreras<fel...@gm...> wrote: > That's what my patch is supposed to fix; g_omx_port_release_buffer() > is called now. I'm sorry. There is my mistake when I apply your patch. It is woking well now. I think your approach is also good and more simple. If there is not any more issue, I think it is good to apply your patch. Regards, Mickey |
From: Felipe C. <fel...@gm...> - 2010-09-13 11:02:24
|
On Mon, Sep 13, 2010 at 1:27 PM, Mickey Kim <jih...@sa...> wrote: > Felipe Contreras<fel...@gm...> wrote: >> That's what my patch is supposed to fix; g_omx_port_release_buffer() >> is called now. > > I'm sorry. > There is my mistake when I apply your patch. > It is woking well now. > I think your approach is also good and more simple. > If there is not any more issue, I think it is good to apply your patch. Excellent, I'll apply the patch then, and add a note that you reviewed/tested it :) -- Felipe Contreras |