JustinTodd
11th July 2005, 19:46
Hello! I am in the process of reverse engineering a protocol which essentially streams H.263+ video over RTP.
Right now I have a tester program that sends the appropriate tcp data to request a stream, and a udp client which
recieves the data into a file. After the data is in a file i use Mplayer for Linux (Which decides to use FFMpegs h.263
codec to decode the video).
Here is what I know so far:
- It is using standard RTP (16 byte fixed size header always). The only byte in the header that is toggled is the
Marker bit. When the marker bit is zero, it indicates that the current frame is split across another packet.
- The video stream format is H.263+. I can actually decode the video and view it using FFMpegs decoder
My problem:
- Although the decoder works perfectly when i use QCIF to encode (or use CIF+ but point the camera at the wall or something that doesnt move), anything higher will cause a ton of decoder
errors to occur:
[h263 @ 0X85A0678] illegal dc 128 at 17 11
[h263 @ 0X85A0678] Error at MB: 270
[h263 @ 0X85A0678] concealing 120 DC
- When I anaylize what is happening at the network layer, I notice that all udp packets are under 1450 bytes. is this normal?
- I also notice that I'll only get errors when the frame sizes exceed 1450 bytes and are split across multiple rtp packets (ie. Marker bit = 0)
- When I analyze the H263 stream (ie. strip off the first 16 byte rtp header) the first few bytes look like this:
00 00 82 FA 1C 10 47 0B EE... // first packet of the frame. total size 1407 bytes. Marker bit 0
00 00 00 00 60 33 84 86 ... // last packet of the frame. total size 720 bytes. Marker bit set to 1
- When analyzing several packets, I notice that the first packet of an h263 frame starts with 2 0 bytes followed by a 2 byte sequence number that increments by 4 every frame.
The next 3 bytes are always 1C 10 47.
- I also notice that for packets with a continued frame, the first 4 bytes are always 0x00, and the remaining are seemingly random.
My questions for the experts:
- How can I make some sense of this H263 data? (after i strip off the 16 byte rtp header).
- Do you have any idea why large frames (due to higher resolution and increased movement) are causing decoder errors? I beleive that I'm not stripping off the correct amount of bytes from packets containing continued frames. am i right?
Right now I have a tester program that sends the appropriate tcp data to request a stream, and a udp client which
recieves the data into a file. After the data is in a file i use Mplayer for Linux (Which decides to use FFMpegs h.263
codec to decode the video).
Here is what I know so far:
- It is using standard RTP (16 byte fixed size header always). The only byte in the header that is toggled is the
Marker bit. When the marker bit is zero, it indicates that the current frame is split across another packet.
- The video stream format is H.263+. I can actually decode the video and view it using FFMpegs decoder
My problem:
- Although the decoder works perfectly when i use QCIF to encode (or use CIF+ but point the camera at the wall or something that doesnt move), anything higher will cause a ton of decoder
errors to occur:
[h263 @ 0X85A0678] illegal dc 128 at 17 11
[h263 @ 0X85A0678] Error at MB: 270
[h263 @ 0X85A0678] concealing 120 DC
- When I anaylize what is happening at the network layer, I notice that all udp packets are under 1450 bytes. is this normal?
- I also notice that I'll only get errors when the frame sizes exceed 1450 bytes and are split across multiple rtp packets (ie. Marker bit = 0)
- When I analyze the H263 stream (ie. strip off the first 16 byte rtp header) the first few bytes look like this:
00 00 82 FA 1C 10 47 0B EE... // first packet of the frame. total size 1407 bytes. Marker bit 0
00 00 00 00 60 33 84 86 ... // last packet of the frame. total size 720 bytes. Marker bit set to 1
- When analyzing several packets, I notice that the first packet of an h263 frame starts with 2 0 bytes followed by a 2 byte sequence number that increments by 4 every frame.
The next 3 bytes are always 1C 10 47.
- I also notice that for packets with a continued frame, the first 4 bytes are always 0x00, and the remaining are seemingly random.
My questions for the experts:
- How can I make some sense of this H263 data? (after i strip off the 16 byte rtp header).
- Do you have any idea why large frames (due to higher resolution and increased movement) are causing decoder errors? I beleive that I'm not stripping off the correct amount of bytes from packets containing continued frames. am i right?