2520 replies to this topic

[MastaG]

Wow thanks Athoik.
I'll test it on my dm800se asap. I have some movies with dts audio.

[babsy98]

we wait for feedback

[christophecvr]

Wow thanks Athoik.
I'll test it on my dm800se asap. I have some movies with dts audio.

Did You test it already.

 

Since that code actually I already tried more then a year ago (whitout extra parameters but well only for gst-1 that well).

 

But then it screwed the manual pause unpause , but since the pause unpause has been corrected by mx3L could quit be that it works now.

[MastaG]

Flashing my dm800se right now.

That is openpli-oe-core gst-1, christophecvr multibox dvbmediasink and athoiks patch on top of enigma2.

[MastaG]

Alright some HLS streams play, but some are still broken:

 

M6 (encrypted HLS stream): http%3a//sslhls.m6tv.cdn.sfr.net/hls-live/livepkgr/_definst_/m6_hls_aes/m6_hls_aes_856.m3u8

Freezes after a whlie,  probably after the next chunk

 

Cielo (HLS stream): http%3a//skyianywhere2-i.akamaihd.net/hls/live/216865/cielo/playlist.m3u8

Freezes after a whlie,  probably after the next chunk

 

Tech N9ne (HLS VOD): http%3a//wildhitz.rr.kpnstreaming.nl/b2b/vod/wildhitz/mp4s/Tech_N9ne_-_Strangeulation_Cypher/index.ism/index.m3u8

Skips a bunch of frames when switching to the highest quality but plays OK now :-)

 

I'm currently copying my movie with DTS audio to my usb stick (had to format it NTFS because of the file limit on fat32).

Will take another 15 minnutes

[MastaG]

DTS downmix is working great here on my DM800Se.

Also after a seek there is no silence, audio keeps working.

 

I guess we've reached a milestone now :-)

 

Most fragmented streams work great now also DTS downmix works without a hitch.

 

I guess athoik, mx3L, christophecvr and Beeker deserve a slice of my delicious home-made weed-cakes

Thanks for making this happen for all of us.

This is the point where gstreamer 1.x really surpasses 0.10.

 

I'll start building new images for everyone later this week !

Edited by MastaG, 30 November 2015 - 23:28.

[christophecvr]

Why don't you try the following? It will work for all cases, without extra variables, not only for GStreamer 1.0 etc etc.
 

diff --git a/lib/service/servicemp3.cpp b/lib/service/servicemp3.cpp
index f6729ab..ea4bbd4 100644
--- a/lib/service/servicemp3.cpp
+++ b/lib/service/servicemp3.cpp
@@ -750,7 +750,7 @@ RESULT eServiceMP3::start()
        {
                eDebug("[eServiceMP3] starting pipeline");
                GstStateChangeReturn ret;
-               ret = gst_element_set_state (m_gst_playbin, GST_STATE_PLAYING);
+               ret = gst_element_set_state (m_gst_playbin, GST_STATE_PAUSED);

                switch(ret)
                {
@@ -2030,6 +2030,8 @@ void eServiceMP3::gstBusCall(GstMessage *msg)
                                if (m_errorInfo.missing_codec.find("video/") == 0 || (m_errorInfo.missing_codec.find("audio/") == 0 && m_audioStreams.empty()))
                                        m_event((iPlayableService*)this, evUser+12);
                        }
+
+                       gst_element_set_state (m_gst_playbin, GST_STATE_PLAYING);
                        break;
                }
                case GST_MESSAGE_ELEMENT:

In deed media does not pause anymore with that above.

 

so the extra params are required.

 

here included the patch for all media pull request send also

Attached Files

•  e2-pause-unpause.patch   2.63KB   19 downloads

[MastaG]

Yep, apply asap! ;-)

[christophecvr]

and the fun even after the patch above, astream which had regularly freezes now works perfect.

 

the one is

#SERVICE 4097:0:1:0:0:0:0:0:0:0:http%3a%2F%2Frtmp.infomaniak.ch%2Flivecast%2Ftvm3%2Fplaylist.m3u8:TVM%203
#DESCRIPTION TVM 3

[christophecvr]

 

and the fun even after the patch above, astream which had regularly freezes now works perfect.

 

the one is

#SERVICE 4097:0:1:0:0:0:0:0:0:0:http%3a%2F%2Frtmp.infomaniak.ch%2Flivecast%2Ftvm3%2Fplaylist.m3u8:TVM%203
#DESCRIPTION TVM 3

Sorry it's depend's on what they are transmitting still some times a freeze between 3 to max 12 sec. However less frequent and much shorter.

 

Note : this stream also is much much worser on all other players. vlc,totem or even from browser using quicktime.

 

The freezing occurs when the playlist.m3u8 changes.

[mamamia]

As  see it, you guys are giving the e2 community the chance to finally influence the future gstreamer development. Gstreamer as well as other open source dev teams can not fix or improve 5 year old decapriated versions. Please keep up the great work! Thank you!

[athoik]

M6 (encrypted HLS stream): http%3a//sslhls.m6tv.cdn.sfr.net/hls-live/livepkgr/_definst_/m6_hls_aes/m6_hls_aes_856.m3u8
Freezes after a whlie,  probably after the next chunk

Please have a look on the other thread regarding this M6, as I said you should have a look with your provider, TS stream is not for our hardware decoders.

See: http://forums.openpl...e-4#entry515984

We have a ticket waiting on GStreamer, if nobody can provide an answer on what is wrong on TS stream I will close the ticket.

so the extra params are required.

Why extra parameter m_user_paused is required? How this variable differs from m_paused?

[christophecvr]

 

M6 (encrypted HLS stream): http%3a//sslhls.m6tv.cdn.sfr.net/hls-live/livepkgr/_definst_/m6_hls_aes/m6_hls_aes_856.m3u8
Freezes after a whlie,  probably after the next chunk

Please have a look on the other thread regarding this M6, as I said you should have a look with your provider, TS stream is not for our hardware decoders.

See: http://forums.openpl...e-4#entry515984

We have a ticket waiting on GStreamer, if nobody can provide an answer on what is wrong on TS stream I will close the ticket.

so the extra params are required.

Why extra parameter m_user_paused is required? How this variable differs from m_paused?

 

The m_paused is used in other situation and or live streams on some seek operations. That's why we cant really rely on it.

 

Actually I'm shure that somewhere in one off the seek procedure some changes must be done with the most recent gst vers.

 

But I really introduced the m_user_paused.  Which only is and can be true when the user paused the media by remote pause button. This action can't be done by a live stream anyway.

 

If You pause the media it willl always recieve a msg  case GST_MESSAGE_ASYNC_DONE:

 

Whitout the protection in case off user requested pause it will relaunch the movie cause you always for the gst to play.

 

So there is a real difference between the use off m_paused  off a user action paused. That's why I introduce the parameter which only is true if the user selected to pause the media. A use which can't be done by live streams.

 

But now I'm so good as shure that the deadlock was caused because before I used :

if(m_paused && !m_user_paused)

In certain cases it could happen that m_paused was not true and so causes the gst never to be be set to playing and this .... resulted to the deadlock's.

 

By just using

if(!m_user_paused)

You cover the users manual requested pause (not avbl by live streams)

 

But also always will launch the gst to playing after settings are known which is so after

case GST_MESSAGE_ASYNC_DONE:

So now we start the gst in a real correct state and that is paused.  Until the required date such as caps are set and eventual extra data based on meta date such as tags and toc is done.

I good example is the tag to selcet You're desired language . The toc by mkv will make the chapter info avbl as a cut so we can jump from chapter forwards or back works perfect now.

 

Then the GST_MESSAGE_ASYNC_DONE will only come if al is known and by the code behind actions taken in function off caps tags tocs. Hup we go and launch the full gstreamer to play for all sinks togheter in the same time fragment.

 

We are working async , this means that before the pas from pause to the first playing all segments need to be set right. In function off base media even the eventual first base shift between audio/video which may be there.

Edited by christophecvr, 1 December 2015 - 14:45.

[athoik]

The m_paused is used in other situation and or live streams on some seek operations. That's why we cant really rely on it.

Really we cannot rely on m_paused? But we can rely on m_user_paused that has exacly the same value as m_paused?

...

416	m_paused = false;
419	m_user_paused = false;

...

1751	m_user_paused = false;
1752	m_paused = false;

...

1763	m_user_paused = true;
1764	m_paused = true;

...

[christophecvr]

Well if there is no difference ??

 

Why this could happen ?

if(m_paused && !m_user_paused)

The point is the very first pas from paused to playing may only and only happen after all caps,tags,tocs are passed , processed and the resulting action have taken,set and done.

 

So at start off media normally the above will be nice . But may NOT happen in case off m_user_paused = true.

 

The m_pause and m_user_paused are two different options however they maybe mostly togheter. in some case. The m_user_paused is always false at media start and will only become true when the user request a pause via remote command off when media stop sequence has been initiated.

 

The gst may not be set back in play state once we are passed the first manual unpause by the :

GST_MESSAGE_ASYNC_DONE:

But only if the users request to unpause.

 

So my error before was really to set :

if(m_paused && !m_user_paused)

The correct value there is just simply

if(!m_user_paused)

It will launch the gst to  playing at the right time and never to early also prevent a deadlock which could happen by the fact that gst was never pased to play state due to some weird issues in live stream which set m_paused to false when it should not.

 

Actually the deadlock which could occur and certain circumstances was really my error and just the cause that we do have a diff between the by me special introduced m_user_paused. Actually I made that parameter cause it is required to differ a user action pause, and any other pause.

 

I should never have used

if(m_paused && !m_user_paused)

Sorry that was a real logical error...

 

Just study base sequencing and interaction between the sinks audio/video,sub and application servicemp3.c

[MastaG]

Well my image for me dm800se last night was created with the original patch from athoik, so without the extra m_user_paused params.

And I can confirm pausing my mkv video with dts audio does not work.

 

I haven't tried christophecvr's pull request yet which has the params.

I may have some time tonight for this.

[Taapat]

@christophecvr I also do not understand why you can not use m_paused.

 

If I compare servicemp3.cpp and changes in your pull reqest, then I see that you to m_user_paused give exactly the same value as m_paused and are doing it exactly in the same places.

In code I can not find a place where m_paused be assigned a different value.

 

Maybe something has been different before, but now, in the latest servicemp3.cpp, I really do not see any difference.

Edited by Taapat, 1 December 2015 - 17:06.

[christophecvr]

Well my image for me dm800se last night was created with the original patch from athoik, so without the extra m_user_paused params.

And I can confirm pausing my mkv video with dts audio does not work.

 

I haven't tried christophecvr's pull request yet which has the params.

I may have some time tonight for this.

Yes read my post above. Actually a very good coding which was there already for almost a year was removed cause they "suspect" never proved the deadlock in some exceptional circumstances could occur.

 

Well the fun (before it put a comment in base enigma2 code when i did a change somewhere now i will never do that anymore as this was abolutely not met to have a personal signature about some changes but looks like some took it that way that wasn't my goal att all ). This time its' helped me since the code was from quit a while and had been tested by a great number off persons before even I presented it to be patched in enigma2. It solved ALL sync issues for filesrc media but actually also for some http media.

 

True is all the test where done with filesrc media. never with internet media (live stream or non live stream but http and or https media).

 

I already saw the prep off this change and saw the possible disaster in wording comming. And yes there its was commit :

 

https://github.com/O...9ffaa6af62c377d

 

did it.

 

The question is in despit the fact  that I marked my work by a short comment of my name. (which I never will do again as i did it to identify a possible error and or bug I introduced by my work with a very short comment off my name but has been taken by some as .... )

 

Well never a single question was asked to me. ???? roughly a revert a some things happened and yes you MastaG did noticed quit fast since you have a good bunch of testers.

 

I see this in a possitif way,

 

First the changes where only for gst-1 and not for the older gst-0.1 but indeed it's actually for both you need it.

Second the weird sometimes deadlock , indeed was caused by that but just what all happened now let my find the cause and its even very logic.

 

So if now my last pull request is done e2 is back to a quit stable gst and the deadlock will not occur anymore.

The reason (and it was even logic) the use off :

			if(m_paused && !m_user_paused)
				gst_element_set_state (m_gst_playbin, GST_STATE_PLAYING);

that must be and is very logic :

			if(!m_user_paused)
				gst_element_set_state (m_gst_playbin, GST_STATE_PLAYING);

By this change the deadlock which could happen before can't happen. But still the base media start will be correct, no video running while correct audio settings are not known yet and have an out off sequence run between video,audio and sub sink.

[christophecvr]

@christophecvr I also do not understand why you can not use m_paused.

 

If I compare servicemp3.cpp and changes in your pull reqest, then I see that you to m_user_paused give exactly the same value as m_paused and are doing it exactly in the same places.

In code I can not find a place where m_paused be assigned a different value.

 

Maybe something has been different before, but now, in the latest servicemp3.cpp, I really do not see any difference.

 

 

Well that's now the general point.

 

First  lets look at the basic start and init of our media player which is here servicemp3.cpp.

 

Very long time the line at init was :

RESULT eServiceMP3::start()
{
	ASSERT(m_state == stIdle);

	if (m_gst_playbin)
	{
		eDebug("[eServiceMP3] starting pipeline");
		GstStateChangeReturn ret;
		ret = gst_element_set_state (m_gst_playbin, GST_STATE_PLAYING);

 That is really wrong and causes the final sinks behind to live there own life at will and cause some weird issues. We need to work async due to the DVB drivers if you need the reason ask pieterg  he's right. However most media at last video/audio and yes even subtitles. Needs to be in a synchronous state when they run.  We achive this to pas the correct initial segment at start. As long all caps,tags and or tocs from a specific media is not known and set we can't allow the launch off gstreamer or the passage to playing before this data is known.

 

That is why we now start at init phase with :

RESULT eServiceMP3::start()
{
	ASSERT(m_state == stIdle);

	if (m_gst_playbin)
	{
		eDebug("[eServiceMP3] starting pipeline");
		GstStateChangeReturn ret;
		ret = gst_element_set_state (m_gst_playbin, GST_STATE_PAUSED);

Then gst does take all info all caps al tags the only and only thing which will not happen is the real play launch.

 

But after all is obtained we end up with  :

 

 

case GST_MESSAGE_ASYNC_DONE:

 

This means we have all required data and settings from the audio/video and sub sink. Including the right start segments and they are set !!!.

 

After some perhaps extra needed settings about the right audio/video and or subt stream are set we launch the gst really to play and yes then it's like a dream all works in perfect sync state.

 

OK then I pause the media,

 

Automaticaly there will be a poll off media settings with all inclusif the actual segment (pts in this case converted to segment) also a new:

case GST_MESSAGE_ASYNC_DONE:

will be used after all media settings included specific video/audio/subtitle tracks have been checked.

In this stage NO we may not relauch the media. For just this case the m_user_paused is made by me.

 

This has been tested for hours but by weeks !! It has been confirmed (but this was now more then a year ago by many many testers)

 

Trough is yes with some live streams a deadlock could occur . But yes the reason is no found : that was

		if(m_paused && !m_user_paused)
				gst_element_set_state (m_gst_playbin, GST_STATE_PLAYING);

If you now start the application , IT STARTS IN PAUSE that's the correct mode and here period end off line.

it will take all and the really needed settings about audio/video and subtitle. This even includes the right start segments.

 

after all is done the msg

GST_MESSAGE_ASYNC_DONE

will come. After that some crucial settings are done based on this msg we will continu and set the gstreamer to playing.

 

But if You pause an automatic poll off the current media happen and msg done will come. however in this state the gst may NOT go to playing .

That now the use off m_user_paused.  In all other cases it must go into playing there and thet was my error adding the m_paused also as this is the reason off the deadlock.

[christophecvr]

@Taapat,

 

Sorry and bloody hell i've got some typo's in previous msg and can't correct them anymore. By some rules the explanation is ok but the typo's make it a bit weird