dr_flac: Slow Seeking With Ogg Container

[MikuAuahDark]

Seeking with native container is fast, but with Ogg container it's slow. The slowdown seems to be linear, the further I seek, the slower it becomes.

To test, first encode a file using FFmpeg to native FLAC.

ffmpeg -i input -c:a flac -compression_level:a 11 output.flac

Then perform remux to Ogg. This is important to preserve the totalPCMFrameCount in the STREAMINFO block, otherwise totalPCMFrameCount is 0 and seeking is not possible. (probably FFmpeg defect)

ffmpeg -i output.flac -c:a copy output.ogg

Then load output.ogg and perform seek. If you test output.flac, seeking is fast.

dr_flac 0.12.38.

[mackron]

Yes, Ogg seeking runs in linear time. The most efficient way to do it is to use Ogg's framing system to do a binary search, but I just haven't prioritized refactoring it because Ogg encapsulation is so uncommon and dr_flac's encapsulation system is not implemented very well at all which makes maintenance difficult (Ogg support was sort of hacked in without much thought put into it). I need to do a full refactor of the encapsulation system.

[MikuAuahDark]

Is it possible to do the encapsulation through libogg? I'm thinking of that because we already have libogg for Vorbis and Theora.

Pada tanggal Min, 8 Mei 2022 09.03, David Reid @.***> menulis:

Yes, Ogg seeking runs in linear time. The most efficient way to do it is to use Ogg's framing system to do a binary search, but I just haven't prioritized refactoring it because Ogg encapsulation is so uncommon and dr_flac's encapsulation system is not implemented very well at all which makes maintenance difficult (Ogg support was sort of hacked in without much thought put into it). I need to do a full refactor of the encapsulation system.

— Reply to this email directly, view it on GitHub https://github.com/mackron/dr_libs/issues/231#issuecomment-1120326567, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZHFFXAUA7VHMKRW5BW6U3VI4HHPANCNFSM5VJ2HC2Q . You are receiving this because you authored the thread.Message ID: @.***>

[mackron]

No, that wouldn't work. I won't add support for libogg integration into the library itself because it's supposed to not have any dependencies. And unfortunately the public API doesn't have any kind of abstraction where you could plug in a custom encapsulation. It's just an unfortunate situation where the library wasn't designed properly for it and it just needs refactoring. In my WIP dr_vorbis project I have proper support for custom encapsulations at the public API level, so depending on how that works out I may update dr_flac to use the same kind of system. That will be ages away before I get to that though.