OpenShot Displays Incorrect Duration for VP9 Encoded WebM Files

[angelsen]

Title: Imported WebM Video File Shows Incorrect Duration

Description:

I'm experiencing an issue with OpenShot (version 3.1.1) on my Linux platform (Manjaro 6.1.26-1). When I import a .webm video file, the duration is reported incorrectly in OpenShot. The actual duration of the video (as shown using exiftool) is 3 minutes and 14 seconds, but OpenShot is not displaying this correct duration.

Here are the details of the video file using exiftool:

ExifTool Version Number         : 12.60
File Name                       : Screencast.webm
Directory                       : .
File Size                       : 4.2 MB
File Modification Date/Time     : 2023:05:11 19:25:03+02:00
File Access Date/Time           : 2023:05:11 19:21:49+02:00
File Inode Change Date/Time     : 2023:05:11 21:36:53+02:00
File Permissions                : -rw-r--r--
File Type                       : WEBM
File Type Extension             : webm
MIME Type                       : video/webm
Doc Type                        : webm
Doc Type Version                : 2
Doc Type Read Version           : 2
Timecode Scale                  : 1 ms
Duration                        : 0:03:14
Muxing App                      : GStreamer matroskamux version 1.22.1
Writing App                     : GStreamer Matroska muxer
Date/Time Original              : 2023:05:11 17:21:49.813014030456543Z
Track Number                    : 1
Track Type                      : Video
Track UID                       : 4e4f985544766e0a
Track Name                      : Video
Image Width                     : 453
Image Height                    : 974
Video Scan Type                 : Unknown (2)
Video Codec ID                  : V_VP8
Image Size                      : 453x974
Megapixels                      : 0.441

file properties json from within openshot:

{
  "acodec": "",
  "audio_bit_rate": 0,
  "audio_stream_index": -1,
  "audio_timebase": {
    "den": 1,
    "num": 1
  },
  "channel_layout": 4,
  "channels": 0,
  "display_ratio": {
    "den": 974,
    "num": 453
  },
  "duration": 65.06666564941406,
  "file_size": "4209370",
  "fps": {
    "den": 1,
    "num": 30
  },
  "has_audio": false,
  "has_single_image": false,
  "has_video": true,
  "height": 974,
  "id": "USNJK0XN0K",
  "interlaced_frame": false,
  "media_type": "video",
  "metadata": {
    "creation_time": "2023-05-11T17:21:49.813014Z",
    "encoder": "GStreamer matroskamux version 1.22.1",
    "language": "eng",
    "title": "Video"
  },
  "path": "/home/fredrik/Videos/Screencasts/Screencast.webm",
  "pixel_format": 0,
  "pixel_ratio": {
    "den": 1,
    "num": 1
  },
  "sample_rate": 0,
  "top_field_first": true,
  "type": "FFmpegReader",
  "vcodec": "vp8",
  "video_bit_rate": 64693,
  "video_length": "1952",
  "video_stream_index": 0,
  "video_timebase": {
    "den": 1000,
    "num": 1
  },
  "width": 453
}

Here are some relevant lines from the openshot-qt.log:

22:33:38 INFO files_model: Imported media file /home/fredrik/Videos/Screencasts/Screencast.webm
...
22:33:51 INFO preview_thread: LoadFile /home/fredrik/Videos/Screencasts/Screencast.webm

Steps to reproduce:

1. Import a .webm video file to OpenShot.
2. Observe the reported duration of the video in OpenShot.

Expected behavior:

The duration of the video file should match the duration reported by exiftool.

Actual behavior:

The duration of the video file in OpenShot does not match the duration reported by exiftool.

Relevant files:

The issue can be reproduced using the 'Screencast.webm' file, which unfortunately cannot be attached here due to its size. Please let me know if there is any additional information or files I can provide to assist in resolving this issue. openshot-qt.log

Environment:

• OpenShot Version: 3.1.1
• libopenshot Version: 0.3.2
• Operating System: Linux Manjaro 6.1.26-1
• Qt Version: 5.15.8
• PyQt Version: 5.15.9
• Python Version: 3.10.10

Please let me know if there's any additional information I can provide to assist in resolving this

[Colorjet3]

Hello @Angelsen. Sorry to see that you are having an issue with Openshot. Please provide some more details for better troubleshooting:

1. I am not familiar with the Exiftool and a novice Linux user.
2. What is the duration of the .webm file if you use the native Manjaro File Manager? Does this value match Exiftool?
3. Right click on the clip on the Track, select Properties, then find the Duration attribute and note the value. I am assuming this matches the JSON Duration value. Please confirm.

If in step 2 the Manjaro File Manager and Exiftool duration values do not match then there is something about Exiftool and the way it calculates the duration.

If the native Manjaro File Manager and Openshot agree on the duration (this is what I am seeing in Ubuntu 22.10) then I would think that there is no issue.

If you have other details to share to further help troubleshooting that would be great.

[angelsen]

Hello @Colorjet3, thank you for your response and the helpful suggestions.

ExifTool, as you mentioned, is a software program that can read, write, and edit metadata in various file types. It's a very versatile tool, supporting numerous metadata formats including EXIF, GPS, IPTC, XMP, and many others, and is also capable of reading metadata from a wide range of digital cameras. This tool can be very useful in situations where you want to extract or manipulate the metadata of your files.

As for the duration of the .webm file, yes, the values provided by ExifTool and the Manjaro File Manager do match.

1. When I check the duration of the .webm file using the native Manjaro File Manager, it matches the information given by the Exiftool. So, I don't think there is a calculation issue with Exiftool.

2. In Openshot, when I right click on the clip on the Track, select Properties, and check the Duration attribute, it doesn't match the duration given by the Manjaro File Manager and Exiftool. This duration discrepancy only happens with my recent screen recordings that are encoded with VP9. My older recordings, which are encoded with VP8, are imported with the correct length in Openshot.

3. Given that the native Manjaro File Manager, Exiftool and Openshot all agree on the duration of my VP8 recordings, I'm starting to think that the issue might be related to the VP9 encoding of my recent recordings.

Any advice on what I could do next would be appreciated.

[dmkUK]

I had the same issue when trying to edit a webm screencast from ubuntu 22.04.2lts' "print screen", whilst trying to describe another issue. The 30 second ish video played in the default player correctly but would only display the first 10 seconds in openshot.

[Colorjet3]

Thank you @Angelsen for the information. I am going to need to escalate this to the lead developer as I am not sure how to resolve this myself.

[Colorjet3]

Hello @Angelsen I see that this hasn't been addressed by the technical team. Please try converting you .webm file using something like Handbrake. You can convert it back to .webm again or to .mp4. Import this new file into Openshot and see if that looks/works better.

[Keram-Yasin]

I encountered this issue today. All the webm files are up to 10s shorter than the actual length. I have been using OpenShot for quite sometime, this is the only shortcoming that I have found on OpenShot. I hope this issue is resolved soon.

[Colorjet3]

Hello @Keram-Yasin. There is currently no ETA on the fix. However, you should be able to convert your file to a .mp4 using something like VLC, Handbrake, or Shutter Encoder. Shutter Encoder has a "bulk convert" option that will simplify the conversion process. This should fix the issue of missing footage for now.

[Keram-Yasin]

Hi @Colorjet3 , Yeah that was my solution for this issue. I found WinX Video Converter particularly useful to bypass the issue on OpenShot.

[buha]

Same for me, 44 seconds VP8 webm shows as 22 seconds clip in openshot 3.1.1 This should be trivial to reproduce, just record a Gnome screencast to obtain a sample .webm.

[matthew-at-qamcom]

I had the same experience from a screencast taken using Ubuntu's print-screen functionality (Ubuntu 22.04.3 LTS). VLC and Firefox would play the webm correctly. Openshot only displayed the first 10 seconds or so. Converting it to an mp4 using ffmpeg solved the problem.

[yinchuan]

I'm having the same issue. In my case, the video is a screen recording by "print screen" on Ubuntu 22.04. The video is in webm format and has duration 69.03 seconds. After imported to OpenShot, the duration becomes 15.4 seconds.

Environment:

• OpenShot Version: OpenShot-v3.2.0-x86_64
• libopenshot Version: 0.3.3
• Operating System: Ubuntu 22.04.4 LTS

---

I'm pretty sure the correct duration is 69.03 seconds by:

• playing it in Chrome
• palying it in VLC
• using ffprobe to inspect
• checking the video header in binary

The result of ffprobe is:

$ ffprobe -v quiet -print_format json -show_format battle1.webm 
{
    "format": {
        "filename": "battle1.webm",
        "nb_streams": 1,
        "nb_programs": 0,
        "format_name": "matroska,webm",
        "format_long_name": "Matroska / WebM",
        "start_time": "0.000000",
        "duration": "69.031561",
        "size": "13031123",
        "bit_rate": "1510164",
        "probe_score": 100,
        "tags": {
            "encoder": "GStreamer matroskamux version 1.20.3",
            "creation_time": "2024-07-02T22:52:25.941734Z"
        }
    }
}

---

After digging around, I reckon the issue lies in how libopenshot recalculating duration to handle missing frames. The relavent code is:

	float avg_fps = 30.0;
	if (starting_frames_detected > 0 && fps_index > 0) {
		avg_fps = float(starting_frames_detected) / std::min(fps_index, max_fps_index);
	}
	// Verify average FPS is a reasonable value
	if (avg_fps < 8.0) {
		// Invalid FPS assumed, so switching to a sane default FPS instead
		avg_fps = 30.0;
	}
	// Update FPS (truncate average FPS to Integer)
	info.fps = Fraction(int(avg_fps), 1);

	// Update Duration and Length
	if (all_frames_detected > 0) {
		// Use all video frames detected to calculate # of frames
		info.video_length = all_frames_detected;
		info.duration = all_frames_detected / avg_fps;
	} else {
		// Use previous duration to calculate # of frames
		info.video_length = info.duration * avg_fps;
	}

Before this part, info.duration has the correct value of 69.03s which is read from the video header. Value of variables are:

• starting_frames_detected: 4, number of frames in the first 3 seconds
• fps_index: 69, seconds of timestamp after truncaing float part
• max_fps_index: 3, size of array to store the number of frames in the first 3 seconds
• all_frames_detected = 462

So avg_fps = (float)4 / min(69, 3) = 4.0 / 3 = 1.3333, it is then reset to 30.0 since it's less than 8.0(the assumption for the threshold of bad FPS). After that, info.duration is set to 462 / 30.0 = 15.4 which is the value seen in File Properties in OpenShot.

The code gets the correct number of frames 462 which can be verified by:

$ ffprobe -v error -count_frames -select_streams v:0 -show_entries stream=nb_read_frames battle1.webm 
[STREAM]
nb_read_frames=463
[/STREAM]

(I don't know why there is a difference of 1, though it doesn't affect the analysis.)

It seems that libopenshot uses inappropriate assumption for average FPS(frame per second) when processing webm files, particularly screen recordings which tend to have a very low FPS when nothing moves a lot.