| Age | Commit message (Collapse) | Author |
|---|
|
sed -i "s/SubtitleContent/TextContent/g" src/lib/*.cc src/lib/*.h src/wx/*.cc src/wx/*.h src/tools/*.cc test/*.cc
sed -i "s/SubtitleDecoder/TextDecoder/g" src/lib/*.cc src/lib/*.h src/wx/*.cc src/wx/*.h src/tools/*.cc test/*.cc
sed -i "s/subtitle_content/text_content/g" src/lib/*.cc src/lib/*.h src/wx/*.cc src/wx/*.h src/tools/*.cc test/*.cc src/lib/wscript src/wx/wscript
sed -i "s/subtitle_decoder/text_decoder/g" src/lib/*.cc src/lib/*.h src/wx/*.cc src/wx/*.h src/tools/*.cc test/*.cc src/lib/wscript
mv src/lib/subtitle_decoder.cc src/lib/text_decoder.cc
mv src/lib/subtitle_decoder.h src/lib/text_decoder.h
mv src/lib/subtitle_content.cc src/lib/text_content.cc
mv src/lib/subtitle_content.h src/lib/text_content.h
mv src/lib/dcp_subtitle_decoder.cc src/lib/dcp_text_decoder.cc
mv src/lib/dcp_subtitle_decoder.h src/lib/dcp_text_decoder.h
mv src/lib/dcp_subtitle_content.cc src/lib/dcp_text_content.cc
mv src/lib/dcp_subtitle_content.h src/lib/dcp_text_content.h
mv src/lib/text_subtitle_content.cc src/lib/text_text_content.cc
mv src/lib/text_subtitle_content.h src/lib/text_text_content.h
mv src/lib/text_subtitle_decoder.cc src/lib/text_text_decoder.cc
mv src/lib/text_subtitle_decoder.h src/lib/text_text_decoder.h
mv src/wx/timeline_subtitle_content_view.cc src/wx/timeline_text_content_view.cc
mv src/wx/timeline_subtitle_content_view.h src/wx/timeline_text_content_view.h
|
|
things.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
With this timeline:
-------> t
SUB1 SUB2 X
We might seek to X, then pass(). Before this change, SUB1 would have been emitted by
the call to the subtitle decoder, then we'd have emitted some black for X. This would
lose SUB2. Now we keep pass()ing and don't emit X until it's the earliest thing
(in the same way that the main decision of what to pass() works).
|
|
|
|
|
|
|
|
|
|
Before this we would get a subtitle at t, which would set the subtitle
decoder position to t. Then a second request for this sub would result
in no seek but the decoder would not re-produce the sub.
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
Firstly, when finding subtitles that exist during a period, only
return those which overlap more than half the period. This means
that, in a fight over a frame, the longest-running subtitle in that
frame will win.
Secondly, make SubtitleDecoder::get pick the wanted subtitles from
the cache simply by comparing their periods to those that were
requested. I think this is nicer than what was there before
(basically reevaulating 'what subtitle(s) for this period') and
also makes the first part of this commit effective.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use the specified time period rather than looking
in the Subtitle.
|
|
|
|
subtitles along the way.
|
|
|
|
|
|
|
|
|
|
but only for preview.
|
|
This reverts commit 9e025d3f85f9d6d855b3d5e6c90bca0eac3a3d49.
It causes corruption in prophet_clip.xml for reasons that
are not yet known.
|
|
|
|
The "accumulation" of, for example, video data when we are looking
for audio data is an *optimisation* to reduce the number of seeks.
It should not be necessary for correctness (the output should be right
even if we never kept anything except what we were looking for).
Doing this accumulation is not always an optimisation; sometimes not
doing it is better. Avoiding it when going back for subtitles is one
of these cases.
|
|
|
|
|
