If more than one file is specified on the command line and the `-L`
option is used, the totals field will show the longest line
encountered; it is not a sum like the other values.
The previous version had a sequence of calls that are likely not
optimized out, while this version is strictly a sequence of static type
conversion which are always fully optimized out.
The intention for this utility is to eventually become a general-purpose
multimedia conversion tool like ffmpeg (except probably not with as many
supported formats, stream mappings and filters). For now, we can not
write any video format so the added complexity is not necessary at the
moment.
WavWriter needs a TON of modernization work, but for now this commit
just tackles two FIXMEs by converting samples correctly into all
supported integer PCM formats. The supported formats are only signed
16-bit and unsigned 8-bit for now, but can be expanded later. At least
we don't produce horrible speaker-destroying noise when writing any
other format.
The JS::VM now owns the one Bytecode::Interpreter. We no longer have
multiple bytecode interpreters, and there is no concept of a "current"
bytecode interpreter.
If you ask for VM::bytecode_interpreter_if_exists(), it will return null
if we're not running the program in "bytecode enabled" mode.
If you ask for VM::bytecode_interpreter(), it will return a bytecode
interpreter in all modes. This is used for situations where even the AST
interpreter switches to bytecode mode (generators, etc.)
This was meant to be a temporary unit testuntil we could run test-js
in bytecode mode. This has been possible for a long time now, so let's
remove the unnecessary extra program.
This encoder is very naive as it only output SOF0 images and uses
pre-defined Huffman tables.
There is also a small bug with quantization which make using it
over-degrade the quality.
It's a little bit of a battle to fit all of the media controls in the
available width of the media element. We currently cram everything on
one horizontal line. We've made adjustments to be able to fit it all,
but the controls (in particular the media timeline) are rather squished.
This paints the timeline above the other media controls now. This
provides much more granular control over the playback position when
scrubbing, and makes it much more likely for the timeline to render at
all.
For example, on https://xboygeniusx.bandcamp.com/album/the-record, a
song with a duration of 03:52 would actually complete in 03:33 on my
machine. This issue only affects Ladybird on Lagom; on Serenity, we
already take the entire 03:52 to play the song.
This fixes the issue when size of abspos items is considered to be
resolvable without performing layout which is not correct in the
scenarious when top/right/bottom/left properties are not auto.
This implements the ability to drag the timeline and volume buttons on
UA-rendered media controls. The two behave a bit differently:
Volume is updated as the user drags the volume button. This isn't a very
expensive operation, so updating in real-time and hearing the volume
change feels nice.
The current time, on the other hand, is not committed until the user
releases the mouse button. Performing a seek every time we get a mouse-
move event is pretty laggy, especially for video. However, we still want
to render updates on the timeline itself (so the position of the button
and the timestamp update as you drag). To do so, we internally pause the
media and override the timestamp provided to the layout node.
In the future, we may be able to seek video periodically to provide some
visual feedback. For example, we can seek after every N seconds of
scrubbing, or when the user pauses scrubbing for a while.
It's currently possible to seek to the total sample count of an audio
loader. We must limit seeking to one less than that count.
This mistake was duplicated in both AudioCodecPluginSerenity/Ladybird,
so the computation was moved to a helper in the base AudioCodecPlugin.
