爲ffmpeg添加自定義濾鏡

原創 anbinger2013 2020-02-24 15:07

http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=26000296&id=3068068

 

前言
FFmpeg的優秀在於它的功能強大和良好的系統框架，而濾鏡就是其中之一。ffmpeg的自帶濾鏡不但能對視頻進行裁剪，添加logo，還能將多個濾鏡組全使用。
更妙之處在於它還可以方便地添加自己定義的各種濾鏡。這種可擴展性對於實際應用來說就頗有價值了。

閒言少述，書歸正傳！
本文第一部分是我對wiki上的一篇教程的翻譯和解釋，但是它並沒有講解如何將寫好的濾鏡添加到ffmpeg中編譯並運行。
第二部分是我自己實踐了的如何將濾鏡添加進ffmpeg中進行編譯和運行(版本ffmpeg-0.8.5)。
最後一部分附上示例用的濾鏡源碼(版本ffmpeg-0.8.5)。

Chapter 1  : 
FFmpeg filter HOWTO
(本章節引自http://wiki.multimedia.cx/index.php?title=FFmpeg_filter_howto)

This page is meant as an introduction of writing filters for libavfilter. This is a work in progress, but should at least point you in the right direction for writing simple filters.

Contents
1. Definition of a filter
      1.1 AVFilter
      1.2 AVFilterPad
2. Picture buffers
      2.1  Reference counting
      2.2 Permissions
3. Filter Links
4. Writing a simple filter
      4.1 Default filter entry points
      4.2 The vf_negate filter
Definition of a filter AVFilter

All filters are described by an AVFilter structure. This structure gives information needed to initialize the filter, and information on the entry points into the filter code. This structure is declared in libavfilter/avfilter.h:

濾鏡的數據結構體(包括需要初始化濾鏡變量，濾鏡的函數入口點等)定義在libavfilter/avfilter.h中:

  1. typedef struct
  2. {
  3.     char *name; ///< filter name

  5.     int priv_size; ///< size of private data to allocate for the filter

  7.     int (*init)(AVFilterContext *ctx, const char *args, void *opaque);
  8.     void (*uninit)(AVFilterContext *ctx);

  10.     int (*query_formats)(AVFilterContext *ctx);

  12.     const AVFilterPad *inputs; ///< NULL terminated list of inputs. NULL if none
  13.     const AVFilterPad *outputs; ///< NULL terminated list of outputs. NULL if none
  14. } AVFilter;

The query_formats function sets the in_formats member of connected output links, and the out_formats member of connected input links, described below under AVFilterLink.

query_formats 函數設置濾鏡輸入，輸出圖像的格式,如YUV420,YUV422等。

AVFilterPad

Let's take a quick look at the AVFilterPad structure, which is used to describe the inputs and outputs of the filter. This is also defined in libavfilter/avfilter.h:

AVFilterPad結構體用於描述濾鏡的輸入和輸出。

  1. typedef struct AVFilterPad
  2. {
  3.     char *name;
  4.     int type;

  6.     int min_perms;
  7.     int rej_perms;

  9.     void (*start_frame)(AVFilterLink *link, AVFilterPicRef *picref);
  10.     AVFilterPicRef *(*get_video_buffer)(AVFilterLink *link, int perms);
  11.     void (*end_frame)(AVFilterLink *link);
  12.     void (*draw_slice)(AVFilterLink *link, int y, int height);

  14.     int (*request_frame)(AVFilterLink *link);

  16.     int (*config_props)(AVFilterLink *link);
  17. } AVFilterPad;

The actual definition in the header file has doxygen comments describing each entry point, its purpose, and what type of pads it is relevant for. These fields are relevant for all pads:

Field Description
name Name of the pad. No two inputs should have the same name, and no two outputs should have the same name.
(pad的名稱，當有多於一個的輸入或輸出時，不要重名)
type Only AV_PAD_VIDEO currently.
config_props Handles configuration of the link connected to the pad

Fields only relevant to input pads are:

Field Description
min_perms Minimum permissions required to a picture received as input.
(本濾鏡要求的輸入圖像的最小授權)
rej_perms Permissions not accepted on pictures received as input.
start_frame Called when a frame is about to be given as input.
draw_slice Called when a slice of frame data has been given as input.
(主要的濾鏡處理函數)
end_frame Called when the input frame has been completely sent.
get_video_buffer Called by the previous filter to request memory for a picture.

Fields only relevant to output pads are:

Field Description
request_frame Requests that the filter output a frame.
Picture buffers Reference counting(引用計數)

All pictures in the filter system are reference counted. This means that there is a picture buffer with memory allocated for the image data, and various filters can own a reference to the buffer. When a reference is no longer needed, its owner frees the reference. When the last reference to a picture buffer is freed, the filter system automatically frees the picture buffer.

濾鏡系統中所有的圖像都是有計數的引用。意即，有一個分配了存儲空間的圖像buffer,而每個濾鏡可以有自己的引用指向這個圖像buffer。當這個引用不再需要時，擁有這個引用的濾鏡將釋放這個引用。當圖像buffer的最後一個引用也被釋放時，濾鏡系統將自動釋放這個圖像buffer。

Permissions(組合濾鏡的授權問題)

The upshot of multiple filters having references to a single picture is that they will all want some level of access to the image data. It should be obvious that if one filter expects to be able to read the image data without it changing that no other filter should write to the image data. The permissions system handles this.

使用組合濾鏡的結果就是會有多個引用指向同一個圖像buffer，而且它們都希望對buffer中的圖像有相同的訪問權限。這時就會產生衝突啦，例如，當一個濾鏡有讀取buffer中圖像數據的權限時，肯定不希望有別的濾鏡同時在改定buffer中的圖像數據。解決這種衝突就需要授權系統來處理。

In most cases, when a filter prepares to output a frame, it will request a buffer from the filter to which it will be outputting. It specifies the minimum permissions it needs to the buffer, though it may be given a buffer with more permissions than the minimum it requested.

通常，當濾鏡準備輸出一幀數據時，它會向濾鏡系統請求一個輸出buffer,這時，濾鏡系統會返回一個buffer結該濾鏡並將這個buffer授予最小的權限。

When it wants to pass this buffer to another filter as output, it creates a new reference to the picture, possibly with a reduced set of permissions. This new reference will be owned by the filter receiving it.

噹噹前濾鏡要將圖像buffer輸出給下一個濾鏡時，該濾鏡會創建一個指向圖像buffer的新引用，這個buffer的授權可能會減小。而這個新的引用會被下一個濾鏡接收。

So, for example, for a filter which drops frames if they are similar to the last frame it output, it would want to keep its own reference to a picture after outputting it, and make sure that no other filter modified the buffer either. It would do this by requesting the permissions AV_PERM_READ|AV_PERM_WRITE|AV_PERM_PRESERVE for itself, and removing the AV_PERM_WRITE permission from any references it gave to other filters.

這段沒搞明白什麼意思

The available permissions are:

Permission Description
AV_PERM_READ Can read the image data.
AV_PERM_WRITE Can write to the image data.
AV_PERM_PRESERVE Can assume that the image data will not be modified by other filters. This means that no other filters should have the AV_PERM_WRITE permission.
AV_PERM_REUSE The filter may output the same buffer multiple times, but the image data may not be changed for the different outputs.
AV_PERM_REUSE2 The filter may output the same buffer multiple times, and may modify the image data between outputs.
Filter Links

A filter's inputs and outputs are connected to those of another filter through the AVFilterLink structure:

  1. typedef struct AVFilterLink
  2. {
  3.     AVFilterContext *src; ///< source filter
  4.     unsigned int srcpad; ///< index of the output pad on the source filter

  6.     AVFilterContext *dst; ///< dest filter
  7.     unsigned int dstpad; ///< index of the input pad on the dest filter

  9.     int w; ///< agreed upon image width
  10.     int h; ///< agreed upon image height
  11.     enum PixelFormat format; ///< agreed upon image colorspace

  13.     AVFilterFormats *in_formats; ///< formats supported by source filter
  14.     AVFilterFormats *out_formats; ///< formats supported by destination filter

  16.     AVFilterPicRef *srcpic;

  18.     AVFilterPicRef *cur_pic;
  19.     AVFilterPicRef *outpic;
  20. };

The src and dst members indicate the filters at the source and destination ends of the link, respectively. The srcpad indicates the index of the output pad on the source filter to which the link is connected. Likewise, the dstpad indicates the index of the input pad on the destination filter.

The in_formats member points to a list of formats supported by the source filter, while the out_formats member points to a list of formats supported by the destination filter. The AVFilterFormats structure used to store the lists is reference counted, and in fact tracks its references (see the comments for the AVFilterFormats structure in libavfilter/avfilter.h for more information on how the colorspace negotiation is works and why this is necessary). The upshot is that if a filter provides pointers to the same list on multiple input/output links, it means that those links will be forced to use the same format as each other.

When two filters are connected, they need to agree upon the dimensions of the image data they'll be working with, and the format that data is in. Once this has been agreed upon, these parameters are stored in the link structure.

The srcpic member is used internally by the filter system, and should not be accessed directly.

The cur_pic member is for the use of the destination filter. When a frame is currently being sent over the link (ie. starting from the call to start_frame() and ending with the call to end_frame()), this contains the reference to the frame which is owned by the destination filter.

The outpic member is described in the following tutorial on writing a simple filter.

Writing a simple filter Default filter entry points

Because the majority of filters that will probably be written will take exactly one input, and produce exactly one output, and output one frame for every frame received as input, the filter system provides a number default entry points to ease the development of such filters. 

Entry point Actions taken by the default implementation
request_frame() Request a frame from the previous filter in the chain.
query_formats() Sets the list of supported formats on all input pads such that all links must use the same format, from a default list of formats containing most YUV and RGB/BGR formats.
start_frame() Request a buffer to store the output frame in. A reference to this buffer is stored in the outpic member of the link hooked to the filter's output. The next filter's start_frame() callback is called and given a reference to this buffer.
end_frame() Calls the next filter's end_frame() callback. Frees the reference to the outpic member of the output link, if it was set by (ie. if the default start_frame() is used). Frees the cur_pic reference in the input link.
get_video_buffer() Returns a buffer with the AV_PERM_READ permission in addition to all the requested permissions.
config_props() on output pad Sets the image dimensions for the output link to the same as on the filter's input.
The vf_negate filter

Having looked at the data structures and callback functions involved, let's take a look at an actual filter. The vf_negate filter inverts the colors in a video. It has one input, and one output, and outputs exactly one frame for every input frame. In this way, it's fairly typical, and can take advantage of many of the default callback implementations offered by the filter system.

First, let's take a look at the AVFilter structure at the bottom of the libavfilter/vf_negate.c file:

  1. AVFilter avfilter_vf_negate =
  2. {
  3.     .name = "negate",

  5.     .priv_size = sizeof(NegContext),

  7.     .query_formats = query_formats,

  9.     .inputs = (AVFilterPad[]) {{ .name = "default",
  10.                                     .type = AV_PAD_VIDEO,
  11.                                     .draw_slice = draw_slice,
  12.                                     .config_props = config_props,
  13.                                     .min_perms = AV_PERM_READ, },
  14.                                   { .name = NULL}},
  15.     .outputs = (AVFilterPad[]) {{ .name = "default",
  16.                                     .type = AV_PAD_VIDEO, },
  17.                                   { .name = NULL}},
  18. };

Here, you can see that the filter is named "negate," and it needs sizeof(NegContext) bytes of data to store its context. In the list of inputs and outputs, a pad whose name is set to NULL indicates the end of the list, so this filter has exactly one input and one output. If you look closely at the pad definitions, you will see that fairly few callback functions are actually specified. Because of the simplicity of the filter, the defaults can do most of the work for us.

Let us take a look at the callback function it does define.

query_formats()
  1. static int query_formats(AVFilterContext *ctx)
  2. {
  3.     avfilter_set_common_formats(ctx,
  4.         avfilter_make_format_list(10,
  5.                 PIX_FMT_YUV444P, PIX_FMT_YUV422P, PIX_FMT_YUV420P,
  6.                 PIX_FMT_YUV411P, PIX_FMT_YUV410P,
  7.                 PIX_FMT_YUVJ444P, PIX_FMT_YUVJ422P, PIX_FMT_YUVJ420P,
  8.                 PIX_FMT_YUV440P, PIX_FMT_YUVJ440P));
  9.     return 0;
  10. }

This calls avfilter_make_format_list(). This function takes as its first parameter the number of formats which will follow as the remaining parameters. The return value is an AVFilterFormats structure containing the given formats. The avfilter_set_common_formats() function which this structure is passed to sets all connected links to use this same list of formats, which causes all the filters to use the same format after negotiation is complete. As you can see, this filter supports a number of planar YUV colorspaces, including JPEG YUV colorspaces (the ones with a 'J' in the names).

config_props() on an input pad

The config_props() on an input pad is responsible for verifying that the properties of the input pad are supported by the filter, and to make any updates to the filter's context which are necessary for the link's properties.

TODO: quick explanation of YUV colorspaces, chroma subsampling, difference in range of YUV and JPEG YUV.

Let's take a look at the way in which this filter stores its context: 

  1. typedef struct
  2. {
  3.     int offY, offUV;
  4.     int hsub, vsub;
  5. } NegContext;

That's right. The priv_size member of the AVFilter structure tells the filter system how many bytes to reserve for this structure. The hsub and vsub members are used for chroma subsampling, and the offY and offUV members are used for handling the difference in range between YUV and JPEG YUV. Let's see how these are set in the input pad's config_props: 

  1. static int config_props(AVFilterLink *link)
  2. {
  3.     NegContext *neg = link->dst->priv;

  5.     avcodec_get_chroma_sub_sample(link->format, &neg->hsub, &neg->vsub);

  7.     switch(link->format) {
  8.     case PIX_FMT_YUVJ444P:
  9.     case PIX_FMT_YUVJ422P:
  10.     case PIX_FMT_YUVJ420P:
  11.     case PIX_FMT_YUVJ440P:
  12.         neg->offY =
  13.         neg->offUV = 0;
  14.         break;
  15.     default:
  16.         neg->offY = -4;
  17.         neg->offUV = 1;
  18.     }

  20.     return 0;
  21. }

This simply calls avcodec_get_chroma_sub_sample() to get the chroma subsampling shift factors, and stores those in the context. It then stores a set of offsets for compensating for different luma/chroma value ranges for JPEG YUV, and a different set of offsets for other YUV colorspaces. It returns zero to indicate success, because there are no possible input cases which this filter cannot handle.

draw_slice()

Finally, the function which actually does the processing for the filter, draw_slice():

  1. static void draw_slice(AVFilterLink *link, int y, int h)
  2. {
  3.     NegContext *neg = link->dst->priv;
  4.     AVFilterPicRef *in = link->cur_pic;
  5.     AVFilterPicRef *out = link->dst->outputs[0]->outpic;
  6.     uint8_t *inrow, *outrow;
  7.     int i, j, plane;

  9.     /* luma plane */
  10.     inrow = in-> data[0] + y * in-> linesize[0];
  11.     outrow = out->data[0] + y * out->linesize[0];
  12.     for(i = 0; i < h; i ++) {
  13.         for(j = 0; j < link->w; j ++)
  14.             outrow[j] = 255 - inrow[j] + neg->offY;
  15.         inrow += in-> linesize[0];
  16.         outrow += out->linesize[0];
  17.     }

  19.     /* chroma planes */
  20.     for(plane = 1; plane < 3; plane ++) {
  21.         inrow = in-> data[plane] + (y >> neg->vsub) * in-> linesize[plane];
  22.         outrow = out->data[plane] + (y >> neg->vsub) * out->linesize[plane];

  24.         for(i = 0; i < h >> neg->vsub; i ++) {
  25.             for(j = 0; j < link->w >> neg->hsub; j ++)
  26.                 outrow[j] = 255 - inrow[j] + neg->offUV;
  27.             inrow += in-> linesize[plane];
  28.             outrow += out->linesize[plane];
  29.         }
  30.     }

  32.     avfilter_draw_slice(link->dst->outputs[0], y, h);
  33. }

The y parameter indicates the top of the current slice, and the h parameter the slice's height. Areas of the image outside this slice should not be assumed to be meaningful (though a method to allow this assumption in order to simplify boundary cases for some filters is coming in the future).

This sets inrow to point to the beginning of the first row of the slice in the input, and outrow similarly for the output. Then, for each row, it loops through all the pixels, subtracting them from 255, and adding the offset which was determined in config_props() to account for different value ranges.

It then does the same thing for the chroma planes. Note how the width and height are shifted right to account for the chroma subsampling.

Once the drawing is completed, the slice is sent to the next filter by calling avfilter_draw_slice().

Chapter 2:

將濾鏡添加進ffmpeg中編譯和運行

1. configure中聲明使用的協議

  1. # filters
  2. ...
  3. tnegate_filter_deps="gpl"

2. libavfilter/allfilter.c中註冊自定義濾鏡

  1. void avfilter_register_all(void)
  2. {
  3.     ...

  5.     REGISTER_FILTER (TNEGATE, tnegate, vf);
  6.     ...
  7. }

3. libavfilter/Makfile中添加濾鏡的鏈接

  1. OBJS = allfilters.o \
  2.        avfilter.o \
  3.        avfiltergraph.o \
  4.        defaults.o \
  5.        drawutils.o \
  6.        formats.o \
  7.        graphparser.o \

  9. OBJS-$(CONFIG_AVCODEC) += avcodec.o
  10. ...
  11. OBJS-$(CONFIG_TNEGATE_FILTER) += vf_tnegate.o

4. configure設置

  1. ./configure \
  2. --enable-gpl --enable-nonfree --enable-version3 \
  3. ...
  4. --enable-avfilter --enable-filter=movie \
  5. --enable-avfilter --enable-filter=tnegate

5. 編譯與運行

  1. #make
  2. #./ffmpeg -i input.flv -vf "tnegate" -y output.flv

chapter 3: 

反相濾鏡源碼

  1. libavfilter/vf_tnegate.c

  3. #include "libavutil/eval.h"
  4. #include "libavutil/opt.h"
  5. #include "libavutil/pixdesc.h"
  6. #include "libavcodec/avcodec.h"
  7. #include "avfilter.h"

  9. typedef struct
  10. {
  11.   int hsub, vsub; // Used for chroma subsampling
  12. }NegContext;

  14. /* */
  15. static int tnegate_config_props(AVFilterLink *link)
  16. {
  17.   NegContext *neg = link->dst->priv;

  19.   avcodec_get_chroma_sub_sample(link->format, &neg->hsub, &neg->vsub);
  20.   switch(link->format)
  21.   {
  22.     case PIX_FMT_YUVJ444P:
  23.     case PIX_FMT_YUVJ422P:
  24.     case PIX_FMT_YUVJ420P:
  25.     case PIX_FMT_YUVJ440P:
  26.       neg->offY =
  27.       neg->offUV = 0;
  28.       break;
  29.     default:
  30.       neg->offY = -4;
  31.       neg->offUV= 1;
  32.   }
  33.   return 0;
  34. }

  36. static void tnegate_draw_slice(AVFilterLink *link, int y, int h, int slice_dir)
  37. {
  38.   NegContext *neg = link->dst->priv;
  39.   //AVFilterPicRef *in = link->cur_pic;
  40.   //AVFilterPicRef *out = link->dst->outputs[0]->outpic;
  41.   AVFilterBufferRef *in = link->cur_buf;
  42.   AVFilterBufferRef *out = link->dst->outputs[0]->out_buf;
  43.   unsigned char *inrow, *outrow;
  44.   int i, j, plane;

  46.   /* luma plane */
  47.   inrow = in-> data[0] + y * in-> linesize[0]; // Get the row position of pixel
  48.   outrow = out->data[0] + y * out->linesize[0];

  50.   for(i = 0; i < h; i++)
  51.   {
  52.     for(j = 0; j < link->w; j++)
  53.       outrow[j] = 255 -inrow[j] + neg->offY;
  54.     outrow += in->linesize[0];
  55.   }

  57.   /* chroma planes */
  58.   for(plane = 1; plane < 3; plane++)
  59.   {
        inrow  = in-> data[plane] + (y >> neg->vsub) * in-> linesize[plane];
        outrow = out->data[plane] + (y >> neg->vsub) * out->linesize[plane];

        for(i = 0; i < (h >> neg->vsub); i++)
        {
          for(j = 0; j < (link->w >> neg->vsub); j++)
            outrow[j] = 255 - inrow[j] + neg->offUV;

  61.       inrow += in-> linesize[plane];
  62.       outrow += out->linesize[plane];
  63.     }
  64.   }
  65.   avfilter_draw_slice(link->dst->outputs[0], y, h, 1);
  66. }

  68. static int tnegate_query_formats(AVFilterContext *ctx)
  69. {
  70.   static const enum PixelFormat pix_fmts[] = {
  71.     PIX_FMT_YUV410P, PIX_FMT_YUV420P, PIX_FMT_GRAY8, PIX_FMT_NV12,
  72.     PIX_FMT_NV21, PIX_FMT_YUV444P, PIX_FMT_YUV422P, PIX_FMT_YUV411P,
  73.     PIX_FMT_NONE
  74.   };
  75.   avfilter_set_common_pixel_formats(ctx, avfilter_make_format_list(pix_fmts));
  76.   return 0;
  77. }

  79. /* the filter's structure */
  80. AVFilter avfilter_vf_tnegate =
  81. {
  82.   .name = "tnegate", ///< filter name
  83.   .priv_size = sizeof(NegContext), ///< size of private data to allocate for the filter
  84.   .query_formats = tnegate_query_formats, ///< set the format of in/outputs
  85.  
  86.   /* the inputs of the filter */
  87.   .inputs = (AVFilterPad[]){{ .name = "default",
  88.                               .type = AVMEDIA_TYPE_VIDEO,
  89.                               .draw_slice = tnegate_draw_slice,
  90.                               .config_props = tnegate_config_props,
  91.                               .min_perms = AV_PERM_READ,},
  92.                             { .name = NULL }},
  93.   /* the ouputs of the filter */
  94.   .outputs = (AVFilterPad[]){{ .name = "default",
  95.                                .type = AVMEDIA_TYPE_VIDEO, },
  96.                              { .name = NULL }},
  97. };


 

發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章

一個簡單的視頻播放器(基於FFMPEG4.0+SDL2.0.8，在Ubuntu 14.04下開發驗證) - 續2

昨天那個例子，在 Ubuntu 14.04下播放視頻時，有個問題，有播放幾秒後，畫面就變成黑白的了。剛開始懷疑是UV數據丟失，不過在將YUV數據輸出到文件，用YUV Player Deluxe播放，畫面色彩正常着。今天在主程序中新起了一個

BeALinuxGraphicCoder 2020-07-07 21:24:29

一個純粹的視頻解碼程序(基於FFMPEG 4.0，在Ubuntu 14.04下驗證)

程序功能：將指定的視頻文件，解碼爲原始YUV數據，只包含視頻流。開發環境：Ubuntu 14.04, GCC 4.8.4, FFMPEG 4.0編譯方法： 將代碼copy命名爲SimpleDecoder.c，與Makefile放置於同一目

BeALinuxGraphicCoder 2020-07-07 21:24:29

FFMPEG AAC編碼

gcc AAC.c -L /usr/local/ffmpeg/lib -lavutil -lavcodec -o AAC ./AAC   #include <stdint.h> #include <stdio.h> #in

ChaoLi_Chen 2020-07-06 11:14:13

FFMPEG H264 編碼

使用H264 編碼  gcc encode_video.c -L /usr/local/ffmpeg/lib -lavutil -lavformat -lavcodec -o encode_video ./encode_vi

ChaoLi_Chen 2020-07-06 11:14:13

windows 下使用 MinGW + msys 編譯 ffmpeg

    本文參考了網絡上的不少文章，但由於版本環境的問題參考文章並不能直接指導編譯，本文吸收多方經驗，並在自己多次編譯實驗的基礎上寫成，歡迎轉載，請註名出處。    FFmpeg是在Linux平臺下開發的，但它同樣可以在其它操作系統環境中

FISH_LJZ 2020-07-05 23:39:16

ffmpeg主要數據結構和函數

FFMpeg 中比較重要的函數以及數據結構如下： 1. 數據結構： (1) AVFormatContext (2) AVOutputFormat (3) AVInputFormat (4) AVCodecContext (5) AV

FISH_LJZ 2020-07-05 23:39:16

【FFMPEG】1. Windows中ffmpeg命令行環境的搭建

一、FFMPEG下載 首先去FFMPEG官網下載編譯好的包。按如下方式下載。     二、拷貝可執行文件到C:\Windows   三、拷貝動態鏈接庫到C:\Windows\SysWOW64 四、打開cmd命令行窗口 輸入ffm

zhubao124 2020-07-04 23:39:12

【FFMPEG】7. ffmpeg命令提取音視頻數據

一、保留封裝格式 1. 保留原始的音頻流封裝格式 ffmpeg -i test.mp4 -acodec copy -vn audio.mp4   2. 保留原始的視頻流封裝格式 ffmpeg -i test.mp4 -vcodec c

zhubao124 2020-07-04 23:39:12

ffmpeg 1.0 filter模塊AVFilterPad結構的權限屬性min_perms/rej_perms分析

2014 10 19 ffmpeg 1.0 filter模塊AVFilterPad結構的權限屬性min_perms/rej_perms分析： 1.註釋翻譯     輸入pad:     輸入buffer最小權限要求.     如果buf

anbinger2013 2020-07-03 17:28:58

FFmpeg filter HOWTO

http://blog.yikuyiku.com/?p=3023   【 翻譯 】FFmpeg filter HOWTO 2012 年 2 月 22 日實踐、翻譯ffmpeg、libavfilter、濾鏡chen 定義一個濾鏡 AV

anbinger2013 2020-07-03 16:49:08

ffmpeg 1.0 filter模塊Buffersrc/ vf_format文件在format轉換中的作用

2014 10 22 ffmpeg 1.0 filter模塊Buffersrc/ vf_format文件在format轉換中的作用：   Buffersrc.c 通過init_video初試化了輸入格式爲yuv420p,如下： stat

anbinger2013 2020-07-03 16:49:08

Ffmpeg 1.0 Filter format流程分析

201410 22 Ffmpeg1.0 Filter format流程分析          Ffmpeg –y – i vga.3gp –vcodec libx264 –an –strict -2 merge.3gp Filter爲:

anbinger2013 2020-07-03 16:49:08

Ffmpeg 1.0 contact分析

2014 10 27 Ffmpeg 1.0 contact分析 ffmpeg -y -i test.3gp -i test1.3gp -filter_complex 'concat' -c:v libx264 -an -strict -2

anbinger2013 2020-07-03 16:49:08

ffmpeg 1.0 filter的picref流程分析

2014 10 19 ffmpeg 1.0 filter的picref流程分析:   ffmpeg -y -i vga.3gp -vcodec libx264 -an -strict -2 merge.3gp 該命令產生4個filter:

anbinger2013 2020-07-03 16:49:08

ffmpeg 水印問題

一、ffmpeg添加水印的2中方式： fmpeg -y -i demo.3gp -i icon-72.png -filter_complex overlay=10:10 -vcodec li bx264 -acodec copy -str

anbinger2013 2020-07-03 16:48:57