search for: ffv1

Dear all, We are excited to announce that the our CELLAR working group charter for the standardization of FFV1, Matroska, and FLAC has been made available for external review. What this means is that it is now under review and available for comment to the wider IETF community. Please send any comments you might have(including statement of support)to the IESG mailing list by November 9, 2015. The mailing l...

...v list, I'm writing to ask for feedback from the FLAC community regarding the possibility of standardizing the FLAC specification through the Internet Engineering Task Force. I'm working with MediaArea on the PREFORMA project which focuses on building conformance checkers for Matroska and FFV1. Since Matroska and FFV1 are not yet formally standardized, this past July, I presented a proposal for an IETF working group for standardizing specifications for FFV1 and Matroska, both of which are open-source but without formal standardized specifications. We chose to bring this to the IETF beca...

...rk is living here https://github.com/ > privatezero/flac_markdown. > > > I sent a pull request at https://github.com/privatezero/flac_markdown/ > pull/1, which starts to add a process to convert the markdown to the RFC > format using the same Makefile approach that we use with the FFV1 and EBML > markdown files. There's still a lot of inter-document cross-referencing > that needs to be adjusted before the Makefile works. For instance current > cross-referencing like: > > [*SUBFRAME\_VERBATIM*](#subframe_verbatim) > > won't render as expected in a plai...

.... It was me who reported the bug where total samples wraps around on overflow. FLAC performs extremely well on SDR samples, both speed and compression ratio. In my testing it outperforms any other free lossless codec by a large margin, being 20% smaller and 10% faster than the next best (which was ffv1). The problem is the metadata, and not just total samples. We also can't put true values in the sample rate field because it doesn't have enough bits (I have files with 35468950MHz nominal sample rate for example), and there is no way to record that samples have been padded eg from 10 bits...

...ezero/flac_markdown>. > > I sent a pull request at https://github.com/privatezero/flac_markdown/pull/1 <https://github.com/privatezero/flac_markdown/pull/1>, which starts to add a process to convert the markdown to the RFC format using the same Makefile approach that we use with the FFV1 and EBML markdown files. There's still a lot of inter-document cross-referencing that needs to be adjusted before the Makefile works. For instance current cross-referencing like: > > [*SUBFRAME\_VERBATIM*](#subframe_verbatim) > > won't render as expected in a plain text RFC, b...

...l the best! > Andrew Weaver From a review of the markdown and the rendered RFC, I’d like to consider renaming many of the components of FLAC from the ALL_CAPS_WITH_UNDERSCORE_STYLE to `Title Case Names in BackTicks` (which is similar to how local components have been named and referenced in the FFV1 and Matroska documents). Thus “METADATA_BLOCK_HEADER” would be `Metadata Block Header` and expressed with that same case and quoting at each reference. I also suggest that the metadata block types such as “METADATA_BLOCK_STREAMINFO” and “METADATA_BLOCK_APPLICATION” simply be renamed as `Streaminfo...

...ac_markdown>. >> >> I sent a pull request at https://github.com/privatezero/flac_markdown/pull/1 <https://github.com/privatezero/flac_markdown/pull/1>, which starts to add a process to convert the markdown to the RFC format using the same Makefile approach that we use with the FFV1 and EBML markdown files. There's still a lot of inter-document cross-referencing that needs to be adjusted before the Makefile works. For instance current cross-referencing like: >> >> [*SUBFRAME\_VERBATIM*](#subframe_verbatim) >> >> won't render as expected in a p...

...a standards. Brian On Oct 15, 2024, at 12:26 PM, Alistair Buxton wrote: > FLAC performs extremely well on SDR samples, both speed and compression ratio. In my testing it outperforms any other free lossless codec by a large margin, being 20% smaller and 10% faster than the next best (which was ffv1). The problem is the metadata, and not just total samples. We also can't put true values in the sample rate field because it doesn't have enough bits (I have files with 35468950MHz nominal sample rate for example), and there is no way to record that samples have been padded eg from 10 bits...

Op di 15 okt. 2024 16:18 schreef Stefan Oltmanns <stefan-oltmanns at gmx.net>: > > I see, but that would require changes in the software using libflac and > require the file to be easily seekable to be able to skip to the end and > depending on how far away the seek points are, it could take a while. > No, seeking to a specific sample can take a while because of all the

...ehavior is setting it to 0 if total samples > 2^36 > > FLAC performs extremely well on SDR samples, both speed and compression > ratio. In my testing it outperforms any other free lossless codec by a > large margin, being 20% smaller and 10% faster than the next best (which > was ffv1). The problem is the metadata, and not just total samples. We also > can't put true values in the sample rate field because it doesn't have > enough bits (I have files with 35468950MHz nominal sample rate for > example), and there is no way to record that samples have been padded e...

I sent in some suggestions regarding Theora yesterday and I got some questions from you guys so I'll answer them.?i said this:Theora should have a feature that disables print screen and video recording software from capturing Theora videos.?Alot of you asked me about the Fair Use law. My answer is this. i do know about fair use.?The?problem is, alot of people don't obey the fair use law as