Am Sonntag, 13. Januar 2008 10:26:03 schrieb Francesco Romani: > Please provide the full command line used, possibily in the various > stages tried, in order to better understand the transcode (wrong) > behaviour.
Alright, this the way I first tried it and which, ideally, would be only one run: transcode -y xvid -w 1600 -J yuy2toyv12,dilyuvmmx,text=range=60-$frames:string="somestring":font=/usr/share/fonts/truetype/FreeSans.ttf:points=12:dpi=120:fade=1:antialias=1:posdef=3,logo=file=/path/to/logo.png:posdef=2:rgbswap -x raw -i "$input" -o "$output" After finding out what went wrong here (and after using mencoder to convert to YV12), I simply took out the yuy2toyv12 filter and tried again. Seeing that the logo will not be rendered (and after experimenting with the logo itself), I split it in at first two steps: transcode -y im,lame -F png -J dilyuvmmx,text=range=60-$frames:string="somestring":font=/usr/share/fonts/truetype/FreeSans.ttf:points=12:dpi=120:fade=1:antialias=1:posdef=3 -x raw -i "$input" -o "$output" And yes, I know that jpg would probably have been a lot faster, but uncompressed jpg naturally tend to grow quite large, and I'm pushing enough data around as is. After compositing all frames, I went on with: transcode -y raw,null --export_fps 0,5 --use_rgb -z -k -g 680x480 -x imlist,null -i "$wd"/list -o "$wd"/tempfile.avi (I actually experimented with the audio, but it was all basically the same as above and didn't change anything regarding the video) After finding out that -k produced nonsense, I left that out and fed the video to mencoder (after merging the audio with avimerge). >From then on, it's a simple encoding, with the options provided by xvid4.cfg: transcode -y xvid -w 1600 -x raw -i "$wd"/tempfile.avi -o "$wd"/"$t_output".avi That's about it. > Are these streams in DV format? Or maybe uncompressed YUY2 frames packed > in AVI or anything else? No, they are not DV. As you guessed, uncompressed YUY2 in AVI. These are produced by DScaler when capturing from a tv-card. > Uhm, I should really improve detectclipping filter and its documentation > as well :) Probably, at least I was somewhat confused and then let it be ;) > filter_logo was seriously improved during 1.1.0 cycle, maybe you could > give a try using transcode 1.1.0-alpha6. > Those anomalies are supposed to be fixed as well in 1.1.0 I will certainly give it a try later on. > That's hard maybe seamples will be needed to fix that, and this raise > various problems, first and most important being copyright issues that I > absolutely want to avoid. Yes, this is quite obvious. Though most of these are captures from video games, which are usually openly distributed on the net. Well, still probably a somewhat grey zone. > No, this is definitively not acceptable. Let's see how this can be > improved. Let me know if you need more information. I will try 1.1.0 later this day. Hope to report better news by then ;) Regards, Toni
