Black or blank first frame in exported videos

[N3WWN]

System Details:

• Operating System / Distro: Fedora 25
• OpenShot Version: 2.3.4 (but I'm seen it with all versions, including daily builds, since at least 2.3.1 when I started using OpenShot)

Start a new project, import one mp4 file (which definitely has an image in frame 1), drag it to the timeline, move it to the start of the timeline, export as mp4.

Exported video will have 1 black or blank frame at the beginning.

[DylanC]

@N3WWN - Any luck with this on V2.4 daily build?

[N3WWN]

Thanks for checking in @DylanC !

The two videos that I most recently rendered with OpenShot-v2.4.0-1-g8a71c3d-55-646-x86_64.AppImage have a blank first frame, so the issue is still present.

Doing some more investigation, I used ffprobe to find the start time of the video stream.

For the videos which are rendered by OpenShot, the start time is not 0.000000, but at the time of the 2nd frame. If I run the videos through ffmpeg to set the moov atom to the start of the video with ffmpeg -i input.mp4 -movflags faststart -codec:v copy -codec:a copy output.mp4, the start time is 0.000000 and the first frame contains video.

$ ffprobe input.mp4 ffprobe version 3.0.1 Copyright (c) 2007-2016 the FFmpeg developers built with Apple LLVM version 8.1.0 (clang-802.0.42) configuration: --prefix=/usr/local/Cellar/ffmpeg/3.0.1 --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-hardcoded-tables --enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-opencl --enable-libx264 --enable-libmp3lame --enable-libxvid --enable-vda libavutil 55. 17.103 / 55. 17.103 libavcodec 57. 24.102 / 57. 24.102 libavformat 57. 25.100 / 57. 25.100 libavdevice 57. 0.101 / 57. 0.101 libavfilter 6. 31.100 / 6. 31.100 libavresample 3. 0. 0 / 3. 0. 0 libswscale 4. 0.100 / 4. 0.100 libswresample 2. 0.101 / 2. 0.101 libpostproc 54. 0.100 / 54. 0.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'input.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf54.20.4 Duration: 00:03:38.25, start: 0.016667, bitrate: 24730 kb/s Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080, 24534 kb/s, 60 fps, 60 tbr, 60 tbn, 120 tbc (default) Metadata: handler_name : VideoHandler Stream #0:1(und): Audio: ac3 (ac-3 / 0x332D6361), 44100 Hz, stereo, fltp, 192 kb/s (default) Metadata: handler_name : SoundHandler Side data: audio service type: main

Since that output formats poorly, how about I just grep out the important portion:

$ ffprobe input.mp4 2>&1 | grep start Duration: 00:03:38.25, start: 0.016667, bitrate: 24730 kb/s

after relocating the moov atom:

$ ffprobe output.mp4 2>&1 | grep start Duration: 00:03:38.25, start: 0.000000, bitrate: 24730 kb/s

As you can see, the duration is exactly the same, but the mp4 generated with OpenShot doesn't start for 0.016667 (1/60s or 1 frame) into the video.

BTW, speaking of relocating the moov atom, it would be very helpful to be able to set options like this (or other ffmpeg options) within OpenShot so that I don't have to remember to do this (and double the disk space requirement) performing this step after OpenShot has completed rendering.

[DylanC]

@N3WWN - Thanks, marking this as a confirmed bug.

[DylanC]

@N3WWN - Still the same in v2.4.1?

[N3WWN]

@DylanC - Yup, still a black/blank frame at the start of the video created by OpenShot and ffprobe shows the start of the video at 0.016667s:

$ ffprobe "First frame blank test 171120.mp4" 2>&1 | grep start Duration: 00:00:25.25, start: 0.016667, bitrate: 14556 kb/s

ETA: This is with OpenShot-v2.4.1-x86_64.AppImage

[DylanC]

@N3WWN - Thanks!

[peanutbutterandcrackers]

@N3WWN - Could you perhaps submit a PR to fix this, good sir? You have the know-how to fix this issue.

Also, strange... I don't think I have noticed this. I think i will try to test this on my machines soon....

[N3WWN]

As a quick update, this is still an issue with OpenShot v2.5.0:

$ ffprobe DSS-Winter-Classic-2020.mp4 2>&1 | grep start
  Duration: 00:06:39.00, start: 0.016016, bitrate: 20183 kb/s

Start frame is still at the 2nd frame in the 60 fps video and not at 0.000000.

[SuslikV]

@N3WWN The start reported by ffmpeg is just first pts/dts in seconds, which is not always 0. The 0.016016 sec is less than 1 frame for 60 fps. What issues it causes for you?

[N3WWN]

Sorry, you're right... 0.016016s is slightly less than 1 frame. 😉 Originally the start frame was always 0.016667s, which is exactly 1 frame.

Where I see the problem is that I use the OpenShot rendered videos several places on various platforms.

Some of them generate thumbnails based on the first frame of each video, so all of the thumbnails are just a blank/black frame.

Many video players also start by displaying the frame at 0.000000s, so the display is blank until you hit play. This can cause disruptions to presentation flow where the first frame is used like a slide to introduce the video that you are about the play.

It's not a HUGE problem, but it's very odd behavior and seems to be unique to OpenShot.

Manually running the rendered via through ffmpeg without re-encoding (using -codec:v copy -codec:a copy) to fix the first frame seems an unnecessary and tedious step. 😃

[SuslikV]

@N3WWN remux can alternate the timestamps of the movie. This highly depends of input fps given to the encoder etc.

[N3WWN]

I almost always have a still image (png or svg) on one or more tracks at the very start of the timeline, so there shouldn't be any issues with input frame rate.

[stale[bot]]

Thank you so much for submitting an issue to help improve OpenShot Video Editor. We are sorry about this, but this particular issue has gone unnoticed for quite some time. To help keep the OpenShot GitHub Issue Tracker organized and focused, we must ensure that every issue is correctly labelled and triaged, to get the proper attention. This issue will be closed, as it meets the following criteria: - No activity in the past 180 days - No one is assigned to this issue We'd like to ask you to help us out and determine whether this issue should be reopened. - If this issue is reporting a bug, please can you attempt to reproduce on the latest daily build to help us to understand whether the bug still needs our attention. - If this issue is proposing a new feature, please can you verify whether the feature proposal is still relevant. Thanks again for your help!

[N3WWN]

I can confirm that this is still an issue.

The most recent daily build that I've used is OpenShot-v2.5.1-dev2-1603140815-07a447c9-78db4b94-x86_64.AppImage from Oct 19, 2020. That version continues to have a black/blank first frame.

[stale[bot]]

Thank you so much for submitting an issue to help improve OpenShot Video Editor. We are sorry about this, but this particular issue has gone unnoticed for quite some time. To help keep the OpenShot GitHub Issue Tracker organized and focused, we must ensure that every issue is correctly labelled and triaged, to get the proper attention.

This issue will be closed, as it meets the following criteria:

• No activity in the past 180 days
• No one is assigned to this issue

We'd like to ask you to help us out and determine whether this issue should be reopened.

• If this issue is reporting a bug, please can you attempt to reproduce on the latest daily build to help us to understand whether the bug still needs our attention.
• If this issue is proposing a new feature, please can you verify whether the feature proposal is still relevant.

Thanks again for your help!

[N3WWN]

Confirmed that this is still an issue in the most recent nightly build (April 26, 2021, 6:02 a.m.): https://github.com/OpenShot/openshot-qt/releases/download/daily/OpenShot-v2.5.1-dev2-daily-7320-a00bbb76-503515e6-x86_64.dmg

[guanzhangrtk]

I'm new to OpenShot and just installed version 2.5.1 on a MacBook Pro running Big Sur 11.3.1. All I did was export a video which I split and the exported video has a blank/black first frame. The source .MOV video does not have this. Just wondering if I did something wrong or if there is any workaround that doesn't include re-encoding the entire video, thanks much!

EDIT: Just want to add that it doesn't matter whether I export starting from frame 1 or frame 1000, the resulting exported video will always have a blank first frame. Will test the latest daily in a bit.

[N3WWN]

@guanzhangrtk No, you're not doing anything wrong. That behavior is exactly why I opened this issue :)

Manually processing the video via ffmpeg without re-encoding (using -codec:v copy -codec:a copy or -c copy) will fix it and is very fast.

[guanzhangrtk]

Thanks @N3WWN, the command ffmpeg -i <input> -c copy <output> works, but to quote you:

Manually running the rendered via through ffmpeg without re-encoding to fix the first frame seems an unnecessary and tedious step. 😃

I hope that this bug can be fixed in future versions!

[JacksonRG]

@N3WWN @guanzhangrtk Just to get a better idea of how to treat this bug: Do either of you encounter this bug when exporting to a specific video format?

[guanzhangrtk]

@JacksonRG Thanks for the response. As far as I know the bug is triggered regardless of which video format is used: I've tried mpeg4, mov, as well as a couple different profiles and they're all the same. If you need any additional info please let me know!

[N3WWN]

@JacksonRG I've only ever exported to mp4 and see it with every profile that I've tried (mostly the 1080p and 4k ones).

[JacksonRG]

Good to know. The files I export do show a blank frame In my file viewer. (Though vlc won't seem to rewind to the 0th frame. I'll check out the export code in the library.

[guanzhangrtk]

EDIT: Just want to add that it doesn't matter whether I export starting from frame 1 or frame 1000, the resulting exported video will always have a blank first frame. Will test the latest daily in a bit.

Just to close the loop, I just tested OpenShot-v2.5.1-dev3-daily-7635-d9ea98eb-92ff6084-x86_64 and exported videos still show the blank first frame. Thanks for looking into this!

[JacksonRG]

@guanzhangrtk Thanks. Good to know. I probably just have to find somewhere that the start is displaced by the duration of one frame. (thanks to you and @N3WWN's detective work, figuring out what time the first frame is actually located.

[guanzhangrtk]

I'm happy to report that as of 2.6.1 this issue has been fixed (at least on macOS). So someone else could probably close the ticket after confirming. However I'm encountering a whole bunch of other issues with the latest version which I will open another ticket for :-)

[stale[bot]]

Thank you so much for submitting an issue to help improve OpenShot Video Editor. We are sorry about this, but this particular issue has gone unnoticed for quite some time. To help keep the OpenShot GitHub Issue Tracker organized and focused, we must ensure that every issue is correctly labelled and triaged, to get the proper attention.

This issue will be closed, as it meets the following criteria:

• No activity in the past 180 days
• No one is assigned to this issue

We'd like to ask you to help us out and determine whether this issue should be reopened.

• If this issue is reporting a bug, please can you attempt to reproduce on the latest daily build to help us to understand whether the bug still needs our attention.
• If this issue is proposing a new feature, please can you verify whether the feature proposal is still relevant.

Thanks again for your help!

[N3WWN]

@guanzhangrtk Do you happen to know which commit fixed this issue? I won't have opportunity to test this for myself for another few weeks ($dayjob workload way too high), but I'm looking forward to its resolution :)

[guanzhangrtk]

@N3WWN Sorry I have no idea, I just know that 2.6.1 no longer has the issue. Also sorry to say but I have switched over to using Shotcut as I have encountered a bunch of other issues with OpenShot which I didn't feel like was going to get looked at soon so I won't probably be coming back to this. Good luck!

[stale[bot]]

Thank you so much for submitting an issue to help improve OpenShot Video Editor. We are sorry about this, but this particular issue has gone unnoticed for quite some time. To help keep the OpenShot GitHub Issue Tracker organized and focused, we must ensure that every issue is correctly labelled and triaged, to get the proper attention.

This issue will be closed, as it meets the following criteria:

• No activity in the past 180 days
• No one is assigned to this issue

We'd like to ask you to help us out and determine whether this issue should be reopened.

• If this issue is reporting a bug, please can you attempt to reproduce on the latest daily build to help us to understand whether the bug still needs our attention.
• If this issue is proposing a new feature, please can you verify whether the feature proposal is still relevant.

Thanks again for your help!