The less assembler in our sources the better. These functions wouldn't
be used very much since SupportDef.h inlines them, but the symbols should
be available.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
Time to get rid of some asm code. Surprisingly, it appears that
on x86[_64] the emitted code for atomic_test_and_get() isn't as efficient
as it could be, even with -O2, but cmpxchg is so expensive that this slight
difference shouldn't matter much.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
If GCC knows what these functions are actually doing the resulting
code can be optimized better what is especially noticeable in case of
invocations of atomic_{or,and}() that ignore the result. Obviously,
everything is inlined what also improves performance.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
- Lazy initializing the fDecodedData variable fits best in
_ResetRawDecodedAudio() as fRawDecodedAudio is all about managing properties
of fDecodedData. So fDecodedData having some memory allocated is seen as a
property here.
- Updated documentation accordingly
- No functional change intended.
- For best performance the color conversion function expects a memory location
aligned to 32 bytes. Without that alignment the color conversion function
falls back to a slower conversion path. This fix was measured via
DO_PROFILING and tested with various 1080p video files.
- The first decoded video frame was always zero bytes large, due to passing the
wrong linesize to the color conversion function. The field containing the
right linesize (fHeader.u.raw_video.bytes_per_row) simply wasn't initialized
yet. Fix it by updating fHeader first before applying deinterlacing and color
converting to the decoded video frame.
Tested with mpeg2_decoder_test where the first picture now isn't empty
(black) anymore.
- Padding is required by FFMPEG for correct operation of all audio 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.
- Resolve TODOs by unifying fVideoChunkBuffer and fChunkBuffer back into
fChunkBuffer because audio path is responsible for freeing fChunkBuffer now.
Resolved TODOs apply to the replacing fVideoChunkBuffer variable by
fChunkBuffer, rename some methods by removing the "Video" part, collapse two
methods into one (_LoadNextChunkIfNeededAndAssignStartTime()).
No functional change intended.
- Enhance "logging stream to file" functionality to write to distinct logging
files for audio and video. Before this commit one could only log video
streams. But with unifying the _LoadNextChunkIfNeededAndAssignStartTime()
audio streams gained the logging functionality for free. But now audio and
video streams would be written in the same log file when watching a media
file containing both audio and video. This is prevented by the distinct
logging mentioned above.
- Update documentation accordingly.
- Main reasons for this refactoring of negotiation steps are to increase
readability and to be on par with the video path.
- Rearrange some negotiation steps in video path to be on par with audio path.
- Add documentation for the new method and update existing documentation
accordingly.
- No functional change intended.
- Fix max line length, switch statement style and some pointer comparisons in
if statements. No functional change intended.
Note: There may be more coding style violations lurking.
- Main purpose is to debug a/v synchronization issues by playing the dumped
mpeg ts data in alternative video players (like ffplay or MediaPlayer) and
see how those behave.
- The commit diffs shows some coding style violations (max. line length) that
show up throughout the whole DVBMediaNode class. Those will be fixed in the
next commit to keep a clean separation between the different code changes.
- Each PowerMonitor now exports a set of descriptors rather than
only a single one. This allows e.g. PowerButtonMonitor to watch
multiple possible button event sources rather than one.
This gets power button working again on some hardware that exports
multiple ACPI power buttons, but offers no obvious way to determine
which one is actually active/being used. In the long term though, it'd
be nice to have a well-defined kernel power event interface that an app
could subscribe to, rather than having to watch individual devfs
descriptors.
Thanks to tqh and korli for advice/review.
- On some hardware, both the fixed function FADT as well as the
device-based power interfaces are present. In such a case we
would fail to publish one or the other, depending on which was
enumerated first, since we'd always attempt to publish the same
name regardless. Now we differentiate the device name for fixed vs
device.
- Only enable fixed function for actual fixed devices.
- Improve tracing.
This still uses the request I had prepared earlier, not the new bulk
request which can get information for the entire package list in one
request. It also has no caching, so it runs for quite a while in the
background (dedicated thread, so hopefully no harm done by keeping it
enabled).
Thanks Augustin, for the parser!
Based on an earlier piece of source code of mine that parsed JSON into
QObjects, this JSON parser creates a BMessage tree.
Will be used by Stephan in HaikuDepot for communication with the web app.
- Kudos to Marcus Overhagen for laying out the general idea of automatic
detection by sharing some of his dvb code examples with me.
- Automatically detect the audio frame rate, channel count and sample format.
- Share audio sample format conversion code between AVFormatReader and
AVCodecDecoder.
- Tested with several video and audio files via MediaPlayer.
- Tested also with test case mp3_decoder_test -after- removing the hard coded
audio decoding parameters. Although the test shows that auto detection is
working (via stepping through the auto detection code path) the complete test
is still failing, due to missing implementation of incomplete audio frame
decoding.
- Add and update the documentation accordingly.
- Main purpose is to prepare auto detection of audio frame properties for
media formats that encode those properties in the frames themself (e.g. MP3)
instead of in the container format (e.g. WMA).
The main difference between akin named methods _DecodeNextAudioFrame() and
_DecodeNextAudioFrameChunk() is that the former method deals with providing
the exact number of audio frames expected by the caller of
BMediaDecoder::Decode() and the latter deals with decoding any number of
audio frames at all.
- New documentation added and existing documentationupdated accordingly.
- No functional change intended.
- Some small refactoring when resetting fRawDecodedAudio. Instead of letting
FFMPEG reset fRawDecodedAudio we do it manually to preserve the allocated
memory in fRawDecodedAudio->opaque (otherwise FFMPEG's
avcodec_get_frame_defaults() would NULLify the opaque pointer without
releasing the allocated memory.
- Keep track of the total size of fDecodedData in fRawDecodedAudio->linesize[0]
instead of relying on calculating it every time it is needed. This makes the
code more comprehensible.
- Main reason for this refactoring is to increase readability and thus make
audio decode path more comprehensible.
- Added documentation for the new method accordingly.
- Small change in calculating the decoded data size to clear when error occurs
during decoding. This way it is more readable and more consistent with
calculations of decoded data size on other locations.
- No functional change intended.
- Main reason for this refactoring is to increase readability and thus make the
audio decode path more comprehensible.
- Added documentation for the new method accordingly.
- No functional change intended.
- Main reasons are to increase readability of audio path and to demonstrate
that chunk loading in audio and video path is the same code that can be
focused in one method (instead of two at the moment). Added a TODO for
collapsing both methods into one and the conditions that must hold true to
do so (just in case I'll be hitted by a bus and someone else has to proceed).
Collapsing is scheduled for a later commit.
- Added documentation for the new method accordingly.
- Make use of full line length in comments of
_LoadNextVideoChunkIfNeededAndAssignStartTime().
- No functional change intended.
- Main reason for this refactoring is to increase readability and thus make the
audio decode path more comprehensible.
- Added documentation for the new method accordingly.
- Small refactoring for detecting when to update fRawDecodedAudio's properties.
This is a preparation step for factoring out the flushing of the
fDecodedDataBuffer in a later commit.
- No functional change intended.
* Use a BTextView for the "no preview" text again, as Skipp_OSX pointed
this allows it to word wrap as needed with any font bigger than 10pt.
* Show a black screen rather than the "no preview" text for Darkness and
when a screensaver fails to load. This matches what screen_blanker will
do.
The BSD grep doesn't know about \s. Moreover, checking for elf (rather
than ELF) seems to make more sense, as that's the format name, not part
of the description.
Patch suggested by geist. Thanks!
- FFMPEG handles the relationship of start time between encoded and decoded
audio data now by using the fTempPacket->dts and the
fDecodedDataBuffer->pkt_dts fields. We still have to manually keep track of
start times for consecutive audio frames though to support returning a number
of audio frames that may assembled of partial AVFrames.
- The start time of the very first audio frame data packet returned by Decode()
is now correctly calculated based on GetNextChunk() start times instead of
being always zero.
- Introduce fRawDecodedAudio that serves as a container to store properties of
the audio frames stored in fDecodedData. This prepares the population of the
fHeader structure with audio frame properties needed to allow clients of
BMediaDecoder::Decode() detect audio format changes in a later commit.
- Remove fStartTime as it is superflous now.
- The reason for compiler complaining about "INT64_C is not defined here" is
gone since the addition of the compiler flag "-D__STDC_CONSTANT_MACROS"
to the Jamfile some time ago. This flag allows C++ to use C99 math features.
- No functional change intended.
- Also change what is printed for video frames. Currently both
debug_fframe_[audio|video] are used in AVCodecDecoder only and thus are
streamlined for their usage there. For example we print the AVFrame.pkt_dts
field instead of the AVFrame.pkt field because the later one is never touched
by AVCodecDecoders usage of the FFMPEG library.
Note: AVFrame.pkt being never touched means that it always contains the value
AV_NOPTS_VALUE making it less useful for debug purposes.
