Video Usability Information (VUI) Guide
by Christian Heine ( sennindemokrit at gmx dot net )
1. Sample Aspect Ratio
-----------------------
* What is it?
The Sample Aspect Ratio (SAR) (sometimes called Pixel Aspect Ratio or just
Pel Aspect Ratio) is defined as the ratio of the width of the sample to the
height of the sample. While pixels on a computer monitor generally are
"square" meaning that their SAR is 1:1, digitized video usually has rather
odd SARs. Playback of material with a particular SAR on a system with
a different SAR will result in a stretched/squashed image. A correction is
necessary that relies on the knowledge of both SARs.
* How do I use it?
You can derive the SAR of an image from the width, height and the
display aspect ratio (DAR) of the image as follows:
SAR_x DAR_x * height
----- = --------------
SAR_y DAR_y * width
for example:
width x height = 704x576, DAR = 4:3 ==> SAR = 2304:2112 or 12:11
Please note that if your material is a digitized analog signal, you should
not use this equation to calculate the SAR. Refer to the manual of your
digitizing equipment or this link instead.
A Quick Guide to Digital Video Resolution and Aspect Ratio Conversions
http://www.iki.fi/znark/video/conversion/
* Should I use this option?
In one word: yes. Most decoders/ media players nowadays support automatic
correction of aspect ratios, and there are just few exceptions. You should
even use it, if the SAR of your material is 1:1, as the default of x264 is
"SAR not defined".
2. Overscan
------------
* What is it?
The term overscan generally refers to all regions of an image that do
not contain information but are added to achieve a certain resolution or
aspect ratio. A "letterboxed" image therefore has overscan at the top and
the bottom. This is not the overscan this option refers to. Neither refers
it to the overscan that is added as part of the process of digitizing an
analog signal. Instead it refers to the "overscan" process on a display
that shows only a part of the image. What that part is depends on the
display.
* How do I use this option?
As I'm not sure about what part of the image is shown when the display uses
an overscan process, I can't provide you with rules or examples. The safe
assumption would be "overscan=show" as this always shows the whole image.
Use "overscan=crop" only if you are sure about the consequences. You may
also use the default value ("undefined").
* Should I use this option?
Only if you know exactly what you are doing. Don't use it on video streams
that have general overscan. Instead try to to crop the borders before
encoding and benefit from the higher bitrate/ image quality.
Furthermore the H264 specification says that the setting "overscan=show"
must be respected, but "overscan=crop" may be ignored. In fact most
playback equipment ignores this setting and shows the whole image.
3. Video Format
----------------
* What is it?
A purely informative setting, that explains what the type of your analog
video was, before you digitized it.
* How do I use this option?
Just set it to the desired value. ( e.g. NTSC, PAL )
If you transcode from MPEG2, you may find the value for this option in the
m2v bitstream. (see ITU-T Rec. H262 / ISO/IEC 13818-2 for details)
* Should I use this option?
That is entirely up to you. I have no idea how this information would ever
be relevant. I consider it to be informative only.
4. Full Range
--------------
* What is it?
Another relic from digitizing analog video. When digitizing analog video
the digital representation of the luma and chroma levels is limited to lie
within 16..235 and 16..240 respectively. Playback equipment usually assumes
all digitized samples to be within this range. However most DVDs use the
full range of 0..255 for luma and chroma samples, possibly resulting in an
oversaturation when played back on that equipment. To avoid this a range
correction is needed.
* How do I use this option?
If your source material is a digitized analog video/TV broadcast it is
quite possible that it is range limited. If you can make sure that it is
range limited you can safely set full range to off. If you are not sure
or want to make sure that your material is played back without
oversaturation, set if to on. Please note that the default for this option
in x264 is off, which is not a safe assumption.
* Should I use this option?
Yes, but there are few decoders/ media players that distinguish
between the two options.
5. Color Primaries, Transfer Characteristics, Matrix Coefficients
-------------------------------------------------------------------
* What is it?
A videophile setting. The average users won't ever need it.
Not all monitor models show all colors the same way. When comparing the
same image on two different monitor models you might find that one of them
"looks more blue", while the other "looks more green". Bottom line is, each
monitor model has a different color profile, which can be used to correct
colors in a way, that images look almost the same on all monitors. The same
goes for printers and film/ video digitizing equipment. If the color
profile of the digitizing equipment is known, it is possible to correct the
colors and gamma of the decoded h264 stream in a way that the video stream
looks the same, regardless of the digitizing equipment used.
* How do I use these options?
If you are able to find out which characteristics your digitizing equipment
uses, (see the equipment documentation or make reference measurements)
then find the most suitable characteristics in the list of available
characteristics (see H264 Annex E) and pass it to x264. Otherwise leave it
to the default (unspecified).
If you transcode from MPEG2, you may find the values for these options in
the m2v bitstream. (see ITU-T Rec. H262 / ISO/IEC 13818-2 for details)
* Should I use these options?
Only if you know exactly what you are doing. The default setting is better
than a wrong one. Use of this option is not a bad idea though.
Unfortunately I don't know any decoder/ media player that ever even
attempted color/gamma/color matrix correction.
6. Chroma Sample Location
--------------------------
* What is it?
A videophile setting. The average user won't ever notice a difference.
Due to a weakness of the eye, it is often economic to reduce the number of
chroma samples in a process called subsampling. In particular x264 uses
only one chroma sample of each chroma channel every block of 2x2 luma
samples. There are a number of possibilities on how this subsampling is
done, each resulting in another relative location of the chroma sample
towards the luma samples. The Chroma Sample Location matters when the
subsampling process is reversed, e.g. the number of chroma samples is
increased. This is most likely to happen at color space conversions. If it
is not done correctly the chroma values may appear shifted compared to the
luma samples by at most 1 pixel, or strangely blurred.
* How do I use this option?
Because x264 does no subsampling, since it only accepts already subsampled
input frames, you have to determine the method yourself.
If you transcode from MPEG1 with proper subsampled 4:2:0, and don't do any
color space conversion, you should set this option to 1.
If you transcode from MPEG2 with proper subsampled 4:2:0, and don't do any
color space conversion, you should set this option to 0.
If you transcode from MPEG4 with proper subsampled 4:2:0, and don't do any
color space conversion, you should set this option to 0.
If you do the c
没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
收起资源包目录
最新版的x264(VS工程) (278个子文件)
football.264 264KB
pixel-a.asm 107KB
predict-a.asm 59KB
deblock-a.asm 58KB
dct-a.asm 46KB
mc-a2.asm 44KB
mc-a.asm 42KB
sad-a.asm 37KB
quant-a.asm 31KB
x86inc.asm 29KB
trellis-64.asm 25KB
pixel.asm 19KB
x86util.asm 18KB
dct-32.asm 16KB
sad16-a.asm 14KB
pixel-32.asm 11KB
dct-64.asm 10KB
checkasm-a.asm 6KB
cabac-a.asm 5KB
cpu-a.asm 4KB
bitstream-a.asm 4KB
const-a.asm 2KB
AUTHORS 2KB
config_only.bat 110B
make_only.bat 98B
analyse.c 166KB
encoder.c 150KB
ratecontrol.c 117KB
checkasm.c 99KB
x264.c 81KB
macroblock.c 80KB
pixel.c 79KB
slicetype.c 77KB
cabac.c 76KB
macroblock.c 53KB
me.c 50KB
rdo.c 47KB
common.c 47KB
pixel.c 47KB
cabac.c 46KB
mc.c 42KB
deblock.c 38KB
dct.c 32KB
mc-c.c 31KB
set.c 30KB
predict.c 30KB
frame.c 30KB
getopt.c 30KB
vlc.c 28KB
cavlc.c 26KB
xyuv.c 25KB
quant.c 24KB
resize.c 23KB
mvpred.c 22KB
mc.c 22KB
dct.c 21KB
predict-c.c 20KB
deblock.c 17KB
timecode.c 16KB
avs.c 15KB
visualize.c 14KB
quant.c 14KB
set.c 13KB
matroska_ebml.c 13KB
cpu.c 13KB
mp4.c 12KB
win32thread.c 10KB
flv.c 10KB
mc-c.c 10KB
lookahead.c 10KB
lavf.c 9KB
y4m.c 8KB
depth.c 8KB
display-x11.c 8KB
ffms.c 7KB
predict.c 7KB
filters.c 6KB
matroska.c 6KB
threadpool.c 5KB
select_every.c 5KB
raw.c 5KB
cache.c 5KB
predict-c.c 5KB
fix_vfr_pts.c 5KB
crop.c 5KB
input.c 4KB
osdep.c 4KB
thread.c 4KB
flv_bytestream.c 4KB
bitstream.c 3KB
source.c 3KB
video.c 3KB
internal.c 2KB
raw.c 2KB
rectangle.c 2KB
x264dll.c 2KB
q_matrix_jvt.cfg 1KB
configure 37KB
COPYING 18KB
.depend 93KB
共 278 条
- 1
- 2
- 3
HEVC_CJL
- 粉丝: 1482
- 资源: 32
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- C#,煎饼排序问题(Pancake Sorting Problem)算法与源代码
- C#,排列组合的堆生成法(Heap’s Algorithm for generating permutations)算法与源代码
- C#,老鼠迷宫问题的回溯法求解(Rat in a Maze)算法与源代码
- 6693eeb8d683458a07938615fba9e68f.apk
- C#,数值计算,解微分方程的龙格-库塔二阶方法与源代码
- C#,数值计算,用割线法(Secant Method)求方程根的算法与源代码
- C#,子集和问题(Subset Sum Problem)的算法与源代码
- mongodb 数据库基本操作
- Linux操作系统基础教程
- Linux操作系统相关习题集
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
- 1
- 2
- 3
- 4
- 5
- 6
前往页