Incorrect Framerate for videos imported from OBS (2.79+) #53857

New Issue

Rusty Widget · 2018-01-22T21:53:09+01:00

Rusty Widget commented

2018-01-22 21:53:09 +01:00

System Information
Windows 7, 8GB RAM, GeForce 1060 with 6GB VRAM

Blender Version
Broken: All versions above 2.79, including 2.79 and 2.8 test builds
Worked: 2.78 and any previous version I've used for video editing, as far back as 2.5.

Short description of error
Videos which are correctly interpreted as being 30fps in 2.78 are being loaded in as 1000fps in 2.79. Somehow, the video playback is still fine, but the number of frames is incorrect and zoom in the vse panel is limited. A 2 minute video has over 120,000 frames. Altering the framerate in the rendering panel only alters the duration of the audio. mp4 files files produced by ffmpeg/blender seem to be fine, but mp4/mkv containers produced by OBS induce the issue.

Exact steps for others to reproduce the error
Launch blender or reload startup file. Open VSE. Add attached video file to VSE by any method. Check the render properties panel. Blender has set framerate to "Custom (1000.0)" with some other unfamiliar variables defined below. Repeat process in 2.78 and notice that the correct framerate (30) is automatically detected, meaning this is a recent change in how blender handles frame rate detection.

Attached is a video that demonstrates the issue for testing purposes.

2018-01-22 15-30-49.mkv

**System Information** Windows 7, 8GB RAM, GeForce 1060 with 6GB VRAM **Blender Version** Broken: All versions above 2.79, including 2.79 and 2.8 test builds Worked: 2.78 and any previous version I've used for video editing, as far back as 2.5. **Short description of error** Videos which are correctly interpreted as being 30fps in 2.78 are being loaded in as 1000fps in 2.79. Somehow, the video playback is still fine, but the number of frames is incorrect and zoom in the vse panel is limited. A 2 minute video has over 120,000 frames. Altering the framerate in the rendering panel only alters the duration of the audio. mp4 files files produced by ffmpeg/blender seem to be fine, but mp4/mkv containers produced by OBS induce the issue. **Exact steps for others to reproduce the error** Launch blender or reload startup file. Open VSE. Add attached video file to VSE by any method. Check the render properties panel. Blender has set framerate to "Custom (1000.0)" with some other unfamiliar variables defined below. Repeat process in 2.78 and notice that the correct framerate (30) is automatically detected, meaning this is a recent change in how blender handles frame rate detection. Attached is a video that demonstrates the issue for testing purposes. [2018-01-22 15-30-49.mkv](https://archive.blender.org/developer/F1943614/2018-01-22_15-30-49.mkv)

Rusty Widget commented

2018-01-22 21:53:09 +01:00

Added subscriber: @r_widget

blender-admin commented

2018-01-22 21:53:09 +01:00

#54148 was marked as duplicate of this issue

Ray molenkamp commented

2018-01-22 21:59:45 +01:00

Added subscriber: @LazyDodo

Ray molenkamp commented

2018-01-22 21:59:45 +01:00

i'm pretty sure this one is already fixed, please try a build from http://builder.blender.org to validate the issue indeed is already solved.

Rusty Widget commented

2018-01-22 22:16:40 +01:00

I just downloaded blender-2.79-42a5624-win64 and blender-2.80-4d3d002-win64 a few hours ago, and the bug occurs in both, so I would say it is not fixed.

Ray molenkamp commented

2018-01-22 22:24:22 +01:00

The issue existed on the export side, not the import side, the mkv attached is actually set to 1000 fps

Input #0, matroska,webm, from '2018-01-22 15-30-49.mkv':
  Metadata:
    ENCODER         : Lavf57.84.100
  Duration: 00:00:03.03, start: 0.000000, bitrate: 913 kb/s
    Stream #0:0: Video: h264 (Main), yuv420p(tv, bt470bg/unknown/unknown), 1920x1080 [SAR 1:1 DAR 16:9], 1k fps, 30 tbr, 1k tbn, 60 tbc (default)
    Metadata:
      DURATION        : 00:00:03.033000000
    Stream #0:1: Audio: aac (LC), 44100 Hz, stereo, fltp (default)
    Metadata:
      title           : Track1
      DURATION        : 00:00:02.926000000

The issue existed on the export side, not the import side, the mkv attached is actually set to 1000 fps ``` Input #0, matroska,webm, from '2018-01-22 15-30-49.mkv': Metadata: ENCODER : Lavf57.84.100 Duration: 00:00:03.03, start: 0.000000, bitrate: 913 kb/s Stream #0:0: Video: h264 (Main), yuv420p(tv, bt470bg/unknown/unknown), 1920x1080 [SAR 1:1 DAR 16:9], 1k fps, 30 tbr, 1k tbn, 60 tbc (default) Metadata: DURATION : 00:00:03.033000000 Stream #0:1: Audio: aac (LC), 44100 Hz, stereo, fltp (default) Metadata: title : Track1 DURATION : 00:00:02.926000000 ````

Rusty Widget commented

2018-01-22 22:33:24 +01:00

But the same file loads fine in 2.78 and all previous versions of blender, and although it's odd to see that OBS is exporting a video with 1k fps, tbr defines the frame rate that the demuxer should use.

ChristopherAnderssarian commented

2018-01-23 15:29:20 +01:00

Added subscriber: @ChristopherAnderssarian

ChristopherAnderssarian commented

2018-01-23 15:29:21 +01:00

This comment was removed by @ChristopherAnderssarian

*This comment was removed by @ChristopherAnderssarian*

Philipp Oeser commented

2018-01-30 17:30:40 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2018-01-30 17:30:40 +01:00

tbr defines the frame rate that the demuxer should use

where is this information from?

> tbr defines the frame rate that the demuxer should use where is this information from?

Philipp Oeser commented

2018-01-30 17:52:26 +01:00

Added subscribers: @Sergey, @troy_s

Philipp Oeser commented

2018-01-30 17:52:26 +01:00

maybe @troy_s or @Sergey know better [about the fps vs. tbr]?

ChristopherAnderssarian commented

2018-02-07 18:36:54 +01:00

Shows reported results in blender-2.79-66521b3

Henrik Berglund commented

2018-02-07 21:01:41 +01:00

Added subscriber: @cyaoeu

Henrik Berglund commented

2018-02-07 21:01:41 +01:00

The video playback is only fine because by default Blender sets the scene fps to the video fps. If you disable use video fps when adding the file (down left) you get an extremely slow video.

There is indeed something wrong with Blender's autodetection of fps. Using tbr instead of fps could be useful if the fps value is wrong (like the "1000 fps" OBS videos which play normally in any video player).

Also from what I could see the code uses r_frame_rate for detecting the fps, but the video I loaded in Blender showed 1000 fps even though ffprobe showed 60/1 fps for the video which made me even more confused. The avg_frame_rate did show 1000/1 though.

The video playback is only fine because by default Blender sets the scene fps to the video fps. If you disable use video fps when adding the file (down left) you get an extremely slow video. There is indeed something wrong with Blender's autodetection of fps. Using tbr instead of fps could be useful if the fps value is wrong (like the "1000 fps" OBS videos which play normally in any video player). Also from what I could see the code uses r_frame_rate for detecting the fps, but the video I loaded in Blender showed 1000 fps even though ffprobe showed 60/1 fps for the video which made me even more confused. The avg_frame_rate did show 1000/1 though. ![ffprobe.png](https://archive.blender.org/developer/F2180900/ffprobe.png)

Henrik Berglund commented

2018-02-07 21:28:28 +01:00

Maybe some matroska (.mkv) weirdness? https://matroska.org/technical/specs/notes.html

Bastien Montagne commented

2018-02-26 10:06:49 +01:00

Added subscribers: @Mapper720-4, @mont29

Sergey Sharybin was assigned by Bastien Montagne

2018-02-26 10:08:00 +01:00

Bastien Montagne commented

2018-02-26 10:08:00 +01:00

This looks more like an FFMPEG issue tbh…

Sergey Sharybin commented

2018-02-26 10:47:11 +01:00

tbr is indeed what one is supposed to be using here, at least as per FFmpeg documentation. The issue is: libav removed it (probably, because it was "guessed" value). tbn is what exists in both libav and FFmpeg, but seems it is not trustful value. Since FFmpeg is what all distors are coming back to, and what is was supposed to be used will try to get code back to use tbr when using FFmpeg.

`tbr` is indeed what one is supposed to be using here, at least as per FFmpeg documentation. The issue is: `libav` removed it (probably, because it was "guessed" value). `tbn` is what exists in both libav and FFmpeg, but seems it is not trustful value. Since FFmpeg is what all distors are coming back to, and what is was supposed to be used will try to get code back to use `tbr` when using FFmpeg.

blender-admin commented

2018-02-26 16:39:18 +01:00

This issue was referenced by 370a2d6917

This issue was referenced by 370a2d6917ebd8df5177fe4854a447e3839dddaa

Sergey Sharybin commented

2018-03-09 10:53:44 +01:00

Changed status from 'Open' to: 'Resolved'

Sergey Sharybin closed this issue

2018-03-09 10:53:44 +01:00

Ben Moore commented

2020-11-13 00:23:09 +01:00

Added subscriber: @Twitching_astronaut