2520 replies to this topic

[Fischreiher]

Thanks, I see. Imaginge I could convince them to help out in the non-DMM Enigma2 integration, would you be available for some support?

[athoik]

Thanks, I see. Imaginge I could convince them to help out in the non-DMM Enigma2 integration, would you be available for some support?

The (core) GStreamer developers are not tight with Dreambox in any way! It's just Dreambox developers that make use of GStreamer and participating in conferences to say their experiences. It could be any of us if we had something to say in this area.

If GStreamer developer(s) are willing to help and receive hardware of course I can help them in the building proccess of the image.

[Fischreiher]

Thanks a lot, athoik, this is very much appreciated.   I'll contact them and let you know.

[Fischreiher]

Hi athoik, I have sent a request for support to the gstreamer developers mailing list yesterday (see my PM to you).

 

You have mentioned "patches in this forum", I could find some in this thread, and betacentauri noticed some of your recent commits. What is the situation currently, is everything committed now that is required for building experimental images with gstreamer 1.x, or which uncommitted patches are required on top?

[athoik]

Hello Fischreiher,

I hope to receive positive feedback from (core) GStreamer developer(s).

Regarding the patches, yes there was some progress i've collect some of them (at least the ones mandatory to buld without errors) and using a bunch of .bbappend files it is possible to build an image with GStreamer 1.0 only by modifying one file in OpenPLi OE (the one that contains MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS).


In order to be able to build OpenPLi OE with GStreamer 1.0 you need to extract  gstreamer1.0.tar.gz   7.27KB   36 downloads inside meta-local/receipes-local
 

cd meta-local/receipes-local
tar -xzvf gstreamer1.0.tar.gz 

Then we need to modify the MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS and remove gst-plugin-dvbmediasink and change it to gstreamer1.0-plugin-dvbmediasink (example for formuler follows)
 

$ git diff
diff --git a/conf/machine/include/formuler.inc b/conf/machine/include/formuler.inc
index 7577a79..3d1b67f 100644
--- a/conf/machine/include/formuler.inc
+++ b/conf/machine/include/formuler.inc
@@ -18,7 +18,7 @@ MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS = "\
 KERNEL_MODULE_AUTOLOAD = "xfs"

 MACHINE_EXTRA_RRECOMMENDS = " \
-       gst-plugin-dvbmediasink \
+       gstreamer1.0-plugin-dvbmediasink \
        ntfs-3g \
        "

Finally it's time to build your favourite image with GStreamer 1.0 support.
 

MACHINE=XXX make image

I suggest don't try to compile feeds also, there is not need yet, there many issues to solve on core enigma2

Additional information: If you created a custom patch and you want to test it all you have to do is copy the patch inside gstreamer1.0 folder, declare it inside enigma2.bbappend and increase PR to force build.
 

+SRC_URI += "file://another-test.patch"
-PR = "r61"
+PR = "r62"

Happy building

Edited by athoik, 10 October 2014 - 18:02.

[Fischreiher]

Hi Athoik,

 

thank you! Betacentauri has provided an experimental image I could test to get a first impression of gst 1.x. As expected there are issues like winding or rewinding in mkv files not working. Yes, I remember what Erik said in post #114. So maybe the problem was never that gst 0.1 was buggy, but servicemp3.cpp is controlling gst incorrectly, independent of the version.

 

In the meanwhile I have also sent my support request to the Gstreamer team on IRC (freenode / #gstreamer) but didn't get any reply either. Maybe I've been asking too much. However I've seen active chatting on #gstreamer , so maybe if you have specific questions to the developers, posting them there could be worth trying.

[pieterg]

note that we are using gstreamer with hardware decoders (with huge buffers, causing a big delay between demux timestamps and play timestamps).

This will cause the same issues with 1.x as we had with 0.1

At least, I don't expect miracles.

 

servicemp3 and the dvbmediasinks are doing the best they can to glue gstreamer with the hardware decoders, but it won't be perfect.

[Fischreiher]

Thanks for pointing out, I wasn't aware of this challenge. Would software decoding be an option for the 1.3GHz boxes?

[athoik]

No it's a shame to use the few cpu cycles for a/v decoding (probably just audio cause video is just impossible, unless you decode a frame per second ).

Video and audio must use the hardware acceleration all the times!

At them momenth the (serious) problem I am having with GStreamer 1.0 is that I am not receiving GST_MESSAGE_EOS in gstBusCall. Although I created a workarough, but workarounds tend to be permanent (so currently it's only for private use).

With latest published patches the current situation is the following:

Pause/Unpause works great
Subtitles works great (also GST_SUBTITLE_ENCODING="ISO-8859-7" works great for non UTF-8 greek ISO subtitles)
End is not received by GStreamer (GST_MESSAGE_EOS never comes to gstBusCall)
Forward/Rewind doesn't work (it's one of the issues I will have a look at)

Also I didn't test streams yet (rtsp, rtmp, hls, mms, smoothstreaming, dash, etc,etc)

Edited by athoik, 14 October 2014 - 20:48.

[athoik]

Seeking with 1,4,7 and 3,6,9 works great.

[Fischreiher]

I see. Good summary.

 

Maybe forward/rewind needs frame accurate seeking, while when jumping with number keys nobody would notice if the jump ends up at the i-frame nearby? Just today I saw some discussion on IRC #gstreamer where the option GST_SEEK_FLAG_ACCURATE was mentioned:

 

 

[11:01]    heftig    __tim: i'm trying to find out why my seek attempts just result in keyframe seeks even though I seek the playbin using GST_SEEK_FLAG_ACCURATE | GST_SEEK_FLAG_FLUSH
[11:02]    heftig    I *need* frame-accurate seeks, though
[11:44]    heftig    __tim: seems the flvdemux is the problem; with qtdemux I have frame-accurate seeking
[11:44]    heftig    (both containing only a h264 stream)
[11:44]    heftig    with 5-second GOPs, and the flv file is only seekable to 5-second increments
[11:50]    __tim    heftig, it sounds like it just doesn't support ACCURATE
[11:50]    __tim    or does it wrong
[11:50]    __tim    could you file a bug?

Edited by Fischreiher, 15 October 2014 - 12:47.

[mx3L]

Hi,

 

I did some test with gstreamer1.0 on et4x00 and here is what I found out:

 

rtmp vod streams in general:

- playback is working

- seeking is not possible, after seek action, picture just freezes

- streams where video length was not detected in 0.10 version is now detected correctly

 

hls vod streams in general:

- playback is working flawlessly, no hickups after 5 minutes of video playback(this was common issue in some hls vod streams on 0.10)

- seeking is working, no hickups after seek as in 0.10, video position after seek is correctly detected, in 0.10 was position always reseted to zero

- wierd thing is appearing, after initial buffering, few seconds later, gstreamer starts emitting buffering messages, jumping from 0 - 100 through whole playback

Buffering 79 percent done
Buffering 81 percent done
Buffering 82 percent done
Buffering 83 percent done
Buffering 85 percent done
Buffering 88 percent done
Buffering 90 percent done
Buffering 94 percent done
Buffering 97 percent done
gst_element_query_position failed in getPlayPosition
Buffering 100 percent done
gst_element_query_position failed in getPlayPosition
gst_element_query_position failed in getPlayPosition
gst_element_query_position failed in getPlayPosition
gst_element_query_position failed in getPlayPosition
gst_element_query_position failed in getPlayPosition
gst_element_query_position failed in getPlayPosition
gst_element_query_position failed in getPlayPosition
eServiceMP3::GST_STREAM_STATUS_TYPE_CREATE -> setting timeout on souphttpsrc to 30s
gst_element_query_position failed in getPlayPosition
gst_element_query_position failed in getPlayPosition
gst_element_query_position failed in getPlayPosition
gst_element_query_position failed in getPlayPosition
eServiceMP3::GST_STREAM_STATUS_TYPE_CREATE -> setting timeout on souphttpsrc to 30s
eServiceMP3::state transition READY -> PAUSED
eServiceMP3::async-done - 1 video, 1 audio, 0 subtitle
AUDIO STRUCT=audio/mpeg
eServiceMP3::audio stream=0 codec=MPEG-4 AAC language=und
eServiceMP3::state transition PAUSED -> PLAYING
Buffering 8 percent done
Buffering 100 percent done
Buffering 7 percent done
Buffering 100 percent done
Buffering 6 percent done
Buffering 100 percent done
Buffering 6 percent done
Buffering 96 percent done
Buffering 98 percent done
Buffering 100 percent done
Buffering 5 percent done
Buffering 6 percent done
Buffering 100 percent done
Buffering 5 percent done
Buffering 97 percent done
Buffering 98 percent done
Buffering 100 percent done
Buffering 6 percent done
Buffering 7 percent done
Buffering 100 percent done
Buffering 6 percent done
Buffering 100 percent done
Buffering 5 percent done
Buffering 100 percent done
Buffering 3 percent done
Buffering 98 percent done
Buffering 100 percent done
Buffering 5 percent done
Buffering 100 percent done
Buffering 3 percent done
Buffering 100 percent done
Buffering 0 percent done
Buffering 100 percent done
Buffering 1 percent done
Buffering 100 percent done
Buffering 1 percent done
Buffering 100 percent done
Buffering 1 percent done
Buffering 97 percent done
Buffering 100 percent done
Buffering 1 percent done
Buffering 100 percent done
Buffering 1 percent done
Buffering 100 percent done

hds vod streams in general:

- not supported

 

http vod streams in general:

- no issues found yet

 

Then I tested some custom local media files and found out, that playback is not so smooth, top command shows 50%CPU

log from et4x00 gstreamer1.0 :  gst_1.0.log   13.59KB   3 downloads

log from et6x00 gstreamer0.10 :  gst_0.10.log   18.05KB   1 downloads

 

 

Thank you for your great work athoik and others who are participating.
 

[mx3L]

DVBAudioSink is not selected for decoding of mp3, because of incorrect caps. This fixes the issue:

marko@marko-Vostro-1500:~/git/gst-plugin-dvbmediasink$ git diff
diff --git a/gstdvbaudiosink.c b/gstdvbaudiosink.c
index a97b7cc..73c6ec8 100644
--- a/gstdvbaudiosink.c
+++ b/gstdvbaudiosink.c
@@ -96,7 +96,7 @@ static guint gst_dvbaudiosink_signals[LAST_SIGNAL] = { 0 };
 #ifdef HAVE_MP3
 #define MPEGCAPS \
                "audio/mpeg, " \
-               "framed =(boolean) true; "
+               "parsed =(boolean) true; "
 #else
 #define MPEGCAPS \
                "audio/mpeg, " \

cpu load is now around 10%, but it solved problem only partially, reactions are better, but audio is getting out of sync with video

Edited by mx3L, 15 October 2014 - 20:56.

[athoik]

Remove alsasink (mv /usr/lib/gstreamer-1.0/libgstalsa.so /usr/lib/gstreamer-1.0/libgstalsa.sok) and see if that fixes the problem.

[mx3L]

Thanks for the tip.

 

Unfortunately didn't resolve audio-video sync problem.

 

To be precise,

when alsasink is in use - audio stuttering, skipping, video slowing/increasing playback speed, out of sync, slow reactions from RC

when dvbaudiosink is in use - audio is alright, normal reactions from RC, video playback pace is problem, first its like in slow motion while audio is going normal, then after few seconds it catches up with audio by fast forward.

 

Attached Files

•  gst1.0_alsasink_removed.log   13.38KB   4 downloads

[athoik]

Hi,

I've just send an email to sttreamer-devel mailing list asking for help regarding the GST_EVENT_EOS not received by the bus.

http://lists.freedes...ber/049981.html

I hope someone with better knowledge of GStreamer can help us overcome our issues..

[betacentauri]

Athoik I can see in your debug this message:
"got buffer empty from driver!"
So event gst_event_eos was received by dvbaudiosink (see line 792). And it stops the sink (the stop command is not used in 0.10 version of dvbaudiosink). So where is the problem? Gstreamer don't stop?

[athoik]

That is correct, the EOS is received by dvbmediasink but it is never coming on the bus!

Maybe the gst_dvbaudiosink_stop (and other changes) introduced by this commit http://sourceforge.n...2bba00d146623a/ causes the GST_EVENT_EOS not received by the bus.

I will check first without gst_dvbaudiosink_stop..

Edited by athoik, 17 October 2014 - 22:55.

[athoik]

Hello,

Regading the GST_EVENT_EOS not received by the bus a solution is on the way...

Regarding the fast forward, i noticed that after you press ffwd and then pause and again pause it starts to play movie in ffwd. So most probably just another issue in our dvbmediasink.

Edited by athoik, 18 October 2014 - 08:36.

[Fischreiher]

  thank you and good luck!