Go to the documentation of this file.
28 #ifndef AVCODEC_H274_H
29 #define AVCODEC_H274_H
36 int8_t
db[13 ][13 ][64][64];
81 const AVFrame *
frame,
int coded_width,
int coded_height);
AVPixelFormat
Pixel format.
int ff_h274_apply_film_grain(AVFrame *out, const AVFrame *in, H274FilmGrainDatabase *db, const AVFilmGrainParams *params)
This structure describes decoded (raw) audio or video data.
it s the only field you need to keep assuming you have a context There is some magic you don t need to care about around this just let it vf type
int16_t slice_tmp[64][64]
int ff_h274_hash_verify(H274HashContext *c, const H274SEIPictureHash *hash, const AVFrame *frame, int coded_width, int coded_height)
static enum AVPixelFormat pix_fmt
@ AV_PIX_FMT_YUV420P
planar YUV 4:2:0, 12bpp, (1 Cr & Cb sample per 2x2 Y samples)
int8_t db[13][13][64][64]
Undefined Behavior In the C some operations are like signed integer dereferencing freed accessing outside allocated Undefined Behavior must not occur in a C it is not safe even if the output of undefined operations is unused The unsafety may seem nit picking but Optimizing compilers have in fact optimized code on the assumption that no undefined Behavior occurs Optimizing code based on wrong assumptions can and has in some cases lead to effects beyond the output of computations The signed integer overflow problem in speed critical code Code which is highly optimized and works with signed integers sometimes has the problem that often the output of the computation does not c
int ff_h274_hash_init(H274HashContext **c, int type)
This structure describes how to handle film grain synthesis in video for specific codecs.
uint8_t display_elemental_periods
these buffered frames must be flushed immediately if a new input produces new the filter must not call request_frame to get more It must just process the frame or queue it The task of requesting more frames is left to the filter s request_frame method or the application If a filter has several the filter must be ready for frames arriving randomly on any input any filter with several inputs will most likely require some kind of queuing mechanism It is perfectly acceptable to have a limited queue and to drop frames when the inputs are too unbalanced request_frame For filters that do not use the this method is called when a frame is wanted on an output For a it should directly call filter_frame on the corresponding output For a if there are queued frames already one of these frames should be pushed If the filter should request a frame on one of its repeatedly until at least one frame has been pushed Return or at least make progress towards producing a frame
static int ff_h274_film_grain_params_supported(int model_id, enum AVPixelFormat pix_fmt)
Check whether ff_h274_apply_film_grain() supports the given parameter combination.
void ff_h274_hash_freep(H274HashContext **c)