gstreamer splitmuxsink with matroskamux generating corrupt output

[hassanctech]

I have a simple gstreamer pipeline running on an IP camera (fixed to
gstreamer version 1.8.3, cannot change this).  I have an h264 stream coming
through avc/au and I have a splitmuxsink using the default filesink but I've
set the muxer to a matroskamux element which is the generic one I haven't
set any properties on it.  On the splitmuxsink I've set the "max-size-time"
field to 60s.  I'm seeing a new file is being generated every 60s but the
file is only around 500 bytes in size so it's clearly on a proper mkv file. 
Using the same pipeline but going to an appsink instead of splitmuxsink, I
can assemble the NAL units on the fly and generate a properly formed
playable file -- but I'd like to avoid this if I can and have gstreamer do
it since it seems this is exactly what splitmuxsink was intended to do. 
Unfortunately the gstreamer that lives on the camera was configured without
the debug so I don't see any error output and all I have to go off of are
the short mkv files generated.  Below is a hexdump of one of them if it
helps (523 bytes):

0000000 1a 45 df a3 01 00 00 00 00 00 00 14 42 82 89 6d
0000010 61 74 72 6f 73 6b 61 00 42 87 81 02 42 85 81 02
0000020 18 53 80 67 01 00 00 00 00 00 01 df 11 4d 9b 74
0000030 01 00 00 00 00 00 00 8c 4d bb 01 00 00 00 00 00
0000040 00 12 53 ab 84 15 49 a9 66 53 ac 88 00 00 00 00
0000050 00 00 00 98 4d bb 01 00 00 00 00 00 00 12 53 ab
0000060 84 16 54 ae 6b 53 ac 88 00 00 00 00 00 00 01 17
0000070 ec 9a 01 00 00 00 00 00 00 12 53 ab 84 10 43 a7
0000080 70 53 ac 88 ff ff ff ff ff ff ff ff ec 9a 01 00
0000090 00 00 00 00 00 12 53 ab 84 1c 53 bb 6b 53 ac 88
00000a0 ff ff ff ff ff ff ff ff ec 9a 01 00 00 00 00 00
00000b0 00 12 53 ab 84 12 54 c3 67 53 ac 88 ff ff ff ff
00000c0 ff ff ff ff 15 49 a9 66 01 00 00 00 00 00 00 73
00000d0 73 a4 90 52 76 2d af ad 99 1a ad 87 be e5 86 28
00000e0 9e 7c 73 2a d7 b1 83 0f 42 40 ec 88 88 00 00 00
00000f0 00 00 00 00 00 4d 80 a4 47 53 74 72 65 61 6d 65
0000100 72 20 6d 61 74 72 6f 73 6b 61 6d 75 78 20 76 65
0000110 72 73 69 6f 6e 20 31 2e 38 2e 33 00 57 41 99 47
0000120 53 74 72 65 61 6d 65 72 20 4d 61 74 72 6f 73 6b
0000130 61 20 6d 75 78 65 72 00 44 61 88 07 95 1d d0 00
0000140 d8 e2 00 16 54 ae 6b 01 00 00 00 00 00 00 73 ae
0000150 01 00 00 00 00 00 00 6a d7 81 01 83 81 01 73 c5
0000160 88 70 c5 ef a1 e4 f6 3c 86 23 e3 83 84 01 fc a0
0000170 55 53 6e 86 56 69 64 65 6f 00 e0 01 00 00 00 00
0000180 00 00 08 b0 82 05 00 ba 82 03 c0 86 90 56 5f 4d
0000190 50 45 47 34 2f 49 53 4f 2f 41 56 43 00 63 a2 a2
00001a0 01 42 00 29 ff e1 00 13 67 42 00 29 e2 90 0a 00
00001b0 f3 60 2d c0 40 40 69 07 89 11 50 01 00 04 68 ce
00001c0 3c 80 12 54 c3 67 01 00 00 00 00 00 00 3d 73 73
00001d0 01 00 00 00 00 00 00 33 63 c0 01 00 00 00 00 00
00001e0 00 0b 63 c5 88 70 c5 ef a1 e4 f6 3c 86 67 c8 01
00001f0 00 00 00 00 00 00 14 45 a3 87 42 49 54 53 50 53
0000200 00 44 87 87 32 31 32 33 30 34 00               
000020b

If I cat the file I of course see some gibberish but also other text such
as: GStreamer matroskamux version 1.8.3 GStreamer Matroska muxer
VideoV_MPEG4/ISO/AVC, I've stripped out the garbage but this is essentially
the only thing written to the file.  Any ideas on how I can debug this?  I
know for sure what is being fed to splitmuxsink is a valid h264 stream, the
only thing that could be off is the PTS and DTS don't use the same time base
and really it should be using just the PTS, I've looked through the code for
the splitmuxsink plugin and it looks like as long as the PTS is valid it
only uses the PTS so I'm not sure if this is the issue.  Here is an example
of the PTS, DTS to show what I mean:

PTS	                        DTS
1202062142644000	48872395
1202062175912000	88699065
1202062209192000	115496365
1202062242547000	147632015
1202062275807000	181026460
1202062309074000	220716350
1202062342356000	247560670
1202062375650000	280627030
1202062408972000	313645540

Finally -- we do NOT generate any B frames so PTS and DTS should be the same
anyway.  An elementary h264 stream for example in the Annex B format does
not contain any time stamps anyway (not sure about mkv maybe it does) so I
suspect this is the problem.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/