I'm demuxing one program stream file and I can't figure out what one PES packet is carrying. (see picture below).
Stream ID is 0xE0, so it is a video stream. Since I'm reading a program stream file, it is the only video stream. As you can see, the packet length is 0x9C, the next byte 0x80 tells us that first two bits are '10', as expected and PES_scrambling_control, PES_priority, data_alignment_indicator, copyright and original_or_copy are all 0 (not set). The next byte 0x09 tells us that we have DSM_trick_mode_flag and PES_extension_flag set. The next byte 0x78 is PES header length. If we skip PES header, we will be at the first byte in the framed area containing 33 bytes. It begins with 00 37 B0... These 33 bytes should be skipped when demuxing, but I can't figure out why. Any comment or suggestion is very welcome.
PES packet picture
PES packet hex values as text:
00 00 01 e0 00 9c 80 09 78 00 52 40 09 ac 00 3f
40 00 22 00 d7 c0 00 e2 00 da 20 04 8a 00 62 60
02 36 00 46 10 0e a1 00 28 50 01 b9 00 d9 d0 09
cd 00 67 30 0f a3 00 44 b0 04 6b 00 8f b0 0d e7
00 64 f0 00 57 00 41 70 09 d7 00 a7 70 0d 5f 00
73 f0 0c 40 80 f8 88 00 b0 80 23 88 06 68 80 38
88 0b a8 80 be 08 07 b0 80 b3 f0 0a 10 80 67 70
08 90 80 b6 70 03 10 80 7f b0 09 00 80 f1 b0 0f
2f 00 37 b0 09 77 00 a4 70 0e 37 00 ca 70 07 47
00 b1 b0 03 33 00 3e 30 06 bd 00 77 50 05 2d 00
15 50
Related
I need to be able to inspect ts packets (looking at video PID 481) and determine whether the packet contains an IDR frame. My understanding is that I need to look for a NAL unit start code, and then something else after that to signify it's the start of an IDR frame. Please can someone clarify?
Here's an example of a packet that I think is an IDR frame, but need to be able to prove it from the payload data:
* Packet 2
---- TS Header ----
PID: 481 (0x01E1), header size: 12, sync: 0x47
Error: 0, unit start: 1, priority: 0
Scrambling: 0, continuity counter: 1
Adaptation field: yes (8 bytes), payload: yes (176 bytes)
Discontinuity: 1, random access: 1, ES priority: 0
PCR: 0x000000013A5
---- PES Header ----
Stream id: 0xE0 (Video 0)
PES packet length: 0 (unbounded)
---- Full TS Packet Content ----
47 41 E1 31 07 D0 00 00 00 08 7E E5 00 00 01 E0 00 00 84 C0 0A 31 00 05
E5 CD 11 00 05 AD 8D 00 00 00 01 09 10 00 00 00 01 67 64 00 29 AC D9 40
78 04 4F DE 02 94 04 04 05 00 00 03 00 01 00 00 03 00 32 E6 80 00 F4 24
00 04 F5 8A 49 30 0F 8B 16 CB 00 00 00 01 68 FA A7 CB 00 00 01 06 00 05
95 6C 60 E4 85 80 00 00 01 06 05 FF FF F5 DC 45 E9 BD E6 D9 48 B7 96 2C
D8 20 D9 23 EE EF 78 32 36 34 20 2D 20 63 6F 72 65 20 31 34 38 20 2D 20
48 2E 32 36 34 2F 4D 50 45 47 2D 34 20 41 56 43 20 63 6F 64 65 63 20 2D
20 43 6F 70 79 72 69 67 68 74 20 32 30 30 33 2D 32 30 31 36
Its not possible to tell from that packet. It is however VERY likely it is an IDR. I say its likely, because looking at the NALUs, I can see an AUD 00 00 00 01 09, an SPS 00 00 00 01 67 a PPS 00 00 00 01 68 then an SEI 00 00 01 06
The SEI however takes the remaining bytes of the packet, You will need to continue reading packets from that PID until you fine the next NALU and see if its an IDR.
i need to read the payload information from a udp packet which is in pcap file.
tshark -x -c 10 -r traces/trace.pcap udp
0000 00 22 4d a8 1f 7f 80 3f 5d 08 52 35 08 00 45 00 ."M....?].R5..E.
0010 05 94 03 e6 40 00 40 11 3b 46 c0 a8 ba 6c c0 a8 ....#.#.;F...l..
0020 ba 6f d4 80 05 dc 05 80 4e 9e 00 00 80 25 1b 3a .o......N....%.:
0030 fd 9e 00 00 00 01 00 00 00 06 5b 29 c2 5b 78 ed ..........[).[x.
0040 00 00 1b 6f c2 5b 78 ed 00 00 1e c4 30 5b 00 00 ...o.[x.....0[..
0050 00 00 85 c7 09 00 00 00 00 00 01 00 00 00 06 00 ................
0060 00 00 c0 07 1c 00 00 00 00 00 c0 07 3c 00 00 00 ............<...
0070 00 00 c0 07 3c 00 00 00 00 00 78 78 78 78 78 78 ....<.....xxxxxx
i get the above output from tshark but the payload consists of packet arrival and departure time from a udp server how i need to retrieve arrival and departure time from above information.
To print both the packet as hex (-x) and the summary with the timestamp in tshark add the -P option. To get the timestamp as absolute instead of relative value add the -ta option. For more information see the documentation.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
How to calculate time duration by using awk for the following file:
02 0F 00 80 C9 CD AB 00 00 48 CF 00 00 00 00 00 00 6B E7 01 07 1A 16 1B 36 00 with Timestamp2014-03-12 18:46:59.986000
02 0F 00 80 CA CD AB 00 00 48 CF 00 00 00 00 00 00 6B E7 01 07 1A 14 DB 39 00 with Timestamp2014-03-12 18:47:02.446279
02 13 23 C8 B0 CD AB 00 00 FF FF E2 75 AC 21 4E 83 00 00 01 83 6C E7 01 11 1A 36 DD 39 00 with Timestamp2014-03-12 18:47:02.455278
02 03 12 00 B0 6B E7 01 03 1A FF FF FF FF with Timestamp2014-03-12 18:47:02.457279
02 17 00 80 CB CD AB 00 00 48 CF 00 10 E2 75 AC 21 4E 83 00 00 00 00 00 00 6B E6 01 07 1A 10 9B 3D 00 with Timestamp2014-03-12 18:47:06.196279
02 10 63 C8 B1 CD AB 00 00 E2 75 AC 21 4E 83 00 00 04 6A E6 01 0F 1A 14 9D 3D 00 with Timestamp2014-03-12 18:47:06.205278
02 03 12 00 B1 6C E6 01 03 1A FF FF FF FF with Timestamp2014-03-12 18:47:06.206279
In other words, last line timestamp value minus first line timestamp values.
Is this what you want (using GNU awk for mktime())?
$ cat tst.awk
sub(/.*Timestamp/,"") {
split($0,t,/[-:. ]/)
time[++nr] = mktime(t[1]" "t[2]" "t[3]" "t[4]" "t[5]" "t[6]) "." t[7]
}
END { print time[nr] - time[1] }
$ awk -f tst.awk file
6.22028
Thanks a lot #Ed Morton; it is not working with this example:
Number of saved packets= 373
Protocol: IEEE 802.15.4
Packet #0 :02 0F 00 80 C9 CD AB 00 00 48 CF 00 00 00 00 00 00 6B E7 01 07 1A 16 1B 36 00 with Timestamp2014-03-12 18:46:59.986000
###################################################################################
Packet #1 :02 0F 00 80 CA CD AB 00 00 48 CF 00 00 00 00 00 00 6B E7 01 07 1A 14 DB 39 00 with Timestamp2014-03-12 18:47:02.446279
###################################################################################
Packet #2 :02 13 23 C8 B0 CD AB 00 00 FF FF E2 75 AC 21 4E 83 00 00 01 83 6C E7 01 11 1A 36 DD 39 00 with Timestamp2014-03-12 18:47:02.455278
###################################################################################
Packet #3 :02 03 12 00 B0 6B E7 01 03 1A FF FF FF FF with Timestamp2014-03-12 18:47:02.457279
###################################################################################
Packet #4 :02 17 00 80 CB CD AB 00 00 48 CF 00 10 E2 75 AC 21 4E 83 00 00 00 00 00 00 6B E6 01 07 1A 10 9B 3D 00 with Timestamp2014-03-12 18:47:06.196279
###################################################################################
Packet #5 :02 10 63 C8 B1 CD AB 00 00 E2 75 AC 21 4E 83 00 00 04 6A E6 01 0F 1A 14 9D 3D 00 with Timestamp2014-03-12 18:47:06.205278
###################################################################################
Packet #6 :02 03 12 00 B1 6C E6 01 03 1A FF FF FF FF with Timestamp2014-03-12 18:47:06.206279
I have an OTI Copni device and I need to install a .cap file to this Copni device. So I have JCOP tools with Eclipse and I try to upload and install. It then gives this the indicated error. I presume this is happening because of a failed authentication.
cm> /term "winscard:4|SCM Microsystems Inc. SDI011G Contactless Reader 0"
--Opening terminal
> /card -a a000000003000000 -c com.ibm.jc.CardManager
resetCard with timeout: 0 (ms)
--Waiting for card...
ATR=3B 88 80 01 00 73 C8 40 00 00 90 00 62 ;....s.#....b
ATR: T=0, T=1, Hist=0073C84000009000
=> 00 A4 04 00 08 A0 00 00 00 03 00 00 00 00 ..............
(21592 usec)
<= 6F 65 84 08 A0 00 00 00 03 00 00 00 A5 59 9F 65 oe...........Y.e
01 FF 9F 6E 06 47 91 20 17 3F 00 73 4A 06 07 2A ...n.G. .?.sJ..*
86 48 86 FC 6B 01 60 0C 06 0A 2A 86 48 86 FC 6B .H..k.`...*.H..k
02 02 01 01 63 09 06 07 2A 86 48 86 FC 6B 03 64 ....c...*.H..k.d
0B 06 09 2A 86 48 86 FC 6B 04 02 15 65 0B 06 09 ...*.H..k...e...
2B 85 10 86 48 64 02 01 03 66 0C 06 0A 2B 06 01 +...Hd...f...+..
04 01 2A 02 6E 01 02 90 00 ..*.n....
Status: No Error
cm> set-key 255/1/DES-ECB/404142434445464748494a4b4c4d4e4f 255/2/DES-ECB/404142434445464748494a4b4c4d4e4f 255/3/DES-ECB/404142434445464748494a4b4c4d4e4f
cm> init-update 255
=> 80 50 00 00 08 C2 3F 4B C4 BE B6 E5 58 00 .P....?K....X.
(43622 usec)
<= 00 00 32 98 00 09 30 97 06 25 01 02 00 10 68 6C ..2...0..%....hl
E3 CA 2C 2B 4D 2C 4B 0D 0E 62 5F 8C 90 00 ..,+M,K..b_...
Status: No Error
cm> ext-auth plain
=> 84 82 00 00 10 EB FC 66 BC FA 30 91 58 5B 51 FA .......f..0.X[Q.
0C 46 D7 43 C9 .F.C.
(12557 usec)
<= 69 85 i.
Status: Conditions of use not satisfied
jcshell: Error code: 6985 (Conditions of use not satisfied)
jcshell: Wrong response APDU: 6985
Unexpected error; aborting execution
Can someone tell me how to upload a .cap file to this device?
Try ext-auth mac instead, the smart card is probably in the state OP_SECURE, which means that at minimal command MAC is required.
As JCOP tools is not publicly available nor open source, I'd suggest you try a publicly available piece of software instead:
https://github.com/martinpaljak/GlobalPlatform#globalplatform-from-openkms
(as the name of the github repository implies this is self-promotion)
During SSL 3.0 handshaking server responses with the following serverhello message
16 03 00 00 51 02 00
00 4d 03 00 4f a1 c1
eb e3 fb 00 a9 c8 25
25 48 6f 89 27 ec bb
80 f3 8c 5d db f7 6c
94 56 d8 34 7a b5 9d
02 20 54 ab 20 ea 05
a6 38 6f ee 55 40 ae
af e2 5d ae 2a 4d c1
c6 f4 09 a7 08 b1 c5
49 39 87 82 d3 f7 00
39 00 00 05 ff 01 00
01 00
I understand this response as follows:
Content-type: 22 (Handshake protocol)
Version: 3.0
Length: a1 (81 bytes)
Content-type: 02 (ServerHello)
Length: 4d (77 bytes)
Version: 3.0
Random: 4f a1 c1 eb e3 fb 00 a9
c8 25 25 48 6f 89 27 ec
bb 80 f3 8c 5d db f7 6c
94 56 d8 34 7a b5 9d 02
SessionID Length: 20 (32 bytes)
SessionID: 54 ab 20 ea 05 a6 38 6f
ee 55 40 ae af e2 5d ae
2a 4d c1 c6 f4 09 a7 08
b1 c5 49 39 87 82 d3 f7
Cipher Suite: 00 39
Compression method: 00
But i can't understand how the last 7 bytes should be interpreted: 00 05 ff 01 00 01 00
That would be the renegotiation_info extension, as defined in RFC 5746:
o If this is the initial handshake for a connection, then the
"renegotiated_connection" field is of zero length in both the
ClientHello and the ServerHello. Thus, the entire encoding of the
extension is ff 01 00 01 00. The first two octets represent the
extension type, the third and fourth octets the length of the
extension itself, and the final octet the zero length byte for the
"renegotiated_connection" field.