Forum Debian Users Gang

Na innym adresie IP to samo?
B na adres 0.0.0.0 może ffmpeg (klient) reagować dziwnie.

Poza tym ACL, chyba nie pozwoliłeś tam na żande adresy.
Spróbuj na serwerze otworzyć ACL allow localhost i klienta posłać na 127.0.0.1.

Ostatnio edytowany przez Jacekalex (2013-11-09 14:12:39)

@Jacekalex:

Zmianiłem plik konfiguracyjny na coś takiego:

Port 8080
BindAddress 0.0.0.0
NoDaemon
CustomLog -

<Feed feed1.ffm>
ACL allow localhost
</Feed>

<Stream test1.avi>
ACL allow localhost
Feed feed1.ffm
Format avi
</Stream>

<Stream status.html>
Format status

# Only allow local people to get the status
ACL allow localhost
# ACL allow 192.168.0.0 192.168.255.255
</Stream>

ale nic to nie dało - dodam tylko że jak na mój gust to chyba działało tak samo bez tego gdyż podczas próby podłączania klienta, serwer wypluwa komunikat:

Sat Nov  9 14:29:38 2013 127.0.0.1 - - [POST] "/feed1.ffm HTTP/1.1" 200 1460
Sat Nov  9 14:30:34 2013 127.0.0.1 - - [GET] "/test1.avi HTTP/1.0" 200 1452

a dokładniej ten pierwszy po wpisaniy wcześniejszej komendy ffmpeg -i plik -f avi http://127.0.0.1:8080/feed1.ffm, a drugi przy próbie podłączania klienta (dziwne tylko że dopiero kiedy klient zgłosi błąd że nie może odtworzyć pliku - pewnie czeka na jakąś zwrotkę z jego strony).

Poza tym reszta po staremu - jak nie działało tak nie działa :(

@ilin:

Chodzi o streming po necie, nie w sieci wewnętrznej - tak więc tvheadend odpada... however - jako że obecnie dumpuję stream programów mplayerem (mplayer dvb:// - dumpstream -dumpfile tutajNazwaJakiegośPipe'a.ts), to pytanko - czy za pomocą tvheadendu da się jakoś bez specjalnego softu dumpować strumienie TV (np. nie wiem... wget http://adresProgramu > pipe) ? Czy raczej trzeba by pisać klienta?

tvheadend można nagrywać do pliku.

Nie dało by sie podpiąc bezposrednio na adres streamu tvheadend ?

Update:

Kurde, już wiem czemu powyższe nie działało - wygląda na to że panowie od ffserver/avserver przyjeli założenie że wszystkie dane przekazujemy w konfigu strumienia, i to z niego ffmpeg je sobie pobierze, czyli po ustawieniu strumienia i załączeniu serwera wystarczy dać:

ffmpeg -i jakiśPlik.avi http://0.0.0.0:8080/feed1.ffm

a resztę parametrów ffmpeg pobierze z ustawień serwera. Niestety nikt nie pomyślał żeby w razie  niezgodności ustawień przekazywanych do strumienia dać jakikolwiek komunikat (nawet w trybie maksymalnego debugowania nie ma ŻADNEJ INFORMACJI)!!! Przez co nie wiadomo co się dzieje i czemu nie działa :/ chyba muszę do kogoś o to napisać w czasie późniejszym bo straciłem praktycznie dwa tygodnie na taką pierdołę :/

Wracając do sprawy - wygląda na to że kiedy wpiszę sobie do ustawień strumienia kodeki zgodnie z tym co wypluwa encoder na RaspberryPI to mogę w ten sposób zacząć streamowanie na zasadzie:

ffmpeg -i pipeDoKtóregoPiszeEncoderNaRaspberry.avi -vcodec copy -acodec copy http://0.0.0.0:8080/feed1.ffm

acodec copy i vcodec copy są potrzebne o ile nie chcemy aby ffmpeg na nowo kodowało stumień (a nie da się tych opcji dać w ustawieniach strumienia). Teraz DVB-T leci - niestety tak że nadal nic z tego nie wynika - w zależności od muxera, mam w najlepszym wypadku audio bez obrazu, a zwykle nawet tyle nie działa.

Najpewniej chodzi o to że omxtx (programik do kodowania za pomocą sprzętowego encodera h264 na RaspberryPi) nie wstawia globalnych nagłówków strumieni per pakiet tylko czeka do zakończenia enkodowania - tak jakby kodował skończony plik avi (na niektórych mux'ach widzę komunikaty w stylu:

Stream 0 does not use global headers but format require global headers
Stream 1 does not use global headers but format require global headers

omxtx z tego co widzę został napisany w oparciu o przykłady z avconv i jest tam włączona opcja do tworzenia globalnych nagłówków, ale chyba nie działa skoro otrzymuję taki komunikat... kurde tak blisko i tak daleko zarazem ;] na razie będę walczyć dalej, ale moje doświadczenie z ffmpeg jest bardzo niewielkie...