Since the seeking byte offset is chosen by linear interpolation
from SCR values, we need to take that first SCR into account
to end up near the correct offset. Otherwise, as the code does
a linear search after that first seek, it will take a LOOOOOONG
time to get there for streams which don't start at zero.
https://bugzilla.gnome.org/show_bug.cgi?id=659485
gcc 4.5 warns when comparing some integer with an enum value, in
the case of GstFlowReturn this is valid though. We should later
add GST_FLOW_CUSTOM_OK1, GST_FLOW_CUSTOM_OK2, etc. after new core
is released.
Increased performance doing pull_range in blocks of 32Kb instead of 4Kb.
Caching the value of gst_adapter_available instead of calling it 3 times.
Added some comments with the header descriptions.
Peek enough data to avoid a corner case where could be readed data outside
the buffer.
Speed up some more inlining some functions and keeping another stream pointer
list to be used as iterator.
Sprinkle branch prediction macros accross the code.
Handling the seeking with flush in pull mode in the proper way.
Don't treat some streams (Private Stream 2) as LPCM when they're not. Fixes
playback of files that have private streams in them now that the PES filter
emits such packets.
This should remove the bogus error messages while still keeping the original
intent of this, which is to inform the pipeline/application/user that we
could not find any valid streams.
There are many reasons why pushing an event can fail, and not all of them are
because there's no link downstream (it could be because it was blocked, or
flushing).
don't ignore the return value of pull_range because we only get a valid non-NULL
buffer when the return value is GST_FLOW_OK. Avoids a crash when the pipeline is
shutting down.
Ensure that the clossing segment is generated correctly and being
properly pushed.
Added some GST_DEBUG to check it.
Ensure that last_stop is updated in stream time.
Calculate duration as delta of PTS as it seems more correct than delta
of SCR in some clips that I tested.
Removed a line wrongly copy pasted in my previous commit.
Avoid an unsigned integer overflow.
Seek last_stop in stream time.
Clamp last_stop in stream time between first and last SCR.
Fixed a typo in the GST_DEBUG line and added some more info.
Original commit message from CVS:
* gst/mpegdemux/gstmpegdemux.c: (gst_flups_demux_src_query),
(gst_flups_demux_parse_pack_start):
Use the adjusted SCR for calculating the mux rate.
Don't update the rate estimation after a discont.
Original commit message from CVS:
* gst/mpegdemux/gstmpegdemux.c: (gst_flups_demux_send_data):
* gst/mpegdemux/gstmpegdemux.h:
The position member in the newsegment event corresponds to the
stream_time of the segment start position.
Original commit message from CVS:
Patch by: Robin Stocker <robin at nibor dot org>
* gst/mpegdemux/gstmpegdemux.c: (gst_flups_demux_src_query):
Converting from time to bytes operates on the stream_time, not the SCR
timeline.
The position reporting should happen in stream_time, not the segment
timestamp range. See #557161.
Original commit message from CVS:
* gst/mpegdemux/gstmpegdemux.c: (gst_flups_demux_send_data):
Make sure the mpegpsdemux element creates valid newsegment events.
Fixes#556428
Original commit message from CVS:
* gst/mpegdemux/gstmpegdemux.c: (gst_flups_demux_send_data),
(gst_flups_demux_parse_pack_start):
Prevent a division by zero if last mux rate was zero.
If we're going to send a NEWSEGMENT event but the segment start
and the current buffer timestamp differ by more than a second we
will start the NEWSEGMENT at the buffer timestamp.
This fixes playback of the tv2-1_25.mpg file, which has 0 as first SCR
but the first PTS are around 1 hour and 40 minutes.
Fixes bug #553755.
Original commit message from CVS:
* gst/mpegdemux/gstmpegdemux.c: (gst_flups_demux_parse_pack_start):
* gst/mpegdemux/gstmpegtsdemux.c: (gst_fluts_demux_data_cb):
Fix build on macosx.
