Post-processing: Difference between revisions

From LinuxTVWiki
Jump to navigation Jump to search
(created page)
 
No edit summary
Line 1: Line 1:
'''Post-processing''' is what you do with your films after you recorded them, if you don't want to watch them and delete them after. For example, you might want to
'''Post-processing''' is what you do with your films after you recorded them to make the files robuster, handier or smaller. Normally one wouldn't go through the trouble if it's just for a quick watch and delete, but files should be post-processeed if you want to archive them.

Common post-processing steps are
* remove errors (e.g. due to weak signal) from the stream: see '''[[cleaning]]'''
* remove errors (e.g. due to weak signal) from the stream: see '''[[cleaning]]'''
* [[cut]] out the adverts, the beginning and the end of the transmission
* bring the film to a different format, e.g. the more effective XviD (or DivX) to save hard-disk space.
* bring the film to a different format, e.g. the more effecient [[MPEEG4]] (XviD or DivX) to save hard-disk space or bring more films onto a DVD.


The latter step is called '''[[re-encoding]]''' (=recoding), if you change the codec (i.e. from MPEG-2 to e.g. XviD). It is called '''requantisation''', if you only change the parameters of the stream (i.e. reduce the MPEG-2 [[PS]] bitrate, which is most likely not a good idea as the bitrate of the transmitted signal is much less than the one of DVDs and visible artifacts already do occur at the common bitrate of 2000kbit/s MPEG-2).
The last step is called '''[[re-encoding]]''' (=recoding), if you change the codec (i.e. from MPEG-2 to e.g. XviD). It is called '''requantisation''', if you only change the parameters of the stream (i.e. reduce the MPEG-2 [[PS]] bitrate, which is most likely not a good idea as the bitrate of the transmitted signal is much less than the one of DVDs and visible artifacts already do occur at the common bitrate of 2000kbit/s MPEG-2).


As a note on image quality: all the common codecs are lossy, i.e. the quality of the encoded video/audio signal you recieve is not as good as the original one. If you re-encode, you can only create more losses/artifacts. Therefore, in order to minimize any additional loss, I use generous XviD bitrates of e.g. 900 kbit/s, which still use less diskspace than the original MPEG-2 file.
A note on image quality: all the common codecs are lossy, i.e. the quality of the encoded video/audio signal you recieve is not as good as the original one. If you re-encode, you can only create more losses/artifacts. Therefore, in order to minimize any additional loss, I use generous XviD bitrates of e.g. 1200 kbit/s, which still use less diskspace than the original MPEG-2 file.

A note on MPEG2 files recorded from DVB: transmission errors are unavoidable... While your player (e.g. [[gxine]]) can deal with it, any post-processing has enormous problems with it - either your re-coding program will crash, or, even worse, it might seem okay but then (after hours of encoding, maybe after wasting a DVD to burn it to) for some films some really annoying [[de-synchronisation]] might occur. This is why '''error correction before re-coding is very important'''.




Line 11: Line 16:
Properly working solutions can be shared here:
Properly working solutions can be shared here:


===Example 1: vdrsync, lame, ffmpeg ===
===Example 1: ProjectX, mplex, avidemux ===
This works with the files as saved with [[VDR]]. I use VDRadmin-am to manage and schedule my DVB recordings. Then I reduce the filesizes for the recordings that I want to archive. So requirement: one or a few output files
This works with the files as saved with [[VDR]]. I use VDRadmin-am to manage and schedule my DVB recordings. Then I reduce the filesizes for the recordings that I want to archive - so 4 films fit on a single layer DVD (4.4 GB). So requirement: one or a few output files of VDR like
001.vdr 002.vdr 003.vdr
in your VDR video directory, e.g. in
/videos/Simpsons/2006-05-06.05.29.90.99.rec/

First I use [[ProjectX]] for error correction.
java -jar /where/ever/you/compiled/projectx/ProjectX.jar -



mplex -f 8 -o mux_smalltc.mpeg2 smalltimecrooks.m2v smalltimecrooks.mp2

At the end I use [[avidemux]] to cut out (by hand) the unnecessary parts at the beginninng and end of film, and the adverts. The GUI is really nice - it takes about 5 minutes to cut out 4 blocks of ads in a 2 hour film. I also use it to encode to MP3 (lame) and MPEG4 (normal 16:9 film with bitrate 1300 kbit/s for action films, 1100 kbit/s for slower films), saving as AVI.
avidemux


===Example 2: vdrsync, lame, ffmpeg ===
This works with the files as saved with [[VDR]]. So requirement: one or a few output files
001.vdr
001.vdr
in your VDR video directory, e.g. in
in your VDR video directory, e.g. in
Line 36: Line 58:
== See also ==
== See also ==
* [[cleaning]]
* [[cleaning]]
* [[cut out ads]]
* [[re-encoding]]
* [[re-encoding]]

Revision as of 17:39, 24 September 2006

Post-processing is what you do with your films after you recorded them to make the files robuster, handier or smaller. Normally one wouldn't go through the trouble if it's just for a quick watch and delete, but files should be post-processeed if you want to archive them.

Common post-processing steps are

  • remove errors (e.g. due to weak signal) from the stream: see cleaning
  • cut out the adverts, the beginning and the end of the transmission
  • bring the film to a different format, e.g. the more effecient MPEEG4 (XviD or DivX) to save hard-disk space or bring more films onto a DVD.

The last step is called re-encoding (=recoding), if you change the codec (i.e. from MPEG-2 to e.g. XviD). It is called requantisation, if you only change the parameters of the stream (i.e. reduce the MPEG-2 PS bitrate, which is most likely not a good idea as the bitrate of the transmitted signal is much less than the one of DVDs and visible artifacts already do occur at the common bitrate of 2000kbit/s MPEG-2).

A note on image quality: all the common codecs are lossy, i.e. the quality of the encoded video/audio signal you recieve is not as good as the original one. If you re-encode, you can only create more losses/artifacts. Therefore, in order to minimize any additional loss, I use generous XviD bitrates of e.g. 1200 kbit/s, which still use less diskspace than the original MPEG-2 file.

A note on MPEG2 files recorded from DVB: transmission errors are unavoidable... While your player (e.g. gxine) can deal with it, any post-processing has enormous problems with it - either your re-coding program will crash, or, even worse, it might seem okay but then (after hours of encoding, maybe after wasting a DVD to burn it to) for some films some really annoying de-synchronisation might occur. This is why error correction before re-coding is very important.


Examples

Properly working solutions can be shared here:

Example 1: ProjectX, mplex, avidemux

This works with the files as saved with VDR. I use VDRadmin-am to manage and schedule my DVB recordings. Then I reduce the filesizes for the recordings that I want to archive - so 4 films fit on a single layer DVD (4.4 GB). So requirement: one or a few output files of VDR like 

001.vdr 002.vdr 003.vdr

in your VDR video directory, e.g. in 

/videos/Simpsons/2006-05-06.05.29.90.99.rec/

First I use ProjectX for error correction. 

java -jar /where/ever/you/compiled/projectx/ProjectX.jar -



mplex -f 8 -o mux_smalltc.mpeg2 smalltimecrooks.m2v smalltimecrooks.mp2

At the end I use avidemux to cut out (by hand) the unnecessary parts at the beginninng and end of film, and the adverts. The GUI is really nice - it takes about 5 minutes to cut out 4 blocks of ads in a 2 hour film. I also use it to encode to MP3 (lame) and MPEG4 (normal 16:9 film with bitrate 1300 kbit/s for action films, 1100 kbit/s for slower films), saving as AVI. 

avidemux


Example 2: vdrsync, lame, ffmpeg

This works with the files as saved with VDR. So requirement: one or a few output files 

 001.vdr

in your VDR video directory, e.g. in 

 /videos/Simpsons/2006-05-06.05.29.90.99.rec/

First we divide the PS into its components: 

 vdrsync 001.vdr 002.vdr 003.vdr 004.vdr (and however many .vdr you have)

This will create two output files, one for video and one for audio. It won't take long, as it just copies raw data. Then we re-encode the MP2 audio stream into a good quality MP3: 

 lame --mp2input -q 5 -h --vbr-new c0.mpa audio.mp3

Finally, we re-encode the video and just copy the temporary MP3 audio file in there in the same step: 

 ffmpeg -deinterlace -i e0.mpv -i audio.mp3  -f avi  -vcodec mpeg4 -b 900 -g 300 -bf 2  -acodec copy  ~/film.avi

(Note that options for a file are left of it, here the -deinterlace for the file e0.mpv.)

This makes a 1.0GB AVI out of a 2.1GB MPEG2 PS, the quality is pretty good. However, I noticed that sometimes the synchronisation of audio-video is slightly off. I can't stand that as I personally look at people's mouths speaking... You can try 

 ffmpeg -itsoffset 00:00:00.200 -deinterlace -i e0.mpv -i audio.mp3  -f avi  -vcodec mpeg4 -b 900 -g 300 -bf 2  -acodec copy  ~/film.avi

which would make the video 200 msec later than the audio. But this won't work if the non-synchronisation varies over the film.


Example 2:

Your go: share your insights with us...


See also

Retrieved from "https://www.linuxtv.org/wiki/index.php?title=Post-processing&oldid=7946"