summaryrefslogtreecommitdiff
path: root/src/lib/video_decoder.cc
AgeCommit message (Collapse)Author
2021-07-10Use dcp::compose rather than our own.composeCarl Hetherington
2021-02-26Fix warning.Carl Hetherington
2021-02-26Typo fix.Carl Hetherington
2021-02-26Fix a set of mistakes related to 3D content.Carl Hetherington
2021-01-31More enum class additions.Carl Hetherington
2021-01-07BOOST_FOREACH.Carl Hetherington
2021-01-07std::shared_ptrCarl Hetherington
2020-02-19Nicer fix for 2D-labelled-3D checking from master.Carl Hetherington
2019-11-20Restore checking of 2D files that are incorrectly set as 3D.Carl Hetherington
2019-11-19Fix problems with playing back 3D DCPs and with inserting 3D DCPsCarl Hetherington
in 2D projects. Also add some tests.
2019-11-11Don't trust video timestamps from FFmpegDecoder.v2.15.32Carl Hetherington
2019-11-11Make DecoderPart::_position an optional.Carl Hetherington
2019-05-21Give an error if 2D content is set to 3D (#1565). Also runCarl Hetherington
3D tests with more parallel jobs to speed them up.
2019-05-10Put Time types in dcpomatic namespace.Carl Hetherington
2018-11-21Take Film pointer out of Content.Carl Hetherington
2018-01-02A previous commit took care to make Decoder::position() not be updatedCarl Hetherington
if the data that was emitted from the decoder was not taken by the player. This means that when the decoder moves into its end trim the position will stay where it is (since the player does not take the data). I can't see the point of doing this; the only use of Decoder::position() is to decide what to pass() next (I think). It is also inconvenient because we would like to check Decoder::position() to decide whether to stop passing a decoder since it's in its end trim (not doing this causes #1154).
2017-12-13Reset VideoDecoder::_position on seek.Carl Hetherington
2017-08-30Fix incorrect reel lengths in some cases; account for emitted data being ↵Carl Hetherington
rejected by the player, and for initial audio not to be at time 0.
2017-07-28Do repeat in the player rather than trying to do it in VideoDecoder.Carl Hetherington
Trying to repeat in VideoDecoder is the wrong side of the distinction between content and DCP time; the repeat is for the DCP and VideoDecoder should be emitting in terms of the source.
2017-06-23Attempts to simplify black-filling logic in Player.Carl Hetherington
2017-05-21Fix _position with VIDEO_FRAME_TYPE_3D_ALTERNATE.Carl Hetherington
2017-04-19Remove unnecessary VideoFrame class.Carl Hetherington
2017-04-19Fix comment.Carl Hetherington
2017-04-19Post-merge tidy-up.Carl Hetherington
2017-04-19Basic grunt-work, untested and unfinished, but it compiles.Carl Hetherington
2016-12-08Further fixes and tidying to 'better-seek'.Carl Hetherington
This fixes the failure to keep track of the `position' of each stream of a multi-stream file. It also tidies things up a bit.
2016-11-22Fix warning.Carl Hetherington
2016-11-21Still more decode logging.Carl Hetherington
2016-11-21Some more decode debug logging.Carl Hetherington
2016-11-20Some more decode logging.Carl Hetherington
2016-11-19Remove out-of-date comment.Carl Hetherington
2016-11-19Move position variables into the video/audio/subtitle decoder classes.Carl Hetherington
2016-11-19Cope with offsets between video/audio/subtitle data in a muxed file.Carl Hetherington
2016-11-17A possibly-better approach to seeking.Carl Hetherington
Before this commit, decoders try to guess whether they should request a seek based on what they have in their buffers. This seems reasonable for video and audio, which will always (I think) have some data lying around to give an indication of where their parent decoders are in the timeline. It doesn't work so well for subtitles, as the storage of subs is cleared out based on time (+/- 5s of "now") so there is a good chance that the storage will be empty. This gives the subtitle decoder no chance of knowing where its parent is, so it's very likely to seek. This commit asks the parent decoder to seek if it wants to, and it decides based on a knowledge of roughly where it is in the timeline. Hence the sub-decoders just see if they have got the data that is being requested, and if not they suggest to the parent that it might like to seek. They then start calling pass(). Hence the parent should only seek if some calls to pass() are not going to elicit the required data in a reasonable time.
2016-10-24Fix seeking with 3D alternate-frame sources.Carl Hetherington
2016-10-19Fix misunderstandings in decoder frame handling for 3D/3D-alternate.Carl Hetherington
2016-07-29Fixes for separate L/R eye content.Carl Hetherington
2016-07-04Comment tweak.Carl Hetherington
2016-06-22Optimization for the referenced video case.Carl Hetherington
With referenced video from a DCP decoder, no video will ever be fetched from the decoder. Hence the code to discard given video will be activated after _decoded builds up to the magic size. Before this commit the code would attempt to fill with black up to given frame N (with N very large) from the last frame in _decoded when _decoded had been trimmed. This would result in exponential growth in execution time for the VideoDecoder::give() path.
2016-06-21Revert "Use make_shared<>."Carl Hetherington
Support for this seems to vary wildly across DoM's build targets. Stuff that builds on 16.04 won't build on 14.04, for example. Seems to not be worth the hassle now. This reverts commit 5a5324ed3a381a86dfe0a6e3932c1d58fdcd596f.
2016-06-21Use make_shared<>.Carl Hetherington
2016-06-14Fix subtle bug with 3D and add a explicit to stop it happening again.Carl Hetherington
2016-06-14Fix some confusion with filling and VideoFrame.Carl Hetherington
2016-06-14Add VideoFrame class.Carl Hetherington
This puts a frame index with an Eyes, which simplifies code in some areas. I can't think of a better name for it, unfortunately.
2016-06-13Fix VideoDecoder::get_video() with 3D.Carl Hetherington
get_video() promises to return all video frames at the given time, but this wasn't working for none-SBS-3D as it would be satisfied when it got the first (left) frame. Adjust get_video() to get all required frames. This showed up bugs in fill_both_eyes, whereby the from parameter was ignored and the wrong things were done in some cases; video_decoder_fill_test.cc tests this stuff.
2016-05-25No-op; fix GPL address and use the explicit-program-name version.Carl Hetherington
2016-05-18Fix seek, for video at least.Carl Hetherington
2016-05-18Rename some methods.Carl Hetherington
2016-05-18Basics of splitting up Decoder tree like Content.Carl Hetherington
2016-05-18Move video frame rate ('prepared-for') into Content.Carl Hetherington