_TrackerLaunchDocuments() dereferences refs to copy it, so, we need
check that it isn't NULL first.
Also a few style fixes.
* Name params consistent with TTracker class methods
ref, message => appRef, refs
* Use NULL instead of 0 for NULL pointer.
- Ensure that start times are increased monotonically for video formats that
contain B-frames, too, as expected by the BMediaDecoders.
Previously start times were returned that seemed to go back in time for
videos containing B-frames.
Tested with resolutionchange.mpg (\see http://samples.ffmpeg.org/MPEG2)
Note: Even though start times aren't going back in time anymore there are
times where two consecutive start times are equal. This would need more
research once this exposes a bug in a real application. Further more this
might seem like a new bug, but before this commit the equal start times would
have simply some different start time[s] in between. So at most this is the
same bug just wearing new clothes :)
- Documentation updated accordingly.
- I misinterpreted the semantics of reordered_opaque. I thought it would
establish the correct relationship between the start_time returned by
GetNextChunk() and the next video frame successfully decoded. But for this
to work reordered_opaque expects to be filled with presentation time stamps.
A series of presentation time stamps may be jumping back in time due to the
presence of B-frames. The decoded frame presentation time stamps series would
then be ordered in a monotonically increased way.
But actually GetNextChunk() always returns monotonically increasing start
times. Mapping this behaviour to FFMPEG's expectations means labeling those
start times as decoding time stamps (dts). Though for those start times to be
related to the correct decoded video frames you have to assign the start time
with the AVPacket containing the data to be decoded.
- This commit finally makes DVB video playback working for me with the TV app.
Though no audio yet.
- The documentation was updated accordingly.
- This field is needed by the dvb.media_addon to detect a format change so
fill it with the correct value.
- Updated documentation accordingly to reflect reordered function calls and new
assumptions based on the function call ordering.
- Due to comparing the wrong fields with one another the dvb.media_addon called
ChangeFormat() on every new video frame.
- Also remove a duplicate print statement.
- This init check prevented the MediaStreamDecoder from setting up an input
format. The values the init check is based on are initialized by the first
call to BMediaDecoder::SetTo() as described in the BeBook ("If you use the
empty form of the constructor, you'll have to call SetTo() to establish the
format to be decoded before calling Decode()"). But MediaStreamDecoder
doesn't provide a public way to call BMediaDecoder::SetTo() first.
There are at least two possible solutions to remedy this situation:
1. Remove the init check
2. Add a public way to call SetTo()
The first solution was chosen for the following reason: Least amount of
code change needed as it is an implementation detail so no client code has
to be touched.
The second solution might make sence when you want to stick to the BeBook
where a clear distinction between SetTo() and SetInputFormat() is made, but
as the current MediaStreamDecoder implementation doesn't stick to the BeBook
anyway there is less need to add another method at this time.
- This is the workaround as described in the bug report #11018.
- I would have preferred to place this workaround in DVBMediaAddon::InitCheck()
as this method can return a status code but unfortunately it is never called.
- Remove use of now superflous media_header_ex structure.
- Respect 80 char line limit and indentation rules. Coding style only applied
to functions raw_[audio|video]_thread, rest of the class may need some more
cleanup.
- No functional change intended.
Parentheses in target names are considered by Jam to mean an archive
member. We have to explicitly use the M selector to keep that part.
Fixes#10378 (certain keymaps missing on image).
Fixes#8812, #10920
At the edge of the fractal, we can get a value between 0 and the number
of iterations. Since the palette is only 256 colors, this was previously
using random colors for any setting with more than 256 iterations, and
ended up crashing the program with very high numbers.
The palette is now looped, which avoids the crash. Looping the palette
allows finer details at the higher zoom levels to be provided using the
full color range, however with some of the palettes this will look quite
noisy.
