2520 replies to this topic

[Erik Slagter]

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.

[Erik Slagter]

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?

[athoik]

 

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.

[mx3L]

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

[athoik]

@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

•  divx-to-mpeg.patch   1.95KB   18 downloads

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

[mx3L]

@athoik

nice! divx5 packed is now working too.

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

[athoik]

@mx3L,

That is good!

Now we need a better version of above patch (eg with support for GStreamer 0.10 etc etc).

[littlesat]

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.

[athoik]

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)?

[pieterg]

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?

[littlesat]

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

[theparasol]

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.

[pieterg]

Who's talking about reverting?

[littlesat]

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

[theparasol]

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

[athoik]

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

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

[mx3L]

little update:

 

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

[salimda]

_hi

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

_thanks

[peteru]

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.

[athoik]

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

What's the case with decodebin, do you have an example?