2520 replies to this topic

[MastaG]

@MastaG

I'll revert both commits but I think its chris' commit since mx3L posted his commit (the one changing "if (validposition)") a while ago in a private thread, so I was using that one already for a long time.

I very very severe error was present  on :

 

 enigma2 till version commit  :

 

https://github.com/O...6996c5dcb6514c5

 

After this commit (the already existent a/v sync issue on duo2 became from sometimes till very pronounced ) After all pretty logic. Since the user demanded media pause state , we do have a code which after the user does a change or demand ,

after this gstreamer will be set in play state and very quick back to pause state this all to have a enigma2 state update . Very nice but wrong. Ok agree enigma2 needs a state update in media paused situation but lauching gstreamer and stop it even before all required sequences into all gstreamer elements are done is wrong. This wrong issue is solved with commit :

https://github.com/O...eddb203b264c627

 

But after this change ok we do have the gst in a/v sequence. But actually better code would be to have e2 update in pause without the start and stop of gstreamer since gstreamer has all ellements up to date and they follow the new changes inclusif the new pts. e2 not but actually we must bring e2 to the state of gstreamer .

 

You're right my friend.

Sorry for not testing it first.

The pull request is not to blame.. must be something recently added to gstreamer git (I'm updating the srcrev's everyday of all the components)...

I'll find it out myself and report back my findings.

 

Again my apologies.

[christophecvr]

The gstreamer recipes are ok. But do not use any patch for servicemp3. The last e2 has all in.

[MastaG]

I'm using two patches for servicemp3.cpp that's not upstream.

But I've reverted them both and they were not the problem.

blocksize.patch: by athoik for increasing the gstreamer buffer a bit:

--- enigma2/lib/service/servicemp3.cpp.orig    2016-04-24 14:54:24.655863532 +0200
+++ enigma2/lib/service/servicemp3.cpp    2016-04-26 09:00:17.527947795 +0200
@@ -2315,6 +2315,11 @@
                 }
             }
         }
+        if (g_object_class_find_property(G_OBJECT_GET_CLASS(source), "blocksize") != 0)
+        {
+            /* default blocksize is only 4096 we need to feed hardware decoder with more data */
+            g_object_set(G_OBJECT(source), "blocksize", 16*1024, NULL);
+        }
         if (g_object_class_find_property(G_OBJECT_GET_CLASS(source), "ssl-strict") != 0)
         {
             g_object_set(G_OBJECT(source), "ssl-strict", FALSE, NULL);

 

servicemp3_faster_zap.patch: by mx3L for faster iptv zapping.

diff --git a/lib/service/servicemp3.cpp b/lib/service/servicemp3.cpp
index 7559042..fd59b62 100644
--- a/lib/service/servicemp3.cpp
+++ b/lib/service/servicemp3.cpp
@@ -782,14 +782,6 @@ RESULT eServiceMP3::stop()
    m_state = stStopped;

    GstStateChangeReturn ret;
-    GstState state, pending;
-    /* make sure that last state change was successfull */
-    ret = gst_element_get_state(m_gst_playbin, &state, &pending, 5 * GST_SECOND);
-    eDebug("[eServiceMP3] stop state:%s pending:%s ret:%s",
-        gst_element_state_get_name(state),
-        gst_element_state_get_name(pending),
-        gst_element_state_change_return_get_name(ret));
-
    ret = gst_element_set_state(m_gst_playbin, GST_STATE_NULL);
    if (ret != GST_STATE_CHANGE_SUCCESS)
        eDebug("[eServiceMP3] stop GST_STATE_NULL failure");

 

But I reverted them both and they were not to blame.

 

Anyways I was still applying some old patches against plugins-base, good and bad which I've reverted.

Now the gstreamer recipes are 100% like yours.

It's building now which will take while since I have to push it to the feeds as well.

I'll report back asap.

 

Thank you for your time gentlemen.

[MastaG]

So anyways.. the segfault wasn't related to enigma2- or gstreamer patches at all.

After reverting back to the gstreamer SRCREV's  used in chris's github recipes the segfault is gone.

So be prepared to face something ugly when upgrading to a newer gstreamer snapshot

[christophecvr]

So anyways.. the segfault wasn't related to enigma2- or gstreamer patches at all.

After reverting back to the gstreamer SRCREV's  used in chris's github recipes the segfault is gone.

So be prepared to face something ugly when upgrading to a newer gstreamer snapshot

Seg fault is indeed gstreamer .

 

The culprit commit is :

https://cgit.freedes...a39ff47d538fa68

 

I filed a bug report :

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

 

Further my recipes for gst-1.9.0.1 are updated but do contain a new patch wich revert the commit as long the error in the code which cause a seg fault on a stb can't be found.

https://github.com/c...1aac4278a16e897

[MastaG]

great job chris!

 

 

On a side note, the segfault only happens on mips32el (softfloat and hardfloat), on sh4 there is no such segfault.

Edited by MastaG, 29 April 2016 - 08:11.

[christophecvr]

great job chris!

 

 

On a side note, the segfault only happens on mips32el (softfloat and hardfloat), on sh4 there is no such segfault.

wich sink are you using on sh4 ?

and are there some extra patches to servicemp3 for sh 4 ?

[MastaG]

I'm using your experimental branch (you merged sh4 support a while ago remember), with a small patch from oe-alliance:

https://github.com/o...sh4-boxes.patch

 

No extra servicemp3.cpp patches at all.

 

Only difference is that sh4 uses gcc-4.8 instead of 4.9 (I'm still building PLi-4).

[christophecvr]

I'm using your experimental branch (you merged sh4 support a while ago remember), with a small patch from oe-alliance:

https://github.com/o...sh4-boxes.patch

 

No extra servicemp3.cpp patches at all.

 

Only difference is that sh4 uses gcc-4.8 instead of 4.9 (I'm still building PLi-4).

Ter info You do not use spark  define anymore then since spark is also sh4 anyway ?

[MastaG]

yes, I see you've adapted the patch from oe-alliance.

Thank you!

Simply _sh_ should be sufficient for all sh4 receivers (fulan family such as spark).

[MastaG]

After upgrading to gstreamer 1.8 and later I have this problem on my spark7162 receiver where adaptive hls streams (m3u8) seem to skip very badly.

 

gst-launch-1.0 playbin uri="http://cdn.djing.com/tv/a-05.m3u8" buffer-size="-1"
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
WARNING: from element /GstPlayBin:playbin0/GstPlaySink:playsink: No volume control found
Additional debug info:
/media/data2/openpli-oe-core/build/tmp/work/sh4-oe-linux/gstreamer1.0-plugins-base/1.9.0.1+gitAUTOINC+base-r7/git/gst/playback/gstplaysink.c(2857): gen_audio_chain (): /GstPlayBin:playbin0/GstPlaySink:playsink:
Volume/mute is not available
buffering... 41%  
(gst-launch-1.0:1541): GStreamer-CRITICAL **: gst_mini_object_ref: assertion 'mini_object != NULL' failed

(gst-launch-1.0:1541): GStreamer-CRITICAL **: gst_caps_merge: assertion 'GST_IS_CAPS (caps2)' failed
Prerolled, waiting for buffering to finish...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock

** (gst-launch-1.0:1541): WARNING **: unhandled DVBAPI Video Event 9

** (gst-launch-1.0:1541): WARNING **: unhandled DVBAPI Video Event 5

 

Strange thing if I play it trough samsamsam's gstplayer_gst-1.0 it seems to play flawlessly.

Could it be in the dvbmediasink?

[christophecvr]

When I play this stream on dm 8000 all runs fine

#SERVICE 4097:0:1:0:0:0:0:0:0:0:http%3a//cdn.djing.com/tv/a-05.m3u8:DJING 2 mastag
#DESCRIPTION DJING 2 mastag

Attached Files

•  oklog.txt   9.91KB   2 downloads

Edited by christophecvr, 30 April 2016 - 13:38.

[MastaG]

Yeah, same here on all of my mips receivers.
It's just my spark7162 receiver thats heavily skipping and freezing on hls streams.

Normal mkv + srt plays fine.

Maybe the hls fix which is applied to plugins-bad is not fully compatible with sh4?
Because using your sink with gstreamer 1.6.3 I have no issues.
I'll try playing forced async mode.

[christophecvr]

Yeah, same here on all of my mips receivers.
It's just my spark7162 receiver thats heavily skipping and freezing on hls streams.

Normal mkv + srt plays fine.

Maybe the hls fix which is applied to plugins-bad is not fully compatible with sh4?
Because using your sink with gstreamer 1.6.3 I have no issues.
I'll try playing forced async mode.

It could be they are working on adaptif streaming and m3u8 is that.

 

p. s. there is in the mean time a better patch I'll put an update on the gstreamer reciepes.

[christophecvr]

@MastaG & @all self builders

 

I just added a change into servicemp3. Now when paused the actions like audio stream change and or chapter jups by mkv who have chapters (chapter support is only avbl with gst-1.0 since mkv demuxer gst-0.10 does not have toc support) But audio support is off course well avbl by gst-0.10.

 

here the patch to servicemp3.

Attached Files

•  E2-paused-state-update-without-gst-state-change.patch   3.16KB   20 downloads

Edited by christophecvr, 4 May 2016 - 22:21.

[MastaG]

I'm going to stop my build and restart with this patch included

[christophecvr]

I just have a question,

 

Is there any box who does support fast seeking backwards ?

 

My two boxes do not (at last not with ioctl and negatif rate) On the vuplus it even caused a deadlock some media trying to use fast backwards. If there is not any stb which supports that, then it's best to change the code that such an action is not possible.

[betacentauri]

Fast rewind will afaik not work.
Old Linux DVB api only has fast forward ioctl: http://linuxtv.org/d..._function_calls
And if you cannot tell the box that the video should be displayed in reverse order it won't work.

With mentioned v4l api it should work:
https://linuxtv.org/...ecoder-cmd.html
I tested it some time ago and it didn't work. I think I have tested it on a xtrend box. But I also don't believe that other boxes support this.

[christophecvr]

Ter info gstreamer recipes for 1.9.0.1 updated to today 2013-05-05 all ok.

 

https://github.com/c...TREAMER-RECIPES

[christophecvr]

Fast rewind will afaik not work.
Old Linux DVB api only has fast forward ioctl: http://linuxtv.org/d..._function_calls
And if you cannot tell the box that the video should be displayed in reverse order it won't work.

With mentioned v4l api it should work:
https://linuxtv.org/...ecoder-cmd.html
I tested it some time ago and it didn't work. I think I have tested it on a xtrend box. But I also don't believe that other boxes support this.

Yes if we could use the new api it would be much better.

 

I already saw one very promissing things is for example the :

 

 

V4L2_DEC_CMD_START 0 Start the decoder. When the decoder is already running or paused, this command will just change the playback speed. That means that calling V4L2_DEC_CMD_START when the decoder was paused will not resume the decoder. You have to explicitly call V4L2_DEC_CMD_RESUME for that. This command has one flag: V4L2_DEC_CMD_START_MUTE_AUDIO. If set, then audio will be muted when playing back at a non-standard speed

 

That should allow us to use the new implemented (as from gst 1.6) trick seek without audio.