Jump to content


Photo

GStreamer 1.0

gstreamer 1.0 openpli

  • Please log in to reply
2520 replies to this topic

#1 athoik

  • PLi® Core member
  • 8,456 posts

+326
Excellent

Posted 3 July 2013 - 19:11

Dear All,

 

 

I thing that everyone likes some might interesting in the new features and stability? offered by newer versions of GStreamer.

 

OpenPLi currently has some "experimental" branches (named gst 1.0) where GStreamer API changes applied in order to be able to build images with the new version of GStreamer.

 

Using those branches i have managed to build an image using latest (stable) GStreamer 1.0.7.

 

Of course results are not so good. Almost.. no media work (except some mkv).

 

So i have some questions:

 

1. Do you want/accept patches for gst 1.0 branch?

 

2. Is it possible to update gst 1.0 branch to latest version (and synchronize with HEAD)?

 

3. What would be the starting point for fixing things, eg first try to fix MP3?

 

4. Maybe its better to create "experimental" gst 1.0 on Github so other teams interesting in Gstreamer 1.0 help?

 

I can attach changes already did here, if someone wants to play with GStreamer 1.0. Making one step at a time all of the sudden we are going to have the first Enigma2 with GStreamer 1.0.

 

Regards,

athoik


Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: GStreamer 1.0 #2 betacentauri

  • PLi® Core member
  • 7,185 posts

+323
Excellent

Posted 3 July 2013 - 20:57

Hi athoik,

 

I think it is a good idea. I also wanted to look at gstreamer 1.x.

To 3: Sjaaky seems to have a solution for this. And I also have fixed it in the current gstreamer version. Perhaps this patch also helps for 1.x:

  http://sourceforge.n...3e5cbc466.patch

 

Regards,

Betacentauri


Xtrend ET-9200, ET-8000, ET-10000, OpenPliPC on Ubuntu 12.04

Re: GStreamer 1.0 #3 pieterg

  • PLi® Core member
  • 32,766 posts

+245
Excellent

Posted 3 July 2013 - 21:04

currently the biggest problem with 1.0 is that the 'systemstream=false' property for video/mpeg does not seem to work

If you omit it from the caps, most formats are playing (but the stream format is not correct, video is stuttering)

Re: GStreamer 1.0 #4 Sjaaky

  • Senior Member
  • 7,443 posts

+41
Good

Posted 3 July 2013 - 21:57

I pushed my changes.
Note that the video part is still very flaky. Only the first few seconds works for some video's. Gstreamer logs an error like 'unmap: assert failed. This is not a buffer'. In order to find out I added a lot of debug output and commented unmaps and unrefs. It is worse now, because all video's fail after a few seconds, because the system runs out of memory.

Anyway I don't have the time to make a better fix. So I'm putting it in your hands ;). Good luck!

currently the biggest problem with 1.0 is that the 'systemstream=false' property for video/mpeg does not seem to work

If you omit it from the caps, most formats are playing (but the stream format is not correct, video is stuttering)

Which means extra headers should be added or headers need to be stripped before we write it to hardware?

Edited by Sjaaky, 3 July 2013 - 21:58.


Re: GStreamer 1.0 #5 athoik

  • PLi® Core member
  • 8,456 posts

+326
Excellent

Posted 3 July 2013 - 22:00

Here are my changes till now:


Attached File  0001-Changes-to-get-latest-gstreamer-1.0.patch.txt   25.14KB   196 downloads

 

 


Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: GStreamer 1.0 #6 Sjaaky

  • Senior Member
  • 7,443 posts

+41
Good

Posted 3 July 2013 - 22:06

Nice way to patch the plugins. I just stripped the plugins from my image, because I was to lazy find a real solution.

Re: GStreamer 1.0 #7 pieterg

  • PLi® Core member
  • 32,766 posts

+245
Excellent

Posted 3 July 2013 - 22:09


currently the biggest problem with 1.0 is that the 'systemstream=false' property for video/mpeg does not seem to work

If you omit it from the caps, most formats are playing (but the stream format is not correct, video is stuttering)

Which means extra headers should be added or headers need to be stripped before we write it to hardware?


Yes, probably.
Or we need to split the stream into whole frames.
Or perhaps there is a replacement for the systemstream property, in 1.0 (I didn't find it yet)

Re: GStreamer 1.0 #8 athoik

  • PLi® Core member
  • 8,456 posts

+326
Excellent

Posted 4 July 2013 - 06:27

currently the biggest problem with 1.0 is that the 'systemstream=false' property for video/mpeg does not seem to work

If you omit it from the caps, most formats are playing (but the stream format is not correct, video is stuttering)

 

Maybe this bug is related with our issue.

 

Sebastian Dröge (GStreamer developer)

I don't know why it exists either but everything all over the place is expecting it. We might want to remove it in 2.0 though.


Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: GStreamer 1.0 #9 pieterg

  • PLi® Core member
  • 32,766 posts

+245
Excellent

Posted 4 July 2013 - 08:46

Ok, this discussion happened after I last tested 1.0, so the systemstream issue might very well be solved with this commit.

Re: GStreamer 1.0 #10 littlesat

  • PLi® Core member
  • 56,091 posts

+685
Excellent

Posted 4 July 2013 - 08:57

Good news!?

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: GStreamer 1.0 #11 Pr2

  • PLi® Contributor
  • 6,034 posts

+255
Excellent

Posted 4 July 2013 - 09:40

Good time to do a full system backup before next online update?  :D

 

Pr2


NO SUPPORT by PM, it is a forum make your question public so everybody can benefit from the question/answer.
If you think that my answer helps you, you can press the up arrow in bottom right of the answer.

Wanna help with OpenPLi Translation? Please read our Wiki Information for translators

Sat: Hotbird 13.0E, Astra 19.2E, Eutelsat5A 5.0W
VU+ Solo 4K: 2*DVB-S2 + 2*DVB-C/T/T2 (used in DVB-C) & Duo 4K: 2*DVB-S2X + DVB-C (FBC)

AB-Com: PULSe 4K 1*DVB-S2X (+ DVB-C/T/T2)
Edision OS Mio 4K: 1*DVB-S2X + 1*DVB-C/T/T2
 


Re: GStreamer 1.0 #12 Sjaaky

  • Senior Member
  • 7,443 posts

+41
Good

Posted 4 July 2013 - 10:08

No. The gstreamer 1.0 branches are still for developers and home-builders only. There are no images available online.
We still need to think about how to introduce gstreamer 1.0 to our users. Maybe we can introduce it in the openpli 4.0 images. But that all depends on when gstreamer 1.0 will be as stable as gstreamer 0.10 in openpli 3, or should I say as stable as in openpli 2.1 ;).

Re: GStreamer 1.0 #13 littlesat

  • PLi® Core member
  • 56,091 posts

+685
Excellent

Posted 4 July 2013 - 14:58

I suggest post the latest changes gstreamer 0.1 is currently more stable in 3.0 then in 2.1...

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: GStreamer 1.0 #14 veskop

  • Senior Member
  • 364 posts

+2
Neutral

Posted 4 July 2013 - 16:11

Maybe we can introduce it in the openpli 4.0 images.

When we can expect some alpha version for test?


Gigablue Quad +250GB HDD ~ Xtrend ET5000 ~ Triax110 Black Multifeed 36E/28E/23E ~ Total TV88 Multifeed 19E/16E/13E/9-7E ~ EMP Centauri 9/1 DiSEqC ~ Panasonic L42G20


Re: GStreamer 1.0 #15 Sjaaky

  • Senior Member
  • 7,443 posts

+41
Good

Posted 4 July 2013 - 16:18

This is a development thread, for developers only. Stop asking questions about images, alpha version, beta version, etc..
Answer to all 'when'-questions is "in due time".

Re: GStreamer 1.0 #16 athoik

  • PLi® Core member
  • 8,456 posts

+326
Excellent

Posted 5 July 2013 - 10:53

Hi all,

 

 

When i am trying to play videos with Gstreamer 1.0 the working videos return the following :

 

 

(enigma2:918): GStreamer-CRITICAL **: gst_buffer_unmap: assertion `GST_IS_BUFFER(buffer)' failed
(enigma2:976): GStreamer-CRITICAL **: gst_buffer_unmap: assertion `GST_IS_BUFFER(buffer)' failed
(enigma2:1023): GStreamer-CRITICAL **: gst_buffer_unmap: assertion `GST_IS_BUFFER (buffer)' failed
...

 

Looking on the servicemp3.cpp i can that we are calling gst_buffer_unmap on two places on  eServiceMP3InfoContainer destructor (line 302) and on  eServiceMP3 gstBusCall (line 1552).

 

Inside gstBusCall we define GstMapInfo map variable (line 1545).

 

How the variable map is know inside eServiceMP3InfoContainer destructor? Also how the variable map is know on eServiceMP3InfoContainer setBuffer (line 335)

 

Maybe (at least) we are leaking memory on those places?

 

 

PS. Soon i will post patches required to build image with GStreamer 1.0 after Sjaaky commit.


Edited by athoik, 5 July 2013 - 10:54.

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: GStreamer 1.0 #17 pieterg

  • PLi® Core member
  • 32,766 posts

+245
Excellent

Posted 5 July 2013 - 11:25

How the variable map is know inside eServiceMP3InfoContainer destructor? Also how the variable map is know on eServiceMP3InfoContainer setBuffer (line 335)

The map is initialised in setBuffer (gst_buffer_map).
And it is unmapped in the destructor, but only if the bufferValue is nonzero (so setBuffer has been called, and map is valid)

Also, the buffer is ref'ed in setBuffer, and not unref'ed untill after unmap.
So I don't see the reason for the assertion...

Re: GStreamer 1.0 #18 athoik

  • PLi® Core member
  • 8,456 posts

+326
Excellent

Posted 5 July 2013 - 11:59

The map is initialised in setBuffer (gst_buffer_map).

 

But there is no declaration (eg GstMapInfo map) inside eServiceMP3InfoContainer! We need a declaration right?

 

PS. I am attaching changes required to build GStreamer 1.0

 

Attached File  0001-Changes-to-get-latest-gstreamer-1.0.patch.txt   3.76KB   63 downloads


Edited by athoik, 5 July 2013 - 11:59.

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: GStreamer 1.0 #19 pieterg

  • PLi® Core member
  • 32,766 posts

+245
Excellent

Posted 5 July 2013 - 12:24


The map is initialised in setBuffer (gst_buffer_map).

 
But there is no declaration (eg GstMapInfo map) inside eServiceMP3InfoContainer!


Yes there is:
http://sourceforge.n...ervicemp3.h#l75

Re: GStreamer 1.0 #20 athoik

  • PLi® Core member
  • 8,456 posts

+326
Excellent

Posted 5 July 2013 - 12:38

Yes there is:

http://sourceforge.n...ervicemp3.h#l75

 

Ooops. you are right! I did't look on header file, sorry about that.


Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916



2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users