<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
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
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.
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
This fixes naive seeking a tiny bit (by basically hinting at _data_cb
that it shouldn't expect the incoming buffers to be the ones just after
the previous ones).
Without this, seeking by more than 10mins forward would just end up in an
endless loop.
This attribute can't be used for function declarations because
it needs the function body. Instead of a forward declaration of
functions, move the function itself above it's first use.
Fixes bug #594489 and compilation with gcc 4.3 and earlier.
In the clips that I've found those streams, the lpcm header is
different than the DVD case.
Then the decoder need to know this in order to be able parse it.
If there is an ISO 639 language descriptor for a stream, send a language
code tag so that players can show a meaningful language for the audio and
subtitle streams.
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.
