[vlc-devel] Documentation for the TS muxer and transcoder

[Christophe Massiot]

Hello,

A few words about what is in the CVS currently. This requires the CVS
of ffmpeg also. To transcode a channel, I currently use the following
command-line :

./vlc -vvv -I dummy --rt-priority --ttl 8 --cr-average 1000 \
			--udp-caching=500 [...] --sout \
			"#transcode{vb=3300,width=480,bframes=2,noise_reduction=250,threads=4,vt=100000,hq=rd,trellis,height=576,interlace,vcodec=mp2v,keyint=36,mpeg4_matrix,strict_rc,hurry_up}:transrate{vb=3500000,shaping=1500}:std{access=rtp{caching=1000,group=5},mux=ts{bmax=4500000,pcr=80,shaping=1500,use-key-frames,dts-delay=350,pid-video=0x44,pid-audio=0x45},url=[...]}"

--udp-caching=500 is required for proper operation of the transcode
module. If it's too small the HURRYUP_GUARD values in ffmpeg/encoder.c
will be reach too frequently.

--rt-priority is required if you want precise scheduling of the UDP
packet of the UDP packets. Otherwise packets may go out too late.

noise_reduction=250 is to remove details. Otherwise encoding at 3300
will have too many artefacts and difference in picture quality between
pictures (we don't do double-pass so this is a bit empirical)

threads=4 is if you have a SMP machine

hq=rd,trellis are to get a much better quality. It takes a lot more CPU
though. They are disabled when in hurry up mode.

interlace,deinterlace : if you don't precise anything, ffmpeg will
encode the frames with the standard algorithms. If you add "interlace",
ffmpeg will special algorithms to enhance the quality of interlaced
pictures (takes more CPU though). "Deinterlace" will deinterlace the
frame first, then encode with the standard algorithms.

mpeg4matrix takes the MPEG-4 quantization matrices instead of the
MPEG-2. I have found that it gave fewer artefacts. It has no effect
on the compatibility of the stream, any standard MPEG-2 decoder can
still decode it.

strict_rc will use the ffmpeg rate control facilities for simple-pass
encoding. If you really want it to be strict you should pass
rc_buffer_aggressivity=10.0 or something, but it gives a lot of
artefacts, so I prefer to let the bitrate raise and transrate the
stream afterwards.

hurry_up mode enables you to activate the optimizations even when
sometimes you don't have enough CPU to do real-time. It will disable
first the B frames, then the trellis quantization, and finally the
rate distorsion. It also raises the noise_reduction parameter if
needed. It implies that to use hurry_up you must at least have
noise_reduction=1.

transrate{shaping=1500} is necessary because since keyint=36, setting
a lower value will lead to transrating on partial GOPs.

rtp{caching=1000} adds a 1 second delay to packets after transcoding.
That shouldn't be necessary here, but sometimes under heavy loads
the processing takes more time than expected.

rtp{group=5} sends five packets at once. This minimizes scheduling
issues.

ts{bmax=4500000} will produce a warning if the bitrate goes above
4.5 Mbi/s. Just a warning, nothing more.

pcr=80 will send a PCR every 80 ms (the spec says below 100 ms).

shaping=1500,use-key-frames will bufferize 1500 ms at most (normally
until the next I picture) and send the stream at constant bitrate
between two I pictures.

dts-delay=350 will put the DTS and PTS 350 ms in the future compared
to the PCR. This will give some bufferization inside the _decoder_.

pid-audio and pid-video assign fixed PIDs to the audio and video
streams. The PCR stream will always be on the video.

-- 
Christophe Massiot.

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>