764 - Green frames in HB output


With a H.264 source I'm doing some cuts and encoding the output with handbrake, Problem is the handbrake output has a few green frames at the start. If I move the cut point back one frame there are then no green frames in the handbrake output.

To reproduce here's a sample: source.rar

Open project file in VRD and export to H.264 either ts or mp4 container.
Open output in handbrake and encode, default profile will do.
Play output and notice green frames at the start.

To produce a green frame free handbrake output move the end of the cut point back one frame.

This also happened occasionally on the previous VRD version I was using, I think it was 761, but since moving to 764 it's hapening a lot more often.


Senior Developer
Staff member
Sounds like Handbrake is having a decoding issue. If you play the cut file in VLC, before recoding with Handbrake, do you see any obvious glitch or error at the cut points that produce the green frames? If not then I suspect this is a Handbrake issue, and not a VideoReDo issue.
Ok I reported this to the handbrake team and this looks like a corrupt input issue. You can read the related report here

Note the error in the handbrake log:

number of reference frames (0+5) exceeds max (4; probably corrupt input), discarding one
What is not know is whether the source is corrupt or just the VideoReDo output however if I encode the source with Handbrake without putting it through VideoReDo first then there is no error in the Hnadbrake log and no green frames in the output.

As you can see in the Handbrake thread the lastest Handbrake nightly uses FFmpeg instead of Libav, the FFmpeg build is better able to deal with the corruption, it doesn't produce green frames but it does still throw the error in the log about a corrupt input.

I can send you the original source file that hasn't been through VideoRoDo if you need it, the one I posted in the OP has been.


Senior Developer
Staff member
When you do a smart edit in VideoReDo we have to recode a few frames around each cut point. Our encoder isn't able to match every single encoding combination, so in some rare cases the recoded frames are encoded slightly different then the pass through frames. This can cause issues with some decoders. Unfortunately this is just the nature of H.264. There are hundreds of encoding options in H.264 and there are no encoders on the market that support them all, so it's impossible for us to match every input file perfectly. We do our best to match the most commonly used options, but in some cases we just can't. Some decoders are more sensitive to these differences then others too. So one player may be able to transition between the encoding differences smoothly while others get errors and produce these green/pink frames.

The only way to guarantee this doesn't happen is to do the recode in VideoReDo.
Thanks for that Dan, I now know why it only affects commercial channels where I cut adverts and not BBC channels which don't have them. Looking forward to version 6 which I believe will have X.264 and AC3 encoding.
Indeed thanks for the update Dan.

Looking back through the encode logs there is a warning for most files but the green frames only appear on a few. Using the latest handbrake with the recent decoder will hopefully get rid of the green frames alltogether because it sounds like there is nothing you can do to improve the situation short of changing the smart encoder to use X.264 but I think I've suggested that before and it wasn't an option.

Grandpa Broon, this also effects BBC channels for me and I've only ever seen the green frames at the start of a file but to be fair I've not really been checking for them at the cut points as well so maybe there are some in there. If you didn't catch it above the latest handbrake nightlies have an updated decoder that didn't produce the green frames on the one source I tested on.