We Keep Coding

How to convert rtp packet payload bytes H264/90000 to any video data?

Studying the sip protocol, I got to the topic of the H264 codec. I began to receive data in the form of rtp packets. I managed to successfully get the following data from the package: Payload type (in my case 97), Timestamp, Sequence number and payload data (byte array). Next, I want to draw images encoded in this data. On the android platform, I use the android.media.MediaCodec class. I follow examples like MediaCodec failing on S7.
I create an instance of MediaCodec. Configuring with MediaFormat. Then I transfer the received bytes to inputBuffer and wait for updates via dequeueOutputBuffer. In my case, the dequeueOutputBuffer method always returns MediaCodec.INFO_TRY_AGAIN_LATER.
I was trying to process bytes before passing to MediaCodec. Defined nal_unit_type. I get 7, 8 and 28. I also defined startBit and endBit in the package. I tried to glue all packages starting with startBit and ending with endBit and transfer them to MediaCodec in a glued form. The result is the same - the dequeueOutputBuffer method always returns MediaCodec.INFO_TRY_AGAIN_LATER
Tell me what I missed.
The server sends the following information about the video to the SDP:
m=video 23542 RTP/AVP 97
b=TIAS:4096000
a=content:main
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=428028; max-fs=8192; packetization-mode=0; max-br=4096; max-fps=3000
a=sendrecv
Edit #1
For example, first received packet payload (array of unsigned byte):
27 42 00 28 95 a0 1e 00 89 f9 70 11 00 00 03 00
42 00 28 95 a0 1e 00 89 f9 70 11 00 00 03 00 01
00 28 95 a0 1e 00 89 f9 70 11 00 00 03 00 01 00
I would venture to suggest that this is a Single NAL Unit Packet. This packet has no padding.
By rfc3984/1.3 i got in first byte:
// 0 1 2 3 4 5 6 7
// +-----+---------+
// | type |
// +-----+---------+
val nal_unit_type = payload[0].toInt() and 0b0_0_0_1_1_1_1_1
nal_unit_type == 7 And I decided that this package contains Sequence Parameter Set data. Next, I want to get the decrypt SPS and get useful information from it (width and height, frame rate ...)
I got in second byte:
// 0 1 2 3 4 5 6 7
// +-+-+-----------+
// |s|e|
// +-+-+-----------+
val start_bit = payload[1].toInt() and 0b1_0_0_0_0_0_0_0 != 0
// +-+-+-----------+
val end_bit = payload[1].toInt() and 0b0_1_0_0_0_0_0_0 != 0
start_bit == false and end_bit == true
Starting from the third byte (payload[2]), I parse the SPS.
Edit #2
I was wrong when I decided that the second byte for nal_unit_type 7 or 8 is the FU header (with start and end bits). The second byte of the payload is already the first byte of the SPS. Thus, I managed to successfully decrypt the SPS and, for example, find out that the image size 1920/1080 is encrypted there (as was expected). But this has not yet helped me in any way to draw the resulting video stream to the android surface view.

How to get specific lines from the file ( between two sections)?

I'm trying to read specific lines in-between two sections using Java 8.
I need to get the information in between ~CURVE INFORMATION and ~PARAMETER INFORMATION
I was able to get it using by checking startsWith() or equals and start storing the lines in some stringbuilder or collection. But is there any method available to get some specific lines in-between some sections.
I was looking at below questions for reference.
How to read specific parts of a .txt file in JAVA
How to read specific parts of the text file using Java
Sample data from file:
~WELL INFORMATION
#MNEM.UNIT DATA TYPE INFORMATION
#---------- ------------ ------------------------------
STRT.FT 5560.0000: START DEPTH
STOP.FT 16769.5000: STOP DEPTH
STEP.FT 0.5000: STEP LENGTH
NULL. -999.2500: NULL VALUE
COMP. SHELL: COMPANY
~CURVE INFORMATION
#MNEM.UNIT API CODE CURVE DESCRIPTION
#---------- ------------ ------------------------------
DEPT.F :
SEWP.OHMM 99 000 00 00:
SEMP.OHMM 99 120 00 00:
SEDP.OHMM 99 120 00 00:
SESP.OHMM 99 220 01 00:
SGRC.GAPI 99 310 01 00:
SROP.FT/HR 99 000 00 00:
SBDC.G/C3 45 350 01 00:
SCOR.G/C3 99 365 01 00:
SPSF.DEC 99 890 03 00:
~PARAMETER INFORMATION
#MNEM.UNIT VALUE DESCRIPTION
#---------- ------------ ------------------------------
RMF .OHMM -: RMF
MFST.F -: RMF MEAS. TEMP.
RMC .OHMM -: RMC
MCST.F -: RMC MEAS. TEMP.
MFSS. -: SOURCE RMF.
MCSS. -: SOURCE RMC.
WITN. MILLER: WITNESSED BY
~OTHER INFORMATION

Using Java9 you can do it elegantly with streams
public static void main(String[] args) {
try (Stream<String> stream = Files.lines(Paths.get(args[0]))) {
System.out.println(stream.dropWhile(string -> !"~CURVE INFORMATION".equals(string)).takeWhile( string -> !"~PARAMETER INFORMATION".equals(string)).skip(1).collect(Collectors.joining("\n")));
} catch (IOException e) {
e.printStackTrace();
}
}
What makes it pleasing is the declarative nature of streams, your literally writing code that says drop elements until start mark then take elements until end mark and join them using "\n"! Java9 added takeWhile and dropWhile, I'm sure you can implement them or get their implementation from a library for java 8. Of course this is just another way to achieve the original goal.

Regexp for german phone number format

I try to get phone numbers from string in german format. But I don't get it to full run. The input text is a full HTML-Page with lots of content, not only the numbers.
Possible Formats:
(06442) 3933023
(02852) 5996-0
(042) 1818 87 9919
06442 / 3893023
06442 / 38 93 02 3
06442/3839023
042/ 88 17 890 0
+49 221 549144 – 79
+49 221 - 542194 79
+49 (221) - 542944 79
0 52 22 - 9 50 93 10
+49(0)121-79536 - 77
+49(0)2221-39938-113
+49 (0) 1739 906-44
+49 (173) 1799 806-44
0173173990644
0214154914479
02141 54 91 44 79
01517953677
+491517953677
015777953677
02162 - 54 91 44 79
(02162) 54 91 44 79
I have tried:
$regex = '~(?:\+?49|0)(?:\s*\d{3}){2}\s*\d{4,10}~';
if(preg_match_all($regex, $input_imprint , $matches)){
print_r($matches);
}
But it doesn't match only a few formats. I have no idea to do it.

Here is a regex to match all your formats.
I would suggest then to replace all unwanted characters and you got your desired result.
(\(?([\d \-\)\–\+\/\(]+)\)?([ .\-–\/]?)([\d]+))
If you need a minimum length to match your numbers, use this:
(\(?([\d \-\)\–\+\/\(]+){6,}\)?([ .\-–\/]?)([\d]+))
https://regex101.com/r/CAVex8/143
updated, thanks for the suggestion #Willi Mentzel

[0-9]*\/*(\+49)*[ ]*(\([0-9]+\))*([ ]*(-|–)*[ ]*[0-9]+)*
Check this link: https://regex101.com/r/CAVex8/1
May introduce some false positives.

This one solved my problem (extracting phone numers from emails):
r"\+?[0-9]+([0-9]|\/|\(|\)|\-| ){10,}"
A plus sign optional at the front, followed by at least 1 number, followed by at least 10 numbers or delimiting characters such as /, (, ) or - or a space.
(There is no official "smallest number of digits" for a telephone number, but I assume they are all at least 11 digits long)
I'm adding this because #Kakul 's solution matched any lien of my text, and using #despecial 's my code would not terminate. (I am guessing it is too computationally expensive for my pc)

This is no solution for the asked question, just an advice for matching phonenumbers!
If you are about to store telephone numbers for you first time, then limit the amount of different accepted formats. Get rid of these for example:
(06442) 3933023
042/ 88 17 890 0
+49(0)121-79536 - 77
02162 - 54 91 44 79
Why?
You need to test more possible ways of inputting an invalid value.
Those formats you absolutely need to concider according to DIN 5008:
0873 376461
03748 37682358
05444 347687-350
0764 812632-41
0180 2 12334
0800 5 23234213
+49 30 3432622-113
0179 1111111
Here is what I came up with: Regex
^(([+]{1}[1-9]{1}[0-9]{0,2}[ ]{1}([1-9]{1}[0-9]{1,4}){1}[ ]{1}([1-9]{1}[0-9]{2,6}){1}([ -][0-9]{1,5})?)|([0]{1}[1-9]{1}[0-9]{1,4}[ ]{1}[0-9]{1,8}([ -][0-9]{1,8})?)?)
Positives:
06429 1111
06901 306180
06429 231
0800 3301000
0179 1111111
0873 376461
03748 37682358
05444 347687-350
0764 812632-41
0180 2 12334
0800 5 23234213
+49 6429 1111
+49 39857 2530
+55 11 2666-0054
+300 11 2666-0054
+49 641 20106 0
+49 641 20106
+49 30 3432622-113
Negatives:
++49 157 184977
+300 11 0000-0000
(06442) 3933023
(02852) 5996-0
(042) 1818 87 9919
06442 / 3893023
06442 / 38 93 02 3
06442/3839023
042/ 88 17 890 0
+49 221 - 542194 79
+49 (221) - 542944 79
0 52 22 - 9 50 93 10
+49(0)121-79536 - 77
+49(0)2221-39938-113
+49 (0) 1739 906-44
+49 (173) 1799 806-44
0173173990644
0214154914479
01517953677
+491517953677
015777953677
02162 - 54 91 44 79
(02162) 54 91 44 79
saddsadasdasd
asdasd
asdasd asdasd asd
asdasd
kjn asohas asdoiasd
23434 234 234 23
323
23434 234----234
///// ----
// id8834 3493934 //

Hey i have a little enhancement for despecial‘s Regex:
(\(?([\d \-\)\–\+\(]+\/?){6,}\)?([ .\-–\/]?)([\d]+))
It filters numbers that have too high occurrencies of /

Android BLE BluetoothAdapter.LeScanCallback scanRecord length ambiguity

I am using the example project from google (BluetoothLeGatt) to receive data from a BLE device and trying to read a specific byte within it's scanRecord obtained by the onLeScan method.
My problem is that there is missmatch between the data I am observing in the network and what I see on logs.
This is on Android 4.3 and using a Samsung Galaxy S4 to test it.
To verify that the scanRecord logs are correct on Android, I am using TI's Packet Sniffer to observe the byte stream being broadcasted by the device, and here it is:
That is 31 bytes of data being broadcasted by the device to the network, and there are no other working devices around.
02 01 1A 1A FF 4C 00 02 15 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 0C C6 64
On the other hand, Android logs claim that the data being received has the length of 62 bytes and it matches the data until the 29th[0-indexed] byte, having 0s for the rest of the data.
02-12 15:34:09.548: D/DEBUG(26801): len: 62
data:02011a1aff4c000215000000000000000000000000000000000000000cc60000000000000000000000000000000000000000000000000000000000000000
And this is the code piece I used in order to obtain the logs within the LeScanCallback method:
int len = scanRecord.length;
String scanHex = bytesToHex(scanRecord);
Log.d("DEBUG", "len: " + len + " data:" + scanHex);
The method used to convert byte array to hex representation:
private static String bytesToHex(byte[] bytes) {
char[] hexChars = new char[bytes.length * 2];
int v;
for ( int j = 0; j < bytes.length; j++ ) {
v = bytes[j] & 0xFF;
hexChars[j * 2] = hexArray[v >>> 4];
hexChars[j * 2 + 1] = hexArray[v & 0x0F];
}
return new String(hexChars);
}
I used a few other example projects including Dave Smith's example and RadiusNetworks' Android iBeacon Library and I ended up with the same results. I can't possibly understand why do I receive 62 bytes of data when "Packet Sniffer" shows (and I also know) that it should be 31 bytes. This would not be my main concern if I was able to read the data in the last byte correctly (I get 00 instead of 64 from Android's BluetoothAdapter). But that is not the case either.
I would appreciate any suggestions about what might potentially be the reason for this missmatch for both the data(last byte only) and the data size between what Android receives and what is actually on the network.

Your transmission is malformed, containing 31 bytes of payload data (PDU length of 37) when its internal length fields indicate it should in total contain only 30 bytes (PDU length 36).
Let's take a look at your data
02 01 1a
This is a length (2) of type codes - 01 and 1a, and good so far
1a ff 4c ...
Now we have a problem - the 1a is a length code for this field (manufacturer specific data), value of 26. Yet 27 bytes of data follow it in your case, instead of the proper 26 you have indicated you will provide.
Now, if you have a properly formed packet, you will still get a larger buffer padded with meaningless (likely uninitialized) values following the proper content, but you can simply ignore that by parsing the buffer in accordance with the field-length values and ignoring anything not accounted for in the proclaimed lengths.
But with your current malformed packet, the copying of packet data to the buffer stops at the proclaimed content size, and the unannounced extra byte never makes it into the buffer your program receives - so you see instead something random there, as with the rest of the unused length.
Probably, when you made up your all-zeroes "region UUID" (might want to rethink that) you simply typed an extra byte...

Decode H264 From Array of Integers

I'm trying to decode a H264 raw protocol from a camera but I'm having some problems using the Jcodec H264Decoder. I receive an array of integers with the information from the camera. Below a sample of the data:
array: 00 00 01 FD 00 00 14 69 00 00 00 01 61 E4 80 6F D3 5B 76 97 DF 04 3A EF 54 97 0E D9 F5...more
The code I'm using is :
ByteBuffer bb = ByteBuffer.wrap( Utils.intArrayToByteArray(array, arraySize) );
bb.rewind();
// Create a buffer to hold the output picture which is big enough
Picture outBuffer = Picture.create( 1920, 1088, ColorSpace.YUV420 );
Picture pic = _decoder.decodeFrame( bb, outBuffer.getData() );
BufferedImage bufferedImage = JCodecUtil.toBufferedImage( pic );
When I try to run it, I get NullPointerException as follow:
Exception in thread "Thread-6" java.lang.NullPointerException
at org.jcodec.codecs.h264.H264Decoder$FrameDecoder.decodeFrame(H264Decoder.java:82)
at org.jcodec.codecs.h264.H264Decoder.decodeFrame(H264Decoder.java:61)
at br.com.grupogiga.security.xm.player.jcodec.JCodecPlayer.test_readNals(JCodecPlayer.java:122)
at br.com.grupogiga.security.xm.player.jcodec.JCodecPlayer.processNAL(JCodecPlayer.java:69)
at br.com.grupogiga.security.xm.player.XMH264Player$1$2.NALArrived(XMH264Player.java:143)
at br.com.grupogiga.security.xm.protocols.ProtocolParser.emitNALArrived(ProtocolParser.java:408)
at br.com.grupogiga.security.xm.protocols.ProtocolParser.run(ProtocolParser.java:121)
at java.lang.Thread.run(Thread.java:722)
What I'm doing wrong ?? How do I decode the data using JCodec ?
Thanks in advance.

That looks to me like no fault of your own, but rather an internal JCodec bug. You can check through the issues on their issue tracker to see if this is known. If not, you may want to create an issue for this. Provide the stack trace and as much information as you can.

Are you certain that you're getting an int array? It would appear to be a byte array from your print-out. I would suggest not doing the array conversion and also not doing a rewind; ByteBuffer.wrap will already put you at position 0 in the buffer. The 00 00 01 is a start of NAL marker and the FD is the NAL type btw.