gstreamer/subprojects/gst-plugins-bad/ext/avtp/meson.build

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

46 lines
1.1 KiB
Meson
Raw Normal View History

avtp_sources = [
'gstavtp.c',
'gstavtpaafdepay.c',
avtp: Introduce AAF payloader element This patch introduces the AVTP Audio Format (AAF) payloader element from the AVTP plugin. The element inputs audio raw data and outputs AVTP packets (aka AVTPDUs), implementing a typical protocol payloader element from GStreamer. AAF is one of the available formats to transport audio data in an AVTP system. AAF is specified in IEEE 1722-2016 section 7 and provides two encapsulation mode: PCM and AES3. This patch implements PCM encapsulation mode only. The AAF payloader working mechanism consists of building the AAF header, prepending it to the GstBuffer received on the sink pad, and pushing the buffer downstream. Payloader parameters such as stream ID, maximum transit time, time uncertainty, and timestamping mode are passed via element properties. AAF doesn't support all possible sample format and sampling rate values so the sink pad caps template from the payloader is a subset of audio/x-raw. Additionally, this patch implements only "normal" timestamping mode from AAF. "Sparse" mode should be implemented in future. Upcoming patches will introduce other AVTP payloader elements that will have some common code. For that reason, this patch introduces the GstAvtpBasePayload abstract class that implements common payloader functionalities, and the GstAvtpAafPay class that extends the GstAvtpBasePayload class, implementing AAF-specific functionalities. The AAF payloader element is most likely to be used with the AVTP sink element (to be introduced by a later patch) but it could also be used with UDP sink element to implement AVTP over UDP as described in IEEE 1722-2016 Annex J. This element was inspired by RTP payloader elements.
2019-01-17 01:16:59 +00:00
'gstavtpaafpay.c',
'gstavtpcvfdepay.c',
'gstavtprvfdepay.c',
'gstavtpvfdepaybase.c',
'gstavtpcvfpay.c',
'gstavtprvfpay.c',
'gstavtpvfpaybase.c',
'gstavtpbasedepayload.c',
avtp: Introduce AAF payloader element This patch introduces the AVTP Audio Format (AAF) payloader element from the AVTP plugin. The element inputs audio raw data and outputs AVTP packets (aka AVTPDUs), implementing a typical protocol payloader element from GStreamer. AAF is one of the available formats to transport audio data in an AVTP system. AAF is specified in IEEE 1722-2016 section 7 and provides two encapsulation mode: PCM and AES3. This patch implements PCM encapsulation mode only. The AAF payloader working mechanism consists of building the AAF header, prepending it to the GstBuffer received on the sink pad, and pushing the buffer downstream. Payloader parameters such as stream ID, maximum transit time, time uncertainty, and timestamping mode are passed via element properties. AAF doesn't support all possible sample format and sampling rate values so the sink pad caps template from the payloader is a subset of audio/x-raw. Additionally, this patch implements only "normal" timestamping mode from AAF. "Sparse" mode should be implemented in future. Upcoming patches will introduce other AVTP payloader elements that will have some common code. For that reason, this patch introduces the GstAvtpBasePayload abstract class that implements common payloader functionalities, and the GstAvtpAafPay class that extends the GstAvtpBasePayload class, implementing AAF-specific functionalities. The AAF payloader element is most likely to be used with the AVTP sink element (to be introduced by a later patch) but it could also be used with UDP sink element to implement AVTP over UDP as described in IEEE 1722-2016 Annex J. This element was inspired by RTP payloader elements.
2019-01-17 01:16:59 +00:00
'gstavtpbasepayload.c',
'gstavtpsink.c',
'gstavtpsrc.c',
avtp: Introduce the CRF Sync Element This commit introduces the AVTP Clock Reference Format (CRF) Synchronizer element. This element implements the AVTP CRF Listener as described in IEEE 1722-2016 Section 10. CRF is useful in synchronizing events within different systems by distributing a common clock. This is useful in a scenario where there are multiple talkers who are sending data to a single listener which is processing that data. E.g. CCTV cameras on a network sending AVTP video streams to a base station to display on the same screen. It is assumed that all the systems are already time-synchronized with each other. So, the AVTP Talker essentially adjusts the AVTP Presentation Time so it's phase-locked with the reference clock provided by the CRF stream. There are 2 different roles of systems which participate in CRF data exchange. A system can either be a CRF Talker, which samples it's own clock and generates a stream of timestamps to transmit over the network, or a CRF Listener, the system which receives the generated timestamps and recovers the media clock from the timestamps. It then adjusts it's own clock to align with recovered media clock. The timestamps generated by the talker may not be continuous and the listener might have to interpolate some timestamps to recover the media clock. The number of timestamps to interpolate is mentioned in the CRF stream AVTPDU (Refer IEEE 1722-2016 Section 10.4 for AVTPDU structure). Only CRF Listener has been implemented in this commit. The CRF Sync element will create a separate thread to listen for the CRF stream. This thread will calculate and store the average period of the recovered media clock. The pipeline thread will use this stored period along with the first timestamp of the latest CRF AVTPDU received to calculate adjustment for timestamps in the audio/video streams. In case of CRF AVTPDUs with single timestamp, two consecutive CRF AVTPDUs will be used to figure out the average period of the recovered media clock. In case of H264 streams, both AVTP timestamp and H264 timestamp will be adjusted. In the future commits, another "CRF Checker" element will be introduced which will validate the timestamps on the AVTP Listener side. Which is why a lot of code has been implemented as part of the gstcrfbase class.
2020-02-06 00:17:39 +00:00
'gstavtpcrfutil.c',
'gstavtpcrfbase.c',
'gstavtpcrfsync.c',
'gstavtpcrfcheck.c',
]
avtp_dep = dependency('', required: false)
avtp_option = get_option('avtp')
if host_machine.system() != 'linux' or not cc.has_type('struct sock_txtime', prefix : '#include <linux/net_tstamp.h>')
if avtp_option.enabled()
error('avtp plugin enabled but host is not supported')
else
subdir_done()
endif
endif
avtp_dep = dependency('avtp', required: avtp_option, version : '>= 0.2.0',
fallback: ['avtp', 'avtp_dep'])
if avtp_dep.found()
gstavtp = library('gstavtp',
avtp_sources,
c_args : gst_plugins_bad_args,
include_directories : [configinc],
avtp: Introduce the CRF Sync Element This commit introduces the AVTP Clock Reference Format (CRF) Synchronizer element. This element implements the AVTP CRF Listener as described in IEEE 1722-2016 Section 10. CRF is useful in synchronizing events within different systems by distributing a common clock. This is useful in a scenario where there are multiple talkers who are sending data to a single listener which is processing that data. E.g. CCTV cameras on a network sending AVTP video streams to a base station to display on the same screen. It is assumed that all the systems are already time-synchronized with each other. So, the AVTP Talker essentially adjusts the AVTP Presentation Time so it's phase-locked with the reference clock provided by the CRF stream. There are 2 different roles of systems which participate in CRF data exchange. A system can either be a CRF Talker, which samples it's own clock and generates a stream of timestamps to transmit over the network, or a CRF Listener, the system which receives the generated timestamps and recovers the media clock from the timestamps. It then adjusts it's own clock to align with recovered media clock. The timestamps generated by the talker may not be continuous and the listener might have to interpolate some timestamps to recover the media clock. The number of timestamps to interpolate is mentioned in the CRF stream AVTPDU (Refer IEEE 1722-2016 Section 10.4 for AVTPDU structure). Only CRF Listener has been implemented in this commit. The CRF Sync element will create a separate thread to listen for the CRF stream. This thread will calculate and store the average period of the recovered media clock. The pipeline thread will use this stored period along with the first timestamp of the latest CRF AVTPDU received to calculate adjustment for timestamps in the audio/video streams. In case of CRF AVTPDUs with single timestamp, two consecutive CRF AVTPDUs will be used to figure out the average period of the recovered media clock. In case of H264 streams, both AVTP timestamp and H264 timestamp will be adjusted. In the future commits, another "CRF Checker" element will be introduced which will validate the timestamps on the AVTP Listener side. Which is why a lot of code has been implemented as part of the gstcrfbase class.
2020-02-06 00:17:39 +00:00
dependencies : [gstaudio_dep, gstvideo_dep, avtp_dep, libm],
install : true,
install_dir : plugins_install_dir,
)
2019-04-17 00:32:46 +00:00
plugins += [gstavtp]
endif