Limit the amount of data scanned when looking for PTSes in duration queries as a
failsafe for kinda broken, potentially large files with sparse or no PTSes.
A previous patch to add streams early to fix playback of
low bitrate streams causes frequent deadlock of a nature
I'm at loss how to fix.
I'm not certain whether it's a bug in decodebin2, or in
that mpegtsdemux patch.
Since it causes a major regression, let it be disabled for now.
This code is to sync to a live source when there is a delay
between start and when we receive the first buffer, so it does
not make sense in a non live case.
This fixes playback of streams where the input timestamps are
based off some arbitrary offset.
https://bugzilla.gnome.org/show_bug.cgi?id=663756
One of my dvds jump on some position and miss about 1 minute of stream.
The reason was mpeg timestamps. On some position scr difference is negative.
It produced negative timestamps. Since it was converted to unsigned value,
gstreamer timestamps was invalid. Instead of increasing mpeg ts,
they was decreasing till it started to be positive.
The jump in timestamps caused mpeg2dec to skip frames to make QoS happy.
This patch just make diff unsigned to avoid negative values.
Signed-off-by: Alexey Fisher <bug-track@fisher-privat.net>
https://bugzilla.gnome.org/show_bug.cgi?id=656115
Some streams declare PIDs but will not send data for them.
Ensure we time out on those, and both send new segments to
keep their time synchronized with the rest, and do not wait
forever before deciding to signal no-more-pads.
https://bugzilla.gnome.org/show_bug.cgi?id=659924
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
There was a second threshold, which apparently needs to be smaller
than the first, though I'm not certain of it as I don't understand
yet this nest of wtf that is the mpeg demuxer timing logic.
Fixes video freezing on one (corrupted) MPEG sample. It would
previously never think it was out of the discontinuity, and would
push buffers with no timestamp.
Now this took me more than a day's poking at the thing, for just
one constant change, and I'm scared to have to touch this again :S
https://bugzilla.gnome.org/show_bug.cgi?id=655804
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.
This is probably the cause for an occasional crash while streaming
MPEG. Blind fix after staring at the code and following logic, so
may or may not fix the issue, I cannot test.
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
Remove the android/ top dir
Fixe the Makefile.am to be androgenized
To build gstreamer for android we are now using androgenizer which generates the needed Android.mk files.
Androgenizer can be found here: http://git.collabora.co.uk/?p=user/derek/androgenizer.git
Or possibly even at startup. If we couldn't find a sync within
the first few bytes, we'd just push more data into the adapter
but never discard any of the invalid data at the beginning, so
would never be able to re-sync.
https://bugzilla.gnome.org/show_bug.cgi?id=639063
<tpm> leio, what's the mpegts demux hack about?
<leio> my libdvbsub code can't handle cut packets
<leio> so the hack instructs the demuxer to gather full packets before pushing down, but it applies that to more PES packet types than just dvbsub, but I'm not sure if that's a bad thing
<leio> either way, needs a cleaner solution, either in demuxer, or I need to handle cut packets
<tpm> ok, but really it should be fixed in the overlay, right?
<tpm> or a parser be inserted
<leio> the problem is that I don't know from the first packet beforehand if it is a cut one or no
<leio> not
<leio> err, first buffer
<leio> just when I receive the next one I see if it has a valid timestamp on it or not
<leio> so I can't very well queue it up in the chain either, I might be blocking the very last subtitle for no reason or something
<tpm> but you could just drop/ignore packets until you find one, right?
<leio> find what?
<tpm> a complete packet?
<leio> the problem isn't that they aren't complete
<leio> the problem is that they are cut across multiple GstBuffers by the demuxer without the hack
<tpm> sure, I understand that
<tpm> but you can't easily determine if a GstBuffer contains he start fragment of a packet or not?
<leio> I guess I could parse the packet and see if its length is enough, just like the libdvbsub code eventually does too
<leio> I can, it has a timestamp if it's the first chunk
<leio> I just never know if I need to wait for more, without some parsing
<tpm> ah ok
<leio> while the demuxer could just give me an uncut one in the first place
<leio> like it always does for program streams
<leio> that gather_pes is always set in gstmpegdemux, but not in gstmpegtsdemux
TDT and TOT sections, with PID=0x14, doesn't extend to several packets
and the section filter is not needed here and shouldn't be used at all
for these tables because the have a different structure.
For example, TDT tables were not parsed for odd hours because this bit
is the 'current_next_indicator' bit for the other sections, and the table
was discarded.
This is a problem if you tune to a channel which uses pid X and later tune to
another channel where X is used for another table (e.g. PMT).
The code that does that was actually already there but never used because the
pat structure was freed before. The commit that introduced those lines intended
to fix a memory leak, but we clean things up elsewhere.
Fixes#622725.
gst_mpeg_descriptor_find() expects the description field to be non-NULL.
This fixes a couple of calls where the value being passed is not
verified to be non-NULL first.
https://bugzilla.gnome.org/show_bug.cgi?id=620456
Some tables in MPEG-TS do not have a crc in the spec, so also mpegtsparse
is not calculating crc for sections with table_id 0x70 - 0x72 because they
do not have a CRC in the spec. See EN300468. Parse Time and Date table and
output bus message.
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.
The current code just uses table id, subtable extension and version number to
check if the section has been seen before. However, this comparison is not
sufficient, causing actually new tables being dismissed.
Fixes bug #614479.
Because config.h defines __MSVCRT_VERSION__, which should be defined
before inclusion of any system header.
Also fixes mpegdemux Makefile.am LIBADD typo.
Fixes#606665
When the stream type is set to private data, gst-mpegtsdemux is trying to find
audio descriptors in PMT and look for AC3 (tag 0x6a) but doesn't look for EAC3
(tag 0x7a). Handle this case too.
Fixes bug #605904.
There is unfortunately no G_*_FORMAT conversion specifier for differences of
pointers in glib, and we can't rely either on all platforms being 64bit.
So let's just cast the difference to a gint and be done with it.
When sending new-segment to a stream, ensure that there is either a valid
PCR, or else wait until there's a PTS on the stream (dropping packets if
needed) in order to avoid generating an invlaid new-segments event.
https://bugzilla.gnome.org/show_bug.cgi?id=595161
