I can now feed the MPEG4 system stream to mpegpsdemux, and it demuxes it correctly; but the src caps are still MPEG2.

I can fix that with an capssetter afterwards.

I'm not quite certain if I should touch that; that would probably best be checked with someone that knows about program stream parsing.

I'm a bit confused. What exactly doesn't work? What does "MPEG4 *system stream* to mpegpsdemux" mean?

This works fine for me:

 $ gst-launch-1.0 videotestsrc num-buffers=5000 ! avenc_mpeg4 ! mpegpsmux ! filesink location=mpeg4.ps

 $ gst-play-1.0 mpeg4.ps

Can you make a sample file available?

Hm, did I forget the patch?

it is about an MPEG4 stream, wrapped in PS, feeding that one to the demuxer did not work.

I'll capture a piece of it on Monday.

mleeman@zee:/home/firmware/mleeman/Development/gstreamer-build-debian/gstreamer-1.4.3/gst-plugins-bad/debian/patches$ cat 03-mpegpsdemux-supports-MPEG4-too.patch 
From 7aac15e6ea489c5e2054aadf4a2c0e61948fdce7 Mon Sep 17 00:00:00 2001
From: Marc Leeman <marc.leeman@gmail.com>
Date: Thu, 11 Dec 2014 12:25:11 +0100
Subject: [PATCH] mpegpsdemux supports MPEG4 too

---
 gst/mpegdemux/gstmpegdemux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gst/mpegdemux/gstmpegdemux.c b/gst/mpegdemux/gstmpegdemux.c
index a337672..e9c2b2b 100644
--- a/gst/mpegdemux/gstmpegdemux.c
+++ b/gst/mpegdemux/gstmpegdemux.c
@@ -98,7 +98,7 @@ static GstStaticPadTemplate sink_template = GST_STATIC_PAD_TEMPLATE ("sink",
     GST_PAD_SINK,
     GST_PAD_ALWAYS,
     GST_STATIC_CAPS ("video/mpeg, "
-        "mpegversion = (int) { 1, 2 }, "
+        "mpegversion = (int) { 1, 2, 4 }, "
         "systemstream = (boolean) TRUE;" "video/x-cdxa")
     );
 
-- 
2.1.3

That seems wrong. Where did you get a file that would be detected as a MPEG4 systemstream with video/mpeg? AFAIK there is no such thing.

A file? What is that?

You know that we are working with all kinds of strange streaming video cameras :-)

I can provide you with a capture if you want.

That would be great, please do :) Also if you know to what spec this stream conforms, please let us know. I thought there's only MPEG1/2 program streams, transport streams, and the MPEG4 variant is the ISO BMFF (aka MP4).

Marc?

Thanks for reminding me, I had to race to meet a deadline yesterday (made it, yeey).

I tried to get a capture this morning, but the encoder is not on the network. I went to see if it got disconnected in order to re-use some power supply or analogue input, but without knowing how the encoder looks like, the name (hisome) is not really helpful in the plethora of brands and cables.

The guy maintaining them is on holiday until January 5th, I'll provide a capture when he gets back.

Friendly reminder :)

Sorry for the delay; I'm uploading the original cap instead of a gdp capture I would make from this:

http://crichton.supercomputerrobot.com/~marc/downloads/hisome_226_255_0_65_30000.cap.xz

This is a MPEG2 PS stream that contains a MPEG4 Part 2 video stream.

... with ST_GST_VIDEO_MPEG1_OR_2 as stream type. And we have no detection for MPEG4 there.

Forcing it to output MPEG4 Part 2 caps makes it work, but I'm not sure how to properly detect this.

You know that we are not detecting this, but we use the uri to 'hint' the bins to what the stream will be (overriding the detection).

I am certainly open for better suggestions to improve support for this encoder chaos.

This kind of peer review is IMO key.

btw, there is more where this came from, I just like to have a review myself before dumping this as a black box into the community.

I will be entering more of these as I have time to review/analyse them myself with patches.

File is gone.

Dunno what to do about this. Broken stream I think, let's close this.