Jump to content


Photo

GStreamer 1.0

gstreamer 1.0 openpli

  • Please log in to reply
2520 replies to this topic

Re: GStreamer 1.0 #1781 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 4 October 2015 - 19:05

Ok found a solution on vuduo2.

 

When using aac audio the audiosink must run in sync.

I'm confused now, so is it problem with aac or raw on vuduo2?

 

Why turn on also gstreamer synchronization? It will just slow buffer flow down, drivers are doing synchronization as far as I know.

 

Please test if removal of my patch will help with playback, thanks.


Edited by mx3L, 4 October 2015 - 19:08.


Re: GStreamer 1.0 #1782 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 4 October 2015 - 19:16

I don't think the patch is wrong, we shouldn't allow other elements to change our sync setting as they like.

If it's really causing problems then we should turn on sync explicitly for raw audio in sink and not to rely on other elements to do it for us.

 

But I cannot confirm that, could you share a raw sample which doesn't work now properly on vuduo2? I will test it on vusolosev2.


Edited by mx3L, 4 October 2015 - 19:16.


Re: GStreamer 1.0 #1783 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 4 October 2015 - 20:04

Yes , it's all starting to be a bit messy. The media which caused the problem on (vuduo2) actually the problems only started after you're patch which just blocked the other elements to change or settings as they like. Since i dug so deeep in the physicall cd/dvd playing

I did not spend much time on the issue. but ....

 

my vuduo2 runs perfect for all with the setiings I give.

my dm8000 runs perfect for all with the settings I give.

 

Also can be said : by dm8000 the majority off media works also with the forced sync set on!! for audio , but not all.

                             by vuduo2 the  majority off media works also with the forced sync set off !! for audio , but not all.

 

By me its by dm8000 100 % if sync for audio forced off always.

                    vuduo2  100%  if sync for audio forced on always.

 

 

This means a real database media versus box should be made , it's really clear that the manufacturers dvb_driver also has an important impact on this setting.



Re: GStreamer 1.0 #1784 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 5 October 2015 - 06:21

by vuduo2 the  majority off media works also with the forced sync set off !! for audio , but not all.

Can you provide sample which doesn't work with sync off and works with sync on?



Re: GStreamer 1.0 #1785 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 5 October 2015 - 07:43

 

by vuduo2 the  majority off media works also with the forced sync set off !! for audio , but not all.

Can you provide sample which doesn't work with sync off and works with sync on?

 

http://users.telenet...ansp/sample.mkv



Re: GStreamer 1.0 #1786 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 5 October 2015 - 07:44

 

 

by vuduo2 the  majority off media works also with the forced sync set off !! for audio , but not all.

Can you provide sample which doesn't work with sync off and works with sync on?

 

http://users.telenet...ansp/sample.mkv

 

on dm8000 sync must be off.

on vuduo2 sync must be on



Re: GStreamer 1.0 #1787 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 5 October 2015 - 08:03

please apply this patch, or use master branch of openpli-enigma2 where it's already applied.

0001-servicemp3-ignore-processing-of-the-same-tags-messag.patch

 

It works for you with sync only because audio buffers are going slow so you're not flooded with tag messages... If you apply this patch, it should work for you also with sync off(well for me it works on vusolose, gst1.6, openpli-dvbmediasink)



Re: GStreamer 1.0 #1788 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 5 October 2015 - 09:40

Well that patch was already applied, but did not test after that was applied.

 

all test again all with sync forced off this saple on duo2 needed sync cause when you changed language track it stopped playing . Now it does that not anymore by that sample



Re: GStreamer 1.0 #1789 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 5 October 2015 - 12:38

Looks indeed that on my duo2 all works back ok if sink is set async.

 

https://github.com/c...ox-dvbmediasink

 

vuplus back to async.



Re: GStreamer 1.0 #1790 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 5 October 2015 - 13:52

That's good to hear. Please next time add some logs to support your claims..

 



Re: GStreamer 1.0 #1791 samsamsam

  • Senior Member
  • 2,024 posts

+146
Excellent

Posted 7 October 2015 - 00:04

Hello,

 

Here you can found player for MIPSEL platform based on ffmpeg (at now only with h264 and AAC codecs).

http://forums.openpl...-11#entry508208

 

Regards,

SSS



Re: GStreamer 1.0 #1792 pieterg

  • PLi® Core member
  • 32,766 posts

+245
Excellent

Posted 7 October 2015 - 08:17

Sync needs to be off, to avoid buffer underruns in driver and hardware.

If you need to enable sync as a workaround, this might indicate that the drivers have poor buffer handling.
It might avoid buffer overruns in that case.

Please just don't make it the default, sync needs to be disabled, thats the whole point of feeding gstreamer buffers to hardware decoders...

Re: GStreamer 1.0 #1793 Erik Slagter

  • PLi® Core member
  • 46,960 posts

+541
Excellent

Posted 7 October 2015 - 09:53

That means mx3l's patch should be reverted I guess.


Edited by Erik Slagter, 7 October 2015 - 09:53.

* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: GStreamer 1.0 #1794 littlesat

  • PLi® Core member
  • 56,303 posts

+691
Excellent

Posted 7 October 2015 - 09:59

Yep.... I had the same doubt.... I remember a time sync was tested....


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


Re: GStreamer 1.0 #1795 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 7 October 2015 - 10:05

That means mx3l's patch should be reverted I guess.

That's not right, my patch is making sure that other elements in pipeline don't turn sync ON.


Edited by mx3L, 7 October 2015 - 10:08.


Re: GStreamer 1.0 #1796 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 7 October 2015 - 20:25

@MastaG

I created bug report for h264parse, and gstreamer dev told us that it's not a bug

https://bugzilla.gno...g.cgi?id=755885

 

If it's problem for only one receiver, I suggest you, to make patch just for it. You can either revert this patch http://cgit.freedesk...27188ffae73c543

or remove VIDEO_CAPS from h264 caps in dvbvideosink, so h264parse will be not selected.



Re: GStreamer 1.0 #1797 MastaG

  • Senior Member
  • 1,531 posts

+118
Excellent

Posted 7 October 2015 - 21:36

Wow mx3L, thats really kind of you!
I was using your patch which removes the caps from the dvbmediasink and it has been working fine ever since :-)

All of my h264 movies (both dts and ac3).
Have been playing flawlessly in DreamPlex.

But I'll revert the gstreamer commit and leave the mediasink alone to see if it makes a difference.

Also a bit offtopic.
I found that the old patch from Athoik which increases the buffersize in servicemp3.cpp really improves streaming from sources with a bit of latency.
I've tested on dm800se, zgemma star and spark7162.
If anyone else would like to try it out to verify that it doesn't break anything, that would be great.
Then we may check this in as well.

Re: GStreamer 1.0 #1798 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 8 October 2015 - 06:51

guys, I still have problems with plenty of files even on the newest GST. It seems, that the issue is caused when the video contains an audio stream encoded with Lame and if it has enc_delay defined. This happens with both mp4 and mkv containers, enigma2 becomes unresponsive. 0.1 was fine, 1.5.1 also worked, just the codec and language was incorrectly displayed, from 1.5.9 it causes enigma2 to hang. 

Since latest service.mp3 patch concerning tags from mx3L the streams are ok

 

dm8000 ok

 

by vuduo2 the lcd must be disabled set to off. If You wan't to pause media. If lcd is to on when You press pause , the sink goes into pause , but enigma2 does not receive the state transition. Which means it can't be unpaused anymore.



Re: GStreamer 1.0 #1799 littlesat

  • PLi® Core member
  • 56,303 posts

+691
Excellent

Posted 8 October 2015 - 07:07

The sync on parch needs to be reverted and for the streams another solution should be found..... Read pietergs comments

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


Re: GStreamer 1.0 #1800 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 8 October 2015 - 07:18

@littlesat

Which sync on patch? We don't have in openpli any patch which turns on sync setting.

 

@pieterg probably didn't fully read this discussion. @christophecvr turn on sync in dvbaudiosink in his multibox-dvbmediasink, since it fixed problem with audio in 1.5.9/1.6.0 gstreamer version. But it wasn't necessary, since problem was with too many tags messages, which was resolved. So there is no sync patch on in any dvbmediasink.


Edited by mx3L, 8 October 2015 - 07:19.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users