Previously, we could get false sync relatively easily - it sometimes happened
on real files. This cleans the code up a fair bit, and makes it require more
confirmation that we've found valid sync before continuing.
Metadata provided seek tables are consistent with metadata's view of
total size, which typically matches real size, but need not do so
(e.g. a truncated file). Fixes seeking and position reporting
in such truncated files (although duration based on metadata may then
still be incorrect).
asf packets in rtp packets should come with their padding fields
set to 0 and the depayload must update them to the correct
value before pushing downstream
This also fixes a bug by which the first buffer (in a multi-packet mode)
passed to asf_demux_parse_packet() would have a GST_BUFFER_SIZE of the
full incoming buffer and not just of the single asf packet.
Fixes corrupted frames introduced by latest commit.
We now have a chance for packets to be collected before we send out the
newsegment. If we're not in accurate seeking (keyunit) it will set
the segment start/time to the keyframe's timestamp.
We now *always* seek to the keyframe just before our requested position.
When we encounter the first keyframe and we were not accurate (therefore doing
keyframe seeking), we update the segment start position to the keyframe timestamp.
This will still cause some timestamp jitter, but giving a hint as to the duration
rather than nothing seems to be a better idea.
Also, this allows some scenarios (like remuxing with asfmux) to estimate the total
duration using the accumulated packet duration (which will be correct).
The simple index entries also contain the number of packets one needs
to retrieve at a given position to get a full keyframe. We therefore
use that information to retrieve all those packets in one buffer when
working in pull-mode.
In gst_asf_demux_chain_headers, when 'goto wrong_type' was called
asfdemux tried to free a const pointer that had been cast to a
normal pointer variable.
We weren't taking the preroll into account previously, meaning that we
were always seeking preroll nanoseconds too early... resulting in a lot
of dropped packets (which are before the start time).
This brings quit a bit closer to as-fast-as-possible seeking in asf files.
Post global tags only after we've added our source pads, so that
tag events get sent downstream in addition to tag messages posted
on the bus. This makes sure tags can be picked up automatically
when transcoding, but also by tagreadbin/playbin2. Fixes#519721.
While we're at it, also add a container-format tag.
When we receive a DISCONT as input, don't clear our complete state but simply
mark a discont that will be put on the next buffer. The code will be able to
handle and throw away incomplete data.
Add some more debug info.
Remove an unused variable.
Let's not put every single mp3 frame in our index, a few frames per
second should be more than enough. For now use an index interval
of 100ms-500ms depending on the upstream size, to keep the index at
a reasonable size. Factor out the code that adds the index entry
into a separate function for better code readability.
While technically upstream may be seekable even if it doesn't know
the exact size, I can't think of a use case where this distincation
is relevant in practice, so for now just assume we're not seekable
if upstream doesn't provide us with a size. Makes sure we don't
build a seek index when streaming internet radio with sources that
pretend to be seekable until you try to actually seek.
Don't overwrite the origin flow return by whatever flow we get
when trying to push the remaining internally queued payloads.
We want to do our eos logic, ie. send an EOS event or segment-done
message in any case. Makes things EOS properly when an EOS event
is forced upon the pipeline so that the source returns
FLOW_UNEXPECTED to a pulling asfdemux. Should fix#582056.
Add a multichannel map to the output caps, and send at least a CODEC and
BITRATE tag. I'm not too sure about the 5.1 and 7.1 channel maps. I have
no samples and can't find info about the channel ordering, but this is
better than nothing.
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
