zzag / plasma5-wallpapers-dynamic

Dynamic wallpaper plugin for KDE Plasma
328 stars 18 forks source link

Builder Assertion failed #135

Closed OWL4C closed 8 months ago

OWL4C commented 8 months ago

running the builder errors out with kdynamicwallpaperbuilder: ./av1/encoder/ratectrl.c:1219: rc_pick_q_and_bounds_no_stats_cbr: Assertionq <= rc->worst_quality && q >= rc->best_quality' failed.` when using both the default Ubuntu Repo version and the 4.4.0 version (IOT instruction (core dumped))

zzag commented 8 months ago

Did you pass any arguments to kdynamicwallpaperbuilder?

OWL4C commented 8 months ago

Didn't matter. No option, only thread count, only speed options, both, always errors.

zzag commented 8 months ago

Can you check that the images have the same resolution?

OWL4C commented 8 months ago

They are all from a timelapse i made myself, and used with a similar tool for macos. Both the conversion and the remaking didn't work.I will append a snippet from my json but i have tried both with specifying the gps with "*" and not passing these arguments (verified that exiftool returns the correct gps). Due to the way i create these scripts, my json uses ' instead of ", maybe that could prove a problem?

OWL4C commented 8 months ago

{"Type": "solar", "Meta": [{"FileName": "P1150679.JPG", "Time": "13:07", "CrossFade": true}, {"FileName": "P1150656.JPG", "Time": "07:22", "CrossFade": true}, ... ]} Paths are truncated but absolute, Time is gotten from exif. It seems this version is actually using double quotes. The pictures are spaced 15 minutes apart and span a total of 96 pictures per set

zzag commented 8 months ago

This is strange. Can you share the source images so I can test whether kdynamicwallpaperbuilder succeeds on my machine? and if not, debug why it fails. You can find my email at profile page.

zzag commented 8 months ago

the source images and the manifest json file*

OWL4C commented 8 months ago

I could reliably get a crash with any picture and 96 entries, while a smaller set works without error. Currently trying to find out where the breaking point is 40 pictures crashes always, 20 only when using --speed 10 This seems to be a limitation of the av1 encoder, it seems to be unable to handle these amounts of data. (Guessing based on the error being from rate-control) Running 40 pictures with a lower speed option works but is slow. Might want to add something into the README about too many files and think about switching to another encoder or JPEG-XL for real. (Or adding compatibility at least.)

zzag commented 8 months ago

Hmm, it might be a bug in the encoder. It would be nice to test with rav1e.

zzag commented 8 months ago

It looks like there's no way to specify the codec via an envvar :(, so I'll add an option in kdynamicwallpaperbuilder. Are you running qt5 or qt6 version?

OWL4C commented 8 months ago

qt5, but since the --speed 1 option is a valid workaround, you could maybe only update the newer version, if that is easier

zzag commented 8 months ago

The linked commit adds a codec option. It can be used as kdynamicwallpaperbuilder --codec rav1e or --codec aom (I believe that's what you use now) or --codec svt.

but since the --speed 1 option is a valid workaround

--speed 0 should produce a file with the minimal size, but it can take a lot of time. Given how many images you have, it might be worth it. It would be a good idea to start with 4 or 5 and see at which point the file size doesn't change that much though.

zzag commented 8 months ago

^ that commits backports --codec option to 4.4. Run git clone https://github.com/zzag/plasma5-wallpapers-dynamic.git --branch 4.4 and then follow the build instructions in README file.

zzag commented 8 months ago

Let me know if rav1e fixes the issue. It's actively maintained and it's written in Rust so it means that it is bug free :smile:

zzag commented 8 months ago

Oh wow, rav1e is actually pretty good. I have a wallpaper that's 180M when encoded by aom, but it's 8M when it's encoded by rav1e and it took less time too.

zzag commented 8 months ago

BTW

{"Type": "solar", "Meta": [{"FileName": "P1150679.JPG", "Time": "13:07", "CrossFade": true}, {"FileName": "P1150656.JPG", "Time": "07:22", "CrossFade": true}, ... ]}

This should be

{
    "Type": "solar",
    "Meta": [
        {
            "FileName": "P1150679.JPG",
            "CrossFade": true,
            "Time": "*",
            "SolarElevation": "*",
            "SolarAzimuth": "*"
        },
        ...
    ]
}

The Time, SolarElevation and SolarAzimuth fields should be initialized based on Exif metadata. You don't need to fill them by hand, kdynamicwallpaperbuilder will do it for you.

OWL4C commented 8 months ago

The branch gives the error symbol lookup error: kdynamicwallpaperbuilder: undefined symbol: _ZN23KDynamicWallpaperWriter12setCodecNameERK7QString when using, the compiling works without errors though. Edit: after purging and reinstalling, rebooting etc it is finally working.

Some observations handling these data sizes: The old image was finally ready (took around 3 hours, 500MB in size) and uses around 1% more CPU in idle than the deer from the examples, as well as consuming around 25% of my cpu for a good few seconds when applied, 10% when changing appearance. Hopefully the new encoder can help that too. On macos the file size was just as big, but integration was far more smooth. That should work out better with the new encoder too. (A quality of life update would be changing the wallpaper to a static version and then updating it to dynamic instead of seeming unresponsive, but usually users would not use these sizes either.)

One last idea would be some kind of progress indicator within the builder tool, currently i can only guess the progress with resource usage. For example a progress bar counting the current picture of the total specified would be great.

Update: using rav1e i could encode the picture (using default options) in just under 1.5 hours. The file size is also ~100 MB smaller.

Thanks for your continued support and even just the project itself!