Inconsistent audio sync, capturing with V4L2 and PulseAudio
Not sure what's going on here but I can't seem to get consistent audio sync capturing from HDMI with ffmpeg. I can get consistent results from OBS no problem (video is always 100ms or thereabouts ahead), even though I have everything set up the same on there, but OBS on Linux does not allow for the input colour range to be changed. This is a known issue that doesn't look like it'll get fixed any time soon. So unless I stick with limited range video, OBS is not the preferable option. OBS does support custom ffmpeg settings, but these appear to only affect the output, which already supports full range anyway. I would like to know what OBS is doing with ffmpeg under the hood but I've not found a way of viewing this.
A big chunk of my command is irrelevant to the issue but best include it all. I was previously using ALSA, but for the sake of consistency with OBS I've switched to Pulse. Behaviour seems similar. I can attempt to sync it up with -itsoffset, but as soon as I've managed to get the sync close it'll already be way off again. The audio sounds fine, and the output sample rate of 48kHz matches with the input. I've also thrown both -vsync, -async and -force_key_frames at it as others have suggested online for these things.
ffmpeg -hide_banner -f pulse -async 1 -i default -itsoffset 0 -f v4l2 -vsync 1 -i /dev/video0 -force_key_frames 0 -pix_fmt yuv420p -src_range 1 -dst_range 1 -color_range 2 -framerate 60 -r 60 -video_size 1920x1080 -vf setpts="(PTS-STARTPTS)" -c:v libx264 -c:a flac -crf 12 -dn -sn -map_metadata -1 -preset veryfast -f matroska capture.mkv
Here's my log from letting an effectively identical command run for 26 seconds. It doesn't look too good but I'm not sure what it means:
https://gofile.io/?c=nEHyj3
As suggested by Xtoforas on Reddit, I have tried using -use_wallclock_as_timestamps 1 and -copyts, but I saw no improvement with -use_wallclock_as_timestamps 1 and -copyts broke the audio, and probably isn't what I want anyway.
linux audio video ffmpeg sync
asked Feb 5 at 17:16
spacer GIFspacer GIF
1012
add a comment |
Not sure what's going on here but I can't seem to get consistent audio sync capturing from HDMI with ffmpeg. I can get consistent results from OBS no problem (video is always 100ms or thereabouts ahead), even though I have everything set up the same on there, but OBS on Linux does not allow for the input colour range to be changed. This is a known issue that doesn't look like it'll get fixed any time soon. So unless I stick with limited range video, OBS is not the preferable option. OBS does support custom ffmpeg settings, but these appear to only affect the output, which already supports full range anyway. I would like to know what OBS is doing with ffmpeg under the hood but I've not found a way of viewing this.
A big chunk of my command is irrelevant to the issue but best include it all. I was previously using ALSA, but for the sake of consistency with OBS I've switched to Pulse. Behaviour seems similar. I can attempt to sync it up with -itsoffset, but as soon as I've managed to get the sync close it'll already be way off again. The audio sounds fine, and the output sample rate of 48kHz matches with the input. I've also thrown both -vsync, -async and -force_key_frames at it as others have suggested online for these things.
ffmpeg -hide_banner -f pulse -async 1 -i default -itsoffset 0 -f v4l2 -vsync 1 -i /dev/video0 -force_key_frames 0 -pix_fmt yuv420p -src_range 1 -dst_range 1 -color_range 2 -framerate 60 -r 60 -video_size 1920x1080 -vf setpts="(PTS-STARTPTS)" -c:v libx264 -c:a flac -crf 12 -dn -sn -map_metadata -1 -preset veryfast -f matroska capture.mkv
Here's my log from letting an effectively identical command run for 26 seconds. It doesn't look too good but I'm not sure what it means:
https://gofile.io/?c=nEHyj3
As suggested by Xtoforas on Reddit, I have tried using -use_wallclock_as_timestamps 1 and -copyts, but I saw no improvement with -use_wallclock_as_timestamps 1 and -copyts broke the audio, and probably isn't what I want anyway.
linux audio video ffmpeg sync
asked Feb 5 at 17:16
spacer GIFspacer GIF
1012
Remove the async and vsync. and add-af aresample=async=1,asetpts=PTS-STARTPTS.
– Gyan
Feb 5 at 17:44
Your logs show corrupted input video packets - that may contribute to a desync. BTW, we can change the color range flag of H264 streams without re-encoding.
– Gyan
Feb 5 at 17:46
@Gyan I've tried that now and it's still the same, possibly even worse. Five minutes of tinkering with it and the audiosync is already 20 seconds out. This is no use.
– spacer GIF
Feb 6 at 16:27
add a comment |
Not sure what's going on here but I can't seem to get consistent audio sync capturing from HDMI with ffmpeg. I can get consistent results from OBS no problem (video is always 100ms or thereabouts ahead), even though I have everything set up the same on there, but OBS on Linux does not allow for the input colour range to be changed. This is a known issue that doesn't look like it'll get fixed any time soon. So unless I stick with limited range video, OBS is not the preferable option. OBS does support custom ffmpeg settings, but these appear to only affect the output, which already supports full range anyway. I would like to know what OBS is doing with ffmpeg under the hood but I've not found a way of viewing this.
A big chunk of my command is irrelevant to the issue but best include it all. I was previously using ALSA, but for the sake of consistency with OBS I've switched to Pulse. Behaviour seems similar. I can attempt to sync it up with -itsoffset, but as soon as I've managed to get the sync close it'll already be way off again. The audio sounds fine, and the output sample rate of 48kHz matches with the input. I've also thrown both -vsync, -async and -force_key_frames at it as others have suggested online for these things.
ffmpeg -hide_banner -f pulse -async 1 -i default -itsoffset 0 -f v4l2 -vsync 1 -i /dev/video0 -force_key_frames 0 -pix_fmt yuv420p -src_range 1 -dst_range 1 -color_range 2 -framerate 60 -r 60 -video_size 1920x1080 -vf setpts="(PTS-STARTPTS)" -c:v libx264 -c:a flac -crf 12 -dn -sn -map_metadata -1 -preset veryfast -f matroska capture.mkv
Here's my log from letting an effectively identical command run for 26 seconds. It doesn't look too good but I'm not sure what it means:
https://gofile.io/?c=nEHyj3
As suggested by Xtoforas on Reddit, I have tried using -use_wallclock_as_timestamps 1 and -copyts, but I saw no improvement with -use_wallclock_as_timestamps 1 and -copyts broke the audio, and probably isn't what I want anyway.
linux audio video ffmpeg sync
asked Feb 5 at 17:16
spacer GIFspacer GIF
1012
Not sure what's going on here but I can't seem to get consistent audio sync capturing from HDMI with ffmpeg. I can get consistent results from OBS no problem (video is always 100ms or thereabouts ahead), even though I have everything set up the same on there, but OBS on Linux does not allow for the input colour range to be changed. This is a known issue that doesn't look like it'll get fixed any time soon. So unless I stick with limited range video, OBS is not the preferable option. OBS does support custom ffmpeg settings, but these appear to only affect the output, which already supports full range anyway. I would like to know what OBS is doing with ffmpeg under the hood but I've not found a way of viewing this.
A big chunk of my command is irrelevant to the issue but best include it all. I was previously using ALSA, but for the sake of consistency with OBS I've switched to Pulse. Behaviour seems similar. I can attempt to sync it up with -itsoffset, but as soon as I've managed to get the sync close it'll already be way off again. The audio sounds fine, and the output sample rate of 48kHz matches with the input. I've also thrown both -vsync, -async and -force_key_frames at it as others have suggested online for these things.
ffmpeg -hide_banner -f pulse -async 1 -i default -itsoffset 0 -f v4l2 -vsync 1 -i /dev/video0 -force_key_frames 0 -pix_fmt yuv420p -src_range 1 -dst_range 1 -color_range 2 -framerate 60 -r 60 -video_size 1920x1080 -vf setpts="(PTS-STARTPTS)" -c:v libx264 -c:a flac -crf 12 -dn -sn -map_metadata -1 -preset veryfast -f matroska capture.mkv
Here's my log from letting an effectively identical command run for 26 seconds. It doesn't look too good but I'm not sure what it means:
https://gofile.io/?c=nEHyj3
As suggested by Xtoforas on Reddit, I have tried using -use_wallclock_as_timestamps 1 and -copyts, but I saw no improvement with -use_wallclock_as_timestamps 1 and -copyts broke the audio, and probably isn't what I want anyway.
linux audio video ffmpeg sync
linux audio video ffmpeg sync
asked Feb 5 at 17:16
spacer GIFspacer GIF
1012
asked Feb 5 at 17:16
spacer GIFspacer GIF
1012
asked Feb 5 at 17:16
spacer GIFspacer GIF
1012
asked Feb 5 at 17:16
spacer GIFspacer GIF
1012
asked Feb 5 at 17:16
spacer GIFspacer GIF
1012
1012
Remove the async and vsync. and add-af aresample=async=1,asetpts=PTS-STARTPTS.
– Gyan
Feb 5 at 17:44
Your logs show corrupted input video packets - that may contribute to a desync. BTW, we can change the color range flag of H264 streams without re-encoding.
– Gyan
Feb 5 at 17:46
@Gyan I've tried that now and it's still the same, possibly even worse. Five minutes of tinkering with it and the audiosync is already 20 seconds out. This is no use.
– spacer GIF
Feb 6 at 16:27
add a comment |
Remove the async and vsync. and add-af aresample=async=1,asetpts=PTS-STARTPTS.
– Gyan
Feb 5 at 17:44
Your logs show corrupted input video packets - that may contribute to a desync. BTW, we can change the color range flag of H264 streams without re-encoding.
– Gyan
Feb 5 at 17:46
@Gyan I've tried that now and it's still the same, possibly even worse. Five minutes of tinkering with it and the audiosync is already 20 seconds out. This is no use.
– spacer GIF
Feb 6 at 16:27
Remove the async and vsync. and add
-af aresample=async=1,asetpts=PTS-STARTPTS.– Gyan
Feb 5 at 17:44
Remove the async and vsync. and add
-af aresample=async=1,asetpts=PTS-STARTPTS.– Gyan
Feb 5 at 17:44
Your logs show corrupted input video packets - that may contribute to a desync. BTW, we can change the color range flag of H264 streams without re-encoding.
– Gyan
Feb 5 at 17:46
Your logs show corrupted input video packets - that may contribute to a desync. BTW, we can change the color range flag of H264 streams without re-encoding.
– Gyan
Feb 5 at 17:46
@Gyan I've tried that now and it's still the same, possibly even worse. Five minutes of tinkering with it and the audiosync is already 20 seconds out. This is no use.
– spacer GIF
Feb 6 at 16:27
@Gyan I've tried that now and it's still the same, possibly even worse. Five minutes of tinkering with it and the audiosync is already 20 seconds out. This is no use.
– spacer GIF
Feb 6 at 16:27
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1402336%2finconsistent-audio-sync-capturing-with-v4l2-and-pulseaudio%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1402336%2finconsistent-audio-sync-capturing-with-v4l2-and-pulseaudio%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Remove the async and vsync. and add
-af aresample=async=1,asetpts=PTS-STARTPTS.– Gyan
Feb 5 at 17:44
Your logs show corrupted input video packets - that may contribute to a desync. BTW, we can change the color range flag of H264 streams without re-encoding.
– Gyan
Feb 5 at 17:46
@Gyan I've tried that now and it's still the same, possibly even worse. Five minutes of tinkering with it and the audiosync is already 20 seconds out. This is no use.
– spacer GIF
Feb 6 at 16:27