Move the following functions to matroska-read-common.[ch] from
matroska-demux.c and matroska-parse.c:
- gst_matroska_{demux,parse}_encoding_cmp
- gst_matroska_{demux,parse}_read_track_encodings
https://bugzilla.gnome.org/show_bug.cgi?id=650877
Move the following functions to matroska-read-common.[ch] from
matroska-demux.c and matroska-parse.c:
- gst_matroska_{demux,parse}_peek_id_length_pull
- gst_matroska_{demux,parse}_peek_id_length_push
https://bugzilla.gnome.org/show_bug.cgi?id=650877
Not doing so will cause buffers to be received by downstream without
a time base set.
We use the same method avimux uses to get access to the event when
collectpads got the sink event function.
https://bugzilla.gnome.org/show_bug.cgi?id=640323
Move the following functions to matroska-read-common.[ch] from
matroska-demux.c and matroska-parse.c:
- gst_matroska_{demux,parse}_encoding_order_unique
- gst_matroska_{demux,parse}_read_track_encoding
https://bugzilla.gnome.org/show_bug.cgi?id=650877
Based on a patch by Guennadi Liakhovetski.
v2: updates because I forgot to add GstTuner interface to v4l2sink
v3: update to add all possible values to norm enum
Move the following functions to matroska-read-common.[ch] from
matroska-demux.c and matroska-parse.c:
- gst_matroska_decode_content_encodings
- gst_matroska_decompress_data
https://bugzilla.gnome.org/show_bug.cgi?id=650877
Replace the following functions with their gst_matroska_read_common_*
counterparts:
- gst_matroska_{demux,parse}_parse_index
- gst_matroska_{demux,parse}_parse_skip
- gst_matroska_{demux,parse}_stream_from_num
Introduce GstMatroskaReadCommon to contain those members of
GstMatroskaDemux and GstMatroskaParse that were used by the above
functions.
https://bugzilla.gnome.org/show_bug.cgi?id=650877
Tell GstBaseParse the duration in samples instead of time, so that
a duration query in DEFAULT format will return the correct number
of samples without rounding errors. Baseparse will convert this
into time itself when needed.
https://bugzilla.gnome.org/show_bug.cgi?id=650785
When not using the fieldanalysis element immediately upstream of deinterlace,
behaviour should remain unchanged. fieldanalysis will set the caps and flags on
the buffers such that they can be interpreted and acted upon to produce
progressive output.
There are two main modes of operation:
- Passive pattern locking
Passive pattern locking is a non-blocking, low-latency mode of operation that
is suitable for close-to-live usage. Initially a telecine stream will be
output as variable framerate with naïve timestamp adjustment. With each
incoming buffer, an attempt is made to lock onto a pattern. When a lock is
obtained, the src pad and output buffer caps will reflect the pattern and
timestamps will be accurately interpolated between pattern repeats. This
means that initially and at pattern transitions there will be short periods
of inaccurate timestamping.
- Active pattern locking
Active pattern locking is a blocking, high-latency mode of operation that is
targeted at use-cases where timestamp accuracy is paramount. Buffers will be
queued until enough are present to make a lock. When locked, timestamps will
be accurately interpolated between pattern repeats. Orphan fields can be
dropped or deinterlaced. If no lock can be obtained, a single field might be
pushed through to be deinterlaced.
Locking can also be disabled or 'auto' chooses between passive and active
locking modes depending on whether upstream is live.
... since the TEARDOWN sequence might not have had a chance to even start,
but at least connections should be closed (synchronously) and state cleaned up.
See #632504.
Simplify the command handling; passing a command to thread means we really
want it to get the message, which means to always flush provided the command
can handle being interrupted. Command thread indicates whether command
allows interruption and ensure non-flushing connection as it subsequently
needs it.
In particular, this also makes the TEARDOWN sequence interruptable
and also prevents races where _loop_ could miss a command and would
continue receiving (or at least trying to).
See #632504.
With the async state changes, it is possible that we need to open the stream
before play and pause.
Also make sure we remember a previous open failure so that we don't keep trying
again.
Simplify the command handling, only continue looping when we have not received
another command or when the previous loop was successfull.
Avoid looping on a disconnected socket.
