Post-processing: Difference between revisions
(created page) |
m (Added category: Software) |
||
(3 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
'''Post-processing''' is what you do with your films after you recorded them, |
'''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 |
* bring the film to a different format, e.g. the more efficient [[MPEG4]] (XviD or DivX) to save hard-disk space or bring more films onto a DVD. |
||
The |
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'''. |
|||
Line 11: | Line 16: | ||
Properly working solutions can be shared here: |
Properly working solutions can be shared here: |
||
===Example 1: |
===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/vdr/The_Long_Good_Friday/2006-09-12.20.59.90.99.rec |
|||
First I use [[ProjectX]] for error correction. |
|||
me@comp:/videos/vdr/The_Long_Good_Friday/2006-09-12.20.59.90.99.rec$ java -jar /usr/bin/px/ProjectX.jar -demux 001.vdr 002.vdr 003.vdr -out /home/me/videos2convert/ -name longgoodfriday |
|||
This will create a video and an audio file (error-free) in the folder specified |
|||
/home/me/videos2convert/longgoodfriday.m2v |
|||
/home/me/videos2convert/longgoodfriday.mp2 |
|||
as well as some text file that shows you how many errors you had in the original stream. |
|||
Now I use [[mplex]] to combine them again (mux them): |
|||
mplex -f 8 -o longgoodfriday_muxed.mpeg2 longgoodfriday.m2v longgoodfriday.mp2 |
|||
At the end I open the file |
|||
longgoodfriday_muxed.mpeg2 |
|||
in [[avidemux]] which I use 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 === |
|||
''Note: this works only in theory - as soon as normal transmission errors occur, vdrsync aborts... '' |
|||
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 30: | Line 59: | ||
===Example |
===Example 3: === |
||
''Your go: share your insights with us...'' |
''Your go: share your insights with us...'' |
||
Line 36: | Line 65: | ||
== See also == |
== See also == |
||
* [[cleaning]] |
* [[cleaning]] |
||
* [[cut out ads]] |
|||
* [[re-encoding]] |
* [[re-encoding]] |
||
[[Category:Software]] |
Latest revision as of 00:31, 3 May 2009
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 efficient MPEG4 (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/vdr/The_Long_Good_Friday/2006-09-12.20.59.90.99.rec
First I use ProjectX for error correction.
me@comp:/videos/vdr/The_Long_Good_Friday/2006-09-12.20.59.90.99.rec$ java -jar /usr/bin/px/ProjectX.jar -demux 001.vdr 002.vdr 003.vdr -out /home/me/videos2convert/ -name longgoodfriday
This will create a video and an audio file (error-free) in the folder specified
/home/me/videos2convert/longgoodfriday.m2v /home/me/videos2convert/longgoodfriday.mp2
as well as some text file that shows you how many errors you had in the original stream.
Now I use mplex to combine them again (mux them):
mplex -f 8 -o longgoodfriday_muxed.mpeg2 longgoodfriday.m2v longgoodfriday.mp2
At the end I open the file
longgoodfriday_muxed.mpeg2
in avidemux which I use 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
Note: this works only in theory - as soon as normal transmission errors occur, vdrsync aborts...
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 3:
Your go: share your insights with us...