gzip CRC check fails

fvid installed through pip3 to bring along dependencies.

Test file: 9.1Mb Photoshop document. Successfully encoded with fvid, uploaded to YouTube, downloaded with ytdl, then run through fvid's decoder. After seeing `Bits are in place`, fvid unpacks the frames 100%, but:
```
Unziping...

Traceback (most recent call last):

File "/usr/local/bin/fvid", line 8, in
sys.exit(main())
File "/usr/local/lib/python3.9/site-packages/fvid/fvid.py", line 274, in main
save_bits_to_file(file_path, bits, key)
File "/usr/local/lib/python3.9/site-packages/fvid/fvid.py", line 144, in save_bits_to_file
bitstring = fo.read()
File "/usr/local/Cellar/python@3.9/3.9.1_8/Frameworks/Python.framework/Versions/3.9/lib/python3.9/gzip.py", line 300, in read
return self._buffer.read(size)
File "/usr/local/Cellar/python@3.9/3.9.1_8/Frameworks/Python.framework/Versions/3.9/lib/python3.9/gzip.py", line 478, in read
self._read_eof()
File "/usr/local/Cellar/python@3.9/3.9.1_8/Frameworks/Python.framework/Versions/3.9/lib/python3.9/gzip.py", line 524, in _read_eof
raise BadGzipFile("CRC check failed %s != %s" % (hex(crc32),
gzip.BadGzipFile: CRC check failed 0xebd7fa1e != 0xc3ae18db
```

I notice that regardless of the command syntax, fvid run multiple times on the same input file generates MP4s of consistently varying byte counts suggesting the algorithm or one of the modules it depends on is flaky. This is consistent across the following syntaxes:
```
fvid -ei filename.ext
fvid --encode -i filename.ext
fvid -i filename.ext -e
```
file.mp4 came out as lengths of 159,351,426; 159,351,436; 159,351,435; 159,351,433 and the resulting downloaded YT videos had similar variances.