32 replies to this topic

[nietgiftig]

@mx3L

Big Thanks for the solution

 

@atilaks

Thanks for the zip

Solution seems to work fine

Tested a few files

 

@Erik Slagter

Thanks for the merge

 

Now I can play almost all files, except some obscure one's.

[Erik Slagter]

I think all credits should go to mx3L, merging isn't much effort

[mx3L]

Suggestion to improve unpause performance:

diff --git a/lib/service/servicemp3.cpp b/lib/service/servicemp3.cpp
index 59237bc..48fb8e4 100644
--- a/lib/service/servicemp3.cpp
+++ b/lib/service/servicemp3.cpp
@@ -467,8 +467,10 @@ eServiceMP3::eServiceMP3(eServiceReference ref):
 		m_sourceinfo.is_video = TRUE;
 	}
 	if ( strstr(filename, "://") )
+	{
 		m_sourceinfo.is_streaming = TRUE;
-
+		m_sourceinfo.protocol = m_ref.path.substr(0, m_ref.path.find("://"));
+	}
 	gchar *uri;
 
 	if ( m_sourceinfo.is_streaming )
@@ -861,7 +863,6 @@ RESULT eServiceMP3::trickSeek(gdouble ratio)
 		return 0;
 	}
 
-	m_currentTrickRatio = ratio;
 
 	bool validposition = false;
 	gint64 pos = 0;
@@ -876,7 +877,28 @@ RESULT eServiceMP3::trickSeek(gdouble ratio)
 
 	if (validposition)
 	{
-		if (ratio >= 0.0)
+		if (m_currentTrickRatio == 1.0 && ratio == 1.0)
+		{
+#if GST_VERSION_MAJOR >= 1
+			if ( !m_sourceinfo.is_streaming || (strcasecmp(m_sourceinfo.protocol.c_str(), "http") && strcasecmp(m_sourceinfo.protocol.c_str(), "https") ) == 0)
+#else
+			if ( !m_sourceinfo.is_streaming )
+#endif
+			{
+					eDebug("eServiceMP3::trickSeek - standard unpause");
+					if ( !(gst_element_get_state(m_gst_playbin, NULL, NULL, 100LL * GST_MSECOND) == GST_STATE_CHANGE_SUCCESS) )
+					{
+						eDebug("eServiceMP3:trickSeek - standard unpause was not successfull, doing seeking unpause");
+						gst_element_seek(m_gst_playbin, ratio, GST_FORMAT_TIME, (GstSeekFlags)(GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_KEY_UNIT), GST_SEEK_TYPE_SET, pos, GST_SEEK_TYPE_SET, -1);
+					}
+			}
+			else
+			{
+				eDebug("eServiceMP3::trickSeek - seeking unpause");
+				gst_element_seek(m_gst_playbin, ratio, GST_FORMAT_TIME, (GstSeekFlags)(GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_KEY_UNIT), GST_SEEK_TYPE_SET, pos, GST_SEEK_TYPE_SET, -1);
+			}
+		}
+		else if (ratio >= 0.0)
 		{
 			gst_element_seek(m_gst_playbin, ratio, GST_FORMAT_TIME, (GstSeekFlags)(GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_SKIP), GST_SEEK_TYPE_SET, pos, GST_SEEK_TYPE_SET, -1);
 		}
@@ -886,7 +908,7 @@ RESULT eServiceMP3::trickSeek(gdouble ratio)
 			gst_element_seek(m_gst_playbin, ratio, GST_FORMAT_TIME, (GstSeekFlags)(GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_SKIP), GST_SEEK_TYPE_SET, 0, GST_SEEK_TYPE_SET, pos);
 		}
 	}
-
+	m_currentTrickRatio = ratio;
 	m_prev_decoder_time = -1;
 	m_decoder_time_valid_state = 0;
 	return 0;
diff --git a/lib/service/servicemp3.h b/lib/service/servicemp3.h
index b3a685e..ab793e4 100644
--- a/lib/service/servicemp3.h
+++ b/lib/service/servicemp3.h
@@ -202,6 +202,7 @@ public:
 		containertype_t containertype;
 		bool is_video;
 		bool is_streaming;
+		std::string protocol;
 		sourceStream()
 			:audiotype(atUnknown), containertype(ctNone), is_video(FALSE), is_streaming(FALSE)
 		{

1. We are doing unpause by seeking to current position.

- this is unnecessary thing to do for local (on GST1.0 also for http[s] streams), since we don't timeout on local streams(on GST1.0 souphttpsrc will not timeout - https://bugzilla.gno...g.cgi?id=683536)

- sometimes state change didn't happen in standard unpause, so then it will fallback to seeking unpause.

 

2. We are doing unpausing by default seeking(not keyframe seeking)

- this is also unneccesary, we can do keyframe seeking instead, since we are doing it already but with overhead caused by looking for segment offset, which we are ignoring in our sinks:

1. DEFAULT BEHAVIOUR:

When a seek to a certain position is requested, the demuxer/parser will
do two things (ignoring flushing and segment seeks, and simplified for
illustration purposes):

 - send a segment event with a new start position

 - start pushing data/buffers again

To ensure that the data corresponding to the requested seek position
can actually be decoded, a demuxer or parser needs to start pushing data
from a keyframe/keyunit at or before the requested seek position.

Unless requested differently (via the KEY_UNIT flag), the start of the
segment event should be the requested seek position.

So by default a demuxer/parser will then start pushing data from
position DATA and send a segment event with start position SEG_START,
and DATA <= SEG_START.

If DATA < SEG_START, a well-behaved video decoder will start decoding frames
from DATA, but take into account the segment configured by the demuxer via
the segment event, and only actually output decoded video frames from
SEG_START onwards, dropping all decoded frames that are before the
segment start and adjusting the timestamp/duration of the buffer that
overlaps the segment start ("clipping"). A not-so-well-behaved video decoder
will start decoding frames from DATA and push decoded video frames out
starting from position DATA, in which case the frames that are before
the configured segment start will usually be dropped/clipped downstream
(e.g. by the video sink).

 

- http://cgit.freedesk...art-seeking.txt

 

So what's added value:

 

1. faster unpause, starting with same frame as in pause mode

1. unpausing will now work on some mp4, which didn't work before(big gops?)

2. added possibility to prefill buffer in default buffering mode for http(s) streams, by pause - > wait to 100% buffer - > unpause, since buffer will be not dropped by seeking event

 

Tested on gstreamer1.0.

 

[mx3L]

-

Edited by mx3L, 15 March 2015 - 13:30.

[mx3L]

In previous post replace "segment offset" with "segment start"

 

added patch

 

Attached Files

•  0001-servicemp3-use-unpause-by-kf-seeking-only-when-neces.patch   3.32KB   2 downloads

Edited by mx3L, 15 March 2015 - 13:31.

[sonci]

In previous post replace "segment offset" with "segment start"

 

added patch

I had the same problem in my Vu solo with OpenPli 4.0, can I apply this patch,

sorry for the ignorance but how to do it?

[betacentauri]

Only developer can do that. Please wait until patch is merged to PLi sources (which can take some days).

Thanks mx3L!

[Erik Slagter]

Did some of you test this? I know this is a hairy subject, pausing/trickle mode/unpausing, it can break very easily (which it did various times in the past). Also it can work on one brand and totally break another.

[mx3L]

Tested on et4000 and et6500 with gstreamer1.0, so far there are no issues, would be great if somebody could test also on other recievers.

[mx3L]

In attachment is split previous patch with more detailed explanation.

 

Attached Files

•  0001-servicemp3-add-protocol-info-about-stream.patch   1.18KB   5 downloads
•  0002-servicemp3-use-unpause-by-kf-seeking-only-when-neces.patch   3.16KB   5 downloads

[Erik Slagter]

Please someone test on VU+.

[sonci]

Please someone test on VU+.

I have a vu solo, just tell me how to patch..

[Erik Slagter]

Nobody developing has a VU+ receiver?