ok, i give up. i've been trying for days to figure out how to reliably convert vdr recordings to divx to save space (approx 300-400MB/hour vs approx 2GB/hr) . the best i've managed is that *some* recordings can be converted, but some won't. i have no idea why some work and some don't - as far as i can tell, it seems to be random (but i know it can't be).
the other thing i can't figure out is how to get mencoder to process multiple input files - e.g. 001.vdr 002.vdr 003.vdr etc, for when the recording is >2GB. i didn't realise at first that mencoder ignored any input files past the first (i only found out when i noticed that a converted show finished halfway through...fortunately, i hadn't deleted the VDR recording yet). even if i try feeding it on stdin, it complains about "Cannot seek backward in linear streams!"
i guess i have to do it in two stages. first convert multiple files to a single file, and then convert that to divx. but how?
this is what i have so far:
---cut here--- #! /bin/bash
# vdr2dix.sh [dir] # # e.g. vdr2divx.sh /video/FooBar/2005-03-22.23.59.99.99.rec # will convert to divx & save as /video/DIVX/FooBar.2005.03.22.avi
OUTDIR=/video/DIVX
IN=$1 program=$(echo $IN | sed -e 's=/video/==' -e 's=/.*==') date=$(echo $IN | sed -e 's=.*([0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]).*=\1=')
OUT="$OUTDIR/$program.$date.avi"
echo $IN "===>" $OUT
ARGS="-oac mp3lame -ovc lavc"
echo mencoder $ARGS -o $OUT $IN/[0-9]*.vdr mencoder $ARGS -o $OUT $IN/[0-9]*.vdr ---cut here---
so, what's the secret? what do i have to do to convert vdr recordings to divx (or any other format)?
i've searched google dozens of times and seen various partial "solutions" posted to various places, but none of them seem to work either, or they've been abandoned, or they're ancient and don't work with current versions of software, and (worst of all) many of them seem to depend on some windows program or other to do part of the job. i don't want to run any windows crap, even with wine. i don't want to run java stuff either. and i don't want to run a GUI to do it - i want simple command line tools that i can use in a script.
so:
1. what *linux-native* tools do i need to do the job?
i have pretty nearly every video codec, library, player, and editing tool available for debian (sid) already installed. i can compile and install anything else i need, if only i knew what i needed.
2. what command-line options do i give to mencoder (and/or any other tools)?
3. if there's an English language FAQ or a HOWTO, please point me at it.
this must be a FAQ by now, but if anybody knows it doesn't look like they're telling (or if they are, it's in German which i can't read).
i've run out of clues.....any help would be appreciated.
craig
ps: i've looked at projectx. by messing about with the incredibly clumsy GUI for ages, i can get it to convert multiple 0*.vdr files into one stream file for conversion with mencoder. i can't get it to do the same thing from the command line, which makes it absolutely useless for scripting purposes. i don't like java apps anyway. they're way too fragile. they have a tendency to break without warning just because you upgrade some unrelated library, and i really dislike having to "fix" the same thing over and over again every month or two.
On Wednesday 23 March 2005 06:34, Craig Sanders wrote:
ok, i give up. i've been trying for days to figure out how to reliably convert vdr recordings to divx to save space (approx 300-400MB/hour vs approx 2GB/hr) . the best i've managed is that *some* recordings can be converted, but some won't. i have no idea why some work and some don't - as far as i can tell, it seems to be random (but i know it can't be).
1) configure mplayer with --enable-largefiles 2) don't ever cut the recordings with vdr 3) run the recording through vdrsync.pl -mpeg2 4) optionally use avidemux to cut (hint: the way to not get any artifacts at cut points is to cut so that the last frame in a segment will be a p frame and the first in the next segment an i frame) out anything you don't want in the final file, I suggest avidemux 2.0.36. .38 seems a bit messed up 5) run the resulting one big mpeg2 file through mencoder
Sometimes there's a sound sync problem but so far every time for me it has been constant, never drifting so it's easy to fix with avidemux or avisync.
thanks, that points me in the right direction at least.
On Wed, Mar 23, 2005 at 07:14:58AM +0200, Jukka Tastula wrote:
- configure mplayer with --enable-largefiles
ok.
- don't ever cut the recordings with vdr
ok.
- run the recording through vdrsync.pl -mpeg2
would love to do that, if it worked.
with vdrsync-snap050222.tgz & vdrsync-0.1.3PRE1.tgz, i got the following error (same on both):
# vdrsync.pl /video/Star_Trek__Enterprise/2005-03-22.23.59.99.99.rec/ -mpeg2 Parameter validation not complete yet Initialising and analysing the streams.... 3009 Mbytes of 3009 read 1547289 PES packets processed Assuming final sync for stream c0, cause there is no new chunk_start Modfied Target to /var/lib/video//vdrsync%d.mpg
Starting multiplexer Error while running 'nice -n 19 /usr/bin/mplex -V -f 3 -r 9800 -o /var/lib/video//vdrsync%d.mpg /var/lib/video//vdrsync.mpv /var/lib/video//vdrsync.ac3 /var/lib/video//vdrsync0.mpa > /dev/null 2> /dev/null ' Housekeeping... Trying to remove /tmp/268871111556671/
Finished processing /video/Star_Trek__Enterprise/2005-03-22.23.59.99.99.rec/ No need to finish DVD Image, since there is none Last fork ended for vdrsync.pl 26887
with vdrsync-0.1.2.2.tgz, i got this:
# vdrsync.pl /video/Star_Trek__Enterprise/2005-03-22.23.59.99.99.rec/ -mpeg2 -o /video/TMP/ Got parameter /video/Star_Trek__Enterprise/2005-03-22.23.59.99.99.rec/ got a directory on the command line trying to open /video/Star_Trek__Enterprise/2005-03-22.23.59.99.99.rec/ Got parameter -mpeg2 Got parameter -o Initialising and analysing the streams.... 10 Mbytes of 0 read Created new MPEG stream object for stream ea, master video stream
Created new MPEG stream object for stream bd
Created new MPEG stream object for stream c0 analysed the first 2000 packets... Total Input Size is 3009230447 30 Mbytes of 3009 readTimedrift bigger than 10 Seconds, killing stream bd got the kill list bd Stream bd was killed due to an error 2090 Mbytes of 3009 read/video/Star_Trek__Enterprise/2005-03-22.23.59.99.99.rec//002.vdr is the next file 3000 Mbytes of 3009 read all Input files processed EOF reached 3009 Mbytes of 3009 read 1547289 PES packets processed 154833 frames written for stream c0 (3715.992 sec) 92900 frames written for stream ea (3716 sec) Ignoring stream bd
audio stream c0 info (MPEG1_Layer_2): Sample frequency: 48000 Bitrate: 256000 Mode: joint_stereo Frame length (bytes) 768 Frame length (ticks) 2160 (90000 / sec)
video stream ea info: Frame length (ticks) 3600 (90000 / sec) Aspect ratio 16:9 Horizontal size 720 Vertical size 576 Frames per Second 25 Bitrate: 10000000
/video/TMP//eampv_c0mpa_remux.mpg as outputname executeing nice -19 /usr/bin/tcmplex -i /video/TMP//ea.mpv -p /video/TMP//c0.mpa -m 2 -o /video/TMP//eampv_c0mpa_remux.mpg
INFO: using reference profile (MPEG2) INFO: profile type is (PAL)
ERROR: File /video/TMP//ea.mpv is not a 11172-2 or 13818-2 Video stream.
Deleting temp files /video/TMP//ea.mpv /video/TMP//c0.mpa
analysing the file with '-i' shows that it has an ac3 stream, mp2 stream, and a video stream.
# vdrsync.pl -i /video/Star_Trek__Enterprise/2005-03-22.23.59.99.99.rec/ Got parameter -i Got parameter /video/Star_Trek__Enterprise/2005-03-22.23.59.99.99.rec/ got a directory on the command line trying to open /video/Star_Trek__Enterprise/2005-03-22.23.59.99.99.rec/ Initialising and analysing the streams.... 10 Mbytes of 0 read Created new MPEG stream object for stream ea, master video stream
Created new MPEG stream object for stream bd
Created new MPEG stream object for stream c0 analysed the first 2000 packets... Total Input Size is 3009230447
audio stream bd info (AC3_audio): Sample frequency: 48000 Bitrate: 192000 Mode: 2/0 Frame length (bytes) 768 Frame length (ticks) 2880 (90000 / sec)
audio stream c0 info (MPEG1_Layer_2): Sample frequency: 48000 Bitrate: 256000 Mode: joint_stereo Frame length (bytes) 768 Frame length (ticks) 2160 (90000 / sec)
video stream ea info: Frame length (ticks) 3600 (90000 / sec) Aspect ratio 16:9 Horizontal size 720 Vertical size 576 Frames per Second 25 Bitrate: 10000000
- optionally use avidemux to cut (hint: the way to not get any artifacts
at cut points is to cut so that the last frame in a segment will be a p frame and the first in the next segment an i frame) out anything you don't want in the final file,
so avidemux will work on the output of vdrsync.pl? good. useful to know that. it doesn't like vdr's "00n.vdr" files at all.
I suggest avidemux 2.0.36. .38 seems a bit messed up
i have 2.0.38+rc1-0.0 installed. i can wait for it to be fixed, for now i just want to be able to convert the entire file to divx. i can worry about fancy stuff like stripping ads later (most of the stuff i watch is on the non-commercial channels anyway, so no ads. about the only thing i watch on commercial TV is a few science fiction shows).
- run the resulting one big mpeg2 file through mencoder
ok, that makes sense. now to find a version of vdrsync.pl where -mpeg2 works.
craig
On Wednesday 23 March 2005 08:19, Craig Sanders wrote:
analysing the file with '-i' shows that it has an ac3 stream, mp2 stream, and a video stream.
That's probably it then. You should try the latest snapshot (050322); the bugs page claims there's a fix for a problem with AC3 and vdr >1.3.19 (and 1.3.23).
On Wed, Mar 23, 2005 at 11:31:17AM +0200, Jukka Tastula wrote:
On Wednesday 23 March 2005 08:19, Craig Sanders wrote:
analysing the file with '-i' shows that it has an ac3 stream, mp2 stream, and a video stream.
That's probably it then. You should try the latest snapshot (050322); the bugs page claims there's a fix for a problem with AC3 and vdr >1.3.19 (and 1.3.23).
thanks. that does the trick.
if anyone else is interested, my converter script now looks like this:
---cut here--- #! /bin/bash
# vdr2dix.sh [dir] # # e.g. vdr2divx.sh /video/FooBar/2005-03-22.23.59.99.99.rec # will convert to divx & save as /video/DIVX/FooBar.2005.03.22.avi
# user-tweakable constants OUTDIR='/video/DIVX' TMPDIR='/video/tmp' ARGS='-oac mp3lame -ovc lavc'
# arg processing IN="$1" show=$(echo "$IN" | sed -e 's=/video/==' -e 's=/.*==') date=$(echo "$IN" | sed -e 's=.*([0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]).*=\1=') OUT="$OUTDIR/$show.$date.avi" #echo $IN "===>" $OUT
[ -e $TMPDIR/vdrsync1.mpg ] && rm -f $TMPDIR/vdrsync1.mpg
#echo vdrsync.pl $IN -mpeg2 -o $TMPDIR/ #echo mencoder $ARGS -o $OUT $TMPDIR/vdrsync1.mpg
vdrsync.pl $IN -mpeg2 -o $TMPDIR/ mencoder $ARGS -o $OUT $TMPDIR/vdrsync1.mpg
rm -f $TMPDIR/vdrsync1.mpg ---cut here---
it probably needs some tweaking of the mencoder arguments for optimum quality/size, but it works as is.
craig
On Wednesday 23 March 2005 21:53, Craig Sanders wrote: <snip>
OUT="$OUTDIR/$show.$date.avi"
<snip>
mencoder $ARGS -o $OUT $TMPDIR/vdrsync1.mpg
rm -f $TMPDIR/vdrsync1.mpg ---cut here---
it probably needs some tweaking of the mencoder arguments for optimum quality/size, but it works as is.
Food for thought:
What if mencoder failed because of a recording that is somehow damaged because of for example signal loss?
Happy hollydays, Kenneth
Hello,
it's probably not a great idea to do the conversion in only one pass if you want to keep a good quality...
You could for example have a look at :
http://magma.epfl.ch/greg/scripts/MENCODER
BUT, I have learn something about sed with your script, thank you for it !!!
On Wed, Mar 23, 2005 at 09:57:14PM +0100, Kenneth Aafl?y wrote:
On Wednesday 23 March 2005 21:53, Craig Sanders wrote:
<snip> > rm -f $TMPDIR/vdrsync1.mpg > ---cut here---
Food for thought:
What if mencoder failed because of a recording that is somehow damaged because of for example signal loss?
the script only deletes the temporary file created by vdrsync.pl, leaving the original .vdr recording intact to be inspected, repaired, or deleted manually.
craig
On Wed, Mar 23, 2005 at 10:17:18PM +0100, Gr?goire Favre wrote:
it's probably not a great idea to do the conversion in only one pass if you want to keep a good quality...
yep, that's my next step...to make it do a good quality two-pass transcoding.
even with the default settings as in the script, the quality is reasonable. artifacts are only really noticable in graphics and lettering on signs etc.
You could for example have a look at :
thanks.
modifying my script to use the same two-pass technique, results in:
note: untested, but if the original (yours?) works, this should work the same.
---cut here--- #! /bin/bash
# vdr2dix.sh [dir] # # e.g. vdr2divx.sh /video/FooBar/2005-03-22.23.59.99.99.rec # will convert to divx & save as /video/DIVX/FooBar.2005.03.22.avi
# user-tweakable constants OUTDIR='/video/DIVX' TMPDIR='/video/tmp'
VBR=1000
# i don't use scaling, so don't have useful values for $C and $S # uncomment and provide good values if you want to scale. #C="" #S="" #SCALE="-vf crop=$C,scale=$S -sws 2"
AUDIO="-oac copy" VIDEO="-ovc lavc -lavcopts vcodec=mpeg4:vbitrate=$VBR:trell:mv0:mbd=2:v4mv:qprd:cmp=10:subcmp=10:mbcmp=10:predia=2:dia=2"
PASS1="$SCALE $AUDIO $VIDEO:vpass=1:turbo" PASS2="$SCALE $AUDIO $VIDEO:vpass=2:turbo"
# arg processing IN="$1" show=$(echo "$IN" | sed -e 's=/video/==' -e 's=/.*==') date=$(echo "$IN" | sed -e 's=.*([0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]).*=\1=') OUT="$OUTDIR/$show.$date.avi" #echo $IN "===>" $OUT
cd $TMPDIR
for f in vdrsync1.mpg frameno.avi divx2pass.log ; do [ -e $f ] && rm -f $f done
vdrsync.pl $IN -mpeg2 -o $TMPDIR/
mencoder -ovc frameno -o frameno.avi -oac mp3lame -lameopts cbr:br=96 $TMPDIR/vdrsync1.mpg mencoder $PASS1 -o /dev/null $TMPDIR/vdrsync1.mpg mencoder $PASS2 -o $OUT $TMPDIR/vdrsync1.mpg
rm -f frameno.avi divx2pass.log vdrsync1.mpg ---cut here---
(does "br=96" in lameopts give reasonable sound quality?)
next on the TODO list: - make one-pass or two-pass selectable from command line, e.g. "-1" or "-2" (probably default to 2 pass) - allow overide of output filename (default to filename derived by sed)
usage would then be:
vdr2divx.sh [-1|-2] [-o filename] <dir>
BUT, I have learn something about sed with your script, thank you for it !!!
sed's a useful tool...but a bit "clumsier" to use than perl. i tend to use sh + sed + awk etc for small, simple scripts and for wrapper scripts that mostly call other programs to do the work, and perl for anything more complex.
craig
Craig Sanders wrote:
On Wed, Mar 23, 2005 at 10:17:18PM +0100, Gr?goire Favre wrote:
it's probably not a great idea to do the conversion in only one pass if you want to keep a good quality...
yep, that's my next step...to make it do a good quality two-pass transcoding.
even with the default settings as in the script, the quality is reasonable. artifacts are only really noticable in graphics and lettering on signs etc.
Has anyone considered using vlc? I use this to create asf files, but vlc can use any video/audio codec and mux you choose (including mpg, avi, ogg, etc.).
#!/bin/sh
FILE=$1
if [ "$FILE" = "" ]; then echo -e "You must specify a file name!\n" exit 0 fi
cat 00*.vdr|pes2ts2 0 0|ts2ps 0 0|vlc -vvv --color /dev/stdin -I telnet --aspect-ratio 4:3 --sout '#transcode{vcodec=DIV3,vb=756,acodec=mp3,ab=192,channels=2,deinterlace}:std{access=file,mux=asf,url=/video/'$FILE'.asf}'
echo -e "Your ASF is ready ($FILE)\n"
On Thu, Mar 24, 2005 at 10:03:56AM +1100, Craig Sanders wrote:
yep, that's my next step...to make it do a good quality two-pass transcoding.
Any reason not to do three-pass ? Even with your actual version you do three-pass :-)
even with the default settings as in the script, the quality is reasonable. artifacts are only really noticable in graphics and lettering on signs etc.
And with respect to size ? Depending on the source, I can achieve a really good quality for about 10% of the original size (best, or worst case I admit, mostly from my camera, not from VDR).
# i don't use scaling, so don't have useful values for $C and $S # uncomment and provide good values if you want to scale.
I don't think you could really automate the cropping and scalling parts, as for example -vf cropdetect is not perfectly usable (sender's logo, etc...) and then one has to scale to really have a perfect quality, I personaly use a value near 0.2 given by the calcbpp.pl from mplayer.
(does "br=96" in lameopts give reasonable sound quality?)
At least for me it's enough...
sed's a useful tool...but a bit "clumsier" to use than perl. i tend to use sh + sed + awk etc for small, simple scripts and for wrapper scripts that mostly call other programs to do the work, and perl for anything more complex.
I also use bash/sed/awk most of the time :-)
Good enhancement to your script !
On Thu, Mar 24, 2005 at 12:20:47AM +0100, Gr?goire Favre wrote:
On Thu, Mar 24, 2005 at 10:03:56AM +1100, Craig Sanders wrote:
yep, that's my next step...to make it do a good quality two-pass transcoding.
Any reason not to do three-pass ? Even with your actual version you do three-pass :-)
yeah, i noticed that.
even with the default settings as in the script, the quality is reasonable. artifacts are only really noticable in graphics and lettering on signs etc.
And with respect to size ?
about 400-450MB per hour, which is a lot better than ~3GB/hour.
that's for the one-pass version. haven't actually tried the two (three :) pass version yet.
craig
On Thu, Mar 24, 2005 at 12:14:12PM +1100, Craig Sanders wrote:
even with the default settings as in the script, the quality is reasonable. artifacts are only really noticable in graphics and lettering on signs etc.
And with respect to size ?
about 400-450MB per hour, which is a lot better than ~3GB/hour.
that's for the one-pass version. haven't actually tried the two (three :) pass version yet.
i tried the three-pass version yesterday afternoon. for a one-hour recording, with transcoding done on my amd64 3200:
one-pass took 37 minutes and resulted in a file 381MB in size. (transcoding at approx 50fps)
three-pass took 206 minutes and resulted in a file 707MB in size. (transcoding at approx 227fps for pass1, 50fps for pass 2, and only 8fps for pass 3)
quality was excellent on both versions. the one-pass seemed very slightly fuzzy in comparison to the three-pass, but it was only noticable if you were looking for it....and even then, i'm not 100% sure that i didn't just imagine it because i was expecting it to be worse.
and that was in full-screen mode on my 21" monitor less than a foot from my eyes. when i set up my dedicated VDR machine connected to my TV about 10 feet from my eyes, it probably wont be noticable at all.
i don't think i'll bother with 2/3 passes any more.
craig
Craig Sanders wrote: ...
one-pass took 37 minutes and resulted in a file 381MB in size. (transcoding at approx 50fps)
three-pass took 206 minutes and resulted in a file 707MB in size. (transcoding at approx 227fps for pass1, 50fps for pass 2, and only 8fps for pass 3)
quality was excellent on both versions. the one-pass seemed very slightly fuzzy in comparison to the three-pass, but it was only noticable if you were looking for it....and even then, i'm not 100% sure that i didn't just imagine it because i was expecting it to be worse.
I thought that the whole point of mutipass divx encoding is to achieve a better quality at the same bitrate. Am I wrong here? Are you sure you specified the same bitrate for both experiments?
And, just for benchmark purposes, have you tried a low bitrate for both one-pass and three-pass, so you can see the differences easier?
Carsten.
On Fri, Mar 25, 2005 at 12:44:45AM +0100, Carsten Koch wrote:
I thought that the whole point of mutipass divx encoding is to achieve a better quality at the same bitrate. Am I wrong here? Are you sure you specified the same bitrate for both experiments?
And, just for benchmark purposes, have you tried a low bitrate for both one-pass and three-pass, so you can see the differences easier?
i'm not interested enough to find out.
if 3-pass can't get noticably better results even with a significantly higher bit-rate (i tried it with VBR=1800) then it's not worth the time to experiment with the same br. at least, it's not worth my time.
one-pass is good enough for me. quality is excellent, and size is good.
craig
On Fri, Mar 25, 2005 at 11:01:04AM +1100, Craig Sanders wrote:
i'm not interested enough to find out.
if 3-pass can't get noticably better results even with a significantly higher bit-rate (i tried it with VBR=1800) then it's not worth the time to experiment with the same br. at least, it's not worth my time.
one-pass is good enough for me. quality is excellent, and size is good.
One pass has also the advantage that you can pipe everything, vdrsync.pl also has a pipe mode :-)
-
C.Y.M -
Carsten Koch -
Craig Sanders -
Grégoire Favre -
Jukka Tastula -
Kenneth Aafløy