View Full Version : Encoder Requirements for streaming AVC Main Profile HD content
Girish
11th October 2011, 18:25
Hello,
I have the below H264 encoder requirements to get the quality video on the decoder side..
1. Each NAL MUST be less than 3320 bytes in size.
2. POC MUST increment by 2 every frame
3. MUST only use interprediction blocks of size 16x16
4. MUST only use one reference picture
I am finding it difficult to load the above settings in my x264 configuration. It would be helpful if someone throws light on these settings.
Many Thanks,
Girish
MasterNobody
11th October 2011, 19:46
Probably something like this:
--profile main --slice-max-size 3319 -A none --ref 1 --force-cfr
also may be --bframes 0 (if "MUST only use one reference picture" mean B-frames also)
Girish
12th October 2011, 14:35
Thanks.. I will try these settings in my encoder and check the quality.
Dark Shikari
12th October 2011, 17:01
-A i4x4,i8x8 would be better, because the rules said nothing about intra prediction modes.
Girish
7th February 2012, 19:06
I am trying to setup a SIP call with the endpoint that has below encoder restrictions..
1. MUST generate H264 Main Profile compatible bit stream --profile main
2. MUST support CABAC cabac 1
3. MUST support 1280x720 1280x720
4. MUST support fixed frame rate: 30 fps or 29.97 fps fps 30
5. MUST generate one macro block-row per slice
6. 1280x720: 45 slices per frame, each slice must be 80 macro blocks in length slices 45 slice_max_mbs 80
7. MUST support deblocking_filter_control_present = 1 & disable_deblocking_filter_idc = 1 deblock 1
8. MUST only use interprediction blocks of size 16x16
9. MUST only use one reference picture --ref 1 --bframes 0
10. Each NAL MUST be less than 3320 bytes in size --slice-max-size 3319
11. POC MUST increment by 2 every frame
And the string formed so far is
--profile main cabac 1 1280x720 fps 30 slices 45 deblock 1 --ref 1 --bframes 0 --slices-max-size 3319 slice_max_mbs 80
With the above string .. I am finding the decoded picture little blurry .. so i am trying to find the answers for the below questions.. Please guide me in loading the below settings..
How to restrict x264 encoder to generate one macro block-row per slice ?
which command line parameter sets deblocking_filter_control_present = 1 & disable_deblocking_filter_idc = 1 ?
How to restrict x264 encoder to use interprediction blocks of size 16x16 ?
How to restrict x264 encoder to force POC to increment by every 2 frame ?
Many Thanks..
benwaggoner
7th February 2012, 22:22
Hello,
I have the below H264 encoder requirements to get the quality video on the decoder side..
1. Each NAL MUST be less than 3320 bytes in size.
2. POC MUST increment by 2 every frame
3. MUST only use interprediction blocks of size 16x16
4. MUST only use one reference picture
I am finding it difficult to load the above settings in my x264 configuration. It would be helpful if someone throws light on these settings.
What are you streaming to that has these requirements?
nm
8th February 2012, 02:26
1. MUST generate H264 Main Profile compatible bit stream --profile main
Correct.
2. MUST support CABAC cabac 1
x264 uses CABAC by default in Main profile. No parameters needed. (If you use libx264, call x264_param_default to get the default parameters filled in for you).
3. MUST support 1280x720 1280x720
4. MUST support fixed frame rate: 30 fps or 29.97 fps fps 30
Make sure the source video is 30 fps. x264 doesn't drop or duplicate frames, so you run out of sync with audio if you don't do that yourself.
x264 can scale the video to 1280x720 with --vf resize:1280,720
You might need some additional parameters if the source aspect ratio is not 16:9 with square pixels.
Tell us more about the source for better advice.
5. MUST generate one macro block-row per slice
6. 1280x720: 45 slices per frame, each slice must be 80 macro blocks in length slices 45 slice_max_mbs 80
These three requirements are all the same thing: for 1280x720 video, one macroblock-row per slice means 45 slices per frame and 80 macroblocks per slice. 45 x 16 = 720 and 80 x 16 = 1280.
You can use either --slices 45 or --slice-max-mbs 80
7. MUST support deblocking_filter_control_present = 1 & disable_deblocking_filter_idc = 1 deblock 1
disable_deblocking_filter_idc=1 means that deblocking should be disabled. Use --no-deblock
8. MUST only use interprediction blocks of size 16x16
--partitions none
9. MUST only use one reference picture --ref 1 --bframes 0
Yep.
10. Each NAL MUST be less than 3320 bytes in size --slice-max-size 3319
That isn't the way to do it since you have other strict slice restrictions and --slice-max-size simply cuts the slice when it reaches the maximum size.
I don't know a good way to enforce this NAL size restriction without modifying x264. The limit is pretty high for streaming though: (3320 x 8) bits x 45 x 30 Hz = 36 Mbps.
11. POC MUST increment by 2 every frame
x264 does that by default.
Here's your settings line so far:
--profile main --no-deblock --partitions none --ref 1 --bframes 0 --vf resize:1280,720 --slices 45
In addition you need rate control settings (1-pass ABR, CRF or CQP with appropriate values) and VBV settings. If you don't specify any, x264 CLI will use --crf 23 without VBV (or if you happen to be using an ancient x264 build, it might be --crf 26, which gives pretty bad quality).
Are you using some x264 frontend or perhaps calling libx264 directly from your own code?
Girish
9th February 2012, 18:09
Thanks for the quick reply..
We are using latest libx264 to generate main profile as required by the CTS (Cisco) Endpoint. We are following the specs to build an endpoint and gateway as provided in http://www.imtc.org/tip-for-developers/ for multi screen signaling and multi RTP media streams. We are calling the libx264 API directly in our code.
The source could be HD camera (for an end point) or RTP(for gateway). When the source is network there are chances that we fail to push frames at constant frame rate due to latency and decode. Looks like I need to work on rate control and also duplicating the frames to get the constant frame rate. I will use the above setting and update you soon.
Girish
12th March 2012, 21:16
Hi ,
I am trying to stream the video from the camera to a sip phone. Video quality is good except when we do motion close to the camera..
I am streaming 720p30.. Following warnings are received while streaming ... Any suggestions to remove the below warnings and to improve the quality//
x264 [warning]: lookaheadless mb-tree requires intra refresh or infinite keyint
x264 [warning]: frame MB size (80x45) > level limit (396)
x264 [warning]: DPB size (3 frames, 4147200 bytes) > level limit (0 frames, 912384 bytes)
x264 [warning]: libv4lconvert: warning more framesizes then I can handle!
VBV bitrate (2672) > level limit (768)
x264 [warning]: VBV buffer (2672) > level limit (2000)
x264 [warning]: MB rate (108000) > level limit (11880)
Thanks,
LoRd_MuldeR
12th March 2012, 21:33
Give your complete x264 command-line, please!
x264 [warning]: frame MB size (80x45) > level limit (396)
The resolution of your source video is bigger than the select H.264 Level allows. Select a higher level or resize to a lower resolution!
x264 [warning]: DPB size (3 frames, 4147200 bytes) > level limit (0 frames, 912384 bytes)
You have selected more reference frames than the selected H.264 Level allows for your video's resolution.
Of course "level limit 0" doesn't make much sense here, but that probably is a consequence of the first warning message you get. So fix that first!
x264 [warning]: MB rate (108000) > level limit (11880)
The resolution@framerate combination is above the limits of the selected H.264 Level. Use a less restrictive Level -or- use a lower resolution and/or framerate!
Typical "resolution@framerate" combinations for various H.264 Levels can be found here:
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels
Girish
15th March 2012, 12:11
Warnings gone.. Quality is improved.. Thanks for the answer..
Girish
11th November 2013, 06:38
--rc-lookahead 0 --sync-lookahead 0 --profile baseline --level 40 --cabac 0 --slice-max-mbs 80 --slices 45 --slice-max-size 3319 --nf --ref 1 --partitions none --keyint 6 --min-keyint 0 --annexb 0 --bframes 0 --sliced-threads --force-cfr --no-mbtree --threads 6
We are using the above string to encode the video stream for streaming to cisco box. We found the decent quality in the cisco screen when we use 24 core box ( Dell R410) to encode. But the quality is bad in 32 core (Dell R420) with the same settings.
We also moved to frame based encoding from slice based encoding by removing --sliced-thread option and found little quality improvement. But the second call has the bad quality video compared to that of first call. htop says 40% CPU load.
Please guide if there are any fine tuning of the above params are required.
Thanks.
nm
11th November 2013, 08:38
Are you using exactly the same x264 binaries on both boxes? Check that the output stream contains the same parameter strings in both cases and that the input video given to x264 is good.
Do you really need to use baseline profile without CABAC? Previously you had different requirements.
Girish
11th November 2013, 15:34
Yes. It is the same binary .. Input video is the stream coming at around 30 fps.
Please ignore the last string . The string used in the boxes are
--rc-lookahead 0 --sync-lookahead 0 --profile main --level 40 --cabac 1 --slice-max-mbs 80 --slices 45 --slice-max-size 3319 --nf --ref 1 --partitions none --keyint 6 --min-keyint 0 --annexb 0 --bframes 0 --sliced-threads --force-cfr --no-mbtree --threads 6
It is the main profile with cabac enabled.
benwaggoner
11th November 2013, 22:33
We are using the above string to encode the video stream for streaming to cisco box. We found the decent quality in the cisco screen when we use 24 core box ( Dell R410) to encode. But the quality is bad in 32 core (Dell R420) with the same settings.
Since you are limiting to 6 threads, your per-core performance is going to matter a lot more. Does the 24 core box use faster or better cores?
We also moved to frame based encoding from slice based encoding by removing --sliced-thread option and found little quality improvement. But the second call has the bad quality video compared to that of first call. htop says 40% CPU load.
That will generally increase your encoder latency by the number of threads you are using.
Girish
12th November 2014, 00:49
Hi Ben,
We had decided to use R410 in the last year hence the Quality/Performance was accepted wrt above x264 string mainly thread count as 6 . Now they are all upgrading to R420 that uses 32 cores and has long support from Dell. I ran couple of load tests using R420 and found the results as same as found in the last year. :) I tried thread count as 0 as well and other combinations. But in all i found R410 ( 24 Cores ) uses 29% and R420 uses 39% load for encoding 3 AVC streams
Does the 24 core box use faster or better cores? Yes.
24 Core Machine has Intel(R) Xeon(R) CPU E5649 @ 2.53GHz
32 Core Machine has Intel(R) Xeon(R) CPU E5-2450 0 @ 2.10GHz
Is CPU Speed matters more that number of cores ?
Is there any magic settings :) that can be used in 32 cores to extract more out of it.
Thanks.
Asmodian
12th November 2014, 22:14
A few comments though benwaggoner will hopefully offer better incites.
Your R410 is actually a 12 (2x6) core system with hyper-threading.
Your R420 is actually a 16 (2x8) core system with hyper-threading.
Even for x264 CPU Speed matters a little more than the number of cores, double speed cores are better than twice as many cores but usually you gain more cores than % speed lost.
The R420 has gained 33% more cores but lost 20% of their speed vs the R410 so it is less obvious which system would be faster. The E5649 boosts 2.53 to 2.93 GHz while the E5-2450 boosts 2.1 to 2.9 GHz and the E5649 uses boost 1.0 while he E5-2450 uses boost 2.0. I wonder what speed each system is actually running at when you are encoding?
Girish
13th November 2014, 02:40
So 33% increase of R420 E5-2450 in compare to that of R410 is noticeable when CPU is running at high load as boost kicks off then.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.