vole

joined 1 year ago
[โ€“] vole@lemmy.world 8 points 1 month ago (2 children)

I'd think so. 3k is so many pixels to compute and send 60 times a second.

But this video says the effect on battery life in their test was like 6%, going from 4k to 800x600. I can imagine that some screens are better at saving power when running at lower resolutions... but what screen manufacturer would optimize energy consumption for anything but maximum resolution? ๐Ÿค” I guess the computation of the pixels isn't much compared to the expense of having those physical dots. But maybe if your web browser was ray-traced? ... ?!

Also, if you take a 2880x1800 screen and divide by 2 (to avoid fractional scaling), you get 1440x900 (this is not 1440p), which is a little closer to 720p than 1080p.

[โ€“] vole@lemmy.world 2 points 3 months ago* (last edited 3 months ago)

I haven't made a bridge to a VM before today, or made a bridge with Network Manager. That being said, I was able to persuade Network Manger to get a bridge working, and there are a few things I can note:

  • When you setup the bridge, the host network interface should become a slave to the bridge. This means that the physical network interface should not have an IP Address, and your bridge should now be where you configure the host's IP address.

    • After you start the VM, you should be able to run ip link | grep 'master br0' on the host, and it should display 2 interfaces which are slaves to br0. One for the physical ethernet interface, one for the VM (vnet). And it should only list your ethernet interface when the VM is off.
  • The RedHat tutorial does not show the bridge and the host having different IP addresses, the RedHat tutorial shows the bridge and the guest having different IP addresses. Actually, no, the RedHat tutorial shows the libvirt NAT bridge, not even the bridge that the tutorial describes creating... If you set the IP address of virbr0, I don't know what happens.

  • If your VM's network adapter is connected to the host's bridge, then you should be able to log into your VM and set a static IP address.

I had a lot of problems getting Network Manager to actually use my ethernet interface as a slave for the bridge. Here's what worked for me, though:

nmcli con show
nmcli con down 'Wired Connection 1'
nmcli con modify 'Wired Connection 1' connection.autoconnect no
nmcli con add type bridge con-name br0 ifname br0
nmcli connection add type bridge-slave ifname enp7s0 master br0
nmcli con modify br0 connection.autoconnect yes
nmcli con modify bridge-slave-enp7s0 connection.autoconnect yes
nmcli con modify br0 ipv4.method manual ipv4.addresses 172.16.0.231/24 bridge.stp no
sudo systemctl restart NetworkManager.service
nmcli con show
ip addr
  • Instead of enp7s0, you'd use enp1s0 I guess.
  • Above, I manually set my bridge IP address to a static address because my ethernet interface is wired directly to another computer, so no DHCP for me. If you have DHCP on your ethernet network, you probably don't need to set "ipv4.method" or "ipv4.addresses".
  • I set "bridge.stp" to "no" because my network doesn't have any redundant paths, and the stp process seems to take like 25 seconds before I can use the bridge network.

After that, I can go into "Virtual Machine Manger", set my VM's NIC's Network Source to "Bridge device...", Device name to"br0", boot my VM, login to my VM, configure my VM's ip address. And then I can connect to the VM's IP address from the physical ethernet network.

[โ€“] vole@lemmy.world 2 points 10 months ago (2 children)

thanks, I'll try out the libx264 encoder next time

[โ€“] vole@lemmy.world 2 points 10 months ago

Oh wow, I didn't know (free) Davinci didn't support using H.264 as source media, that feels rather limited.

[โ€“] vole@lemmy.world 4 points 10 months ago* (last edited 10 months ago) (6 children)

Completely tangential tip, but in the very-limited video editing I've done recently: I've used Davinci Resolve, rendered as .mov, and then used ffmpeg to render to my actual desired format. e.g. h264 w/ aac audio so I can upload to Youtube:

ffmpeg -i input.mov -c:v libopenh264 -profile:v high -c:a aac -pix_fmt yuv420p output.mp4

I do think that finding the right flags to pass to ffmpeg is a cursed art. Do I need to specify the video profile and the pix_fmt? I don't know; I thought I did when I adventured to collect these flags. Though maybe it's just a reflection of the video-codec horrors lurking within all video rendering pipelines.

edit: there may also be nvidia-accelerated encoders, like h264_nvenc, see ffmpeg -codecs 2>/dev/null | grep -i 'h\.264'. I'm not sure if the profile:v and pix_fmt options apply to other encoders or just libopenh264.

[โ€“] vole@lemmy.world 12 points 11 months ago (3 children)

/home is not deprecated, it's optional but common. Here is the section from FHS: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s08.html