0

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.

Improve this question
6
  • Remove the async and vsync. and add -af aresample=async=1,asetpts=PTS-STARTPTS.
    – Gyan
    Commented Feb 5, 2019 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
    Commented Feb 5, 2019 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
    Commented Feb 6, 2019 at 16:27
  • Did you ever find a solution? I have a high-end setup for game streaming, but the v4l capture is almost always out of sync with the ALSA capture despite the timestamps lining up at the start. CPU use is minimal, disk I/O is nowhere near limits. The audio sync drifts around as well; what's frustrating is this /used/ to work perfectly on an old ffmpeg version (way too old to bisect).
    – madscientist159
    Commented Jun 8, 2019 at 2:07
  • @madscientist159 No, I never found a solution. I think OBS got updated to now allow for full RGB colour range, which I guess solves my problem. I haven't fired it up lately to check.
    – spacer GIF
    Commented Jun 11, 2019 at 22:42

1 Answer 1

Reset to default
0

It's with a heavy heart that I'm going to say I'm giving up on ffmpeg for this purpose. Spent a few more hours tinkering with it the other day to no avail.

OBS is now fine for streams and stuff. For capturing interlaced footage, I have a capture box. I saw madscientist159 mention GStreamer but haven't tried it due to its learning curve - the Hello World example is 40 lines in length.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .