We used to skip frame rate setup if the camera was already setup
with the requested frame rate. This breaks some cameras though,
causing them to not output data (several models of Thinkpad cameras
have this problem at least).
So, don't skip.
https://bugzilla.gnome.org/show_bug.cgi?id=638300
The reason is to let rtpdtmfmux drop buffers during the inter digit interval,
this way, there will be more silence around the DTMF tones so IVFs will have
a better chance recognizing them.
flacdec converts the src timestamp to a sample number, uses that internally, then reconverts the sample number to a timestamp for the output buffer. Unfortunately, sample numbers can't be represented in an integer number of nanoseconds, and the conversion process was truncating rather than rounding, resulting in sample numbers and output timestamps that were often off by a full sample.
This corrects the time->sample convesion
This likely breaks stuff. The good: all of the methods now create
field images aligned with input frames, without timestamp mangling.
The bad: this touches a lot of code, much of which is hairy and in
need of cleanup. However, at this point we can reasonably create a
PSNR-based test.
There's no use in splitting the incoming data down to the segsize
limit - by writing as much as possible in one chunk, we increase
performance and avoid PulseAudio unnecessary rewinds.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
In particular, do so even if failing to read while prerolling,
such as when reading from a partial file (eg, while it is being
downloaded).
This fixes a wedge in playbin2.
https://bugzilla.gnome.org/show_bug.cgi?id=651965
The libFLAC API is callback based, and we must only call it to
output data when we know we have enough input data. For this
reason, a single processing step is done when receiving a buffer.
However, if there were metadata buffers still pending, a step
intended for the first audio frame might end up writing that
leftover metadata. Since a single step is done per buffer, this
will cause every buffer to be written one step late.
This would add some latency (a bufferfull's worth), possibly
lose a buffer when seeking or the like, and also cause timestamp
and offset to be applied to the wrong buffer, as updates to
the "current" segment last_stop (from incoming buffer timestamp)
will be applied to an output buffer originating from the previous
incoming buffer.
This fixes the issue by ensuring that, upon receiving the first
audio frame, processing is done till all metadata is processed,
so the next "single step" done will be for the audio frame. After
this, we should keep to 1 input buffer -> 1 output buffer and so
avoid getting out of sync.
https://bugzilla.gnome.org/show_bug.cgi?id=650960
Yes, I was tracking another bug and the small test file I generated
to test with improbably just happened to trigger this, with a second
and last frame of 1615 bytes.
https://bugzilla.gnome.org/show_bug.cgi?id=656649
