Re: [transcode-users] Tcrequant breakthrough!
Tomi Ollila wrote: On Thu 12 Feb 2009 19:17, John Pilkington j.p...@tesco.net writes: I just tried your posted example. I had no problems with: $ mplex -M -f 8 -o am-dvd.mpg am.m2v am.mp2 $ vamps -e 1.5 -a 1 -p -i xx am-dvd.mpg out.vob and out.vob played like any normal .mpg file. /* stuff deleted */ so maybe you should try different mplex options :-) What is the system you are running mplex/vamps (os and hardware platform ?) John P Tomi kernel-2.6.27.12-170.2.5.fc10.x86_64.rpm Vamps V0.99.2 from http://vamps.sourceforge.net/ mjpegtools mplex-2 version 1.9.0 (2.2.7) from http://dl.atrpms.net/f10-x86_64/atrpms/stable/mjpegtools-1.9.0-18.fc10.x86_64.rpm Hardware: Gateway GM5074b Intel Core 2 Duo John P
Re: [transcode-users] Tcrequant breakthrough!
For some reason vamps doesn't properly work for me, uses up lots of cpu cycles (and if running with -v -v produces output) but it just seems to stop producing output at some point and never actually completes... My guess is that it sees something in the input stream which causes a problem, as it always stops at the same byte count on a given file. % uname -a Linux tigger.otto.net 2.6.27.12-170.2.5.fc10.x86_64 #1 SMP Wed Jan 21 01:33:24 EST 2009 x86_64 x86_64 x86_64 GNU/Linux % tcprobe -i Time-2-dvd.mpg [tcprobe] MPEG program stream (PS) [tcprobe] summary for Time-2-dvd.mpg, (*) = not default, 0 = not detected import frame size: -g 720x576 [720x576] aspect ratio: 16:9 (*) frame rate: -f 25.000 [25.000] frc=3 PTS=0.1200, frame_time=40 ms, bitrate=7784 kbps audio track: -a 0 [0] -e 48000,16,2 [48000,16,2] -n 0x50 [0x2000] (*) PTS=0.1200, bitrate=224 kbps -D 0 --av_fine_ms 0 (frames ms) [0] [0] % date; time vamps -v -v -e 1.22 -a 1 -p -i xx Time-2-dvd.mpg Time-2-shrink-dvd.mpg Fri Feb 13 14:41:50 EET 2009 Info: Actual video ES vaporization factor: 1.221 Info: Actual video ES vaporization factor: 1.221 Info: Actual video ES vaporization factor: 1.219 ... Info: Actual video ES vaporization factor: 1.233 Info: Actual video ES vaporization factor: 1.203 Info: Actual video ES vaporization factor: 1.217 ^C vamps -v -v -e 1.22 -a 1 -p -i xx Time-2-dvd.mpg Time-2-shrink-dvd.mpg 236.15s user 3.69s system 92% cpu 4:18.14 total % date Fri Feb 13 14:46:10 EET 2009 % ls -lh Time-2-* -rw-rw-r-- 1 otto otto 1.5G 2007-07-27 14:43 Time-2-dvd.mpg -rw-rw-r-- 1 otto otto 20M 2009-02-13 14:42 Time-2-shrink-dvd.mpg -- /* * * Otto J. Makela o...@iki.fi * * * * * * * * * * * * * * * */ /* Phone: +358 40 765 5772, FAX: +358 42 7655772, ICBM: 60N 25E */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki, FINLAND */ /* * * Computers Rule 0100 01001011 * * * * * * * * * * * * */
Re: [transcode-users] Tcrequant breakthrough!
Otto J. Makela wrote: I just got confirmation from our friends at Metakine that their M2VRequantiser also produces garbage on my original test data, so the conclusion is that the equivalent of: tcdemux -i videofile-dvd.mpg -x mpeg2 sample.m2v will produce video content to sample.m2v which (though it will play with programs like xine) cannot be handled by tcrequant or mplex. What is your suggestion, what can be done to fix this? In view of this question about tcdemux it might be useful for me to clarify both my experience of successfully using tcrequant in the past and what I meant by .vob files when describing my experiments with vamps. I have been using MythArchive to create dvds from dvb-t recordings. All recordings have been stripped, in mencoder, of all except one audio channel before lossless mpeg2 transcoding with a cutlist by mythtranscode. Output is (probably) mpeg2 PS. MythArchive then uses mythreplex --demux --fix_sync -o outfiles_prefix -v 224 -a 192 infile the code for which is replex.c within the mythtranscode package; I don't know what its history is or how it may be related to tcdemux. tcrequant is called if needed to shrink the video file before mplex -M -f 8 and dvdauthor. I saw artefacts here in fc10, none in CentOS. Target shrinkage was rarely more than a few percent. The experiments I have done with vamps in fc10 have used the output of the mplex -M -f 8 stage with target shrinkage up to 2.0 - and no prior passage through tcrequant. I haven't seen artefacts although obviously the quality is reduced. These files are what I referred to as .vob files. vamps may report an error on reaching EOF, and the MythArchive code sometimes reports fatal buffer underflow in mplex, and exits, after creating an output file although I don't think it reacts similarly when using a FIFO. I think I can avoid this by mplex -M -f 8 -b 500 -r 15000 but have only tried this once. Code for use in the real world ought to be robust, but are there definitive examples of standard-compliant input for testing tcdemux? HTH, John P
Re: [transcode-users] Tcrequant breakthrough!
John Pilkington wrote: Otto J. Makela wrote: I just got confirmation from our friends at Metakine that their M2VRequantiser also produces garbage on my original test data, so the conclusion is that the equivalent of: tcdemux -i videofile-dvd.mpg -x mpeg2 sample.m2v will produce video content to sample.m2v which (though it will play with programs like xine) cannot be handled by tcrequant or mplex. What is your suggestion, what can be done to fix this? In view of this question about tcdemux it might be useful for me to clarify both my experience of successfully using tcrequant in the past and what I meant by .vob files when describing my experiments with vamps. I have been using MythArchive to create dvds from dvb-t recordings. All recordings have been stripped, in mencoder, of all except one audio channel before lossless mpeg2 transcoding with a cutlist by mythtranscode. Output is (probably) mpeg2 PS. MythArchive then uses mythreplex --demux --fix_sync -o outfiles_prefix -v 224 -a 192 infile the code for which is replex.c within the mythtranscode package; I don't know what its history is or how it may be related to tcdemux. tcrequant is called if needed to shrink the video file before mplex -M -f 8 and dvdauthor. I saw artefacts here in fc10, none in CentOS. Target shrinkage was rarely more than a few percent. The experiments I have done with vamps in fc10 have used the output of the mplex -M -f 8 stage with target shrinkage up to 2.0 - and no prior passage through tcrequant. I haven't seen artefacts although obviously the quality is reduced. These files are what I referred to as .vob files. vamps may report an error on reaching EOF, and the MythArchive code sometimes reports fatal buffer underflow in mplex, and exits, after creating an output file although I don't think it reacts similarly when using a FIFO. I think I can avoid this by mplex -M -f 8 -b 500 -r 15000 but have only tried this once. Code for use in the real world ought to be robust, but are there definitive examples of standard-compliant input for testing tcdemux? HTH, John P I just tried your posted example. I had no problems with: $ mplex -M -f 8 -o am-dvd.mpg am.m2v am.mp2 $ vamps -e 1.5 -a 1 -p -i xx am-dvd.mpg out.vob and out.vob played like any normal .mpg file. $ ls -l total 21828 -rw-rw-r-- 1 John John 9172992 2009-02-12 16:51 am-dvd.mpg -rw-rw-r-- 1 John John 8375981 2009-02-10 23:37 am.m2v -rw-rw-r-- 1 John John 561792 2009-02-10 23:37 am.mp2 -rw-rw-r-- 1 John John 4194304 2009-02-12 16:59 out.vob -rw-rw-r-- 1 John John 363 2009-02-11 00:08 requant-sample2.txt so maybe you should try different mplex options :-) John P
Re: [transcode-users] Tcrequant breakthrough!
I need to correct this. See below. I just tried your posted example. I had no problems with: $ mplex -M -f 8 -o am-dvd.mpg am.m2v am.mp2 $ vamps -e 1.5 -a 1 -p -i xx am-dvd.mpg out.vob and out.vob played like any normal .mpg file. $ ls -l total 21828 -rw-rw-r-- 1 John John 9172992 2009-02-12 16:51 am-dvd.mpg -rw-rw-r-- 1 John John 8375981 2009-02-10 23:37 am.m2v -rw-rw-r-- 1 John John 561792 2009-02-10 23:37 am.mp2 -rw-rw-r-- 1 John John 4194304 2009-02-12 16:59 out.vob -rw-rw-r-- 1 John John 363 2009-02-11 00:08 requant-sample2.txt so maybe you should try different mplex options :-) John P === In fact out.vob had a shorter playing time because vamps did not reach the eof. vamps: Fatal: Bad padding packet length at 9170958: 2024 Following are part-outputs from ffmpeg -i Input #0, mpeg, from 'am-dvd.mpg': Duration: 00:00:19.99, start: 0.12, bitrate: 3670 kb/s Stream #0.0[0x1e0]: Video: mpeg2video, yuv420p, 704x576 [PAR 12:11 DAR 4:3], 4578 kb/s, 25.00 tb(r) Stream #0.1[0x1c0]: Audio: mp2, 48000 Hz, stereo, s16, 224 kb/s Input #0, mpeg, from 'out.vob': Duration: 00:00:11.04, start: 0.12, bitrate: 3039 kb/s Stream #0.0[0x1e0]: Video: mpeg2video, yuv420p, 704x576 [PAR 12:11 DAR 4:3], 4578 kb/s, 25.00 tb(r) Stream #0.1[0x1c0]: Audio: mp2, 48000 Hz, stereo, s16, 224 kb/s ===
Re: [transcode-users] Tcrequant breakthrough!
John Pilkington wrote: I haven't investigated this idea, but might the problem here be a result of using tcrequant on an input stream rather than a file? I've tried both, it doesn't make a difference. I just used a pipeline to make things a bit more compact in this example case, it will do the same thing if you use an intermediate file. -- /* * * Otto J. Makela o...@iki.fi * * * * * * * * * * * * * * * */ /* Phone: +358 40 765 5772, FAX: +358 42 7655772, ICBM: 60N 25E */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki, FINLAND */ /* * * Computers Rule 0100 01001011 * * * * * * * * * * * * */
