Forum: Offtopic H.265 Stream von Kamera aufnehmen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Robert S. (efyzz)


Bewertung
-1 lesenswert
nicht lesenswert
Moin,

ich habe bereits eine 1080p H.264 Überwachungskamera, deren Stream ich 
mit meinem NAS per FFMPEG aufnehmen kann. Das kostet etwa 14% CPU-Last 
und ich erhalte eine MP4-Datei. Ich gehe davon aus, dass hierbei nichts 
umcodiert werden muss, was die schwache CPU schont. Es wird nur alle 
3600s geschnitten und Keyframes neu generiert, soweit ich das verstehe.
ffmpeg -i rtsp://<ip>:554/11 -vcodec copy -r 50 -f segment -segment_time 3600 -segment_format mp4 -reset_timestamps 1 -strftime 1 "<Pfad>/%Y-%m-%d_%H-%M_test.mp4"

Nun möchte ich mir eine weitere Kamera anschaffen. Aktuelle Modelle 
unterstützen meist (nur noch?) den H.265 Codec. Kann man den Stream hier 
genauso aufnehmen, ohne die CPU zu strapazieren? Welches Dateiformat 
müsste man als Output angeben?

Danke euch!

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
-1 lesenswert
nicht lesenswert
Über welche Auflösung reden wir bei H.265? Bei hohen Auflösung könnte 
auch der Speicher zum Problem werden bzw. der Datendurchsatz.

H.264 wurde über die letzten Jahren durch die Ideen aus H.265 ein ganzes 
Stück weiterentwickelt, so daß der Abstand zwischen beiden Codecs nicht 
mehr so groß ist wie ursprünglich angestrebt. Sicher, daß Du H.265 
wirklich brauchst?

von Robert S. (efyzz)


Bewertung
-1 lesenswert
nicht lesenswert
Ich brauche das nicht, aber die Kameras, die für mich in Frage kommen, 
haben alle schon H.265.

Eigentlich sollten es 5MP werden. Beim Durchsatz und Speicherbedarf sehe 
ich eigentlich keine Probleme. Das dürften doch trotzdem höchstens 
10MB/min werden?! Aber wenn das beispielsweise größere 
Kompatibilitätsprobleme bei der Aufnahme machen sollte, würde ich 
notgedrungen wohl nur 2MP nehmen.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
-1 lesenswert
nicht lesenswert
Das meine ich nicht, sondern die Rohdaten im Speicher beim Codieren von 
4K Aufnahmen, ggf. noch mit vielen FPS.

von Georg A. (georga)


Bewertung
-1 lesenswert
nicht lesenswert
Robert S. schrieb:
> Kann man den Stream hier genauso aufnehmen, ohne die CPU zu
> strapazieren?

Ja. h.264/h.265 sind äusserlich sehr ähnlich.

> Welches Dateiformat müsste man als Output angeben?

.mp4 ;) MP4 ist kein Codec, sondern ein Container-Format. Das kann h.264 
als auch h.265 (und MPEG1/2-Video) enthalten.

von Robert S. (efyzz)


Bewertung
-1 lesenswert
nicht lesenswert
OK, also wird vermutlich einfach derselbe ffmpeg Befehl funktionieren.

Ben B. schrieb:
> Das meine ich nicht, sondern die Rohdaten im Speicher beim Codieren von
> 4K Aufnahmen, ggf. noch mit vielen FPS.

Achso, also höhere Belastung von NAS-CPU und -RAM. Mmh ... Kann man grob 
schätzen, wie schlimm das sein könnte, auf Basis der jetzigen 14% 
CPU-Last bei 2MP / 1080p?

Ich kann mir leider nicht so richtig vorstellen, was ffmpeg da 
eigentlich macht. Also eigentlich ja nur den Stream in einen Container 
verpacken. Sprich Metadaten wie Zeitstempel usw. drumherum basteln. 
Richtig?

Aber sowohl ffmpeg, als auch später das abspielende Gerät, müssen dann 
den H.265 Codec unterstützen, richtig? MP4 ist also nicht gleich MP4 ...

von Georg A. (georga)


Bewertung
-1 lesenswert
nicht lesenswert
Robert S. schrieb:
> Ich kann mir leider nicht so richtig vorstellen, was ffmpeg da
> eigentlich macht. Also eigentlich ja nur den Stream in einen Container
> verpacken. Sprich Metadaten wie Zeitstempel usw. drumherum basteln.
> Richtig?

Naja, warum ffmpeg was macht, weiss eh keiner so ganz genau ;) Aber im 
Endeffekt wird es hier nur der Verbindungsaufbau und das 
Umverpacken/Multiplexen der einzelnen Elementardatenströme sein. RTSP 
liefert ja erstmal nur eine Initial-Beschreibung via SDP, wo es die 
Datenströme gibt und was sie sind. Das sind dann üblicherweise 2 
UDP-Streams (RTP-Header, Video + Audio, jeweils ES-Format), meistens 
nochmal 2 UDP-Streams mehr (RTCP, im wesentlichen Timestamps für A+V). 
Das muss man alles in einen einzigen Datenstrom mit Headern 
(Sync-Pattern, Atoms, Timestamps, etc.) zusammenfummeln.

> Aber sowohl ffmpeg, als auch später das abspielende Gerät, müssen dann
> den H.265 Codec unterstützen, richtig? MP4 ist also nicht gleich MP4 ...

Richtig, das ist ja das tolle an Containern, dass man erst beim 
Reingucken weiss, was wirklich drin ist...

von Robert S. (efyzz)


Bewertung
-1 lesenswert
nicht lesenswert
Alles klar! Naja, nicht wirklich ... Aber Du hast mir sehr geholfen!

Hatte übrigens gestern das Glück, mal eine H.265 Kamera zu testen. Und 
tatsächlich: es funktioniert mit demselben ffmpeg-Befehl. Nur der 
Windows Media Player kann diese Datei dann nicht mehr (ohne weiteres) 
abspielen. Damit wäre bewiesen, dass in der mp4-Datei plötzlich etwas 
anderes drin steckt :D

von Tim T. (tim_taylor) Benutzerseite


Bewertung
-1 lesenswert
nicht lesenswert
Robert S. schrieb:
> Alles klar! Naja, nicht wirklich ... Aber Du hast mir sehr geholfen!
>
> Hatte übrigens gestern das Glück, mal eine H.265 Kamera zu testen. Und
> tatsächlich: es funktioniert mit demselben ffmpeg-Befehl. Nur der
> Windows Media Player kann diese Datei dann nicht mehr (ohne weiteres)
> abspielen. Damit wäre bewiesen, dass in der mp4-Datei plötzlich etwas
> anderes drin steckt :D

Wobei man auch dem h.265 beibringen kann, mit entsprechenden Codecs. 
Besser natürlich man verwendet direkt was Brauchbares wie z.B. den 
SMPlayer (https://www.smplayer.info/de/downloads).

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.