Jump to content


Photo

GStreamer 1.0

gstreamer 1.0 openpli

  • Please log in to reply
2520 replies to this topic

Re: GStreamer 1.0 #301 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+541
Excellent

Posted 14 November 2014 - 15:57

Correct, this is what GStreamer devs where telling again and again, xvid is mpeg4 part2 why you need special handling? So they rejected patch that adds format in caps (like the wmv does). Here is the bug: https://bugzilla.gno...g.cgi?id=739196

So every mpeg4 part2 codecs must/should handled by streamtype = 4.

 

I think you misunderstand the standpoint of the gstreamer devs. IMHO they are right. Xvid (and divx) are indeed just mpeg4 part (aka mpeg4 vc). The separate frames without the container (the elementary stream) is really just mpeg4 vc (also incorrectly referred to as mpeg4 asp). This issue has nothing to do with the codec. It's a container issue. As soon as you wrap mpeg4 (or even mpeg2...) containing B frames into an avi container, there is no way to store the DTS. Avi only has (implicit) PTS. To overcome this limitation (other than using a proper container that can handle B frames) divx decided to "pack" B frames together with "normal" frames (I/P). As soon as the avi demuxer has spliced the container into elementary streams, it SHOULD also re-create the separate frames from the packed frames, including the DTS (calculated from the position in the stream and the frame rate), and you'd have a perfectly normal mpeg4 vc stream that every decoder can handle (including a hardware decoder).

 

So imho the avi demuxer should handle this special case which only occurs in avi containers, if only because once demuxed, there might not be enough metadata left to reconstruct the separate files.


* 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.


Re: GStreamer 1.0 #302 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+541
Excellent

Posted 14 November 2014 - 16:04

Here are the latest bbappends and patches.

It includes the following:

1. GStreamer 1.4.4
2. fix for divx3 and xvid
3. build missing plugins (only cdxaparse missing because is not ported to 1.0 yet)
4. fix for librtmp blocking on send operations timeout (SO_SNDTIMEO)
5. fix for rtmp seek

You can find information how to use gstreamer1.0v4.tar.gz at #143,#125 (simply extract on meta-local/recipes-local and change MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS to GStreamer 1.0 dvbmediasink).

Is this still actual?


* 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.


Re: GStreamer 1.0 #303 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 14 November 2014 - 16:09

 

Here are the latest bbappends and patches.

It includes the following:

1. GStreamer 1.4.4
2. fix for divx3 and xvid
3. build missing plugins (only cdxaparse missing because is not ported to 1.0 yet)
4. fix for librtmp blocking on send operations timeout (SO_SNDTIMEO)
5. fix for rtmp seek

You can find information how to use gstreamer1.0v4.tar.gz at #143,#125 (simply extract on meta-local/recipes-local and change MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS to GStreamer 1.0 dvbmediasink).

Is this still actual?

 

 

Almost, all my pending dvbmediasink patches commited. So they should removed from gstreamer1.0-plugin-dvbmediasink.bbappend

 

Also patch avidemux-set-pts-on-all-buffers.patch is not good, it should be removed from gstreamer1.0-plugins-good_1.4.%.bbappend

 

And also apply patch from mx3L in order to workaround PTS/DTS issue on some codecs.


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: GStreamer 1.0 #304 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 14 November 2014 - 16:56

@athoik

Of course I agree with your aproach, I'm just concerned about little decrease in perfomance, since to me it looks like that on startup of playback/after seeking there is more noticable delay, then it was in 0.10/pre-parsed option enabled for xvid on 1.0. By delay I mean that e2 reactions to rc commands are slower. I think it's caused by additional parsing by mpeg4videoparse. It's not big deal, I just thought that if hw can do it without sw mpeg4 parsing than let it.



Re: GStreamer 1.0 #305 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 14 November 2014 - 19:23

@mx3L, could you please try the following patch on top of your latest pts/dts patch?

 
diff --git a/gstdvbvideosink.c b/gstdvbvideosink.c
index 211ce86..760831f 100755
--- a/gstdvbvideosink.c
+++ b/gstdvbvideosink.c
@@ -76,7 +76,7 @@
 #include <gst/gst.h>
 #include <gst/base/gstbasesink.h>
 
-#define PACK_UNPACKED_XVID_DIVX5_BITSTREAM
+#undef PACK_UNPACKED_XVID_DIVX5_BITSTREAM
 
 #include "common.h"
 #include "gstdvbvideosink.h"
@@ -207,7 +207,15 @@ GST_STATIC_PAD_TEMPLATE (
 #else
 		VIDEO_CAPS 
 #endif
-		", divxversion = (int) [ 3, 5 ]; "
+		", divxversion = (int) 3;"
+	"video/x-divx, "
+#ifdef HAVE_LIMITED_MPEG4V2
+		MPEG4V2_LIMITED_CAPS
+#else
+		VIDEO_CAPS
+#endif
+		", parsed = (boolean) true "
+		", divxversion = (int) [4, 6];"
 	"video/x-xvid, "
 #ifdef HAVE_LIMITED_MPEG4V2
 		MPEG4V2_LIMITED_CAPS
@@ -821,7 +829,7 @@ static GstFlowReturn gst_dvbvideosink_render(GstBaseSink *sink, GstBuffer *buffe
 	}
 #endif
 	/* remove dummy packed B-Frame */
-	if (self->codec_type == CT_MPEG4_PART2 && data_len <= 7)
+	if (self->codec_type == CT_MPEG4_PART2 && data_len < 10)
 		goto ok;
 
 	pes_header[0] = 0;
@@ -1518,7 +1526,7 @@ static gboolean gst_dvbvideosink_set_caps(GstBaseSink *basesink, GstCaps *caps)
 #endif
 			}
 			break;
-			case 4:
+			case 44:
 				streamtype = 14;
 				self->codec_type = CT_DIVX4;
 #if GST_VERSION_MAJOR >= 1
@@ -1535,14 +1543,16 @@ static gboolean gst_dvbvideosink_set_caps(GstBaseSink *basesink, GstCaps *caps)
 			break;
 			case 6:
 			case 5:
-				streamtype = 15;
+			case 4:
+				streamtype = 4;
+				self->codec_type = CT_MPEG4_PART2;
 #if GST_VERSION_MAJOR >= 1
-				self->use_dts = TRUE;
+				self->use_dts = FALSE;
 #endif
 #ifdef PACK_UNPACKED_XVID_DIVX5_BITSTREAM
 				self->must_pack_bitstream = TRUE;
 #endif
-				GST_INFO_OBJECT (self, "MIMETYPE video/x-divx vers. 5 -> VIDEO_SET_STREAMTYPE, 15");
+				GST_INFO_OBJECT (self, "MIMETYPE video/x-divx vers. %d -> VIDEO_SET_STREAMTYPE, 4", divxversion);
 			break;
 			default:
 				GST_ELEMENT_ERROR (self, STREAM, FORMAT, (NULL), ("unhandled divx version %i", divxversion));
It seems to me that this version works for divx (packed and unpacked).

Attached Files


Edited by athoik, 14 November 2014 - 19:24.

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: GStreamer 1.0 #306 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 14 November 2014 - 20:12

@athoik

nice! divx5 packed is now working too.


Edited by mx3L, 14 November 2014 - 20:12.


Re: GStreamer 1.0 #307 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 14 November 2014 - 20:17

@mx3L,

That is good!

Now we need a better version of above patch (eg with support for GStreamer 0.10 etc etc).
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: GStreamer 1.0 #308 littlesat

  • PLi® Core member
  • 57,064 posts

+698
Excellent

Posted 14 November 2014 - 20:22

Just my thoughts...

 

When >1.0 is good... why do we need support for 0.10 anymore?


Edited by littlesat, 14 November 2014 - 20:22.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: GStreamer 1.0 #309 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 14 November 2014 - 21:14

Just my thoughts...
 
When >1.0 is good... why do we need support for 0.10 anymore?


So is it ok to add only gstreamer 1.0 code on gst-1.0 branch (without adding >=1 checks and ofc <1)?
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: GStreamer 1.0 #310 pieterg

  • PLi® Core member
  • 32,766 posts

+245
Excellent

Posted 14 November 2014 - 22:04

I think it's better to keep 0.1 support.

I can imagine that we might want to try an older version every now and then, to compare result?



Re: GStreamer 1.0 #311 littlesat

  • PLi® Core member
  • 57,064 posts

+698
Excellent

Posted 14 November 2014 - 23:02

Also a good point pieterg.... First get it good... And when it get into trouble we can still fallback...

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: GStreamer 1.0 #312 theparasol

  • Senior Member
  • 4,157 posts

+198
Excellent

Posted 14 November 2014 - 23:15

Just commit it without gstreamer0.1 support... if we run into issues there is more drive to fix it. I believe reverting is lame and stalls progress.

People that want a perfect working box can always flash a working older image.


@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: GStreamer 1.0 #313 pieterg

  • PLi® Core member
  • 32,766 posts

+245
Excellent

Posted 15 November 2014 - 00:35

Who's talking about reverting?



Re: GStreamer 1.0 #314 littlesat

  • PLi® Core member
  • 57,064 posts

+698
Excellent

Posted 15 November 2014 - 00:38

Hopefully we can jump to this renewed gstreamer soon... :)

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: GStreamer 1.0 #315 theparasol

  • Senior Member
  • 4,157 posts

+198
Excellent

Posted 15 November 2014 - 00:40

Who's talking about reverting?

 

I did... is there another way? Github is not my cup of tea. SVN is something my brain can handle ;)


@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: GStreamer 1.0 #316 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 15 November 2014 - 06:49

I did... is there another way?


Using branches you can have gstreamer 0.10 leaving in master and gstremer 1.0 leaving in gst-1.0 branch.

So dvbmediasink-1.0 can safely use branch gst-1.0 while dvbmediasink-0.10 can safely use branch master.

If OpenPLi (and others) switch to GStreamer 1.0 without looking back any more, then gst-1.0 branch can become the master and the current master to become gst-0.10

So no reverts, just branches :D

Edited by athoik, 15 November 2014 - 06:49.

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: GStreamer 1.0 #317 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 15 November 2014 - 10:45

little update:

 

divx4 simple profile now also works on et6500 with latest divx-to-mpeg.patch



Re: GStreamer 1.0 #318 salimda

  • Senior Member
  • 30 posts

0
Neutral

Posted 15 November 2014 - 15:07

hi

can u create gsreamer 1.4.4 file like ipk for dreambox emage openpli 2.0.

thanks



Re: GStreamer 1.0 #319 peteru

  • Senior Member
  • 36 posts

+5
Neutral

Posted 16 November 2014 - 05:45

It would be nice to come up with a solution that can still use the caps to negotiate the right set of nodes when using decodebin, so that enigma2 does not have to build a specific pipeline for AVIs.

"Beauty lies in the hands of the beer holder."

 


Re: GStreamer 1.0 #320 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 16 November 2014 - 06:55

@peteru, we are using playbin in enigma2 and caps negotiate without problems.

What's the case with decodebin, do you have an example?
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



0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users