After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 785770 - pcapparse: support nanosecond time stamps
pcapparse: support nanosecond time stamps
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal enhancement
: 1.13.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-08-03 12:00 UTC by Aaron Boxer
Modified: 2017-08-10 07:38 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
support nanosecond timestamp (2.98 KB, patch)
2017-08-03 12:43 UTC, Aaron Boxer
committed Details | Review

Description Aaron Boxer 2017-08-03 12:00:14 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 ?
Comment 1 Sebastian Dröge (slomo) 2017-08-03 12:03:50 UTC
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.
Comment 2 Aaron Boxer 2017-08-03 12:04:07 UTC
Correction: the nybbles of the third and fourth bytes are reversed.

i.e. 0xa1b2c3d4  =>   0xa1b23c4d
Comment 3 Aaron Boxer 2017-08-03 12:04:52 UTC
I believe for nanoseconds, it re-uses the msec field.
Comment 4 Aaron Boxer 2017-08-03 12:43:37 UTC
Created attachment 356846 [details] [review]
support nanosecond timestamp
Comment 5 Sebastian Dröge (slomo) 2017-08-03 12:52:03 UTC
Review of attachment 356846 [details] [review]:

Looks good. Does it work on your example stream?
Comment 6 Aaron Boxer 2017-08-03 12:54:29 UTC
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.
Comment 7 Aaron Boxer 2017-08-03 12:55:48 UTC
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
Comment 8 Sebastian Dröge (slomo) 2017-08-03 12:56:56 UTC
Does pcapparse output any buffers? Do the other elements?

You could put an imagefreeze right before ximagesink.
Comment 9 Aaron Boxer 2017-08-03 12:58:17 UTC
Correction:

gst-launch-1.0 -v filesrc location=~/test.cap !  pcapparse ! rtpmp2tdepay ! tsdemux ! jpeg2000parse ! openjpegdec ! videoconvert ! ximagesink
Comment 10 Aaron Boxer 2017-08-03 12:59:50 UTC
hmmmm, why wouldn't pcapparse output buffers :)  ? If it doesn't, that would explain things.....
Comment 11 Aaron Boxer 2017-08-03 13:04:34 UTC
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
Comment 12 Aaron Boxer 2017-08-03 13:15:18 UTC
imagefreeze didn't help, unfortunately
Comment 13 Sebastian Dröge (slomo) 2017-08-03 13:22:57 UTC
> gst-launch-1.0 -v filesrc location=~/test.cap !  pcapparse ! fakesink silent=false

Does that print all the packets with correct timestamps?
Comment 14 Aaron Boxer 2017-08-03 13:25:16 UTC
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
Comment 15 Aaron Boxer 2017-08-03 13:29:41 UTC
This pipeline prints the packets:

gst-launch-1.0 -v filesrc location=~/test.cap !  fakesink silent=false
Comment 16 Aaron Boxer 2017-08-03 13:31:39 UTC
Actually, I guess this is just printing the buffers from filesrc
Comment 17 Sebastian Dröge (slomo) 2017-08-03 13:38:27 UTC
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.
Comment 18 Aaron Boxer 2017-08-03 14:13:02 UTC
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
Comment 19 Sebastian Dröge (slomo) 2017-08-03 14:27:20 UTC
That means that it consumes buffers without timestamps but does not output anything. It's going to be that VLAN thing.
Comment 20 Aaron Boxer 2017-08-03 15:20:42 UTC
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.
Comment 21 Aaron Boxer 2017-08-03 15:25:54 UTC
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!!
Comment 22 Sebastian Dröge (slomo) 2017-08-04 06:01:56 UTC
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?
Comment 23 Aaron Boxer 2017-08-04 11:46:42 UTC
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)
Comment 24 Aaron Boxer 2017-08-04 11:47:24 UTC
Their native jpeg 2000 decoder is kind of dodgy.
Comment 25 Aaron Boxer 2017-08-04 11:57:44 UTC
Test pipeline:  

gst-launch-1.0 -v filesrc location=~/test.cap !  pcapparse ! fakesink silent=false
Comment 26 Aaron Boxer 2017-08-09 02:58:42 UTC
So, what is the best way of trouble shooting a bad PTS value ?
Comment 27 Sebastian Dröge (slomo) 2017-08-09 06:50:56 UTC
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.
Comment 28 Sebastian Dröge (slomo) 2017-08-09 06:51:37 UTC
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
Comment 29 Aaron Boxer 2017-08-09 14:10:43 UTC
(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?
Comment 30 Sebastian Dröge (slomo) 2017-08-09 14:40:32 UTC
I would pass it through tsdemux and check where exactly it gets confused and if we can do something about that
Comment 31 Aaron Boxer 2017-08-09 14:44:17 UTC
Thanks. I was thinking of perhaps a binary dump of the PES packets, and then analyze somehow?
Comment 32 Sebastian Dröge (slomo) 2017-08-09 14:50:22 UTC
Sure, gst_util_dump_mem() if you want to do that :)
Comment 33 Aaron Boxer 2017-08-09 20:53:55 UTC
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 ?
Comment 34 Aaron Boxer 2017-08-09 21:03:50 UTC
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
Comment 35 Aaron Boxer 2017-08-09 21:04:44 UTC
So, this can't be a PTS time stamp, because it doesn't change.
Comment 36 Aaron Boxer 2017-08-10 02:34:19 UTC
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.
Comment 37 Sebastian Dröge (slomo) 2017-08-10 07:38:33 UTC
Can you open a new bug about this? It looks like some support for something is missing in tsdemux.