Resulting strip is (too) short

[tin2tin]

Is it only on Windows the resulting strip is cut shorter. Like this?

The fps seems to be set correct in the command line. Any ideas how to solve this?

EDIT: If it is the first part which is missing(slow start up of ffmpeg?), maybe the strip end should be aligned with the stopped playhead position instead of the start position?

[fsiddi]

Latency could be due to ffmpeg or due to the time it takes your device to start recording. Someone with better ffmpeg knowledge could help here, but for our use case this is sufficient. I'll make a separate ticked issue to evaluate an ffmpeg replacement.

[tin2tin]

Does this only happen on Windows? Is the recorded audio in sync on Linux and macOS?

[tin2tin]

A bit of investigation:

https://trac.ffmpeg.org/wiki/DirectShow#BufferingLatency

There is also an option audio_buffer_size. Basically if you're capturing from a live mic, the default behavior for this hardware device is to "buffer" 500ms (or 1000ms) worth of data, before it starts sending it down the pipeline. This can introduce startup latency, so setting this to 50ms (msdn suggests 80ms) may be a better idea here. The timestamps on the data will be right, it will just have added (unneeded) latency if you don't specify this.

-audio_buffer_size 50

But it doesn't seem to have any effect on the short strips...

[tin2tin]

It seems like it's around 2 sec. missing from the start, so maybe the strip should be moved to the right, so the right handle is at the the playhead position, in order to keep the audio will stay in sync with the images?

How much time is there for you guys between the end of the strip and the playhead? (I counted sec out loud when hitting record and 1+2 where missing, and there is a 2 sec distance between right handle of the generated strip and the playhead)

[britalmeida]

I have seen a similar problem before in a linux system and adding the "-fflags nobuffer" fixed the issue there. You could try experimenting with the ffmpeg flags.

[tin2tin]

I've tried "-fflags nobuffer", "-movflags +faststart" and other things, but it seems ffmpeg takes a few sec to start both inside of Blender and outside(directly in cmd).

Maybe playing/generating color strip could be delayed until "size" is found in the stdout? I mean looking for the first instance of this line: "size= 1219kB time=00:00:06.51 bitrate=1532.8kbits/s speed=1.03x"

Is it correct that this delay is only on Windows?

[britalmeida]

I can't tell if the delay only happens on Windows. It could be your specific audio recording hardware. Have you tried a different microphone or a different computer?

Unfortunately, I don't have any other suggestions than the flags you've already tried, besides trying a different solution than ffmpeg.

I'm not sure it would help to delay generating the color strip. It's technically possible, but I think people expect it to start recording immediately. The push to talk button is meant to work during playback and a bit of delay can really make for a crappy experience :(

I'll leave this issue open, since it's not solved, but I don't have concrete plans to test different audio recording solutions.

[tin2tin]

I guess it could start as it is doing right now, with a red strip, but with the words: "Starting up", and then when the string "size" is detected in stdout, the start would be cut, the color would become green and the word would be "Recording"(and the generated strip would start at the time "size" is detected)? This way the sync should be preserved between the images and the recorded audio.

[britalmeida]

What I meant is this feature really is designed to be a real-time experience. People are supposed to see their edit playing and then press the button just at the write time to record temp dialog and other sounds. A delay totally breaks this workflow. The delay should not be there.

I don't see the advantage of adding the "Starting up". If there is a delay, it's already obvious that something went wrong, because the strip is short. I don't see the usefulness of moving the strip around. It probably needs a re-take.

[tin2tin]

I found no way to avoid the latency problem through ffmpeg command lines on Windows, however I found a way to "remote control" Audacity from Blender, so you start the recording in Blender, but it is actually Audacity doing the recording, and when finished you can do audio processing in Audacity, before sending the recording to Blender VSE: https://github.com/tin2tin/audacity_tools_for_blender