When we are waiting for a server reply, handle data messages instead of
ignoring them.

Refactor and make a method to handle a data message.

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

Actually call BINDTODEVICE to bind to the interface as given by the
property.

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

In theory we can only get I420 though, just to be on the safe side.

The encoder does not work with Y42B and Y444 yet it seems.

After we do a pause request, go back to loop mode so that we can listen
for server messages again.

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

First forward the stream-start, then the caps, then the rest

When setting timestamps on outgoing buffers, clear the
dts explicitly, otherwise it may end up being set to a
bogus value from last time it was used. Avoids every
second or so buffer's dts being set to 0. Not that it
should matter for raw video.

It is already defined in core.

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

When we go to paused, we first flush the connection and then send the pause
command. As a result of the flushing, the scheduled paused command can get
lost. Wait until the connection is completely flushed and the rtsp task is
waiting before issuing the paused or playing request.

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

As cameras tend to have a quite specific set of capabilities (specific
framerates for each resolution), getting the peer caps filtered by our
probed caps can cause a big increase in the caps size which slows down
things quire a bit.

As for negotiation v4l2 iterates through the caps of the peer to find the
first intersection with the probed caps, getting the fully expanded
intersection of capabilities is not useful.

Using the same testcase as for bug #702632, adding this patch on top of
the patches suggested there speeds up getting the inital frame from
around ~14-15 seconds to around ~3-4 seconds.

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

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

This can only reliably work if demuxers have a
separate streaming thread per srcpad. This should be
done in a demuxer base class, which integrates parts
of multiqueue

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

bug #700505

Following a representation change that causes a resolution change,
the video decoder fails to decode correctly. Dashdemux detects the
representation change and pushes a new caps event and an
initialization segment (a new moov atom) to the downstream qtdemux,
but it doesn't handle this new moov yet, it will only parse the
first one it receives.

This commit changes qtdemux to accept a new moov in a dash bitstream
switching scenario.

Do not send stream start again when reconfiguring a pad for new caps.
That is common for adaptive streams

The mp2t payloader in 0.10 mislabelled the streams as MP2T-ES
instead of MP2T, so accept that as well for compatibility reasons.

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

Lock the state of the all our elements and manage their states
outselves. Because we are working async, we can't rely on the state
change function to set the state at the right time or to return the
right return value from the state change function.

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

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

Don't use an unused hashtable to iterate source to calculate bandwidth.
Remove unused code.

This is needed for pa_format_info_get_prop_* functions.

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

This reverts commit 01457027.

We'll just depend on PulseAudio 2.0 or above instead of having the bug
partially fixed based on the installed libpulse version.

The getcaps function we added uses some pa_format_info_get_prop...
accessor functions that were only added in 2.0, so we only have our
getcaps implementation exist if we're compiling against libpulse 2.0 or
above.

Eventually, we could bump the minimum requirement to 2.0 or above.

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

This reverts commit 2d3910fc.

It's not solving any problem and instead causes code to fall apart.

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

And also mark the streams that should be selected by default if
marked so in the headers.

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

Split out two more tests. Extract more common code into helpers. Add coverage for float.

Only map input if we are reading it. Cleanup the logging and the comments a bit.

Use special variants for the case when we don't change the panorama (pan=0.0).
Simplify the processing functions by passing the panorama value directy instead
of the instance. Use orc for clearing buffers too.

The last end_time was saved after conversion, so the comparison
had to be made after conversion for it to make sense.

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

When the segment start is not 0, this created a situation where
the output_end_time is inferior to output_start_time, and the duration
of the next buffer ended up underflowing.

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

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

Also configure video streams as early as possible.

Related https://bugzilla.gnome.org/show_bug.cgi?id=701856
but not fixing that.