tv z mplayera

[Shining Path]

Użytkownik WieslawKierbedz napisał:
> Użytkownik Shining Path napisał:
> 
>>>> - na v4l2 nie działa w ogóle, wypluwa taki błąd:
>>>>
>>>> v4l2: ioctl query capabilities failed: Zły argument
>>>> v4l2: 0 frames successfully processed, 0 frames dropped.
>>>> ============ Sorry, this file format is not recognized/supported 
>>>> =============
>>>> === If this file is an AVI, ASF or MPEG stream, please contact the 
>>>> author! ===
>>>> Cannot open demuxer.
>>>> - na v4l działa, acz tutaj także się pluje, bowiem:
>>>> Card reports an unknown audio mode !
>>>> Kernel patchowany łatkami z bytesex.org.
> 
> 
> Jeśli używasz v4l2, to lepiej chyba użyć bttv-0.9 zamiast 0.7 (kernele 
> 2.2 i niepatchowane 2.4).
> 0.9 pracuje na v4l2, 0.7 najwyżej używa v4l1-compat.

2.4.22 łatałem kraxelem, bttv pozostawiłem niezmienone, teraz rozumiem czemu
v4l2 nie działa w ogóle.
Kompiluje 2.6 z łatkami - wczoraj niestety potrzeba snu okazała się 
silniejsza.

>> mplayer własny - dystrybucyjny nie spełnił mych oczekiwań.
>> przerobiłem pldowego speca w/g własnego widzimisię, do przejrzenia tutaj
>> http://www.ghnet.pl/~halab/pliki/scripts/mplayer.spec
>> Zaznaczę jednak istotną rzecz - na dystrybucyjnym tez nie działa!
>>
>> Używam 2.4.22 - własna produkcja.
>> 2.6.0-test9 - mam także, ale bez jakichkolwiek łatek - skompilowałem 
>> sobie
>> dla testu  (jak nazwa wskazuje :).
>> Myślisz, że babor może być w kernelu 2.4.x? Na 2.4.20 pod Ra z mplayerem 
> 
> 2.4.20 - tu się zaczęły moje klopoty z v4l2 i trwały do 2.6 - próbowałem 
> potem z 2.4.21 (2.4.22 sobie darowałem:)) i było to samo

Na 2.4.20 używałem v4l, działało OK. O v4l2 nie było mowy, choćby z tej 
przyczyny, że
nie łatałem kernela pod tym kątem. Ten sam kernel kompilowany pod Ac - 
póki miałem
mplayera 0.90, było w porządku.

> - w videodev2.h było include <time.h> - wywoływało redeklarację 
> (kolidowało - time.h jest nawet w kernelu chyba 2 razy i jeszcze w glibc),
> potrzebne to jest do kompilacji samego videodev, od 2.4.22 jest już 
> warunek - tylko w przypadku kompilacji kernela (i modułów),
> aplikacje to omijają.
> 
> #ifdef __KERNEL__
> #include <linux/time.h> /* need struct timeval */
> #endif
> W 2.4.20 jest tylko środkowa linijka.
> Krótko - niektóre programy (w tym mplayer) w ogóle nie wykrywały (albo 
> "unusable") v4l, albo się wywalały w trakcie kompilacji.
> Teraz znowu jest ok. A przygodę z 2.4 skończyłem na 2.4.20 właśnie.
> A 2.6 już na desktopie na 2.4 bym nie zamienił.

Ja 2.6 ino tak na chwilkę i dla sprawdzenia jak to działa. A działa 
naprawdę nieźle. Wydaje mi
się czy jest rzeczywiście szybszy? Zakończyłem jednak z nim przygodę na 
rzecz 2.4.22 bo
nie umiałem zmusić lirca i sensors do działania. Szkoda, że wcześniej 
nie zajrzałem na
Twoją stronę (/dev/input/eventX  - żebym to ja wiedział wcześniej :)

Nadal mam jednak wątpliwości co do sensors - z tego co pamiętam burzył 
się o
brak i2c-proc, nadal go nie ma - jak to łyknąć?

> A patche nie są moje :(.
> A lirc-devinput nie jest konieczny z tymi łatami - devinput działa na 
> "czystym" 2.6.
> A łaty lirca dodają moduły do starego, dobrego gpio animaxa, i seriala - 
> wystarczą programy z distro - lirc-0.6.6.
> (Piszę, bo zauważyłem, żeś i to chwycił ;)).

Ano chwyciłem i to nie raz - dopiero za którymś razem udało mi się 
pobrać plik prawidłowo.
Nonstop miałem błędy w paczce i nic nie można było z nią zrobić.

Właśnie na czystym 2.6 nie było gpio co mnie bardzo zmartwiło.
A lirc-0.6.6 podczas kompilacji wywalał się. Widać za szybko się wtedy 
poddałem :/


> Ufff.

Ja se ufffne jak będzie to działać.
Strasznie długo się kompiluje to 2.6 :(


-- 
Robert Halabowski - http://www.ghnet.pl/~halab
Komputer bez Linuksa jest jak plaża bez słońca.
z /dev/dsp wydobywa się: Borysewicz_and_Kukiz_-_01_-_Bo_tutaj_jest_jak_jest