Conversation
… for each frame on a new thread xd
…r ffmpeg is finished if there are more files in the directory to do
|
The most recent commit uses the pillow library to check if the png file is a valid png, as the path for the file will exist before it's fully generated from ffmpeg. This should hopefully stop the race condition of chafa trying to open the png file before it's properly created by ffmpeg. |
|
Caveat is you'd have to add the pillow library to the project in a venv and probably a pyproject.toml lol |
|
weird bug with fastfetch in general in the devshell where the shell variable is a bit messed up but otherwise the devshell works good as an environment for users with nix |
why not just check the size? |
Honestly I just wasn't sure what a good minimum filesize was. (weirdly enough in the time I walked away from my computer and came back the check using the pillow library no longer works as it did? It's failing every other benchmark now lol when I ran it like 10 times in a row). So I'm back to square 1 again lol. This is the error in particular that occurs at times with the filesize (and now pillow) check, most commonly when running the benchmark as it runs the program multiple times. It only shows up in about 1 in 4 benchmark runs but that's still not ideal. This wasn't a concern before as we were only starting the chafa process after ffmpeg had finished processing the video, but now that it is running concurrently it is an issue. I'll keep trying stuff. |
|
I think I fixed the image open with pillow check? Running benchmark like 10 times to be absolutely sure. |
|
Okay, gonna work on file size check and see if I can get that working. If not well we have one that works. I ran the benchmark for the pillow check one like 15 times with no errors lol. |
|
Been playing around with checking filesize and so far no dice. Setting it to check if size is greater than 0 still yields the error, so does 1000 (it's size in bytes). I dont't know if there will be a filesize we can check against that reliably for every image size will get the output. The only way ik of to make sure chafa opens a valid file outside of using the pillow library is to add a sleep of like 0.02, but that drastically increases time and we may as well just wait for the ffmpeg process to finish before doing chafa stuff at that point. |
|
On the bright side this is the result of benchmarking bad apple with multithreading: vs EDIT: redid the commands with fps of 20 fps to match yours on the youtube video |
|
I might have an idea for a more efficient way of doing stuff with detecting when ffmpeg has processed the frame. Hold off on merging this for now, I'll be experimenting with it tomorrow(today but not 4am lol) and I'll get back to you with results |
|
Okay while this new commit adds another dependency in numpy, it allows me to set the ffmpeg process to pipe out raw frame data in which I use numpy and pillow to save to an image file, this allows for chafa to generate a new ascii frame exactly when ffmpeg finishes making one. The times are a lot better too as I can set the png compression level which I have set to 0 for maximum speed This is what the new ffmpeg function looks like so you can check it out without having to search for it in the file itself: and the chafa process: |
|
I think adding these libraries are worth it for cutting the uncached time down from 8 seconds to 2-3 seconds. |
|
For a slight increase in time in exchange for drastically lower video frame file sizes (I had the compression set to 0) we can also set compression to 1 which brought image files of 8.2mb down to like 1.3 This is the time with compression at 0. If you'd prefer this so the image file size is smaller, lmk and I'll push this change. |
|
Sadly couldn't find a way to get it to work with filesize only, and I honestly think this is the least hacky way to do this |
|
@Notenlish I was conferring with someone else about some stuff with this. First suggestion was to add a threadpool. The other one is that there is actually a Chafa python module someone made. If we could have that I think I could reduce time some more as instead of using pil to save the image to png to open with chafa, I think we might be able to just pipe the raw ffmpeg stream into chafa using it, meaning no image would ever need to be saved. So it would either be an extra dependency for efficiency and speed(?) but may still need numpy and PIL. Or it would be able to cut both of those out entirely and the raw ffmpeg frame extraction straight into chafa using it. It's python bindings for the chafa C API which has that capability afaik. |
|
I think both of those could work |
|
@Notenlish As I said in prev pr may not be available for a while. Probs gonna start from scratch with this to re-implement it with the refactor. Ty for your patience. :3 |
2 participants
I added the threading to close: #9
It probably could be a lot better, but it is implemented.
Here's the benchmark output info for my machine:
Threading:
No threading:
Every now and again benchmark.py gives an error on one of the runs to do with the png not being a valid file tho, most likely due to chafa trying to open an image before it can be rendered by ffmpeg. I've not had this issue once running the program normally though so idrk. Could probably fix it by adding a sleep command in somewhere to give ffmpeg more time to process the image before chafa tries to open it. I am tired tho lol so probably won't get that done today.
EDIT:
Nvm think I fixed the race condition between chafa and ffmpeg. Added a 0.02s sleep call at the start of the loop to run the chafa threads.