Jump to content


Photo

Unable to compile gst-1.0 branch


  • Please log in to reply
249 replies to this topic

Re: Unable to compile gst-1.0 branch #161 theparasol

  • Senior Member
  • 4,157 posts

+198
Excellent

Posted 5 February 2014 - 19:29

Have now the exact crashpoint... this crashes some how....

 

http://sourceforge.n...cemp3.cpp#l1546

 

if (gst_iterator_find_custom(children, (GCompareFunc)match_sinktype, &element, (gpointer)"GstDVBAudioSink"))

 

Trying a different approach!


@Camping: ZGemma H.2S, Technisat Multytenne 4-in-1 @Home: Edision Mini 4K, Wave Frontier T55, EMP Centauri EMP DiSEqC 8/1 switch, 4x Inverto Ultra Black single LNB


Re: Unable to compile gst-1.0 branch #162 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 5 February 2014 - 19:45

@theparasol,

Well done! Using your patch there is no GS when watching a movie with subtitles. Alhough the subtitles are not synced yet (but let's fix that later).

Here is another GS.
playing 4097:0:0:0:0:0:0:0:0:0:/media/usb/2/tone24bit.m4a
eServiceMP3::construct!
eServiceMP3::playbin uri=file:///media/usb/2/tone24bit.m4a
eServiceMP3::starting pipeline
gst_element_query_position failed in getPlayPosition
new service started! trying to download cuts!
download failed, no cuesheet interface
resolved to PLAY
gst_element_query_position failed in getPlayPosition
resolved to PLAY
gst_element_query_position failed in getPlayPosition
eServiceMP3::state transition NULL -> READY
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
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
gst_element_query_position failed in getPlayPosition
action ->  MediaPlayerActions prevBouquet
gst_element_query_position failed in getPlayPosition
gst_element_query_position failed in getPlayPosition
[__evUpdatedInfo] title 0 of 0 (24 bit Tone ALAC Test File)
[__evUpdatedInfo] title 0 of 0 (24 bit Tone ALAC Test File)
eServiceMP3::state transition READY -> PAUSED
before subsink
PC: 765fb1d4
00000000 00000001 00000000 00000000
00000001 006172ec 7fa7e108 00000001
272c1348 002184b4 77270000 00000001
00d0c000 00000000 00000000 7fa7dea8
7fa7e108 7fa7e150 7fa7e0b8 770c8160
7fa7e150 7fa7e108 00000001 7fa7e3bc
00001463 765fb1d0 00000000 00000000
00644fa0 7fa7e078 7fa7e2d8 770c819c
-------
getResolvedKey config.plugins.crashlogautosubmit.sendAnonCrashlog failed !! (Typo??)
getResolvedKey config.plugins.crashlogautosubmit.addNetwork failed !! (Typo??)
getResolvedKey config.plugins.crashlogautosubmit.addWlan failed !! (Typo??)
main thread is non-idle! display spinner!
Killed

Attached Files


Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Unable to compile gst-1.0 branch #163 theparasol

  • Senior Member
  • 4,157 posts

+198
Excellent

Posted 5 February 2014 - 20:27

Same crash like mine, it crashes on this

 

if (gst_iterator_find_custom(children, (GCompareFunc)match_sinktype, &element, (gpointer)"GstDVBAudioSink"))

 

And I think something weird must be going on in this function (I have now added some debugging there too!)

 

gint eServiceMP3::match_sinktype(GstElement *element, gpointer type)
{
    eDebug("match_sinktype element1=%s, element2=%s", g_type_name(G_OBJECT_TYPE(element)), (const char*)type);
    return strcmp(g_type_name(G_OBJECT_TYPE(element)), (const char*)type);
}

 

The whole stinking reason this strange construction is in is that someone has hacked around to get the right playposition and to determine if its audio or video source.

I'm very much into stripping it all out again and replace it by something more "Gstreamer" function... there must be something like gst_is_this_audio() and gst_is_this_video()

 

But I'm not very experienced on this matter, perhaps someone else here is and can tell what issues there is and why its done the way its done now?


@Camping: ZGemma H.2S, Technisat Multytenne 4-in-1 @Home: Edision Mini 4K, Wave Frontier T55, EMP Centauri EMP DiSEqC 8/1 switch, 4x Inverto Ultra Black single LNB


Re: Unable to compile gst-1.0 branch #164 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 5 February 2014 - 21:01

Ask GStreamer@IRC, last time they where solve issue with HLS caps immediately. Maybe they can help..
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Unable to compile gst-1.0 branch #165 theparasol

  • Senior Member
  • 4,157 posts

+198
Excellent

Posted 6 February 2014 - 15:28

@All:

 

Right now all my git issues are over and busy with a complete rewriting of the crappy servicemp3, I have too much time to burn since I'm recovering from the flu ;)

 

Its not done that these messages "gst_element_query_position failed in getPlayPosition" appear even if there cant be done a position query at that stage.

Its not done that epg updates are done on objects that dont need epg updates in the first place

Its obvious that over the years it has been extended with all kinds of patches. So back to the drawingboard!

 

- Wipeout of gstreamer < 1.0 -> NO MORE #ifdef constructions as it make sources difficult to read and lead easily to errors.

- Complete implementation of all gstreamer bus messages

- Basis for gstreamer 1.0 (handling of important bus messages, starting, pausing, stopping)

 

At this moment I see it as nice learning project for myself, when I'm happy with the results I'll post a patch so you all can shoot at it :)


@Camping: ZGemma H.2S, Technisat Multytenne 4-in-1 @Home: Edision Mini 4K, Wave Frontier T55, EMP Centauri EMP DiSEqC 8/1 switch, 4x Inverto Ultra Black single LNB


Re: Unable to compile gst-1.0 branch #166 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 6 February 2014 - 16:24

@theparasol,


Please upload your progress in Github, so others can take a look :)

Regarding the GS i hope that i've found a solution. Actually the code that causes problems is almost identical with function gst_bin_get_by_name.

Here is how gst_bin_get_by_name is implemented in latest GStreamer.
/**
 * gst_bin_get_by_name:
 * @bin: a #GstBin
 * @name: the element name to search for
 *
 * Gets the element with the given name from a bin. This
 * function recurses into child bins.
 *
 * Returns NULL if no element with the given name is found in the bin.
 *
 * MT safe.  Caller owns returned reference.
 *
 * Returns: (transfer full): the #GstElement with the given name, or NULL
 */
GstElement *
gst_bin_get_by_name (GstBin * bin, const gchar * name)
{
  GstIterator *children;
  GValue result = { 0, };
  GstElement *element;
  gboolean found;

  g_return_val_if_fail (GST_IS_BIN (bin), NULL);

  GST_CAT_INFO (GST_CAT_PARENTAGE, "[%s]: looking up child element %s",
      GST_ELEMENT_NAME (bin), name);

  children = gst_bin_iterate_recurse (bin);
  found = gst_iterator_find_custom (children,
      (GCompareFunc) compare_name, &result, (gpointer) name);
  gst_iterator_free (children);

  if (found) {
    element = g_value_dup_object (&result);
    g_value_unset (&result);
  } else {
    element = NULL;
  }

  return element;
}

static gint
compare_name (const GValue * velement, const gchar * name)
{
  gint eq;
  GstElement *element = g_value_get_object (velement);

  GST_OBJECT_LOCK (element);
  eq = strcmp (GST_ELEMENT_NAME (element), name);
  GST_OBJECT_UNLOCK (element);

  return eq;
} 
The important part is the function compare_name, it is accepting GValue in the parameters not GstElement.
+#if GST_VERSION_MAJOR < 1
 gint eServiceMP3::match_sinktype(GstElement *element, gpointer type)
 {
 	return strcmp(g_type_name(G_OBJECT_TYPE(element)), (const char*)type);
 }
+#else
+gint eServiceMP3::match_sinktype(const GValue *velement, const gchar *type)
+{
+	GstElement *element = g_value_get_object(velement);
+	return strcmp(g_type_name(G_OBJECT_TYPE(element)), type);
+}
+#endif

+#if GST_VERSION_MAJOR < 1
 	static gint match_sinktype(GstElement *element, gpointer type);
+#else
+	static gint match_sinktype(const GValue *velement, const gchar *type);
+#endif
Here is the patch of above code:
Attached File  2servicemp3.patch.txt   1.38KB   4 downloads

It compiles and hopefully solves the problem (not tested yet, i will test later).

Edited by athoik, 6 February 2014 - 16:25.

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Unable to compile gst-1.0 branch #167 theparasol

  • Senior Member
  • 4,157 posts

+198
Excellent

Posted 6 February 2014 - 16:48

Nice find Athoik!

 

I considered the custom search as too difficult and already replaced the whole search construction with a far more simple approach:

 

if (gst_bin_get_by_name_recurse_up(GST_BIN(m_gst_playbin), "GstDVBAudioSink")){
    audioSink = GST_ELEMENT_CAST(GST_BIN(m_gst_playbin));
}
if (gst_bin_get_by_name_recurse_up(GST_BIN(m_gst_playbin), "GstDVBVideoSink")){
    videoSink = GST_ELEMENT_CAST(GST_BIN(m_gst_playbin));
}

 

Works for all gstreamer versions till now ;)


@Camping: ZGemma H.2S, Technisat Multytenne 4-in-1 @Home: Edision Mini 4K, Wave Frontier T55, EMP Centauri EMP DiSEqC 8/1 switch, 4x Inverto Ultra Black single LNB


Re: Unable to compile gst-1.0 branch #168 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 6 February 2014 - 18:30

Just checked and GS is gone using (mine) above patch. Also the subtitles sync is ok now!

I agree to use gst_bin_get_by_name_recurse_up since it works, it will reduce the code also ;)
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Unable to compile gst-1.0 branch #169 malakudi

  • Senior Member
  • 1,449 posts

+69
Good

Posted 6 February 2014 - 18:55

As I understand most of the functionality is now working? What about mkv with multiple audio tracks and multiple subtitles that have problem with gstreamer 0.10?



Re: Unable to compile gst-1.0 branch #170 betacentauri

  • PLi® Core member
  • 7,185 posts

+323
Excellent

Posted 6 February 2014 - 19:27

I guess the problem is not fixed in 1.2.2, because the bug report is still open: https://bugzilla.gno...g.cgi?id=600648


Xtrend ET-9200, ET-8000, ET-10000, OpenPliPC on Ubuntu 12.04

Re: Unable to compile gst-1.0 branch #171 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 6 February 2014 - 21:32

Some problems are not solved yet on latest GStreamer, but at least having the latest version is easy to report issues (they do not accept issues from old 0.10 version any more).

I found one more issue, using GStreamer 1.2.2 we are not build rtmp any more. In order to solve we can create a file named gstreamer1.0-plugins-bad_1.2.2.bbappend with the following data:
PRINC="1"
DEPENDS += "librtmp"
EXTRA_OECONF := "${@bb.data.getVar('EXTRA_OECONF',d,1).replace('--disable-rtmp', '--enable-rtmp').replace('--disable-dts', '--enable-dts')}"
The above additionally enables dts plugin.

@malakudi, the adventure to GStremer 1.0 just begun, there are many issues to get solved eg dvbmediasink for VU+ and Dreamboxes, issues with caps (caps are more strict in GStreamer 1.0) and many many other...

If we are solving issues and those issues are commited (at least the parts that doesn't break something) i am confident that OpenPLi 5 will switch to GStreamer 1.0 ;)

Edited by athoik, 6 February 2014 - 21:33.

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Unable to compile gst-1.0 branch #172 theparasol

  • Senior Member
  • 4,157 posts

+198
Excellent

Posted 7 February 2014 - 00:48

While working on my project I already discovered that servicemp3 is doing wrong things with the pipeline.

No prerolling, no prerolled -> play  it just play it direct!

And stopping the pipeline is not going to all states, it shuts off directly...

 

Reworking the whole servicemp3 at once is taking a bit longer but I'll see if I can do a quick correct implement of the preroll and stopping of the pipeline.

 

My latest patch to prevent crashing of gstreamer 1.0

 

 

Attached Files


@Camping: ZGemma H.2S, Technisat Multytenne 4-in-1 @Home: Edision Mini 4K, Wave Frontier T55, EMP Centauri EMP DiSEqC 8/1 switch, 4x Inverto Ultra Black single LNB


Re: Unable to compile gst-1.0 branch #173 malakudi

  • Senior Member
  • 1,449 posts

+69
Good

Posted 7 February 2014 - 10:00

Since openpli-4 is now the only mentained version, I guess openpli-5 alpha should include gst-1.x , to allow more people to debug/test it.



Re: Unable to compile gst-1.0 branch #174 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 7 February 2014 - 11:51

Since openpli-4 is now the only mentained version, I guess openpli-5 alpha should include gst-1.x , to allow more people to debug/test it.


That's a nice idea . The only problem is that for some boxes like the et (libxt)some packages are binary's . Compiled to use gst 0.1 . Then we will have to remove them , or look if there is an already gst 1.0 package avbl . It is wel time to move as 0.1 support is stopped. And the longer the more basic codec support is going down for gst 0.1. At this time for standard dvb (tuner)applications , still all needed codecs can be threated with 0.1. They also do run 100% with gst1.0_1.2.2 . But I would not be surprised that in not so long time anymore some Channels will become unusable with a gst 0.1 base . ( no updated codecs more in future) .

Re: Unable to compile gst-1.0 branch #175 theparasol

  • Senior Member
  • 4,157 posts

+198
Excellent

Posted 7 February 2014 - 15:17

in not so long time... actually with uitzendinggemist sbs6 streams the gst 0.1 cant cope already.

 

Perhaps switch troublefree boxes like mine (XP1000) build recipe to gstreamer 1.0 already.

I dont have any near contacts with ET manufacturer, perhaps openpli team members do and could ask for "closed bins" against gstreamer 1.0? 


@Camping: ZGemma H.2S, Technisat Multytenne 4-in-1 @Home: Edision Mini 4K, Wave Frontier T55, EMP Centauri EMP DiSEqC 8/1 switch, 4x Inverto Ultra Black single LNB


Re: Unable to compile gst-1.0 branch #176 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 7 February 2014 - 15:48

Yes that's a nice idea . For the vuduo2 to all basic stuff are running 100 % ok with gst1.0_1.2.2 . I mean with this dvb (tuner) sat hd sd dts andy dolby for all channels.
Recording for all ok playing recorded programs ok even those recorded in old days with a dm 7020.

Playing dvd iso's all ok . All type off audio and subtitle ok.
Mp4 ok ass well.

Only the mp3 did not worked yet , but that's a problem off services.mp3 . And on that you're working. Not home now but when homeg and i do have time i'll try this patch.
If that's ok just also will test other codings like flac , vorbis and wma.

If that's ok as well it will just be a mather to adapt the plugins (which is still big work).

But i was also first waiting on what will till now be inserted into the now current master 's off openpli , enigma2 and plugins . If we now till where it will go . It maybe interesting to create a seperate bitbake branch . For gst- 1.0 as that what is in now is unusable

Re: Unable to compile gst-1.0 branch #177 Sjaaky

  • Senior Member
  • 7,443 posts

+41
Good

Posted 7 February 2014 - 16:03

For your information, servicemp3 has a misleading name. Actually servicemp3 is the only class using gstreamer, so everything requiring gstreamer is played by servicemp3. It is used for everything except dvb and dvd. To be more specific:

watching dvb sat hd sd dts and dolby => no gstreamer
dvd iso's => no gstreamer
watching recordings => gstreamer
mkv, mp4, wmv => gstreamer
mp3, flac, vorbis, wma => gstreamer

Re: Unable to compile gst-1.0 branch #178 theparasol

  • Senior Member
  • 4,157 posts

+198
Excellent

Posted 7 February 2014 - 16:21

I know Sjaaky, it was better if this servicemp3 name changes into something like servicegst

 

Right now doing latest changes to an improved starting/stopping/playing of servicegst.... urhem... I mean servicemp3 ;)


@Camping: ZGemma H.2S, Technisat Multytenne 4-in-1 @Home: Edision Mini 4K, Wave Frontier T55, EMP Centauri EMP DiSEqC 8/1 switch, 4x Inverto Ultra Black single LNB


Re: Unable to compile gst-1.0 branch #179 malakudi

  • Senior Member
  • 1,449 posts

+69
Good

Posted 7 February 2014 - 16:29

@Sjaaky: I think that "watching recordings => gstreamer" is incorrect.


Edited by malakudi, 7 February 2014 - 16:30.


Re: Unable to compile gst-1.0 branch #180 Erik Slagter

  • PLi® Core member
  • 46,960 posts

+541
Excellent

Posted 7 February 2014 - 16:39

@Sjaaky: I think that "watching recordings => gstreamer" is incorrect.

It is, it's recordings like camera recordings (mp4, mov, etc.).

 

DVB is already mentioned above.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
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.



0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users