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

ffmpeg使用x264编码的配置

使用ffmpeg进行.264编码的相关文章比较少,google了一下,特总结如下:

  • qscale的取值可以是0.01-255但实际使用超过50就很糟糕了
  • ffmpeg的cbr模式可以把码率控制的不错,但是vbr无法限制最高码率(虽然有max的设置,但是程序没有实现)
  • x264标准的封装是x264+aac in flv或者x264+aac in MP4

接下来说明下ffmpeg命令行的语法规则(本块内容来自2009-03-02官方文档):
语法规则结构:

一个最简单的命令形式:

这个命令把视频以64k的码率重编码。

显然,输入文件前面要加一个-i选项下面介绍一些有用的全局参数:

  • -formats 参数。会显示你机器当前支持的封装、编码、解码器的信息
  • -y参数,会指示ffmpeg覆盖输出文件
  • -t 指定视频流持续的时常,支持以秒为单位的数字或”时:分:秒[.毫秒]”
  • -fs 指定输出文件大小的限制
  • -ss 指定开始的时间,和-t的单位一样
  • -target 直接设定你想要转成的目标格式,所有的相关设置都会采用内设值,当然也你也可以加上自己要修改的参数。可用的选择有:
    “vcd”, “svcd”, “dvd”, “dv”, “dv50″, “pal-vcd”, “ntsc-svcd”, …
    这个例子把视频转换成vcd的格式

接下来介绍视频选项:

  • -b 指定码率注意单位是bit/s,所以我们一般要加k,比如 -b 1000k 就是1000kb/s
  • -g 设置组的大小
  • -vframes 指定要编码的帧数,比如-vframes 1 就是编码1帧,截图的时候就这样写.
  • -r 指定帧率,默认是25
  • -s 指定图像分辨率,用wxh的格式,比如320×240
  • -aspect 指定宽高比 可以些16:9这种,也可以写小数比如1.3333
  • -croptop 指定顶部裁减多少像素,类似的还有-cropleft -cropright -cropbuttom
  • -bt 设置比特率容许的误差,默认4000k,在第一阶段时使用这个参数会告诉码率控制器能够偏移平均码率多远,这个选项和最大最小码率无关.设太小了不利于质量
  • -maxrate 和-minrate 指定允许的最大和最小码率,一般如果要用cbr模式编码的话会用这个:

    否则用处不大
  • -vcodec 强制使用某种编码器
  • -sameq 使用和源文件相同的质量,这个选项是动态码率的
  • -pass 指定编码阶段,这个只有1和2,第一阶段的时候应该不处理音频,并且把输出导向空,比如:
  • -qscale 使用固定量化因子来量化视频这个是在vbr模式的,前面有提到,越小质量越好,不要超过50,相关的参数还有-qmin –qmax用来设定最大最小可使用的量化值
  • -qdiff 指定固定量化器因子允许的最大偏差
  • -qblur 指定量化器模糊系数,可用范围是0.0-1.0越大使得码率在时间上分配的越平均
  • -qcomp 指定视频量化器压缩系数,默认0.5
  • -me_method 指定运动估计方法(motion estimation method),可用的选择从垃圾到好排列如下:
    zero (0向量)
    phods
    log
    x1
    hex
    umh
    epzs (默认)
    full (完全搜索,很慢又好不到哪里去)
  • -mbd 设定宏模块决策,可用的值:
    0 使用mb_cmp,不知道是什么东西,所以这些参数我参考一下mencoder里面的
    1 选用需要比特最少的宏块模式
    2 选用码率失真最优的宏块模式
  • -4mv 使用宏块的4个运动向量,只支持mpeg4
  • -part 使用数据划分,只支持mpeg4
  • -ilme 强制允许交错的编码,只支持mpeg2和mpeg4,你可以选择用-deinterlace来去交错

音频部分:

  • -ar 设置采样频率,默认44100hz
  • -ab 设置比特率,默认64k
  • -an 禁用音频录制
  • -acodec 指定音频编码器

下面举几个x264编码的例子:
我使用mencoder调用x264编码一个psp用的视频:
x264+aac in mp4 for psp

对应的ffmpeg编码参数是:
ffmpeg

需要注意的是,flags2里面那块,似乎要按照一定顺序才能正常工作,其他地方都差不多,详细情况可以从下面两篇文章得出:
第一篇是这个在网上被传了很多,但有些问题的对照表格,我修改了有问题的部分:

FFmpeg option x264 option
-g <frames> –keyint
-b <bits per second> –bitrate
-bufsize <bits> –vbv-bufsize
-maxrate <bits> –vbv-maxrate
-pass <1,2,3> –pass
-crf <float> –crf
-cqp <int> –qp
-bf <int> –bframes
-coder <0,1> –no-cabac
-bframebias <int> –b-bias
-keyint_min <int> –min-keyint
-sc_threshold <int> –scenecut
-deblockalpha <int>-deblockbeta <int> –deblock
-qmin <int> –qpmin
-qmax <int> –qpmax
-qdiff <int> –qpstep
-qcomp <float> –qcomp
-qblur <float> –qblur
-complexityblur <float> –cplxblur
-refs <int> –ref
-directpred <int> –direct
-me_method <epzs,hex,umh,full> –me
-me_range <int> –merange
-subq <int> –subme
-bidir_refine <0,1> –bime
-trellis <0,1,2> –trellis
-nr <int> –nr
-level <int> –level
-bt <bits> –ratetol = -bt / -b
-rc_init_occupancy <bits> –vbv-init = -rc_init_occupancy / -bufsize
-i_qfactor <float> –ipratio = 1 / -i_qfactor
-b_qfactor <float> –pbratio
-chromaoffset <int> –chroma-qp-offset
-rc_eq <string> –rc_eq
-threads <int> –threads
-cmp <-chroma/+chroma> –no-chroma-me
-partitions –partitions
+parti8×8 i8×8
+parti4×4 i4×4
+partp8×8 p8×8
+partp4×4 p4×4
+partb8×8 b8×8
-flags
-loop/+loop –no-deblock/–deblock
-psnr/+psnr –no-psnr/nothing
-flags2
+bpyramid –b-pyramid
+wpred –weightb
+brdo –b-rdo 我这里的ffmpeg已经不能用这个了
+mixed_refs –mixed-refs
+dct8×8 –8×8dct
-fastpskip/+fastpskip –no-fast-pskip
+aud –aud

下面是一篇关于这些参数详细解释的文章,转自:http://ffmpeg.x264.googlepages.com/mapping
一下是这篇文章在2008年11月19日更新的版本:

Frame-type options:

  • –keyint <integer> (x264)
    -g <integer>
     (FFmpeg)
    Keyframe interval, also known as GOP length. This determines the maximum distance between I-frames. Very high GOP lengths will result in slightly more efficient compression, but will make seeking in the video somewhat more difficult. Recommended default: 250
  • –min-keyint <integer> (x264)
    -keyint_min <integer> (FFmpeg)
    Minimum GOP length, the minimum distance between I-frames. Recommended default: 25
  • –scenecut <integer> (x264)
    -sc_threshold <integer> (FFmpeg)
    Adjusts the sensitivity of x264’s scenecut detection. Rarely needs to be adjusted. Recommended default: 40
  • –pre-scenecut (x264)
    UNKNOWN (FFmpeg)
    Slightly faster (but less precise) scenecut detection. Normal scenecut detection decides whether a frame is a scenecut after the frame is encoded, and if so then re-encodes the frame as an I-frame. This is not compatible with threading, however, and so –pre-scenecut is automatically activated when multiple encoding threads are used.
  • –bframes <integer> (x264)
    -bf <integer> (FFmpeg)
    B-frames are a core element of H.264 and are more efficient in H.264 than any previous standard. Some specific targets, such as HD-DVD and Blu-Ray, have limitations on the number of consecutive B-frames. Most, however, do not; as a result, there is rarely any negative effect to setting this to the maximum (16) since x264 will, if B-adapt is used, automatically choose the best number of B-frames anyways. This parameter simply serves to limit the max number of B-frames. Note that Baseline Profile, such as that used by iPods, does not support B-frames. Recommended default: 16
    • –b-adapt <integer> (x264)
      -b_strategy <integer> (FFmpeg)
      x264, by default, adaptively decides through a low-resolution lookahead the best number of B-frames to use. It is possible to disable this adaptivity; this is not recommended. Recommended default: 1

0: Very fast, but not recommended. Does not work with pre-scenecut (scenecut must be off to force off b-adapt).

1: Fast, default mode in x264. A good balance between speed and quality.

2: A much slower but more accurate B-frame decision mode that correctly detects fades and generally gives considerably better quality. Its speed gets considerably slower at high bframes values, so its recommended to keep bframes relatively low (perhaps around 3) when using this option. It also may slow down the first pass of x264 when in threaded mode.
  • –b-bias 0 (x264)
    -bframebias 0 (FFmpeg)
    Make x264 more likely to choose higher numbers of B-frames during the adaptive lookahead. Not generally recommended. Recommended default: 0
  • –b-pyramid (x264)
    -flags2 +bpyramid (FFmpeg)
    Allows B-frames to be kept as references. The name is technically misleading, as x264 does not actually use pyramid coding; it simply adds B-references to the normal reference list. B-references get a quantizer halfway between that of a B-frame and P-frame. This setting is generally beneficial, but it increases the DPB (decoding picture buffer) size required for playback, so when encoding for hardware, disabling it may help compatibility.
  • –no-cabac (x264)
    -coder 0,1 (FFmpeg)
    CABAC is the default entropy encoder used by x264. Though somewhat slower on both the decoding and encoding end, it offers 10-15% improved compression on live-action sources and considerably higher improvements on animated sources, especially at low bitrates. It is also required for the use of trellis quantization. Disabling CABAC may somewhat improve decoding performance, especially at high bitrates. CABAC is not allowed in Baseline Profile. Recommended default: -coder 1 (CABAC enabled)
  • –ref <integer> (x264)
    -refs <integer> (FFmpeg)
    One of H.264’s most useful features is the abillity to reference frames other than the one immediately prior to the current frame. This parameter lets one specify how many references can be used, through a maximum of 16. Increasing the number of refs increases the DPB (Decoded Picture Buffer) requirement, which means hardware playback devices will often have strict limits to the number of refs they can handle. In live-action sources, more reference have limited use beyond 4-8, but in cartoon sources up to the maximum value of 16 is often useful. More reference frames require more processing power because every frame is searched by the motion search (except when an early skip decision is made). The slowdown is especially apparent with slower motion estimation methods. Recommended default: -refs 6
  • –no-deblock (x264)
    -flags -loop (FFmpeg)
    Disable loop filter. Recommended default: -flags +loop (Enabled)
  • –deblock (x264)
    -deblockalpha <integer>(FFmpeg)
    -deblockbeta <integer>(FFmpeg)
    One of H.264’s main features is the in-loop deblocker, which avoids the problem of blocking artifacts disrupting motion estimation. This requires a small amount of decoding CPU, but considerably increases quality in nearly all cases. Its strength may be raised or lowered in order to avoid more artifacts or keep more detail, respectively. Deblock has two parameters: alpha (strength) and beta (threshold). Recommended defaults:-deblockalpha 0 -deblockbeta 0 (Must have ‘-flags +loop’)
  • –interlaced (x264)
    UNKNOWN (FFmpeg)
    Enables interlaced encoding. x264’s interlaced encoding is not as efficient as its progressive encoding; consider deinterlacing for maximum effectiveness.

Ratecontrol:

  • –qp <integer>(x264)
    -cqp <integer>(FFmpeg)
    Constant quantizer mode. Not exactly constant completely–B-frames and I-frames have different quantizers from P-frames. Generally should not be used, since CRF gives better quality at the same bitrate.
  • –bitrate <integer>(x264)
    -b <integer>(FFmpeg)
    Enables target bitrate mode. Attempts to reach a specific bitrate. Should be used in 2-pass mode whenever possible; 1-pass bitrate mode is generally the worst ratecontrol mode x264 has.
  • –crf <float>(x264)
    -crf <float>(FFmpeg)
    Constant quality mode (also known as constant ratefactor). Bitrate corresponds approximately to that of constant quantizer, but gives better quality overall at little speed cost. The best one-pass option in x264.
  • –vbv-maxrate <integer>(x264)
    -maxrate <integer>(FFmpeg)
    Specifies the maximum bitrate at any point in the video. Requires the VBV buffersize to be set. This option is generally used when encoding for a piece of hardware with bitrate limitations.
  • –vbv-bufsize <integer>(x264)
    -bufsize <integer> (FFmpeg)
    Depends on the profile level of the video being encoded. Set only if you’re encoding for a hardware device.
  • –vbv-init <float>(x264)
    -rc_init_occupancy <float>(FFmpeg)
    Initial VBV buffer occupancy. Note: Don’t mess with this.
  • –qpmin <integer> (x264)
    -qmin <integer> (FFmpeg)
    Minimum quantizer. Doesn’t need to be changed. Recommended default: -qmin 10
  • –qpmax <integer> (x264)
    -qmax <integer> (FFmpeg)
    Maximum quantizer. Doesn’t need to be changed. Recommended default: -qmax 51
  • –qpstep <integer> (x264)
    -qdiff <integer> (FFmpeg)
    Set max QP step. Recommended default: -qdiff 4
  • –ratetol <float>(x264)
    -bt <float>(FFmpeg)
    Allowed variance of average bitrate
  • –ipratio <float>(x264)
    -i_qfactor <float>(FFmpeg)
    Qscale difference between I-frames and P-frames.
  • –pbratio <float>(x264)
    -b_qfactor <float>(FFmpeg)
    Qscale difference between P-frames and B-frames.
  • –chroma-qp-offset <integer>(x264)
    -chromaoffset <integer>(FFmpeg)
    QP difference between chroma and luma.
  • –aq-strength <float> (x264)
    UNKNOWN (FFmpeg)
    Adjusts the strength of adaptive quantization. Higher values take more bits away from complex areas and edges and move them towards simpler, flatter areas to maintain fine detail. Default: 1.0
  • –pass <1,2,3> (x264)
    -pass <1,2,3>(FFmpeg)
    Used with –bitrate. Pass 1 writes the stats file, pass 2 reads it, and 3 both reads and writes it. If you want to use three pass, this means you will have to use –pass 1 for the first pass, –pass 3 for the second, and –pass 2 or 3 for the third.
  • –stats <string>(x264)
    UNKNOWN (FFmpeg)
    Allows setting a specific filename for the firstpass stats file.
    • –rceq <string>(x264)
      -rc_eq <string>(FFmpeg)
      Ratecontrol equation. Recommended default: -rc_eq ‘blurCplx^(1-qComp)’
  • –qcomp <float>(x264)
    -qcomp <float> (FFmpeg)
    QP curve compression: 0.0 => CBR, 1.0 => CQP. Recommended default: -qcomp 0.60
  • –cplxblur <float>(x264)
    -complexityblur <float>(FFmpeg)
    Reduce fluctuations in QP (before curve compression) [20.0]
  • –qblur <float>(x264)
    -qblur <float>(FFmpeg)
    Reduce fluctuations in QP (after curve compression) [0.5]
  • –zones /(x264)
    UNKNOWN (FFmpeg)
    Allows setting a specific quantizer for a specific region of video.
  • –qpfile (x264)
    UNKNOWN (FFmpeg)
    Allows one to read in a set of frametypes and quantizers from a file. Useful for testing various encoding options while ensuring the exact same quantizer distribution.

Analysis:

  • –partitions <string> (x264)
    -partitions <string> (FFmpeg)
    p8x8 (x264) /+partp8x8 (FFmpeg)p4x4 (x264) /+partp4x4 (FFmpeg)b8x8 (x264) /+partb8x8 (FFmpeg)

    i8x8 (x264) /+parti8x8 (FFmpeg)

    i4x4 (x264) /+parti4x4 (FFmpeg)

    One of H.264’s most useful features is the ability to choose among many combinations of inter and intra partitions. P-macroblocks can be subdivided into 16×8, 8×16, 8×8, 4×8, 8×4, and 4×4 partitions. B-macroblocks can be divided into 16×8, 8×16, and 8×8 partitions. I-macroblocks can be divided into 4×4 or 8×8 partitions. Analyzing more partition options improves quality at the cost of speed. The default is to analyze all partitions except p4x4 (p8x8, i8x8, i4x4, b8x8), since p4x4 is not particularly useful except at high bitrates and lower resolutions. Note that i8x8 requires 8x8dct, and is therefore a High Profile-only partition. p8x8 is the most costly, speed-wise, of the partitions, but also gives the most benefit. Generally, whenever possible, all partition types except p4x4 should be used.

  • –direct <integer>(x264)
    -directpred <integer>(FFmpeg)
    B-frames in H.264 can choose between spatial and temporal prediction mode. Auto allows x264 to pick the best of these; the heuristic used is whichever mode allows more skip macroblocks. Auto should generally be used.
  • –direct-8×8 (x264)
    UNKONWN (FFmpeg)
    This should be left at the default (-1).
  • –weightb (x264)
    -flags2 +wpred(FFmpeg)
    This allows B-frames to use weighted prediction options other than the default. There is no real speed cost for this, so it should always be enabled.
  • –me (x264)
    -me_method (FFmpeg)
    dia (x264) / epzs (FFmpeg) is the simplest search, consisting of starting at the best predictor, checking the motion vectors at one pixel upwards, left, down, and to the right, picking the best, and repeating the process until it no longer finds any better motion vector.hex (x264) / hex (FFmpeg) consists of a similar strategy, except it uses a range-2 search of 6 surrounding points, thus the name. It is considerably more efficient than DIA and hardly any slower, and therefore makes a good choice for general-use encoding.umh (x264) / umh (FFmpeg) is considerably slower than HEX, but searches a complex multi-hexagon pattern in order to avoid missing harder-to-find motion vectors. Unlike HEX and DIA, the merange parameter directly controls UMH’s search radius, allowing one to increase or decrease the size of the wide search.

    esa (x264) / full (FFmpeg) is a highly optimized intelligent search of the entire motion search space within merange of the best predictor. It is mathematically equivalent to the bruteforce method of searching every single motion vector in that area, though faster. However, it is still considerably slower than UMH, with not too much benefit, so is not particularly useful for everyday encoding.

    One of the most important settings for x264, both speed and quality-wise.

  • –merange <integer>(x264)
    -me_range <integer>(FFmpeg)
    MErange controls the max range of the motion search. For HEX and DIA, this is clamped to between 4 and 16, with a default of 16. For UMH and ESA, it can be increased beyond the default 16 to allow for a wider-range motion search, which is useful on HD footage and for high-motion footage. Note that for UMH and ESA, increasing MErange will significantly slow down encoding.
  • –mvrange(x264)
    UNKNOWN (FFmpeg)
    Limits the maximum motion vector range. Since x264 by default limits this to 511.75 for standards compliance, this should not be changed.
  • –subme 6(x264)
    -subq 6(FFmpeg)
    1: Fastest, but extremely low quality. Should be avoided except on first pass encoding.

    2-5: Progressively better and slower, 5 serves as a good medium for higher speed encoding.

    6-7: 6 is the default. Activates rate-distortion optimization for partition decision. This can considerably improve efficiency, though it has a notable speed cost. 6 activates it in I/P frames, and subme7 activates it in B frames.

    8-9: Activates rate-distortion refinement, which uses RDO to refine both motion vectors and intra prediction modes. Slower than subme 6, but again, more efficient.

    An extremely important encoding parameter which determines what algorithms are used for both subpixel motion searching and partition decision.

  • –psy-rd <float>:<float> (x264)
    UNKNOWN (FFmpeg)
    First value represents the amount that x264 biases in favor of detail retention instead of max PSNR in mode decision. Requires subme >= 6. Second value is psy-trellis, an experimental algorithm that tries to improve sharpness and detail retention at the expense of more artifacting. Recommended starting values are 0.1-0.2. Requires trellis >= 1. Recommended default: 1.0:0.0
  • –mixed-refs(x264)
    -flags2 +mixed_refs(FFmpeg)
    H.264 allows p8x8 blocks to select different references for each p8x8 block. This option allows this analysis to be done, and boosts quality with little speed impact. It should generally be used, though it obviously has no effect with only one reference frame.
  • –no-chroma-me(x264)
    UNKNOWN (FFmpeg)
    Chroma is used in the last steps of the subpixel refinement by default. For a slight speed increase, this can be disabled (at the cost of quality).
  • –8x8dct (x264)
    -flags2 +dct8x8(FFmpeg)
    Gives a notable quality boost by allowing x264 to choose between 8×8 and 4×4 frequency transform size. Required for i8x8 partitions. Speed cost for this option is near-zero both for encoding and decoding; the only reason to disable it is when one needs support on a device not compatible with High Profile.
  • –trellis <0,1,2>(x264)
    -trellis <0,1,2>(FFmpeg)
    0: disabled1: enabled only on the final encode of a MB2: enabled on all mode decisions

    The main decision made in quantization is which coefficients to round up and which to round down. Trellis chooses the optimal rounding choices for the maximum rate-distortion score, to maximize PSNR relative to bitrate. This generally increases quality relative to bitrate by about 5% for a somewhat small speed cost. It should generally be enabled. Note that trellis requires CABAC.

  • –no-fast-pskip(x264)
    -flags2 -fastpskip(FFmpeg)
    By default, x264 will skip macroblocks in P-frames that don’t appear to have changed enough between two frames to justify encoding the difference. This considerably speeds up encoding. However, for a slight quality boost, P-skip can be disabled. In this case, the full analysis will be done on all P-blocks, and the only skips in the output stream will be the blocks whose motion vectors happen to match that of the skip vector and motion vectors happen to match that of the skip vector and which have no residual. The speed cost of enabling no-fast-pskip is relatively high, especially with many reference frames. There is a similar B-skip internal to x264, which is why B-frames generally encode much faster than P-frames, but it cannot be disabled on the commandline.
  • –no-dct-decimate(x264)
    UNKNOWN (FFmpeg)
    By default, x264 will decimate (remove all coefficients from) P-blocks that are extremely close to empty of coefficents. This can improve overall efficiency with little visual cost, but may work against an attempt to retain grain or similar. DCT decimation should be left on unless there’s a good reason to disable it.
  • –nr(x264)
    UNKNOWN (FFmpeg)
    a fast, built-in noise reduction routine. Not as effective as external filters such as hqdn3d, but faster. Since x264 already naturally reduces noise through its quantization process, this parameter is not usually necessary.
  • –deadzone-inter(264)
    –deadzone-intra (x264)
    UNKNOWN (FFmpeg)
    UNKNOWN (FFmpeg)
    When trellis isn’t activated, deadzone parameters determine how many DCT coefficients are rounded up or down. Rounding up results in higher quality and more detail retention, but costs more bits–so rounding is a balance between quality and bit cost. Lowering these settings will result in more coefficients being rounded up, and raising the settings will result in more coefficients being rounded down. Recommended: keep them at the defaults.
  • –cqm (264)
    –cqpfile(x264)UNKNOWN (FFmpeg)
    UNKNOWN (FFmpeg)
    Allows the use of a custom quantization matrix to weight frequencies differently in the quantization process. The presets quant matrices are “jvt” and “flat”. –cqpfile reads a custom quant matrices from a JM-compatible file. Recommended only if you know what you’re doing.

 

转自:http://rhingheart.blogspot.com/2009/03/ffmpegx264-ffmpeg-x264.html

通过 ffmpeg 无损剪切/拼接视频

剪切/拼接视频文件是一种常见需求。在线视频网站现在往往将一个视频文件分割成 n 段,以减少流量消耗。使用 DownloadHelper/DownThemAll 这类工具下载下来的往往就是分割后的文件。能实现剪切/拼接视频文件的工具多种多样,但往往都需要进行视频重编码(transcoding),这就不可避免的带来了视频质量上的损耗,更不用提那长的令人发指的转换时间了…

其实借助 ffmpeg 我们就可以在不进行视频重编码的情况下完成此类任务:

剪切

其中 START_TIME/STOP_TIME 的格式可以写成两种格式:

  1. 以秒为单位计数: 80
  2. 时:分:秒: 00:01:20

拼接 :

拼接的情况稍微复杂些,我们需要将需要拼接的视频文件按以下格式保存在一个列表 list.txt 中:

相应的命令为:

由于不需要重编码,这两条命令几乎是即时完成的。

方便起见,我写了一个脚本来简化操作。放在 github 上,请自取:
https://gist.github.com/imcaspar/8771268

以上拼接操作生效的前提是,所有视频文件的格式编码相同,如果需要拼接不同格式的视频文件可以借助以下脚本:
https://gist.github.com/imcaspar/8778002

 

>>

-ss START_TIME 这个东西写在 -i 前面会好一点,因为是用得copy,所以显示不出什么差别,但是如果是有进行转码的话就可以体现出优势了

在-i参数前面的 -ss 是针对源文件的,所以会直接从对应的位置开始截取。
在后面的 -ss 是针对目标文件的,会对源文件解码,然后直到对应位置才开始输出。。

-ss 在 -i 前面和后面是不同的 在前面的时候是fast seeking 是不准的 会差几个frame 在后面的时候是accurate seeking 准但是速度慢 根据官网说明(http://trac.ffmpeg.org/wiki/Seeking%20with%20FFmpeg) 应该两个地方都用(fast and accurate seeking)

 

转自:http://segmentfault.com/blog/caspar/1190000000414341?page=1

Seeking with FFmpeg

Cutting small sections

To extract only a small segment in the middle of a movie, it can be used in combination with -t which specifies the duration, like -ss 60 -t 10 to capture from second 60 to 70. Or you can use the -to option to specify an out point, like -ss 60 -to 70 to capture from second 60 to 70. -t and -to are mutually exclusive. If you use both, -t will be used.

Note that if you specify -ss before -i only, the timestamps will be reset to zero, so -t and -to have the same effect:

Here, the first command will cut from 00:01:00 to 00:03:00 (in the original), whereas the second command would cut from 00:01:00 to 00:02:00, as intended.

If you cut with stream copy (-c copy) you need to use the -avoid_negative_ts 1 option if you want to use that segment with the ​concat demuxer .

Example:

Time unit syntax

Note that you can use two different time unit formats: sexagesimal (HOURS:MM:SS.MICROSECONDS, as in 01:23:45.678), or in seconds. If a fraction is used, such as 02:30.05, this is interpreted as “5 100ths of a second”, not as frame 5. For instance, 02:30.5 would be 2 minutes, 30 seconds, and a half a second, which would be the same as using 150.5 in seconds.

Doing a bitstream copy gives me a broken file?

If you use -ss with -c:v copy, the resulting bitstream might end up being choppy, not playable, or out of sync with the audio stream, since ffmpeg is forced to only use/split on i-frames.

 

转自:http://trac.ffmpeg.org/wiki/Seeking%20with%20FFmpeg

How to concatenate (join, merge) media files

Concat demuxer

The concat demuxer was added to FFmpeg 1.1. You can read about it in the documentation.

Instructions

Create a file mylist.txt with all the files you want to have concatenated in the following form (lines starting with a # are ignored):

Note that these can be either relative or absolute paths. Then you can stream copy or re-encode your files:

It is possible to generate this list file with a bash for loop, or using printfEither of the following would generate a list file containing every *.wav in the working directory:

If your shell supports process substitution (like Bash and Zsh), you can avoid explicitly creating a list file and do the whole thing in a single line. This would be impossible with the concat protocol (see below):

You can also loop a video. This example will loop input.mkv 10 times:

Concat protocol

While the demuxer works at the stream level, the concat protocol works at the file level. Certain files (mpg and mpeg transport streams, possibly others) can be concatenated. This is analogous to using cat on UNIX-like systems or copy on Windows.

Instructions

If you have MP4 files, these could be losslessly concatenated by first transcoding them to mpeg transport streams. With h.264 video and AAC audio, the following can be used:

If you’re using a system that supports named pipes, you can use those to avoid creating intermediate files – this sends stderr (which ffmpeg sends all the written data to) to /dev/null, to avoid cluttering up the command-line:

All MPEG codecs (H.264, MPEG4/divx/xvid, MPEG2; MP2, MP3, AAC) are supported in the mpegts container format, though the commands above would require some alteration (the-bsf bitstream filters will have to be changed).

 

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

FFMPEG fields drop and dup

“I was wondering about the meaning of drop and dup at the output of ffmpeg? What is their meaning?”

“Drop” means it has dropped a frame during encoding.

“Dup” means it has duplicated a frame during encoding.

 

来自:http://forums.creativecow.net/thread/291/265