Currently, whenever we generate a 128-bit UID, we store it in a list and
return 0 if we ever encounter a collision. This is so mathematically
improbable that it's not worth checking for, so we can save memory and
time by not tracking the UID. Even if a collision happened, a list of
only 10 UIDs would be unlikely to detect it.
This article has a good description of how improbable a collision is:
https://en.wikipedia.org/wiki/Universally_unique_identifier#Collisionshttps://bugzilla.gnome.org/show_bug.cgi?id=797086
TOC support in mastroskamux has been deactivated for a couple of years. This commit updates it to recent GstToc evolutions and introduces toc unit tests for both matroska-mux and matroska-demux.
There are two UIDs for Chapters in Matroska's specifications:
- The ChapterUID is a mandatory unsigned integer which internally refers to a given chapter. Except for title & language which use dedicated fields, this UID can also be used to add tags to the Chapter. The tags come in a separate section of the container.
- The ChapterStringUID is an optional UTF-8 string which also uniquely refers to a chapter but from an external perspective. It can act as a "WebVTT cue identifier" which "can be used to reference a specific cue, for example from script or CSS".
During muxing, the ChapterUID is generated and checked for unicity, while the ChapterStringUID receives the user defined UID. In order to be able to refer to chapters from the tags section, we maintain an internal Toc tree with the generated ChapterUID.
When demuxing, the ChapterStringUIDs (if available) are assigned to the GstTocEntries UIDs and an internal toc mimicking the toc is used to keep track of the ChapterUIDs and match the tags with the appropriate GstTocEntries.
https://bugzilla.gnome.org/show_bug.cgi?id=790686
WebM has a couple of specific requirements we need to handle.
Idea is to set this flag once and just rely on mux->is_webm
at run time instead of repeatedly figuring this out from
GST_MATROSKA_DOCTYPE_WEBM (which requires a strcmp()).
Support for TAG_IMAGE and TAG_ATTACHMENT is commented out; this requires caps
on buffers which is gone from 0.11.
Segment handling in the demuxer is a bit complex; I added some FIXME comments
in places where I'm not yet sure if I ported correctly.
Frame duration might vary for 1 usecond, in this case matroskamux
decides to create BLOCKGROUP instead of SIMPLEBLOCK.
Convert duration to timecodescale which is (typically) less precise, and
then also allow the difference of 1/-1 to arrange for less sensitive check.
Based on patch by Alexey Fisher <bug-track@fisher-privat.net>
Fixes#653080.
Start cluster at every keyframe or when we would overflow the previous
cluster's relative timestamp field. This would avoid as much as possible
starting clusters at non-keyframes.
Remove BITMAPINFOHEADER and use the one from riff-lib. Also remove the
WAVEFORMATEX_SIZE define and use a sizeof together with the respective struct.
Besides better code reuse this lessens the ununsed symbols in the docs.
Added the 'min-index-interval' property to matroskamux,
which determines how much time (nanoseconds) is left
between keyframes stored in the index.
Fixes#583985.
Link to properties. Correct titles for examples. Document a few trivial cases. Keep lists in section file and docs/plugins/Makefile.am alphabetically ordered. Fix warnings that gtk-doc points out.
Original commit message from CVS:
* gst/matroska/matroska-mux.c: (gst_matroska_mux_reset),
(gst_matroska_mux_handle_sink_event), (gst_matroska_mux_finish):
* gst/matroska/matroska-mux.h:
Remove internal taglist and fully use tagsetter interface.
Original commit message from CVS:
* gst/matroska/matroska-mux.c: (gst_matroska_mux_reset),
(gst_matroska_mux_start), (gst_matroska_mux_finish),
(gst_matroska_mux_write_data):
* gst/matroska/matroska-mux.h:
Don't write another SeekHead which indexes all Clusters to the end of
the file. This isn't useful for anything and just increases filesize.
Original commit message from CVS:
Based on patch by: Wouter Cloetens <wouter at mind be>
* gst/matroska/matroska-mux.c: (gst_matroska_mux_video_pad_setcaps),
(gst_matroska_mux_request_new_pad), (gst_matroska_mux_release_pad),
(gst_matroska_mux_finish), (gst_matroska_mux_collected):
* gst/matroska/matroska-mux.h:
Keep track of first and last timestamps for each incoming stream,
so we can calculate the total duration for live sources and other
input where we can't query the duration from the start or where
there's no constant framerate from which we can deduce the
duration; also use calculated/observed duration if it is bigger
than the previously queried duration. Furthermore, use
gst_pad_query_peer_duration() and take into account that it may
return TRUE but still a duration of CLOCK_TIME_NONE, which easily
screws up comparisons when using unsigned integers. Fixes#504081.
Original commit message from CVS:
Fix byte order reversion for writing ebml floats.
Write segment duration and muxing application in matroska.
Added TTA codec to the list of supported codecs to mux into matroska.
Original commit message from CVS:
Riff, EBML, fourcc etc. work. Not fully finished, but better than
what we used to have and definately worth a first broad testing.
I've revived rifflib. Rifflib used to be a bytestream-for-riff, which
just dup'ed bytestream. I've rewritten rifflib to be a modern riff-
chunk parser that uses bytestream fully, plus adds some extra functions
so that riff file parsing becomes extremely easy. It also contains some
small usability functions for strh/strf and metadata parsing. Note that
it doesn't use the new tagging yet, that's a TODO.
Avidemux has been rewritten to use this. I think we all agreed that
avidemux was pretty much a big mess, which is because it used all
sort of bytestream magic all around the place. It was just ugly.
This is a lot nicer, very complete and safe. I think this is far more
robust than what the old avidemux could ever have been. Of course, it
might contain bugs, please let me know.
EBML writing has also been implemented. This is useful for matroska.
I'm intending to modify avidemux (with a riffwriter) similarly. Maybe
I'll change wavparse/-enc too to use rifflib.
Lastly, several plugins have been modified to use rifflib's fourcc
parsing instead of their own. this puts fourcc parsing in one central
place, which should make it a lot simpler to add new fourccs. We might
want to move this to its own lib instead of rifflib.
Enjoy!
