2520 replies to this topic

[athoik]

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

[betacentauri]

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

[pieterg]

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)

[Sjaaky]

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.

[athoik]

Here are my changes till now:

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

 

 

[Sjaaky]

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

[pieterg]

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)

[athoik]

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.

[pieterg]

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

[littlesat]

Good news!?

[Pr2]

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

 

Pr2

[Sjaaky]

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 .

[littlesat]

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

[veskop]

Maybe we can introduce it in the openpli 4.0 images.

When we can expect some alpha version for test?

[Sjaaky]

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".

[athoik]

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.

[pieterg]

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...

[athoik]

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

 

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

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

[pieterg]

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

[athoik]

Yes there is:

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

 

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