First frame of encoding is black

[ph471]

Description of problem or question:

Whenever I encode a video, the first frame of the video is black. This means that its thumbnail is black whenever you send it in Discord.


Steps to reproduce the problem (If Applicable):

Perhaps encode a video using the settings from my Activity Log


HandBrake version (e.g., 1.0.0):

1.2.2


Operating system and version (e.g., Ubuntu 16.04 LTS, macOS 10.13 High Sierra, Windows 10 Creators Update):

Windows 10 Education


HandBrake Activity Log ***required*** (see How-to get an activity log)

https://we.tl/t-v4GPufblgY

[BradleyS]

Disable the Align A/V Start setting on the Summary tab. Doing this could ruin audio video sync if your video has MP4 edit lists.

[ph471]

Disable the Align A/V Start setting on the Summary tab. Doing this could ruin audio video sync if your video has MP4 edit lists.

Thanks, this fixed my problem.

[JohnAStebbins]

Disable the Align A/V Start setting on the Summary tab. Doing this could ruin audio video sync if your video has MP4 edit lists.

I thought about mentioning this, but the log indicated that audio and video streams both started at PTS 0. So there should not have been any initial blank frames. But now that I think about it, audio pre-roll may also lead to the need for an initial blank frame.

Perhaps we should modify the behaviour to extend the start time of the first frame rather than inserting blank frames?

[BradleyS]

Seems reasonable.

[JohnAStebbins]

Seems reasonable.

Except that I can't reproduce the issue. So I'm not exactly sure that the problem is here Audio pre-roll isn't factored in till *after* sync (in the encoder) so it's not that. Sync sees that the streams start at the same time, so I have no idea why there would be a blank frame. A source sample would be helpful if that's possible.

Extending the start time is probably still a good idea, at least for small differences in PTS between streams. But there may be something more *interesting* happening here that should also be investigated.

[JohnAStebbins]

Ah, never mind. No need for a sample. I see why the log indicates that both streams start at 0. This log indicates the state of the buffers output by sync, not the input to sync. Everything makes sense now

[JohnAStebbins]

Well, it looks like we are already doing what I was thinking we should do If the gap between start times at the beginning of the streams is less than one frame period, we are extending the start time and frame duration to fill the gap. If the gap is greater than a frame period, we insert black frames of the appropriate frame duration.

I'm hesitant to duplicate the first frame for extended periods of time as that is going to change the presentation so that it doesn't match the original video. I think we are already doing the right thing in this case.

[BradleyS]

I was just thinking the same thing about extending the first frame too long being an issue. Sounds like we're smarter than we remember.

[rollin_eng]

I was just thinking the same thing about extending the first frame too long being an issue. Sounds like we're smarter than we remember.

That can’t possibly be true