Importing any video to VSE results in audio and video having different lengths (not a codec problem, happens to all videos) #54655

New Issue

Louigi Verona · 2018-04-16T13:16:30+02:00

Louigi Verona commented

2018-04-16 13:16:30 +02:00

System Information
Xubuntu 16.04, I am using a Dell and an Asus laptops. I don't think my graphics card matters for Blender VSE.

Blender Version
Broken: All later versions: 2.78 and 2.79 (obtained form the website) (although have not tested with 2.77)
Worked: Blender 2.76b f337fea (obtained form the website)

Short description of error
Importing any video to Blender VSE results in different video and audio lengths, with video usually being shorter than the audio. The fps chosen matches the video fps. Same video file is imported correctly in Blender 2.76b.

In the vast majority of cases (basically, a careful way of saying always) fiddling with custom fps settings doesn't solve the problem, the difference remains. The issue was reproduced by Blender users on the #blender IRC channel.

A very important note: the same happens to all videos with constant bit rates .

This ticket is not about supporting "a codec", this ticket is about fixing a bug that has broken video import across codecs. Also, I have to repeat here, otherwise people don't read further and attempt to close the ticket:

The problem is reproducible for me in the vast majority of cases, with all sorts of video files. This includes screencasting videos made with the SimpleScreenRecorder and all videos downloaded from YouTube. In fact, I was not able to find a file for which it doesn't happen.

Exact steps for others to reproduce the error

Please note, you don't have to use my file. The problem occurs with virtually any video file that has audio and video. Download one from YouTube. This ticket is not about supporting "a codec", this is a bug across codecs.

This is the test project with a video file. The video was shot using a standard camera app of a Samsung Galaxy 4mini phone.
https://louigiverona.com/files/var/TestProject/

The video is 95 Mb (it is only 50 sec), wanted to make it somewhat longer, since for very short videos the difference might not be that large, although typically still there, even if by 1.
Since I put the file on my server, I ask to not download it if you are not planning to work on the bug, so that I don't get a huge bill by the end of the month :)

Results of the test:
Lengths in 2.76b:
audio 1404
video 1404

Lengths in 2.79:
audio 1404
video 1391

The problem is reproducible for me in the vast majority of cases, with all sorts of video files. This includes screencasting videos made with the SimpleScreenRecorder and videos downloaded from YouTube. The only reason I am including a sample file is because clear reproduction steps are required to file a ticket of this sort. But I could have asked anyone to take any file that has audio and video and import it into Blender VSE, with same results.

All videos from any of the cameras I own, from three mobile phones (Samsung Galaxy 4mini, Huawei P8 Lite, Samsung A3) and from an expensive Nikon camera - all videos without exception always end up being opened with different lengths in 2.78 and 2.79. At the same time, they are all in complete sync in Blender 2.76b, with audio and video always having the exact same length.

I have asked several people to reproduce the issue in Blender 2.79 and all the people I asked were able to reproduce the problem immediately, using their own video files.

Another way to reproduce is to download a video from YouTube. Here is a random video I watched, downloaded and tested: https://www.youtube.com/watch?v=FNLoxaSSQ2A

Here, inspite of the video being long, the difference is smaller - but still there. The video is at 29.970030 frame rate.

Blender 2.76b:
audio 200391
video 200391

Blender 2.79:
audio 200391
video 200389

It seems that the ability of later versions of Blender to automatically detect the imported video fps is at play here. Many videos will not have exactly 30 fps, for example the frame rate of the video I supply with my test project is 30.003730. This difference is small enough to be neglected, but as JA12 in the IRC channel found out, Blender seems to try to convert this fps to some exact number and fails because of the length of the field, however, he was not certain this is really the cause. He was able to immediately reproduce an issue with my project and by importing some other video and seeing the same problem. Everyone on IRC were able to reproduce the problem using my TestProject file with the video also. JA12 was also able to reproduce the problem with the latest development version of Blender.

I will do my best to provide additional information is necessary.

**System Information** Xubuntu 16.04, I am using a Dell and an Asus laptops. I don't think my graphics card matters for Blender VSE. **Blender Version** Broken: All later versions: 2.78 and 2.79 (obtained form the website) (although have not tested with 2.77) Worked: Blender 2.76b f337fea (obtained form the website) **Short description of error** Importing *any* video to Blender VSE results in different video and audio lengths, with video usually being shorter than the audio. **The fps chosen matches the video fps. Same video file is imported correctly in Blender 2.76b.** In the vast majority of cases (basically, a careful way of saying always) fiddling with custom fps settings doesn't solve the problem, the difference remains. The issue was reproduced by Blender users on the #blender IRC channel. A very important note: the same happens to all videos with [constant bit rates ](https://developer.blender.org/T54655#494818). This ticket is not about supporting "a codec", this ticket is about fixing a bug that has broken video import across codecs. Also, I have to repeat here, otherwise people don't read further and attempt to close the ticket: `The problem is reproducible for me in the vast majority of cases, with all sorts of video files. This includes screencasting videos made with the SimpleScreenRecorder and all videos downloaded from YouTube. In fact, I was not able to find a file for which it doesn't happen.` **Exact steps for others to reproduce the error** *Please note, you don't have to use my file. The problem occurs with virtually any video file that has audio and video. Download one from YouTube. This ticket is not about supporting "a codec", this is a bug across codecs.* This is the test project with a video file. The video was shot using a standard camera app of a Samsung Galaxy 4mini phone. https://louigiverona.com/files/var/TestProject/ The video is 95 Mb (it is only 50 sec), wanted to make it somewhat longer, since for very short videos the difference might not be that large, although typically still there, even if by 1. *Since I put the file on my server, I ask to not download it if you are not planning to work on the bug, so that I don't get a huge bill by the end of the month :)* Results of the test: Lengths in 2.76b: audio 1404 video 1404 Lengths in 2.79: audio 1404 video 1391 `The problem is reproducible for me in the vast majority of cases, with all sorts of video files. This includes screencasting videos made with the SimpleScreenRecorder and videos downloaded from YouTube. The only reason I am including a sample file is because clear reproduction steps are required to file a ticket of this sort. But I could have asked anyone to take any file that has audio and video and import it into Blender VSE, with same results.` All videos from any of the cameras I own, from three mobile phones (Samsung Galaxy 4mini, Huawei P8 Lite, Samsung A3) and from an expensive Nikon camera - *all videos without exception* always end up being opened with different lengths in 2.78 and 2.79. At the same time, they are all in complete sync in Blender 2.76b, with audio and video always having the exact same length. I have asked several people to reproduce the issue in Blender 2.79 and all the people I asked were able to reproduce the problem immediately, using their own video files. Another way to reproduce is to download a video from YouTube. Here is a random video I watched, downloaded and tested: https://www.youtube.com/watch?v=FNLoxaSSQ2A Here, inspite of the video being long, the difference is smaller - but still there. The video is at 29.970030 frame rate. Blender **2.76b**: audio 200391 video 200391 Blender **2.79**: audio 200391 video 200389 It seems that the ability of later versions of Blender to automatically detect the imported video fps is at play here. Many videos will not have exactly 30 fps, for example the frame rate of the video I supply with my test project is 30.003730. This difference is small enough to be neglected, but as JA12 in the IRC channel found out, Blender seems to try to convert this fps to some exact number and fails because of the length of the field, however, he was not certain this is really the cause. He was able to immediately reproduce an issue with my project and by importing some other video and seeing the same problem. Everyone on IRC were able to reproduce the problem using my TestProject file with the video also. JA12 was also able to reproduce the problem with the latest development version of Blender. I will do my best to provide additional information is necessary.

Louigi Verona commented

2018-04-16 13:16:30 +02:00

Added subscriber: @LouigiVerona

ChristopherAnderssarian commented

2018-04-16 16:23:10 +02:00

Added subscriber: @ChristopherAnderssarian

ChristopherAnderssarian commented

2018-04-16 16:23:10 +02:00

Having a look at the metadata; the audio is longer than the video:
Video: Line 23: 46 s 361 ms
Audio: Line 50: 46 s 784 ms
Blender seems to be setting the correct frame rate there's just a bit of extra audio.
P658: Metadata inspection of #54655's video sample

General
Complete name                            : C:\Users\admin\Downloads\#54655\20180415_111352.mp4
Format                                   : MPEG-4
Format profile                           : Base Media
Codec ID                                 : isom (isom/3gp4)
File size                                : 94.7 MiB
Duration                                 : 46 s 784 ms
Overall bit rate                         : 17.0 Mb/s
Encoded date                             : UTC 2018-04-15 09:14:40
Tagged date                              : UTC 2018-04-15 09:14:40

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4
Format settings                          : CABAC / 1 Ref Frames
Format settings, CABAC                   : Yes
Format settings, RefFrames               : 1 frame
Format settings, GOP                     : M=1, N=30
Codec ID                                 : avc1
Codec ID/Info                            : Advanced Video Coding
Duration                                 : 46 s 361 ms
Bit rate                                 : 17.0 Mb/s
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Variable
Frame rate                               : 30.000 FPS
Minimum frame rate                       : 29.499 FPS
Maximum frame rate                       : 30.529 FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.273
Stream size                              : 94.0 MiB (99%)
Title                                    : VideoHandle
Language                                 : English
Encoded date                             : UTC 2018-04-15 09:14:40
Tagged date                              : UTC 2018-04-15 09:14:40
mdhd_Duration                            : 46361

Audio
ID                                       : 2
Format                                   : AAC
Format/Info                              : Advanced Audio Codec
Format profile                           : LC
Codec ID                                 : mp4a-40-2
Duration                                 : 46 s 784 ms
Source duration                          : 46 s 786 ms
Source_Duration_FirstFrame               : 2 ms
Bit rate mode                            : Constant
Bit rate                                 : 128 kb/s
Channel(s)                               : 2 channels
Channel positions                        : Front: L R
Sampling rate                            : 48.0 kHz
Frame rate                               : 46.875 FPS (1024 SPF)
Compression mode                         : Lossy
Stream size                              : 704 KiB (1%)
Source stream size                       : 704 KiB (1%)
Title                                    : SoundHandle
Language                                 : English
Encoded date                             : UTC 2018-04-15 09:14:40
Tagged date                              : UTC 2018-04-15 09:14:40
mdhd_Duration                            : 46784

Having a look at the metadata; the audio is longer than the video: Video: Line 23: 46 s 361 ms Audio: Line 50: 46 s 784 ms Blender seems to be setting the correct frame rate there's just a bit of extra audio. [P658: Metadata inspection of #54655's video sample](https://archive.blender.org/developer/P658.txt) ``` General Complete name : C:\Users\admin\Downloads\#54655\20180415_111352.mp4 Format : MPEG-4 Format profile : Base Media Codec ID : isom (isom/3gp4) File size : 94.7 MiB Duration : 46 s 784 ms Overall bit rate : 17.0 Mb/s Encoded date : UTC 2018-04-15 09:14:40 Tagged date : UTC 2018-04-15 09:14:40 Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4 Format settings : CABAC / 1 Ref Frames Format settings, CABAC : Yes Format settings, RefFrames : 1 frame Format settings, GOP : M=1, N=30 Codec ID : avc1 Codec ID/Info : Advanced Video Coding Duration : 46 s 361 ms Bit rate : 17.0 Mb/s Width : 1 920 pixels Height : 1 080 pixels Display aspect ratio : 16:9 Frame rate mode : Variable Frame rate : 30.000 FPS Minimum frame rate : 29.499 FPS Maximum frame rate : 30.529 FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.273 Stream size : 94.0 MiB (99%) Title : VideoHandle Language : English Encoded date : UTC 2018-04-15 09:14:40 Tagged date : UTC 2018-04-15 09:14:40 mdhd_Duration : 46361 Audio ID : 2 Format : AAC Format/Info : Advanced Audio Codec Format profile : LC Codec ID : mp4a-40-2 Duration : 46 s 784 ms Source duration : 46 s 786 ms Source_Duration_FirstFrame : 2 ms Bit rate mode : Constant Bit rate : 128 kb/s Channel(s) : 2 channels Channel positions : Front: L R Sampling rate : 48.0 kHz Frame rate : 46.875 FPS (1024 SPF) Compression mode : Lossy Stream size : 704 KiB (1%) Source stream size : 704 KiB (1%) Title : SoundHandle Language : English Encoded date : UTC 2018-04-15 09:14:40 Tagged date : UTC 2018-04-15 09:14:40 mdhd_Duration : 46784 ```

Louigi Verona commented

2018-04-16 17:52:09 +02:00

I am not sure how is this possible, unless this is really how all cameras and videos in general work. And somehow Blender 2.76b does everything correctly, whereas the "correct" frame rate of later versions results in audio and video being out of sync.

stephen paschke commented

2018-04-17 09:43:01 +02:00

Added subscriber: @Paskperfect

stephen paschke commented

2018-04-17 09:43:01 +02:00

Yes, this in general is how all cameras and video recorders work, these days. Why? Gone are the days when you needed a bit of magnetic tape to move across a tape-head at a constant rate, or a constant 33 1/3 rotations per minute to faithfully reproduce video or sound.
All readily-available video and audio is compressed in some form, to either make it fit into a smaller distribution medium, or stream "faster" through phone lines, to save someone time, or money.
Before you load a file for editing in Blender, consider using a program (such as Handbrake) that can convert between variable-rate and constant-rate frames-per-second formats. You might also try FFMPeg, which is used by both Blender and Handbrake to do their video conversions for exporting to different formats. Handbrake is a lot easier to work with, than FFMPeg, though.
Other editing suites do similar conversions, without telling you about it, and still take just as long to process.

Yes, this in general is how all cameras and video recorders work, these days. Why? Gone are the days when you needed a bit of magnetic tape to move across a tape-head at a constant rate, or a constant 33 1/3 rotations per minute to faithfully reproduce video or sound. All readily-available video and audio is compressed in some form, to either make it fit into a smaller distribution medium, or stream "faster" through phone lines, to save someone time, or money. Before you load a file for editing in Blender, consider using a program (such as Handbrake) that can convert between variable-rate and constant-rate frames-per-second formats. You might also try FFMPeg, which is used by both Blender and Handbrake to do their video conversions for exporting to different formats. Handbrake is a lot easier to work with, than FFMPeg, though. Other editing suites do similar conversions, without telling you about it, and still take just as long to process.

Louigi Verona commented

2018-04-17 11:51:02 +02:00

Stephen, this is all fine, but somehow Blender 2.76b was doing it correctly, without requiring me to use Handbrake or any other converter.

"Other editing suites do similar conversions, without telling you about it, and still take just as long to process."

Well, I tried Kdenlive. I imported the same file - there was no processing of any sort, it just got added to the timeline, everything perfectly in sync.

Stephen, this is all fine, but somehow Blender 2.76b was doing it correctly, without requiring me to use Handbrake or any other converter. "Other editing suites do similar conversions, without telling you about it, and still take just as long to process." Well, I tried Kdenlive. I imported the same file - there was no processing of any sort, it just got added to the timeline, everything perfectly in sync.

Olly Funkster commented

2018-04-17 12:20:58 +02:00

Added subscriber: @Funkster-3

Olly Funkster commented

2018-04-17 12:20:58 +02:00

Since the audio length in your reports is the same between 2.76b and later versions, and it's the video that has changed length, I would argue that 2.76b was getting the video length wrong somehow. It may even be a difference in ffmpeg / libavcodec rather than in blender itself, since the library versions also change between blender releases.

FWIW, my local builds are based around 2.78ish, and I get matching audio and video lengths with the cameras I use:

Canon S95
Canon EOS M
TCL SVC 200

None of these cameras use variable frame rate. No editing system can perfectly match audio and video if the video frame interval is not consistent. Mobile phones and OBS are notorious for creating videos with inconsistent frame intervals due to them being busy doing other things with the CPU.

I'm not at my main machine right now, next time I am I'll try some clips in the 2.78 and 2.79 releases but I don't recall having any problems.

Since the audio length in your reports is the same between 2.76b and later versions, and it's the video that has changed length, I would argue that 2.76b was getting the video length wrong somehow. It may even be a difference in ffmpeg / libavcodec rather than in blender itself, since the library versions also change between blender releases. FWIW, my local builds are based around 2.78ish, and I get matching audio and video lengths with the cameras I use: - Canon S95 - Canon EOS M - TCL SVC 200 None of these cameras use variable frame rate. No editing system can perfectly match audio and video if the video frame interval is not consistent. Mobile phones and OBS are notorious for creating videos with inconsistent frame intervals due to them being busy doing other things with the CPU. I'm not at my main machine right now, next time I am I'll try some clips in the 2.78 and 2.79 releases but I don't recall having any problems.

Louigi Verona commented

2018-04-17 13:07:21 +02:00

Okay, so I just took the test video which I supplied, used Handbrake to convert it to 30 constant fps. Now Codec info says exactly 30 fps.

Opening it in Blender 2.79:
audio: 1405
video: 1391

Project fps is at 30.

Opening it in Blender 2.76b:
audio: 1405
video: 1405

Project fps is at 30.

So, even with the constant frame rate the problem seems to persist.

Okay, so I just took the test video which I supplied, used Handbrake to convert it to 30 constant fps. Now Codec info says exactly 30 fps. Opening it in Blender 2.79: audio: 1405 video: 1391 Project fps is at 30. Opening it in Blender 2.76b: audio: 1405 video: 1405 Project fps is at 30. So, even with the constant frame rate the problem seems to persist.

ChristopherAnderssarian commented

2018-04-17 18:36:45 +02:00

@LouigiVerona Try importing your converted video in 2.79b (or preferably a daily build ) and see if the problem persists.

@LouigiVerona Try importing your converted video in 2.79b (or preferably a [daily build ](https://builder.blender.org/download/)) and see if the problem persists.

Olly Funkster commented

2018-04-17 19:06:21 +02:00

I just downloaded your sample... it only contains 1391 video frames (checked by transcoding it with ffmpeg and looking at the frame count at the end).

So any setup that makes you a video strip 1405 frames long is adding some frames somewhere to compensate.

I just downloaded your sample... it only contains 1391 video frames (checked by transcoding it with ffmpeg and looking at the frame count at the end). So any setup that makes you a video strip 1405 frames long is adding some frames somewhere to compensate.

Tobiasz Karoń commented

2018-10-31 16:46:01 +01:00

Added subscriber: @TobiaszunfaKaron

Tobiasz Karoń commented

2018-10-31 16:46:01 +01:00

Recently I had a problem with audio exported from Ardour being longer than the same audio from OBS video file (both at 48kHz sampling rate both PCM streams).
It broke both in Blender and Kdenlive in similar ways. I think it could be a problem in one of the libraries these programs use to parse audio stream metadata or something.
Not sure if it's related though.

Recently I had a problem with audio exported from Ardour being longer than the same audio from OBS video file (both at 48kHz sampling rate both PCM streams). It broke both in Blender and Kdenlive in similar ways. I think it could be a problem in one of the libraries these programs use to parse audio stream metadata or something. Not sure if it's related though.

Tobiasz Karoń commented

2018-10-31 16:57:44 +01:00

@Funkster-3 - Could your result be because ffmpeg is not compensating correctly for some dropped frames in the stream?

If the same file plays fine in VLC or another media player I guess it's a problem in Blender or some libraries Blender use. I know that editing video is more complex than simply playing it back, but I don't see a reason why it should make the A/V sync break. It's not what I'd expect to happen in a video editor.

@Funkster-3 - Could your result be because ffmpeg is not compensating correctly for some dropped frames in the stream? If the same file plays fine in VLC or another media player I guess it's a problem in Blender or some libraries Blender use. I know that editing video is more complex than simply playing it back, but I don't see a reason why it should make the A/V sync break. It's not what I'd expect to happen in a video editor.

Olly Funkster commented

2018-10-31 17:10:32 +01:00

@TobiaszunfaKaron VLC is pretty clever, and if the file contains information about a dropped frame or an altered presentation time, you can bet that VLC is capable of interpreting that correctly and adjusting the timing to stay in sync. Blender just takes the average frame rate, and the index of the frame you're on, and calls it a day.

Tobiasz Karoń commented

2018-11-05 09:41:38 +01:00

Hmm, maybe that's the root of the problem? But in such case - could transcoding (or just remuxing) the file to a constant FPS file could help?

Louigi Verona commented

2018-11-05 10:18:39 +01:00

@Funkster-3 If you read the info I have provided above, this doesn't add up. Blender does everything correctly in previous versions, and so do Kdenlive and even OpenShot.

My forced workaround is to use an old version of Blender for editing, but then render it through the new version of Blender. Basically, I can just import all the files through the old version of Blender I mentioned, and once they are imported, this new Blender version can open the files normally and work with them.

So, the problem is very clearly in the change of file importing into VSE. I am confused as to why this demonstrable fact is still being disputed.

@Funkster-3 If you read the info I have provided above, this doesn't add up. Blender does everything correctly in previous versions, and so do Kdenlive and even OpenShot. My forced workaround is to use an old version of Blender for editing, but then render it through the new version of Blender. Basically, I can just import all the files through the old version of Blender I mentioned, and once they are imported, this new Blender version can open the files normally and work with them. So, the problem is very clearly in the change of file importing into VSE. I am confused as to why this demonstrable fact is still being disputed.

Olly Funkster commented

2018-11-05 10:56:06 +01:00

Any change in behaviour is in FFMPEG, not in the VSE code itself (which just takes the frames and the playback rate data from ffmpeg as it has always done).

But the real source of the error is your video file, whose length, frame count, and playback rate do not add up, and that is not blender's responsibility to fix - given the extremely limited (i.e. near-zero) amount of coding resource available for VSE development, dealing more gracefully with non-compliant video files is about as near to the bottom of the priority list as it's possible to get.

If you are able to develop a fix for your edge case that doesn't break anything else, great. Otherwise I would suggest that some kind of transcoding / editing of frame rate data / change to the way your source video is generated is your only option at this point.

Good luck! :o)

Any change in behaviour is in FFMPEG, not in the VSE code itself (which just takes the frames and the playback rate data from ffmpeg as it has always done). But the real source of the error is your video file, whose length, frame count, and playback rate do not add up, and that is not blender's responsibility to fix - given the extremely limited (i.e. near-zero) amount of coding resource available for VSE development, dealing more gracefully with non-compliant video files is about as near to the bottom of the priority list as it's possible to get. If you are able to develop a fix for your edge case that doesn't break anything else, great. Otherwise I would suggest that some kind of transcoding / editing of frame rate data / change to the way your source video is generated is your only option at this point. Good luck! :o)

Louigi Verona commented

2018-11-05 11:03:36 +01:00

I respectfully disagree. Please, see comment https://developer.blender.org/T54655#494818 where I have transcoded a file to have audio of exact same length as video, and the import into Blender still failed. And yet it works completely fine in an old version.

Dilshod commented

2019-01-14 11:24:28 +01:00

Added subscriber: @ddilshod

Dilshod commented

2019-01-14 11:24:28 +01:00

I have the same problem. My workaround was to change the frame rate of my galaxy note 9 to 60 when taking videos in full hd. Then I adjusted the custom rate so it matches the frame rate of 59.06 because the windows file properties shows this rate. Didn't even bother to see the real precise frame rate in VLC because the number would be somewhat of 59.060004001. This setup gave me a little longer audio than the video. The difference is so minor that even in long videos it's unnoticeable, I just cut the end of the audio so it matches the video. To me it's clearly a bug. It's supposed to identify the floating frame rate just like in Shotcut, there the videos are perfect, in Blender for some reason you have to work around it....

Richard Antalik commented

2019-02-22 20:11:34 +01:00

Added subscriber: @iss

Richard Antalik commented

2019-02-22 20:11:34 +01:00

No description provided.

Richard Antalik commented

2019-06-07 01:23:05 +02:00

Changed status from 'Open' to: 'Archived'

Richard Antalik closed this issue

2019-06-07 01:23:05 +02:00

Richard Antalik self-assigned this 2019-06-07 01:23:05 +02:00

Richard Antalik commented

2019-06-07 01:23:05 +02:00

I am once again looking at this task, and see, that the sample video has variable frame rate.

We can not support every single video codec. We do support most "mainstream" codecs. I am not aware about any demand for supporting variable frame rate codecs in Blender.

PS: You say that Blender version 2.76b worked. It may seem, like it did, but I doubt, that file was decoded properly.

PPS: Even if Blender would support this codec, you would probably want to make proxies for this footage. You can use indexed codec when converting from VFR to CFR and skip proxy building in Blender.

I am once again looking at this task, and see, that the sample video has variable frame rate. We can not support every single video codec. We do support most "mainstream" codecs. I am not aware about any demand for supporting variable frame rate codecs in Blender. PS: You say that Blender version 2.76b worked. It may seem, like it did, but I doubt, that file was decoded properly. PPS: Even if Blender would support this codec, you would probably want to make proxies for this footage. You can use indexed codec when converting from VFR to CFR and skip proxy building in Blender.

Louigi Verona commented

2019-06-07 08:53:19 +02:00

Changed status from 'Archived' to: 'Open'

Louigi Verona reopened this issue

2019-06-07 08:53:19 +02:00

Louigi Verona commented

2019-06-07 08:53:19 +02:00

Dear Richard,

This ticket is not at all about supporting "a codec". If you would, in fact, look at this comment , you would see that videos with constant bit rate have exactly the same problem. This is the second time I have to say this, because people fail to read the discussion. I will now edit this information into the original description so that this doesn't happen again.

Moreover, I have tried importing videos from various devices, random videos downloaded from YouTube - and each and every one of them has this problem. And none of them have this problem in 2.76b. In fact, I was not able to find a video which doesn't have this problem, and everyone else whom I asked to check on their machines have been able to duplicate the problem.

So, this is not a ticket about supporting a codec, this is a ticket describing a bug which makes using Blender VSE for imported videos (any videos with video+audio, any codec) impossible after version 2.76b.

Dear Richard, This ticket is not at all about supporting "a codec". If you would, in fact, look at [this comment ](https://developer.blender.org/T54655#494818), you would see that videos with constant bit rate have exactly the same problem. This is the second time I have to say this, because people fail to read the discussion. I will now edit this information into the original description so that this doesn't happen again. Moreover, I have tried importing videos from various devices, random videos downloaded from YouTube - and *each and every one of them* has this problem. And *none of them* have this problem in 2.76b. In fact, I was not able to find a video which doesn't have this problem, and everyone else whom I asked to check on their machines have been able to duplicate the problem. So, this is not a ticket about supporting a codec, this is a ticket describing a bug which makes using Blender VSE for imported videos (any videos with video+audio, any codec) impossible after version 2.76b.

Louigi Verona changed title from ~~Importing any video to VSE results in audio and video having different lengths~~ to Importing any video to VSE results in audio and video having different lengths (not a codec problem, happens to all videos)

2019-06-07 09:12:06 +02:00

Richard Antalik commented

2019-06-07 13:08:20 +02:00

@LouigiVerona Sorry for misunderstanding.
While it's true, that I constantly overlook details, but still sometimes, less is more(description is quite verbose).

Anyway, I reviewed 4 files:

20180415_111352.mp4
- contains 1391 video frames - imported correctly in 2.8. Not saying, that length is "correct", but we can only work with what we got.
- audio length is also correct

Following videos did have small difference(<5frames) in audio and video length - seems good to me.

Most video containers do support storage of audio with length independent to video length. However all these cases, Blender is not responsible for this discrepancy.

Practically speaking, Blender can trim content of audio or video, to be aligned, however this is not really nice thing to do.

@LouigiVerona Sorry for misunderstanding. While it's true, that I constantly overlook details, but still sometimes, less is more(description is quite verbose). Anyway, I reviewed 4 files: - 20180415_111352.mp4 - contains 1391 video frames - imported correctly in 2.8. Not saying, that length is "correct", but we can only work with what we got. - audio length is also correct Following videos did have small difference(<5frames) in audio and video length - seems good to me. - https://www.youtube.com/watch?v=FNLoxaSSQ2A - https://www.youtube.com/watch?v=QBajx0T3BGk - https://www.youtube.com/watch?v=kYPHw8_p2N8 Most video containers do support storage of audio with length independent to video length. However all these cases, Blender is not responsible for this discrepancy. Practically speaking, Blender can trim content of audio or video, to be aligned, however this is not really nice thing to do.

Richard Antalik commented

2019-06-10 02:45:34 +02:00

Changed status from 'Open' to: 'Archived'

Richard Antalik closed this issue

2019-06-10 02:45:34 +02:00

Richard Antalik commented

2019-06-10 02:45:34 +02:00

Closing this again.

I also tested this in 2.76 - 1405 frames imported, but after frame 1391 movie strip output was nothing.
This means, that your file was probably recoded incorrectly, and that 2.76 would also be out of sync.

If you can demonstrate this problem with another file, please create new task for this.

Closing this again. I also tested this in 2.76 - 1405 frames imported, but after frame 1391 movie strip output was nothing. This means, that your file was probably recoded incorrectly, and that 2.76 would also be out of sync. If you can demonstrate this problem with another file, please create new task for this.

Fabien commented

2021-01-28 18:42:10 +01:00

Added subscriber: @Fabien-Marello

Fabien commented

2021-01-28 19:05:26 +01:00

Just adding that the workaround described earlier worked for me :
I converted my file from a "Peak Framerate" mp4 to a "Constant Framerate" m4v with Handbrake. My frame number wasn't divided by nearly 2 anymore (which is not exactly the described problem, that occurs on smaller scales, but it was the single related topic that I found).

Thanks.

In #54655#494737, @Paskperfect wrote:
Yes, this in general is how all cameras and video recorders work, these days. Why? Gone are the days when you needed a bit of magnetic tape to move across a tape-head at a constant rate, or a constant 33 1/3 rotations per minute to faithfully reproduce video or sound.
All readily-available video and audio is compressed in some form, to either make it fit into a smaller distribution medium, or stream "faster" through phone lines, to save someone time, or money.
Before you load a file for editing in Blender, consider using a program (such as Handbrake) that can convert between variable-rate and constant-rate frames-per-second formats. You might also try FFMPeg, which is used by both Blender and Handbrake to do their video conversions for exporting to different formats. Handbrake is a lot easier to work with, than FFMPeg, though.
Other editing suites do similar conversions, without telling you about it, and still take just as long to process.

Just adding that the workaround described earlier worked for me : I converted my file from a "Peak Framerate" mp4 to a "Constant Framerate" m4v with Handbrake. My frame number wasn't divided by nearly 2 anymore (which is not exactly the described problem, that occurs on smaller scales, but it was the single related topic that I found). Thanks. > In #54655#494737, @Paskperfect wrote: > Yes, this in general is how all cameras and video recorders work, these days. Why? Gone are the days when you needed a bit of magnetic tape to move across a tape-head at a constant rate, or a constant 33 1/3 rotations per minute to faithfully reproduce video or sound. > All readily-available video and audio is compressed in some form, to either make it fit into a smaller distribution medium, or stream "faster" through phone lines, to save someone time, or money. > Before you load a file for editing in Blender, consider using a program (such as Handbrake) that can convert between variable-rate and constant-rate frames-per-second formats. You might also try FFMPeg, which is used by both Blender and Handbrake to do their video conversions for exporting to different formats. Handbrake is a lot easier to work with, than FFMPeg, though. > Other editing suites do similar conversions, without telling you about it, and still take just as long to process.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Importing any video to VSE results in audio and video having different lengths (not a codec problem, happens to all videos) #54655