GNOME Bugzilla – Bug 785770
pcapparse: support nanosecond time stamps
Last modified: 2017-08-10 07:38:33 UTC
For nanosecond, the bytes of the second nybble (i.e. first nybble is the endian nybble) in the magic are reversed. Question: does the parser need to do anything about the nanoseconds vs milliseconds ?
Probably? It's probably stored in a bigger integer? Or at least the scaling of timestamps from milliseconds to nanoseconds shouldn't happen in this case.
Correction: the nybbles of the third and fourth bytes are reversed. i.e. 0xa1b2c3d4 => 0xa1b23c4d
I believe for nanoseconds, it re-uses the msec field.
Created attachment 356846 [details] [review] support nanosecond timestamp
Review of attachment 356846 [details] [review]: Looks good. Does it work on your example stream?
Thanks. By work, I guess it does, since it throws no errors :) I think because the clip is so short, it doesn't want to play the video.
Test file: http://s3.amazonaws.com/fox_misc/aperi_tr01_1s_pkts-C.cap.gz Test pipeline (unzip file above and rename to test.cap) gst-launch-1.0 -v filesrc location=~/test.cap ! rtpmp2tdepay ! tsdemux ! jpeg2000parse ! openjpegdec ! videoconvert ! ximagesink
Does pcapparse output any buffers? Do the other elements? You could put an imagefreeze right before ximagesink.
Correction: gst-launch-1.0 -v filesrc location=~/test.cap ! pcapparse ! rtpmp2tdepay ! tsdemux ! jpeg2000parse ! openjpegdec ! videoconvert ! ximagesink
hmmmm, why wouldn't pcapparse output buffers :) ? If it doesn't, that would explain things.....
This pipeline :) : gst-launch-1.0 -v filesrc location=~/test.cap ! pcapparse ! tsdemux ! jpeg2000parse ! openjpegdec ! videoconvert ! ximagesink I get this warning Pipeline is PREROLLING ... 0:00:00.061924432 24544 0x97ee80 WARN basesrc gstbasesrc.c:2433:gst_base_src_update_length:<filesrc0> processing at or past EOS
imagefreeze didn't help, unfortunately
> gst-launch-1.0 -v filesrc location=~/test.cap ! pcapparse ! fakesink silent=false Does that print all the packets with correct timestamps?
No packets at all :( $ gst-launch-1.0 -v filesrc location=~/test.cap ! pcapparse ! fakesink silent=false Setting pipeline to PAUSED ... Pipeline is PREROLLING ... /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = event ******* (fakesink0:sink) E (type: stream-start (10254), GstEventStreamStart, stream-id=(string)9edc58a8dfb33502205739d8f624221ce060230734f1ac76d894146938c97f22, flags=(GstStreamFlags)GST_STREAM_FLAG_NONE, group-id=(uint)0;) 0xe5e5e0 /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = event ******* (fakesink0:sink) E (type: eos (28174), ) 0xe5e6c0 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 0:00:00.000080522
This pipeline prints the packets: gst-launch-1.0 -v filesrc location=~/test.cap ! fakesink silent=false
Actually, I guess this is just printing the buffers from filesrc
So you'll need to check why pcapparse does not like to print the packets. Is this the JPEG2000 capture? That had the IP packets wrapped in some kind of VLAN thing. 802.1q or something. That should be easy to just remove here when found.
So, at debug level 5, I get the following: 3:gst_pad_chain_data_unchecked:<pcapparse0:sink> calling chainfunction &gst_pcap_parse_chain with buffer buffer: 0x7feb8c005330, pts 99:99:99.999999999, dts 99:99:99.999999999, dur 99:99:99.999999999, size 4096, offset 5066752, offset_end 5070848, flags 0x0 The 9s seem wrong to me. $ GST_DEBUG=5 gst-launch-1.0 -v filesrc location=~/test.cap ! fakesink silent=false 2>&1 | grep pcapparse
That means that it consumes buffers without timestamps but does not output anything. It's going to be that VLAN thing.
So, with my vlan fix, I can see the packets with fakesink, and it looks like the jpeg2000parse parser is working. Still don't see any video though.
For this pipeline GST_DEBUG=3 gst-launch-1.0 -v filesrc location=~/test.cap ! pcapparse ! tsdemux ! jpeg2000parse ! openjpegdec ! videoconvert ! imagefreeze ! ximagesink with my two pcapparse patches, I am now seeing tsdemux warnings: 0:00:01.070779503 8815 0x1831050 WARN pesparser pesparse.c:416:mpegts_parse_pes_header: bad PTS value 0:00:01.070781019 8815 0x1831050 WARN tsdemux tsdemux.c:2253:gst_ts_demux_parse_pes_header: Error parsing PES header. pid: 0x45 stream_type: 0x6 0:00:01.070788151 8815 0x1831050 DEBUG pesparser pesparse.c:140:mpegts_parse_pes_header: header_size : 14 0:00:01.070821307 8815 0x1831050 WARN pesparser pesparse.c:416:mpegts_parse_pes_header: bad PTS value 0:00:01.070823313 8815 0x1831050 WARN tsdemux tsdemux.c:2253:gst_ts_demux_parse_pes_header: Error parsing PES header. pid: 0x42 stream_type: 0x6 Progress!!
Ok, now only the MPEG-TS stream is weird, assuming the pcapparse changes are correct. If you pass the output of pcapparse to a filesink, does it play in ffmpeg?
Well, ffmpeg will read the original cap file, but it can't handle the JPEG 2000 payload: Here is the output [mpegts @ 0x24214c0] PES packet size mismatch [jpeg2000 @ 0x2425900] Psot 268156 too big [jpeg2000 @ 0x2425900] error during processing marker segment ff90 [mpegts @ 0x24214c0] PES packet size mismatch Last message repeated 33 times [s302m @ 0x2427040] frame has invalid header [s302m @ 0x24264a0] frame has invalid header [s302m @ 0x2427040] frame has invalid header [mpegts @ 0x24214c0] PES packet size mismatch Last message repeated 4 times [s302m @ 0x2427be0] frame has invalid header [s302m @ 0x2427040] frame has invalid header [s302m @ 0x2427be0] frame has invalid header [s302m @ 0x2427040] frame has invalid header [s302m @ 0x2427be0] frame has invalid header [s302m @ 0x2427040] frame has invalid header [s302m @ 0x2427be0] frame has invalid header [s302m @ 0x2427040] frame has invalid header Last message repeated 4 times [mpegts @ 0x24214c0] PES packet size mismatch [s302m @ 0x2427040] frame has invalid header [mpegts @ 0x24214c0] PES packet size mismatch Last message repeated 27 times [NULL @ 0x2429360] start time for stream 5 is not set in estimate_timings_from_pts [NULL @ 0x24440a0] start time for stream 6 is not set in estimate_timings_from_pts [NULL @ 0x2444c40] start time for stream 7 is not set in estimate_timings_from_pts [NULL @ 0x24457e0] start time for stream 8 is not set in estimate_timings_from_pts [NULL @ 0x2446380] start time for stream 9 is not set in estimate_timings_from_pts [NULL @ 0x2446f20] start time for stream 10 is not set in estimate_timings_from_pts [mpegts @ 0x24214c0] PES packet size mismatch Last message repeated 8 times [mpegts @ 0x24214c0] Could not find codec parameters for stream 5 (Audio: s302m (BSSD / 0x44535342), 0 channels): unspecified sample format Consider increasing the value for the 'analyzeduration' and 'probesize' options [mpegts @ 0x24214c0] Could not find codec parameters for stream 6 (Audio: s302m (BSSD / 0x44535342), 0 channels): unspecified sample format Consider increasing the value for the 'analyzeduration' and 'probesize' options [mpegts @ 0x24214c0] Could not find codec parameters for stream 7 (Audio: s302m (BSSD / 0x44535342), 0 channels): unspecified sample format Consider increasing the value for the 'analyzeduration' and 'probesize' options [mpegts @ 0x24214c0] Could not find codec parameters for stream 8 (Audio: s302m (BSSD / 0x44535342), 0 channels): unspecified sample format Consider increasing the value for the 'analyzeduration' and 'probesize' options Input #0, mpegts, from 'test.cap': Duration: 00:00:01.05, start: 60948.079933, bitrate: 516894 kb/s Program 1 Stream #0:0[0x74]: Video: jpeg2000 ([33][0][0][0] / 0x0021), yuv422p10le, 1280x720, 59.94 fps, 59.94 tbr, 90k tbn, 90k tbc Stream #0:1[0x42]: Audio: s302m (BSSD / 0x44535342), 48000 Hz, stereo, s32 (24 bit), 2689 kb/s Stream #0:2[0x43]: Audio: s302m (BSSD / 0x44535342), 48000 Hz, stereo, s32 (24 bit), 2689 kb/s Stream #0:3[0x44]: Audio: s302m (BSSD / 0x44535342), 48000 Hz, stereo, s32 (24 bit), 2689 kb/s Stream #0:4[0x45]: Audio: s302m (BSSD / 0x44535342), 48000 Hz, stereo, s32 (24 bit), 2689 kb/s Stream #0:5[0x46]: Audio: s302m (BSSD / 0x44535342), 0 channels Stream #0:6[0x47]: Audio: s302m (BSSD / 0x44535342), 0 channels Stream #0:7[0x48]: Audio: s302m (BSSD / 0x44535342), 0 channels Stream #0:8[0x49]: Audio: s302m (BSSD / 0x44535342), 0 channels Stream #0:9[0xc8]: Data: bin_data ([6][0][0][0] / 0x0006) Stream #0:10[0xc9]: Data: bin_data ([6][0][0][0] / 0x0006)
Their native jpeg 2000 decoder is kind of dodgy.
Test pipeline: gst-launch-1.0 -v filesrc location=~/test.cap ! pcapparse ! fakesink silent=false
So, what is the best way of trouble shooting a bad PTS value ?
Bad PTS value where? The pcapparse patch is correct, I checked it here against another capture and it outputs the same for nsec timestamps as without.
commit 111921ae7031d54c40eb9beaed2eaf36b5865023 (HEAD -> master) Author: Aaron Boxer <boxerab@gmail.com> Date: Thu Aug 3 08:42:14 2017 -0400 pcapparse: Support pcap with nanosecond timestamps https://bugzilla.gnome.org/show_bug.cgi?id=785770
(In reply to Sebastian Dröge (slomo) from comment #27) > Bad PTS value where? The pcapparse patch is correct, I checked it here > against another capture and it outputs the same for nsec timestamps as > without. Thanks. So, perhaps the mpeg TS stream is corrupt ? What is the best way of validating the mpeg ts stream for conformance to standard?
I would pass it through tsdemux and check where exactly it gets confused and if we can do something about that
Thanks. I was thinking of perhaps a binary dump of the PES packets, and then analyze somehow?
Sure, gst_util_dump_mem() if you want to do that :)
So, reading the beginning of the PES header in method mpegts_parse_pes_header, I get the following bytes: 0x80 0x0a 0x1b 0xd2 0xbd 0xfe 0x80 is a flag indicating a PTS, but the next byte should have its low bit set. Since it doesn't, the PTS is rejected. This byte pattern appears for each PES packet, so it doesn't look like corruption, as it is the same pattern. I am not familiar enough with mpeg ts to see what is going on here..... By the way, I also see this: #define ST_PS_VIDEO_MPEG2_DCII 0x80 Is this a private video stream, perhaps, rather than a PTS ?
Aha! Stream type is 0x06, indicating a private stream. From gstreamer header: * 0x06 ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES * packets containing private data Also /* Un-official time-code stream */ #define ST_PS_TIMECODE 0xd2 and #define ST_VIDEO_H264 0x1b
So, this can't be a PTS time stamp, because it doesn't change.
Could it be that "SMPTE 302m" embeds some kind of non-MPEG-codec into the MPEG-TS, using a private stream? FFMpeg reports "SMPTE 302m" audio stream.
Can you open a new bug about this? It looks like some support for something is missing in tsdemux.