Speed up video encoding

Question

My task is to create html5 compatible video from input video (.avi, .mov, .mp4, etc.). My understanding is that my output should be .webm or .mp4 (H264 video, aac audio). I use ffmpeg for conversion and it takes a lot of time. I wonder if I could use ffprobe to test if input video is "H264" and "aac" and if so then maybe I could just copy video/audio into output without modifications.

I.e. I have next idea:

1. Get input video info using ffprobe:

ffprobe {input} -v quiet -show_entries stream=codec_name,codec_type -print_format json

The result would be JSON like this:

"streams": [
 {codec_name="mjpeg",codec_type="video"},
 {codec_name="aac",codec_type="audio"}
]

2. If JSON tells that video codec is h264 then I think I could just copy video stream. If JSON tells that audio codec is h264 aac then I think I could just copy audio stream.
3. JSON above tells that my audio is "aac". So I think I could just copy audio stream into ouput video but still needs video stream conversion. For the above example my ffmpeg command would be like:

ffmpeg -i {input} -c:v libx264 -c:a copy ouput.mp4

The question is if I could always use this idea to produce html5 compatible video and if this method will actually speed up video conversion.

Answer 1

The question is if I could always use this idea to produce html5 compatible video

Probably, but some caveats:

• Your output may use H.264 High profile, but your target device may not support that (but that is not too likely now).
• Ensure that the pixel format is yuv420p. If it is not then it may not play and you will have to re-encode with -vf format=yuv420p. You can check with pix_fmt in your -show_entries stream.
• If the file is directly from a video camera, or some other device with inefficient encoding, then the file size may be excessively large for your viewer.
• Add -movflags +faststart to your command so the video can begin playback before the file is completely downloaded.

and if this method will actually speed up video conversion.

Yes, because you're only stream copying (re-muxing) which is fast, and not re-encoding some/all streams which is slow.