Before, vp8dec had no option but to decode all frames even if some/all
of them would be late. With this change, performance when keyframes are
frequent is helped a great deal. On my Thinkpad X60s, decoding a 20 s
1080p sunflower encode with keyframes every 10 frames went from taking
42 s with 5 frames shown to 21 s with 15 frames shown (still slow
enough to count by hand). When keyframes are more sparse, you will
still be able to catch up eventually, but the results won't be as
noticable.
The original plan was to let WebM v1 be the same as Matroska v2 (with
extra constraints), but for simplicity it was decided to handle the
versions equally, such that e.g. SimpleBlock is only allowed in WebM v2.
Failure to do this for corrupt input can cause a subbuffer bigger
than the actual buffer to be created, quickly leading to segfault.
Test case:
bug_s222005751_r0.001____memcpy.webm
The comment says this cannot happen, but it did and I don't know
why. This is not the correct fix, needs investigation. Test case:
bug_s555010094_r0.0005:0.008____IA__g_assertion_message_expr.webm
Because GstMatroskaTrackContext *stream is set up in the first
SimpleBlock or Block, a rogue CodecState otherwise causes a segfault on
derefencing the NULL pointer. Test case:
bug_s5506167_r0.001____gst_matroska_demux_parse_blockgroup_or_simpleblock.webm
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.
As a side effect, avoid sending newsegment updates with start times
that go back and forth, which leads to bogus downstream running_time.
Also fixes seeking in bug #606744.
.. by initializing streams starting at 0, as that is basically
where we 'seek to' at the start and assume streams to start elsewhere.
Also enables newsegment update events for subtitle streams.
Matroska uses three-letter ISO 639-2B codes, but GST_TAG_LANGUAGE is
supposed to contain two-letter ISO 639-1 codes, so use new language
code mapping functions in -base to convert between those two as
needed.
Fixes#505823.
Send pending tags only from the streaming thread, just after we've sent
the newsegment event, not with e.g. flush-start. This not only does the
right thing, but also makes sure we're not trampling over variables set
up in the streaming thread from the seeking thread in case someone tries
to issue a seek just as the demuxer is parsing the headers.
Fixes#601617. Spotted by Ognyan Tonchev.
