JAVA将字符串变为输入流

关于字符串转化为输入流,我找到2种方法:
1. 用StringReader将字符串转化为Reader
2. 用ByteArrayInputStream将字符串转化为InputStream. 还有一个类StringBufferInputStream也可以将String转化为InputStream,但是由于它只支持字符串中每个字符的低八位,所以已经被遗弃了。
PS: java.io.Reader 和 java.io.InputStream 组成了 Java 输入类。Reader 用于读入16位字符,也就是 Unicode 编码的字符;而 InputStream 用于读入 ASCII 字符和二进制数据。

示例代码如下:

 

转自:http://zben000.javaeye.com/blog/787562

h.264 baseline and main profile

H.264的编解码框架与以前提出的标准如H.261、H.263及MPEG-1/2/4并无显著变化,也是基于混合编码的方案:以运动矢量代表图象序列各帧的运动内容,使用前面已解码帧对其进行运动估计和补偿或使用帧内预测技术,所得的图象参差值要经过变换、量化、熵编码等部分的处理。所以,新标准的性能提升在于各个部分的技术方案的改进及新算法的应用。

    新标准在提高图象传输的容错性方面做了大量工作,重新定义了适于图像的结构划分。在编码时,图象帧各部分被划分到多个slice结构中去,每个slice都可以被独立解码不受其它部分的影响。Slice由图象最基本的结构——宏块组成,每个宏块包含一个16×16的亮度块和两个8×8的色度块。为进一步提高鲁棒性,整个系统被划分为视频编码层和网络抽象层。视频编码层主要描述要传输的视频数据所承载的视频内容。而网络抽象层则是考虑不同的应用,如视频会议通信、H.32X连续包的视频传输或RTP/UDP/IP的通信。

    H.264标准分成三个框架(profile):Baseline、Main及X,代表了针对不同应用的算法集及技术限定。其中,Baseline主要包含了低复杂度、低延时的技术特征;主要是针对交互式的应用;考虑到了恶劣环境下的容错性,Baseline的内容基本都被其它更高级别的profile所包含。而Main profile是针对更高编码效率的应用,如视频广播。X profile 的设计主要针对流媒体的应用,在这一框架中所有容错技术和对比特流的灵活访问及切换技术都将包括其中。
(1)Baseline profile的主要技术特征。
Baseline的解码器只对I slice及P slice进行操作。
    对于帧间预测,相比以前的标准,为了更精确的对图象的运动内容进行预测补偿,新标准允许宏块更进一步划分为16×16、16×8、8×16、8×8、8×4、4×8、4×4的子块;运动估计精确到经由6-tap滤波器得到的1/4象素位置;运动矢量由相邻块预测得到,其预测的差值被编码传输。H.264支持多参考帧的预测,规定运动估计使用的参考帧数最多可达15帧,多参考帧的使用大大提高了对图像传输的容错性,抑制了错误在空间和时间上的蔓延。
    对于所有的slice编码类型,H.264支持两类帧内编码:4×4与16×16编码模式。对于4×4模式,每一个亮度4×4块有8种不同方向上的预测模式及DC预测模式。对于16×16模式,每个16×16亮度块有4种帧内预测模式。而对于宏块的8×8色度采样,采用与亮度16×16几乎相同的预测模式。为了保证slice的编码独立性,帧内预测是不允许跨越slice边界的。
对于变换、量化部分。不同于以前标准对预测参差值的变换编码使用DCT变换,H.264使用了简单的整数变换。这种变换与DCT相比压缩性能几乎相同且有许多优势,其核心变换的计算只使用加减、移位运算,避免了精度的损失。对变换参差系数的量化使用了52级步长的量化器,而H.263标准只有31级。量化步长以12.5%递增,量化步长范围的扩大似的编码器能够更灵活和精确的进行控制,在比特率和图象质量之间达到折中。
对熵编码部分。对于要传输的量化变换系数,若使用基于上下文的变长编码(CAVLC),它是根据前面已编码传输的量化变换系数值的大小来选择接下来系数编码要使用的变长编码表。由于变长编码表的设计是基于相应的统计条件,所以其性能要优于使用单一变长编码表。而对其它数据如头信息等,使用一种单一的变长编码表(Exp-Golomb code)。
    新标准仍然使用基于块的预测及重构方式,为了去除由此产生的影响图象主观质量的方块效应,H.264使用了去块效应滤波器。其主要思想是当块边界上两边差较小则使用滤波器使差别“平滑”掉,若边界上图象特征明显就不使用滤波。这样既为减弱“块效应”的影响又避免滤掉图象的客观特征。同时在相同主观质量下使得比特率减少5-10%。
    另外,对图象数据的组织及传输。在H.264标准中的图象宏块可以灵活的宏块组织顺序(FMO)划分为多个slice group;slice之间是相互独立的可以任意的顺序传输到解码端(ASO)。而且在比特流中slice可以使用重复的方式(RS)传输,这在slice数据出错的情况下可用来进行恢复,增强了图象传输的鲁棒性。同时slice间的相互独立性抑制了错误的空间传播,因此提高了比特流的容错性。
    ⑵ Main profile的技术特征
    Main profile包含Baseline profile的所有算法并具有额外的技术特征,但它并不支持FMO、ASO及RS等技术。只支持对I、P、B slice的处理操作。
    在此框架内提出了适配块划分尺寸的变换(ABT)的概念。此概念是针对帧间编码的,其主要思想是将对预测参差进行变换编码的块尺寸与用来进行运动补偿的块尺寸联系起来。这样就尽可能的利用最大的信号长度进行变换编码。但是由于复杂度的原因,进行变换的最大块尺寸被限制在8×8以下。
    对熵编码部分,为更高效的进行编码,这里使用了基于上下文的算术编码(CABAC)使熵编码的性能进一步提高。相比较CAVLC,在相同图象质量下编码电视信号使用CABAC将会使比特率减少10-15%。
    另,Main profile不支持多个slice group的划分。
    ⑶ 相关的编码问题如何对已提出的预测模式进行选择(mode decision)和使用运动估计策略(ME)历来都视频编码实现的重点研究课题。在H.263标准的实现软件中对模式的选择是简单的基于对阀值的比较。在新标准的测试软件中使用了拉格朗日率失真优化策略,它是基于使用每种图象块尺寸和每种预测模式而产生的参差及其传输的码率。这样,模式选择可以取得优化的率失真性能但这是以提高运算复杂度为代价的。此优化操作是对下面拉各朗日函数的最小化: J = SATD + λ”R 其中,R为对应传输的各部分的比特率;λ为优化参数,其与量化参数有很强的相关性。SATD为经过哈德曼变换的4×4块的预测参差绝对值总和。对于所有帧内、帧间宏块编码模式及多参考帧的选择都通过对拉各朗日函数的最小化来实现。通常,视频标准只是包括解码规范,而模式选择的技术研究是属于编码端的范畴,所以不列在标准之内。
转自:http://www.360doc.com/content/10/0907/11/2172436_51813892.shtml

FFmpeg and x264 Encoding Guide

机械键盘推荐>>

x264 is a H.264/MPEG-4 AVC encoder. The goal of this guide is to inform new users how to create a high-quality H.264 video.

There are two rate control modes that are usually suggested for general use: Constant Rate Factor (CRF) or Two-Pass ABR. The rate control is a method that will decide how many bits will be used for each frame. This will determine the file size and also how quality is distributed.

If you need help compiling and installing libx264 see one of our FFmpeg and x264 compiling guides.

Constant Rate Factor (CRF)

This method allows the encoder to attempt to achieve a certain output quality for the whole file when output file size is of less importance. This provides maximum compression efficiency with a single pass. Each frame gets the bitrate it needs to keep the requested quality level. The downside is that you can’t tell it to get a specific filesize or not go over a specific size or bitrate.

1. Choose a CRF value

The range of the quantizer scale is 0-51: where 0 is lossless, 23 is default, and 51 is worst possible. A lower value is a higher quality and a subjectively sane range is 18-28. Consider 18 to be visually lossless or nearly so: it should look the same or nearly the same as the input but it isn’t technically lossless.

The range is exponential, so increasing the CRF value +6 is roughly half the bitrate while -6 is roughly twice the bitrate. General usage is to choose the highest CRF value that still provides an acceptable quality. If the output looks good, then try a higher value and if it looks bad then choose a lower value.

Note: The CRF quantizer scale mentioned on this page only applies to 8-bit x264 (10-bit x264 quantizer scale is 0-63). You can see what you are using by referring to theffmpeg console output during encoding (yuv420p or similar for 8-bit, and yuv420p10le or similar for 10-bit). 8-bit is more common among distributors.

2. Choose a preset

A preset is a collection of options that will provide a certain encoding speed to compression ratio. A slower preset will provide better compression (compression is quality per filesize). This means that, for example, if you target a certain file size or constant bit rate, you will achieve better quality with a slower preset. Similarly, for constant quality encoding, you will simply save bitrate by choosing a slower preset.

The general guideline is to use the slowest preset that you have patience for. Current presets in descending order of speed are: ultrafast,superfastveryfastfasterfast,mediumslowslowerveryslowplacebo. The default preset is medium. Ignore placebo as it is not useful (see FAQ). You can see a list of current presets with -preset help, and what settings they apply with x264 –fullhelp.

You can optionally use -tune to change settings based upon the specifics of your input. Current tunings include: filmanimationgrainstillimagepsnrssim,fastdecodezerolatency. For example, if your input is animation then use the animation tuning, or if you want to preserve grain then use the grain tuning. If you are unsure of what to use or your input does not match any of tunings then omit the -tune option. You can see a list of current tunings with -tune help, and what settings they apply withx264 –fullhelp.

Another optional setting is -profile:v which will limit the output to a specific H.264 profile. This can generally be omitted unless the target device only supports a certain profile (see Compatibility). Current profiles include: baselinemainhighhigh10high422high444. Note that usage of -profile:v is incompatible with lossless encoding.

As a shortcut, you can also list all possible internal presets/tunes for FFmpeg by specifying no preset or tune option at all:

Note: Windows users should use NUL instead of /dev/null.

3. Use your settings

Once you’ve chosen your settings apply them for the rest of your videos if you are encoding more. This will ensure that they will all have similar quality.

CRF Example

Note that in this example the audio stream of the input file is simply ​stream copied over to the output and not re-encoded.


Two-Pass

This method is generally used if you are targeting a specific output file size and output quality from frame to frame is of less importance. This is best explained with an example. Your video is 10 minutes (600 seconds) long and an output of 50 MB is desired. Since bitrate = file size / duration:

Two-Pass Example

Note: Windows users should use NUL instead of /dev/null.

As with CRF, choose the slowest preset you can tolerate.

Also see ​Making a high quality MPEG-4 (“DivX”) rip of a DVD movie. It is an MEncoder guide, but it will give you an insight about how important it is to use two-pass when you want to efficiently use every bit when you’re constrained with storage space.


Lossless H.264

You can use -qp 0 or -crf 0 to encode a lossless output. Use of -qp is recommended over -crf for lossless because 8-bit and 10-bit x264 use different -crf values for lossless. Two useful presets for this are ultrafast or veryslow since either a fast encoding speed or best compression are usually the most important factors. Most non-FFmpeg based players will not be able to decode lossless (but YouTube can), so if compatibility is an issue you should not use lossless.

Lossless Example (fastest encoding)

Lossless Example (best compression)


Overwriting default preset settings

You can overwrite default preset settings with the x264opts option, the x264-params option, or by using the libx264 private options (see ffmpeg -h encoder=libx264). This is not recommended unless you know what you are doing. The presets were created by the x264 developers and tweaking values to get a better output is usually a waste of time.

Example:


Additional Information & Tips

ABR (Average Bit Rate)

This provides something of a “running average” target, with the end goal that the final file match this number “overall on average” (so basically, if it gets a lot of black frames, which cost very little, it will encode them with less than the requested bitrate, but then the next few seconds of (non-black) frames it will encode at very high quality, to bring the average back in line). Using 2-pass can help this method to be more effective. You can also use this in combination with a “max bit rate” setting in order to prevent some of the swings.

CBR (Constant Bit Rate)

There is no native CBR mode, but you can “simulate” a constant bit rate setting by tuning the parameters of ABR:

In the above example, -bufsize is the “rate control buffer” so it will enforce your requested “average” (4000k in this case) across each 1835k worth of video. So basically it is assumed that the receiver/end player will buffer that much data so it’s ok to fluctuate within that much.

Of course, if it’s all just empty/black frames then it will still serve less than that many bits/s but it will raise the quality level as much as it can, up to the crf level.

CRF with maximum bit rate

You can also also use a crf with a maximum bit rate by specifying both crf *and* maxrate settings, like

This will effectively “target” crf 20, but if the output exceeds 400kb/s, it will degrade to something less than crf 20 in that case.

Low Latency

libx264 offers a -tune zerolatency option. See the StreamingGuide.

Compatibility

All devices

If you want your videos to have highest compatibility with target devices (older iOS versions or all Android devices):

This disables some advanced features but provides for better compatibility. Typically you may not need this setting (and therefore avoid using -profile:v and -level), but if you do use this setting it may increase the bit rate quite a bit compared to what is needed to achieve the same quality in higher profiles.

iOS

iOS Compatability (​source)
Profile Level Devices Options
Baseline 3.0 All devices -profile:v baseline -level 3.0
Baseline 3.1 iPhone 3G and later, iPod touch 2nd generation and later -profile:v baseline -level 3.1
Main 3.1 iPad (all versions), Apple TV 2 and later, iPhone 4 and later -profile:v main -level 3.1
Main 4.0 Apple TV 3 and later, iPad 2 and later, iPhone 4S and later -profile:v main -level 4.0
High 4.0 Apple TV 3 and later, iPad 2 and later, iPhone 4S and later -profile:v high -level 4.0
High 4.1 iPad 2 and later and iPhone 4S and later -profile:v high -level 4.1
  • This table does not include any additional restrictions which may be required by your device.
  • -level currently does not affect the number of reference frames (-refs). See ticket #3307.

Apple Quicktime

Apple QuickTime only supports YUV planar color space with 4:2:0 chroma subsampling (use -pix_fmt yuv420p) for H.264 video. For information on additional restrictions see​QuickTime-compatible Encoding.

Blu-ray

See ​Authoring a professional Blu-ray Disc with x264.

Pre-testing your settings

Encode a random section instead of the whole video with the -ss and -t options to quickly get a general idea of what the output will look like.

  • -ss: Offset time from beginning. Value can be in seconds or HH:MM:SS format.
  • -t: Output duration. Value can be in seconds or HH:MM:SS format.

faststart for web video

You can add -movflags +faststart as an output option if your videos are going to be viewed in a browser. This will move some information to the beginning of your file and allow the video to begin playing before it is completely downloaded by the viewer. It is not required if you are going to use a video service such as YouTube.


FAQ

Will two-pass provide a better quality than CRF?

​No, though it does allow you to target a file size more accurately.

Why is placebo a waste of time?

It helps at most ~1% compared to the veryslow preset at the cost of a much higher encoding time. It’s diminishing returns: veryslow helps about 3% compared to the slowerpreset, slower helps about 5% compared to the slow preset, and slow helps about 5-10% compared to the medium preset.

Why doesn’t my lossless output look lossless?

Blame the RGB to YUV color space conversion. If you convert to yuv444 it should still be lossless (which is the default now).

Will a graphics card make x264 encode faster?

Not necessarily. ​x264 supports OpenCL for some lookahead operations. There are also some proprietary encoders that utilize the GPU, but that does not mean they are well optimized, though encoding time may be faster; and they might be ​worse than vanilla x264, and possibly slower. Regardless, FFmpeg today doesn’t support any means of GPU encoding, outside of libx264.

Encoding for dumb players

You may need to use -pix_fmt yuv420p for your output to work in QuickTime and most other players. These players only supports the YUV planar color space with 4:2:0 chroma subsampling for H.264 video. Otherwise, depending on your source, ffmpeg may output to a pixel format that may be incompatible with these players.


Additional Resources

 

转自:https://trac.ffmpeg.org/wiki/x264EncodingGuide

FFMPEG解码多线程

FFMPEG多线程编码器一般以在Slice内分功能模块进行多线程编码,如h263,h263P,msmpeg(v1, v2, v3),wmv1。包含以下几个线程:(1)Pre_estimation_motion_thread运动估计前的准备;(2)Estimation_motion_thread运动估计;(3)Mb_var_thread宏块其他变量;(4)Encode_thread编码主线程。当然也有例外,如FFV1编码器按Slice为线程单位进行多线程编码。

FFMPEG多线程解码器分为Frame级和Slice级两种,Slice级多线程同时解码一帧中不同的部分。Frame级多线程同时接受多帧码流,实现并行解码,当前帧处于显示状态时,未来的几帧已经在其他线程中被解码。

  1. Slice Threading

FFmpeg中,dvvideo_decoder, ffv1_decoder, h264_decoder, mpeg2_video_decoder和mpeg_video_decoder均支持了Slice Threading。

实现方法是:首先为codecContext注册注册多线程处理函数excute(),Codec解码过程中处理Slice时调用avctx->excute()。excute()启动Slice解码工作线程开始多线程解码,同时快速返回开始下一Slice的解析和解码。

Frame Threading主线程和解码线程的同步如图1所示。

 图1 Frame Threading主线程和解码线程的同步

  1. Frame Threading

目前为止支持Frame Threading的解码器有h264_decoder, huffyuv_decoder, ffvhuff_decoder, mdec_decoder, mimic_decoder, mpeg4_decoder, theora_decoder, vp3_decoder和vp8_decoder。

Frame Threading有如下限制:用户函数draw_horiz_band()必须是线程安全的;为了提升性能,用户应该为codec提供线程安全的get_buffer()回调函数;用户必须能处理多线程带来的延时。另外,支持Frame Threading的codec要求每个包包含一个完整帧。Buffer内容在ff_thread_await_progress()调用之前不能读,同样,包括加边draw_edges()在内的处理,在ff_thread_report_progress()调用之后,Buffer内容不能写。

每个线程都有以下四个状态。如图2所示,为了保证线程安全,若Codec未实现update_thread_context()和线程安全的get_buffer(),则必须在解码完成后才能将状态转换为STATUS_SETUP_FINISHED,意味着下一个线程只能在当前线程解码完成后才能开始解码。

而如图3所示,如果Codec实现update_thread_context()和线程安全的get_buffer(),线程状态可以在解码开始之前转换为STATUS_SETUP_FINISHED,这样,下一个线程就可能与当前线程并行。

图2 Codec未实现update_thread_context()和线程安全的get_buffer(),线程状态转换

图3 Codec实现update_thread_context()和线程安全的get_buffer(),线程状态转换

解码主线程通过调用submit_packet()将码流交给对应的解码线程。主线程和解码线程的同步如图4所示。

图4 Frame Threading主线程和解码线程的同步

 

转自:http://blog.csdn.net/xietao_live_cn/article/details/6452030

关于GOP与RAP的一些解释

在之前的博文中,我曾经简单把之前阅读文献资料和编译软件的记录和心得记录分享了一下。由于我也是刚刚接触HEVC没几天,有些问题我的理解也不是很深入,在之前的博文中有博友对高层语法中的一些概念提出了疑问。在咨询了了解背景知识的同学之后,经过仔细地重新推敲参考文献(”Overviewof HEVC”)之后,对一些问题找到了一些答案,在此另发一篇博文作为回应。
关于码流中的三种随机接入点的解释:
BLA、CRA、IDR是文献中提到过的三种随机接入点(RAP),在文献中的解释的确不是很容易理解。更关键的是,与这三个名词相应的还有GOP,open/closedGOP,RASL,RADL等等概念,环环相扣,一个不理解,剩下的也很难弄懂,下面我们一个一个解释,很多也是我自己刚刚想到的,不一定正确全面,欢迎批评。
(1)关于GOP。这是图像组(Group ofPictures)的意思,表示编码的视频序列分成了一组一组的有序的帧的集合进行编码。每个GOP一定是以一个I帧开始的,但是却不一定指代的是两个I帧之间的距离。因为一个GOP内可能包含几个I帧,只有第一个I帧(也就是第一帧)才是关键帧。在程序cfg中,GOP的长度和两个I帧的距离也是两个不同参数指定的(如IntraPeriod和GOPSize或者类似的参数)。所以,两个I帧的间距不可能大于GOP的长度,一般情况是更小的。
(2)关于IDR。这个词儿的全称是Instantaneous DecodingRefresh,是在H.264中定义的结构。在H.264中,IDR帧一定是I帧,而且一定是GOP的开始,也是H.264GOP的关键帧。但是反过来却不成立,I帧不一定是IDR帧。GOP的长度不是定死不变的,在H.264的编码器中,如果判定场景发生变化,那么即使不到原定GOP的末尾,也会在这个位置加入一个IDR,作为新一个GOP的开始。此时这个GOP的长度就被缩小了。
(3)闭合GOP和开放GOP(closedGOP/openGOP),CRA。闭合GOP是H.264中GOP的格式。在H.264的GOP中,所有的GOP都是独立解码的,与其他GOP无关,即它们都是“封闭”的。但是在HEVC中,GOP的结构发生了变化,采用了“开放”的结构,在解码过程过可能会参考其他GOP的数据。这时,一个GOP的起始帧命名为CRA,cleanrandomaccess,同样采用帧内编码,但是这个GOP内的帧间编码帧可以越过CRA参考前一个GOP的数据,这便是GOP的open。
(4)关于BLA。个人感觉BLA只是CRA在视频流切换情况下的一种特例。视频流在某个RAP上要求切换到另一个视频流继续解码,则直接将该CRA同另一个视频流中的接入CRA连接,后者便是BLA。由于BLA之前解码到缓存的视频流与当前视频流无关,因此其特性类似于直接从该点进行随机存取后的CRA。
(5)RASL和RADL。这是两种GOP间的图像类型。如果解码器从某个CRA随机接入,则按照显示顺序的后面几帧数据由于缺少参考帧而不能解码,这些图像将被解码器抛弃,即skipleading。而对于没有从当前CRA接入的数据,这些图像可以被正常解码显示,因此称为decodableleading。由于这些数据是有可能舍弃的,因此其他图像(trailingpictures)不能参考这些数据,否则万一这些图像被舍弃,将会有更多的图像受其影响而不能正常解码。
下面举个例子:
假设视频序列的显示顺序为①,这是一个完整的GOP,解码顺序为②
①I B BP B B P B B P
②I P BB P B B P B B
在H.264中,第一个I帧为IDR,GOP为闭合结构,因此两个GOP组成视频的结构为
I B B P B B P B B PI B B P B B P B BP(显示顺序)
I P B B P B B P BB I P B B P B B P BB(解码顺序)
而在HEVC中,两个I帧为CRA,GOP为开放结构,因此GOP的结构为:
I B B P B B P B B PBBI BB P B B P B (显示顺序)
I P BB P B B P B B I B B P B B P BB…(解码顺序)
两个红色的B帧表示的是按照解码顺序在CRA之后,该GOP内参考的前一个GOP进行编码的图像。这样便很容易得知,如果选择在第二个CRA进行随机接入,这两个红色的B帧将会由于没有参考帧无法解码而被舍弃。这两个红色的B帧即RASP。如果没有选择这个CRA进行随机接入,这两个红色B帧将可以顺利解码,即成为RADP。
对于BLA,情况也是类似的。由于出现码流拼接,第二段码流的CRA之后的B也会因为没有参考帧无法解码而丢弃。很容易理解,此时缓存中的参考帧数据还来自上一段码流,跟当前码流没关系,当然不能用作B的参考了。
之余HEVC这么设计的目的,我觉得应该是为了编码效率考虑的。因为B帧的压缩比相对是最高的,引入这种设计可以在不影响随机存取性能的前提下,尽可能增大B帧的比重,提高整体压缩编码的性能。
以下是一些国外研究者在论坛中对这个问题的一些讨论,可以拿来做一下参考:
www.linkedin.com/groups/IDR-vs-CRA-3724292.S.125836481
forum.doom9.org/archive/index.php/t-105129.html
转自:http://blog.sina.com.cn/s/blog_520811730101jlsa.html