Go to the source code of this file.
|
| static int | get_block (GetBitContext *gb, int16_t *block, const uint8_t *scan, const uint32_t *quant) |
| | read one block from stream More...
|
| |
| int | ff_rtjpeg_decode_frame_yuv420 (RTJpegContext *c, AVFrame *f, const uint8_t *buf, int buf_size) |
| | decode one rtjpeg YUV420 frame More...
|
| |
| void | ff_rtjpeg_decode_init (RTJpegContext *c, int width, int height, const uint32_t *lquant, const uint32_t *cquant) |
| | initialize an RTJpegContext, may be called multiple times More...
|
| |
| void | ff_rtjpeg_init (RTJpegContext *c, AVCodecContext *avctx) |
| |
Value:The exact code depends on how similar the blocks are and how related they are to the block
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
static const double coeff[2][5]
Definition at line 25 of file rtjpeg.c.
Referenced by get_block().
Value:The reader does not expect b to be semantically here and if the code is changed by maybe adding a a division or other the signedness will almost certainly be mistaken To avoid this confusion a new type was SUINT is the C unsigned type but it holds a signed int to use the same example SUINT a
static int get_bits_count(const GetBitContext *s)
static void skip_bits(GetBitContext *s, int n)
aligns the bitstream to the given power of two
Definition at line 30 of file rtjpeg.c.
Referenced by get_block().
Value:} while (0)
static int get_block(GetBitContext *gb, int16_t *block, const uint8_t *scan, const uint32_t *quant)
read one block from stream
The exact code depends on how similar the blocks are and how related they are to the block
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
GLint GLenum GLboolean GLsizei stride
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 it should return
Referenced by ff_rtjpeg_decode_frame_yuv420().
read one block from stream
- Parameters
-
| gb | contains stream data |
| block | where data is written to |
| scan | array containing the mapping stream address -> block position |
| quant | quantization factors |
- Returns
- 0 means the block is not coded, < 0 means an error occurred.
Note: GetBitContext is used to make the code simpler, since all data is aligned this could be done faster in a different way, e.g. as it is done in MPlayer libmpcodecs/native/rtjpegn.c.
Definition at line 46 of file rtjpeg.c.
decode one rtjpeg YUV420 frame
- Parameters
-
| c | context, must be initialized via ff_rtjpeg_decode_init |
| f | AVFrame to place decoded frame into. If parts of the frame are not coded they are left unchanged, so consider initializing it |
| buf | buffer containing input data |
| buf_size | length of input data in bytes |
- Returns
- number of bytes consumed from the input buffer
Definition at line 106 of file rtjpeg.c.
Referenced by decode_frame().
| void ff_rtjpeg_decode_init |
( |
RTJpegContext * |
c, |
|
|
int |
width, |
|
|
int |
height, |
|
|
const uint32_t * |
lquant, |
|
|
const uint32_t * |
cquant |
|
) |
| |
initialize an RTJpegContext, may be called multiple times
- Parameters
-
| c | context to initialize |
| width | width of image, will be rounded down to the nearest multiple of 16 for decoding |
| height | height of image, will be rounded down to the nearest multiple of 16 for decoding |
| lquant | luma quantization table to use |
| cquant | chroma quantization table to use |
Definition at line 158 of file rtjpeg.c.
Referenced by codec_reinit(), and decode_frame().
1.8.11
