gzip CRC check fails

[duanemoody]

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 <module>
   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/[email protected]/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/[email protected]/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/[email protected]/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.

[Theelx]

That's very interesting. I've never seen that before, I'll start googling for an answer now.

Edit: It seems that according to https://stackoverflow.com/questions/35459354/python-gzip-crc-check-failed, it's caused by corruption or something of the files you're using. Have you tried deleting the file and re-downloading it?

Edit 2: Can you send the corrupted file here so I can test with it?

[Theelx]

@dobrosketchkun As the person who implemented gzip support, do you think that the gzip could become problematic when run through youtube's compression and then redownloaded?

[smileyhogue]

Looks like I have the same issue when uploading, then downloading from youtube as well. Works just fine if I do not upload to youtube

[Theelx]

@smileyhogue Can you send the affected file(s) here so I can test?

Edit: I need the file that has already been uploaded and downloaded form YouTube because I don't want to give Google any more information on me by uploading stuff than I need to.

[Theelx]

Ok, well I just swallowed my pride and uploaded a test file to youtube. When I downloaded with youtube-dl with the -k option on youtube-dl (to keep the original video and the audio files separate), I found that the main .mp4 that had the .m4a audio in it had this CRC error, however decoding just the video worked fine. Test files attached for you guys to try.

Working one:

https://user-images.githubusercontent.com/43764914/108606617-0108cd80-7389-11eb-89cd-13984643f43b.mp4

Not working one:

https://user-images.githubusercontent.com/43764914/108606622-08c87200-7389-11eb-98f2-6d85d3ccbb04.mp4

[pablo-01]

I can confirm similar issue, even with downloading video/audio separately using the -k switch. OSError: CRC check failed 0x3af5c3bd != 0x4c4d5ef

Only happens when using the file downloaded from YouTube.

Link to video: https://youtu.be/YV9dPIdqXC0

Edit:

Link to file before uploading to YouTube: https://github.com/PavKmiec/Helpers/raw/main/Files/Neuromancer.mp4