[psp3004]

Abend,

da ich mich nun schon seit ca. 7 Jahren mit HTML/CSS/PHP/Javascript usw. beschäftige und schon das ein oder andere kleine bis mittelgroße Projekt, auch wenn es meisten nur Privat war, verwirklicht habe, möchte ich nun mein erstes größeres Projekt anfangen. (Welches ruhig ein wenig Zeit in Anspruch nehmen kann/muss).

Und zwar soll es um eine Streamingseite in Richtung Youtube/Twitch gehen.
Vorrangig soll der User einen eigenen Livestream über eine Webcam bzw. alternativ auch über die Kamera eines Smartphones starten können.
Diesen sollen x-beliebige User auch Live ansehen können.

Nun da ich leider keine Ahnung in Sachen Streaming habe (außer natürlich ein einfachen Video welches auf dem Server liegt direkt einzubinden), muss ich auf euch zurück greifen!
Was brauche ich für mein Vorhaben?

Server/Encoder usw.
Wie lasse ich einen User den Stream starten
Wie binde ich den Stream entsprechend ein, wenn ein User diesen sehen möchte


Und dies alles, wenn es geht, erst einmal Opensource

Hoffe ihr könnt mir helfen bei meinen Vorhaben
(Falls dies nicht das Richtige Unterforum ist bitte ich einen Admin, dies ins richtige zu verschieben)

Gruß

[Gispelmob]

Streaming bedeutet erstens viele Bits die gleichzeitig bewegt werden wollen. Dass heisst die Verbindung muss eine hohe Bandbreite haben.

Zweites bedeutet encoden Rechenpower. Der Server braucht also CPU Power und viel RAM. Im Idealfall kann man jedem User einen Teil CPU Power und RAM dynamisch zuordnen. Außerdem ist der richtige Codec ein wichtiger Teil. Die Frage ist also ob man das encoden weglassen kann und nur den Streamingpart nimmt.

Drittens darfst du davon ausgehen das Bandbreite beim Netzwerk und CPU Power beim Server beliebigt nach oben skaliert werden dürfen, je mehr Nutzer den Dienst gleichzeitig nutzen.

Viertens solltes du dir auch über die Rechte und den Datenschutz im klaren sein, wenn die Videos auf dem Server gespeichert bzw. zwischen gespeichert werden und du mit persönlichen Daten der User in Kontakt kommst.

Was die Seite angeht, benötigst du eine Benutzerverwaltung. Außerdem muss die Seite eine mobile und eine Browseransicht haben, die beide gleich gut bedient werden wollen. Außerdem sollte die Seite nicht nur im IE oeder Edge nutzbar sein, sondern in allen gängigen Browsern gleichermaßen funktionieren. Das wären also neben IE und Edge noch FF, Chrome, Opera und Safari und die mobilen Varianten davon wenn du Handys unterstützen willst.

Desweiteren ist die Verschlüsselung mittels SSL nicht zu vergessen. Lets Encrypt sollte für den Anfang reichen. Zum entwickeln reichen aber auch erstmal selbstsignierte Zertifikate.

Schwieriger wird es bei der Anbindung der Hardware. Webcams oder Handycams kann man mit HTML/CSS/PHP/Javascript nicht steuern, da diese Sprachen nicht auf die Systemebene und die Treiber zugreifen können. Da müsste ein anderes Backend her, aber für eine Möglichkeit eines Videouploads reicht es.

Eventuell kann man ja noch was mit HTML5 machen, aber damit habe ich mich noch nicht beschäftigt. Da müsste dann ein anderer weitermachen.

Dieser Beitrag wurde von Gispelmob bearbeitet: 19. Juni 2017 - 22:24

[RalphS]

Ich seh da schon ein bissel ein Problem im Ansatz. "Live" bedeutet Echtzeit und da kommen ja schon die Upstream-Raten der jeweiligen "Aufzeichner" ins Spiel.

Also muß der Keks erst auf einen Server, und sei es nur, um das puffern zu können. Dann ist es aber nicht mehr live.


Und dann sind wir bei den erwähnten Datenmengen, die - bei ausreichend gutem Besuch -- schnell ins Exorbitante gehen. Da muß also der ISP mitspielen. In jedem Fall wird das erwartungsgemäß teuer.


Potentielle Ausnahme: es gibt eine von YT/Twitch bereitgestellte API, die genutzt werden kann. Dann müßte man eine App für die gängigen mobilen Betriebsumgebungen ausrollen, damit die "Clients" das ohne Umwege ans Ziel (YT / Twitch) streamen können. Bandbreite ist bei denen vorhanden; dafür sind sie ja schließlich da. "Live" hängt aber natürlich immer noch von den verfügbaren Bandbreiten am jeweiligen Endgerät ab.


Von einer eigenen, per Internet bereitgestellten Lösung würde ich solange absehen, wie es keinen Geldgeber gibt.

[Gispelmob]

Er will aber nicht YT/Switch per API nutzen, sondern etwas eigenes aufbauen.

Ich seh da nur den Weg über ein Browserplugin oder eine eigene Software die den Stream aufzeichnet und auf den Server lädt. Wenn es in Echtzeit sein soll, steigen die Anforderungen an Client, Server und vorallem an die Netzwerkanbindung.

Im Grunde genommen kann man nur die Webseite per HTML/CSS/JS (Client) und PHP/SQL (Server) aufbauen. Die Anwendung/App um Streams aufzunehmen muss man dann in z.B. C++ oder ähnlichem schreiben. Insgesamt ist diese Idee ein Projekt für mehrere Personen.

[RalphS]

Das hab ich schon kapiert, aber alles andere wird unter anderem aus den von Dir genannten Gründen einfach teuer. Daher auch der Hinweis auf den Geldgeber.

Evtl, wenn nicht schon geschehen und das ganze hier untergegangen ist, mal hinsetzen und über den geplanten Einsatzzweck nachdenken.

Denn, angenommen das funktioniert so wie beschrieben: Was soll dann damit gemacht werden? Als Stream wäre das ja unidirektional; als Videochat würde es nichts taugen trotz Echtzeit. Andererseits hat man als "Sender" eben wegen der Live-Eigenschaft keinerlei Korrekturmöglichkeiten; wenn einem die Katze vor laufender Kamera ins Gesicht gekackt hat, dann ist das übertragen und fertig.


Oder anders gesagt, möglicherweise ist das gesetzte Ziel mit (sehr) viel weniger Anforderungen umsetzbar.

[psp3004]

Danke euch erstmal.

Zitat (Gispelmob: 20. Juni 2017 - 06:33)

Ich seh da nur den Weg über ein Browserplugin oder eine eigene Software die den Stream aufzeichnet und auf den Server lädt. Wenn es in Echtzeit sein soll, steigen die Anforderungen an Client, Server und vorallem an die Netzwerkanbindung.

Im Grunde genommen kann man nur die Webseite per HTML/CSS/JS (Client) und PHP/SQL (Server) aufbauen.
Die Anwendung/App um Streams aufzunehmen muss man dann in z.B. C++ oder ähnlichem schreiben. Insgesamt ist diese Idee ein Projekt für mehrere Personen.

Hatte schon über NodeJS und WebRTC nach gedacht da kann man mittels multiPeerconnection eine Verbindung zu mehren Nutzern aufbauen, aber maximal nur 10 Nutzer glaub ich

Zitat (RalphS: 20. Juni 2017 - 09:28)

Evtl, wenn nicht schon geschehen und das ganze hier untergegangen ist, mal hinsetzen und über den geplanten Einsatzzweck nachdenken.

In erster Linie hat bzw. soll das keinen, zu mindesten im Moment, großen Einsatzzweck haben.
Möchte einfach mein Kenntnisse erweitern.

[Ludacris]

Zitat (Gispelmob: 19. Juni 2017 - 22:12)

Schwieriger wird es bei der Anbindung der Hardware. Webcams oder Handycams kann man mit HTML/CSS/PHP/Javascript nicht steuern, da diese Sprachen nicht auf die Systemebene und die Treiber zugreifen können. Da müsste ein anderes Backend her, aber für eine Möglichkeit eines Videouploads reicht es.

Eventuell kann man ja noch was mit HTML5 machen, aber damit habe ich mich noch nicht beschäftigt. Da müsste dann ein anderer weitermachen.

Stimmt so nicht. Du kannst mit HTML5 und JS komplett auf die gesamte Hardware zugreifen.

https://danielsteine...amer/index.html
Hier mal ein Beispiel zum Kamera & Mirofonzugriff.

[Gispelmob]

Gispelmob sagte:

Eventuell kann man ja noch was mit HTML5 machen, aber damit habe ich mich noch nicht beschäftigt.

Zitat (Ludacris: 02. August 2017 - 12:51)

Stimmt so nicht. Du kannst mit HTML5 und JS komplett auf die gesamte Hardware zugreifen.

Merkste selber ne?

Außerdem ist "gesamte Hardware" leider falsch. Nur auf die Hardware die auch vom Browser supported wird und deine Links auf leere Seiten sind jetzt auch nicht so überzeugend.

Dieser Beitrag wurde von Gispelmob bearbeitet: 02. August 2017 - 14:06

[RalphS]

Quellcode?

Aber, SSL hostname mismatch. Und Let's Encrypt. Zugriff bleibt da wohl aus Sicherheitsgründen besser blockiert.

[Holger_N]

Vielleicht sollte man das viel einfacher angehen. Man stelle sich vor jemand formuliert als Ziel:

»Hallo, ich möchte eine Seite komplett selbst programmieren, die vom Funktionsumfang her in etwa der Youtube-Plattform entspricht.«

Um da Aufwand und Machbarkeit auszudiskutieren, muß man doch eigentlich gar nicht so weit ins technische Detail, wie das hier schon der Fall ist.

[Wiesel]

Bevor du über technische Details sprichst solltest du dir über die rechtlichen Konsequenzen im Klaren sein. Die Hürden sind so hoch, dass du dir über die Technik meiner Meinung nach keine Gedanken machen musst.

Du schreibst, du möchtest eine x-beliebige Anzahl von Usern auf den Stream Zugriff gewähren. Wenn nur einer der Streamer im Hintergrund Radio an hat, bist du am Arsch, weil die GEMA anklopft. Ich bewzeifele, dass du so einen langen Atem und die finanziellen Möglichkeiten hast, die Google im Jahrelangen Rechtsstreit mit der Gema hatte.

[Ludacris]

Zitat (Gispelmob: 02. August 2017 - 14:04)

Merkste selber ne?

Außerdem ist "gesamte Hardware" leider falsch. Nur auf die Hardware die auch vom Browser supported wird und deine Links auf leere Seiten sind jetzt auch nicht so überzeugend.

Jo eh - mit HTML5 geht recht viel - Kamera & Mikro, GPS ist schon mal absolut kein problem.
Machs mitm Handy auf

Zitat (RalphS: 02. August 2017 - 14:41)

Quellcode?

Spoiler

<!DOCTYPE html>
<html lang="en">

<head>
    <title></title>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
</head>

<body>
    <video autoplay></video>

    <script>
        var errorCallback = function (e) {
            console.log('Reeeejected!', e);
        };

        // Not showing vendor prefixes.
        navigator.getUserMedia({
            video: true,
            audio: true
        }, function (localMediaStream) {
            var video = document.querySelector('video');
            video.src = window.URL.createObjectURL(localMediaStream);

            // Note: onloadedmetadata doesn't fire in Chrome when using it with getUserMedia.
            // See crbug.com/110938.
            video.onloadedmetadata = function (e) {
                // Ready to go. Do some stuff.
            };
        }, errorCallback);

        navigator.getUserMedia = navigator.getUserMedia ||
            navigator.webkitGetUserMedia ||
            navigator.mozGetUserMedia ||
            navigator.msGetUserMedia;

        var video = document.querySelector('video');

        if (navigator.getUserMedia) {
            navigator.getUserMedia({
                audio: true,
                video: true
            }, function (stream) {
                video.src = window.URL.createObjectURL(stream);
            }, errorCallback);
        } else {
            video.src = 'somevideo.webm'; // fallback.
        }

        var hdConstraints = {
            video: {
                mandatory: {
                    minWidth: 1280,
                    minHeight: 720
                }
            }
        };

        navigator.getUserMedia(hdConstraints, successCallback, errorCallback);



        var vgaConstraints = {
            video: {
                mandatory: {
                    maxWidth: 640,
                    maxHeight: 360
                }
            }
        };

        navigator.getUserMedia(vgaConstraints, successCallback, errorCallback);

        MediaStreamTrack.getSources(function (sourceInfos) {
            var audioSource = null;
            var videoSource = null;

            for (var i = 0; i != sourceInfos.length; ++i) {
                var sourceInfo = sourceInfos[i];
                if (sourceInfo.kind === 'audio') {
                    console.log(sourceInfo.id, sourceInfo.label || 'microphone');

                    audioSource = sourceInfo.id;
                } else if (sourceInfo.kind === 'video') {
                    console.log(sourceInfo.id, sourceInfo.label || 'camera');

                    videoSource = sourceInfo.id;
                } else {
                    console.log('Some other kind of source: ', sourceInfo);
                }
            }

            sourceSelected(audioSource, videoSource);
        });

        function sourceSelected(audioSource, videoSource) {
            var constraints = {
                audio: {
                    optional: [{
                        sourceId: audioSource
                    }]
                },
                video: {
                    optional: [{
                        sourceId: videoSource
                    }]
                }
            };

            navigator.getUserMedia(constraints, successCallback, errorCallback);
        }

        function fallback(e) {
            video.src = 'fallbackvideo.webm';
        }

        function success(stream) {
            video.src = window.URL.createObjectURL(stream);
        }

        if (!navigator.getUserMedia) {
            fallback();
        } else {
            navigator.getUserMedia({
                video: true
            }, success, fallback);
        }

        function hasGetUserMedia() {
            return !!(navigator.getUserMedia || navigator.webkitGetUserMedia ||
                navigator.mozGetUserMedia || navigator.msGetUserMedia);
        }

        if (hasGetUserMedia()) {
            // Good to go!
        } else {
            alert('getUserMedia() is not supported in your browser');
        }
    </script>
</body>
</html>

Anmerkung: Das kommt 1:1 ausm Internet.

Zitat (RalphS: 02. August 2017 - 14:41)

Aber, SSL hostname mismatch. Und Let's Encrypt. Zugriff bleibt da wohl aus Sicherheitsgründen besser blockiert.

Huch? SSL Hostname mismatch sollte eigentlich nicht sein Caddy ruft für jeden Host der nicht explizit ein Zertifikat hat eines bei Let's encrypt ab.

[Gispelmob]

Aha, von HTML5 sprechen und dann mit Javascript kommen.

[Holger_N]

Zitat (Gispelmob: 03. August 2017 - 13:50)

Aha, von HTML5 sprechen und dann mit Javascript kommen.

~kurz mal einmischen~ Er schrieb deutlich:

Zitat (Ludacris: 02. August 2017 - 12:51)

…Du kannst mit HTML5 und JS komplett auf die gesamte Hardware zugreifen.

[RalphS]

Ah, sorry, Ludacris. Mit meinem "Quellcode?"-Einwand hatte ich mich eigentlich darauf bezogen, daß das, was man sieht, nicht das ist, was man bekommt und daß eine "leere Seite" nur und ausschließlich so eine ist, wo - vereinfacht - zwischen <html> und </html> nix steht.

Daher der Hinweis auf den Quellcode - man möge da reinschauen.

War also nicht an Dich, sondern an Gispelmob adressiert. Den Quellcode hatte ich mir schon selber angeschaut.

Was das andere da angeht:

$ openssl s_client connect danielsteiner.net:443

CONNECTED(00000004)
---
Certificate chain
 0 s:/CN=pwtests.gq
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=pwtests.gq
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA384
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3058 bytes and written 434 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: ...
    Session-ID-ctx: 
    Master-Key: ...
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket:
    ...

    Start Time: 1501770468
    Timeout   : 300 (sec)
    Verify return code: 62 (Hostname mismatch)
---
$

danielsteiner.net != pwtests.pq .

Wenn Du DNS.1 = danielsteiner.net im SubjectAltName hinzufügst, paßt es.

Dieser Beitrag wurde von RalphS bearbeitet: 03. August 2017 - 15:36