2520 replies to this topic

[athoik]

@athoik
I'm still on 1.4.5, and there are no issues:

Then it is quite possible that something was changed on the HEAD that causes that issue.

Anyone else updated on HEAD with that issue? (or it is only happening at me?)

Edited by athoik, 29 April 2015 - 20:56.

[christophecvr]

Just tried it out. On dm8000 with latest gstreamer head same issue.

[mx3L]

I would suggest to look in last 6-7 commits of basesink http://cgit.freedesk...grep&q=basesink, and try to revert them one by one to see which commit is causing it.

[christophecvr]

An update on the current situation. Due to the previous error with caps I decided to again build the full gstreamer back. If removed all gstreamer repos the gstreamer the 4 plugins and gst libav(this last needed on vuduo2.)

The latest master head off today. I removed all patches they are not needed with updated gstreamer1.0 even the contrary some screw it just up. Perhaps prolonged use will show that perhaps one or other patch will have to be set. That can only be determined by extensive testing.

Only one patch needed to remain in and it's actually a patch from a gstreamer developper which is in there experimental branch. I puted that already in my very last GST-1-20150428-GIT.patch  (thats an informatif patch not meant to apply).

That's a patch to solve a compiler error due to missing static declaration for gstreamer1.0-plugins-base_git.bb I named it video-converter-fix-compiler-warning-due-missing-static-declaration.patch

 

By the way I named the gitpkgv now.

 

inherit gitpkgv
PV = "1.4.5.01+git${SRCPV}"
PKGV = "1.4.5.01+git${GITPKGV}"

 

The obtained srcrev I have now with my to days build using $[AUTOREV}

are.

 

 

gstreamer1.0  6386934b3fa18ecd64e4e6b11c6c37a264b0b294
gstreamer1.0-plugins-bad 87d8270f302b03f63ce04f986d824892a2c131fd
gstreamer1.0-plugins-base 5a8d1d22469a522dc5dcf0cde01cc7a3ae31aac5
gstreamer1.0-plugins-good 178f0a4522f2df0cd12147fdb24dfe994e5b68ae
gstreamer1.0-plugins-ugly 9a18b9e4ce6e38f40d743777f6095845f2fa6414
gsteramer1.0-libav 1caf1197502cd8165b4b2f7be37e6f25eda2ccea

Those I now set in SRCREV. and they are binded to 1.4.5.01.

 

If Now I wan't an updated git I'll adapt the SRCREV and set 1.4.5.02  . This way I hope to avoid the opkg upgrade bump.

 

Now I reflashed boxes. The caps issue is still there. However seeking about the issue it almost shure the problem is from our dvbmediasink (wheater that from pli or mine). When we passed from the gst-0.1.36 to the 1.0 we still have things which are not implemented like it should. And most probably it did worked ok just cause there is a bug in 1.4.5 concerning caps which where not unrefed when they should. Those problems are solved but now we have a problem with our sink.

anyway athoik and I are working on it to solve the issue. And it's better to solve it now then start with 1.4.5 and being faced with that issue the first gst tag update. To stay on top off media evolution it will be required in future.

 

But one very very very good news and issue now .... Eureka the media tag issue is now completely solved.  Now we have the tags whitout a missing thing. It's complete language code included.

 

Before we used a patch called taglist-not-send-to-down-stream-if-all-the-frame-cor.patch  This made that tags at least where sended but with undefined language. Now do NOT use this patch anymore. Wit the master HEAD the tags are all pushed and the complete with correct language code.

 

So yes we are improving. If the caps issue is solved we could become ready for a real beta version.

[mx3L]

I was also looking into this issue. For now I know that problem is in dvbvideosink and not in dvbaudiosink, since when I set property "video-sink" of playbin to fakesink, it works.

I also cleaned up dvbvideosink to bare minimum (render and get_caps method does nothing), but problem persist. So I suppose that this issue has to be basesink related.

 

What do you think?

[pieterg]

my guess:

http://cgit.freedesk...a7f89b8d7d1005f

 

we do not expect set_caps to be called again at that stage

[pieterg]

please ignore, that commit is rather old, and set_caps was called before this was applied.

[mx3L]

@pieterg

I think there will be some changes in caps handling, after this issue will be fixed I will post patch with updated description.

 

Why are we handling caps event ourselves? I think we should let basesink to do that and let it call our set_caps function.

diff --git a/gstdvbvideosink.c b/gstdvbvideosink.c
index fbebd11..fe52596 100644
--- a/gstdvbvideosink.c
+++ b/gstdvbvideosink.c
@@ -512,17 +512,6 @@ static gboolean gst_dvbvideosink_event(GstBaseSink 
*sink, GstEvent *event)
 		}
 		break;
 	}
-	case GST_EVENT_CAPS:
-	{
-		GstCaps *caps;
-		gst_event_parse_caps(event, &caps);
-		if (caps)
-		{
-			ret = gst_dvbvideosink_set_caps(sink, caps);
-			gst_caps_unref(caps);
-		}
-		break;
-	}
 	default:
 		ret = GST_BASE_SINK_CLASS(parent_class)->event(sink, event);
 		break;

[christophecvr]

please ignore, that commit is rather old, and set_caps was called before this was applied.

Yes that was in november and latest tag is december. So this patch is in cluded in the tag 1.4.5 version.

[betacentauri]

Thanks for the info that language codes are now working! Then I guess I can close my bug report on bugzilla.

[christophecvr]

Thanks for the info that language codes are now working! Then I guess I can close my bug report on bugzilla.

Yess but do not forget to remove the patch :

taglist-not-send-to-down-stream-if-all-the-frame-cor.patch

 

As this will again cause the language code to be undetermined.

 

wen You build for gstreamer1.0 (and I use latest head so not shure how it is in the tag 1.4.5).

[christophecvr]

@mx3L

 

I tried it but no luck caps problem still there . (I already tried this working way but did it only in audiosink now I did in both audio ,and video sink ) still same problem.

 

For the rest off the day I'll take a brake now with gstreamer(being gstreaming since 5 'O' clock am pfffff). To restart with fresh head tommorow an attack the caps issue.

 

However maybe some do not realise it for me this day has already been a milestone into evolution,

 

The media tag issue is really solved.

 

So time for plan B yes beer

Edited by christophecvr, 30 April 2015 - 17:08.

[pieterg]

@pieterg
I think there will be some changes in caps handling, after this issue will be fixed I will post patch with updated description.
 
Why are we handling caps event ourselves? I think we should let basesink to do that and let it call our set_caps function.

good point, makes sense to let the baseclass handle that.

[athoik]

The following pipeline with dvbaudiosink produce no errors.
 

# gst-launch-1.0 -v souphttpsrc location=http://megahdlive1-f.akamaihd.net/i/live_1@105260/master.m3u8 ! hlsdemux ! decodebin ! dvbaudiosink

But with dvbvideosink produce errors.
 

# gst-launch-1.0 -v souphttpsrc location=http://megahdlive1-f.akamaihd.net/i/live_1@105260/master.m3u8 ! hlsdemux ! decodebin ! dvbvideosink

...

(gst-launch-1.0:1811): GStreamer-CRITICAL **: _gst_util_uint64_scale_int: assertion 'denom > 0' failed
(gst-launch-1.0:1811): GStreamer-CRITICAL **: _gst_util_uint64_scale_int: assertion 'denom > 0' failed

Edit1. This one produce no errors (and seems to work)
 

# gst-launch-1.0 -v souphttpsrc location=http://megahdlive1-f.akamaihd.net/i/live_1@105260/master.m3u8 ! hlsdemux ! tsdemux  ! h264parse ! dvbvideosink

Edit2. It is not broadcasting that's why..

Edited by athoik, 30 April 2015 - 19:49.

[athoik]

Currently something really strange is going on! The following command reports no error.

# gst-launch-1.0 playbin uri=http://megahdlive1-f.akamaihd.net/i/live_1@105260/master.m3u8 -v

But running stream from enigma2 (via bouquets) same errors appear...

(enigma2:3040): GStreamer-CRITICAL **: gst_mini_object_ref: assertion 'mini_object != NULL' failed
(enigma2:3040): GStreamer-CRITICAL **: gst_caps_merge: assertion 'GST_IS_CAPS (caps2)' failed

I don't know if something help the gst-launch but currenlty I am using @mx3L suggestions (https://github.com/a...ee1b09d009bfd16)

[MastaG]

athoik, I've built a fresh image using gstreamer head and christophecvr's multibox sink for dm800se.

I'll test tonight a report back.

[MastaG]

Athoik,

 

Well started a clean build for my dm800se.

+ with: gstreamer head

+ with: your fixes for gstreamer head: fixed 0001-riff-media-added-fourcc-to-all-mpeg4-video-caps.patch and removing deps: cairo gdk-pixbuf gudev

+ with: gstreamer1.0-plugins-bad-dashdemux and gstreamer1.0-plugins-bad-smoothstreaming

+ with: gstreamer1.0-plugin-multibox-mediasink from christophecvr repo

+ with: mx3L's patch on top of the mediasink:

--- a/gstdvbvideosink.c
+++ b/gstdvbvideosink.c
@@ -518,6 +518,7 @@ static gboolean gst_dvbvideosink_event(GstBaseSink *sink, GstEvent *event)
         gst_event_parse_caps(event, &caps);
         if (caps)
         {
+            self->must_send_header = TRUE;
             ret = gst_dvbvideosink_set_caps(sink, caps);
             gst_caps_unref(caps);
         }

 

- without: glibc-gconv-utf-16 since that was fixed in gstreamer head right?

 

HLS works OK

Smooth works partly

mpeg-dash still broken

 

And your link:

# gst-launch-1.0 playbin uri=http://megahdlive1-f.akamaihd.net/i/live_1@105260/master.m3u8 -v

It freezes a lot, like there is insufficient bandwidth..

http://pastebin.com/RjkCtmaY

[athoik]

Using the sink I post above there are no critical errors in gst-launch. But in enigma they shown.

In your trace the following appear:

(gst-launch-1.0:723): GStreamer-CRITICAL **: gst_mini_object_ref: assertion 'mini_object != NULL' failed

So issue is still around. What happens if you add changes from my sink?

BTW: h265 doen't crash now, right?

PS. Correct,Utf-16 is not required using head

Edited by athoik, 1 May 2015 - 17:25.

[athoik]

Hi,

I installed gdb and debug packages and run enigma2:

G_DEBUG=fatal_warnings gdb enigma2

Here is the backtrace (bt, bt full, thread apply all bt): http://pastebin.com/1TVPYChu

[mx3L]

Hi,

 

I know this is not a solution we are looking for, but I think we don't need h264parse element at all.

In case there is no "width" and "height" set in the caps(which we don't use at all in set_caps, just codec-data), we can just remove these parameters for h264 from our pad template, so h264parse will be not added to pipeline to detect these parameters.

diff --git a/gstdvbvideosink.c b/gstdvbvideosink.c
index c6c4260..880e92d 100644
--- a/gstdvbvideosink.c
+++ b/gstdvbvideosink.c
@@ -185,8 +185,7 @@ GST_STATIC_PAD_TEMPLATE (
 		"mpegversion = (int) { 1, 2 }, "
 		VIDEO_CAPS "; "
 #ifdef HAVE_H264
-	"video/x-h264, "
-		VIDEO_CAPS "; "
+	"video/x-h264 ; "
 #endif
 #ifdef HAVE_H263
 	"video/x-h263, "

Now without h264parse there are no issues. What do you think?

Edited by mx3L, 1 May 2015 - 22:38.