-
-
Notifications
You must be signed in to change notification settings - Fork 951
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
Real lossless ugoira #1550
Real lossless ugoira #1550
Conversation
Don't use I don't think VP9 encoding with the |
Okay. Forgot the imagehash. But I cannot find an easy way to prove a resulted webm file is really lossless. Even if it is, there is no benefit. Just wasting time and get a larger file.
|
Just disable
Not everyone would want a mkv/mp4 file, but as an additional option why not I guess. |
By the way, you can expand this is issue to not only about video quality but also preserving the original ugoira timings, because FFmpeg has a problem with it. But you have to use mkvmerge for it. |
Without This doesn't apply when using
It most likely does, but some players can't play a yuvj444p video. |
Have you tried |
mkvmerge seems like not designed for merging images to a video. Maybe I should wait for the problem of ffmpeg to be fixed. I think |
You can make mkv with FFmpeg, then use mkvmerge to fix timecodes, mkvmerge doesn't re-encode video in this case afaik.
This problem seems to be quiet old, but barely anyone noticed it. I reported it to FFmpeg devs recently but most likely it can take them very long to do something about it. Just like this issue with duplicating the last frame.
|
I checked the |
Ok, I tested some random ugoira which had 20ms duration on all frames without
Timestamp roundings are happening on the input stream, not output, so setting output fps to 999 or anything else won't really help. |
You are right. I tested it. Nothing changed. |
I think I found a workaround for this issue. @mikf
You definitely shouldn't put I only tested it for webm format, and it was fine with those ugoiras I tested, but I'm not sure yet this can be stable. |
So I tested your workaround and it works perfectly for VP8/VP9 videos, but not at all for basically anything else. It doesn't work with
Could you explain why this is bad? It works perfectly fine for ugoira with constant frame delay, i.e. the frame timestamps from For ugoira with more than one frame delay value, the current strategy puts -r after -i and the frame timestamps with that are all over the place. And just for reference, here is Danbooru's ugoira-to-webm code: It generates a |
Well, yes,
Are you sure? Honesly, I'm not that good in FFmpeg filters, so can't say much about it, maybe it just needs to be formatted appropriately.
You mean
It was meant for my workaround. We simply don't need to put Without my workaround you can leave it as it is. Earlier I said that you don't need to put
Yes, as long as frame delays are constant it works perfectly fine, but as I said it's not always the case.
I suggested using
The danbooru code is quiet old. With current mkvmerge you don't need to duplicate the last frame, I tested it. |
Just in case you guys haven't seen it yet, it might be worth taking a look at how PixivUtil2 does it: https://github.com/Nandaka/PixivUtil2/blob/c3207e105ae9b5050888338543f04604fe3ca352/PixivHelper.py#L943 |
I've seen it. Nothing really useful tbh. Mostly it's the same as gallery-dl and has the same issue with timecodes. I think I kinda went off-topic in this pull request. Should I open it as issue instead? |
Ensures exact frame timecodes with no duplicate frames. Possible issues are the duration the last frame in an Ugoira with variable frame durations is shown and insufficient timestamp precision of the underlying file system (e.g. FAT32, ext3; works on ext4, tmpfs, NTFS).
I believe I found a method to get accurate timecodes with only FFmpeg: the The only remaining issue is the display time of the last frame in a variable-delay Ugoira. Ugoira with constant delays don't "require" duplicating the last frame with this method. (I've also added the Concerning this PR @fmnijk: Keep the changes in |
Ah. Well, I knew about Have you tested it? Also, on this line there's only |
Yes, it works really well on Linux.
Never seen one where the frames aren't
This is only when using the |
https://www.pixiv.net/en/artworks/44663338 This is what I'm testing. Latest build from Actions Made the Testing the
No idea what's the problem. Is it Windows or FFmpeg itself |
Sounds like the same underlying issue I touched in my post above. The last frame only gets shown for 1/fps seconds, and fps gets calculated as 1/GCD of all frame delays. Works for constant framerates, but is usually too short for variable framerates.
Its FFmpeg. In Python |
I did another tests and it looks like not only
That sucks. So many problems with FFmpeg. Well, you still can implement my solution from the post above (#1550 (comment)), make it optional and use it for webm. |
'image2' with nanasecond mtime timestamps doesn't work on Windows
I tried But some video renderer might not keep the duration of the last frame. |
mkvmerge does have a python wrapper, but, as stated in the README, the current documentation is a bit sparse. |
by selecting the "mkvmerge" demuxer (#1550)
I used the "--ugoira-conv-lossless" argument to generated lossless webm file.
But the framehash values calculated by ffmpeg framehash muxer are different to original jpg files in zip file.
So I add a "--ugoira-conv-copy" argument.
It used the method in the accepted answer of here.
Compared to "--ugoira-conv-lossless" argument, the resulted file is smaller and the conversion is faster.
I also add a "repeat-last-frame" option in ugoira.py.