Encoding shifts video 2 frames back

HandBrake for Windows support
Forum rules
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
veresk
Posts: 15
Joined: Thu Aug 23, 2018 8:12 pm

Encoding shifts video 2 frames back

Post by veresk » Thu Aug 23, 2018 10:07 pm

Description of problem or question:

HandBrake encodes video file with 2 frames shifted back (another words - video is placed 2 frames earlier). Evenly through out the whole video.

Steps to reproduce the problem (If Applicable):

I rendered out from Adobe After Effects (NOT Adobe Media Encoder) an uncompressed AVI (default settings) and encoded it with HandBrake.

HandBrake settings:
FPS same as source, constant
Grain (tried None)
Profile Auto
Constant quality
Audio - Auto passthru (tried AAC), but audio is not the case here. Audio is not shifted!
Align A/V start didn't help.


Tried different settings, different videos. The result is solid - video is 2 frames earlier, then in the original uncompressed file.

An IMPORTANT note:
All of my videos starts with black screen and silence.
The 1st frame that contains some image is 2 frames earlier then the first sound starts.
For instance:
frame #10 starts to show something
frame #12 starts to sound something

HandBrake version (e.g., 1.0.0):

1.1.1

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

Win7x64

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

https://pastebin.com/LGSdJY3G

User avatar
JohnAStebbins
HandBrake Team
Posts: 5181
Joined: Sat Feb 09, 2008 7:21 pm

Re: Encoding shifts video 2 frames back

Post by JohnAStebbins » Thu Aug 23, 2018 11:10 pm

Is it missing any video frames? Are any video frames longer or shorter than they should be?

If no to both, then is the audio actually starting when it should? I.e. is the audio starting later than it should rather than the video starting earlier?

What is your methodology for determining when audio starts relative to the video?

veresk
Posts: 15
Joined: Thu Aug 23, 2018 8:12 pm

Re: Encoding shifts video 2 frames back

Post by veresk » Wed Sep 05, 2018 11:03 am

Thank you for a quick respond and excuse me for not responding back soon. I thought there will be a notification e-mail. Never mind =)

My methodology is simple: in editing software I'm placing the encoded file on top of the original. So I can see a waveform of both files and a video of course.

The encoded file is 2 frames shorter! These 2 frames were cut off from a start of the video in the process of encoding. I checked the final 2 frames - they are visually identical, just shifted backwards in time (the whole video is shifted 2 frames backwards!).

There's no point of creating a special testing video with a timecode because in all of my videos I NEED first 10 frames black (and first 12 frames silent).

This is a tricky situation, so I'd like to highlight this again:
All of my videos starts with black screen and silence.
A frame that contains some image is 2 frames earlier then the first sound starts.
Specifically:
frames 0-9 are black
frame #10 starts to show my static logo
frame #12 starts a "bang" sound
(in the encoded video: frame #8 starts to show my static logo, but "bang" sound is still at frame #12)

So my guess is - HandBreak sees this as an unsync and tries to do some video shifting to match frame #10 (logo appears) with frame #12 (audio begins). But for some reason he shifts video even further from the point where audio starts =)

From now on I will check for a reply daily! =)

User avatar
JohnAStebbins
HandBrake Team
Posts: 5181
Joined: Sat Feb 09, 2008 7:21 pm

Re: Encoding shifts video 2 frames back

Post by JohnAStebbins » Wed Sep 05, 2018 2:59 pm

Do you know how many frames are actually in your original video?

The log says the duration is 4:44.07 (284.07 seconds). At a framerate of 23.976, that's 6810.86232 frames. The log reports that 6811 frames were output. So the numbers all add up. Nothing missing according to what's reported in the log. So I'm wondering if those numbers are correct.

veresk
Posts: 15
Joined: Thu Aug 23, 2018 8:12 pm

Re: Encoding shifts video 2 frames back

Post by veresk » Wed Sep 05, 2018 3:53 pm

6811 - that's the original
6809 - that's the encoded output

I've made the encoding twice! Every time I've configured all the settings manually. With minor changes (you see the log from the last encoding).

Believe me, the exact(!) same thing was with another 2 videos. But there is one video which was encoded properly! And the only difference was the length. Troubled videos were 4-6 min. Properly encoded video was 2:23.

Everything else in my videos is the same:
- resolution
- framerate
- grainy picture (I used both "Grain" tune and "None")
- weird start (image at frame 10, sound at frame 12)
- rendered out from After Effects (not Media Encoder) with default uncompressed settings (avi).

User avatar
JohnAStebbins
HandBrake Team
Posts: 5181
Joined: Sat Feb 09, 2008 7:21 pm

Re: Encoding shifts video 2 frames back

Post by JohnAStebbins » Wed Sep 05, 2018 4:01 pm

The encoded output definitely has 6811 frames, from your log:

Code: Select all

[00:03:46] mux: track 0, 6811 frames, 1304093854 bytes, 36725.28 kbps, fifo 512
This line in the log comes from the muxer (very last stage in the encoding pipeline). It counts every frame that gets output. How are you determining the number of frames in the output?

veresk
Posts: 15
Joined: Thu Aug 23, 2018 8:12 pm

Re: Encoding shifts video 2 frames back

Post by veresk » Wed Sep 05, 2018 4:38 pm

After Effects shows the frame number in it's info panel.
PLUS - I can see the encoded video is shorter since I've placed both videos right on top of each other in AE. Layer 1 layer 2 =)
And I also see the waveform is identical. Matching perfectly in both original and the encoded one.

BTW, just right now I've encode 4 videos and everything is fine. They all were rendered from AE into uncompressed avi, 23.976, grainy. But they all have video and audio right from the very 1st frame and they all are very short (~1 min).

User avatar
JohnAStebbins
HandBrake Team
Posts: 5181
Joined: Sat Feb 09, 2008 7:21 pm

Re: Encoding shifts video 2 frames back

Post by JohnAStebbins » Wed Sep 05, 2018 5:26 pm

After Effects may be broken. This is why I ask. Have you tried other players and stepped through the video. VLC would be a good option.

User avatar
JohnAStebbins
HandBrake Team
Posts: 5181
Joined: Sat Feb 09, 2008 7:21 pm

Re: Encoding shifts video 2 frames back

Post by JohnAStebbins » Wed Sep 05, 2018 5:27 pm

veresk wrote:
Wed Sep 05, 2018 4:38 pm
BTW, just right now I've encode 4 videos and everything is fine. They all were rendered from AE into uncompressed avi, 23.976, grainy. But they all have video and audio right from the very 1st frame and they all are very short (~1 min).
Can you post another log of one of these videos that encoded correctly? I'm wondering if there is something different in the encoding settings that is triggering a problem in AE.

veresk
Posts: 15
Joined: Thu Aug 23, 2018 8:12 pm

Re: Encoding shifts video 2 frames back

Post by veresk » Wed Sep 05, 2018 8:09 pm

Well, I've got a bad news (probably for me alone. I don't know).

Every(!) encoded file has this "2 video frames earlier" problem (those 4 files I just overlooked somehow. They have this problem too) .
I've tried Adobe After Effects render, Adobe Media Encoder render (uncompressed/mp4). Took a random video file (completely random net download), without any Adobe this time, with default HandBrake settings and with manually changed settings. Problem stays.

Frame count and placement I've checked with VLC, Movavi and even PowerDVD =)
Video stream in the encoded video is TWO FRAMES EARLIER.

User avatar
JohnAStebbins
HandBrake Team
Posts: 5181
Joined: Sat Feb 09, 2008 7:21 pm

Re: Encoding shifts video 2 frames back

Post by JohnAStebbins » Wed Sep 05, 2018 8:19 pm

Can you supply a source sample we can test with and see the problem first hand?

musicvid
Veteran User
Posts: 3100
Joined: Sat Jun 27, 2009 1:19 am

Re: Encoding shifts video 2 frames back

Post by musicvid » Wed Sep 05, 2018 8:26 pm

This is a known, persistent issue with many AVI in Handbrake. Audio leads video by 42 ms.
Discussed in detail here https://www.vegascreativesoftware.info/ ... 94/?page=1

Reported in 2012 and subsequently
https://www.youtube.com/watch?v=AhsiQfEfpA0&t=32s

User avatar
JohnAStebbins
HandBrake Team
Posts: 5181
Joined: Sat Feb 09, 2008 7:21 pm

Re: Encoding shifts video 2 frames back

Post by JohnAStebbins » Wed Sep 05, 2018 8:38 pm

Hmm, I wonder if the nightly build would make any difference. It's a different avi demux.

veresk
Posts: 15
Joined: Thu Aug 23, 2018 8:12 pm

Re: Encoding shifts video 2 frames back

Post by veresk » Wed Sep 05, 2018 8:53 pm

Thank you! I will send you a link via private message.

There will be:
- original uncompressed avi from AE
- encoded mp4 of that avi (yes, with 2 shifted video frames as I can see it here)
- activity log from this encoding

veresk
Posts: 15
Joined: Thu Aug 23, 2018 8:12 pm

Re: Encoding shifts video 2 frames back

Post by veresk » Wed Sep 05, 2018 8:59 pm

musicvid wrote:
Wed Sep 05, 2018 8:26 pm
This is a known, persistent issue with many AVI in Handbrake. Audio leads video by 42 ms.
Discussed in detail here https://www.vegascreativesoftware.info/ ... 94/?page=1

Reported in 2012 and subsequently
https://www.youtube.com/watch?v=AhsiQfEfpA0&t=32s
Well, for me it's not only AVI. I tried encoded mp4 (from Adobe ME) and still got this issue. Tried random downloaded video and still got this issue.

I've read that discussion. They say the problem is when PCM is present and the AUDIO is shifted as a result.
In my case audio stays in place frame-accurate. The video is shifted.

User avatar
JohnAStebbins
HandBrake Team
Posts: 5181
Joined: Sat Feb 09, 2008 7:21 pm

Re: Encoding shifts video 2 frames back

Post by JohnAStebbins » Thu Sep 06, 2018 5:07 pm

I had a look at the files you supplied. Both the uncompressed and encoded version have 968 video frames.

When I single step through both the original and encoded version, I see the logo appear at frame 14 and hear a blip at frame 17 (playing back with mpv).

If I had to guess, AE is ignoring or not processing mp4 edit lists properly. If this is the case, you should be able to verify it by changing some video settings that will eliminate the need for an edit list entry for the video. Try setting the video encoder preset to "ultrafast". This prevents the encoder from using b-frames, which require an edit list entry to adjust the start time of video.

If this is actually the problem, you may still have a problem with shift because AAC audio also requires an edit list entry. AAC has a "preroll" period where the encoder outputs some initial data that is used to prime the decoder, but this data must be dropped during playback. The edit list tells a decoder where the actual beginning of sound is in the decoded data.

veresk
Posts: 15
Joined: Thu Aug 23, 2018 8:12 pm

Re: Encoding shifts video 2 frames back

Post by veresk » Thu Sep 06, 2018 6:51 pm

Ultrafast HELPED!
Now AE shows both original and encoded as completely identical things in terms of length, waveform and frame content sync.

1.
But shouldn't the Ultrafast'ed file size be a bit bigger, then the Placebo version? I thought Placebo is more efficient.
Placebo encode 109 125 048 bytes
Ultrafast encode 108 240 939 bytes
(Quality was always Constant with value -8- )

2.
You've said Both the uncompressed and encoded version have 968 video frames. I can not get even close to this number :o
Uncompressed has 495 frames... as I see it :? Both files in total 990 frames.

3.
Should Adobe make some move? May be, but I highly doubt he would. So may be HandBrake could make some clarification in -HELP- or/and even add an option Adobe related, Vegas related, God knows what else related. I read that Vegas thread and closer to the end they still only deal with the problem, but have no solution and say something like "looks like I should play safe and just render out internally in Vegas". Like in my case I might say Adobe Media Encoder. Everything's fine with it except file sizes. HandBrake makes encoding much MUCH more efficiently.

BTW, I started to use HandBrake only a couple of month ago and only once I rendered out with HandBrake an important business video and immediately got an e-mail "your file has no sound". That was when I set audio to "AACpassthru" and all I know they've opened it on some MACbook. Why?? I'm making videos on a fee basis since 2007 and I've got not a single return case. So now I just gained more uncertainty about using anything else but reliable Adobe :(

of course NOT :D

User avatar
JohnAStebbins
HandBrake Team
Posts: 5181
Joined: Sat Feb 09, 2008 7:21 pm

Re: Encoding shifts video 2 frames back

Post by JohnAStebbins » Thu Sep 06, 2018 7:12 pm

1. Ultrafast is "less effecient" at compression. What this means is that for a given desired quality, the filesize will most likely be larger. The quality slider only provides a rough control of the actual output quality. Changing other settings (e.g. changing from placebo to ultrafast) slightly changes what output quality a particular RF value produces. If you are getting smaller files, the actual quality is most likely also lower.

2. Oops, sorry. Was looking at the wrong track. Both are 495 frames.

3. All of HandBrake's "Production" presets set b-frames=0. I don't know if this was done to address this particular type of problem or not. Maybe BradleyS will chime in since he created these presets. But a note somewhere in the documentation wouldn't hurt.

When it comes to mp4, there are a lot of tools out there (including pro tools like AE) that just get it wrong.

The AAC encoder in the current (and upcoming 1.1.2) release of HandBrake has known issues. I've never seen any issue report of no sound, but there are plenty of issues about poor sound quality. The next release after 1.1.2 will have an improved AAC encoder.

veresk
Posts: 15
Joined: Thu Aug 23, 2018 8:12 pm

Re: Encoding shifts video 2 frames back

Post by veresk » Thu Sep 06, 2018 8:11 pm

So what if I set encoder preset to Placebo, but in Extra option field I put "b-frames=0" ?
Well, it didn't work :(

Could you PLEASE tell me how can I enjoy all of the advantages of Placebo, but turn off b-frames. Cause I'd really like to use HB as a final encoding tool.

________________________________________________________________________________________
...and may be you know why these "pro tool" (like AE) while being such a PRO could possibly get wrong one of the most popular video format on earth? Adobe even positions MP4 as a primary and the most welcome format. This is absurd!

...and why Align A/V start doesn't help while described as a cure specifically for MP4 Edit lists problem?

User avatar
Rodeo
HandBrake Team
Posts: 11927
Joined: Tue Mar 03, 2009 8:55 pm

Re: Encoding shifts video 2 frames back

Post by Rodeo » Thu Sep 06, 2018 8:20 pm

Try "bframes=0" (without quotes).

User avatar
JohnAStebbins
HandBrake Team
Posts: 5181
Joined: Sat Feb 09, 2008 7:21 pm

Re: Encoding shifts video 2 frames back

Post by JohnAStebbins » Thu Sep 06, 2018 8:27 pm

Is this an intermediate file that you will be re-encoding again? If so, why placebo? For intermediates, it's a whole lot faster to just use more disk space to preserve quality.

Even if it's not an intermediate, placebo has it's name for a reason. The amount of gain you might get with placebo can be measured in bytes per gigabyte. "Slow" or "Slower" are going to be more than enough.

User avatar
JohnAStebbins
HandBrake Team
Posts: 5181
Joined: Sat Feb 09, 2008 7:21 pm

Re: Encoding shifts video 2 frames back

Post by JohnAStebbins » Thu Sep 06, 2018 8:55 pm

..and may be you know why these "pro tool" (like AE) while being such a PRO could possibly get wrong one of the most popular video format on earth?
The "mp4 spec" is a bit of a mess. Apple created it's QT spec based on mp4 and did things their own way for a very long time. Then there is the official ISO media spec that developed in parallel. They are not 100% compatible even though they are very very similar. This leads to a lot of confusion. And edit lists are just difficult period. You can (and apple did) do crazy things with edit lists. For example, you can take an existing stream and add an edit list to it to completely re-cut it. You can chop segments out, reorder segments, repeat segments, all without touching the existing media streams. There aren't many (any?) players beyond QT that support playback of such edited files. But the spec allows it.

When mp4 was initially developed, I'm guessing they didn't really envision codecs with out of order timestamps (b-frames). The mp4 spec doesn't really have timestamps. It only has a series of frame durations. Out of order timestamps basically requires a negative duration or offset be specified someplace. So they stuffed this into an edit list entry. More recent iterations of the ISO spec allow for negative ctts values which is another way to handle b-frames. But who knows how many players actually would support this, seeing as how it's kind of new.
...and why Align A/V start doesn't help while described as a cure specifically for MP4 Edit lists problem?
Align A/V start addresses a specific problem where the source audio and video bitstreams do not start at the exact same timestamp. Your source tracks all start at the exact same timestamp, you just have black video frames and silent audio frames up to a certain point. Players that require "Align A/V start" may or may not still have the 2 frame slip you are seeing when b-frames are enabled. "Align A/V start" prevents insertion of a different type of edit list entry called an "empty edit". An empty edit tells the player that rendering of a track needs to be delayed, relative to other tracks. The type of edit entry you are having a problem with tells the player that samples should be "skipped". Skipped is in quotes because it's actually a bit more complicated. There are other fields that get factored in that determine what actually happens.

User avatar
JohnAStebbins
HandBrake Team
Posts: 5181
Joined: Sat Feb 09, 2008 7:21 pm

Re: Encoding shifts video 2 frames back

Post by JohnAStebbins » Thu Sep 06, 2018 9:08 pm

Ugh, I stated something backwards. "Align A/V start" *prevents* the insertion of an "empty edit". Empty edits confuse some players.

Previous post edited and corrected. :mrgreen:

veresk
Posts: 15
Joined: Thu Aug 23, 2018 8:12 pm

Re: Encoding shifts video 2 frames back

Post by veresk » Thu Sep 06, 2018 10:35 pm

Thank you for such a rich respond! and I apologies for messing with A/THE and my other grammar awkwardness. EN is not my first language.

Anyway I consider the problem is solved for me -> bframes=0
Yes, of course Placebo has it's name for a reason so I will behave reasonably :wink: and thanks for depicting how messy "MP4 spec" really is!

I felt specially delighted watching HandBrake utilizing all my 32 CPU threads simultaneously and evenly. A truly rare thing. Great work guys!

User avatar
BradleyS
Moderator
Posts: 1356
Joined: Thu Aug 09, 2007 12:16 pm

Re: Encoding shifts video 2 frames back

Post by BradleyS » Sat Sep 08, 2018 12:38 am

JohnAStebbins wrote:
Thu Sep 06, 2018 7:12 pm
3. All of HandBrake's "Production" presets set b-frames=0. I don't know if this was done to address this particular type of problem or not. Maybe BradleyS will chime in since he created these presets. But a note somewhere in the documentation wouldn't hurt.
Generally speaking, all-Intra or closed GOP, high bit rate I/P video is preferred for editing. The reasoning is simple: less computationally expensive to decode leading to faster scrubbing/seeking. This is generally expected for production intermediate encodes and the reasoning is well-known in the industry so I guess I didn't see a major reason to document it in depth, beyond stating which frame types are used.

Anyway, the official production presets lacking B-frames is not for compatibility reasons, but apparently it does not hurt. Premiere/AE/FCP are all fairly picky about various small things, and in my testing all handle these presets well (as designed!).

You're probably wasting your time using slower encoder presets for production intermediate purposes. It's better to disable all the slow bit crunching algorithms and simply throw more bits at the encode, enforcing a small closed GOP and CFR. You'll end up with a better result that decodes predictably and scrubs faster in your NLE, for the cost of a larger file. Hence why the production presets were created. It may seem counter-intuitive, but such encodes will probably use less of your CPU resources.

Post Reply