Posted By

rowntreerob on 08/18/11


java rtsp media rtp amr filesink

Versions (?)

RTSP - RTP - AMR raw audio packet handler

 / Published in: Bash

notes - handling raw audio stream delivered over RTP from Youtube servers gaps in java packages to handle 'messageReceived' over the network and to handle RTP dynamic packet headers (see rfc2198) while parsing for the start of hex data for the audio stream in the packet. In the pcap, there are 4 dynamic headers starting around Ox32 in the packet. Those 4 headers NOT being handled by packetHandler in libStageFright.

  1. docs:
  5. tools:
  6. wireshark
  7. hexdump
  9. wireshark packets:
  10. :: pcap file for AMR-NB w/ RFC 2198 dynamic RTP headers
  14. java packages:
  15. RTSPClientLib.tar.gz on
  18. cpp packages:
  21. principal packetHandlers:
  22. live.livemedia.MultiFramedRTPSource::networkReadHandler1()
  23. com.biasedbit.efflux.packet.DataPacket Class
  25. **ISSUE** rfc2198 in libstagefright
  26. packet details:
  27. packets shown in the wireshark pictures are:
  28. RTP raw Audio streams
  29. dynamic packet type '99' per RTP RFC
  30. AMR/8000/1 at 12.2 k bandwidth ( amr frame format type='7' )
  31. packet length 375 hdr length 54 : when call java getPacketData you get len=321
  32. java len includes the 13 bytes of 4 rfc2198 redundant hdrs
  33. first raw audio frame inside packets at disp. 0x0044 in the dump
  34. 0x3c is the 1 byte frame header in the raw audio stream
  36. issue: 13 bytes at disp 0x36 as shown in wireshark images above does not correspond to the
  37. rfc packet-header docs on the header fields 'CSRC' and 'Extension Headers'
  38. These 13 bytes are 4 consequtive dynamic headers (rfc2198) that do NOT get handled by the call in java
  39. to getPacketBody(). The java handlers do not seem to know what to do with those 13 bytes??
  41. issue: if you are wifi dwnld on the stream, you also have to insert 0x3c frame headers every 32 bytes so that the file can be read back and played with proper AMR decode. The cpp
  42. mplayer fileHandler takes care of this, java does not. The cpp fileHandler just starts at
  43. 0x40 and then inserts frame header at 32 byte boundaries.
  45. java discrepancy:
  46. calling packet.getData() or packet.getDataAsArray() return object can not be passed
  47. directly to a file sink. Response has extra 16 byte preface before the start of the
  48. first audio frame. '0xf0 bc bc bc bc bc bc bc bc bc' at the start of the response are
  49. in the raw wireshark packet starting at 0x0036 in the dump.

Report this snippet  

You need to login to post a comment.