Webcam - Transcode webcam images into live h264 stream example

[adelanteDev]

Hi, I have modified the above example for my needs. Now the structure of my project looks like this: Client1 sends the image to the server, the server saves it to disk and sends it to Client2. When I want my server to run more threads (I need several ports for different webcams).

My server :

`public class Server {

static List<Integer> ports = new ArrayList<Integer>();

public static void main(String[] args) {
    ports.add(20000);
    ports.add(20001);

    if (args.length == 0) {
        for (int i = 0; i < ports.size(); i++)
            initPorts("localhost", ports.get(i));
    } else {

    }
}

public static void init(String host, int port) {
    StreamServerAgent serverAgent = new StreamServerAgent();
    serverAgent.start(new InetSocketAddress(host, port));
}

public static void initPorts(final String host, final int port) {
    new Thread() {
        @Override
        public void run() {
            init(host, port);
        }
    }.run(); }

Error :

https://pastebin.com/w4QjzCkD

I suspect that the problem is that although the image from Client1 is transmitted on one port, when the client connects to port 20001. It still receives the image from the client on port 20,000.

[sarxos]

@adelanteDev Czy ten problem nadal występuje, czy udało się Tobie go ominąć? W razie co służę supportem, jednak z uwagi na mocno ograniczony czas zaznaczam, że moge nie być dostepny od ręki.

[adelanteDev]

Jestem dużo dalej jeśli chodzi o kod niż w momencie którym to pisałem. W tamtym momencie udało mi się usunąć ten błąd (przynajmniej tak myślałem). W tej chwili mój projekt wysyła z różnych komputerów obraz na jeden serwer, tam jest obraz też zapisywany do plików mp4. Natomiast różni klienci mogą podłączać się pod serwer i oglądać na żywo obraz z kamerek. Niestety okazało się, że błąd nadal występuje. Program się wysypuje po około dniu, dwóch działania. Dodatkowo zauważyłem że im większa liczba fpsów wysyłanych tym szybciej program się wysypuje. W argumencie wywołania oczywiście dałem -Xmx4096. Idąc za radami wyczytanymi w internecie skompilowałem ręcznie bibliotekę xuggler 5.5. Natomiast to również nie rozwiązało problemu.

Błąd z dziś :
https://pastebin.com/VG2wypTv

Byłbym wdzięczny za pomoc, bo to blokuje bardzo mój projekt.

[sarxos]

@adelanteDev,

Wygląda na to, że to nie Xuggler wywala Twoją apkę, tylko BridJ, kiedy przychodzi czas GC i finalizacji śmieci :( Trochę to niefajne, bo jest to jedna z fundamentalnych bibliotek, z których korzysta domyślny Capture Driver projektu Webcam Capture API.

Stack: [0x000000001d0b0000,0x000000001d1b0000],  sp=0x000000001d1aeed0,  free space=1019k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [ntdll.dll+0x4f23c]
C  [kernel32.dll+0x21a0a]
C  [bridj.dll+0xa750]
C  [bridj.dll+0x7288]
C  0x00000000023b7f74
 
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.bridj.JNI.free(J)V+0
j  org.bridj.Pointer$FreeReleaser.release(Lorg/bridj/Pointer;)V+192
j  org.bridj.Pointer$5.release(Lorg/bridj/Pointer;)V+14
j  org.bridj.Pointer$3.release()V+19
j  org.bridj.Pointer$3.finalize()V+1
J 2476% C2 java.lang.ref.Finalizer$FinalizerThread.run()V (55 bytes) @ 0x00000000029828a8 [0x00000000029825c0+0x2e8]
v  ~StubRoutines::call_stub

Rozwiązanie tego problemu lezy prawdopodobnie po stronie samej biblioteki BridJ, jednak Olivier (autor tej biblioteki) ostatnimi czasy nie ma za duzo czasu na jej rozwój, więc pozostają Tobie tak naprawdę dwie opcje:

1. Upgrade BridJ do najnowszej wersji z nadzieją, że to magicznie naprawi crashowanie się Twojej apki,
2. Wymianę Capture Driver'a na inny, który nie korzysta z BridJ.

Sprawdź 1, a jeśli to nie pomoże, to od razu idź w opcję 2. Samodzielne debugowanie i naprawianie BridJ jest hardcorowe, bo to naprawdę skomplikowany projekt i może zająć więcej czasu niż się wydaje.

Odnosnie opcji 2, skoro pracujesz na Windowsie, to szczególnie polecam webcam-capture-driver-native
autorstwa Franka Papenmeier'a z uwagi na fakt, że na najniższym poziomie wykorzystuje najnowsze API Microsoftu do obsługi video, tj. Media Foundation. Inne, starsze Capture Drivery kompatybilne z Windowsem korzystają z bibliotek, które używają starej technologii Direct3D.

Pamiętaj, że przy wymianie drivera powinieneś usunąć BridJ (wraz z jego zależnościami) z classpath aby nie robił już problemów. Jeśli korzystasz z Mavena, to nie powinien być problem - wystarczy dać exluda na dependency, ale jesli nie korzystasz z Mavena, to musisz je usunąc ręcznie i zweryfikowac czy coś nie zostało popsute.

[adelanteDev]

@sarxos

Wielkie dzięki za odpowiedź. Jeśli chodzi o punkt 1, to mam wersje 0.7.0 więc chyba najnowszą. Przeszedłem do punktu drugiego :

1.Ściągnąłem jar'a webcam-capture-driver-native.jar i dodałem go do projektu.
2.Pliki .dll wrzuciłem do katalogu bin Javy.
3. W programie ustawiłem drivery tak :

` public static class MyCompositeDriver extends WebcamCompositeDriver {

    public MyCompositeDriver() {
        add(new NativeWebcamDriver());
        add(new IpCamDriver());
    }
}

static {
    Webcam.setDriver(new MyCompositeDriver());
}`

Inicjuję kilka kamerek. Każda w odzdzielnym wątku. W ten sposób :

      Thread thread2 = new Thread() {
            public void run() {
                StreamingClient stream = new StreamingClient();
                stream.init("192.168.1.91", 2000, 0, 10);
            }
        };
        Thread thread3 = new Thread() {
            public void run() {
                StreamingClient stream = new StreamingClient();
                stream.init("192.168.1.91", 2001, 1, 10);
                }
        };
        Thread thread1 = new Thread() {
            public void run() {
                StreamingClient stream = new StreamingClient();
                stream.init("192.168.1.91", 2002, 2, 10);
                }
        };

Czasami występuje problem, że nie wszystkie kamerki się inicjują, mimo tego że lista kamerek zawsze wynosi 3. Ale to sporadycznie. Przetestuję i dam znać czy błąd dalej występuje.

[sarxos]

@adelanteDev,

Skoro otwieranie w osobnych wątkach nie działa, to spróbuj otworzyć kamerki w głównym wątku, a potem przekaż referencję zamiast tych indeksów do metody init(...).

Przykładowo:

Webcam w0 = Webcam.getWebcams().get(0);
Webcam w1 = Webcam.getWebcams().get(1);
Webcam w2 = Webcam.getWebcams().get(2);

w0.open();
w1.open();
w2.open();

Thread thread0 = new Thread(() -> new StreamingClient().init("192.168.1.91", 2000, w0, 10));
Thread thread1 = new Thread(() -> new StreamingClient().init("192.168.1.91", 2001, w1, 10));
Thread thread2 = new Thread(() -> new StreamingClient().init("192.168.1.91", 2002, w2, 10));

EDIT: Poprawilem kod.

[adelanteDev]

@sarxos

Dziwna sprawa, na moim komputerze wystarczyło to, że między wątkami dałem Thread.sleep(1000L).
Natomiast na innych przy użyciu mojego kodu, działała tylko pierwsza kamerka, a przy użyciu Twojego dostawałem wyjątek "Webcam has already been locked". Dziwna sprawa bo nic nie używało pozostałych kamerek. Użyłem webcam.getLock().disable(); i to rozwiązało problem z ilością działających kamerek. Jeśli chodzi o błąd z EXCEPTION_ACCESS_VIOLATION to dam znać jutro bądź pojutrze, bo zazwyczaj włąśnie tyle musiał chodzić klient wysyłający obraz aby ten wyjątek wyskoczył.

[sarxos]

@adelanteDev

Jeśli musisz robić webcam.getLock().disable() to upewnij się, że nie masz drugiego procesu w tle, który też korzysta z tych kamerek. To jest najczęściej powód błędu na lockach (webcam has already been locked). Często jest tak, że ktoś używa wątków niedemonicznych (każdy wątek jest domyślnie niedemoniczny), które nie kończą się przy tzw. gracefull shutdown (czyli śmierć wątka main) i można je ubić tylko poprzez zakończenie aplikacji za pomocą System.exit(). Takie wątki niedemoniczne cały czas utrzymują proces aktywny, a w tym procesie zablokowane kamerki. Można to łatwo zaobserwować jak zrobisz na Linuxie ps -ef | grep java a na Windowsie jak wejdziesz w manager procesów i tam będzie więcej procesów java niż powinno być. Innym powodem (potencjalnym) błędu na locku może być bardzo szybki restart procesu po jego wywaleniu się (po crashu). Generalnie ten problem wskazuje, że "coś" jest nie tak i lepiej w to spojrzeć, aby mieć pełną wiedzę na temat działanie aplikacji. Jeśli włączysz dokładne debug logi to tam powinno być trochę więcej informacji kiedy i co jest blokowane.

[adelanteDev]

@sarxos

Okay przetestowane, powyższy błąd już nie występuje. Dzięki za poświęcony czas. Będę wprowadzał jeszcze kilka funkcji do swojego projektu. Gdybym sobie z czymś nie radził, będę pytał w innych wątkach. Dzięki i powodzenia!

[sarxos]

@adelanteDev To super wiadomość :) Powodzenia z projektem!