Switch to H.265 codec

[Theelx]

https://github.com/AlfredoSequeida/fvid/blob/c20c6877d59da1075de473ab0fc17882132b2786/fvid/fvid.py#L317 So in this line, we tell it to use a H.264 codec, but H.265 is supported by Youtube and basically any other video file sharing/storing service. H.265 allows the resulting file to be much smaller in size, however it won't be able to decode any previously-encoded H.264 files. I propose we either:

• add an -h265 flag allowing users to encode/decode with that
• make the code try h265 first and default back to libx264rbg if that doesn't work
• or, bump fvid to 2.0.0 when/if this is done to signify that h264 encoded videos won't be decodable anymore

Thoughts? I'm learning towards the second option.

[Theelx]

References: https://www.videoconverterfactory.com/tips/h265vsh264.html https://trac.ffmpeg.org/wiki/Encode/H.265 https://support.google.com/youtube/troubleshooter/2888402

[Theelx]

Update: Just encoded one of my test images, 580KB, with libx265 and the resulting file.mp4 about 31MB, compared to 123MB with libx264rgb.

Update 2: Apparently I accidentally made it lossy, so I passed a lossless option, and now it's 63MB. Still better though, and it only takes 15 seconds to encode.

Update 3: WOW. Apparently, since libx265 isn't rgb, each pixel is a simple integer rather than a tuple of 3 integers, so we can massively simplify the decoding process. Decoding the pixels is now over 3x faster than it was in pure Python, and the speedups are probably almost as large in Cython.

[AlfredoSequeida]

Oh wow, this is cool! I'm not very experienced with video codecs, so I didn't even know there was a better option. I think this is a good idea. What happens if the program was to "try h265 first and default back to libx264rbg"? Does FFmpeg fail and quit by default when libx264rbg fails?

[Theelx]

So yeah, ffmpeg would fail when it tries to decode a file with the wrong mime type. I'm not totally sure how to catch that fail, but I'm confident it could be done.

Edit: Fun fact: There's actually a newer, even better format called H.266, or VCC, but it was only standardized in July 2020, so not enough implementations yet for ffmpeg to use it.

[AlfredoSequeida]

Yesterday I was working on a project using a program called mediainfo to view file metadata on Linux. Looking up their project, it looks like it also supports mac and windows and we could use it to view video data like a codec and therefore make fvid support virtually any codec by reading that info prior to decoding. I'm willing to bet that ffprobe can do the same thing. If I get some time today I could look into that, but anyone else that is curious can try it too.

[Theelx]

@AlfredoSequeida That's a possibility. I think it'd be better to just add an option for a user to be able to specify the codec they want that ffmpeg supports though.

[Theelx]

Do you mind if I merge zfec error correction and a flag for using H265 into master? (I did the H265 flag yesterday)

[AlfredoSequeida]

@Theelgirl I'm definitely ok with the H265 flag and I think that zfec should be good too (good job on that by the way). My only concern about zfec is that with the current zip issue, which I haven't had time to look at, I haven't seen a successful decode form a compressed vid (like from YouTube). So we just have to remember to fix that before pushing out the next version to PyPI.

[Theelx]

Sounds good.