Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
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
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
|
2
(3) |
3
(1) |
4
|
5
|
6
|
7
|
|
8
|
9
|
10
|
11
|
12
|
13
|
14
|
|
15
|
16
|
17
|
18
|
19
(1) |
20
(6) |
21
(3) |
|
22
|
23
(1) |
24
(9) |
25
(1) |
26
(2) |
27
(4) |
28
|
|
29
|
30
(1) |
31
(2) |
|
|
|
|
|
From: Prajnashi S <prajnashi@gm...> - 2009-03-31 06:32:50
|
Hi, On Fri, Mar 27, 2009 at 5:53 PM, Felipe Contreras < felipe.contreras@...> wrote: > On Fri, Mar 27, 2009 at 10:12 AM, Prajnashi S <prajnashi@...> wrote: > > > > > > On Fri, Mar 27, 2009 at 5:43 AM, Felipe Contreras > > <felipe.contreras@...> wrote: > >> > >> Hi, > >> > >> I've taken your patch and I've put it in a new branch in github. I > >> took a quick look and it seems it will require quite a bit of effort > >> before this can be merged, bit doesn't look bad :) > >> > >> First I want to start minimizing the changes and I already started > >> with the aacdec, can you take a look and see if you can do the same > >> for the other components? > > > > OK, but I can do it after completing video flinger sink and java glue > code. > > > >> > >> > >> A few comments: > >> > >> Remove BUILD_WITH_ANDROID, for now this branch should be only for > >> Android. Once it's clean we can start merging the stuff that can be > >> shared by all the omx implementations and then rebase on top of the > >> latest master. > > > > OK, actually, most of them is not android specific, they shall be moved > > outside BUILD_WITH_ANDROID. But, we need analyze them case by case, > because > > I'm not sure if PV OpenMax follow spec strictly. > > I mean if PV needs something different, then just do the change, don't > put it inside #if BUILD_WITH_ANDROID. That way it's easier to review. > > Also, PV is opensource, right? If we find something that is against > the spec we can send them patches. However, some stuff can go into the > master branch (no #if BUILD_WITH_ANDROID) as it would not affect other > implementations. > Agree. > > Cheers. > > -- > Felipe Contreras > -- -- Prajnashi S |
|
From: Prajnashi S <prajnashi@gm...> - 2009-03-31 06:31:58
|
I used the Edward's repo now. On Tue, Mar 31, 2009 at 4:11 AM, Felipe Contreras < felipe.contreras@...> wrote: > On Fri, Mar 27, 2009 at 11:12 AM, Prajnashi S <prajnashi@...> wrote: > > > > > > On Fri, Mar 27, 2009 at 5:43 AM, Felipe Contreras > > <felipe.contreras@...> wrote: > >> > >> Hi, > >> > >> I've taken your patch and I've put it in a new branch in github. I > >> took a quick look and it seems it will require quite a bit of effort > >> before this can be merged, bit doesn't look bad :) > >> > >> First I want to start minimizing the changes and I already started > >> with the aacdec, can you take a look and see if you can do the same > >> for the other components? > > > > OK, but I can do it after completing video flinger sink and java glue > code. > > > >> > >> > >> A few comments: > >> > >> Remove BUILD_WITH_ANDROID, for now this branch should be only for > >> Android. Once it's clean we can start merging the stuff that can be > >> shared by all the omx implementations and then rebase on top of the > >> latest master. > > > > OK, actually, most of them is not android specific, they shall be moved > > outside BUILD_WITH_ANDROID. But, we need analyze them case by case, > because > > I'm not sure if PV OpenMax follow spec strictly. > > > >> > >> Can we remove the extra debugging stuff like "Enter" and "Leave"? Once > >> the android branch is merged we can think on adding them back. > >> > >> Also, is it possible for you to use the branch I just setup? Or a fork > >> of it? That way we can verify that there are no regressions in the > >> process. > >> > >> http://github.com/felipec/gst-openmax/commits/android > > > > Of cause, I can use your branch. > > In which git repo are you working on right now? > > -- > Felipe Contreras > -- -- Prajnashi S |
|
From: Felipe Contreras <felipe.contreras@gm...> - 2009-03-30 20:12:00
|
On Fri, Mar 27, 2009 at 11:12 AM, Prajnashi S <prajnashi@...> wrote: > > > On Fri, Mar 27, 2009 at 5:43 AM, Felipe Contreras > <felipe.contreras@...> wrote: >> >> Hi, >> >> I've taken your patch and I've put it in a new branch in github. I >> took a quick look and it seems it will require quite a bit of effort >> before this can be merged, bit doesn't look bad :) >> >> First I want to start minimizing the changes and I already started >> with the aacdec, can you take a look and see if you can do the same >> for the other components? > > OK, but I can do it after completing video flinger sink and java glue code. > >> >> >> A few comments: >> >> Remove BUILD_WITH_ANDROID, for now this branch should be only for >> Android. Once it's clean we can start merging the stuff that can be >> shared by all the omx implementations and then rebase on top of the >> latest master. > > OK, actually, most of them is not android specific, they shall be moved > outside BUILD_WITH_ANDROID. But, we need analyze them case by case, because > I'm not sure if PV OpenMax follow spec strictly. > >> >> Can we remove the extra debugging stuff like "Enter" and "Leave"? Once >> the android branch is merged we can think on adding them back. >> >> Also, is it possible for you to use the branch I just setup? Or a fork >> of it? That way we can verify that there are no regressions in the >> process. >> >> http://github.com/felipec/gst-openmax/commits/android > > Of cause, I can use your branch. In which git repo are you working on right now? -- Felipe Contreras |
|
From: Felipe Contreras <felipe.contreras@gm...> - 2009-03-27 09:58:05
|
2009/3/27 René Stadler <mail@...>:
>
> Signed-off-by: René Stadler <mail@...>
> ---
> omx/gstomx_base_filter.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/omx/gstomx_base_filter.c b/omx/gstomx_base_filter.c
> index 3679916..2da5eff 100644
> --- a/omx/gstomx_base_filter.c
> +++ b/omx/gstomx_base_filter.c
> @@ -540,7 +540,10 @@ pad_chain (GstPad *pad,
> setup_ports (self);
>
> if (!g_omx_core_prepare (self->gomx))
> + {
> + g_mutex_unlock (self->ready_lock);
> goto fail_omx_state;
> + }
>
> self->ready = TRUE;
> gst_pad_start_task (self->srcpad, output_loop, self->srcpad);
> --
> 1.5.6.3
Acked. Thanks :)
--
Felipe Contreras
|
|
From: Felipe Contreras <felipe.contreras@gm...> - 2009-03-27 09:53:44
|
On Fri, Mar 27, 2009 at 10:12 AM, Prajnashi S <prajnashi@...> wrote: > > > On Fri, Mar 27, 2009 at 5:43 AM, Felipe Contreras > <felipe.contreras@...> wrote: >> >> Hi, >> >> I've taken your patch and I've put it in a new branch in github. I >> took a quick look and it seems it will require quite a bit of effort >> before this can be merged, bit doesn't look bad :) >> >> First I want to start minimizing the changes and I already started >> with the aacdec, can you take a look and see if you can do the same >> for the other components? > > OK, but I can do it after completing video flinger sink and java glue code. > >> >> >> A few comments: >> >> Remove BUILD_WITH_ANDROID, for now this branch should be only for >> Android. Once it's clean we can start merging the stuff that can be >> shared by all the omx implementations and then rebase on top of the >> latest master. > > OK, actually, most of them is not android specific, they shall be moved > outside BUILD_WITH_ANDROID. But, we need analyze them case by case, because > I'm not sure if PV OpenMax follow spec strictly. I mean if PV needs something different, then just do the change, don't put it inside #if BUILD_WITH_ANDROID. That way it's easier to review. Also, PV is opensource, right? If we find something that is against the spec we can send them patches. However, some stuff can go into the master branch (no #if BUILD_WITH_ANDROID) as it would not affect other implementations. Cheers. -- Felipe Contreras |
|
From: Prajnashi S <prajnashi@gm...> - 2009-03-27 08:13:01
|
On Fri, Mar 27, 2009 at 5:43 AM, Felipe Contreras < felipe.contreras@...> wrote: > Hi, > > I've taken your patch and I've put it in a new branch in github. I > took a quick look and it seems it will require quite a bit of effort > before this can be merged, bit doesn't look bad :) > > First I want to start minimizing the changes and I already started > with the aacdec, can you take a look and see if you can do the same > for the other components? OK, but I can do it after completing video flinger sink and java glue code. > > > A few comments: > > Remove BUILD_WITH_ANDROID, for now this branch should be only for > Android. Once it's clean we can start merging the stuff that can be > shared by all the omx implementations and then rebase on top of the > latest master. OK, actually, most of them is not android specific, they shall be moved outside BUILD_WITH_ANDROID. But, we need analyze them case by case, because I'm not sure if PV OpenMax follow spec strictly. > > > Can we remove the extra debugging stuff like "Enter" and "Leave"? Once > the android branch is merged we can think on adding them back. > > Also, is it possible for you to use the branch I just setup? Or a fork > of it? That way we can verify that there are no regressions in the > process. > > http://github.com/felipec/gst-openmax/commits/android > Of cause, I can use your branch. > > Cheers. > > On Thu, Mar 26, 2009 at 5:26 PM, Prajnashi S <prajnashi@...> wrote: > > > > > > ---------- Forwarded message ---------- > > From: Prajnashi <prajnashi@...> > > Date: Thu, Mar 26, 2009 at 11:22 PM > > Subject: View this page "Port all packages step by step" > > To: prajnashi <prajnashi@...> > > > > > > > > Update pages to make gst-openmax support amrnb, amrwb, h263, h264, > > mpeg4. You can use following command to test. > > > > Play a amrwb 3gp file > > > > # ./gst-launch-0.10 filesrc location=wb.3gp ! qtdemux ! queue ! > > omx_amrwbdec ! audioflingersink > > > > > > Play a mp4 video file: > > > > # ./gst-launch-0.10 filesrc location=1.mp4 ! qtdemux ! queue ! > > omx_mpeg4dec ! ffmpegcolorspace ! fbdevsink > > > > > > > > Play a h264 video file: > > > > # ./gst-launch-0.10 filesrc location=264.mp4 ! qtdemux ! queue ! > > omx_h264dec ! ffmpegcolorspace ! fbdevsink > > > > > > Play a h263 video file: > > > > # ./gst-launch-0.10 filesrc location=263.mp4 ! qtdemux ! queue ! > > omx_h263dec ! ffmpegcolorspace ! fbdevsink > > > > > > Play a mp4 + aac file: > > > > # ./gst-launch-0.10 filesrc location=av.mp4 ! qtdemux name=demux > > demux. ! omx_aacdec ! audioflingersink demux. ! omx_mpeg4dec ! > > ffmpegcolorspace ! fbdevsink > > > > > > Play a h263 + amrnb file: > > > > # ./gst-launch-0.10 filesrc location=av.3gp ! qtdemux name=demux > > demux. ! omx_amrnbdec ! audioflingersink demux. ! omx_h263dec ! > > ffmpegcolorspace ! fbdevsink > > > > > > Click on > > > http://groups.google.com/group/prajnashi/web/port-all-packages-step-by-step > > - or copy & paste it into your browser's address bar if that doesn't > > work. > > --~--~---------~--~----~------------~-------~--~----~ > > You received this message because you are subscribed to the Google Groups > > "prajnashi" group. > > To post to this group, send email to prajnashi@... > > To unsubscribe from this group, send email to > > prajnashi+unsubscribe@...<prajnashi%2Bunsubscribe@...> > > For more options, visit this group at > > http://groups.google.com/group/prajnashi?hl=en > > -~----------~----~----~----~------~----~------~--~--- > > > > > > > > > > -- > > -- Prajnashi S > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > Gstreamer-openmax mailing list > > Gstreamer-openmax@... > > https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax > > > > > > > > -- > Felipe Contreras > -- -- Prajnashi S |
|
From: René Stadler <mail@re...> - 2009-03-27 00:14:28
|
Signed-off-by: René Stadler <mail@...>
---
omx/gstomx_base_filter.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/omx/gstomx_base_filter.c b/omx/gstomx_base_filter.c
index 3679916..2da5eff 100644
--- a/omx/gstomx_base_filter.c
+++ b/omx/gstomx_base_filter.c
@@ -540,7 +540,10 @@ pad_chain (GstPad *pad,
setup_ports (self);
if (!g_omx_core_prepare (self->gomx))
+ {
+ g_mutex_unlock (self->ready_lock);
goto fail_omx_state;
+ }
self->ready = TRUE;
gst_pad_start_task (self->srcpad, output_loop, self->srcpad);
--
1.5.6.3
|
|
From: Felipe Contreras <felipe.contreras@gm...> - 2009-03-26 21:43:19
|
Hi, I've taken your patch and I've put it in a new branch in github. I took a quick look and it seems it will require quite a bit of effort before this can be merged, bit doesn't look bad :) First I want to start minimizing the changes and I already started with the aacdec, can you take a look and see if you can do the same for the other components? A few comments: Remove BUILD_WITH_ANDROID, for now this branch should be only for Android. Once it's clean we can start merging the stuff that can be shared by all the omx implementations and then rebase on top of the latest master. Can we remove the extra debugging stuff like "Enter" and "Leave"? Once the android branch is merged we can think on adding them back. Also, is it possible for you to use the branch I just setup? Or a fork of it? That way we can verify that there are no regressions in the process. http://github.com/felipec/gst-openmax/commits/android Cheers. On Thu, Mar 26, 2009 at 5:26 PM, Prajnashi S <prajnashi@...> wrote: > > > ---------- Forwarded message ---------- > From: Prajnashi <prajnashi@...> > Date: Thu, Mar 26, 2009 at 11:22 PM > Subject: View this page "Port all packages step by step" > To: prajnashi <prajnashi@...> > > > > Update pages to make gst-openmax support amrnb, amrwb, h263, h264, > mpeg4. You can use following command to test. > > Play a amrwb 3gp file > > # ./gst-launch-0.10 filesrc location=wb.3gp ! qtdemux ! queue ! > omx_amrwbdec ! audioflingersink > > > Play a mp4 video file: > > # ./gst-launch-0.10 filesrc location=1.mp4 ! qtdemux ! queue ! > omx_mpeg4dec ! ffmpegcolorspace ! fbdevsink > > > > Play a h264 video file: > > # ./gst-launch-0.10 filesrc location=264.mp4 ! qtdemux ! queue ! > omx_h264dec ! ffmpegcolorspace ! fbdevsink > > > Play a h263 video file: > > # ./gst-launch-0.10 filesrc location=263.mp4 ! qtdemux ! queue ! > omx_h263dec ! ffmpegcolorspace ! fbdevsink > > > Play a mp4 + aac file: > > # ./gst-launch-0.10 filesrc location=av.mp4 ! qtdemux name=demux > demux. ! omx_aacdec ! audioflingersink demux. ! omx_mpeg4dec ! > ffmpegcolorspace ! fbdevsink > > > Play a h263 + amrnb file: > > # ./gst-launch-0.10 filesrc location=av.3gp ! qtdemux name=demux > demux. ! omx_amrnbdec ! audioflingersink demux. ! omx_h263dec ! > ffmpegcolorspace ! fbdevsink > > > Click on > http://groups.google.com/group/prajnashi/web/port-all-packages-step-by-step > - or copy & paste it into your browser's address bar if that doesn't > work. > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups > "prajnashi" group. > To post to this group, send email to prajnashi@... > To unsubscribe from this group, send email to > prajnashi+unsubscribe@... > For more options, visit this group at > http://groups.google.com/group/prajnashi?hl=en > -~----------~----~----~----~------~----~------~--~--- > > > > > -- > -- Prajnashi S > > ------------------------------------------------------------------------------ > > _______________________________________________ > Gstreamer-openmax mailing list > Gstreamer-openmax@... > https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax > > -- Felipe Contreras |
|
From: Prajnashi S <prajnashi@gm...> - 2009-03-26 15:27:03
|
---------- Forwarded message ---------- From: Prajnashi <prajnashi@...> Date: Thu, Mar 26, 2009 at 11:22 PM Subject: View this page "Port all packages step by step" To: prajnashi <prajnashi@...> Update pages to make gst-openmax support amrnb, amrwb, h263, h264, mpeg4. You can use following command to test. Play a amrwb 3gp file # ./gst-launch-0.10 filesrc location=wb.3gp ! qtdemux ! queue ! omx_amrwbdec ! audioflingersink Play a mp4 video file: # ./gst-launch-0.10 filesrc location=1.mp4 ! qtdemux ! queue ! omx_mpeg4dec ! ffmpegcolorspace ! fbdevsink Play a h264 video file: # ./gst-launch-0.10 filesrc location=264.mp4 ! qtdemux ! queue ! omx_h264dec ! ffmpegcolorspace ! fbdevsink Play a h263 video file: # ./gst-launch-0.10 filesrc location=263.mp4 ! qtdemux ! queue ! omx_h263dec ! ffmpegcolorspace ! fbdevsink Play a mp4 + aac file: # ./gst-launch-0.10 filesrc location=av.mp4 ! qtdemux name=demux demux. ! omx_aacdec ! audioflingersink demux. ! omx_mpeg4dec ! ffmpegcolorspace ! fbdevsink Play a h263 + amrnb file: # ./gst-launch-0.10 filesrc location=av.3gp ! qtdemux name=demux demux. ! omx_amrnbdec ! audioflingersink demux. ! omx_h263dec ! ffmpegcolorspace ! fbdevsink Click on http://groups.google.com/group/prajnashi/web/port-all-packages-step-by-step - or copy & paste it into your browser's address bar if that doesn't work. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "prajnashi" group. To post to this group, send email to prajnashi@... To unsubscribe from this group, send email to prajnashi+unsubscribe@...<prajnashi%2Bunsubscribe@...> For more options, visit this group at http://groups.google.com/group/prajnashi?hl=en -~----------~----~----~----~------~----~------~--~--- -- -- Prajnashi S |
|
From: Felipe Contreras <felipe.contreras@gm...> - 2009-03-25 23:39:44
|
FYI, This one has DSP binaries that actually work :) I tested with latest gst-openmax. ---------- Forwarded message ---------- From: Daniel Díaz <mrchapp@...> Date: Thu, Mar 26, 2009 at 1:01 AM Subject: [openmax-devel] [RELEASE] tiopenmax 0.3.5 now available! To: openmax-devel@... Hello! Please find tiopenmax 0.3.5 in the following location: https://omapzoom.org/gf/project/openmax/frs/ This is the same OpenMAX IL code as last time (tiopenmax 0.3), only the DSP binaries have been updated. Greetings! Daniel Díaz ddiaz@... _______________________________________________ Openmax-devel mailing list Openmax-devel@... https://omapzoom.org/mailman/listinfo/openmax-devel -- Felipe Contreras |
|
From: Felipe Contreras <felipe.contreras@gm...> - 2009-03-24 22:00:14
|
Sometimes pad_link is called after switching the state; we need to have omx
initialized always.
Based on the tunneling patch series by Frederik Vermelen (NXP), whom
also gave feedback to this patch.
Signed-off-by: Felipe Contreras <felipe.contreras@...>
---
omx/gstomx_base_sink.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/omx/gstomx_base_sink.c b/omx/gstomx_base_sink.c
index f2b3d0a..fd42159 100644
--- a/omx/gstomx_base_sink.c
+++ b/omx/gstomx_base_sink.c
@@ -31,6 +31,8 @@
static gboolean share_input_buffer;
+static inline gboolean omx_init (GstOmxBaseSink *self);
+
enum
{
ARG_0,
@@ -81,6 +83,14 @@ change_state (GstElement *element,
switch (transition)
{
case GST_STATE_CHANGE_NULL_TO_READY:
+ if (!self->initialized)
+ {
+ if (!omx_init (self))
+ return GST_PAD_LINK_REFUSED;
+
+ self->initialized = TRUE;
+ }
+
g_omx_core_prepare (self->gomx);
break;
--
1.6.2.1.316.gedbc2
|
|
From: Felipe Contreras <felipe.contreras@gm...> - 2009-03-24 22:00:00
|
Based on the tunneling patch series by Frederik Vermelen (NXP), whom
also gave feedback to this patch.
Signed-off-by: Felipe Contreras <felipe.contreras@...>
---
omx/gstomx_base_sink.c | 94 +++++++++++++++++++++--------------------------
omx/gstomx_base_sink.h | 1 -
2 files changed, 42 insertions(+), 53 deletions(-)
diff --git a/omx/gstomx_base_sink.c b/omx/gstomx_base_sink.c
index 2e29312..f2b3d0a 100644
--- a/omx/gstomx_base_sink.c
+++ b/omx/gstomx_base_sink.c
@@ -78,31 +78,47 @@ change_state (GstElement *element,
gst_element_state_get_name (GST_STATE_TRANSITION_CURRENT (transition)),
gst_element_state_get_name (GST_STATE_TRANSITION_NEXT (transition)));
- ret = GST_ELEMENT_CLASS (parent_class)->change_state (element, transition);
+ switch (transition)
+ {
+ case GST_STATE_CHANGE_NULL_TO_READY:
+ g_omx_core_prepare (self->gomx);
+ break;
- GST_LOG_OBJECT (self, "end");
+ case GST_STATE_CHANGE_READY_TO_PAUSED:
+ g_omx_core_start (self->gomx);
+ break;
- return ret;
-}
+ case GST_STATE_CHANGE_PAUSED_TO_READY:
+ g_omx_port_finish (self->in_port);
+ break;
-static gboolean
-stop (GstBaseSink *gst_base)
-{
- GstOmxBaseSink *self;
+ default:
+ break;
+ }
- self = GST_OMX_BASE_SINK (gst_base);
+ ret = GST_ELEMENT_CLASS (parent_class)->change_state (element, transition);
- GST_LOG_OBJECT (self, "begin");
+ if (ret == GST_STATE_CHANGE_FAILURE)
+ goto leave;
- g_omx_core_finish (self->gomx);
+ switch (transition)
+ {
+ case GST_STATE_CHANGE_PLAYING_TO_PAUSED:
+ g_omx_port_pause (self->in_port);
+ break;
- g_omx_core_deinit (self->gomx);
- if (self->gomx->omx_error)
- return GST_STATE_CHANGE_FAILURE;
+ case GST_STATE_CHANGE_PAUSED_TO_READY:
+ g_omx_core_finish (self->gomx);
+ break;
+ default:
+ break;
+ }
+
+leave:
GST_LOG_OBJECT (self, "end");
- return TRUE;
+ return ret;
}
static void
@@ -138,33 +154,12 @@ render (GstBaseSink *gst_base,
GST_LOG_OBJECT (self, "state: %d", gomx->omx_state);
- if (G_UNLIKELY (gomx->omx_state == OMX_StateLoaded))
- {
- GST_INFO_OBJECT (self, "omx: prepare");
-
- setup_ports (self);
- g_omx_core_prepare (self->gomx);
-
- self->ready = TRUE;
- }
-
in_port = self->in_port;
if (G_LIKELY (in_port->enabled))
{
guint buffer_offset = 0;
- if (G_UNLIKELY (gomx->omx_state == OMX_StateIdle))
- {
- GST_INFO_OBJECT (self, "omx: play");
- g_omx_core_start (gomx);
- }
-
- if (G_UNLIKELY (gomx->omx_state != OMX_StateExecuting))
- {
- GST_ERROR_OBJECT (self, "Whoa! very wrong");
- }
-
while (G_LIKELY (buffer_offset < GST_BUFFER_SIZE (buf)))
{
OMX_BUFFERHEADERTYPE *omx_buffer;
@@ -347,7 +342,6 @@ type_class_init (gpointer g_class,
gstelement_class->change_state = change_state;
- gst_base_sink_class->stop = stop;
gst_base_sink_class->event = handle_event;
gst_base_sink_class->preroll = render;
gst_base_sink_class->render = render;
@@ -382,31 +376,25 @@ activate_push (GstPad *pad,
{
GST_DEBUG_OBJECT (self, "activate");
- if (self->ready)
+ /* we do not start the task yet if the pad is not connected */
+ if (gst_pad_is_linked (pad))
{
- /* we do not start the task yet if the pad is not connected */
- if (gst_pad_is_linked (pad))
- {
- /** @todo link callback function also needed */
- g_omx_port_resume (self->in_port);
- }
+ /** @todo link callback function also needed */
+ g_omx_port_resume (self->in_port);
}
}
else
{
GST_DEBUG_OBJECT (self, "deactivate");
- if (self->ready)
- {
- /** @todo disable this until we properly reinitialize the buffers. */
+ /** @todo disable this until we properly reinitialize the buffers. */
#if 0
- /* flush all buffers */
- OMX_SendCommand (self->gomx->omx_handle, OMX_CommandFlush, OMX_ALL, NULL);
+ /* flush all buffers */
+ OMX_SendCommand (self->gomx->omx_handle, OMX_CommandFlush, OMX_ALL, NULL);
#endif
- /* unlock loops */
- g_omx_port_pause (self->in_port);
- }
+ /* unlock loops */
+ g_omx_port_pause (self->in_port);
}
gst_object_unref (self);
@@ -422,6 +410,8 @@ omx_init (GstOmxBaseSink *self)
if (self->gomx->omx_error)
return FALSE;
+ setup_ports (self);
+
return TRUE;
}
diff --git a/omx/gstomx_base_sink.h b/omx/gstomx_base_sink.h
index 1356cf7..564f380 100644
--- a/omx/gstomx_base_sink.h
+++ b/omx/gstomx_base_sink.h
@@ -49,7 +49,6 @@ struct GstOmxBaseSink
char *omx_component;
char *omx_library;
- gboolean ready;
gboolean initialized;
};
--
1.6.2.1.316.gedbc2
|
|
From: Felipe Contreras <felipe.contreras@gm...> - 2009-03-24 21:59:48
|
Based on the tunneling patch series by Frederik Vermelen (NXP), whom
also gave feedback to this patch.
Signed-off-by: Felipe Contreras <felipe.contreras@...>
---
omx/gstomx_base_sink.c | 54 +++++++++++++++++++++++++++++++----------------
omx/gstomx_base_sink.h | 1 +
2 files changed, 36 insertions(+), 19 deletions(-)
diff --git a/omx/gstomx_base_sink.c b/omx/gstomx_base_sink.c
index 8ab055c..0f22f14 100644
--- a/omx/gstomx_base_sink.c
+++ b/omx/gstomx_base_sink.c
@@ -64,24 +64,6 @@ setup_ports (GstOmxBaseSink *self)
}
static gboolean
-start (GstBaseSink *gst_base)
-{
- GstOmxBaseSink *self;
-
- self = GST_OMX_BASE_SINK (gst_base);
-
- GST_LOG_OBJECT (self, "begin");
-
- g_omx_core_init (self->gomx, self->omx_library, self->omx_component);
- if (self->gomx->omx_error)
- return GST_STATE_CHANGE_FAILURE;
-
- GST_LOG_OBJECT (self, "end");
-
- return TRUE;
-}
-
-static gboolean
stop (GstBaseSink *gst_base)
{
GstOmxBaseSink *self;
@@ -341,7 +323,6 @@ type_class_init (gpointer g_class,
gobject_class->dispose = dispose;
- gst_base_sink_class->start = start;
gst_base_sink_class->stop = stop;
gst_base_sink_class->event = handle_event;
gst_base_sink_class->preroll = render;
@@ -409,6 +390,40 @@ activate_push (GstPad *pad,
return result;
}
+static inline gboolean
+omx_init (GstOmxBaseSink *self)
+{
+ g_omx_core_init (self->gomx, self->omx_library, self->omx_component);
+
+ if (self->gomx->omx_error)
+ return FALSE;
+
+ return TRUE;
+}
+
+static GstPadLinkReturn
+pad_sink_link (GstPad *pad,
+ GstPad *peer)
+{
+ GOmxCore *gomx;
+ GstOmxBaseSink *self;
+
+ self = GST_OMX_BASE_SINK (GST_OBJECT_PARENT (pad));
+
+ GST_INFO_OBJECT (self, "link");
+
+ gomx = self->gomx;
+
+ if (!self->initialized)
+ {
+ if (!omx_init (self))
+ return GST_PAD_LINK_REFUSED;
+ self->initialized = TRUE;
+ }
+
+ return GST_PAD_LINK_OK;
+}
+
static void
type_instance_init (GTypeInstance *instance,
gpointer g_class)
@@ -435,6 +450,7 @@ type_instance_init (GTypeInstance *instance,
GstPad *sinkpad;
self->sinkpad = sinkpad = GST_BASE_SINK_PAD (self);
gst_pad_set_activatepush_function (sinkpad, activate_push);
+ gst_pad_set_link_function (sinkpad, pad_sink_link);
}
GST_LOG_OBJECT (self, "end");
diff --git a/omx/gstomx_base_sink.h b/omx/gstomx_base_sink.h
index 2ac371d..1356cf7 100644
--- a/omx/gstomx_base_sink.h
+++ b/omx/gstomx_base_sink.h
@@ -50,6 +50,7 @@ struct GstOmxBaseSink
char *omx_library;
gboolean ready;
+ gboolean initialized;
};
struct GstOmxBaseSinkClass
--
1.6.2.1.316.gedbc2
|
|
From: Felipe Contreras <felipe.contreras@gm...> - 2009-03-24 21:59:47
|
Signed-off-by: Felipe Contreras <felipe.contreras@...>
---
omx/gstomx_base_sink.c | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/omx/gstomx_base_sink.c b/omx/gstomx_base_sink.c
index 0f22f14..2e29312 100644
--- a/omx/gstomx_base_sink.c
+++ b/omx/gstomx_base_sink.c
@@ -63,6 +63,28 @@ setup_ports (GstOmxBaseSink *self)
free (param);
}
+static GstStateChangeReturn
+change_state (GstElement *element,
+ GstStateChange transition)
+{
+ GstStateChangeReturn ret = GST_STATE_CHANGE_SUCCESS;
+ GstOmxBaseSink *self;
+
+ self = GST_OMX_BASE_SINK (element);
+
+ GST_LOG_OBJECT (self, "begin");
+
+ GST_INFO_OBJECT (self, "changing state %s - %s",
+ gst_element_state_get_name (GST_STATE_TRANSITION_CURRENT (transition)),
+ gst_element_state_get_name (GST_STATE_TRANSITION_NEXT (transition)));
+
+ ret = GST_ELEMENT_CLASS (parent_class)->change_state (element, transition);
+
+ GST_LOG_OBJECT (self, "end");
+
+ return ret;
+}
+
static gboolean
stop (GstBaseSink *gst_base)
{
@@ -323,6 +345,8 @@ type_class_init (gpointer g_class,
gobject_class->dispose = dispose;
+ gstelement_class->change_state = change_state;
+
gst_base_sink_class->stop = stop;
gst_base_sink_class->event = handle_event;
gst_base_sink_class->preroll = render;
--
1.6.2.1.316.gedbc2
|
|
From: Felipe Contreras <felipe.contreras@gm...> - 2009-03-24 21:59:46
|
From: Frederik Vernelen <frederik.vernelen@...> For contributions in the initial implementation of gst-omx state alignment and tunneling. Signed-off-by: Felipe Contreras <felipe.contreras@...> --- omx/gstomx_base_sink.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/omx/gstomx_base_sink.c b/omx/gstomx_base_sink.c index 705b886..8ab055c 100644 --- a/omx/gstomx_base_sink.c +++ b/omx/gstomx_base_sink.c @@ -1,7 +1,10 @@ /* * Copyright (C) 2007-2009 Nokia Corporation. + * Copyright (C) 2008 NXP. * - * Author: Felipe Contreras <felipe.contreras@...> + * Authors: + * Felipe Contreras <felipe.contreras@...> + * Frederik Vernelen <frederik.vernelen@...> * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public -- 1.6.2.1.316.gedbc2 |
|
From: Felipe Contreras <felipe.contreras@gm...> - 2009-03-24 21:59:27
|
This patch series seems to be safe to merge since it doesn't degrade the situation with the base sink, which is pretty bad. Doing some hacks here and there I managed to get some output of the audiosink, so at least this works. Thanks go to Frederik Vernelen for the initial implementation and feedback. This is the first step towards merging the tunneling branch, but I would like some feedback if possible, at least from Frederik. Frederik, can I have you acknoledgement to merge this? Felipe Contreras (4): basesink: move omx initalization to pad link basesink: add empty change_state function basesink: align gst and omx states in base_sink basesink: initalize omx when changing to READY Frederik Vernelen (1): basesink: add NXP copyright omx/gstomx_base_sink.c | 161 ++++++++++++++++++++++++++++++------------------ omx/gstomx_base_sink.h | 2 +- 2 files changed, 103 insertions(+), 60 deletions(-) |
|
From: Felipe Contreras <felipe.contreras@gm...> - 2009-03-24 07:30:02
|
On Tue, Mar 24, 2009 at 3:40 AM, Prajnashi S <prajnashi@...> wrote: > Will the 0.10.0.5 will support tunnel? If yes, do we have any document? In > addition, is there any plan to integrate with specific hardware, which > support OMX, such as TI OMAP, Marvell, and so on? As I said, I don't know if the tunneling branch will be merged for .5, but if not, it will be available as a separate branch, and will be soon merged for .6. The whole idea of OpenMAX IL is to be able to use different implementations transparently. Of course theory != practice. Personally I've tested all the video components on OMAP platform, and a few others on bellagio. I know some people have been able to use gst-openmax on different platforms, but it always seems as if their companies have asked them to keep a low profile. Regarding Marvell, I think one guy told me he could get H.264 decoding working there, but I don't know more. -- Felipe Contreras |
|
From: Prajnashi S <prajnashi@gm...> - 2009-03-24 01:46:11
|
Will the 0.10.0.5 will support tunnel? If yes, do we have any document? In addition, is there any plan to integrate with specific hardware, which support OMX, such as TI OMAP, Marvell, and so on? On Tue, Mar 24, 2009 at 8:12 AM, Felipe Contreras < felipe.contreras@...> wrote: > Hi, > > Many things have changed since the previous release and it's already > very late for the new release, I'm sorry I haven't had time to work on > it. > > I've delayed the release because I wanted to have tunneling support, > but I haven't had time to test it for Maemo. I don't want to delay the > release any more for a number of reasons. > > There has been some work to port gst-openmax to Google Android, and I > think there's already a patch series waiting to be merged. Since > activity has increased so has the pressure from GStreamer developers > to change the code-style to something more pleasant for them and since > gst-openmax is part of the GStreamer project it was only a matter of > time before that happened. > > So the plan is to rebase all the important branches to the latest git > master branch, do a bit of testing and release 0.10.0.5. After that, > the code-style will be updated. That would require rebasing the > tunneling branch, and in the process I might be able to finally merge > it, but maybe not. If I'm not able to merge the tunneling branch for > 0.10.0.5, there will probably be another release soon after that with > tunneling. > > In the meantime I've updated (rewritten?) the wiki page[1] and I've > tested that bellagio 0.9.1 still works fine with the master branch, > both for audio and video components. > > If you have anything on your mind for 0.10.0.5 now is the time to share it. > > Cheers. > > [1] http://freedesktop.org/wiki/GstOpenMAX > > -- > Felipe Contreras > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Gstreamer-openmax mailing list > Gstreamer-openmax@... > https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax > -- -- Prajnashi S |
|
From: Felipe Contreras <felipe.contreras@gm...> - 2009-03-24 00:12:40
|
Hi, Many things have changed since the previous release and it's already very late for the new release, I'm sorry I haven't had time to work on it. I've delayed the release because I wanted to have tunneling support, but I haven't had time to test it for Maemo. I don't want to delay the release any more for a number of reasons. There has been some work to port gst-openmax to Google Android, and I think there's already a patch series waiting to be merged. Since activity has increased so has the pressure from GStreamer developers to change the code-style to something more pleasant for them and since gst-openmax is part of the GStreamer project it was only a matter of time before that happened. So the plan is to rebase all the important branches to the latest git master branch, do a bit of testing and release 0.10.0.5. After that, the code-style will be updated. That would require rebasing the tunneling branch, and in the process I might be able to finally merge it, but maybe not. If I'm not able to merge the tunneling branch for 0.10.0.5, there will probably be another release soon after that with tunneling. In the meantime I've updated (rewritten?) the wiki page[1] and I've tested that bellagio 0.9.1 still works fine with the master branch, both for audio and video components. If you have anything on your mind for 0.10.0.5 now is the time to share it. Cheers. [1] http://freedesktop.org/wiki/GstOpenMAX -- Felipe Contreras |
|
From: Prajnashi S <prajnashi@gm...> - 2009-03-23 13:44:37
|
Hi, I upload gst-openmax + opencore OpenMAX patch. Currently, only AAC works. I will make more codec work very soon. The disadvantage is opencore cannot work anymore after apply my patch. :( On Sat, Mar 21, 2009 at 4:50 PM, Edward Hervey <bilboed@...> wrote: > > On Sat, 2009-03-21 at 16:30 +0800, Prajnashi S wrote: > > I just want OpenMAX. > > That we all agree on. > > > It's easy to reuse it with opencore, otherwise, I have to port > > bellagio + ffmpeg + x264 + mad + ..., it's a nightmare for me. > > Really ? The only problem I can see is that the openmax parts are > stored within the opencore modules (codecs_v2/), but I'll be working on > being able to use those parts alone. > > Yesterday I plotted the dependency graph of the whole of GStreamer (by > parsing all the .mk files) to figure out what key components needed to > be replaced. > For multimedia, the key parts are: > * libmedia (Kind of an abstraction layer to opencore and media > handling) > * libmediaplayerservice (A centralized playback service) > * libmedia_jni (the JNI bindings for libmedia) > > Nothing else does direct calls to OpenCore or their plugins, therefore > it should be those that should be switched to using GStreamer. > > So we basically have the following stack: > * applications/libraries/frameworks > * libmedia* > * OpenCore and/or decoders (they have a special handling for vorbis > and sonivox) > * OpenMax > > Which we can convert to: > * applications/libraries/frameworks > * libmedia* > * GStreamer and plugins. > * OpenMax > > > Meanwhile, I'm not sure if all these packages has performance issue. > > > > To use opencore, everything is done by PV. :-) > > > > On Fri, Mar 20, 2009 at 11:46 PM, Edward Hervey <bilboed@...> > > wrote: > > > > On Fri, 2009-03-20 at 17:28 +0200, Felipe Contreras wrote: > > > On Fri, Mar 20, 2009 at 5:15 PM, Edward Hervey > > <bilboed@...> wrote: > > > > > > > > Hi, > > > > > > > > This is a private mail (not on the mailing list). > > > > > > You mean not on the gst-openmax mailing list :) > > > > > > ... FUCK. > > > > > > > > > So yes, I was expecting these kind of issues considering > > how much of a > > > > mess the 'official' android repositories are. > > > > > > > > Maybe the best (if you haven't synchronized your local > > repositories) > > > > is to submit a patch against the 'old' opencore, and > > rebase it from > > > > there. > > > > > > > > The real question is ... do you really need opencore ? Or > > do you just > > > > need the openmax part of opencore ? > > > > > > > > I'm currently deactivating opencore in my local checkouts > > because: > > > > * it makes the whole build system fail (see > > android-platform) > > > > * We want to get rid of opencore :) > > > > > > I don't want to get rid of opencore. I'm all in for multiple > > choices :) > > > > > > > > > Sure, as long as we can strip opencore of everything that > > gstreamer > > and plugins does... which is.. well I guess it's all of > > opencore except > > for openmax. > > > > > > > > > > > > > > > > > > -- > > -- Prajnashi S > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups > "prajnashi" group. > To post to this group, send email to prajnashi@... > To unsubscribe from this group, send email to > prajnashi+unsubscribe@...<prajnashi%2Bunsubscribe@...> > For more options, visit this group at > http://groups.google.com/group/prajnashi?hl=en > -~----------~----~----~----~------~----~------~--~--- > > -- -- Prajnashi S |
|
From: Prajnashi S <prajnashi@gm...> - 2009-03-21 12:36:08
|
OpenMAX component will provided by IC vendor, but not defined by LiMo On Thu, Mar 19, 2009 at 10:05 PM, Wei <wei.hu.tw@...> wrote: > Hi, all, > > I know that LiMo uses Gstreamer as its multimedia framework. > However, does anyone know whether LiMo uses the gstreamer-openmax? > And if LiMo does use gstreamer-openmax, what OpenMAX IL components it > currently uses? > For example, MPEG-4 decoder component? or something else? > > Wei Hu > http://www.csie.ntu.edu.tw/~r88052/ > http://wei-hu-tw.blogspot.com/ > > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Gstreamer-openmax mailing list > Gstreamer-openmax@... > https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax > > -- -- Prajnashi S |
|
From: Edward Hervey <bilboed@gm...> - 2009-03-21 08:44:25
|
Hi,
On Sat, 2009-03-21 at 16:31 +0800, Prajnashi S wrote:
> Do you want rebase for me?
Whether it's a rebase, or just a patch from the 0.10.0.4 version, you
can send them to me and I'll integrate it into a git repository along
with adding it into the manifest.
Edward
>
> On Fri, Mar 20, 2009 at 11:25 PM, Felipe Contreras
> <felipe.contreras@...> wrote:
> On Fri, Mar 20, 2009 at 5:02 PM, Prajnashi S
> <prajnashi@...> wrote:
>
> > It depends on effort. If it's big, I will use 0.10.0.4 and
> rebase later.
> > Actually, why you put latest stable version to
> http://www.gstreamer.net/, just as
> > other packages do?
>
>
> Yes, the effort will need to be done, it just depends on who
> does it.
> Maybe it's easier for me to do it, maybe not, it depends on
> the amount
> of code.
>
> Well, 0.10.0.4 is the latest pre-release, I've been busy and I
> haven't
> had time to make another one =/
>
> --
> Felipe Contreras
>
>
>
> --
> -- Prajnashi S
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "prajnashi" group.
> To post to this group, send email to prajnashi@...
> To unsubscribe from this group, send email to prajnashi
> +unsubscribe@...
> For more options, visit this group at
> http://groups.google.com/group/prajnashi?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
|
|
From: Prajnashi S <prajnashi@gm...> - 2009-03-21 08:31:40
|
Do you want rebase for me? On Fri, Mar 20, 2009 at 11:25 PM, Felipe Contreras < felipe.contreras@...> wrote: > On Fri, Mar 20, 2009 at 5:02 PM, Prajnashi S <prajnashi@...> wrote: > > It depends on effort. If it's big, I will use 0.10.0.4 and rebase later. > > Actually, why you put latest stable version to http://www.gstreamer.net/, just > as > > other packages do? > > Yes, the effort will need to be done, it just depends on who does it. > Maybe it's easier for me to do it, maybe not, it depends on the amount > of code. > > Well, 0.10.0.4 is the latest pre-release, I've been busy and I haven't > had time to make another one =/ > > -- > Felipe Contreras > -- -- Prajnashi S |
|
From: Felipe Contreras <felipe.contreras@gm...> - 2009-03-20 15:25:30
|
On Fri, Mar 20, 2009 at 5:02 PM, Prajnashi S <prajnashi@...> wrote: > It depends on effort. If it's big, I will use 0.10.0.4 and rebase later. > Actually, why you put latest stable version to http://www.gstreamer.net/, just as > other packages do? Yes, the effort will need to be done, it just depends on who does it. Maybe it's easier for me to do it, maybe not, it depends on the amount of code. Well, 0.10.0.4 is the latest pre-release, I've been busy and I haven't had time to make another one =/ -- Felipe Contreras |
|
From: Prajnashi S <prajnashi@gm...> - 2009-03-20 15:04:02
|
Another issue is I also change opencore. We'd better create a new repo for it, just like we did in build On Fri, Mar 20, 2009 at 9:41 PM, Edward Hervey <bilboed@...> wrote: > > On Fri, 2009-03-20 at 21:02 +0800, Prajnashi S wrote: > > Hi, all > > I just modified gst-openmax-0.10.0.4 to make it use opencore OMX. > > Currently, only aac decoder works. I will contribute code in next 2 > > days. I will focus on mp3/amr/mp4/h263/h264 later. I think openmax > > solution is better than other software codec like ffmpeg in embed > > system, because > > 1) we can reuse opencore's OMX. > > 2) most chipset vendor provide OMX solution. > > > > Edward, > > Since the repo is more and more stable, I plan to push openmax > > direclty to your repository. We need discuss how to do that. > > > > In addtion, I'm not sure if 0.10.0.4 is too old (I change a lot of > > thing). I will check if I can rebase to newer version after that. > > Anyone in gst-openmax can give some comments? > > The best might be to: > * clone gst-openmax (cgit.freedesktop.org/gstreamer/) > * checkout the 0.10.0.4 version (git checkout -b android v0.10.0.4) > * apply your patches, commit everything > * send a mail with the output of "git diff v0.10.0.4" and I'll triage > it into a android-gst-openmax repo (and what can go upstream will go > upstream). > > Edward > > > > > -- > > -- Prajnashi S > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups > "prajnashi" group. > To post to this group, send email to prajnashi@... > To unsubscribe from this group, send email to > prajnashi+unsubscribe@...<prajnashi%2Bunsubscribe@...> > For more options, visit this group at > http://groups.google.com/group/prajnashi?hl=en > -~----------~----~----~----~------~----~------~--~--- > > -- -- Prajnashi S |