Version written is 3.0
Base times are left empty for now.
Content-Type should be the MIME type of the stream. It is set to
the GStreamer media type for now, which is probably the same for
the streams oggmux supports.
https://bugzilla.gnome.org/show_bug.cgi?id=563251
vorbisenc currently reacts in a rater draconian fashion if input
timestamps are more than 1/2 sample off what it considers ideal. If data
is 'too late' it truncates buffers, if it is 'too soon' it completely
shuts down encode and restarts it. This is causingvorbisenc to produce
corrupt output when encoding data produced by sources with bugs that
produce a smple or two of jitter (eg, flacdec)
If ints are 64 bits, 32 bits should get promoted in varargs anyway,
and we don't care about 16 bit ints.
This makes the code a lot more readable, and still gets us nice
hexadecimal 32 bit serialnos.
https://bugzilla.gnome.org/show_bug.cgi?id=656775
Instead of just assuming all pads are created at the same time,
remember which ones are actually new (via ->pending_blocked_pads).
This allows the following use-case to properly work:
* Upstream starts with audio-only
* Only that pad gets data, blocks and a real audio sink is created
* Upstream laters adds a video stream
* A new pad is requested, blocks and reconfiguration kicks in in
order to add a new real video sink
Unlike linux, OSX wakes up select with POLLOUT (instead of POLLERR) when
connect() is done async and the connection is refused. Therefore always check
for the socket error state using getsockopt (..., SO_ERROR, ...) after a
connection attempt.
In ID3 v2.3 compressed frames will have a 4-byte data length indicator
after the frame header to indicate the size of the decompressed data.
This integer is unlikely to be a sync-safe integer for v2.3 tags,
only in v2.4 it's sync-safe.
Reversing the unsynchronisation seems to work slightly differently
for ID3 v2.3 tags and v2.4 tags: v2.3 tags don't have syncsafe frame
sizes in the frame header, so the unsynchronisation is applied to
the whole frame data including all the frame headers. v2.4 frames
have sync-safe sizes, however, so the unsynchronisation only needs
to be applied to the actual frame data, and it seems that's what's
being done as well. So we need to undo the unsynchronisation on a
per-frame basis for v2.4 tags for things to work properly.
Fixes extraction of coverart/images from APIC frames in ID3 v2.4
tags (#588148).
Add unit test for this as well.
We didn't handle unsynchronization at all up to now, which might have
caused frames to not be extracted - esp. frames after an APIC picture
frame. Fixes#577468.
