Tuesday, November 23, 2010

RTMPDUMP

RTMPDUMP is a good tools to dump rtmp stream into a file and analyze the rtmp protocol.

Below are some commands

VOD

rtmpdump.exe -r "rtmp://host:port/app/path/file.mp4" -o "output.mp4" -z

Variables
app -> your rtmp application name
path -> your rtmp path in the application to the file (optional)
file.mp4 -> your VOD file name
output.mp4 -> your output file name to local disk

Commands
-z -> debug print mode
-r -> rtmp url
-o -> output file

Live

rtmpdump.exe -r "rtmp://host:port/app/path" -v -y "live.stream" -o "output.mp4" -z

Variables
app -> your rtmp application name
path -> your rtmp path in the application to the file (optional)
live.stream -> your live stream path
output.mp4 -> your output file name to local disk

Commands
-z -> debug print mode
-r -> rtmp url
-o -> output file
-v -> live stream (denoting this will provide play time to a negative value)
-y -> the play path for your stream

If you run rtmpdump at command prompt, it will print its debug message at stdout. However, these debug message cannot be pipe to other output (such as writing debug output to file). The reason being is rtmpdump printing these debug message in stderr.

One way to get the output is to write a Java class that capture the error stream output from rtmpdump.

Thursday, November 18, 2010

RTMP Part 10 - Handshake

In the RTMP specification provided by Adobe, it did not mention the importance of handshake.

Also, the RTMP specification 1.0 that is widely available online is "outdated". The reason it is "outdated" because this specification defined the handshake only for flv streaming. If you use this handshake for connecting H.264 stream, it will never work. Below are from RTMP specification 1.0 handshake




In the RTMP 1.0 specification, 5th to 8th bytes are zero bytes in the first client and server message. That in turn saying that it only support flv stream. The client will not play the H.264 stream even if you have sent correct onMetaData and configuration information. So, if you are working on a flash media server for serving H.264 stream, you should take note of this handshake.

Client versions equal to or greater than Flash 9,0,124,0 require a nonzero value as the fifth byte of the handshake request. Furthermore, Flash 10.0.32.18 seems have changed the handshake again.

I will describe the handshake with my best knowledge with the 3 way handshake

1. Client send a 1537 bytes message to server. The first byte in the message is still the version byte. Now, it have 2 types, 0x03 (normal RTMP) and 0x06 (encrypted RTMP). The next four bytes are timestamp. The next four bytes are flash client version. The remaining bytes are challenge bytes for the server to validate the client connection using SHA 256 Hash digest.

2. If the server validate the client correctly, it should reply a 3073 bytes message to client. The first bytes is version byte, 0x03. The next 1536 bytes are challenge bytes from server (first 4 bytes are timestamp, next four bytes are server version and the remaining bytes are challenge bytes). The next 1536 byte contains 1504 bytes of pure random data and 32 bytes for comparison hash value.

3. If the client validate the server correctly, it will reply a 1536 bytes message. The first byte is version byte, 0x03. The remaining bytes are the first 1536 bytes of the server challenge message.

Wednesday, November 10, 2010

RTMP Part 9 - RTMP URL

In general, RTMP server accept 2 types of URL connection.

1. Flash player

Open source player such as flowplayer and JW Player use this format

I am referring to flowplayer in this example, but in general, they have the equivalent variables.


Most server requires you to define at least an application name.

For URL, they commonly support format tag flv, m4v, mp4. So, for flv, it will be


In Wowza VOD example, the RTMP setting for flowplayer will be


2. Single RTMP URL

There are application that requires only single RTMP URL. For example, VLC and rmptdump.exe

The single RTMP URL is


For using rtmpdump to connect to Wowza VOD, the RTMP URL is


Please note that most single RTMP URL treat and information after application instance as path to the file. For example


These 2 URL is the same. They are referring that sample.mp4 is at the path folder1/folder2/ of the vod/app1.

MP4 File Format Part 2

ISO IEC 14496-12 defined the base media file format for MPEG file structure.

ISO IEC 14496-15 Information technology — Coding of audio-visual objects — Part 15: Advanced Video Coding (AVC) file format extends part 12 to provide specific atom/box type for AVC (H.264)

Mdat Atom

As mdat is about frame, I have to mention about AVC sample structure


ISO 14496-15 define AVC sample structure as externally framed sample and have a frame length supplied by external framing. Thus, AVC access unit means a set of NAL units where each NAL has

  • a usually 4 bytes fields to denote the frame size
  • followed by a NAL unit

With that in mind, the screenshot shows a the red box denote the frame size (4 bytes). The blue box is the start of the frame, in this case, it is H.264 Non-IDR frame. See 5.2.3 of that document.

AVC Decoder Configuration Record

H.264 require decoder configuration data to initialize the decoder prior to any decoding process. Thus, MP4 file must have this record in the Movie Box.

These decoder configuration record data are stored in STSD (sample decription box) - Visual Sample Entry. For H.264, this is stored in a avc1 atom.

Before going into that, I should provide some information regarding the AVC decoder configuration record. Below is the AVC decoder configuration record in a class structure.


configurationVersion - 8 bits int value that is always 1. If decoder see unrecognized version, the decoder should not decode the stream

AVCProfileIndication - 8 bits int value that contains profile code in ISO IEC 14496-10

profile_compatibility - 8 bits int value that exactly the same byte that occurs between profile_IDC and level_IDC in the SPS

AVCLevelIndication - 8 bits int value that define the level code

lengthSizeMinusOne - 2 bits int value that indicate the length in bytes of the NALUnitLength field in an AVC video sample

numOfSequenceParameterSets - 5 bits int value that indicate the number os SPSs that are used as the initial set of SPSs for decoding the AVC elementary stream

sequenceParameterSetLength - 16 bits int value that indicate the length in bytes of SPS

sequenceParameterSetNALUnit - the actual SPS. The length is defined by the preceding sequenceParameterSetLength field

numOfPictureParameterSets - 8 bits int value that indicate the number of PPS that are used as the initial set of PPSs for decoding the AVC elementary stream

pictureParameterSetLength - 16 bits int value that indicate the length in bytes of the PPS

pictureParameterSetNALUnit - the actual PPS. The length is defined by the preceding pictureParameterSetLength field

acv1 -Sample Description Name And Format


avc1 is an AVC visual sample entry. It has a avcC (AVC Configuration Box) atom. This atom contains an AVCDecoderConfigurationRecord as state above.

I have broker down and highlighted those value in acvC atom

Red - these 4 bytes in red denote the length of the atom, including the length and type field
Green - these 4 bytes in green denote the type field
Purple - those bytes surrounded by purple is the AVCDecoderConfigurationRecord. So, the length of AVCDecoderConfigurationRecord is length of atom - 8

By following AVCDecoderConfigurationRecord structure, you can parse the values easily.

For example,

0x01 - the first byte is configurationVersion = 1

0x42 - the second byte is AVCProfileIndication = 66

0xC0 - the third byte is profile_compatibility = 192

0x15 - the fourth byte is AVCLevelIndication = 21

Reference: ISO IEC 14496-12 and ISO IEC 14496-15

Monday, November 8, 2010

MP4 File Format Part 1

This is a MP4 file format notes that reference from ISO IEC 14496-12 2005 edition about Information technology — Coding of audio-visual objects — Part 12: ISO base media file format

This is not designed for details explanation of each atom. For detail information, please read the ISO IEC 14496-12 document.

General Format


In general, MP4 file format has the following structure

ftyp
  • File type box that denote the mp4 media type
mdat
  • Media data box which contains the actual AV frames.
  • Within a mdat, there are chunks and samples
moov
  • Movie box which is the container for all metadata
  • Each moov has have a mvhd (Movie header box)
  • It can contains N trak box. Each trak box contains media specific meta data information Usually, it will have 2 tracks (video and audio)
  • More importantly, it contains sample information such as stsd, stts, stsz stsc, stco, etc...

Mdat Atom

MPEG4 sample


H.264 sample


Mdat is the media data atom which contain video and audio frames. As you can see from the screenshot, it is separated into 2 tracks (video and audio). Each track has multiple chunks and each chunks has multiple samples. Usually, you can treat each sample as a AV frame.

The number of sample in the chunk is defined in stsc atom (sample to chunk box) and the chunk offset is defined in stco atom (chunk offset box).

For MPEG4 (see MPEG4 sample), the red box denote the start code for MPEG4 Elementary stream. ISO 14496-14 states that MPEG4 media-data is stored as access units, a range of contiguous bytes for each access unit (a single access unit is the definition of a ‘sample’ for an MPEG-4 media stream). See 3.1.1 of the document

For H.264 (see H.264 sample), the red box denote the frame size (4 bytes). The blue box is the start of the frame, in this case, it is H.264 Non-IDR frame. ISO 14496-15 states that H.264 sample needs a length field preceding each NAL. See 5.2.3 of that document.

STSC - Sample To Chunk Box


The stsc tells you the number of samples in a chunk. To read this, you need to read first chunk and samples per chunks together. In the screenshot, first chunk has 1, 3, 5, 6..... and samples per chunk has 4, 5, 4, 5.... This means the followings:

chunk 1 - 2 has 4 samples
chunk 3 - 4 has 5 samples
chunk 5 has 4 samples

and so on...

STCO - Chunk Offset Box


This box tells you the location of the chunk. This offset is referred from the start of file. In the screenshot, it has values of 1516, 4880,...

As this is a video track, that means the first video chunk is located at 1516 bytes of the file.

STSZ - Sample Size Box


This box tell you the size of each sample in the chunk. It also tells you the number of sample counts in this track.

If you look at the entry size, it state 2229, 529,....

That means the first sample has 2229 bytes and second samples has 529 bytes

STSD - Sample Description Box


This box tells you the codec type, initialization and any information requires for the coding in the track.

As you can see in the screenshot, it contains AVC configuration box. Those are the information required (SPS, PPS, etc..) for decoding this video track.

Reference: ISO IEC 14496-12, ISO IEC 14496-14, ISO IEC 14496-15

Hadoop - How to setup a Hadoop Cluster

Below is a step-by-step guide which I had used to setup a Hadoop Cluster Scenario 3 VMs involved: 1) NameNode, ResourceManager - Host...