There is no difference between pushing out a buffer directly
with gst_rtp_base_depayload_push() and returning it from the
process function. The base class will just call _depayload_push()
on the returned buffer as well.
So instead of marshalling buffers through three layers and back,
just push them from one place in handle_nal() and always return
NULL from the process vfunc. This simplifies the code a little.
Also rename _push_fragmentation_unit() to _finish_fragmentation_unit()
for clarity. Push sounds like it means being pushed out, whereas
it might just be pushed into an adapter.
This change has the side-effect that multiple NALs in a single STAP
(such as SPS/PPS) may no longer be pushed out as a single buffer if
we output NALs in byte-stream format (i.e. not aggregate AUs), but
that shouldn't really make any difference to anyone.
This implements H264 encoding support using generic V4L2 interface. It is
reported to work with Samsung MFC driver, IXM.6 CODA driver and
Qualcomm mainline Venus driver. Other platform should be supported as
none of this work is platform specific.
The implementation consist of a GstV4l2VideoEnc base class, which
implements the core streaming functionality. This base class is implemented
by GstV4l2H264Enc class that implements the caps negotiation specific to
H264 profiles and level. This implementation supports hardware with multiple
H264 encoder. Though, to make it simplier to use, the first discovered H264
encoder will be named v4l2h264enc. Other encoder found during discovery will
have a unique name like v4l2video0h264enc.
This work is the combined work of multiple developpers in the last 3
years. Thanks to all of the contributors:
Ayaka <ayaka@soulik.info>
Frédéric Sureau <frederic.sureau@vodalys.com>
Jean-Michel Hautbois <jean-michel.hautbois@veo-labs.com>
Nicolas Dufresne <nicolas.dufresne@collabora.com>
Pablo Anton <pablo.anton@vodalys-labs.com>
https://bugzilla.gnome.org/show_bug.cgi?id=728438
Use the ::process_rtp_packet() vfunc to avoid mapping the
RTP buffer twice.
gst_rtp_buffer_get_payload_buffer() returns a new sub-buffer
which will always be writable, so no need to make it writable.
Every g_quark_from_static_string() is a hash table lookup serialised
on the global quark lock in GLib. Let's just look up the two quarks
we need once and cache them locally for future use. While we're at it,
add new utility functions for the two most commonly used tags
(audio + video). Make first argument a gpointer so we don't have to
cast and make the code ugly. These are used for logging purposes
only anyway.
This allows timing out on network errors much earlier
(currently it takes ~15min to timeout) and we can still
unlock and change state in the meantime.
https://bugzilla.gnome.org/show_bug.cgi?id=571722
Fixes a negotiation error seen when trying to playback of a .MOV file with
a mono AAC audio stream decoded by avcdec_aac that doesn't set channel-mask
field but sink was requiring channel-mask=0x3.
Tags are pushed to "videosrcpad"/"audiosrcpad" in
gst_dvdemux_add_pad() method, however they will be NULL
in this method, hence tags are not pushed.
Instead, send tag event to "pad" created gst_dvdemux_add_pad().
Signal no-more-pads when both pads are created
https://bugzilla.gnome.org/show_bug.cgi?id=743657
Since the move from CVS the property name of the documentation example
has been filename instead of location. Users trying the gst-launch
command as is will get:
no property name "filename" in element
Fixing it.
If a non-reference stream is behind the reference stream by an amount of
time smaller than the alignment threshold (in nsec), it counts as being
after it.
https://bugzilla.gnome.org/show_bug.cgi?id=782563
Timecode trak is only supported for mov right now, not for mp4. That
code would otherwise create an invalid trak if the muxed video contained
timecode metadata.
https://bugzilla.gnome.org/show_bug.cgi?id=782684
We only accept new caps if they are basically the same. We don't want to
reset anything as if the caps are new, otherwise various state could get
out of sync with the current run.
We have some padding added after the initial moov, so a bigger updated
moov can be handled to some degree and is expected. Previously we just
ignored the padding and errored out in cases when the padding would've
just been enough.
souphttpsrc now shares its SoupSession with other elements in the
pipeline via GstContext if possible (session-wide settings are all the
defaults), or if the context was forced by the application.
This allows multiple souphttpsrcs to reuse connections, cookies, etc.
https://bugzilla.gnome.org/show_bug.cgi?id=780140
This sets up a moov with the correct sample positions beforehand and
only works with constant framerate, I-frame only streams.
Currently only support for ProRes and raw audio is implemented but
adding new codecs is just a matter of defining appropriate maximum frame
sizes.
https://bugzilla.gnome.org/show_bug.cgi?id=781447
When muxing raw audio, we have no way of storing timestamps but are just
storing a continuous stream of audio samples. If the difference between
the expected and the real timestamp becomes to big, we should error out
instead of silently creating files with wrong A/V sync.
https://bugzilla.gnome.org/show_bug.cgi?id=780679
We were unnecessarily looping/goto-ing repeatedly when we had exactly
the amount of data as the free space, and also when the free space was
too small. This, as it turns out, is a very common scenario with
Directsound on Windows.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=773681
We have to do polling here because the event notification API that
Directsound exposes cannot be used with live playback since all events
must be registered in advance with the capture buffer, you cannot
add/remove them once playback has begun. Directsoundsrc had the same
problem.
See also: https://bugzilla.gnome.org/show_bug.cgi?id=781249
