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 550064 - [vorbisenc] Doesn't handle non-zero start timestamps properly
[vorbisenc] Doesn't handle non-zero start timestamps properly
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-08-31 14:10 UTC by Sebastian Dröge (slomo)
Modified: 2011-05-20 07:56 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sebastian Dröge (slomo) 2008-08-31 14:10:41 UTC
Hi,
vorbisenc doesn't handle non-zero start timestamps properly. This can be tested with

gst-launch-0.10 audiotestsrc num-buffers=1000 timestamp-offset=3000000000 ! vorbisenc ! oggmux ! filesink location=test.ogg

This stream starts with sound at 0 seconds while, with exchanging vorbisenc by flacenc, it starts at 3 seconds.
Comment 1 Sebastian Dröge (slomo) 2008-08-31 14:15:21 UTC
OTOH when muxing together with Theora the offset is handled fine
Comment 2 David Schleef 2008-08-31 16:39:29 UTC
I think it's vorbisenc that is correct here.  In particular, the granulepos values in the resulting file are offset from 0.

(There's a test in the testsuite concerning this, IIRC.)
Comment 3 Sebastian Dröge (slomo) 2011-05-19 08:39:12 UTC
I guess we need to define this as preferred behaviour of encoders somewhere. IMHO the encoders should just passthrough timestamps and timing information/segments and muxers should then muxers should mux them based on the running time.

Of course this is a bit complicated in the case of oggmux, but ideally oggmux would generate the granulepos itself without relying on the encoder to create them.
Comment 4 David Schleef 2011-05-19 17:40:51 UTC
(In reply to comment #3)
> I guess we need to define this as preferred behaviour of encoders somewhere.
> IMHO the encoders should just passthrough timestamps and timing
> information/segments and muxers should then muxers should mux them based on the
> running time.

This is what vorbisenc does (pipline above):

00:00:00.000: serialno 0316912248, granulepos 0, packetno 0 *** bos: 30 bytes
00:00:00.000: serialno 0316912248, calc. gpos 0, packetno 1: 91 bytes
00:00:00.000: serialno 0316912248, granulepos 0, packetno 2: 3.114 kB
00:00:03.000: serialno 0316912248, calc. gpos 132300, packetno 3: 43 bytes
00:00:03.002: serialno 0316912248, calc. gpos 132428, packetno 4: 20 bytes
00:00:03.015: serialno 0316912248, calc. gpos 133004, packetno 5: 56 bytes
00:00:03.039: serialno 0316912248, calc. gpos 134028, packetno 6: 38 bytes

First non-header packet is at 132300, or ~3*44100.

I'm not sure what the problem is here.
Comment 5 Sebastian Dröge (slomo) 2011-05-20 07:56:33 UTC
Yes, you're right. I looked at the output of oggmux (the offset/offset_end) which is of course not the granulepos anymore.