We track streams for which a data callback is set (and for which
pads will be added only when data is received), and signal
no-more-pads when the last pad is added.
https://bugzilla.gnome.org/show_bug.cgi?id=659924
In a test stream, I get one buffer with a PTS of about 15 seconds
in the future compared to the previous one, and next buffers with
timestamps continuing where the original ones left off.
This caused the sink to wait 15 seconds to display the frame while
more frames queued up, and then dump all the subsequent frames as
they "arrived too late".
Maybe that threshold should be made configurable, but for now,
make it more smaller to catch more of these.
https://bugzilla.gnome.org/show_bug.cgi?id=655804
Non AV streams keep using the larger threshold (10 minutes), as
subtitles may arrive only every so often.
If the estimated bitrate is lower than 188 bytes, there's most likely
something completely wrong with the two samples. If that happens,
force recalculation.
Use guint64 for observation PCR, I saw cases where it would overflow.
Sync from gst-fluendo-mpegdemux and have seeking/duration query
improvements in. No support however for wrapped around pcrs etc. but a
start nonetheless.
Also fix indentation issues.
Original commit message from CVS:
* gst/mpegdemux/gstmpegtsdemux.c:
* gst/mpegdemux/gstmpegtsdemux.h:
Enable latency code, since we're definitely after 0.10.12
Original commit message from CVS:
Patch by: Josep Torra
* gst/mpegdemux/gstmpegtsdemux.c:
* gst/mpegdemux/gstmpegtsdemux.h:
Properly handle some resync cases in the optimised
buffering strategy.
Original commit message from CVS:
Patch from: Josep Torra
* gst/mpegdemux/gstmpegtsdemux.c:
* gst/mpegdemux/gstmpegtsdemux.h:
Use a preallocated buffer per stream for PES packets sent on src pads.
Adaptively adjust buffer size appropriately.
