2520 replies to this topic

[MastaG]

@mx3L

        if (g_object_class_find_property(G_OBJECT_GET_CLASS(source), "ssl-strict") != 0)
        {
            g_object_set(G_OBJECT(source), "ssl-strict", FALSE, NULL);
        }

 

I guess this doesn't work anymore in gstreamer 1.7.x?

[athoik]

GStreamer 1.6.3 is out!

http://gstreamer.freedesktop.org/news/

[littlesat]

What is 1.7....???

[arn354]

1.6.x is stable "branch"

1.7.x is unstable "branch" which will be the next 1.8.x stable "branch"

 

The GStreamer team is pleased to announce the first release of the unstable 1.7 release series. The 1.7 release series is adding new features on top of the 1.0, 1.2, 1.4 and 1.6 series and is part of the API and ABI-stable 1.x release series of the GStreamer multimedia framework. The unstable 1.7 release series will lead to the stable 1.8 release series in the next weeks. Any newly added API can still change until that point.

 

[athoik]

Their experimental version.

1.6 = stable
1.7 = experimental, when stable tag as 1.8
1.8 = stable
1.9 = experimental, when stable tag as 2.0

And so on...

[athoik]

The master-next updated with GStreamer 1.6.3 and some additional patches from upstream.

I know somebody mention before that buffering is not working with GStreamer 1.0.

I can confirm the bug, when buffering enabled the stream is not playing at all or make huge pauses and sometimes never recovers.

 * UNUSED variable from service reference is now used as buffer flag for gstreamer
 * REFTYPE:FLAGS:STYPE:SID:TSID:ONID:NS:PARENT_SID:PARENT_TSID:UNUSED
 *   D  D X X X X X X X X
 * 4097:0:1:0:0:0:0:0:0:0:URL:NAME (no buffering)
 * 4097:0:1:0:0:0:0:0:0:1:URL:NAME (buffering enabled)
 * 4097:0:1:0:0:0:0:0:0:3:URL:NAME (progressive download and buffering enabled)

If you like to test simply set 1 in unused field.

[dazulrich]

GST 1.7.2 unstable is out.... 

 

http://gstreamer.freedesktop.org/news/ 

[malakudi]

I am testing gstreamer 1.6.3 on master-next for various boxes. Can someone report what are the issues on 1.6.x that are fixed on 1.7.x? I would like to test them under 1.6.3 . Thank you

[MastaG]

Hi there,

 

I could need some help here.

In servicemp3.cpp I have the following code to stop a running stream:

RESULT eServiceMP3::stop()
{
        if (!m_gst_playbin || m_state == stStopped)
                return -1;

        eDebug("[eServiceMP3] stop %s", m_ref.path.c_str());
        m_state = stStopped;

        GstStateChangeReturn ret;
        eDebug("[eServiceMP3] Trying to set GST_STATE_NULL using GstStateChangeReturn");
        ret = gst_element_set_state(m_gst_playbin, GST_STATE_NULL);
        eDebug("[eServiceMP3] set_state requested, now checking whether we have reached GST_STATE_NULL");
        if (ret != GST_STATE_CHANGE_SUCCESS)
                eDebug("[eServiceMP3] stop GST_STATE_NULL failure");

        eDebug("[eServiceMP3] Done");
        saveCuesheet();
        m_nownext_timer->stop();

        return 0;
}

 

As you can see, I've applied mx3L's patch for slightly faster iptv-zapping (which will be part of my next release) and also I've wrapped a few debug messages.

 

On my spark receiver I have the following problem (with or without mx3L's patch).

When I stop a running h264 movie (I've tried both raw mp4 and mkv) it will free Enigma2 when it has been playing for over approx 5 minutes.

This happens in both the internal movie player and dreamplex.

 

It always starts playing correctly, like this:

playing 4097:0:0:0:0:0:0:0:0:0:/run/movies/A.Bronx.Tale.1993.720p.x264.AC3-Riding High/A.Bronx.Tale.1993.720p.x264.AC3-Riding High.mkv:A Bronx Tale
[eServiceMP3] construct!
[eServiceMP3] playbin uri=file:///run/movies/A.Bronx.Tale.1993.720p.x264.AC3-Riding%20High/A.Bronx.Tale.1993.720p.x264.AC3-Riding%20High.mkv
[eServiceMP3] subtitle uri: file:///run/movies/A.Bronx.Tale.1993.720p.x264.AC3-Riding%20High/A.Bronx.Tale.1993.720p.x264.AC3-Riding%20High.srt
[eServiceMP3] starting pipeline
[eServiceMP3] state transition NULL -> READY
2
6
3
1
[eDVBDB] getBouquet failed.. no path given!
[eDVBDB] getBouquet failed.. no path given!
resolved to PLAY
RemovePopup, id = ZapError
[eConsoleAppContainer] Starting /usr/bin/grab
2
6
3
1
2
6
3
1
2
6
3
1

** (enigma2:1952): WARNING **: unhandled DVBAPI Video Event 9
[eServiceMP3] state transition READY -> PAUSED
[eServiceMP3] subsink properties set!
[eServiceMP3] loading cuesheet
[eServiceMP3] cutfile not found!
2
6
3
1
[eServiceMP3] async-done - 1 video, 1 audio, 1 subtitle
[eServiceMP3] AUDIO STRUCT=audio/x-ac3
[eServiceMP3] audio stream=0 codec=AC-3 audio language=und
[eServiceMP3] subtitle stream=0 language=und codec=SubRip
[eServiceMP3] getSubtitleType::subtitle probe caps type=text/x-raw
2
6
3
1
[eServiceMP3] switched to subtitle stream 0
2
6
3
1
[eServiceMP3] async-done - 1 video, 1 audio, 1 subtitle
[eServiceMP3] AUDIO STRUCT=audio/x-ac3
[eServiceMP3] audio stream=0 codec=AC-3 audio language=und
[eServiceMP3] subtitle stream=0 language=und codec=SubRip
[eServiceMP3] getSubtitleType::subtitle probe caps type=text/x-raw
2
6
3
1
[eServiceMP3] state transition PAUSED -> PLAYING
[eServiceMP3] async-done - 1 video, 1 audio, 1 subtitle
[eServiceMP3] AUDIO STRUCT=audio/x-ac3
[eServiceMP3] audio stream=0 codec=AC-3 audio language=und
[eServiceMP3] subtitle stream=0 language=und codec=SubRip
[eServiceMP3] getSubtitleType::subtitle probe caps type=text/x-raw
2
6
3
1
2
6
3
1

(enigma2:1952): GStreamer-WARNING **: /media/data2/openpli-oe-core/build/tmp/work/sh4-oe-linux/gstreamer1.0/1.7.2+gitAUTOINC+82e529cea5-r0/git/gst/gstpad.c:4379:gst_pad_push_data:<subparse3:src> Got data flow before segment event

(enigma2:1952): GStreamer-WARNING **: /media/data2/openpli-oe-core/build/tmp/work/sh4-oe-linux/gstreamer1.0/1.7.2+gitAUTOINC+82e529cea5-r0/git/gst/gstpad.c:4126:gst_pad_chain_data_unchecked:<src_0:proxypad59> Got data flow before segment event

(enigma2:1952): GStreamer-WARNING **: /media/data2/openpli-oe-core/build/tmp/work/sh4-oe-linux/gstreamer1.0/1.7.2+gitAUTOINC+82e529cea5-r0/git/gst/gstpad.c:4379:gst_pad_push_data:<decodebin6:src_0> Got data flow before segment event

(enigma2:1952): GStreamer-WARNING **: /media/data2/openpli-oe-core/build/tmp/work/sh4-oe-linux/gstreamer1.0/1.7.2+gitAUTOINC+82e529cea5-r0/git/gst/gstpad.c:4126:gst_pad_chain_data_unchecked:<src_0:proxypad61> Got data flow before segment event

(enigma2:1952): GStreamer-WARNING **: /media/data2/openpli-oe-core/build/tmp/work/sh4-oe-linux/gstreamer1.0/1.7.2+gitAUTOINC+82e529cea5-r0/git/gst/gstpad.c:4379:gst_pad_push_data:<uridecodebin7:src_0> Got data flow before segment event

(enigma2:1952): GStreamer-WARNING **: /media/data2/openpli-oe-core/build/tmp/work/sh4-oe-linux/gstreamer1.0/1.7.2+gitAUTOINC+82e529cea5-r0/git/gst/gstpad.c:4126:gst_pad_chain_data_unchecked:<inputselector9:sink_0> Got data flow before segment event

(enigma2:1952): GStreamer-WARNING **: /media/data2/openpli-oe-core/build/tmp/work/sh4-oe-linux/gstreamer1.0/1.7.2+gitAUTOINC+82e529cea5-r0/git/gst/gstpad.c:4379:gst_pad_push_data:<inputselector9:src> Got data flow before segment event

(enigma2:1952): GStreamer-WARNING **: /media/data2/openpli-oe-core/build/tmp/work/sh4-oe-linux/gstreamer1.0/1.7.2+gitAUTOINC+82e529cea5-r0/git/gst/gstpad.c:4126:gst_pad_chain_data_unchecked:<playsink:text_sink> Got data flow before segment event

(enigma2:1952): GStreamer-WARNING **: /media/data2/openpli-oe-core/build/tmp/work/sh4-oe-linux/gstreamer1.0/1.7.2+gitAUTOINC+82e529cea5-r0/git/gst/gstpad.c:4379:gst_pad_push_data:<text_sink:proxypad62> Got data flow before segment event

(enigma2:1952): GStreamer-WARNING **: /media/data2/openpli-oe-core/build/tmp/work/sh4-oe-linux/gstreamer1.0/1.7.2+gitAUTOINC+82e529cea5-r0/git/gst/gstpad.c:4126:gst_pad_chain_data_unchecked:<streamsynchronizer3:sink_2> Got data flow before segment event

(enigma2:1952): GStreamer-WARNING **: /media/data2/openpli-oe-core/build/tmp/work/sh4-oe-linux/gstreamer1.0/1.7.2+gitAUTOINC+82e529cea5-r0/git/gst/gstpad.c:4379:gst_pad_push_data:<streamsynchronizer3:src_2> Got data flow before segment event

(enigma2:1952): GStreamer-WARNING **: /media/data2/openpli-oe-core/build/tmp/work/sh4-oe-linux/gstreamer1.0/1.7.2+gitAUTOINC+82e529cea5-r0/git/gst/gstpad.c:4126:gst_pad_chain_data_unchecked:<tbin:text_sink> Got data flow before segment event

(enigma2:1952): GStreamer-WARNING **: /media/data2/openpli-oe-core/build/tmp/work/sh4-oe-linux/gstreamer1.0/1.7.2+gitAUTOINC+82e529cea5-r0/git/gst/gstpad.c:4379:gst_pad_push_data:<text_sink:proxypad74> Got data flow before segment event

(enigma2:1952): GStreamer-WARNING **: /media/data2/openpli-oe-core/build/tmp/work/sh4-oe-linux/gstreamer1.0/1.7.2+gitAUTOINC+82e529cea5-r0/git/gst/gstpad.c:4126:gst_pad_chain_data_unchecked:<subqueue:sink> Got data flow before segment event

(enigma2:1952): GStreamer-WARNING **: /media/data2/openpli-oe-core/build/tmp/work/sh4-oe-linux/gstreamer1.0/1.7.2+gitAUTOINC+82e529cea5-r0/git/gst/gstpad.c:4379:gst_pad_push_data:<subqueue:src> Got data flow before segment event

(enigma2:1952): GStreamer-WARNING **: /media/data2/openpli-oe-core/build/tmp/work/sh4-oe-linux/gstreamer1.0/1.7.2+gitAUTOINC+82e529cea5-r0/git/gst/gstpad.c:4126:gst_pad_chain_data_unchecked:<subtitle_sink:sink> Got data flow before segment event
[eServiceMP3] Gstreamer warning : Internal data flow problem. (1) from subtitle_sink
[eServiceMP3] async-done - 1 video, 1 audio, 1 subtitle
[eServiceMP3] AUDIO STRUCT=audio/x-ac3
[eServiceMP3] audio stream=0 codec=AC-3 audio language=und
[eServiceMP3] subtitle stream=0 language=und codec=SubRip
[eServiceMP3] getSubtitleType::subtitle probe caps type=text/x-raw
2
6
3
1
[eServiceMP3] state transition PAUSED -> PLAYING

 

When I stop playing within a few minutes, it stops correctly without feezing.

Like this example:

[eServiceMP3] stop /run/movies/22 Bullets (2010)/22.bullets.2010.720p.BrRip.x264.YIFY.mp4
[eServiceMP3] Trying to set GST_STATE_NULL using GstStateChangeReturn
[eServiceMP3] set_state requested, now checking whether we have reached GST_STATE_NULL
[eServiceMP3] Done
2
6
3
1
[eDVBDB] getBouquet failed.. no path given!
service end!
resolved to PLAY
[gRC] main thread is non-idle! display spinner!
[eServiceMP3] destruct!

 

However this is what happens when the movie has been playing for over 5 minutes:

[eServiceMP3] stop /run/movies/The.Bourne.Supremacy.2004.720p.BluRay.x264-x0r/The.Bourne.Supremacy.2004.720p.BluRay.x264-x0r.mkv
[eServiceMP3] Trying to set GST_STATE_NULL using GstStateChangeReturn
[gRC] main thread is non-idle! display spinner!

I did setup a gdb-environment for testing, but since the cpu load goes up to 150% the debugger will freeze as well.

 

Playing the exact same movie with: gst-launch-1.0 doesn't suffer from this problem.

I've tried multiple times with:

gst-launch-1.0 playbin uri="file:///un/movies/22 Bullets (2010)/22.bullets.2010.720p.BrRip.x264.YIFY.mp4"

And I couldn't reproduce it.

It always cleans up nicely to GST_STATE_NULL when I press CTRL+C

 

Now it used to be working on spark7162, this is something that crept in, in the last 4 or 5 months I guess?

Is there a difference between enigma2 calling: gst_element_set_state(m_gst_playbin, GST_STATE_NULL); and me pressing CTRL + C in the gst-launch-1.0 playbin ?

 

Any help is appreciated

[MastaG]

A small update on the above issue.

After trying a few things to rule out the problem:

- countless modifications to servicemp3.cpp and the dvbmediasink

- switching between taapats and the duckbox drivers

 

I've finally got it fixed by reverting to stable gstreamer 1.6.3 for sh4 (spark/spark7162).

 

So there's probably something wrong gstreamer 1.7.1 (and newer) that only triggers this issue on sh4 when the playbin is called from enigma2.

When enigma2 calls: "gst_element_set_state(m_gst_playbin, GST_STATE_NULL)" gstreamer seems to freeze making enigma2 wait forever.

So basically servicemp3 hangs on that call and doesn't go any further.

 

Gstreamer will try and stop the movie but hangs somewhere.

It doesn't get to the point where the dvbmediasink would do: if (self->fd >= 0) ioctl(self->fd, VIDEO_CLEAR_BUFFER);, thus it will not clear the screen.

The movie just freezes showing only the last frame and servicemp3 keeps waiting with a spinner.

 

I was wrong about the CPU usage of 150%, since that seems always the case on sh4.

 

So it's time to start playing with gdb again to find the freeze in gstreamer 1.7.90 and hopefully I'm able to make a decent bugreport so it gets fixed in time for 1.8.

But for my next build, spark will be on gstreamer 1.6.3 for now

[malakudi]

Unless there are known issues with 1.6.3 (I asked in post #2208 but nobody answered), it is better to use it instead of development release. I haven't found any issue with 1.6.3 on the STBs I have tested.

[MastaG]

I agree with you.

But testing development releases now and then would be a good way of telling whether the upcoming 1.8 release will work on our dvb receivers.

The gstreamer developers will not fix things for our use-cases if we don't report things.

 

Also there's many improvements for playing Apple HLS streams in 1.7.1 and upwards.

Many fragmented streams which would lose audio or stop completely will play correctly in 1.7.90.

I've had many m3u8 streams thrown at me for testing, so I guess IPTV is becoming more important lately.

 

Apart from some third-party addons (like Albatros), I haven't had any bug-reports of streams breaking/crashing on gstreamer 1.7.x for mipsel receivers.

For the record, I've attempted the same tests playing my video's on various other receivers like the old DM800HD and I couldn't reproduce the freeze on stopping streams.

So my problem only concerns gstreamer 1.7.x on sh4 receivers.

 

I hope to find the spot where it crashes using gdb and make a decent bug-report about it.

Time is always against me

[gorski]

Don't get me wrong, m8, you know I like your efforts - but I have to tell you this: it seems to me that forcing newest Gstreamer into these old and weak machines is a wee bit of a miss... I think that functioning (at all), then stability and speed should be priority, as in being able to prove that something really is functioning....

 

Newest releases should be tested privately, to my mind, then reported to the devs... From then on patience would be a virtue, before including new developments into the older platforms... Really, it would save you a lot of headache and time, also! I fear that both you and users testing your images may be wasting a lot of your/their good will, time and energy for very little gain, so to speak. Moreover, Gstreamer in Alien1/2 possibly has no place...

 

Best of luck!

[MastaG]

Thank you gorski,

 

I guess I'm pushing a bit too hard on these sh4 receivers.

Especially with zero programming skills.

However I do hope to find the cause for my videos freezing when trying to stop them (some day).

 

Niet omdat het moet, maar omdat het kan

[gorski]

If you can, OK... but my suggestion was kinda well-intended and practical... I mean, if you have difficulties, then maybe, just maybe it would be better not to do that in public...

 

Does the problem exist in Taapat's version? If not, what's the difference?

 

Have you tried only Eplayer E2 version?

 

[MastaG]

I get your point

 

I'm using Taapat's enigma2 (with minor patches for the spark7162 and backports from PLii's e2).

Also I'm using mostly his oe-core recipes for spark/spark7162.

 

But yes, I've tried both his drivers and the ones from duckbox (which are way slower btw) and both show the same issue when trying to stop a video.

So it's definitely a problem in gstreamer itself on sh4.

 

Regarding eplayer, I've adapted all of his hard work into my tree as well.

So my eplayer builds are basically the same as his. (now using the latest ffmpeg 3.0).

I've only tested my last eplayer build which had ffmpeg 2.8.6.

I found it working great except for the fact that it doesn't automatically enable playback of external subtitles (having to enter the audio -> subtitle selection screen everytime).

Apart from that, I found no issues at all during my quick tests.

[gorski]

Cool, good to know.

 

Kick out Gstreamer from Aliens and we'll have fun...

[mx3L]

Hello,

My et6x00 revived, so I did some testing with recent gstreamer version 1.6.3.

 

I found problem with seeking in some mp4 files:

 

After seeking is done, decoder is frozen, i.e no rendering is done, but when I do pause/unpause playback normally continues.

 

Problem starts to occur with my recent commit to dvbmediasink - https://github.com/O...73f649c74ca734c

When we send segment event back to basesink, basesink stores this segment and starts dropping buffers which don't belong to this segment.

There is nothing wrong with, but as I found out freeze occurs when non-keyframe buffer is written to video device, without writing keyframe buffer first.

 

We are doing keyframe seeking(i.e we are using flag GST_FLAG_KEY_UNIT). From gstreamer docs this should happen:

 

 

Summary:
...
 - if the KEY_UNIT flag is specified, the demuxer/parser should start
   pushing data from the key unit nearest the seek position (or from
   the seek position if that falls on a key unit), and
   the start of the new segment should be adjusted to the position of
   that key unit which was nearest the requested seek position (ie.
   the new segment start should be the position from which data is
   pushed).
 

 

So this should be be TRUE after seeking is done: (segment_start == start_time(first_buffer_after_seek) && is_keyframe(first_buffer_after_seek)).

 

But unfortunately with above file the situation after seeking is like this:

1. (segment_start > start_time(first_buffer_after_seek) && is_keyframe(first_buffer_after_seek))

 

So basesink drops buffers not in segment and once buffer is in segment(in my mp4 non-keyframe) it is written, which causes decoder to freeze:

2. (segment_start <= start_time(first_buffer_after_seek) && !is_keyframe(first_buffer_after_seek))

 

AFAIK, decoder expects first buffer to be keyframe buffer so it can reconstruct from it non-keyframe buffers, so best behaviour for decoder should be to drop non-keyframe buffers, if key-frame buffer was not written yet.

For example this looks like to be done in vusolose decoder, where seeking works with this file without problem.

 

 

For now I see these options:

 

1. revert my commit, this will fix the problem since first frame is always keyframe, however segment start can be far of from first rendered buffer.

Why to care about segment start time, why not just write everything as it comes?

 

We have to take into account also audio decoder. For example without dropping out of segment buffers following situation occurs after seeking:

0:00:05.349813925  5297   0x4ba950 DEBUG           dvbvideosink gstdvbvideosink.c:536:gst_dvbvideosink_event:<dvbvideosink0> configured segment time segment start=0:04:07.040000000, offset=0:00:00.000000000, stop=0:06:19.560000000, rate=1.000000, applied_rate=1.000000, flags=0x01, time=0:04:06.880000000, base=0:00:00.000000000, position 0:04:07.040000000, duration 99:99:99.999999999
0:00:05.395594740  5297   0x4ba950 DEBUG           dvbvideosink gstdvbvideosink.c:773:gst_dvbvideosink_render:<dvbvideosink0> pts: 0:04:01.400000000, dts: 0:04:01.240000000
...
0:00:05.474820518  5297   0x4baac0 DEBUG           dvbaudiosink gstdvbaudiosink.c:914:gst_dvbaudiosink_event:<dvbaudiosink0> configured segment time segment start=0:04:06.880000000, offset=0:00:00.000000000, stop=0:06:19.396187500, rate=1.000000, applied_rate=1.000000, flags=0x01, time=0:04:06.880000000, base=0:00:00.000000000, position 0:04:06.880000000, duration 99:99:99.999999999
0:00:05.476547333  5297   0x4baac0 DEBUG           dvbaudiosink gstdvbaudiosink.c:1316:gst_dvbaudiosink_render:<dvbaudiosink0> pts: 0:04:06.874479166, dts: 0:04:06.874479166

This is log done after seeking, it's clear that we are writing video from 4:01 time, while audio from 4:06 time, so we have at least 5 seconds of only video playback without sound.

 

If we drop out of segment buffers than we start write video/audio very close to each other so there is immediately video with sound:

0:00:04.668972480  5330   0x4ba950 DEBUG           dvbvideosink gstdvbvideosink.c:536:gst_dvbvideosink_event:<dvbvideosink0> configured segment time segment start=0:04:07.040000000, offset=0:00:00.000000000, stop=0:06:19.560000000, rate=1.000000, applied_rate=1.000000, flags=0x01, time=0:04:06.880000000, base=0:00:00.000000000, position 0:04:07.040000000, duration 99:99:99.999999999
0:00:04.760231851  5330   0x4ba950 DEBUG           dvbvideosink gstdvbvideosink.c:772:gst_dvbvideosink_render:<dvbvideosink0> pts: 0:04:07.080000000, dts: 0:04:06.880000000
...
0:00:04.766059221  5330   0x4baac0 DEBUG           dvbaudiosink gstdvbaudiosink.c:914:gst_dvbaudiosink_event:<dvbaudiosink0> configured segment time segment start=0:04:06.880000000, offset=0:00:00.000000000, stop=0:06:19.396187500, rate=1.000000, applied_rate=1.000000, flags=0x01, time=0:04:06.880000000, base=0:00:00.000000000, position 0:04:06.880000000, duration 99:99:99.999999999
0:00:04.770749295  5330   0x4baac0 DEBUG           dvbaudiosink gstdvbaudiosink.c:1315:gst_dvbaudiosink_render:<dvbaudiosink0> pts: 0:04:06.895812500, dts: 0:04:06.895812500

So I don't think we should revert this one, since with this patch we have faster A/V sync after seeking.

 

2. drop non-keyframe buffers after flush until there is keyframe buffer. I have currently done this and looks to be working without problem.

3. solve the problem upstream, i.e find out why segment start != start_time(first_buffer_after_seek) after doing keyframe seeking

 

test patch for 2. solution:

https://gist.github....375bffdc4052819

 

sample:

https://dl.dropboxus...seek_freeze.mp4

 

It would be great if somebody could test seeking in this file also on other receivers, if it causes you the same problem.

[MastaG]

mx3L great to see you again

If you like I can adapt the patch for my next round of testing images.

[mx3L]

Hi, sure at least more people will test it.