5 ms·

Part of why this took so long is probably the author's unfamiliarity in working with video. >For example, I captured video from 20 tapes before realizing that

Part of why this took so long is probably the author's unfamiliarity in working with video. >For example, I captured video from 20 tapes before realizing that the audio was slightly out of sync. Or I discovered after weeks of editing that I’d been exporting video in a format that doesn’t support online streaming. Both of these are fixable with some ffmpeg incantations.

mtlynch 6y ago
>Both of these are fixable with some ffmpeg incantations. I knew that I could re-encode for web streaming, but doesn't each re-encode degrade quality? I didn't realize that I could have fixed the audio issues with ffmpeg, though.
- klodolph 6y ago
  So… if you’re archiving, you’d normally make one high-quality master copy and then create the lower-quality streaming versions from that. Unfortunately, there are often reasons that you’d want multiple versions for streaming. You also don’t always need to re-encode for streaming. It depends on why the format couldn’t stream in the first place. If you use the wrong container format for streaming (like you create an MKV file), then you can use -codec:v copy -codec:a copy and you’re not re-encoding anything. On the other hand, if you got a yuv444 and you need yuv420 for streaming, that requires re-encoding.
- blibble 6y ago
  no need to re-encode the video if you're only manipulating the audio, and audio is so small compared to video you could just have it lossless (or effectively lossless) amusing I made the same mistake when batch digitising tapes, did about 20 before realising the audio was out of sync
- rom16384 6y ago
  In this case you could have used mp4box [1] to fix the audio synchronization without re-encoding. [1] https://github.com/gpac/gpac/wiki/MP4Box https://github.com/gpac/gpac/wiki/MP4Box
  - mtlynch 6y ago
    I've never seen this utility before. Thanks for the pointer!
- parliament32 6y ago
  >doesn't each re-encode degrade quality Sometimes, it depends on what you were transcoding between in the previous steps, but it most likely doesn't matter because your original consumer-handheld-camera-and-cheap-tapes quality was trash anyway. Like another commenter mentioned, in cases like this you'd want one high-quality archive export, then transcode to one or a few lossy formats for ease of streaming. You'd fix the audio drift by changing the sample rate of the audio stream with asetrate: https://ffmpeg.org/ffmpeg-filters.html#asetrate https://ffmpeg.org/ffmpeg-filters.html#asetrate (or you could change the framerate of the video, either way)
- fomine3 6y ago
  FYI: "-vcodec copy -acodec copy"
klodolph 6y ago
That’s true, but FFmpeg is a bit of a beast and the normal way to use it for anything but the most basic stuff is “post a question online and see if somebody answers with an FFmpeg command-line I can copy and paste”.
- jlarocco 6y ago
  Why do it yourself if you want to avoid learning how? ffmpeg has documentation, and people actually read it and learn to use it...
  - klodolph 6y ago
    You’re asking the wrong person. I’m describing how most people use FFmpeg. It’s easy to forget how frustrating it is to figure out what you want to do with FFmpeg just from reading the docs.

mtlynch 6y ago

>Both of these are fixable with some ffmpeg incantations. I knew that I could re-encode for web streaming, but doesn't each re-encode degrade quality? I didn't realize that I could have fixed the audio issues with ffmpeg, though.

klodolph 6y ago
So… if you’re archiving, you’d normally make one high-quality master copy and then create the lower-quality streaming versions from that. Unfortunately, there are often reasons that you’d want multiple versions for streaming. You also don’t always need to re-encode for streaming. It depends on why the format couldn’t stream in the first place. If you use the wrong container format for streaming (like you create an MKV file), then you can use -codec:v copy -codec:a copy and you’re not re-encoding anything. On the other hand, if you got a yuv444 and you need yuv420 for streaming, that requires re-encoding.
blibble 6y ago
no need to re-encode the video if you're only manipulating the audio, and audio is so small compared to video you could just have it lossless (or effectively lossless) amusing I made the same mistake when batch digitising tapes, did about 20 before realising the audio was out of sync
rom16384 6y ago
In this case you could have used mp4box [1] to fix the audio synchronization without re-encoding. [1] https://github.com/gpac/gpac/wiki/MP4Box https://github.com/gpac/gpac/wiki/MP4Box
- mtlynch 6y ago
  I've never seen this utility before. Thanks for the pointer!
parliament32 6y ago
>doesn't each re-encode degrade quality Sometimes, it depends on what you were transcoding between in the previous steps, but it most likely doesn't matter because your original consumer-handheld-camera-and-cheap-tapes quality was trash anyway. Like another commenter mentioned, in cases like this you'd want one high-quality archive export, then transcode to one or a few lossy formats for ease of streaming. You'd fix the audio drift by changing the sample rate of the audio stream with asetrate: https://ffmpeg.org/ffmpeg-filters.html#asetrate https://ffmpeg.org/ffmpeg-filters.html#asetrate (or you could change the framerate of the video, either way)
fomine3 6y ago
FYI: "-vcodec copy -acodec copy"

klodolph 6y ago

That’s true, but FFmpeg is a bit of a beast and the normal way to use it for anything but the most basic stuff is “post a question online and see if somebody answers with an FFmpeg command-line I can copy and paste”.

jlarocco 6y ago
Why do it yourself if you want to avoid learning how? ffmpeg has documentation, and people actually read it and learn to use it...
- klodolph 6y ago
  You’re asking the wrong person. I’m describing how most people use FFmpeg. It’s easy to forget how frustrating it is to figure out what you want to do with FFmpeg just from reading the docs.