Youtube
dobrosketchkun opened this issue · comments
Okay, we need to address the elephant in the room - the intended use of the fvid module - you encode some file and put a video on youtube. In theory, it's okay, but.
If you are to upload a video on youtube it'll change the framerate to 60. So, say, you download the video by using, let say, youtube-dl and try to decode it - if you've used another framerate, you get a different number of images and an error of unzipping.
You can check it yourself - https://www.youtube.com/watch?v=JFL2vSxVzsU (if you don't have youtube-dl or something like this, just change youtube to youtubepp and you will be redirected to some site on which you can download 1080p video)
py -m fvid -i pap_encoded_youtube-1-5.mp4 -d -o pap_decoded.mobi`
<...>
frame= 240 fps=1.5 q=-0.0 Lsize=N/A time=00:00:40.00 bitrate=N/A speed=0.243x
<...>
in the original was 8 frames.
But, if I change a framerate to default 1/5:
ffmpeg -i pap_encoded_youtube.mp4 -filter:v fps=fps=1/5 pap_encoded_youtube-1-5.mp4
and use video instead:
py -m fvid -i pap_encoded_youtube-1-5.mp4 -d -o pap_decoded.mobi
I get a decoded file.
What I propose. Since -f 60 doesn't work, can we change the framerate from 1/5 to 1 in order to somewhat reduce the filesize (I assume 1 will work for any file and system, something like 5 - I don't really now - something like 6 and higher works for some files but not for all) and hardcode it in code and thus getting rid of -f flag.
After that, we add
ffmpeg -i from_youtube.mp4 -filter:v fps=fps=some_frame_rate_we_will_agree_upon temp_file_to_decode.mp4
in code and all will be working as intended.
As background, the fps of 1/5 was chosen to definitively prevent YouTube's compression from corrupting the data. It has been shown by trial and error that a fps of 1/5 works, but a fps of 1 hasn't been thoroughly tested.
But anyway, yes, the intended use of fvid is for storing stuff in YouTube. However, there are other video sharing websites out there that might use a different framerate. I suggest that we change the default framerate to 1 if we can successfully encode/decode at 1 fps, but keep the -f flag for any users of other more obscure streaming services.
Yeah, you are forgetting that you need the video file to be in the framerate it was encoded in order to properly decode it.
So you need to know if some website keeps the framerate or it changes it to 30 or 60 or 120, etc, rendering usage of this module very difficult.
And even if do as you said, weneed to implement this behavior:
ffmpeg -i from_youtube.mp4 -filter:v fps=fps=some_frame_rate_we_will_agree_upon temp_file_to_decode.mp4
into code, or one cannot use youtube either.
Don't we already set ffmpeg to use the -r <framerate> flag, rendering an fps flag useless? Isn't -r a shortcut for fps? If not, can we include the fps in the video file, similar to how the name of the original file is inserted in (the name of the original file is inserted somewhere, otherwise it wouldn't decode into the original file)?
Plus, I was suggesting we offload the responsibility/right of determining the required framerate to the user. We could compile a list of recommended framerates for common sites like youtube, flipgrid, vimeo, etc, but my opinion is that the user should be given as much choice as possible.
Don't we already set ffmpeg to use the
-r <framerate>
Yes, we did, in initial encoding, but I'm talking about decoding. I'm saying if one used a default framerate and upload it on youtube, in order to decode the video resiever need to externally use ffmpeg with whatever flag to change framerate to original and only then use the fvid module again to decode. It is way too complicated and cumbersome for a big chunk of users - this functional should be inside our script.
we offload the responsibility/right of determining the required framerate to the user.
Very destructive idea. Users are specific beings, if you give them a chance to do something wrong, they will do something worng and say we are responsible for this (in a way we are). I'm totaly agree that the user should be given as much choice as possible, but by default, everything must be working out-of-the-box; hence - user should just use minimal funtional on both sides in intended way and it must work without buts.
Ok, so would you find it acceptable to set the default decoding framerate to 60, or 1, or 1/5, or whatever, so it works out-of-the-box for users, but let an advanced user specify the decoding framerate flag with -f <framerate>?
Yeah, of course, this is the best solution (meaning we need yo add framerate changing to the default number into our video-decoding part)
PS I vote for framerate 1; it's a good compromise between working with every file and possibly on every videohosting, and video filesize reduction.