dcpomatic/src/lib/ffmpeg_decoder.cc, branch v2.16.25 DCP-o-matic DCP tools https://git.carlh.net/cgit/dcpomatic/atom?h=v2.16.25 2022-09-10T19:00:06Z Some improved logging. 2022-09-10T19:00:06Z Carl Hetherington cth@carlh.net 2022-09-09T22:45:11Z urn:sha1:6917c511507bee74297845267811e7bcc042e62e Bump libdcp for better ContentKind support, and libsub 2022-09-03T15:12:34Z Carl Hetherington cth@carlh.net 2022-09-03T12:49:25Z urn:sha1:0a5d3c77247d3e68a144bfc077c29fbcf3819735 for fixes to \c tags in SSA files. Set up TextDecoder position based on the time that the next thing will 2022-06-12T13:40:33Z Carl Hetherington cth@carlh.net 2022-06-08T07:58:16Z urn:sha1:c8a036eb727ceddc64a0304d781c916eb952c001 be emitted, instead of the time that the last thing was (#2268). This is to avoid problems with the example shown in the test, where just because a subtitle in source A comes before a subtitle in source B, source A is pass()ed next and may then emit a subtitle which should be after the next one in B. Handle multiple bitmap subtitles at the same time correctly (#2239). 2022-04-28T12:00:07Z Carl Hetherington cth@carlh.net 2022-04-28T12:00:07Z urn:sha1:e06941199da90359f41ce80c276752bc0f172d7e Previously if there were two images at the same time we would start them both, then the stop time would be set in the second one but not the first. This meant that the first one would hang around forever. Make emit_bitmap_start take a ContentBitmapText. 2022-04-28T07:47:22Z Carl Hetherington cth@carlh.net 2022-04-28T07:47:22Z urn:sha1:ff27a57f028b0ab967e38c555fbfcdca560f15fd C++11 and whitespace cleanups. 2022-04-03T21:25:19Z Carl Hetherington cth@carlh.net 2022-04-02T22:04:31Z urn:sha1:d311043bf3c1e3e7f41b314f7ab7c91ed7e5aa7f Try to handle EAGAIN from avcodec_send_packet() properly. 2022-02-17T08:59:26Z Carl Hetherington cth@carlh.net 2022-02-15T21:47:48Z urn:sha1:80430058f5eefb55147218a85225adeb6b616f4d The docs say on EAGAIN we should call avcodec_receive_frame() and then re-send the same packet again. This should do that. This is a fix for errors trigged by the accompanying test. Fix failure to decode multiple video frames from one packet (#2159). 2022-01-11T21:16:16Z Carl Hetherington cth@carlh.net 2022-01-11T15:42:30Z urn:sha1:758c1ba16ab87152621f6c7c62c2e011a2ae2712 Cleanup: move some stuff into process_video_frame(). 2022-01-11T21:16:08Z Carl Hetherington cth@carlh.net 2022-01-11T15:38:13Z urn:sha1:84039db657c3cc72719706a136c90741170c765a Use a separate AVFrame for each stream when decoding. 2022-01-11T21:16:04Z Carl Hetherington cth@carlh.net 2022-01-11T15:34:26Z urn:sha1:b703142e8750c509174b4d964009aecf93f3d834 This seems to be what ffplay does and it feels like it makes sense as frames may be built from multiple packets AFAICS.