I am trying to fetch the dimensions (Height and width) from a H264 stream. I know that to fetch the same details from a mpeg2 stream you have to look at the four bytes following the sequence header start code ((01B3)). Will the same logic work for H264? Would appreciate any help I get..
4 Answers
NO!!!
You must run a complex function to extract video dimensions from Sequence Parameter Sets. How to do this? Well first you must write your own Exp-Golomb decoder, or find one online... in live555 source code somewhere there is one for example...
Then you must get one SPS frame. It has NAL=0x67
(NAL is the first byte in a H.264 frame) and you can find it as Base64 encoded string in SDP under sprop-parameter-sets
its the first Base64 string before the first comma. Other comma separated strings there are Picture Parameter Sets... This is one SPS from SDP Z0KAKYiLQDIBL0IAAB1MAAK/IAg=
you need to decode something like this from Base64 into a byte array.
Then you must extract RAW BYTE SEQUENCE PAYLOAD that is followed by NAL UNIT HEADER in that byte array!!! It is usually one byte long, but read on just to be sure... RBSP contains the bytes needed to run the seq_parameter_set_data( )
function. So you need to strip off the NAL UNIT HEADER first (one or more bytes).
Here it is the function that extracts RBSP bytes from SPS NAL UNIT:
Then when you have SPS (RBSP bytes) you need to perform a function that parses bits in this byte array. Here's the function with all the parameters parsed there (whole document can be found here: http://www.itu.int/rec/T-REC-H.264-201003-I/en and its free):
There you can see some strange stuff... first, your video dimensions are calculated like this:
Width = ((pic_width_in_mbs_minus1 +1)*16) - frame_crop_right_offset*2 - frame_crop_left_offset*2;
Height = ((2 - frame_mbs_only_flag)* (pic_height_in_map_units_minus1 +1) * 16) - (frame_crop_top_offset * 2) - (frame_crop_bottom_offset * 2);
Second, and most important, in DESCRIPTOR column of this code table, is stated what you should do to read the bold text parameter in the first column. This is what values in there mean:
- u(N) - Read an unsigned number which is N bits long
- s(N) - Read a signed number which is N bits long
- ue(v) - Read an unsigned Exp-Golomb number (v is for variable length, so its same as
ue()
) - se(v) - Read a signed Exp-Golomb number
This is where your Exp-Golomb decoder comes in handy...
So, implement this function, parse SPS, and you will get your Width and Height. Enjoy... :)
-
What are those ScalingList4x4[], DefaultScalingMatrix4x4Flag[], UseDefaultScalingMatrix8x8Flag[] arrays? Are they defined as a constant values? – Novalis Oct 26 '11 at 15:32
-
I really don't know, but in that document I provided, you can probably see what are those... :/ UPDATE: It looks like that document is not public any more... you will have to login as I see... – Cipi Oct 26 '11 at 15:46
-
2Well i find a public one... http://www-ee.uta.edu/Dip/Courses/EE5359/H.264%20Standard2007.pdf but not usefull info about those... – Novalis Oct 26 '11 at 15:55
-
-
do you know where I can find info about how to encode sps/pps from decimal to base64? couldnt find it in the spec – Bob Mar 22 '12 at 18:01
-
That is the standard Base64 encoding! Just google for the sample code for your programming language there are MANY samples, like this one for C++ (http://www.adp-gmbh.ch/cpp/common/base64.html), or ask a question here... – Cipi Mar 23 '12 at 09:39
-
1I don't know where you get Base64 from, that's not used anywhere in H.264. Everything in the SPS is Exp-Golomb coded. You must be looking at some software that parses it to Base64 for convenience. – SilverbackNet Jul 03 '14 at 00:17
-
Where would the * 2 for the cropping values come from? In the H264 ITU 7.4.2.1.1 SPS semantics, you can read that you multiply the crop value by CropUnitX and CropUnitY. If ChromaArrayType is - than CropUnitX is 1 and CropUnitY is 2-frame_mbs_only_flag. So I see no reason to have a hard set 2* here... thanks – jyavenard Apr 07 '15 at 08:33
The size calculations are wrong unfortunatly and should be:
width = ((pic_width_in_mbs_minus1 +1)*16) - frame_crop_left_offset*2 - frame_crop_right_offset*2;
height= ((2 - frame_mbs_only_flag)* (pic_height_in_map_units_minus1 +1) * 16) - (frame_crop_top_offset * 2) - (frame_crop_bottom_offset * 2);

- 221
- 2
- 2
Actually cropping parameters should be used only when [frame_cropping_flag] is enabled in SPS. Enjoy H.264!

- 24,821
- 10
- 45
- 52

- 61
- 1
- 1
Regarding frame size calculation, the above formula is not correct.
When chroma_format_idc
is present, then we have to extract it from the SPS.
When chroma_format_idc
is not present, it shall be inferred to be equal to 1 (4:2:0 chroma format). In that case the separate_color_plane_flag
is not set. That means that chromaArrayType = chroma_format_idc
and subWidthC
and subHeightC
are uqual to 2.
The variables cropUnitX and cropUnitY are derived as follows:
If
chromaArrayType
is equal to0
,cropUnitX
andcropUnitY
are derived as:cropUnitX = 1 cropUnitY = 2 - frame_mbs_only_flag
Otherwise (
chromaArrayType
is equal to1
,2
, or3
),cropUnitX
andcropUnitY
are derived as:cropUnitX = subWidthC cropUnitY = subHeightC * ( 2 - frame_mbs_only_flag )
Now you can use cropUnitX
and cropUnitY
in the above formula to get the correct values for frame size.

- 163
- 11