* Invoking jam from Haiku's checkout directory (instead of the output
directory) caused the repository creation to fail because of relative
paths to package files being used. Now we make sure that HAIKU_TOP
is an absolute path to avoid problems like these.
- Fixes a bug using realloc with a memory area that is declared const which
lead to a crash in MediaPlayer playing big_buck_bunny_720p_stereo.ogg.
- The refactoring introduces a strict separation between const memory areas
(chunk data read from GetNextChunk()) and mutable memory areas
(fVideoChunkBuffer) by using a copy operation instead of a casted
assignment operation.
- Updated documentation accordingly.
- Besides fixing the bug, there is no functional change intended.
- Main reason for refactoring was to increase readability of
_DecodeNextVideoFrame() by simplifying it. Refactoring was tested
successfully for no functional change with mpeg2_decoder_test.
- Reindented the method definition in the header file so that the new method
_LoadNextVideoChunkIfNeededAndUpdateStartTime() fits into 80 chars per line.
Reindentdation is applied to methods only as the member variables have no
space left for reindentation.
- Update documentation accordingly.
- Fix wording of audio part to audio path.
- No functional change intended.
- Padding is required by FFMPEG for correct operation of all video decoders.
FFMPEG performs some speed optimizations under the hood that may lead to
reading over the end of the chunk buffer wouldn't there have been padding
applied.
- Note: Padding is required for audio decoders, too. I will tackle this in some
later commits. For the time being we have a degradation in code reuse, due to
different memory ownership of chunk buffers in audio and video decoder path.
Audio path must not care about freeing chunk buffers whereas video path must.
- Fix coding style and some typos.
- Update documentation accordingly.
- Video frames still contained in the video decoder are now flushed when there
are no encoded data chunks left (signaled by B_LAST_BUFFER_ERROR).
- New code was successfully tested with mpeg2_decoder_test. The last test image
is now decoded, too, resulting in a bump of the expected number of decoded
images.
- Refactor code to support flushing -and- keep the readability at a sane level.
- Remove some uncommented code for the sake of readability.
- Documentation updated accordingly.
Stop-gap solution to make smpeg installable until the separate libstdc++
package is available. Then it will hopefully have a reliable "compat"
version we can depend on.
* The thread could set fRunning to false before the caller had set it to
true, leading to a stalled request.
* Happened easily when testing "data" requests, which are fast since no
I/O is involved.
* Possibly also helps with stalled redirects on Google search I've been
seeing for some time.
* Allows having a lot of bookmarks in the menu, and only the most often
used ones in the bar.
* If the "Bookmark bar" folder doesn't exist, the old behavior (using
the main Bookmarks folder for the bar as well as the menu) is used.
* If none of these exists, the bookmark bar will not be available (just
like the bookmark menu)
Fixes#11092.
We may want to update the default set of bookmark to include some links
in the bar.
There is some misunderstanding on what the "deflate" is, and we can't
reliably decode it in all cases. So, don't advertise support for it and
let servers use gzip (or no compression) instead.
Fixes#11093
- Kudos to Marcus Overhagen for laying out the general idea of automatic
detection by sharing some of his dvb code examples with me.
- Simplify pixel format search code by removing the loop and let FFMPEG
decide what pixel format to use based on the actual video data.
- Automatically detect the video frame rate based on the actual video data.
- Remove fOutputVideoFormat to avoid synchronizing values in two distinct
places. The member variable fHeader is the main place for important decoder
parameters now.
- Introduce fOutputColorSpace containing the color space that was previously
tracked in the fOutputVideoFormat member variable.
- Update the documentation accordingly.
- The frame rate calculation is purely based on AVCodecContext fields. This way
the frame rate can be calculated by the FFMPEG decoder based on the actual
video data. This is useful for automatically detection of the correct
decoding parameters (not implemented yet but scheduled for a later commit).
- Not used anywhere yet (scheduled for a later commit).
- Also some minor documentation updates.
- Also make use of the extracted code in the AVCodecDecoder class.
- Enhance some documentation and fix some coding style violations.
- No functional change intended.
- This allows a BMediaDecoder (e.g. FFMPEG Plugin) to communicate back format
changes to its clients.
For a more thorough explanation and discussion see haiku-development mailing
list: http://www.freelists.org/post/haiku-development/Request-for-protest-Media-Kit-Extend-media-header-struct
- Backwards compatibility is taken into account and preserved by reducing the
relevant _reserved[] fields.
- Code changes that will actually make use of these extensions are due for the
following commits. As these structure extensions affect several Haiku
components (e.g. media_server, MediaPlayer, etc.) and third party apps (e.g.
StampTV, etc.) I refrain from committing them in one batch with this commit.
This should make it easier to track down bugs originating in this code
change.
(cherry picked from commit 806b6888d2dcf84b4934f8f137a48d3381864d1c)
* Remove unneeded path mashup in curl to find the ca_root_certificates
and use the file in .self/data/ssl. This makes it possible to rename the
package providing ca_root_certificates without everything exploding.
* Use a certificate file in the format cURL expects, not Mozilla source
file in NSS format.
The RFC for Data URLs specifies a nonstandard format, and because of
this it doesn't support queries and fragments. This allows the use of
the # and ? characters in the URL data. We didn't handle this properly,
which would lead to truncated data.
Some URLs may use the % character for other purposes than URL-encoding
(this is seen in some data URLs). Make sure we parse that properly, and
avoid a possible out of bounds access if the percent char is near the
end of the string.
