dashdemux: Remove wrong assertion

This is wrong because:
* If the rate is negative we should check for the *previous* period
* adaptivedemux already does the proper checks before calling this
  method

ttml: Simplify code

n2 can never be NULL since:
* it's in a "while (n1 && n2)" block
* and it's not modified before

CID #1405868

nonstreamaudio: Avoid using wrong variable

And to make that 100% obvious, only use variables declared within the
switch cases instead of function-wide ones.

Also remove useless one-time-use-only variable.

CID #1409857

nonstreamaudio: Avoid using un-initialized value

We would end up with cur_position not set but proceed being at its
default value of TRUE. Instead, properly set proceed to FALSE

CID #1409855

adaptivedemux: Fix debugging message

GstSegment position is a guint64 and not a gint64

CID #1409910

adaptivedemux: Check live seeking range more often

The live seeking range was only checked when doing actual seeks. This was
assuming that the rate would always be 1.0 (i.e. the playback would
advance in realtime, and therefore fragments would always be available
since the seeking window moves at the same rate).

With non-1.0 rates, this no longer becomes valid, and therefore we need
to check whether we are still within the live seeking range when advancing.

https://bugzilla.gnome.org/show_bug.cgi?id=783075

adaptivedemux: Don't create invalid event

tags could potentially be NULL

adaptivedemux: retry download MAX_DOWNLOAD_RETRY_COUNT times before erroring

What we want is to retry downloading the fragment on 4xx/5xx errors
however returning EOS will cause waiting for a manifest update for live
(which may be a really long time) or stop everything for non-live.

Change that to only return EOS/ERROR once we've reached the error limit.

https://bugzilla.gnome.org/show_bug.cgi?id=776609

gl: Fix indentation

glframebuffer: #define GL_READ_FRAMEBUFFER / GL_DRAW_FRAMEBUFFER if not defined yet

Just like we do elsewhere already.

glformat: fix the usage of GST_GL_RGB565

GL_RGB565 is sized internal glformat, the corresponding glformat
should be GL_RGB and type is GL_UNSIGNED_SHORT_565. Otherwise will
return GL_INVALID_ENUM when creating texture.

https://bugzilla.gnome.org/show_bug.cgi?id=783066

glframebuffer: check frame buffer status need use specific fbo target

https://bugzilla.gnome.org/show_bug.cgi?id=783065

openmpt: Fix compilation with 0.2.7386 as in Debian

The OPENMPT_API_VERSION_AT_LEAST macro does not exist.

tests: Make audiomixer test_clip verify the resulting timestamps too

aggregator: Process serialized queries through the queue

This ensures that they really get processed in order with
buffers. Just waiting for the queue to be empty is sometimes not
enough as the buffers are dropped from the pad before the result is
pushed to the next element, sometimes resulting in surprising
re-ordering.

aggregator: Set flow to FLUSHING on pad stop

Fixes a rare race where the pad is being stopped while doing a query.

tests: audiointerleave: Remove drain with manual clock

Now that the queries go onto the queue, you may need to pull the crank
in order for them to be processed, making this test difficult.

Require wildmidi >= 0.4

https://bugzilla.gnome.org/show_bug.cgi?id=768576

wildmidi: include stdint.h for int8_t

win32: update .def file for new base class

https://bugzilla.gnome.org/show_bug.cgi?id=768576

wildmididec: explicitly cast buffer data to int8 in _decode()

Fixes compiler warning introduced in commit ff32a4297:

gstwildmididec.c:637:47: error: pointer targets in passing argument 2 of ‘WildMidi_GetOutput’ differ in signedness
       WildMidi_GetOutput (wildmidi_dec->song, (char *) (info.data), info.size);
                                               ^
wildmidi_lib.h:106:15: note: expected ‘int8_t * {aka signed char *}’ but argument is of type ‘char *’
 WM_SYMBOL int WildMidi_GetOutput (midi *handle, int8_t *buffer, uint32_t size);

https://bugzilla.gnome.org/show_bug.cgi?id=768576

openmpt: Add openmptdec element

https://bugzilla.gnome.org/show_bug.cgi?id=768576

wildmidi: Port to 1.0 on top of the nonstreamaudiodecoder base class

https://bugzilla.gnome.org/show_bug.cgi?id=768576

audio: Add nonstreamaudiodecoder base class

https://bugzilla.gnome.org/show_bug.cgi?id=768576

gltestsrc: Fix typo (occured->occurred)

https://bugzilla.gnome.org/show_bug.cgi?id=782947

meson: don't need config.h.meson any longer

audioaggregate: Don't hold object locks across calls to aggregate_one

https://bugzilla.gnome.org/show_bug.cgi?id=782878

aggregator: Request pad templates which are not request pad

https://bugzilla.gnome.org/show_bug.cgi?id=782920

aggregator: Don't restrict sink pad names

Sink pads could have other names than sink_%u

https://bugzilla.gnome.org/show_bug.cgi?id=782920

glbasemixer: Remove unused negotiated member

This is now all handled in GstAggregator, so this code is not
called anymore.

videoaggregator: Declare that it supports the video meta on input

https://bugzilla.gnome.org/show_bug.cgi?id=782918

gl*mixer: Use propose_allocation from the GstAggregator base class

https://bugzilla.gnome.org/show_bug.cgi?id=782918

aggregator: Implement propose allocation

https://bugzilla.gnome.org/show_bug.cgi?id=782918

aggregator: Check for the result of caps events

https://bugzilla.gnome.org/show_bug.cgi?id=782918

aggregator: Caps event always goes to the aggregate thread

So no need to check it here.

https://bugzilla.gnome.org/show_bug.cgi?id=782918

gl/viv-fb: Fix user-choice string comparisons

https://bugzilla.gnome.org/show_bug.cgi?id=782921

qmlglsink: Add dummy texture that is shown as placeholder for NULL buffers

https://bugzilla.gnome.org/show_bug.cgi?id=782917

win32: update .def file for new exports

videoaggregator: Create normal video pool as a fallback

https://bugzilla.gnome.org/show_bug.cgi?id=746529

audioaggregator: Use downstream allocator and params if available

https://bugzilla.gnome.org/show_bug.cgi?id=746529

glbasemixer: Remove own decide_allocation, use GstAggregator's

https://bugzilla.gnome.org/show_bug.cgi?id=746529

glbasemixer: Use aggregator for allocation handling

https://bugzilla.gnome.org/show_bug.cgi?id=746529

videoaggregator: Get the buffer from the pool if available

https://bugzilla.gnome.org/show_bug.cgi?id=746529

aggregator: Add downstream allocation query

https://bugzilla.gnome.org/show_bug.cgi?id=746529

videoaggregator: Return to parent on reconfigure

The caps negotiation is now in the parent, so need to return there
if a reconfiguration is needed, otherwise it will loops forever.

gl: x11: fix compiler warning

glcontext: add public swap_buffers function

That simply calls the implementation

examples: gl: remove ancient bitrotten .vcproj files

adaptivedemux: fix debug message printf format

Match gsize to G_GSIZE_FORMAT in the debug message.

https://bugzilla.gnome.org/show_bug.cgi?id=782873

win32: update .def file for API removal

audiointerleave: Take object lock while modifying channel count

aggregator: Remove unused GST_FLOW_NOT_HANDLED

aggregator: add simple support for caps handling

Modelled off the videoaggregator caps handling as that seems the most
mature aggregtor-using implementation that has caps handling there is.

https://bugzilla.gnome.org/show_bug.cgi?id=776931

aggregator: Reset upstream latency on first buffer

In the case an aggregator is created and pads are requested but only
linked later, we end up never updating the upstream latency.
This was because latency queries on pads that are not linked succeed,
so we never did a new query once a live source has been linked, so the
thread was never started.

https://bugzilla.gnome.org/show_bug.cgi?id=757548

videoaggregator: delay using new caps from a sink pad until the next buffer in the queue is taken

When caps changes while streaming, the new caps was getting processed
immediately in videoaggregator, but the next buffer in the queue that
corresponds to this new caps was not necessarily being used immediately,
which resulted sometimes in using an old buffer with new caps. Of course
there used to be a separate buffer_vinfo for mapping the buffer with its
own caps, but in compositor the GstVideoConverter was still using wrong
info and resulted in invalid reads and corrupt output.

This approach here is more safe. We delay using the new caps
until we actually select the next buffer in the queue for use.
This way we also eliminate the need for buffer_vinfo, since the
pad->info is always in sync with the format of the selected buffer.

https://bugzilla.gnome.org/show_bug.cgi?id=780682

aggregator: Always handle sync'ed events on output thread

Having all synchronized events always be handled on the output
thread should make synchronization easier.

https://bugzilla.gnome.org/show_bug.cgi?id=781673

aggregator: Delay clipping to output thread

This is required because the synchronized events like caps or segments
may only be processed on the output thread.

https://bugzilla.gnome.org/show_bug.cgi?id=781673

aggregator: Make pad eos as soon as all buffers are processed, dont way for events

https://bugzilla.gnome.org/show_bug.cgi?id=781673

aggregator: Only count buffers when declaring queue full

https://bugzilla.gnome.org/show_bug.cgi?id=781673

tests: Test caps using query

Sending an event can accepted event if the caps were rejected
because the event could be queued and processed later.

Also send a drain query in the caps test to make sure that the
event has been processed.

https://bugzilla.gnome.org/show_bug.cgi?id=781673

aggregator: Simplify clip function

The return value was ignored anyway

https://bugzilla.gnome.org/show_bug.cgi?id=781673

aggregator: Only declare first buffer on actual buffer

The function needs to be unlocked if any data is received, but only
end the first buffer processing on an actual buffer, synchronized events
don't matter on the first buffer processing.

https://bugzilla.gnome.org/show_bug.cgi?id=781673

aggregator: Set initial position on first buffer

Set the initial position on the first buffer, otherwise the queue
will grow without limits before the output thread is started.

https://bugzilla.gnome.org/show_bug.cgi?id=781673

aggregator: Reset the pad's first buffer flag with the rest

There is not reason to have separate code to reset this one.

https://bugzilla.gnome.org/show_bug.cgi?id=781673

aggregator: Reset pad on init

Factor out the pad reset code from the flushing and use it on init as well

https://bugzilla.gnome.org/show_bug.cgi?id=781673

aggregator: Fix indentation

https://bugzilla.gnome.org/show_bug.cgi?id=781673

glcontext: keep a ref to the active thread

With the macOS/iOS implementations, the active thread can change
multiple times over the life of a pipeline which would expose a race in
the thread tracking.

Fix by taking a ref on the active thread while the context is active.

https://bugzilla.gnome.org/show_bug.cgi?id=779202

meson: add options to set package name and origin

https://bugzilla.gnome.org/show_bug.cgi?id=782172

examples: fix macOS 9.12 deprecation warnings

Add #defines to allow older versions of macOS to use the new constant names.

cocoa: fix a recently introduced typo

Fixes gstgldisplay_cocoa.m:175:26: error: use of undeclared identifier 'singletone'.

cocoa: fix macOS 10.12 deprecation warnings

Add #defines to allow older versions of macOS to use the new constant names.

dashdemux: Use correct (sub) fragment start when clipping chunk size

If we didn't download anything yet, we shouldn't use fragment.start but
the start position of the current sidx entry.

dashdemux: Make sure to pass the next buffer after a seek with DISCONT flag

When we manually seek for skipping ahead in keyunit-only trickmode, we
have to enforce that ourselves as adaptivedemux does not know about the
seeks.

dashdemux: Ensure that we never ever download over the current SIDX entry

Even if downloading more than needed to try to get the moof and first
keyframe both together.

dashdemux: Take SIDX entry timestamp/duration into account for keyunit-only mode

And not the whole segment's timestamp/duration

dashdemux: Reset parsing state correctly in various places

dashdemux: Reset previous target_time when seeking

dashdemux: Smooth out skip distances in keyframe-only trick modes

This ensures smoother playback. It looks weird if we first do a big
jump, then play a couple of consecutive frames, just to again skip ahead
quite a bit because we ran late again.

dashdemux: Take configure max bitrate/framerate into account for keyframe skipping

And by default only produce up to 10 fps.

dashdemux: Try harder to not run into a loop over the same fragment over and over

While still making sure to not jump ahead one fragment further than
needed.

dashdemux: Add some debug output to the target time selection

dashdemux: Use the current clock running time in addition to the QoS earliest time

dashdemux: Download keyframes from the current position if we're far enough ahead

Far enough here means more than 500ms or 4 times the average keyframe
download time. There is no need to jump ahead by one average keyframe
download time in this case.

This makes playback smooth if the network is fast enough.

dashdemux: Fix sync sample selection based on target time in reverse playback mode

dashdemux: Snap-seek for skipping ahead and use actual keyframe distance in the current fragment if applicable

dashdemux: Don't adjust for fragment duration twice when seeking ahead in KEYUNITS mode

dashdemux: Add current fragment duration in reverse playback mode to the position

We play from the end of the fragment to the beginning, not from the
beginning backwards.

dashdemux: Never take more than the current fragment duration for estimations inside the fragment

Taking the average might give us from results.

dashdemux: Don't increase current position if we just downloaded the moof in KEYUNIT mode

dashdemux: Improve key-unit trick mode downloading

When dealing with key-unit trick mode downloads, the goal is to
provide the best "Quality of Experience". This is achieved by:
1) maximizing the number of frames displayed per second
2) avoiding "stalling" as much as possible (i.e. not downloading and
  decoding frames fast enough)

This implementation achives this by:
1) Knowing very precisely the current keyframe being download (i.e
  more accurate than at the fragment level which might contain more
  than one keyfram). This is the new "actual_position" variable
  introduced by this commit
2) Knowing the position of downstream (provided by QoS and stored
  in the adaptivedemuxstream qos_earliest_time variable)
3) Knowing how long it takes to request and fully download a keyframe
  (the average_download_time variable)

Taking those 3 variables into account, whenever a keyframe has been
pushed downstream we calculate a "target time" (target_time variable)
which is the ideal next keyframe time to request so that:
1) It will be requested/downloaded/demuxed/decoded in time to be
  displayed without being too late
2) It will not be too far ahead that it would cause too few frames
  per second to be displayed.

How far ahead we will request is inversily proportional to how close
the actual position (actual_position) is from the downstream
position (qos_earliest_time). The more is buffered between the source
and the sink, the "closer" the target time will be, and therefore
the more frames per seconds will be displayed (up to the limit
of keyframes_per_second * absolute_rate).

dashdemux: Store average download time

This will be used to bound the download rate when working in
keyframe-only trick mode

adaptivedemux: Add various comments to the code

adaptivedemux: Store QoS time

Allows subclasses to know where downstream is and make decisions
based upon that

dashdemux: Collect keyunit distance and size statistics

dashdemux: Disable bitrate switching in key-unit trick mode

This creates too much havoc for now

dashdemux: Use new adaptivedemux trickmode macro

Reduces the lines of code, and makes it a bit more readable

adaptivedemux: Add a macro to know if we are in trickmode-keyunit

Reduces the amount of lines of code in subclasses

uvch264src: Apply timestamps to outgoing aux buffers

When extracting an aux buffer from an MJPG carrier, at
*least* put the original timestamp on it, even if we
fail to apply any other timestamp (which we always do
at the moment, because the timestamp calculating code
was never finished). Apply a DTS using the camera
supplied delay value as well, assuming that there's
no re-ordering going on (there isn't in the C920,
which is really the only extant camera doing this
stuff) and a warning if that turns out not to be true.

qt: Use GST_GL_HAVE_PLATFORM_CGL instead of GST_GL_HAVE_PLATFORM_COCOA

The latter is not used/available anymore since years. Also fix a typo
in the include path for the Cocoa GL display header.

motioncells: delay motionmaskcoords until caps arrive

motionmaskcoords is not applied on start because the information
about resolution isn't available until caps arrive.

https://bugzilla.gnome.org/show_bug.cgi?id=768666