Thanks for the information.
Besides hwinfo there are other options like lshw, hardinfo and inxi for checking hardware details on linux.

Yeah, that’s correct.
The -u option can be used to check udp ports exclusively.

Here’s what I have right now that works:
ffmpeg -init_hw_device qsv=hw -filter_hw_device hw -i input.mkv -vf zscale=transfer=linear,tonemap=clip,zscale=transfer=bt709,format=yuv420p,scale=1280:-2 -vcodec h264_qsv -map 0:v -map 0:a:0 -map 0:a:1 -c:a copy -map 0:s:0 -c:s copy outputfile720p.mkv

What this is doing:
1)UHD HDR hevc source
2)Tonemapping
3)Scaling to 720p
4) Encoding to h264
5) Copying the first two audio tracks and the first subtitle track using the map function. I have to map video as well or else it fails.

This correctly tonemaps, and I can tell via intel_gpu_top that some gpu is being used, but the filter is not going through qsv.

Bonus question: I can’t get global_quality to work, how does that work with -vcodec h264_qsv

do you have source ?

Thanks,
Chuan

that’s a good idea, specially for a “mobile” form factor device that can tell its heat levels through body touch.

1.26 Joules energy-psys
0.80 Joules energy-pkg
…

Even this energy-psys only “reflects” the Watts indicated by my real (external) power meter. I read between 2.8 – 4.2 W depending on the kernel/distro. Good idling is with 3.2W real, 1W psys and a cool case. Not-so-good is 3.8W real, 3W psys and “feverish” case after 15 minutes. I am not even convinced the power meter manages to measure the (variable?) current precisely.

25 W noturbo, 75% pstate limit
4.0 W minimal activity / bad idling
3.2 W good idling (can even stay at 2.8 W – but how exactly?!?)
1.8 W “freeze”
1.1 W suspend-to-ram
0.9 W (!) Main power Off

This is with a 2017 intel nuc mini-pc. The numbers show you CAN get quite close to “freeze” system state. Feeling the warmth of the case is the best control, especially when the fan is not blowing (yet).

Thanks for the comment

1. Root Privileges: Running `iotop` typically requires root privileges because it needs access to kernel-level I/O statistics. This means you need to run it with `sudo`, which might not always be feasible or desired for all users.

2. System Impact: Monitoring I/O usage in real-time can consume system resources itself, potentially affecting the overall system performance. This impact might be more pronounced on systems with heavy I/O loads or limited resources.

3. Limited Historical Data: `iotop` provides real-time data but does not offer a history of disk I/O usage over time. If you need to analyze historical I/O patterns or trends, you might need to complement `iotop` with other tools that collect and store historical data.

4. Complexity and Learning Curve: Understanding the various columns and data presented by `iotop` might require some familiarity with disk I/O concepts and Linux internals. This can be a challenge for users who are not well-versed in these areas.

5. Dependency and Availability: `iotop` might not be installed by default on all Linux distributions. Users need to ensure that it is available on their system or install it using package managers.

6. Non-Standard Behavior: Different versions of `iotop` might have slightly different behavior and options depending on the distribution and version of Linux. This can lead to inconsistencies when moving between different systems.

7. Process Identifier (PID) Changes: In systems with dynamic processes, the PIDs of processes can change over time. This can make it challenging to track specific processes’ I/O usage accurately.

8. External Dependencies: `iotop` relies on the `python` and `psutil` libraries to gather and display I/O information. If these dependencies are not present or configured correctly, `iotop` might not function as expected.

Despite these potential problems, `iotop` remains a valuable tool for gaining insights into real-time disk I/O usage by processes on a Linux system. Users can manage and mitigate these issues by considering the limitations and being aware of the potential impact on their system’s performance.

thanks for the feedback. shall improve in future.
glad that you found the guide useful.

Re: improvements, on the server side code, zero out the buffer after the write (ie: after “send the message back to client”) in the connection handler.

1. **Troubleshooting Processes:**
You can use `lsof` to identify which processes have certain files open, which can be helpful when diagnosing issues like “file in use” errors.

Example: To find processes that have a specific file named “example.txt” open:
“`bash
lsof /path/to/example.txt
“`

2. **Monitoring Network Connections:**
`lsof` can help you monitor network connections and find out which processes are using certain network sockets.

Example: To list all network sockets in use:
“`bash
lsof -i
“`

3. **Checking for Deleted Files:**
Sometimes, even if a file is deleted, processes might still have it open. `lsof` can reveal such “deleted but still open” files.

Example: To find deleted files that are still open:
“`bash
lsof +L1
“`

4. **Identifying Processes Holding a File:**
If you’re trying to determine which processes are preventing you from unmounting a filesystem or ejecting a removable device, `lsof` can help.

Example: To find processes using files on a specific filesystem:
“`bash
lsof /mnt/myfilesystem
“`

5. **Monitoring Users’ Activity:**
Administrators can use `lsof` to monitor users’ activity by checking which files or sockets processes are accessing.

Example: To list all files opened by a specific user (replace “username” with the actual username):
“`bash
lsof -u username
“`

6. **Finding Processes Using a Port:**
You can use `lsof` to identify which processes are using a specific port, which is helpful when debugging network-related issues.

Example: To find processes using port 8080:
“`bash
lsof -i :8080
“`

7. **Checking Shared Libraries:**
`lsof` can help you identify which processes have certain shared libraries loaded.

Example: To find processes using a specific shared library (replace “libname.so” with the library name):
“`bash
lsof /path/to/libname.so
“`

Remember that using the `lsof` command often requires superuser (root) privileges to access information about all processes. Always exercise caution and ensure you have the necessary permissions before running `lsof`.