[Home]Transcode Internals/Optimisations

No diff available--this is the first major revision. (no other diffs)

Introduction

Then this might be for you.

Transcode has a lot of filter plugins which are not optimized. Filters in transcode usually get a single video frame and do transformations on that frame. The filter API is as simple as efficient it is explained in great detail in /docs/filter-API.txt with sample code for a dummy filter.

All filters in transcode are in the filter/ directory and are mostly a single C file. The variety of filters ranges from very simple filters -- like filter_invert.c -- to complex stuff like filter_yuvdenoise.c.

The audio filters are per definition less CPU intensive than the video filters because they have to deal with less data.

Here is an overview of filters which would be glad about a speedup (lexicographical order)

Is a interlace detection plugin. The detection algorithm could be improved as well as the speed.

Audio filter which generate audio clips from source

Audio filter which collects statistics about the audio stream.

A chroma-lag shifter. It shifts the color components of the video to the left or right. For RGB mode, the filter implements its own rgb2yuv conversion.

A denoiser with no SIMD optimizations It uses a different algorithm than the yuvdenoiser.

A very efficient and well written filter.

Simple filter which inverts the video.

renders a logo into the video stream.

removes a logo from the video stream.

Filter through a rectangular mask, everything outside the masked will be blacked out.

Normalizes the audio stream. The filter is based on mplayers volnorm filter.

Resamples to audio stream doing conversions from eg. 48000Hz to 44100Hz. The code is based on code from the sox application.

This filter provides a smart, motion-based deinterlacing capability. In static picture areas, interlacing artifacts do not appear, so data from both fields is used to provide full detail. In moving areas, deinterlacing is performed.

The filter was written for VirtualDub by Donald Graft. It produces very good results. It was written with the RGB colorspace in mind. To use it in transcode with YUV mode enabled a yuv2rgb and rgb2yuv wrapper has been build around this filter. It would speed up a lot, if rewritten for native YUV mode. There are probably other areas in this filter which are a candidate for a speedup.

Is a single-frame smoothing plugin. It is very CPU intensive

It generates stream of testframes. Optimizing this filter is probably not worth it but it is a good testbed for generating problematic testframes.

This filter performs a subtle but useful sharpening effect. The result is a sharpening effect that not only avoids amplifying noise, but also tends to reduce it. A welcome side effect is that files processed with this filter tend to compress to smaller files.

The filter was written for VirtualDub by Donald Graft. It was written with the RGB colorspace in mind. To be useful with transcodes YUV mode, the filter has been partially rewritten.

This filter comes from the mjpeg tools and denoises the video by doing a motion analyse. There are some SIMD parts in this filter but it could be much faster.

This filter comes from the mjpeg tools and smoothes the video by appying a median algorithm. It is CPU intensive.

This filter does a colorspace conversion from YUY2 to YV12. A speedup would be possible by optimizing the downsample algorithm.

Colorspaces

In transcode, the filter gets a char* which points to the raw video data. Only two colorspaces are possible in transcode.

RGB

This is actually RGB24 meaning there are 24 bits or 3 Bytes available for each pixel. It is a packed format, each component is 1 byte large. The size of the image is Width*Height*3. The memory layout is
 ___________________________________
|__R__|__G__|__B__|__R__|__G__|__B__| ....
 \_______________/ \_______________/
    Pixel(0,0)        Pixel(1,0)

YUV (4:2:0)

This is actually YV12 or Y420 with 1+1/2 byte per pixel. It is a planar format meaning first all Y data then Cr and then Cb. The memory layout is
 __________________ ...  ______  ...  _____
|__Y__|__Y__|__Y__| ... |__Cr_|  ... |__Cb_| ....
 \___/ \___/ \___/     
 (0,0) (1,0) (2,0)

There are Width*Height Y bytes, Width*Height/4 Cr bytes and Width*Height/4 Cb bytes. The size of the image is Width*Height*3/2

YUV (4:2:2)

This is UYVY 8-bit packed.
 _______________________________________  ....
|_U1_|_Y1_|_V1_|_Y2_|_U3_|_Y3_|_V3_|_Y4_| ....
 \_________________/ \_________________/
    Pixel 1 and 2       Pixel 3 and 4

Size of the image is 2*W*H.

(c) 2003 Tilmann Bitterberg <transcode@tibit.org> Modified: Tue Oct 14 10:35:46 CEST 2003


Transcode Wiki | Transcode Internals | Recent Changes | Preferences
Password required to edit | View other revisions
Last edited January 4, 2005 8:11 pm by Monroe (diff)
Search: