Some Xing headers apparently start the TOC at byte 1 instead of 0. Don't
reject them because of it, just subtract the initial offset when reading
the table.
Be more lenient about what we accept as changing bits in a header - basically,
only require that the mp3 sync marker is present, for the mpeg version,
layer and samplerate.
Fixes: #581464
Some mp3 streams have an offset in timestamps, requiring us to push the
frame *AFTER* segment.stop in order for the decoder to be able to push
all data up to the segment.stop position.
This also makes timestamps (more) consistent before and after a possible
seek, and moreover makes for reasonable position reporting in live stream
(whose payload timestamps should not be taken for granted).
* Improve newsegment handling, e.g. upstream might live in TIME.
* Only send newsegment if we have needed info.
* Avoid reading past end of data section.
lame_set_VBR_quality(), which takes a floating point value for the
quality, has been added only in v3.98. Use lame_set_VBR_q(), which
takes quality as an integer, for older LAME versions.
Fixes#581341.
The problem that happens is the following:
* A packet with multiple payloads comes in
* Those payloads get handled one by one
* The first payload contains the first audio payload with timestamp A
* The second payload contains the first video (key)frame with timestamp V (where V < A)
With the previous code, the following would happen:
* the first payload gets processed, then passed to queue_for_stream
* queue_for_stream detects it's the first valid timestamp received and stores
first_ts = A
* the second payload gets processed, then pass to queue_for_stream
* queue_for_stream detects the timestamp is lower than first_ts... and
discards it... resulting in losing the first keyframe of the video stream
We've been having this issue for *ages*... it's just that nobody noticed it
that much with playbin. But with playbin2's aggresive multiqueue handling, this
will result in multiqueue not being able to preroll (because the video decoder will
be dropping a ton of buffers before (maybe) receiving the next keyframe).
Tested with over 200 asf files, and they all play the first frame correctly now,
even the most braindead ones.
This might be caused by entering the if() line 1214 and then not having
any activated_streams.. resulting in reaching line 1267 without having
any valid flow value.
