SEQUENCER: Frame Rate Base Rounding Leads To Vid / Audio Strips Out Of Sync by 1 Frame #21138

New Issue

yellow .... · 2010-02-14T00:10:14+01:00

yellow .... commented

2010-02-14 00:10:14 +01:00

%%%Really pedantic issue but the frame rate base value ie /:1.000 is rounding the wrong way, for example if I add video which is 29.97 and enter 1.001 frame base video and audio strips are out by 1 frame. However if I change the base to 1.0009 vid/audio strips are correct same length.

Like wise if I add video which is 30.01 with a base of 1.001 the strips are out by one frame, changing it to 1.000 gives me correct vid/audio strip lengths.

Sorry really pedantic to raise this bug.

wget http://s3.amazonaws.com/videos.vimeo.com/155/000/15500064.mp4

Add as 30fps at 1.001 and see 5808 Aud & 5809 Vid

Add as 30fps at 1.0009 and see 5809 aud & 5809 Vid

Ubuntu Linux 64bit Rev. 26876%%%

%%%Really pedantic issue but the frame rate base value ie /:1.000 is rounding the wrong way, for example if I add video which is 29.97 and enter 1.001 frame base video and audio strips are out by 1 frame. However if I change the base to 1.0009 vid/audio strips are correct same length. Like wise if I add video which is 30.01 with a base of 1.001 the strips are out by one frame, changing it to 1.000 gives me correct vid/audio strip lengths. Sorry really pedantic to raise this bug. wget http://s3.amazonaws.com/videos.vimeo.com/155/000/15500064.mp4 Add as 30fps at 1.001 and see 5808 Aud & 5809 Vid Add as 30fps at 1.0009 and see 5809 aud & 5809 Vid Ubuntu Linux 64bit Rev. 26876%%%

yellow .... commented

2010-02-14 00:10:14 +01:00

Changed status to: 'Open'

Troy Sobotka commented

2010-02-15 23:11:36 +01:00

%%%Confirming here - Linux amd64 (Ubuntu 9.10)

Tested against 60fps NTSC (60/1.001) and rounding results in a frame off.%%%

%%%Confirming here - Linux amd64 (Ubuntu 9.10) Tested against 60fps NTSC (60/1.001) and rounding results in a frame off.%%%

Janne Karhu commented

2010-11-16 19:33:53 +01:00

%%%The frame rate rounding is not the issue here and all of the related calculations are done correct. The "problem" is that in the video file you provided the video and audio streams have slightly different lengths. The audio track has a length of 193.82697 seconds while the video stream's length is 193,86034 seconds (5810 frames / 29.970029 fps). Using the framerate base of 1.001 is absolutely correct here, but the difference in stream lengths results in the one frame offset.

I don't know how common it is for video recording software to leave the streams at slightly different lengths, but luckily this will not lead to syncing issues as long as the correct framerate base is used. So when you see the video and audio tracks are different length in the sequencer it only means that the actual data streams are of different lengths.

Closing the report.%%%

%%%The frame rate rounding is not the issue here and all of the related calculations are done correct. The "problem" is that in the video file you provided the video and audio streams have slightly different lengths. The audio track has a length of 193.82697 seconds while the video stream's length is 193,86034 seconds (5810 frames / 29.970029 fps). Using the framerate base of 1.001 is absolutely correct here, but the difference in stream lengths results in the one frame offset. I don't know how common it is for video recording software to leave the streams at slightly different lengths, but luckily this will not lead to syncing issues as long as the correct framerate base is used. So when you see the video and audio tracks are different length in the sequencer it only means that the actual data streams are of different lengths. Closing the report.%%%

Janne Karhu commented

2010-11-16 19:33:53 +01:00

Changed status from 'Open' to: 'Archived'

Janne Karhu closed this issue

2010-11-16 19:33:53 +01:00

Janne Karhu commented

2010-11-16 20:49:35 +01:00

%%%The frame rate rounding is not the issue here and all of the related calculations are done correct. The "problem" is that in the video file you provided the video and audio streams have slightly different lengths. The audio track has a length of 193.82697 seconds while the video stream's length is 193,86034 seconds (5810 frames / 29.970029 fps). Using the framerate base of 1.001 is absolutely correct here, but the difference in stream lengths results in the one frame offset.

I don't know how common it is for video recording software to leave the streams at slightly different lengths, but luckily this will not lead to syncing issues as long as the correct framerate base is used. So when you see the video and audio tracks are different length in the sequencer it only means that the actual data streams are of different lengths.

Closing the report.%%%

%%%The frame rate rounding is not the issue here and all of the related calculations are done correct. The "problem" is that in the video file you provided the video and audio streams have slightly different lengths. The audio track has a length of 193.82697 seconds while the video stream's length is 193,86034 seconds (5810 frames / 29.970029 fps). Using the framerate base of 1.001 is absolutely correct here, but the difference in stream lengths results in the one frame offset. I don't know how common it is for video recording software to leave the streams at slightly different lengths, but luckily this will not lead to syncing issues as long as the correct framerate base is used. So when you see the video and audio tracks are different length in the sequencer it only means that the actual data streams are of different lengths. Closing the report.%%%

nh commented

2016-04-30 10:26:21 +02:00

Added subscriber: @computaholic

nh commented

2016-04-30 10:26:21 +02:00

Hi,

I am actually having the identical problem and I hope to reopen this bug (Blender 2.77, Ubuntu 16.04)

Setup: I have a video shot with a GOPRO at 59.95 fps. I want to use in a 29.97 fps environment inside blender, so I use ffmpeg to change the fps value.

Problem: When I import 29.97 video, the audio and video are off by 1 frame. Specifically, the audio is one frame longer than the video. I would like to have the audio and video to have the same==identical length.

What have I done so far: Now comes the funny part. So when I import the 29.97 fps video, the audio is one frame longer, as described above. However, the actual audio information is indeed a little shorter than the video. So I split up the audio and video, encoded the video separately and then joined the two parts together. That did not change a thing. However, when I just import the audio file, then the resulting strip is actually 1 frame shorter than the video! Both audio strips (from the video and the single one) line up perfectly in regards of their waveform, so there is only a difference in the padding at the end of the file.

The audio part from the original 59.94 video would line up perfectly with the encoded 29.97 video. But that would be too complicated to always import two videos and then combine audio and video...

So, here I have 3 audio strips with the very identical audio information, but with three different lengths, where the strip from the single audio file is one frame shorter than the video, the strip from the 29.97 video is 1 frame longer and the audio strip from the 59.94 is as long as the video strip.

In my opinion it is unclear how blender determines the length of an audio strip. I does not matter, whether the audio and video do not share the same size in milliseconds, as this would always never be the case due to different frame lengths in audio and video.

Unless there is a method on how to prepare files in such way, that blender will reliably detect the audio strip length, this is indeed a bug to consider.

Thanks for your help.

ffmpeg 59.94 to 29.94

ffmpeg -i GOPR7304-59.94fps.MP4 -y -probesize 5000000 -s 640x368 -c:v prores -profile:v 0 -qscale:v 13 -vendor ap10 -pix_fmt yuv422p10le -acodec copy -r 30000/1001 GOPR7304-29.97.mov

ffmpeg splitting

ffmpeg -i GOPR7304-59.94fps.MP4 -map 0:0 -vcodec copy 04.m4v -map 0:1 -acodec copy 04.m4a

Thanks!

Hi, I am actually having the identical problem and I hope to reopen this bug (Blender 2.77, Ubuntu 16.04) Setup: I have a video shot with a GOPRO at 59.95 fps. I want to use in a 29.97 fps environment inside blender, so I use ffmpeg to change the fps value. Problem: When I import 29.97 video, the audio and video are off by 1 frame. Specifically, the audio is one frame longer than the video. I would like to have the audio and video to have the same==identical length. What have I done so far: Now comes the funny part. So when I import the 29.97 fps video, the audio is one frame longer, as described above. However, the actual audio information is indeed a little shorter than the video. So I split up the audio and video, encoded the video separately and then joined the two parts together. That did not change a thing. However, when I just import the audio file, then the resulting strip is actually 1 frame shorter than the video! Both audio strips (from the video and the single one) line up perfectly in regards of their waveform, so there is only a difference in the padding at the end of the file. The audio part from the original 59.94 video would line up perfectly with the encoded 29.97 video. But that would be too complicated to always import two videos and then combine audio and video... So, here I have 3 audio strips with the very identical audio information, but with three different lengths, where the strip from the single audio file is one frame shorter than the video, the strip from the 29.97 video is 1 frame longer and the audio strip from the 59.94 is as long as the video strip. In my opinion it is unclear how blender determines the length of an audio strip. I does not matter, whether the audio and video do not share the same size in milliseconds, as this would always never be the case due to different frame lengths in audio and video. Unless there is a method on how to prepare files in such way, that blender will reliably detect the audio strip length, this is indeed a bug to consider. Thanks for your help. ffmpeg 59.94 to 29.94 ``` ffmpeg -i GOPR7304-59.94fps.MP4 -y -probesize 5000000 -s 640x368 -c:v prores -profile:v 0 -qscale:v 13 -vendor ap10 -pix_fmt yuv422p10le -acodec copy -r 30000/1001 GOPR7304-29.97.mov ``` ffmpeg splitting ``` ffmpeg -i GOPR7304-59.94fps.MP4 -map 0:0 -vcodec copy 04.m4v -map 0:1 -acodec copy 04.m4a ``` Thanks!

Troy Sobotka commented

2016-04-30 15:14:03 +02:00

This isn't related to the bug and likely due to a combination of GOP with non-equal encoded data.

Daniel commented

2023-07-25 14:52:43 +02:00

Hi
It looks like I have the same bug again since Blender 3.0 and with the newest 3.6.1
I have a lot of projects with 29.97fps (30000/1001) and those work correctly with Blender 2.9x but since Blender 3.0 all video clips are 1 frame shorter and my projects are a mess, because the frames in all clips are also shifted 1 frame !!
If I set the base to 1.0009 instead of 1.001 its all fine, but if I set 29.97 from the drop-down menu, all clips are 1 frame shorter.
I have this also tested with videos without any audio and that makes no difference.
The audio length btw is alway correct.

maybe the problems in this posts, which I have found, has the same cause ?
https://blender.stackexchange.com/questions/51650/audio-is-1-frame-off
https://blender.stackexchange.com/questions/250718/blender-3-0-vse-audio-and-video-out-of-sync-bug

Please open this issues again!

Hi It looks like I have the same bug again since Blender 3.0 and with the newest 3.6.1 I have a lot of projects with 29.97fps (30000/1001) and those work correctly with Blender 2.9x but since Blender 3.0 all video clips are 1 frame shorter and my projects are a mess, because the frames in all clips are also shifted 1 frame !! If I set the base to 1.0009 instead of 1.001 its all fine, but if I set 29.97 from the drop-down menu, all clips are 1 frame shorter. I have this also tested with videos without any audio and that makes no difference. The audio length btw is alway correct. maybe the problems in this posts, which I have found, has the same cause ? https://blender.stackexchange.com/questions/51650/audio-is-1-frame-off https://blender.stackexchange.com/questions/250718/blender-3-0-vse-audio-and-video-out-of-sync-bug Please open this issues again!

Daniel commented

2023-07-26 09:25:55 +02:00

@troy_s @Sergey should I open a new issue?

Daniel referenced this issue

2023-08-07 09:41:24 +02:00

VSE: Frame Rate Base Rounding Leads To Vid / Audio Strips Out Of Sync by 1 Frame #110878

Sign in to join this conversation.