I'm not going to put in a second version of a large and potentially security sensitive library like gstreamer without a very good reason. Do you have a very good reason for using this over the version of gstreamer that is in wheezy?

plugwash wrote:I'm not going to put in a second version of a large and potentially security sensitive library like gstreamer without a very good reason. Do you have a very good reason for using this over the version of gstreamer that is in wheezy?

gstreamer-0.10 and gstreamer 1.0
work together.
I don't know about any packages that depend on gstreamer 1.0
but, gstreamer 1.0 is only version that support gstreamer openMax
I think many people would like to test new stuff from gstreamer 1.0 and don't what to recompile it on raspberry pi.
And hw acceleration from openMax is really nice
as output to Qt QML and other

If you still don't want
Is there any plan with experimental repo ? like on offication debian repo

The gstreamer website says they can be installed together but doesn't say anything about them "working together",

Our priority for raspbian wheezy is to stay as close to debian wheezy as reasonablly possible and avoid breaking stuff that works. The only time I'd even consider rebuilding everything against a new version of a library before debian does it is if the version currently in raspbian is not working at all. So even if I did put gstreamer 1.0 in it would just be a confusing orphan.

plugwash wrote:The gstreamer website says they can be installed together but doesn't say anything about them "working together",

Our priority for raspbian wheezy is to stay as close to debian wheezy as reasonablly possible and avoid breaking stuff that works. The only time I'd even consider rebuilding everything against a new version of a library before debian does it is if the version currently in raspbian is not working at all. So even if I did put gstreamer 1.0 in it would just be a confusing orphan.

So sorry but you will have to wait for raspbian jessie.

This is not about rebuilding against new library.
all packages stay linked with gstreamer 0.10
but you will add this new library to repository(distribution) and that is all.

or you can simply add experimental repository(distribution) from debian repo(distribution)
and all users will be able to use this kind of packages as gstreamer 1.0 is one of experimental package

If I use wheezy armel on rasp. I can simple download/install gstreamer 1.0 and all works fine
but I can't do same on raspbian that is problem
as debian have experimental repo(distribution) but raspbian don't

Last edited by m][sko on Wed Feb 20, 2013 3:06 pm, edited 1 time in total.

I have installed the gstreamer1.0* packages from the repo and attempted video playback with gst-launch. I couldn't find any fbdevsink element, so I went with X > startx and then the following gst-launch line:

I was really interrested to test gstreamer opencv plugins, but it doesn't seem to be in the bad-plugins package, i was wondering if it's because opencv is made for intel cpu and it could'nt be ported on arm?

I have installed the gstreamer1.0* packages from the repo and attempted video playback with gst-launch. I couldn't find any fbdevsink element, so I went with X > startx and then the following gst-launch line:

I got "internal data stream error" and "pipeline doesn't want to preroll" - also tried with other media files.

Can any of you confirm or dismiss success using gst-omx at this point, with gstreamer 1.0 on the Pi?

Maybe a proper gst-launch line for testing?

Thanks!

I can confirm the same bad behavior here. I am running latest-everything including the latest gstreamer packages from vontaene.de as of a few hours ago. Here's a simpler stream invocation that produces the same result:

I'm happy to run this again with debug output enabled. What level is best to try?

Note: The same file plays perfectly with omxplayer - but I'd really like to get this working within the gstreamer framework, as I have to embed this inside another app. (And at this point I'm about ready to give up on gstreamer and turn my attention entirely to using openmax directly. But I'd rather not.)

I've spent A LOT of hours studying / learning how to use gstreamer over the past week or so. To date, I have yet to get openmax to play well with gstreamer. The above is the closet I've come. It is entirely possible that I'm doing something dumb here. Help?

by Defiant » Sat Mar 30, 2013 4:08 am
The problem seems to be with the sink. So far I only tested xvimagesink over ssh.
The same pipeline works with fakesink, right?

You're absolutely right. I hadn't thought to try it that way - still too new to this. With fakesink it doesn't crash (I presume it's pumping video into the bit bucket). With xvimagesink pointing over an ssh X proxy it works - as a slideshow of course. But interestingly enough if I change that to ximagesink pointing over the same ssh proxy I get the same crash as earlier documented.

The error message text had me looking at gst-omx - how could that be getting influenced by the type of sink in use? I'm pretty sure I also tried a software-rendering pipe using ximagesink successfully - though of course it rendered at about 1/3 FPS... Given that, then the issue is the specific combination of gst-omx and ximagesink. I wonder if I can stick something in the pipe in between the two that will help them from messing with each other?

Unfortunately I don't see any other gstreamer sink types via "gst-inspect-1.0 | grep sink" that show any promise for use with the Pi's GPU.