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

Kitchensink v2 dev branch #77

Draft
wants to merge 73 commits into
base: master
Choose a base branch
from
Draft

Kitchensink v2 dev branch #77

wants to merge 73 commits into from

Conversation

katajakasa
Copy link
Owner

@katajakasa katajakasa commented Oct 30, 2023

WIP

Done:

  • Require ffmpeg 5.x.
  • Slightly less cpu intensive due to newer ffmpeg API
  • Split decoding and demuxing to their own threads
  • Proper thread locking and conditions
  • Better seek (no more lockups and weirdness!)
  • Better clock control
  • Lower memory usage, less allocations overall (use av_frame_ref/unref)
  • Stream switching
  • Clang-format
  • Hardware decoding for video (push to gpu, pull from gpu)
  • Functionality for fetching buffering status and size (in bytes and in time)

Under construction:

  • Don't support any graphics API directly -- instead support pulling the frames directly. User can then decide what graphics API they want to use.

TODO:

  • Set AVDISCARD_ALL on unused streams
  • Function for waiting for buffers to fill before starting playback
  • Allow disabling a stream after playback has been started.
  • Finally figure out multichannel audio -- properly map ffmpeg channels to SDL channels, and try to do the right thing if there is no direct match.
  • Get rid of subtitle renderers -- just make them separate decoders.
  • Move libass renderer to a thread
  • Better atlas ?

Not a goal:

  • Colorspaces. Those things are evil. hisssss.

@katajakasa
Copy link
Owner Author

Is it possible to add back ffmpeg 4.x support? For example buildroot still uses ffmpeg 4.x. So requiring 5.x makes this unusable on many embedded devices that use buildroot to generate their images.

Probably, but I really don't want to. There are a bunch of handy APIs in v5 that v4 does not have (e.g. conversion stuff). I don't use ffmpeg v4 myself, and I have no test environments for it. Also, I don't want to put any time in testing against every last variation of the v4 libraries.

Still, finishing this branch will probably take quite a while still with how little time I have to put on it. It may well be that everyone has at least ffmpeg v5 at that point ;)

katajakasa added 29 commits May 12, 2024 19:54
This should fix audio streams where the output packets can be very small (just a few samples!).
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

Successfully merging this pull request may close these issues.

2 participants