You can test each of them for a short duration by inserting -t N e.g. filter_complex "amerge" -map 0:v -map "" -c:v libx264 -b:v 4000k -c:a aac -b:a 128k -ac 2 -shortest method3.ts Method 3 Combination of the above ffmpeg -use_wallclock_as_timestamps 1 -i input.dv -f lavfi -use_wallclock_as_timestamps 1 -i "aevalsrc=0:c=2:s=48000" \ filter_complex "amerge" -map 0:v -map "" -c:v libx264 -b:v 4000k -c:a aac -b:a 128k -ac 2 -shortest method2.ts Method 2 Merge with dummy audio ffmpeg -i input.dv -f lavfi -i "aevalsrc=0:c=2:s=48000" \ af "aresample=async=1:first_pts=0" -c:a aac -b:a 128k -fflags +genpts method1.ts Method 1b Use resampler with flag set to inject silence when input audio timestamps have gaps ffmpeg -i input.dv -c:v libx264 -b:v 4000k \ Method 1a Use system time as timestamps ffmpeg -use_wallclock_as_timestamps 1 -i input.dv \ Here are three wildcard attempts at solving this issue: How can I fix this? Is there a way to demux the audio and video with timestamps, so that after conversion they will add up correctly? Or is there anyway to fill these gaps in audio, so that both streams are the same size to begin with? So the more "fragments" are on the tape, the more these differences add up. Whenever I turn the camera on or off (as to start and stop recording) the video starts just a tiny bit faster then the audio. I think I've pinpointed the source of this behaviour. I could just stretch the audio and combine it with the video (I've tested that), but I can't be certain if the audio will be in sync somewhere in the middle of the recording. As I said the differences vary greatly.Īs for the solution. This particular one differs by 1.448 seconds. Estimating duration from bitrate, this may be inaccurate ![]() video_conversion/13.dvįfprobe version 2.8.4 Copyright (c) 2007-2015 the FFmpeg developersĬonfiguration: -prefix=/usr -disable-debug -disable-static -disable-stripping -enable-avisynth -enable-avresample -enable-fontconfig -enable-gnutls -enable-gpl -enable-ladspa -enable-libass -enable-libbluray -enable-libdcadec -enable-libfreetype -enable-libfribidi -enable-libgsm -enable-libmodplug -enable-libmp3lame -enable-libopencore_amrnb -enable-libopencore_amrwb -enable-libopenjpeg -enable-libopus -enable-libpulse -enable-libschroedinger -enable-libsoxr -enable-libspeex -enable-libssh -enable-libtheora -enable-libv4l2 -enable-libvidstab -enable-libvorbis -enable-libvpx -enable-libwebp -enable-libx264 -enable-libx265 -enable-libxvid -enable-shared -enable-version3 -enable-x11grab ![]() Here's an example file that I've split into separate audio and video files to check the differences. ![]() An hour long tape can have between 0.1 and 4 seconds of audio lag at the end. BEFORE you say anything about the sampling frequency - the audio differences are of absolutely random length. It turns out that no matter how I demux it the audio is always out of sync. I thought it's a problem with DVGRAB so I saved the RAW files (which are synced correctly) and wanted to process them with ffmpeg. Saving it to a DVI file resulted in the audio being out of sync. There I had two options: pulling RAW data from the dv tape, resulting in a muxed file OR demuxing it and saving to a DVI file. I've started off with pulling the files to my PC (via firewire) using DVGRAB. I have over 50 DV tapes (from and old Sony camcorder) to be converted to a more modern, usable format (most likely H264). I've been stuck with this problem for months.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |