[Fixed] Unwanted - Handbrake set the first frame to black

[Elan]

Hi,

I have an issue because Handbrake make the first frame of my video black. Even if I try to skip the first frame or even more using an offset, the first frame of the encoded video is always black.

This is an unwanted behaviour because I will publish multiple short videos on a popular website frontpage and I don't want to have a black flash frame each time they loop.

I use Handbrake version 0.10.0 x86_64 (2014112200) on OSX

You can view a 10 seconds preview in action at :
https://dl.dropboxusercontent.com/u/482 ... index.html

I zip the source, encode, preset and log files in my dropbox : (<10MB)
https://dl.dropboxusercontent.com/u/482 ... kFrame.zip

Thank you,

Eric

[Deleted User 11865]

Does it go away if you add "bframes=0" without quotes to the additional x264 options text box?

[Deleted User 13735]

Good call, Mr. Rodeo.

Any b-frames adds one blank frame at the beginning; b-pyramid actually adds two.
Also, to minimize the initial seek times, be sure to enable Web Optimized.
And don't use mp3 audio. It adds its own little delay.

It's nothing to do with Handbrake; it's a format thing.
With a fast CPU, you should be able to achieve "almost" seamless looping, as I have done with my Android wallpaper.

[Ritsuka]

mp4v2 muxer used to add an edit list to move the first video pts to 0. Libav adds an empty edit list at the start to fill the b-frames offset. Personally I preferred how it worked before but I am not going to write a patch to change it, so I will not complain any further .

[Elan]

Thank you for the additional informations.

I don't think it's a format thing because using FFMPEG with the same x264 encoding options didn't set a first black frame. Also with bframes=0 give me a file of 1.3MB instead of 816KB.

Code: Select all

ffmpeg -i source.mp4 -pix_fmt yuv420p -c:v libx264 -preset medium -crf 22 -x264opts "weightp=0:trellis=0:b-adapt=0:ref=3:bframes=3:direct=spatial:me=umh:subq=9:no-mbtree=1:level=3.1" -movflags faststart -y FFMPEG-Output.mp4

I need the smallest file with good compatibility (minimum iPad generation 1) because the frontage has more that a hundred millions monthly views with multiple devices. As the videos will be encoded by some users with little to no technical knowledge I prefer teach them how to use Handbrake with a preset instead of FFMPEG in CLI.

[Deleted User 11865]

I think ffmpeg might have a slight A/V desync (either that or they added features to their MP4 muxer which haven't yet made their way into HandBrake), though I'm not really sure. Maybe if you can convince ritsuka to patch libavformat…

[Deleted User 13735]

Yes, b-frames carry a huge compression advantage, but they can also put a burden on slower devices.

[Elan]

I would appreciate if this issue could be added to the bug list to be fixed in a future roadmap. You should agree with me that this is not a normal behaviour for the output content to be different from the source.

I also expose a clear usage case where it cause a problem.

[superplussed]

I would second Elan's request. My previous version of Handbrake didn't do this, but my upgrade caused this new problem to start happening. It is clearly a bug and not desirable.

[Elan]

Thanks superplussed for the idea ! I will use an older version...

[s55]

Marked as confirmed for now.

[JohnAStebbins]

Fixed. Please try it out in the next nightly build.
http://trac.handbrake.fr/changeset/6865