Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support chained ogg files #18

Closed
est31 opened this issue Jun 8, 2017 · 5 comments
Closed

Support chained ogg files #18

est31 opened this issue Jun 8, 2017 · 5 comments

Comments

@est31
Copy link
Member

est31 commented Jun 8, 2017

Apparently its legal to chain multiple logical streams inside an ogg/vorbis file. The vorbis spec explicitly allows it:

The Ogg/Vorbis I specification currently dictates that Ogg/Vorbis streams use Ogg transport streams in degenerate, unmultiplexed form only. That is:

    A meta-headerless Ogg file encapsulates the Vorbis I packets
    The Ogg stream may be chained, i.e., contain multiple, contigous logical streams (links).
    The Ogg stream must be unmultiplexed (only one stream, a Vorbis audio stream, per link) 

See also similar bugs filed for flac, in firefox, and opus.

We should at least support playback here.

@est31
Copy link
Member Author

est31 commented Jun 8, 2017

The use case is streaming apparently, when you want to update metadata while the stream is running.

@lu-zero
Copy link
Contributor

lu-zero commented Mar 1, 2018

In general the demuxer should issue what I call a new stream event and react to it by either allocating a new decoder if it is a new stream or resetting the current decoder pinned to the current stream.

If you have some test sample we could try to adapt your ogg demuxer to fit this model and make sure it works well enough.

@est31
Copy link
Member Author

est31 commented Mar 2, 2018

I don't have any test samples but I think you should be able to generate some by concatenating two distinct ogg/vorbis files (it is important that they are distinct so that the stream serials don't match).

The ogg crate and the low level API of lewton that rust-av uses are more or less ready for it. The ogg crate just spits out packets and the only state that the low level API holds must be destroyed one way or another. What does need a change is the glue code between the two. lewton provides its own glue code via the inside_ogg module. This glue code is not used by the av-vorbis crate however, more or less by construction (av-vorbis intends to be generic from the container, supporting e.g. matroska, while inside_ogg only concerns ogg). The purpose of the inside_ogg module is to allow "normal" users to parse ogg/vorbis files without much fuss which is 99% of what people want to do. So given that even if it is fixed in lewton, it won't automatically be fixed for rust-av, I think we should open a separate bug in the av-vorbis crate and track the issue there.

@est31
Copy link
Member Author

est31 commented Mar 22, 2018

There are test vectors in https://people.xiph.org/~xiphmont/test-vectors/vorbis/ (files chain-test1.ogg to chain-test3.ogg) . Commit e051c7e introduced initial support.

@est31
Copy link
Member Author

est31 commented Oct 28, 2018

The first and second chained file examples are now fixed with commits dbfaae5 and e2b38e8.

@est31 est31 closed this as completed Oct 28, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants