[Bug] Output file on decoding is always "file.bin"
ThatIsAPseudo opened this issue · comments
Whenever I run this script to decode a video it generated, the output file is file.bin. I tried renaming the extension to match the original file I encoded but it didn't work. Morevover, this file.bin is lighter than the original file.
I've noticed this as well. The file.bin is def a bug. Also, I believe the file is smaller as it looses some encoding information as well as metadata.
@ThatIsAPseudo So I have actually seen this as well. The reason this happens has to do with magic or mimetypes. Basically, either minetypes or magic is having trouble identifying the file and therefore the file extension is incorrect. Link me to the file and I can do some testing.
The interesting thing with this project is that unless we have a reference file we can't know what is going on since every file is going to behave different.
Well I tested with a bunch of files and several filetypes (zip, 7z, jpg, csv, pdf), none of them worked so I assume it isn't the issue.
However I agree with the fact that we should have a common test file. We can use classic standard test images, such as Lenna :
Type : png
MD5 : 814a0034f5549e957ee61360d87457e5
SHA1 : 3ee0d360dc12003c0d43e3579295b52b64906e85
SHA256 : 7e497501a28bcf9a353ccadf6eb9216bf098ac32888fb542fb9bfe71d486761f
Edit : this image did not work for me, it gave me the same file.bin.
@ThatIsAPseudo I tried the Lenna picture and it worked fine for me and the md5sums match. I got a file.png when I decoded the video. One thing to note - later today or tomorrow I will be adding a check that asks to replace files or generates unique file names. As of now, if you have another file.mp4 in the same directory you are running fvid from, fvid will not run because the ffmpeg output is being hidden (and ffmpeg will not replace the file automatically). If that is the cause I would suggest you check for that and try again.
Other than that if you're using the latest version 0.0.2 and its still not working I would assume its an issue with the installation of dependencies or something else.
Here is the output in case you want to try decoding it:
Let me know how it goes.
Edit: Actually I think I might be wrong, after decoding from the YT video I got the same thing you are describing, but it works from the file (before uploading to YT). so that tells me YT is compressing it in some way that was unexpected. I will take a look at the decoding algorithm and see what's happening there.
This is good because I had not found a file that had not worked before. Thank you!
@ThatIsAPseudo Actually upon further inspection, this morning I woke up to work on this bug and realized that yesterday the reason it didn't work for me was that I was actually trying to decode the original image file instead of the video lol. This morning it worked fine.
[alfredo@DARTHNET test]$ ls
'Lenna_(test_image).png' 'Lenna_(test_image).png-d1t-9Pp741k.mp4'
[alfredo@DARTHNET test]$ fvid -i Lenna_(test_image).png-d1t-9Pp741k.mp4 -d
Getting bits from frame: 100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 1080/1080 [00:36<00:00, 29.92it/s]
Getting bits from frame: 82%|█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████▎ | 891/1080 [00:29<00:06, 30.68it/s]
[alfredo@DARTHNET test]$ ls
file.png 'Lenna_(test_image).png' 'Lenna_(test_image).png-d1t-9Pp741k.mp4'
[alfredo@DARTHNET test]$ md5sum file.png
814a0034f5549e957ee61360d87457e5 file.png
[alfredo@DARTHNET test]$ sha1sum file.png
3ee0d360dc12003c0d43e3579295b52b64906e85 file.png
[alfredo@DARTHNET test]$ sha256sum file.png
7e497501a28bcf9a353ccadf6eb9216bf098ac32888fb542fb9bfe71d486761f file.png
all sums match.
I would suggest and see if you were not doing the same thing.
Let me know if you are still having issues.
That is not my problem, I keep getting file.bin when I try to use fvid :
Edit: I renamed Lenna to Lenna_original cause I thought it could be a problem if fvid tried to output a png file with the same name.
(fvid) ╭─ThatIsAPseudo@Computer ~/Downloads/fvid_tests
╰─$ ls
Lenna.png
(fvid) ╭─ThatIsAPseudo@Computer ~/Downloads/fvid_tests
╰─$ fvid -i Lenna.png -e
(fvid) ╭─ThatIsAPseudo@Computer ~/Downloads/fvid_tests
╰─$ ls
Lenna.png file.mp4
(fvid) ╭─ThatIsAPseudo@Computer ~/Downloads/fvid_tests
╰─$ mv Lenna.png Lenna_original.png
(fvid) ╭─ThatIsAPseudo@Computer ~/Downloads/fvid_tests
╰─$ ls
Lenna_original.png file.mp4
(fvid) ╭─ThatIsAPseudo@Computer ~/Downloads/fvid_tests
╰─$ fvid -i file.mp4 -d
Getting bits from frame: 83%|██████████████████████████▍ | 894/1080 [01:07<00:14, 13.23it/s]
(fvid) ╭─ThatIsAPseudo@Computer ~/Downloads/fvid_tests
╰─$ ls
Lenna_original.png file.bin file.mp4
I'm having this issue as well.
@ThatIsAPseudo Interesting, did you cut the output short? I see that Getting bits from frame stops at 83%. When I encoded the Lenna image I had a total of 2 frames so if you see my output I have two loading bars. The first one finishes (meaning one whole frame was processed) and the second one stops at 82% (because if you look at my YT upload, the second frame does not cover the full height of the 1920x1080 frame).
That makes me think that maybe your copy of the program is either not encoding the full video or not getting all the frames from the encoded video.
A simple test might be to download the video I uploaded and run that so we can see if the issue is with the encoding or decoding.
@KasperSvendsenGit Maybe try the same thing I just suggested to see if anything changes for you. On my end its working fine. @ThatIsAPseudo Something else that I can think might be the issue is maybe one of the dependencies is not working. Either ffmpeg or libmagic.
Thank you guys for pointing out these issues, it's really helpful and interesting to see how other people are experiencing different things. Also, the program keeps changing pretty rapidly since people are contributing to the code base, so even though those parts of the program have not changed much, it might be helpful to make sure you're on the latest git version, which is currently ahead of the PyPi version.
You can download/clone the repo, navigate to the program downloaded directory (unzip if necessary), and install that like this:
pip3 install .
@ThatIsAPseudo Interesting, did you cut the output short?
No I did not, but I noticed the difference of loading bar length as well.
I just tried with the video you uploaded on PyPi version of fvid, and it did not work either. (I also still have a single 83% loading bar instead of 2 like you)
I'll try again with the git repo version to see if that works better.
Edit:
Did not work after cloning the git repo.
Btw the md5sum of the file.mp4 fvid encoded is edf2817a19069556110faa3c2371298d, so that might help you see if the encoding part is ok.
@ThatIsAPseudo What operating system are you using it on? I was just able to replicate your results using a 2019 MacBook Pro running macOS Mojave. In this case I think the issue was numpy because I was having trouble installing it and followed some instructions on GitHub for a different repo where they had the same runtime error I was getting when trying to use numpy.
What operating system are you using it on?
I'm using macOS Big Sur Beta 9. I did not notice any issue regarding numpy though, but I may be able to run some tests if this helps you narrow down the exact cause of the problem
@ThatIsAPseudo can you put the output of python -m pip list in a comment so we can see what versions of the libraries you are running? Here is the output of mine for this project:
Package Version
------------- -------
bitstring 3.1.7
ffmpeg-python 0.2.0
future 0.18.2
numpy 1.19.2
Pillow 7.2.0
pip 20.1.1
python-magic 0.4.18
setuptools 47.1.0
tqdm 4.50.1
Also, just for kicks python --version
╰─$ python --version
Python 3.8.6
╰─$ python -m pip list
Package Version
------------- -------------------
bitstring 3.1.7
certifi 2020.6.20
ffmpeg-python 0.2.0
future 0.18.2
fvid 0.0.2
numpy 1.19.2
Pillow 7.2.0
pip 20.2.3
python-magic 0.4.18
setuptools 49.6.0.post20200917
tqdm 4.50.1
wheel 0.35.1
All looks normal to me. How about the output of:
ffmpeg -version
and
ls /usr/local/Cellar/libmagic
ffmpeg version 4.3.1 Copyright (c) 2000-2020 the FFmpeg developers
built with Apple clang version 11.0.3 (clang-1103.0.32.62)
configuration: --prefix=/usr/local/Cellar/ffmpeg/4.3.1_1 --enable-shared --enable-pthreads --enable-version3 --enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libbluray --enable-libdav1d --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librubberband --enable-libsnappy --enable-libsrt --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librtmp --enable-libspeex --enable-libsoxr --enable-videotoolbox --disable-libjack --disable-indev=jack
libavutil 56. 51.100 / 56. 51.100
libavcodec 58. 91.100 / 58. 91.100
libavformat 58. 45.100 / 58. 45.100
libavdevice 58. 10.100 / 58. 10.100
libavfilter 7. 85.100 / 7. 85.100
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 7.100 / 5. 7.100
libswresample 3. 7.100 / 3. 7.100
libpostproc 55. 7.100 / 55. 7.100
╰─$ ls /usr/local/Cellar/libmagic
5.39
@ThatIsAPseudo wow I was expecting to find something you had missed but looks like we are in the same boat. I hadn't tried with the most recent build yet but it seems the framerate functionality is causing issues.
@AlfredoSequeida Here is what I am seeing. With the 0.0.2 version running fvid with the following flags: -i test/Lana.png -e I am getting an output video that is 10 seconds long and all black.
Running it with the new flag -f 1/5 the program hangs. I think the issue is ffmpeg on macos may have a different api for changing the framerate or the API might work differently.
I went back to test with v0.0.1 and confirmed it is working on that version.
@AlfredoSequeida I think its the framerate tag. It seems the framerate flag is only supposed to be used with whole number integers per their documentation here:
https://ffmpeg.org/ffmpeg.html#toc-X11-grabbing
The -enc_time_base seems to be the only one that accepts the 1/framerate argument.
What the difference is I am not certain but I believe that is the issue.
@dtaivpp Well I will make tests again, but I did try to manually change the framerate to 1, 5, 30, 60 directly in the script (all whole numbers), and it did not work either...
But I may be mistaking so I'll test it again and tell you what I get.
I decided to sleep in today, but I'm glad you guys are so active on the topic. As of now, I have only been able to replicate the issue on macOS, and I believe @dtaivpp is also running it on macOS, so I think it must be some specific difference with regards to that, today I will put some time to look over the code and try to find out what is really going on.
@AlfredoSequeida go to bed. Ill see if I can find anything in the meantime
I can replicate on Windows and Ubuntu 20.04. I can say with 95% certainty that the issue is with mimetypes. Put these lines in your save_bits_to_file function and you'll see what I mean:
import io # put imports at top of file
import magic # put imports at top of file
extension = magic.from_buffer(io.BytesIO(bits.encode('utf-8')).read(1024), mime=True)
bitstring = Bits(bin=bits)
mime = Magic(mime=True)
mime_type = mime.from_buffer(bitstring.tobytes())
print(extension, "|", mime_type, "|" mimetypes.guess_extension(type=mime_type))Edit: You'll get this:
text/plain | application/octet-stream | .bin
Clearly, it thinks we're decoding either plain text or binary, so something is up.
Edit 2: The first thing that produces text/plain is just for show, it won't actually be useful. When I decode an mp4 of a jpg image though, it works fine, so could it be the png file format?
@Theelgirl I do think the file.bin issue is with mimetypes. I think we may need to break these out into two issues though. Macos right now cannot encode files that require more than one frame. If it takes on frame it works fine but anything past that fails. For example right now the output of Lana for me is a 10 second video with all black frames.
Edit* for both 0.0.1 and 0.0.2 multi frame encoding isn't working. I'm exploring to see what it may be.
@dtaivpp I think I may have monkey-patched us a temporary fix for file.bin assuming users don't get curious and change file extensions, and can always see the file names themselves. I made it so that the mp4s generated are in the format file.png.mp4 or file.jpg.mp4 (depending on the original extension of the image) instead of file.mp4. This allows the script to parse the file when the user inputs it for decoding, and take the original file extension by splitting at periods. The big problem that I forsee with this is that the filenames written upon encoding are different from the user-specified one in that they have the original extension inserted in, however I think we can glob a fix around that for unix, if not windows.
@Theelgirl that makes sense to me. Put in a PR for that jazz and hopefully Alfredo can merge it tomorrow.
I have a few leads on why it may not be working for Macos users as well. Seems ffmpeg on mac is both opinionated on the positioning of arguments and makes several assumptions unlike its unix and windows counterparts. Testing some different configs now.
Ok, got it, I'll submit a PR now. I got a simple file guesser working for Ubuntu for in case the user decides to strip out the extra file extensions, hopefully it works in Windows and MacOS also.
I just want to let you guys know that I definitely see your work and it does not go unappreciated - I have just had a busy couple of days with school stuff, but as soon as I have some time I will go through all of this. Thank you!
@ThatIsAPseudo This should be fixed with the most recent version, which rewrote parts of the mechanisms by which files were decoded. I merged it on github, so now we just need @AlfredoSequeida to release it to PyPi, then you can simply update with pip install -U fvid and let us know if it actually is fixed. For now though, you can install it off github with pip install git+https://github.com/AlfredoSequeida/fvid.git#egg=fvid and test it.
I just tried (sorry for the delay), I wipped my install then reinstalled everything and it works perfectly !