hermann pitton wrote:
Hi,
this is good news.
Updated cvs from the server and the patch cleanly applied. V4l2 was
autodetected on my 2.4.20-v4l2. Don't have the issues frbiscani has with
the cvs-snapshot on the mplayer-users list. (Is his kernel v4l2
patched?)
This issue has been resolved, there were some missing ifdef's (try
--disable-tv-v4l and see)
(I compiled with the Live.Com libs and had an issue with faad2 1.2 beta
cvs-20030721. Configure doesn't get the version from libfaad.so.0, the
symlink to libfaad.so.0.0.0. So gcc-3.2.2 RH-9 bails out on ad_faad.c in
libmpcodecs.
Renamed the so.0.0.0 to so.0 to get around.)
Don't know, this shouldn't be related to v4l at all.
Have to update myself, what is going on with deinterlacing and how to
set and find my chan-list again and then to look at your saa7134-tvaudio
patch and as you say, the minor controls are not ready yet, but that's
all for now.
They actually work for me, but they have different ranges (0..100
instead of 0..65535 in v4l).
Tried to make some stress with:
"mencoder -v -tv
driver=v4l2:width=720:height=576:input=0:adevice=/dev/dsp1:audioid=1
tv:// -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=1800:keyint=250 -oac
mp3lame -lameopts cbr:mode=0:br=128 -o mencoder-v4l2-test.avi"
After 40 minutes and 60000 frames I lost two (on startup or close) and
a/v is completly in sync on my old amd 1GHz athlon-tbird on a A7V133
with 384 MB slow SDRAMM and/but saa7134-20030724.
Some lost frames at startup are allright, as mplayer compensates for the
excess audio samples at startup.
That is really fine and tough :)
Glad you enjoy it as I do :)
--
Jindrich Makovicka
