search

OpenShot / openshot-qt

OpenShot Video Editor is an award-winning free and open-source video editor for Linux, Mac, and Windows, and is dedicated to delivering high quality video editing and animation solutions to the world.
http://www.openshot.org
Other
4.13k stars 521 forks source link

OpenShot Displays Incorrect Duration for VP9 Encoded WebM Files #5235

Open angelsen opened 1 year ago

angelsen commented 1 year ago

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:

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

Colorjet3 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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

buha commented 7 months ago

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 commented 7 months ago

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 commented 5 days ago

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:

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

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:

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.