I've just merged the https://github.com/xiph/flac/pull/735
Since the last email on this list, I've added one more function to the
API, FLAC__stream_decoder_skip_single_link(), which does 'bisecting
seeking' to find the end of the link if its location isn't known yet.
This was quite a complex piece
Martijn van Beurden wrote:
Okay, I just came up with a possible solution. In the case of
multiplexed streams, FLAC could not just keep track of its own serial
number in that link, but also of the serial numbers of other streams
in that link. That way, it could easily determine whether it is still
Okay, I just came up with a possible solution. In the case of
multiplexed streams, FLAC could not just keep track of its own serial
number in that link, but also of the serial numbers of other streams
in that link. That way, it could easily determine whether it is still
in the current link, as any
I've been thinking a while about this, reading some code, and I can't
get my head around it, so I hope I can get some more help and/or
advice.
As an example, take a multiplexed, chained stream, with both links
being a video stream alongside a FLAC audio track. To find the end of
the first link and
Martijn van Beurden wrote:
There are still a lot of things that can be improved in libFLAC, so I
think I'll leave it be for a while when this works. I agree it is not
efficient, but for now, chained ogg is a niche use case for FLAC. I'd
Incremental steps are usually best. I think mostly you wan
Op di 3 sep 2024 om 16:10 schreef Timothy B. Terriberry :
>
> Martijn van Beurden wrote:
> > As far as I know, please correct if wrong, neither libopusfile nor
> > libvorbisfile provide this functionality either. In neither I could
> > find a function to find the total number of samples over all li
Martijn van Beurden wrote:
As far as I know, please correct if wrong, neither libopusfile nor
libvorbisfile provide this functionality either. In neither I could
find a function to find the total number of samples over all links.
Opus has a fixed samplerate so there is no changing, but libvorbisf
Op ma 2 sep 2024 om 22:40 schreef Timothy B. Terriberry :
>
> Martijn van Beurden wrote:
> >> Since chained streams can have different sample rates, how would one go
> >> about seeking to a specific _time_?
> >
> > I assume one would first use the sample rate of the first link to
> > guess the samp
Martijn van Beurden wrote:
Since chained streams can have different sample rates, how would one go
about seeking to a specific _time_?
I assume one would first use the sample rate of the first link to
guess the sample number, seek to that point, correct if it turns out
one of the links that pas
For some reason, I didn't get Brians email, but I noticed it was
replied to, so I'll copy from the archive
> Is there an overview - in plain English - summarizing the API changes?
No, not yet, as it isn't final yet. However, for the API changes, one
only has to look at the header files, not the a
brianw wrote:
On Sep 1, 2024, at 12:44 PM, Martijn van Beurden wrote:
Everything works, but as is with any change to the API, I don't know
whether it is convenient for API users other than the flac command
line tool. So, I'd like some feedback.
I only looked briefly, but I had a few questions.
Hello,
Is there an overview - in plain English - summarizing the API changes? I
realize that the github page linked below has the actual code changes, but I
was hoping for a design overview. I do see comments and discussion, but did not
readily find any overview. If I missed something, please h
12 matches
Mail list logo
