Re: Tcrequant breakthrough!

Otto J. Makela wrote:
> 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
> 
It still seems to work well for me in the circumstances I have 
described, but there is lots of code in eg read-cell that seems to be 
aimed at reading strange dvd-specific packets.

It does seem, however, that the output file plays for a few seconds less 
than the input file.  I suspect that the final 4Mb output buffer is not 
being written.

This thread *is* still relevant to this list because vamps does 
(sometimes!!) a job similar to the suspect, and deprecated, tcrequant.

I'm sure content providers must use something like this to tailor their 
transmissions to fit their channel bandwidth: or is it all done in hardware?

John P