After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 654828 - matroskamux: useless overhead on vorbis.
matroskamux: useless overhead on vorbis.
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-07-18 10:06 UTC by Oleksij Rempel
Modified: 2011-09-07 13:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch v1 (2.11 KB, patch)
2011-07-18 18:00 UTC, Oleksij Rempel
none Details | Review

Description Oleksij Rempel 2011-07-18 10:06:46 UTC
Current matroska/webm-mux create BlockGroup with timestamp and duration for each vorbis block. IMHO it is a useless overhead.

Background:
Usually Blockgroup with duration used together with DefaultDuration to reduce overhead. In case with vorbis we can't use DefaultDuration.
Vorbisencoder use variable block size. It variate from 64 to 8192 samples per block. What minimal and maximal blocksizes will be used, depends on initial settings (like sample rate and quality/bitrate), and some other decisions made after start for specific sample groups.
After codec start we can ask minimal and maximal blocksize, and probably use some middle one to calculate block duration, but this behavior may variate from one codecversion to other.

So we can't use DefaultDuration.

About the use of BlockDuration. Since we know samplerate and probably can read current blocksize of vorbis in blockheader, there is no sense to use blockduration.

In case the blockduration is less as difference between current and next timestamp, then we play silence in the rest of the time. If it is bigger, then some thing is wrong and muxer is brocken. But we can't fix it if we write blockduration.

Are there any other use for blockduration for vorbis? If not, it should be removed.
Comment 1 Oleksij Rempel 2011-07-18 18:00:52 UTC
Created attachment 192208 [details] [review]
patch v1
Comment 2 Mark Nauwelaerts 2011-09-07 10:25:49 UTC
On the one hand, this already seems to have been partially addressed in bug #653080 (avoiding to write a block duration as much as possible).

On the other hand, this is pretty HACKish kind of patch, and the whole argument as to whether or not a block duration is useful/needed is not really vorbis specific and kind of a matter-of-taste (in particular, yes, a matroska file with no duration for the buffers/block will probably play just fine).

All in all, IMO this means this kind of "overhead tweaking" should/could be configured by some property (similar to the current min-index-interval and streamable ones).  A patch that way should therefore go down well ...
Comment 3 Sebastian Dröge (slomo) 2011-09-07 10:35:01 UTC
Yes, as discussed on IRC a few weeks ago this should be a property on the muxer's sinkpads. There are also many other things that could be configured in matroskamux on a per-stream basis
Comment 4 Oleksij Rempel 2011-09-07 13:53:20 UTC
Ok Sebastian, you have right.
I'll reduce me to Bug 654379.