- We let FFMPEG keep track of the correct relationship between presentation
start time of the encoded video frame and the resulting decoded video frame.
This simplyfies our code, meaning less lines of code to maintain :)
- Update documentation and pointing out some corner cases when calculating the
correct presentation start time of a decoded video frame under certain
circumstances.
- Fix doxygen: Use doxygen style instead of javadoc style.
- No functional change intended.
Signed-off-by: Colin Günther <coling@gmx.de>
- Main purpose is to make reading the function DecodeNextFrame() easier on the
eyes, by moving out auxiliary code.
Note: The media_header update code for the start_time is still left in
DecodeNextFrame(). This will be addressed in a later commit specially
targetted on handling start_time calculations for incomplete video frames.
- Also updated / added some documentation.
- No functional change intended.
Signed-off-by: Colin Günther <coling@gmx.de>
- This commit makes the mpeg2_decoder_test successfully decode the test video
into 84 consecutive PNG images, yeah :)
- If this commit broke playing video files for you please file a bug report.
I've tested only with one video file (big_buck_bunny_720p_stereo.ogg) that
everything still works.
- The implementation has some shortcomings though, that will be addressed with
some later commits:
1. Start time of media header is wrongly calculated. At the moment we are
using the start time of the first encoded data chunk we read via
GetNextChunk(). This works only for chunk that contain one and exactly
one frame, but not for chunks that contain the end or middle of a frame.
2. Fields of the media header aren't updated when there is a format change
in the middle of the video stream (for example the pixel aspect ratio
might change in the middle of a DVB video stream (e.g. switch from 4:3
to 16:9)).
- Also fix a potential bug, where the CODEC_FLAG_TRUNCATED flag was always
set, due to missing brackets.
Signed-off-by: Colin Günther <coling@gmx.de>
- It is just one flag that needs to be set, so that streaming video data can be
handled by the FFMPEG library.
- For reference: This flag is based on FFMPEG's 0.10.2 video decode example
(doc/example/decoding_encoding.c).
- The _DecodeNextVideoFrame() method needs to be adjusted (still to come), to
take streamed data into account. So the flag on its own doesn't help, but it
is a reasonable step in that direction.
Signed-off-by: Colin Günther <coling@gmx.de>
- Factor out the deinterlacing and color converting part to make the code more
readable. This makes it easier to understand which code belongs to the actual
decoding process and which code to the post processing.
- There seems to be no performance impact involved (I just looked at the spikes
of the process manager) in factoring out this part, but one can always inline
the method if a closer performance assesment (e.g. by enabling the profiling
the existing profiling code) suggests so.
- Document the _DecodeVideo() method a little bit. Maybe someone can document
the info parameter, as I'm a little bit clueless here.
- No functional change intended.
Signed-off-by: Colin Günther <coling@gmx.de>
(cherry picked from commit c5fa095fa73d47e75a46cfc138a56028fcc01819)
* Now that system updates seem to work properly, put the haiku
repository config and cache file onto the image automatically.
* Adjust URL of haiku repository (it is currently redirected
to some other URL at download.haiku-os.org, but that will be
changed later).
Double checked BeOS R5 & Haiku R1/A4 and BTextView should be 356
bytes, somewhere since then we've added 4 bytes. So, this commit
reduces the class size from 360 back to 356 by removing 1 reserved
int32 (instead of 2).
I believe the class size changed in hrev46798 as a result of adding
2 bools (1 byte each padded out to 4 bytes).
Sorry for the noise.
... while Shift is held down in a selection.
Before this commit, if you had some text selected and you pressed
Home or End with a Shift held down the selection would not change.
This was annoying and most likely unintentional. Thank you Axel for
informing me of this problem.
After this commit if you have some text selected and you press Home
with a Shift key held down it will move the end of the selection to the
first character of the same line that the end of selection is on and if you
press End with a Shift key held down it will move the end of the selection
to the last character of the same line that the end of the selection is on.
I looked at how a bunch of different OS's and applications handled this
and found that there are a bunch of different behaviors we could use here,
and there doesn't appear to be any consensus as to what the "right" or
"wrong" way to do this is so please forgive me if this doesn't work exactly
as you expect it to.
Note that the implementation used here is very different from how BeOS
R5 worked. In BeOS R5 pressing Home or End with Shift held down
always extended the selection, it never subtracted from it.
In BeOS pressing Home with Shift held down extended the selection from
the left-most part of the selection to the first charcter of the same line.
Pressing End with Shift held down extended the selection from the
right-most part of the selection to the end of the same line.
Private Method docs are/should be in doxygen format. Remove \brief as doxygen
doesn't need this if you document along side the method.
Remove brief description comments from public methods, you'll need to look in the
Haiku Book for this now.
style squash
In hrev46796 I added two new private methods: _PreviousLineStart(),
and _NextLineEnd() which increased the size of the class breaking
binary compatability because I forgot to decrement the reserved array.
This commit decrements the reserved array restoring the class size
to the original size fixing the binary compat issue.
Thanks Axel for noticing.
The order is updated so the virtual methods appear in the same order
that they did in BeOS R5 with methods new to Haiku added to the bottom.
Perform() moves up, all other methods move below GetDragParameters(),
the last virtual method in BeOS R5's TextView.h.
* There is no point in trying to pack the scanlines in a gradient, as it
is very likely that each pixel will have a different color.
* Moreover, the packed scanline generator will assume all pixels in the
* scanline have the same alpha value (for faster blending), and it may
* not be the case.
Fixes#2946.
Thanks to stippi and jessicah who helped tracking and understanding the issue.
* Add a vertical linear gradient. This bypasses AGG and uses a faster
code path, which works.
* Add gradients drawn in a ClipToPicture() context. This uses an
* unpacked scanline rasterizer, which works.
This hints to the problem being the use of a packed scanline rasterizer,
with agg gradients touching the alpha channel.
