Jump to content


Photo

ET9200 problems with mp4 playback

ET9200

  • Please log in to reply
32 replies to this topic

Re: ET9200 problems with mp4 playback #21 nietgiftig

  • Senior Member
  • 787 posts

+39
Good

Posted 20 June 2014 - 14:15

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


 Hardware: Master VU Uno 4K SE  1x Mut@nt HD51.4K & 2x ZgemmaH9T
Software : Pli (v7) (7.1rc) 2019 


Re: ET9200 problems with mp4 playback #22 Erik Slagter

  • PLi® Core member
  • 45,366 posts

+499
Excellent

Posted 20 June 2014 - 14:24

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


* Wavefrontier T90 with 28E/23E/19E/13E/9E/4.8E/0.8W/5W via SCR switches 2 x 2 x 6 user bands
* Ziggo digital cable TV (FTA)
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: ET9200 problems with mp4 playback #23 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 15 March 2015 - 12:34

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.

 



Re: ET9200 problems with mp4 playback #24 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 15 March 2015 - 13:29

-


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


Re: ET9200 problems with mp4 playback #25 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 15 March 2015 - 13:30

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

 

added patch

 

Attached Files


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


Re: ET9200 problems with mp4 playback #26 sonci

  • Senior Member
  • 26 posts

0
Neutral

Posted 15 March 2015 - 13:46

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?



Re: ET9200 problems with mp4 playback #27 betacentauri

  • PLi® Core member
  • 5,596 posts

+254
Excellent

Posted 15 March 2015 - 15:48

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

Thanks mx3L!
Xtrend ET-9200, ET-8000, ET-10000, OpenPliPC on Ubuntu 12.04

Re: ET9200 problems with mp4 playback #28 Erik Slagter

  • PLi® Core member
  • 45,366 posts

+499
Excellent

Posted 15 March 2015 - 17:33

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.


* Wavefrontier T90 with 28E/23E/19E/13E/9E/4.8E/0.8W/5W via SCR switches 2 x 2 x 6 user bands
* Ziggo digital cable TV (FTA)
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: ET9200 problems with mp4 playback #29 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 15 March 2015 - 19:23

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.



Re: ET9200 problems with mp4 playback #30 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 17 March 2015 - 07:43

In attachment is split previous patch with more detailed explanation.

 



Re: ET9200 problems with mp4 playback #31 Erik Slagter

  • PLi® Core member
  • 45,366 posts

+499
Excellent

Posted 18 March 2015 - 18:28

Please someone test on VU+.
* Wavefrontier T90 with 28E/23E/19E/13E/9E/4.8E/0.8W/5W via SCR switches 2 x 2 x 6 user bands
* Ziggo digital cable TV (FTA)
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: ET9200 problems with mp4 playback #32 sonci

  • Senior Member
  • 26 posts

0
Neutral

Posted 20 March 2015 - 14:23

Please someone test on VU+.

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



Re: ET9200 problems with mp4 playback #33 Erik Slagter

  • PLi® Core member
  • 45,366 posts

+499
Excellent

Posted 20 March 2015 - 14:55

Nobody developing has a VU+ receiver?


* Wavefrontier T90 with 28E/23E/19E/13E/9E/4.8E/0.8W/5W via SCR switches 2 x 2 x 6 user bands
* Ziggo digital cable TV (FTA)
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.





Also tagged with one or more of these keywords: ET9200

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users