Use the length of the payload for estimating the receiver bitrate so that it
matches the calculations done on the sender side. Together with the number of
packets one can scale the bitrate with the header overhead of the lower
transport.
Don't reuse the same variable we need for stats for the bitrate estimation
because we're updating it.
Refactor the bitrate estimation code so that both sender and receivers use the
same code path.
Changing it to the newest timestamp that was ever pushed will
increase the segment start in 500ms jumps, which could be just
after the next sparse stream buffer. E.g.
Video at 1.0s, sparse stream at 0.5s would jump the
sparse stream to 1.0s. Now a new sparse stream buffer could
appear that has a timestamp of 0.9s and this would be
dropped for no good reason because of bad luck.
Multiple flvparse/flvdemux instances should be able to operate without
trampling over each other by accidentally re-using the same (static)
variables. (Spotted by Mark Nauwelaerts)
For calculating the durations of each sample, we are supposed to add each
duration modulo 1<<32 so make the elapsed time counter a uint32.
Fixes#610280
Make the handing of the mime type within the "boundary" a bit less naive.
The standard for MIME allows parameters to follow the "type" / "subtype"
clause separated from the mime type by ';'.
Modifies the multipartdemuxer's header parsing so it doesnt assume
the whole line after "content-type:" is the mime type and thus makes it a bit
more resilient to finding absurd mime types in the case where parameters are
added.
Fixes#604711
ALAC codec-data apparently comes in (at least) two flavours (mov, mp4),
so use atom based parsing to retrieve required data, rather than
aiming for a specific offset.
See also #580731.
Remove some code where we pass ntpnstime around, we can do most things with the
running_time just fine.
Rename a variable in the ArrivalStats struct so that it's clear that this is the
current system time.
Don't calculate the NTP time based on the running_time of the pipeline but from
the systemclock. This allows us to generate more accurate NTP timestamps in case
the systemclock is synchronized with NTP or similar.
Used the _add_associationv variant of GstIndex since we know how many
associations we're adding. Trims up to 50% from index generation time.
Note : It would be great if the index could be generated on the fly or
on request as opposed to being fully created at startup.
If we detect backward timestamps on the server, don't try to resync when we
don't have an input timestamp (such as when using RTSP over TCP) instead, do
nothing but assume the timestamp was ok, it will correct itself when time goes
forwards.
