Differences

This shows you the differences between two versions of the page.

--- aes67 [2018/12/19 11:42] – created mazdermind
+++ aes67 [2018/12/31 14:09] (current) – [WorkdClock] mazdermind
@@ Line 43: / Line 43: @@
 ==== PTP ====
 Es gibt eine fertige PTP-Implementierung für GStreamer, diese muss nur korrekt initialisiert und die Pipeline damit konfiguriert werden. Das geht **nicht** mit `gst-launch-1.0` sondern nur mit einer Host-Applikation (z.B: in Python).
+Die GStreamer PTP-Clock konnte sich nicht mit dem Nexus syncen, daher haben wir den 35C3 mit der internen Free-Running Clock gefahren.
 Links:
@@ Line 48: / Line 50: @@
   * https://coaxion.net/blog/2015/05/ptp-network-clock-support-in-gstreamer/
+==== WorkdClock ====
+Da das Audio-Backup am Ende vor allem in Sync zum Video sein muss, wäre es vermutlich gut, es mit dem Video-Recording zu syncen.
+<code>
+:52 <       MaZderMind > https://coaxion.net/blog/2014/12/improved-gstreamer-support-for-blackmagic-decklink-cards/
+:54 <       MaZderMind > man könnte voctomix über den reference-in der duo2 karten mit einer worldclock versehen
+:54 <       MaZderMind > vmtl. würde das sogar automatisch passieren, wenn wir da mal was dran stecken würden
+:55 <       MaZderMind > The clock of the hardware is now exposed to the pipeline as a GstClock and even if the pipeline chooses a different clock, the elements will slave their internal clock to the
+                           master clock of the pipeline and make sure that synchronization is even kept if the pipeline clock and the Decklink hardware clock are drifting apart. Thanks to GStreamer’s
+                           extensive synchronization model and all the
+:55 <       MaZderMind > functionality that already exists in the GstClock class, this was much easier than it sounds.
+:56 <       MaZderMind > da die audio-backup-recorder auch eine decklink karte hatten würden die einfach die selbe clock bekommen und schon wäre alles schön in sync
+:56 <       MaZderMind > die decklink-karten können blackburst und trisync
+:57 <       MaZderMind > hhelenav Simpel ^
+:00 <       MaZderMind > jup, GstDecklinkClock ist verfügbar
+</code>
+===== AES67 Loudness-Meter =====
+Für das Loudness-Meter in der ACR benutzen wir eine Pipeline aus drei Komponenten:
+  * Eine GStreamer-Pipeline zum empfangen und dekodieren des AES67-Datenstroms, gibt ein wav aller Kanäle aus
+  * Ein ffmpeg41-Prozess, der das wav auf den `ebur128`-Filter wirft und dadurch die visuelle Anzeige der Loudness über die Zeit hinweg generiert, gibt raw-Video- und Audio in matroska verpackt aus
+  * Ein ffplay-Prozess, der das Video anzeigt
+Das sieht dann ungefähr so aus:
+<code>
+gst-launch-1.0 -q udpsrc multicast-iface=enp0s25.2342 address=239.192.42.42 port=5004 !\
+	application/x-rtp, clock-rate=48000, channels=2 !\
+	rtpL24depay !\
+	audioconvert !\
+	wavenc !\
+	fdsink |\
+		/opt/ffmpeg-4.1-64bit-static/ffmpeg -y -nostdin -i - -filter_complex '
+			[0] pan=2c|c0=c0|c1=c1, ebur128=video=1:target=-16:gauge=shortterm:scale=relative [v][a]
+		' -map '[v]' -map '[a]' \
+		-pix_fmt yuv420p -c:v rawvideo \
+		-c:a pcm_s16le -f matroska - |\
+			ffplay -v 0 -autoexit -exitonkeydown -exitonmousedown -window_title "ebur128 Loudness" -
+</code>
+Angepasst werden muss hier ebenfalls das Interface und die Multicast-Gruppe. Mit dem `pan`-Filter werden die beiden Kanäle aus den eingehenden 8 ausgewählt, die für die Loudness-Analyse verwendet werden. Um beispielsweise die Kanäle 4 und 5 (`0123_45_67`) benutzt werden, sieht der Filter so aus: `pan=2c|c0=c4|c1=c5`.