Forums

- With the patch mp3 playback works, but the progress on the timeline is too fast. Within 10 seconds playback (from start of file) timeline shows over 1 minute.

@athoik: You don't have this problem??

- With the patch mp3 playback works, but the progress on the timeline is too fast. Within 10 seconds playback (from start of file) timeline shows over 1 minute.

@athoik: You don't have this problem??

 

Yes, i have this also (just checked), count it as 5.
 

Yes my bad. I didn't have a lot of time and a few people asked for gst 1.0 improvements, so I though just commit it and be done with it.

I know, no problem. Just a tip, git-cola helps me a lot in such situations, to quickly sort out my local changes.

- With the patch mp3 playback works, but the progress on the timeline is too fast. Within 10 seconds playback (from start of file) timeline shows over 1 minute.

Me too, sort of. The AUDIO_CONTINUE is given to the hardware before the first bytes are written to the buffer. The first sound I hear is > 10 seconds into the song.
Edited by Sjaaky, 7 July 2013 - 21:28.

One issue gone... (thanks to help from gstreamer irc channel).

 

Issues till now:

3. Trying to play hls streams i am getting missing H.264 decoder.

 

 

root@dm800se:~# gst-launch-1.0 playbin uri=http://devimages.apple.com/iphone/samples/bipbop/gear1/prog_index.m3u8
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
Buffering, setting pipeline to PAUSED ...
Done buffering, setting pipeline to PLAYING ...
Missing element: H.264 decoder
WARNING: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: No decoder available for type 'video/x-h264, stream-format=(string)byte-stream, alignment=(string)nal'.
Additional debug info:
gsturidecodebin.c(880): unknown_type_cb (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0
WARNING: from element /GstPlayBin:playbin0/GstPlaySink:playsink: No volume control found
Additional debug info:
gstplaysink.c(2649): gen_audio_chain (): /GstPlayBin:playbin0/GstPlaySink:playsink:
Volume/mute is not available
New clock: GstSystemClock
^CCaught interrupt -- handling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 10017752335 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

 

Maybe stream-format=(string)byte-stream is causing a problem?

 

[22:16] <athoik> hello guys, i am using GStreamer on embeeded STB (Dreambox with Enigma2)

[22:16] <athoik> and there is an efford to migrate on Gstreamer 1.0

[22:17] <athoik> some specialists already did some changes to the API

[22:18] <athoik> and now we can build images (using custom openembedded) with GStreamer 1.0

[22:18] <athoik> but we are facing many issues

[22:20] <athoik> eg when we are trying the following gst-launch-1.0 playbin uri=http://devimages.app...prog_index.m3u8

[22:20] <athoik> we are getting No decoder available for type 'video/x-h264, stream-format=(string)byte-stream, alignment=(string)nal'.

[22:23] <athoik> but on sink we have the following (among other caps) video/x-h264, width = (int) [ 16, 4096 ], height = (int) [ 16, 4096 ], framerate = (fraction) [ 0, MAX ]

[22:23] <__tim> yeah, the subset caps checks are a bit stricter in 1.0 (read: have been fixed like how they're supposed to work)

[22:24] <__tim> the problem is the missing framerate field here

[22:24] <__tim> the sink should probably not require it

[22:24] <athoik> ok a i can create the sink without framerate and retry

[22:25] <athoik> btw, here is the sink of our STB  http://sourceforge.n...tdvbvideosink.c

[22:25] <__tim> but it should probably have a parsed=true so that h264parse is plugged

[22:26] <athoik> where should i put parsed=true? on the pipeline

[22:27] <__tim> where you remove the framerate=[0,MAX] in the sink template caps

[22:28] <__tim> it might not be needed, depends a bit on your sink

[22:57] <athoik> wow! __tim, it worked!  :-)

[22:58] <athoik> now gst-launch-1.0 playbin uri=http://devimages.app...prog_index.m3u8 is working

[22:58] <athoik> thank you

 

Interesting!
Also the "parsed=true" thing which might be a cleaner solution for the mp3 problem (my patch for the mp3 problem reverts one commit). If I have time I'll check if it is really a fix for the problem.
Thanks athoik!

@sjaaky, pieterg: Would it be possible to commit the patches in the gst1.0 branch? Would be easier for everyone to have the latest version instead of searching in the forum for patches.
Edited by betacentauri, 8 July 2013 - 21:52.

Hi there,

 

 

h264parse is missing.. (i think i is install by default on gstreamer 0.10) In order to get it back we need to install the following:

 

 

opkg install gst-plugins-bad-videoparsersbad_1.0.7-r4_mips32el.ipk libgstcodecparsers-1.0-0_1.0.7-r4_mips32el.ipk

 

I have already some patches that they are solving bad flv metadata (ported from 0.10), but the i don't know if we them also, now that h264parse is back i will test again tommorow.

Edited by athoik, 8 July 2013 - 22:05.

Thanks for all the help here....

Hello,

 

Can we restart this thread?

 

It would be nice to bring gst-1.0 branch up to date and start pushing patches already provided here.

 

Thanks.

 

PS. GStreamer 1.2.2 is out!

Is it interesting to spend the effort to implement it? What are the highlights?

There are numerous improvements like:

Gstreamer 0.10 not supported any more, (Gstreamer) developers ask to switch to newer version in order to open ticket.

GStreamer 1+ has much better support for HLS (+encrypted segments)

Has DASH-MPEG and generally better support for streaming.

The new version offers more flexible memory management, attaching non-media metadata to buffers and more efficient buffer allocation. These improvements should make the framework more suitable for use in embedded devices...

And many, many other improvements.

http://m.h-online.co...?from-classic=1
Edited by athoik, 27 December 2013 - 21:50.

gstreamer 1.x has already been in OE-core for a while. It's my understanding that there are issues with the drivers that make it hard to switch to a more recent version and so we're stuck with the ancient 0.x versions.

no, we're not stuck to 0.x, 1.x just needs some more work (in servicemp3 and dvbmediasink)

And for vu and dmm we cannot use our mediasink anymore.....???

We can use OpenPLi mediasink if we create patches (#ifdef Dreambox, #ifdef Vu, etc) in order to handle Dreambox and Vu special cases. But i don't think you like to mess OpenPLi code like this.

Well, we need more recent gstreamer versions for E.G. "Uitzending gemist" plugin, the SBS6, Net5 and Veronica videostreams dont play correct due to issues with fragmented video play support in old gstreamer 0.10

Since openpli dropped support for dreambox, that leaves only issues with Vu+ boxes, or is this "problem" common for all boxes.

I havent tried it yet but is my xp1000 box giving issues too?

There are issues solved on this thread, with patches attached, but never applied.

I would like to see some activity here

This is in the planning for sure. It's just that's it's quite a big bang and we've had numerous problems with gstreamer updates before.

Edited by Erik Slagter, 21 January 2014 - 20:10.

I would like to see some activity here

 

Me too, perhaps the regular openpli devs are quite busy with their paid job and they appreciate a helping hand

 

I'm merely a novice coder but I learn quick. I brushed my C skills a little bit up on oscam but I want to make a switch to something more usefull.

The gstreamer upgrade looks like  a nice starting point for me: its well documented and I can learn a lot from it.

 

http://cgit.freedesk...ting-to-1.0.txt

 

http://www.google.nl....59568121,d.d2k

 

Right now facing a total new world with git instead of svn I was just getting used to handle, so first thing learning how to handle the new workbench tools!

 

BTW: Compiling on my vm image takes awfull long time, does it make any noticable difference if I configure an old P4 3.0 HT with native linux to compile?

Edited by theparasol, 21 January 2014 - 20:16.

As athoik said, we have more or less ready-to-go patches. We've had some discussion whether to apply them in a separate branch first or immediately on the master. The decision has been made for the second option. This means that at some moment in time, there will be a image version that is VERY experimental, so we might want to warn user to make backups, download the previous-working-image etc.