From 86c9cd50e1b73e6d89db312f2ee58e85ff270194 Mon Sep 17 00:00:00 2001 From: Carl Hetherington Date: Thu, 20 Jan 2022 21:23:09 +0100 Subject: Slightly hacky fix for -114 errors during 3D encodes (#2173). It still feels like I'm missing some large and beautiful trick with gathering all the gap-filling code into one place, but such a trick still eludes me. --- src/lib/player.cc | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'src/lib') diff --git a/src/lib/player.cc b/src/lib/player.cc index 4e586ed77..42c22ab7d 100644 --- a/src/lib/player.cc +++ b/src/lib/player.cc @@ -812,6 +812,19 @@ Player::pass () for (auto const& i: _delay) { do_emit_video(i.first, i.second); } + + /* Perhaps we should have Empty entries for both eyes in the 3D case (somehow). + * However, if we have L and R video files, and one is shorter than the other, + * the fill code in ::video mostly takes care of filling in the gaps. + * However, since it fills at the point when it knows there is more video coming + * at time t (so it should fill any gap up to t) it can't do anything right at the + * end. This is particularly bad news if the last frame emitted is a LEFT + * eye, as the MXF writer will complain about the 3D sequence being wrong. + * Here's a hack to workaround that particular case. + */ + if (_next_video_eyes && _next_video_time && *_next_video_eyes == Eyes::RIGHT) { + do_emit_video (black_player_video_frame(Eyes::RIGHT), *_next_video_time); + } } return done; -- cgit v1.2.3