H.265 Stream von Kamera aufnehmen

Ü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?

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.

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

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.

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 ...

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...

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