The reported problem was not actually a bug, since feof() and ferror()
were both checked but both gcc and coverity complained about that and
changing it accordingly actually simplifies the code.
support 29.98, because 48 kHz is divisible by 24000/1001 (it's 2002
samples)
Note that 29.97 (or 59.94) is still not supported because 48 kHz is not
evenly divisible by that value (it is 1601.6 audio samples per 29.97
video frame).
On incorrect device index, the further call succeeds but rate returned
is 0, resulting in wrong assert in ring_buffer_init().
+ s/MODULE_NAME/MOD_NAME for convenience (usual in other code)
if no configuration is set, empty string ("") is passed, not NULL
This resulted in wrong device set 0 set because the atoi doesn't check
its arguments. Example of fixed behavior:
uv -s testcard -r coreaudio
`AudioUnitSetProperty(s->auHALComponentInstance, kAudioOutputUnitProperty_CurrentDevice,
kAudioUnitScope_Global, 1, &device, sizeof(device));` succeeded with 0
for some reason (but not with other values).
Since in last commit, the printed index has changed, print device name
to ensure user that it is the correct one.
+ fixed not freed device state array on cleanup
- describe 'fps' option - although the semantics is obvious, it was not
mentioned that it accepts 'i' (interlaced) suffix
- change FPS in examples to '59.94i' to illustrate the syntax
refer to GH-317
Limits frame rate to specified value.
This can be used if source doesn't keep its nominal frame rate, as some
Magewells do and use higher.
Another use case is just to limit the framerate from eg. 60 to 25 (which
are coprimes, for 60 and 30, already existing capture filter 'every')
can be used.
In Wayland, when resizing windows programmatically glfwSetWindowSize(),
if swap buffers was not triggered, event returning back to the original
resolution is triggered when swap buffer is triggered just after
drawing. It looks like that no drawing should occur before window size
change and swap buffers, seems there has been reports for SDL, eg. [1].
Also do not call gl_resize() after glfw_resize_window() (needless, it
will be triggered via callback after swapping the buffers).
To reproduce the wrong behavior - use Wayland with GLFW native Wayland
build, then: `uv -t testcard -d gl` (size may be any other than the
splashscreen size 512x512).
[1] https://github.com/libsdl-org/SDL/pull/4821
Window width is not taken directly from video desc but rather computed
according to height (to reflect optional aspect ratio). So the window
size needs to be rather rounded to respect odd sizes like 187x77, which
rounded down 186x77, eg.:
uv -t testcard:size=187x77 -d gl
Instead of crashing on assert, print user-friendly message that the Y4M
is not supported. Also print the properties of the file and what is
supported, which allows easy debug and user can eg. request the feature.
this fixes the original commit 8977fd42 (2016-09-02) that presumably
never worked, because there were inverted conditions.
The idea of the original commit (fixed with this) was to conserve CPU
cycles when not receiving any data.
check if Mix_GetSoundFonts() is a usable font and if so, use
This has precedence over bundled songs. But most importantly, it will
allow running also from just compiled source, where there is no sound
font relative to `uv` executable but there could be a sound font in
system paths.
While on x86_64 is libsvtav1 still slightly ahead, on the M1 mac, the
AOM AV1 performs significantly better (2x faster).
The above holds for native builds, it actually looks like the x86_64
build running SVT AV1 on M1 mac doesn't run correctly at all - it
produces just blank picture (green as is zeroed YCbCr buffer).
