Menu
▾
▴
gstreamer-openmax — Development list for GStreamer OpenMax plugins
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
|
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(5) |
Feb
(3) |
Mar
|
Apr
(2) |
May
(4) |
Jun
(1) |
Jul
(11) |
Aug
(31) |
Sep
(2) |
Oct
(21) |
Nov
(16) |
Dec
(56) |
| 2009 |
Jan
(12) |
Feb
(5) |
Mar
(34) |
Apr
(9) |
May
(5) |
Jun
(7) |
Jul
(18) |
Aug
(5) |
Sep
(2) |
Oct
(6) |
Nov
(50) |
Dec
|
| 2010 |
Jan
(3) |
Feb
(67) |
Mar
(135) |
Apr
(30) |
May
(2) |
Jun
(11) |
Jul
|
Aug
(18) |
Sep
(12) |
Oct
(4) |
Nov
(17) |
Dec
(11) |
| 2011 |
Jan
(14) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Mickey K. <jih...@sa...> - 2010-08-16 04:02:19
|
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
|
|
From: 김지훈 <jih...@sa...> - 2010-08-16 00:50:44
|
<HTML><HEAD><TITLE>Samsung Enterprise Portal mySingle</TITLE>
<META content="text/html; charset=euc-kr" 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>I'm using Totem Player on Ubuntu.</P>
<P>When I check repeat mode option in totem, player stops after only two time repeatation.</P>
<P> </P>
<P>I could find that totem doesn't change the state, when it meet the end of stream.</P>
<P>But I also could find gst-openmax code doesn't consider this case.</P>
<P>When gst-openmax meet EOS, it throw output buffer of queue (in output_loop()).</P>
<P>So there is one buffer loss during one time repeatation.</P>
<P><BR>
<META name=GENERATOR content=ActiveSquare><X-BODY><BR>To resolve this issue, I have modified two function as below.</P>
<P> </P>
<P>output_loop ()</P>
<P>{</P>
<P>...</P>
<P> 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;</P>
<P> // 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><SPAN style="COLOR: #ff0000">#if 1<BR> g_omx_port_push_buffer (out_port, omx_buffer);<BR>#endif</SPAN><BR> goto leave;<BR> }</P>
<P>...</P>
<P>}</P>
<P> </P>
<P>g_omx_port_flush()</P>
<P>{</P>
<P> 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><SPAN style="COLOR: #ff0000">#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><SPAN style="COLOR: #ff0000">#else</SPAN></SPAN><SPAN style="COLOR: #ff0000"><BR> omx_buffer->nFilledLen = 0;<BR> g_omx_port_release_buffer (port, omx_buffer);<BR>#endif</SPAN><BR> }<BR> }</P>
<P>....</P>
<P>}</P>
<P> </P>
<P> </P>
<P>Please give your opinion.</P>
<P> </P>
<P>Regards,</P>
<P>Mickey</P>
<P><BR> </P>
<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: Rob C. <ro...@ti...> - 2010-06-29 22:02:42
|
On 06/29/2010 04:30 PM, hd d wrote: > thanks for the response - yes - i am referring to linux - can you give > a more detailed call flow on what happens in user space and kernel > space. How does sink element pass memory region to decoder element in > user space? omx decoder element needs an fd, offset, length to mmap > framebuffer memory into user space or does this all happen in kernel > space without any intervention in userspace/framework. This applies to > use cases like camera v4l2 src sending data to omx video encoder in > gst framework. if camera and omx vid enc need to share the same > physical memory, additional information about memory region (like a > buffer identifier or fd) needs to be exchanged between user space > elements in gst. typically the decoder would not care too much about *where* the sink got the memory.. but would just use pad_alloc() to allow the video sink element to allocate memory which the video sink thinks the decoder should decode into.. some video sinks (for example, v4l2sink or omapfbsink) will mmap buffers into userspace, and then pass this to the decoder. But normally the decoder doesn't need to know which fd was mmap'd, the offset, etc. But if your decoder requires physically contiguous memory, with no possibility to remap virtually contiguous memory, then it possibly gets complicated. (Not to mention, various useful elements for debugging, like filesink, won't work to well..) btw, v4l2src (camera/encode) might be a bad example.. since what is in gst-plugins-good doesn't support pad_alloc() / USERPTR. So it allocates it's own buffers. But there are other camera elements which do a similar thing to what you describe, doing pad_alloc() to allocate buffers from the display, which then get sent to both encoder and sink element. BR, -R |
|
From: hd d <hda...@gm...> - 2010-06-29 21:30:50
|
thanks for the response - yes - i am referring to linux - can you give a more detailed call flow on what happens in user space and kernel space. How does sink element pass memory region to decoder element in user space? omx decoder element needs an fd, offset, length to mmap framebuffer memory into user space or does this all happen in kernel space without any intervention in userspace/framework. This applies to use cases like camera v4l2 src sending data to omx video encoder in gst framework. if camera and omx vid enc need to share the same physical memory, additional information about memory region (like a buffer identifier or fd) needs to be exchanged between user space elements in gst. On Tue, Jun 29, 2010 at 3:38 AM, Felipe Contreras < fel...@no...> wrote: > hda...@gm... wrote: > > New to gst - need some help: > > > > what is the best way to pass meta data from one element to the other in > gst > > pipeline? > > example use case: in a HW accelerated transcoding session, OMX video > decoder > > output buffer is sent to OMX video encode. decoder output is present > in a > > physically contiguous memory identified by a file descriptor and > encode > > needs to use this file descriptor to derive the physical address of > > decoder's output buffer. OMX buffer header provides platform private > field > > to carry platform specific data. > > Gst seems to define buffer meta data but what is the best place to > embed > > this information. Does gst have any platform private/reserved fields > > (similar to OMX buffer hdr platform private data) to carry such > information? > > > http://www.gstreamer.net/data/doc/gstreamer/head/gstreamer/html/gstreamer-GstBuffer.html#GstBufferFlag > > Another question is how does buffer from one element get passed to > another > > element when elements are in different processes? Or gst assume all > elements > > run in the same process.this cannot be practical scenario as usually > display > > resides in a different process. > > All GStreamer elements run in the same process. The display server might > run in a separate process, but that's independent of GStreamer (i.e. the > API is X11, not Gst). > > If you only want to provide custom data between two contiguous elements in > the > pipeline you have two options: > > 1) Provide a GstBuffer sub-type, like GstOmxBuffer. Then it should be > easy to add any information that you want, but you should check that > the GType is the right one. > > 2) Add a custom field to the GstCaps of the buffer. > > However, I don't see why you need a fd for contiguous memory. On OMAP3 > platform I have simple sink element that provides framebuffer memory > (which is contiguous), and the video decoder element mmaps that memory. > At kernel level the dspbridge driver is able to identify this memory as > VM_IO, and the mmap operation is very fast. IOW; everything happens > behind the scene; at kernel level. > > Are we talking about linux? > > -- > Felipe Contreras > |
|
From: Felipe C. <fel...@no...> - 2010-06-29 11:47:01
|
hda...@gm... wrote: > New to gst - need some help: > > what is the best way to pass meta data from one element to the other in gst > pipeline? > example use case: in a HW accelerated transcoding session, OMX video decoder > output buffer is sent to OMX video encode. decoder output is present in a > physically contiguous memory identified by a file descriptor and encode > needs to use this file descriptor to derive the physical address of > decoder's output buffer. OMX buffer header provides platform private field > to carry platform specific data. > Gst seems to define buffer meta data but what is the best place to embed > this information. Does gst have any platform private/reserved fields > (similar to OMX buffer hdr platform private data) to carry such information? > http://www.gstreamer.net/data/doc/gstreamer/head/gstreamer/html/gstreamer-GstBuffer.html#GstBufferFlag > Another question is how does buffer from one element get passed to another > element when elements are in different processes? Or gst assume all elements > run in the same process.this cannot be practical scenario as usually display > resides in a different process. All GStreamer elements run in the same process. The display server might run in a separate process, but that's independent of GStreamer (i.e. the API is X11, not Gst). If you only want to provide custom data between two contiguous elements in the pipeline you have two options: 1) Provide a GstBuffer sub-type, like GstOmxBuffer. Then it should be easy to add any information that you want, but you should check that the GType is the right one. 2) Add a custom field to the GstCaps of the buffer. However, I don't see why you need a fd for contiguous memory. On OMAP3 platform I have simple sink element that provides framebuffer memory (which is contiguous), and the video decoder element mmaps that memory. At kernel level the dspbridge driver is able to identify this memory as VM_IO, and the mmap operation is very fast. IOW; everything happens behind the scene; at kernel level. Are we talking about linux? -- Felipe Contreras |
|
From: Victor M. J. L. <ce...@gm...> - 2010-06-29 10:37:49
|
> Yes, I'm not interested on maintaining the 'omap' branch any more. > > Ideally TI should fix their implementation, and/or submit patches to > gst-openmax to add whatever if missing. If there's another repository > that works, I would gladly drop the 'omap' branch from the official > repo. > > Does this sound reasonable? OK. I'll do that. vmjl |
|
From: Felipe C. <fel...@no...> - 2010-06-29 10:15:21
|
ce...@gm... wrote: > Right now the instruction in elinux.org [1] are pretty broken because > the repository git://github.com/felipec/gst-openmax.git > is obsolete by now. > > The official repository also has a branch for omap but it is not > rebased against the current HEAD. The idea was to merge 'master' to 'omap', rather than rebase. AFAIK that branch should still work (even if not up-to-date). > So, > > a) How should we update the instructions in elinux.org? (also I want > to notice that depending on scratchbox is not a good idea imo) > > b) Is it a good idea provide another repository (I've an untested > rebased branch) for omap/beagleboard ? > > 1. http://elinux.org/BeagleBoard/gst-openmax Yes, I'm not interested on maintaining the 'omap' branch any more. Ideally TI should fix their implementation, and/or submit patches to gst-openmax to add whatever if missing. If there's another repository that works, I would gladly drop the 'omap' branch from the official repo. Does this sound reasonable? -- Felipe Contreras |
|
From: hd d <hda...@gm...> - 2010-06-29 07:09:17
|
New to gst - need some help: what is the best way to pass meta data from one element to the other in gst pipeline? example use case: in a HW accelerated transcoding session, OMX video decoder output buffer is sent to OMX video encode. decoder output is present in a physically contiguous memory identified by a file descriptor and encode needs to use this file descriptor to derive the physical address of decoder's output buffer. OMX buffer header provides platform private field to carry platform specific data. Gst seems to define buffer meta data but what is the best place to embed this information. Does gst have any platform private/reserved fields (similar to OMX buffer hdr platform private data) to carry such information? http://www.gstreamer.net/data/doc/gstreamer/head/gstreamer/html/gstreamer-GstBuffer.html#GstBufferFlag Another question is how does buffer from one element get passed to another element when elements are in different processes? Or gst assume all elements run in the same process.this cannot be practical scenario as usually display resides in a different process. |
|
From: Victor M. J. L. <ce...@gm...> - 2010-06-23 11:53:06
|
Hi, Right now the instruction in elinux.org [1] are pretty broken because the repository git://github.com/felipec/gst-openmax.git is obsolete by now. The official repository also has a branch for omap but it is not rebased against the current HEAD. So, a) How should we update the instructions in elinux.org? (also I want to notice that depending on scratchbox is not a good idea imo) b) Is it a good idea provide another repository (I've an untested rebased branch) for omap/beagleboard ? 1. http://elinux.org/BeagleBoard/gst-openmax regards, vmjl |
|
From: Felipe C. <fel...@gm...> - 2010-06-03 10:19:42
|
Hi Giulio, On Thu, Jun 3, 2010 at 12:49 PM, giulio urlini <giu...@gm...> wrote: > the error produced by the OpenMAX component is generated because the > output buffer size is less than the minimum needed size. The problem > should be found in the allocation of the buffers done by the > application, that in this case is the gst element or the gst > framework. There is a way to specify the size of the buffers needed? gst-openmax uses the field nBufferSize from the port settings. So my guess is that the component is not configuring that properly. -- Felipe Contreras |
|
From: giulio u. <giu...@gm...> - 2010-06-03 09:49:08
|
Hi All, the error produced by the OpenMAX component is generated because the output buffer size is less than the minimum needed size. The problem should be found in the allocation of the buffers done by the application, that in this case is the gst element or the gst framework. There is a way to specify the size of the buffers needed? Giulio Urlini On Tue, Jun 1, 2010 at 14:12, Felipe Contreras <fel...@gm...> wrote: > On Tue, Jun 1, 2010 at 1:22 PM, 代坤娟 <dai...@gm...> wrote: >> i want to use omx_aacdec to play aac audio, but it cant work and displays: >> >> OMX-In omx_audiodec_component_ >> BufferMgmtCallback output size is not enough 32768 >> OMX-In omx_audiodec_component_BufferMgmtCallback output size is not enough >> 32768 >> OMX-In omx_audiodec_component_BufferMgmtCallback output size is not enough >> 32768 > > That error message is not from gst-openmax, but looks like you are > using bellagio. I am cross posting to their ml. > > -- > Felipe Contreras > > ------------------------------------------------------------------------------ > > _______________________________________________ > Omxil-devel mailing list > Omx...@li... > https://lists.sourceforge.net/lists/listinfo/omxil-devel > |
|
From: Felipe C. <fel...@gm...> - 2010-06-01 12:39:17
|
On Tue, Jun 1, 2010 at 1:22 PM, 代坤娟 <dai...@gm...> wrote: > i want to use omx_aacdec to play aac audio, but it cant work and displays: > > OMX-In omx_audiodec_component_ > BufferMgmtCallback output size is not enough 32768 > OMX-In omx_audiodec_component_BufferMgmtCallback output size is not enough > 32768 > OMX-In omx_audiodec_component_BufferMgmtCallback output size is not enough > 32768 That error message is not from gst-openmax, but looks like you are using bellagio. I am cross posting to their ml. -- Felipe Contreras |
|
From: 代坤娟 <dai...@gm...> - 2010-06-01 10:22:20
|
hello i want to use omx_aacdec to play aac audio, but it cant work and displays: OMX-In omx_audiodec_component_ BufferMgmtCallback output size is not enough 32768 OMX-In omx_audiodec_component_BufferMgmtCallback output size is not enough 32768 OMX-In omx_audiodec_component_BufferMgmtCallback output size is not enough 32768 i configure the gst-omx with --enable-experimental , gst-launch-0.10 filesrc location="/usr/local/demo/lt.aac" ! aacparse ! omx_aacdec ! audioresample ! alsasink what is the problem, pls help me! daisy |
|
From: Felipe C. <fel...@gm...> - 2010-05-19 15:51:55
|
Hi Ivan, On Wed, May 19, 2010 at 6:22 PM, Maldonado Zambrano, Ivan <iva...@ti...> wrote: > I have a few days working on gstreamer and I have a doubt. > > I’m checking a defect in a decoder. In my code there is a function that > looks for a “codec_data” field: > > gst_structure_has_field (structure, "codec_data") > > My question is. Where does “codec_data” field is defined? I mean, I looked > for it in all my code and I didn’t find it. The field comes from the demuxer, and it's any kind of data that the codec might need outside of the normal stream. For example in the case of H.264 it would be the SPS and PPS when the bytestream mode is not used. -- Felipe Contreras |
|
From: Maldonado Z. I. <iva...@ti...> - 2010-05-19 15:22:19
|
Hi all, I have a few days working on gstreamer and I have a doubt. I'm checking a defect in a decoder. In my code there is a function that looks for a "codec_data" field: gst_structure_has_field (structure, "codec_data") My question is. Where does "codec_data" field is defined? I mean, I looked for it in all my code and I didn't find it. Regards and thanks in advanced Maldonado Zambrano, Ivan x01...@ti...<mailto:x01...@ti...> Project L25x. |
|
From: Stefan K. <en...@ho...> - 2010-04-26 14:47:28
|
Felipe Contreras wrote:
> On Sat, Apr 24, 2010 at 11:31 PM, Stefan Kost <en...@ho...> wrote:
>
>> I agree that gst_element_class_set_details_simple() does not bring a
>> huge speedup normally, but then there is no point in wasting cycles. It
>> definitely shortes a fully registry rescann, which e.g. happens when you install
>> a new plugin (e.g. on demand). And as usual several small gains (or wastes) add up.
>> Anyway do as you prefer, I said what I have to say on this matter.
>>
>
> If you really want to save cycles, try this:
>
> static inline void
> __gst_element_details_copy(GstElementDetails *dest,
> const GstElementDetails *src)
> {
> g_free(dest->longname);
> g_free(dest->klass);
> g_free(dest->description);
> g_free(dest->author);
> dest->longname = g_strdup(src->longname);
> dest->klass = g_strdup(src->klass);
> dest->description = g_strdup(src->description);
> dest->author = g_strdup(src->author);
> }
>
Yes, the stupid validate is something that should be tuned off for a
release.
Stefan
> That's saving *way* many more cycles.
>
> Or even better, make gst_element_class_set_details() inline, then the
> compiler can find the most optimal path. I did tests, and the
> resulting assembly is the same for gst_element_class_set_details(),
> and gst_element_class_set_details_simple() with -O2 (when the
> functions are inline).
>
>
|
|
From: Felipe C. <fel...@gm...> - 2010-04-25 12:06:51
|
On Mon, Apr 19, 2010 at 10:05 AM, Felipe Contreras <fel...@gm...> wrote: > 2010/4/19 Rob Clark <ro...@ti...>: >> gst_element_class_set_details() is now deprecated. Replace with gst_element_class_set_details_simple() instead. > > Agh. I don't see the point of that deprecation, I will contend that. After Benjamin Otte's explanation I guess it doesn't make sense to stick with gst_element_class_set_details(); it would have been nice to make the fields const, but that would be ABI breakage, and there are other reasons why the function was removed. Hopefully there will be a better alternative soon. In the meantime I'll apply this patch. Thanks. -- Felipe Contreras |
|
From: Felipe C. <fel...@gm...> - 2010-04-25 11:44:05
|
On Sat, Apr 24, 2010 at 11:31 PM, Stefan Kost <en...@ho...> wrote:
> I agree that gst_element_class_set_details_simple() does not bring a
> huge speedup normally, but then there is no point in wasting cycles. It
> definitely shortes a fully registry rescann, which e.g. happens when you install
> a new plugin (e.g. on demand). And as usual several small gains (or wastes) add up.
> Anyway do as you prefer, I said what I have to say on this matter.
If you really want to save cycles, try this:
static inline void
__gst_element_details_copy(GstElementDetails *dest,
const GstElementDetails *src)
{
g_free(dest->longname);
g_free(dest->klass);
g_free(dest->description);
g_free(dest->author);
dest->longname = g_strdup(src->longname);
dest->klass = g_strdup(src->klass);
dest->description = g_strdup(src->description);
dest->author = g_strdup(src->author);
}
That's saving *way* many more cycles.
Or even better, make gst_element_class_set_details() inline, then the
compiler can find the most optimal path. I did tests, and the
resulting assembly is the same for gst_element_class_set_details(),
and gst_element_class_set_details_simple() with -O2 (when the
functions are inline).
--
Felipe Contreras
|
|
From: Stefan K. <en...@ho...> - 2010-04-24 20:32:43
|
Am 24.04.2010 12:31, schrieb Felipe Contreras: > On Fri, Apr 23, 2010 at 9:19 PM, Stefan Kost <en...@ho...> wrote: >> Am 23.04.2010 20:05, schrieb Felipe Contreras: >>> Well, so far I don't agree with the change from GStreamer API, so I >>> think removing GST_DISABLE_DEPRECATED is the sensible solution. >> >> Just apply robs patch and its fine. Setting a struct just for passing the >> parameters is not very useful. I will also do the extensible variant sooner or >> later becasue I have a needs for it. > > I _can_ do that, but I also can remove GST_DISABLE_DEPRECATED. Given > that I see no advantage at all of using > gst_element_class_set_details_simple(), I don't see why we should use > it. If a better API is provided at some point, sure, we will switch, > but in the meantime there's no such thing. > Using the disable_deprecated macros simply helps to do gradual porting towards newer api. I agree that gst_element_class_set_details_simple() does not bring a huge speedup normally, but then there is no point in wasting cycles. It definitely shortes a fully registry rescann, which e.g. happens when you install a new plugin (e.g. on demand). And as usual several small gains (or wastes) add up. Anyway do as you prefer, I said what I have to say on this matter. Stefan |
|
From: Felipe C. <fel...@gm...> - 2010-04-24 09:31:09
|
On Fri, Apr 23, 2010 at 9:19 PM, Stefan Kost <en...@ho...> wrote: > Am 23.04.2010 20:05, schrieb Felipe Contreras: >> Well, so far I don't agree with the change from GStreamer API, so I >> think removing GST_DISABLE_DEPRECATED is the sensible solution. > > Just apply robs patch and its fine. Setting a struct just for passing the > parameters is not very useful. I will also do the extensible variant sooner or > later becasue I have a needs for it. I _can_ do that, but I also can remove GST_DISABLE_DEPRECATED. Given that I see no advantage at all of using gst_element_class_set_details_simple(), I don't see why we should use it. If a better API is provided at some point, sure, we will switch, but in the meantime there's no such thing. -- Felipe Contreras |
|
From: Felipe C. <fel...@gm...> - 2010-04-24 09:23:16
|
On Fri, Apr 23, 2010 at 8:30 PM, Rob Clark <ro...@ti...> wrote: > On 04/23/2010 12:05 PM, Felipe Contreras wrote: >> Well, so far I don't agree with the change from GStreamer API, so I >> think removing GST_DISABLE_DEPRECATED is the sensible solution. > > well, internally this was what we did for a short term temporary solution.. > but I'm not a huge fan of removing all deprecated API checking just for the > benefit of one API. So far I haven't got anything positive from checking for deprecated API, so I don't see the point of continuing doing that. > Unfortunately, I don't see a good way to rescue the > gst_element_class_set_details() API without changing the GstElementDetails > struct to use const pointers. (Although offhand I'm not sure why that > approach wasn't taken.) I think that should have been marked as todo for 0.11, and if gst_element_class_set_info() gets implemented, great. -- Felipe Contreras |
|
From: Stefan K. <en...@ho...> - 2010-04-23 18:19:59
|
Am 23.04.2010 20:05, schrieb Felipe Contreras:
> On Mon, Apr 19, 2010 at 10:32 AM, Rob Clark <ro...@ti...> wrote:
>> On 04/19/2010 02:23 AM, Felipe Contreras wrote:
>>> Yeah, but that's code-style patronizing. So what if I prefer a C99 style
>>> like:
>>>
>>> GstElementDetails details = {
>>> .longname = "OpenMAX IL AAC audio decoder",
>>> .klass = "Codec/Decoder/Audio",
>>> .description = "Decodes audio in AAC format with OpenMAX IL",
>>> .author = "Felipe Contreras",
>>> };
>>>
>>> gst_element_class_set_details(element_class,&details);
>>>
>>> At some point that won't work? Why?
>>
>> IIRC it was some brokenness of GstElementDetails which showed when
>> -Wwrite-strings (or similar) was enabled.. because the fields in that struct
>> were not const. I think the only wait to fix that would be have some new
>> GstElementDetailsConst struct, which isn't any better..
>>
>> honestly, I don't have a preference either way.. the only reason I changed
>> this was I didn't want to have to remove GST_DISABLE_DEPRECATED
>
> Well, so far I don't agree with the change from GStreamer API, so I
> think removing GST_DISABLE_DEPRECATED is the sensible solution.
>
Just apply robs patch and its fine. Setting a struct just for passing the
parameters is not very useful. I will also do the extensible variant sooner or
later becasue I have a needs for it.
Stefan
|
|
From: Rob C. <ro...@ti...> - 2010-04-23 17:30:27
|
On 04/23/2010 12:05 PM, Felipe Contreras wrote:
> On Mon, Apr 19, 2010 at 10:32 AM, Rob Clark<ro...@ti...> wrote:
>
>> On 04/19/2010 02:23 AM, Felipe Contreras wrote:
>>
>>> Yeah, but that's code-style patronizing. So what if I prefer a C99 style
>>> like:
>>>
>>> GstElementDetails details = {
>>> .longname = "OpenMAX IL AAC audio decoder",
>>> .klass = "Codec/Decoder/Audio",
>>> .description = "Decodes audio in AAC format with OpenMAX IL",
>>> .author = "Felipe Contreras",
>>> };
>>>
>>> gst_element_class_set_details(element_class,&details);
>>>
>>> At some point that won't work? Why?
>>>
>> IIRC it was some brokenness of GstElementDetails which showed when
>> -Wwrite-strings (or similar) was enabled.. because the fields in that struct
>> were not const. I think the only wait to fix that would be have some new
>> GstElementDetailsConst struct, which isn't any better..
>>
>> honestly, I don't have a preference either way.. the only reason I changed
>> this was I didn't want to have to remove GST_DISABLE_DEPRECATED
>>
> Well, so far I don't agree with the change from GStreamer API, so I
> think removing GST_DISABLE_DEPRECATED is the sensible solution.
>
>
well, internally this was what we did for a short term temporary
solution.. but I'm not a huge fan of removing all deprecated API
checking just for the benefit of one API.
Unfortunately, I don't see a good way to rescue the
gst_element_class_set_details() API without changing the
GstElementDetails struct to use const pointers. (Although offhand I'm
not sure why that approach wasn't taken.)
BR,
-R
|
|
From: Felipe C. <fel...@gm...> - 2010-04-23 17:05:43
|
On Mon, Apr 19, 2010 at 10:32 AM, Rob Clark <ro...@ti...> wrote:
> On 04/19/2010 02:23 AM, Felipe Contreras wrote:
>> Yeah, but that's code-style patronizing. So what if I prefer a C99 style
>> like:
>>
>> GstElementDetails details = {
>> .longname = "OpenMAX IL AAC audio decoder",
>> .klass = "Codec/Decoder/Audio",
>> .description = "Decodes audio in AAC format with OpenMAX IL",
>> .author = "Felipe Contreras",
>> };
>>
>> gst_element_class_set_details(element_class,&details);
>>
>> At some point that won't work? Why?
>
> IIRC it was some brokenness of GstElementDetails which showed when
> -Wwrite-strings (or similar) was enabled.. because the fields in that struct
> were not const. I think the only wait to fix that would be have some new
> GstElementDetailsConst struct, which isn't any better..
>
> honestly, I don't have a preference either way.. the only reason I changed
> this was I didn't want to have to remove GST_DISABLE_DEPRECATED
Well, so far I don't agree with the change from GStreamer API, so I
think removing GST_DISABLE_DEPRECATED is the sensible solution.
--
Felipe Contreras
|
|
From: Felipe C. <fel...@gm...> - 2010-04-23 10:13:47
|
On Mon, Apr 19, 2010 at 10:28 AM, Stefan Kost <en...@ho...> wrote: > Felipe Contreras wrote: >> At some point that won't work? Why? > > It is causing a extra reloc and pointer copying. Yeah, but only when the plugin is registered... so it's only a few extra cycles once in a while, isn't it? > What I would like to > see instead is to use GstStructure for plugin and element details. Then > we would have: > > gst_element_class_set_info(element_class,...) > > this could be either a varargs function that takes the args and/or one that takes the structure. Right now using a non extensible intermediate structure is not so useful. Indeed, it's not, but I fail to see how removing gst_element_class_set_details() improves the situation at all. -- Felipe Contreras |
3 messages has been excluded from this view by a project administrator.
