Gstreamer 1.0 for raspbian

[m][sko]

Can you plz add gstreamer 1.0 packages to raspbian repo
it will need only recompilation and that is all
at least it work for me

http://ftp.de.debian.org/debian/pool/ma ... s-base1.0/
as much gstreamer plugins as possible

[plugwash]

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?

[m][sko]

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

[plugwash]

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.

[nemilos]

+1 for gstreamer1.0 in raspbian ! thx

can you give some line to compile gstreamer-1.0 for raspbian ? thx ..

[m][sko]

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

[m][sko]

+1 for gstreamer1.0 in raspbian ! thx

can you give some line to compile gstreamer-1.0 for raspbian ? thx ..

download source packages from
http://ftp.de.debian.org/debian/pool/ma ... s-base1.0/
for example
gst-plugins-base1.0_1.0.5-1.debian.tar.gz
gst-plugins-base1.0_1.0.5-1.dsc
gst-plugins-base1.0_1.0.5.orig.tar.xz

extract package with
dpkg-source -x gst-plugins-base1.0_1.0.5-1.dsc
and build packge with
dpkg-buildpackage -b -us -uc
all works fine on raspbian

[Defiant]

Maybe someone can put prebuilds on a custom repository?

[m][sko]

Maybe someone can put prebuilds on a custom repository?

I don't know to make repo.
do you know about any nice how to?

I would like to add gstreamer openmax package too, but I don't how to write proper debian package files

[Defiant]

I can do the repository part..trying to compile gst1.0 now.

As for creating packages, the debian distribution is pretty good documented, look for dh_make:
http://www.debian.org/doc/manuals/maint ... st.en.html

[m][sko]

I can do the repository part..trying to compile gst1.0 now.

As for creating packages, the debian distribution is pretty good documented, look for dh_make:
http://www.debian.org/doc/manuals/maint ... st.en.html

http://live.mdragon.org/gst_raspbian/
without gst-omx package for now

[Defiant]

ok cool, I copied them over:

/etc/apt/sources.list:

Code: Select all

deb http://vontaene.de/raspbian-updates/ . main

Did you start work on the package gst-omx yet? -if not I can set it up.

[m][sko]

ok cool, I copied them over:

/etc/apt/sources.list:

Code: Select all

deb http://vontaene.de/raspbian-updates/ . main

Did you start work on the package gst-omx yet? -if not I can set it up.

plz do it
thx

[Defiant]

Package gstreamer1.0-omx uploaded

[wickwire]

Thanks for all the work,

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:

gst-launch-1.0 --gst-debug=omx:5 filesrc location=big_buck_bunny_480p_h264.mov ! qtdemux name=demuxer \ demuxer. ! queue ! faad ! audioconvert ! alsasink device=hw:0,0 sync=false \ demuxer. ! h264parse ! omxh264dec ! autovideosink

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!

[Defiant]

works here, what does the debug output look like?

[acryl]

Thanks for packaging Gsteamer1.

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?

[Defiant]

opencv itself works fine on ARM. Maybe gstopencv hasn't been ported yet..

I connect both together using the appsink element.

[Defiant]

I have updated the gstreamer1.0-omx Package to 1.0 from
http://lists.freedesktop.org/archives/g ... 00275.html

[mcisely]

by wickwire » Wed Mar 06, 2013 11:25 am
Thanks for all the work,

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:

gst-launch-1.0 --gst-debug=omx:5 filesrc location=big_buck_bunny_480p_h264.mov ! qtdemux name=demuxer \ demuxer. ! queue ! faad ! audioconvert ! alsasink device=hw:0,0 sync=false \ demuxer. ! h264parse ! omxh264dec ! autovideosink

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:

gst-launch-1.0 filesrc location=big_buck_bunny_480p_h264.mov ! qtdemux ! h264parse ! omxh264dec ! ximagesink

Actual tty output from the attempt:

Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstOMXH264Dec-omxh264dec:omxh264dec-omxh264dec0: Internal data stream error.
Additional debug info:
gstomxvideodec.c(1667): gst_omx_video_dec_loop (): /GstPipeline:pipeline0/GstOMXH264Dec-omxh264dec:omxh264dec-omxh264dec0:
stream stopped, reason not-negotiated
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...

This also breaks in the same way:

gst-launch-1.0 filesrc location=big_buck_bunny_480p_h264.mov ! decodebin ! autovideosink

Exact output in the above case:

Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstOMXH264Dec-omxh264dec:omxh264dec-omxh264dec0: Internal data stream error.
Additional debug info:
gstomxvideodec.c(1667): gst_omx_video_dec_loop (): /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstOMXH264Dec-omxh264dec:omxh264dec-omxh264dec0:
stream stopped, reason not-linked
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...

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?

-Mike

[Defiant]

The problem seems to be with the sink. So far I only tested xvimagesink over ssh.
The same pipeline works with fakesink, right?

[denjell]

just wondering if you could add a python-gst1.0 and python-gst1.0-dev to the repo...

[mcisely]

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.

-Mike

[Defiant]

ok, I have updated gstreamer to 1.0.6 and liborc to 0.4.17.

After updating the following pipeline should work:

Code: Select all

 gst-launch-1.0 filesrc location=big_buck_bunny_720p_H264_AAC_25fps_3400K.MP4 ! decodebin ! videoconvert ! ximagesink

just wondering if you could add a python-gst1.0 and python-gst1.0-dev to the repo...

The gst1.0 python wrapper doesn't seem to be packaged for debian yet :(

[Defiant]

I've uploaded a new version of the bad plugins with fbdevsink enabled using this patch