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 784969 - matroskamux: Should use SimpleBlocks for Opus and probably other audio codecs
matroskamux: Should use SimpleBlocks for Opus and probably other audio codecs
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: dont know
1.12.0
Other Linux
: Normal minor
: 1.12.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-07-15 06:58 UTC by Sebastian Dröge (slomo)
Modified: 2017-08-11 08:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
matroskamux: For audio tracks, take the default duration from the first buffer (3.53 KB, patch)
2017-07-18 07:43 UTC, Sebastian Dröge (slomo)
committed Details | Review

Description Sebastian Dröge (slomo) 2017-07-15 06:58:25 UTC
> gst-launch-1.0 audiotestsrc num-buffers=1000 ! opusenc ! matroskamux ! filesink location=test.mka

This plays fine in GStreamer and ffplay, but VLC only plays silence.

> gst-launch-1.0 audiotestsrc num-buffers=1000 ! vorbisenc ! matroskamux ! filesink location=test.mka

This plays fine everywhere.

> ffmpeg -i test.mka -acodec opus test2.mka

This plays fine everywhere too.


We must be doing something weird here that confuses VLC.
Comment 1 Tim-Philipp Müller 2017-07-15 08:39:18 UTC
WRN00C: Unknown element in TrackEntry [56][BB] at 421 (size 4 total 7)
WRN00C: Unknown element in TrackEntry [56][AA] at 428 (size 3 total 6)
WRN201: Unknown 'BlockVirtual' for read profile 'matroska v2' in BlockGroup at 211505

vlc does do a short 'blip' at the very end ;)
Comment 2 Sebastian Dröge (slomo) 2017-07-15 10:07:51 UTC
(In reply to Tim-Philipp Müller from comment #1)
> WRN00C: Unknown element in TrackEntry [56][BB] at 421 (size 4 total 7)
> WRN00C: Unknown element in TrackEntry [56][AA] at 428 (size 3 total 6)

SeekPreroll and CodecDelay also written by ffmpeg (with the same values) and required for Opus.

> WRN201: Unknown 'BlockVirtual' for read profile 'matroska v2' in BlockGroup
> at 211505

Where do you see that? We don't write BlockVirtual


But we write real BlockGroups with Blocks, while ffmpeg writes SimpleBlocks (except for the last). We should do that too as it causes overhead to not use SimpleBlocks.
Comment 3 Sebastian Dröge (slomo) 2017-07-18 07:17:18 UTC
The problem here is that VLC apparently only likes Opus in SimpleBlocks. But we can't write SimpleBlocks here as we don't know the duration of all buffers. We could assume that duration of the first to be the default duration, and in 99% of the cases that would work, but there's no guarantee.

When making matroskamux output SimpleBlocks, VLC plays this just fine. This seems like a bug in VLC (nothing requires SimpleBlocks to be used for Opus in the spec), and an inefficiency on our side
Comment 4 Sebastian Dröge (slomo) 2017-07-18 07:28:42 UTC
See https://trac.videolan.org/vlc/ticket/18545 for the VLC bug report.
Comment 5 Sebastian Dröge (slomo) 2017-07-18 07:43:23 UTC
Created attachment 355802 [details] [review]
matroskamux: For audio tracks, take the default duration from the first buffer

... if we don't have any better idea from the caps. This allows writing
SimpleBlocks for a majority of audio streams where the duration of
frames is usually fixed. And as a side effect, allows VLC to play
streams with Opus as it only works with SimpleBlocks currently:
  https://trac.videolan.org/vlc/ticket/18545
Comment 6 Sebastian Dröge (slomo) 2017-07-18 07:44:27 UTC
This makes about 6% difference in file size for a simple "audiotestsrc ! opusenc ! matroskamux" pipeline.
Comment 7 Sebastian Dröge (slomo) 2017-07-19 08:03:33 UTC
While it's probably a bit optimistic to assume that upstream puts correct duration on buffers, it shouldn't cause problems if it is incorrect. We would just put (wrong) durations on each Block again then.

A future patch could extract codec specific durations from buffers directly by parsing, but I'd postpone that for later when it's actually needed.
Comment 8 Tim-Philipp Müller 2017-07-19 08:25:10 UTC
If upstream puts incorrect durations on there, that's an upstream bug then.

As long as it works if upstream doesn't put durations on the buffers.
Comment 9 Sebastian Dröge (slomo) 2017-07-19 08:39:31 UTC
It will work as good as before the patch then (not using SimpleBlocks but full BlockGroups/Blocks)
Comment 10 Sebastian Dröge (slomo) 2017-07-25 08:29:04 UTC
Attachment 355802 [details] pushed as 317d338 - matroskamux: For audio tracks, take the default duration from the first buffer
Comment 11 Sebastian Dröge (slomo) 2017-07-25 08:37:11 UTC
Not sure if this should also go into 1.12. It reduces muxing overhead quite a bit and fixes playback in VLC (due to a VLC bug), but OTOH could also have unforeseen side effects.
Comment 12 Tim-Philipp Müller 2017-07-25 08:49:10 UTC
I wonder if it should at least check the assumptions it makes, and fallback to full blocks if the duration is not the same every time?