ported changes from GPUJPEG, mostly cosmetic
For Win32 implementation, winsock2 is not used at all - Windows stdlib.h
contains _byteswap_* family so it is better to use these and not pull
the whole winsock2.h header struff (and also the winsock library but this
is irrelevannt for UG because we need to link with it unconditionally).
do not tackle with references - needlessly making this more complex
With returning the variable, no static variables needed, just the
references need to be explicitly const (which were previously as well,
although implicitly).
Mark the returned variables as constexpr. Having inline function that
returns reference (although const) to non-const static variable perhaps
disallow inlining. Some caller maight have issued const_cast<> to a
non-const reference and modify the value which may be allowed (the)
static value is non-const.
Setting the vars to non-const should solve the problem. Using constexpr
is just nicer (requires avoiding std::string). Returning the value
directy instead of reference should be OK as well.
Y416 was called UYVA16_422(_conv) which is incorrect, since the codec
subsampling is 4:4:4:4 (444 with alpha).
VUYA8 - added 4444 for the consistency (all YCbCr formats contain
subsampling).
The fix commit 8c19440a (2025-10-01) locked in flush_capture_data(),
which was ok when called from rewind_file(). But that function is
called also from vidcap_file_process_message() which is called with
mutex already held (CID 896223).
So moving the lock from flush_captured_data() up to rewind_file().
Also CID 896221 is fixed - subsequent s->new_msg was called seemingly
without lock (double lock + 1x unlock considered unlocked). Now in this
context one pair lock/unlock was removed which means that the lock is
still held.
fixes CID 896221, CID 896223, commit 8c19440a
The metadata array was actually positionally indexed, which was error prone.
Use rather switch - the advantage is that also a warning is issued if
some enum member not handled and also solves the above.
- s/Captured/Transmitted/ video format (has compressed codec)
- print the input codec in brackets
- do not parse the format from istringstream and print directly
moved from RTP - allows processing for all video_rxtx now
Note that (as just like previously), on the console if 'i' is pressed, the
compressed format is print, not Captured (as indicated by the message).
4K Extreme supports 12 bit on output but not in input. Those devices
correctly detect 12-bit input but the captured buffer is scrambled.
So enforce 10-bit capture if 12 bit input is detected but not supported.
Since the commit 443fe59d (2023-04-11), the sole CS change was not
handled.
There can be 2 cases:
1. bit-depth change (without color-space), which was not handled
2. CS changed was even more harmful because no signal was detected then
The above cases should be handled. The bit-depth handle should be
ignored just if codec= is explicitly specified, in which case the depth
is taken from the argument (specified codec CS is not honored - YUV must
be captured as YUV, RGB similarly).
More dense lines (reduce spaces) - when terminal is narrow, less likely
wraps to next line. For display it even has <= 80 rows, for capture it
may be more (mode FourCC is print so there is less spare space).
When no video is arriving, the resized window doesn't have defined
content.
Moreover, if using Wayland, the window change of fullscreen is not
applied at until next refresh (new frame in this case).
Fix the benchmark tool build when src/config.h present and CUDA
conversions enabled there. The appropriate CUDA files will be required
if HAVE_LAVC_CUDA_CONV is defined.
The [file] (URL few commits below) has actually set r_frame_rate as
1/1200k, which causes the libavcodec JPEG decoder crash (received is
something like 1792i due to overflow). avg_frame_rate contains 1/25.
Prior to the commit 9891f19a (HEAD~3) avio_seek was called prior to
avformat_seek_file. This worked fine for normal containers (eg. MP4). But
after this was swapped, avio_seek after that broke that.
In order to work properly, run avio_seek() just if avformat_seek_file
fails (fixes temporarily broken .mp4 loop). Only case remaining is
JPEG/MJPEG file loop, which returns 0 for the avformat_seek_file() call.
This is handled ad hoc (I don't have any better solution now).
Rewinding the file (:loop option) doesn't work using raw HEVC like with
the [file].
avformat_seek_file retrurns EPERM, which was handled as an error, so
stopped the worker.
avio_seek seems to do the job but must be performed _after_ (unsuccessful)
avformat_seek_file.
[file]:
https://ultravideo.fi/video/ReadySetGo_3840x2160_120fps_420_8bit_HEVC_RAW.hevc
Use fixed width second precision - looks better when the stat lines are
below each other (if the order of magnitude matches, the same alignment).
Use B instead of bytes (shorter, also likely won't exceed 80 rows).
steps to reproduce the fixed behavior:
1) run `hd-rum-transcode 8M 7000 100::`
2) press Ctrl-C
There is compress_done() called once - once by the now commented out
line and then also with compress_state_deleter::operator().
This problem technically occurs since 2ca38e7c (16th Jun 2025) when
module_done() was replaced with compress_done(), which doesn't allow double
call (in cotrary to module_done(), which does). The root of the problem
is perhaps the commit 7460563 (2022-01-18).
