Closed adamhewitt627 closed 1 year ago
What do you mean by "official release build"? There are no official builds.
Is this based on libvidstab? I have no experience with that set of filters, and thus having a hard time making sense of your report. Can you try to explain the issue a bit more?
Looks like I mean the Gyan builds - I don't remember if I used Choco or Winget to install it.
It is based on libvidstab
, but it seems that there is a difference in your build configuration with how that gets pulled in. (Stretching my knowledge of C/C++ and how 3rd party code gets compiled in here)
Documentation and examples show that using the filter is simply:
> ffmpeg -i "input-file.mp4" -vf "vidstabdetect" -f "null" "-"
# vidstabdetect creates a TRF file, consumed here to create an output
> ffmpeg -i "input-file.mp4" -vf "vidstabtransform" "output-file.mp4"
Looking at https://github.com/georgmartius/vid.stab/blob/master/src/serialize.c, it seems like it can produce either binary or text output. Both are perfectly valid though, and understood just fine by it when reading the file back on. So while a bit curious that it differs between builds (maybe gyan uses an older version of libvidstab, and the default was changed at some point?), it should not cause any issues.
It even explicitly defaults to the binary serialization mode if it's unset (and ffmpeg never sets it): https://github.com/georgmartius/vid.stab/blob/master/src/motiondetect.c#L111
So I don't really see how it'd ever end up in text-serialization mode. Is there an entirely different libvidstab out there somewhere, with a compatible API?
It must relate back to this commit: https://github.com/georgmartius/vid.stab/commit/9d9066dcac6edfc3724d417e3522a747590c706a Pre v1.1.1 (Which advertises itself as v1.2.0 for some reason?!), selecting the serialization format was a compile time option, but even that defaulted to binary. So the only way I see how Gyans builds could end up with the text output would be if he was a) using an outdated version of libvidstab (1.1.0 or older) and manually opted to configure it for text output.
In any case, it's not an issue, just a different serialization method (if you think it is one for some reason, you need to raise it in ffmpeg trac, so it can select text output again at runtime).
Or are you having any actual issue, other than the file format being different?
Sounds like you're right, and I found this one also related: https://github.com/georgmartius/vid.stab/issues/104
I opened it here since this environment was the one broken, but looks like it's not in your control. Thank you for the help!
I'm still trying to understand what exactly is broken. Are you facing any issues with the binary format, other than it not being human readable in a text editor? Does reading it back in not work?
I think vidstab in the BtbN builds is failing to read it back in, but also sounds like a known bug with vidstab. I'm not sure why gyan would be writing it as text, but it looks like that's what is side-stepping the vidstab bug.
In that case please open a bug in ffmpeg trac. FFmpeg might have to manually request the text format. The filter does look like it's expecting a text file, given it uses a utf8-specific fopen function.
I patch vidstab to force it to write ASCII since the 2nd stage filter fopen is U8. I'll submit a patch in a few days to make it configurable inside the filters.
I am attempting to use the
vidstabdetect
/vidstabtransform
filters.transforms.trf
file is binary data (screenshot attached) while the official release build produces a valid text file.vidstabtransform
fails.vidstabtransform
works on both builds - as long as the TRF is the text instead of the (corrupted?) binary.@BtbN output
Official build output