Kalcifer

joined 11 months ago
[–] Kalcifer@sh.itjust.works 10 points 5 days ago (1 children)
[–] Kalcifer@sh.itjust.works 9 points 5 days ago (11 children)
[–] Kalcifer@sh.itjust.works 8 points 1 week ago* (last edited 1 week ago) (5 children)

From what landfill did you unearth this 2010 era edgy ignorant teen humor?

[–] Kalcifer@sh.itjust.works 3 points 1 week ago

T460, by my experience, has been perfect.

[–] Kalcifer@sh.itjust.works 16 points 1 week ago (3 children)
[–] Kalcifer@sh.itjust.works 4 points 1 week ago (5 children)
[–] Kalcifer@sh.itjust.works 16 points 1 week ago (5 children)
[–] Kalcifer@sh.itjust.works 1 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

So, I bought an EasyCap device and ran some tests. I encountered a few things that I don't quite understand, and I would really appreciate your input!

I used a test VHS tape that I purchased at a thrift store (I'm not 100% sure if it's NTSC or PAL, but I'm decently confident that it's NTSC) (I'm also not sure what its aspect ratio is — I think it's either 1.33:1 or 4:3). I'm playing the tape in a PV-D4745S-K VCR. I have the composite out of the VCR going into the aforementioned capture device which is connected to a computer running Arch Linux.

First, I used the following ffmpeg capture settings:

ffmpeg -i /dev/video2 out.mkv

After capturing a short snippet of the test tape, I probed its metadata with ffprobe -i out.mkv, and saw that it was strangely in 25FPS, and 720x576 (which caused the video to be stretched vertically slightly), which is PAL. So, somehow the NTSC VHS being played in an NTSC VCR was being converted to PAL. In addition to that, the colors in the video were very overexposed. I tried a bunch of different manual settings like specifying interlacing with -vf "interlace", -standard ntsc, -vf scale=720:480, -vf fps=29.97, -standard NTSC, and none of them solved the issue. I then came across this answer on StackOverflow which stated that capture cards themselves have settings for the video feed, and ffmpeg can modify them with the -show_video_device_dialog true option. From the ffmpeg documentation:

show_video_device_dialog

If set to true, before capture starts, popup a display dialog to the end user, allowing them to change video filter properties and configurations manually. Note that for crossbar devices, adjusting values in this dialog may be needed at times to toggle between PAL (25 fps) and NTSC (29.97) input frame rates, sizes, interlacing, etc. Changing these values can enable different scan rates/frame rates and avoiding green bars at the bottom, flickering scan lines, etc. Note that with some devices, changing these properties can also affect future invocations (sets new defaults) until system reboot occurs.

Unfortunately, when trying this option, an error popped up saying that the option was unrecognized. After some digging, and prompting ChatGPT, I found that apparently that option is Windows only as it relies on Windows' "DirectShow system". The way to modify it in Linux is to use the Video4Linux2 framework, which is controlled with v4l2-ctl. So, I ran the following:

v4l2-ctl --device=/dev/video2 --list-formats-ext

which showed the following entry:

...
[0]: 'YUYV' (YUYV 4:2:2)
    size: Discrete 720x480
...
        Interval: Discrete 0.033s (30.000 fps)
...

So it is able to output NTSC — ie 720x480 at 29.97fps (I guess it rounds up the fps for whatever reason). So I then tried

ffmpeg -f v4l2 -video_size 720x480 -i /dev/video2 out.mkv

and it was able to output the video at 720x480 29.97 fps as desired, and the colors were no longer super overexposed. Using the -vf "interlace" flag, I do seem to also be able to capture interlaced video, so it also doesn't force progressive which is nice.

I thought that the capture card would be able to just autodetect what the input resolution was to allow ffmpeg to record at that, or at the very least, I would expect that specifying NTSC in ffmpeg would force the standard, but neither of those worked and I'm not sure why. There's also still an ongoing issue of the video being zoomed in/cropped slightly (I verified this by comparing against online sources of the same video (some were a VHS rip, others from non-VHS sources)). I tested the VCR's output on a regular TV, but unfortunately the TV forced 4:3 and cropped it even more, so I wasn't able to make a perfect comparison, though that was only additional horizontal cropping — the vertical cropping from before was still present. To be able to verify that, I'll have to pick up another test VHS tape to see if perhaps the test VHS tape that I currently have was just recorded in a cropped format.

 

there is no worry about keeping to our release date of October 21st [for Factorio: Space Age and Factorio 2.0] [1].

References

 

I have a bunch of old VHS tapes that I want to digitize. I have never digitized VHS tapes before. I picked up a generic HDMI capture card, and a generic composite to HDMI converter. Using both of those, I was planning on hooking a VCR up to a computer running OBS. Overall, I'm rather ignorant of the process. The main questions that I currently have are as follows:

  • What are the best practices for reducing the risk of damaging the tapes?
  • Are there any good steps to take to maximize video quality?
  • Is a TBC required (can it be done in software after digitization)?
  • Should I clean the VCR after every tape?
  • Should I clean every tape before digitization?
  • Should I have a separate VCR for the specific purpose of cleaning tapes?

Please let me know if you have any extra advice or recommendations at all beyond what I have mentioned. Any information at all is a big help.

 

Solution

This is a bug in KDE Plasma [1.1][2]. It appears that it might be fixed in KDE Plasma v6.2 [1.2][3].

Original Post

I have noticed this behavior with Element and Signal while playing Deadlock. The game will have a pretty severe stutter, ie the frame-rate will substantially dip, for half a second or so at the exact moment that a message is received. It seems to happen with every message. Do note that these are only messages that would result in a system notification. All other messages that are silent, ie they have no pop-up notification, do not result in any stutter.

  • OS: Arch Linux, Kernel: v6.6.49-1-lts
  • DE: KDE Plasma v6.1.4
  • WM: Wayland
  • CPU: Intel Core i5-4690k
  • GPU: AMD Radeon RX 6600

Updates

  • I have tried disabling this setting in Deadlock:
  • I have tried windowed-borderless
  • I have noticed that the moment that the stutter occurs, my CPU spikes maybe 20% and my GPU drops to 0%.

References

  1. @narc0tic_bird@lemm.ee. "Have you ever experienced stuttering in a game if you receive a message in a desktop messaging app during gameplay?". sh.itjust.works. Lemmy. Published: 2024-09-09T23:12:24Z. Accessed: 2024-09-10T00:03Z. https://sh.itjust.works/comment/13818926. https://lemm.ee/comment/14674507.
    1. it’s a bug in KDE Plasma

    2. [the bug] might be fixed [in KDE Plasma] 6.2

  2. "Bug 487780: Fullscreen game stutter when Plasma receives notifications.". Robert. bugs.kde.org. Published: 2024-05-30T03:58Z. Accessed: 2024-09-10T00:06Z. https://bugs.kde.org/show_bug.cgi?id=487780.
  3. Zamundaaa. "Bug 487780: Fullscreen game stutter when Plasma receives notifications.". bugs.kde.org. Published: 2024-08-19T12:01:08Z. Accessed: 2024-09-10T00:13Z. https://bugs.kde.org/show_bug.cgi?id=487780#c13.

    There are some remaining code paths that can block direct scanout - namely effects that haven't been fixed, or that may need to block direct scanout in some situations. There's a new API in 6.2 that effects can use though, https://invent.kde.org/plasma/kwin/-/merge_requests/6203, which blocks direct scanout only when really necessary. It's implemented for all built in effects, and external javascript effects automatically make use of this API too.

7
Theseus' Axe (youtube.com)
submitted 3 weeks ago* (last edited 3 weeks ago) by Kalcifer@sh.itjust.works to c/philosophy@lemmy.world
 

References

 

References

 

There's currently 2 follow up videos:

  1. https://www.youtube.com/watch?v=t63zjRnJ9iI
  2. https://www.youtube.com/watch?v=WbGFnIhf-6Y

References

40
submitted 1 month ago* (last edited 1 month ago) by Kalcifer@sh.itjust.works to c/git@programming.dev
 

Git records the local timezone when a commit is made [1]. Knowledge of the timezone in which a commit was made could be used as a bit of identifying information to de-anonymize the committer.

Setting one's timezone to UTC can help mitigate this issue [2][3] (though, ofc, one must still be wary of time-of-day commit patterns being used to deduce a timezone).

References

  1. Git documentation. git-commit. "Date Formats: Git internal format". Accessed: 2024-08-31T07:52Z. https://git-scm.com/docs/git-commit#Documentation/git-commit.txt-Gitinternalformat.

    It is <unix-timestamp> <time-zone-offset>, where <unix-timestamp> is the number of seconds since the UNIX epoch. <time-zone-offset> is a positive or negative offset from UTC. For example CET (which is 1 hour ahead of UTC) is +0100.

  2. jthill. "How can I ignore committing timezone information in my commit?". Stack Overflow. Published: 2014-05-26T16:57:37Z. (Accessed: 2024-08-31T08:27Z). https://stackoverflow.com/questions/23874208/how-can-i-ignore-committing-timezone-information-in-my-commit#comment36750060_23874208.

    to set the timezone for a specific command, say e.g. TZ=UTC git commit

  3. Oliver. "How can I ignore committing timezone information in my commit?". Stack Overflow. Published: 2022-05-22T08:56:38Z (Accessed: 2024-08-31T08:30Z). https://stackoverflow.com/a/72336094/7934600

    each commit Git stores a author date and a commit date. So you have to omit the timezone for both dates.

    I solved this for my self with the help of the following Git alias:

    [alias]
    co = "!f() { \
        export GIT_AUTHOR_DATE=\"$(date -u +%Y-%m-%dT%H:%M:%S%z)\"; \
        export GIT_COMMITTER_DATE=\"$(date -u +%Y-%m-%dT%H:%M:%S%z)\"; \
        git commit $@; \
        git log -n 1 --pretty=\"Autor: %an <%ae> (%ai)\"; \
        git log -n 1 --pretty=\"Committer: %cn <%ce> (%ci)\"; \
    }; f"
    


Cross-posts:

19
submitted 1 month ago* (last edited 1 month ago) by Kalcifer@sh.itjust.works to c/privacy@lemmy.world
 

Git records the local timezone when a commit is made [1]. Knowledge of the timezone in which a commit was made could be used as a bit of identifying information to de-anonymize the committer.

Setting one's timezone to UTC can help mitigate this issue [2][3] (though, ofc, one must still be wary of time-of-day commit patterns being used to deduce a timezone).

References

  1. Git documentation. git-commit. "Date Formats: Git internal format". Accessed: 2024-08-31T07:52Z. https://git-scm.com/docs/git-commit#Documentation/git-commit.txt-Gitinternalformat.

    It is <unix-timestamp> <time-zone-offset>, where <unix-timestamp> is the number of seconds since the UNIX epoch. <time-zone-offset> is a positive or negative offset from UTC. For example CET (which is 1 hour ahead of UTC) is +0100.

  2. jthill. "How can I ignore committing timezone information in my commit?". Stack Overflow. Published: 2014-05-26T16:57:37Z. (Accessed: 2024-08-31T08:27Z). https://stackoverflow.com/questions/23874208/how-can-i-ignore-committing-timezone-information-in-my-commit#comment36750060_23874208.

    to set the timezone for a specific command, say e.g. TZ=UTC git commit

  3. Oliver. "How can I ignore committing timezone information in my commit?". Stack Overflow. Published: 2022-05-22T08:56:38Z (Accessed: 2024-08-31T08:30Z). https://stackoverflow.com/a/72336094/7934600

    each commit Git stores a author date and a commit date. So you have to omit the timezone for both dates.

    I solved this for my self with the help of the following Git alias:

    [alias]
    co = "!f() { \
        export GIT_AUTHOR_DATE=\"$(date -u +%Y-%m-%dT%H:%M:%S%z)\"; \
        export GIT_COMMITTER_DATE=\"$(date -u +%Y-%m-%dT%H:%M:%S%z)\"; \
        git commit $@; \
        git log -n 1 --pretty=\"Autor: %an <%ae> (%ai)\"; \
        git log -n 1 --pretty=\"Committer: %cn <%ce> (%ci)\"; \
    }; f"
    


Cross-posts:

79
submitted 1 month ago* (last edited 1 month ago) by Kalcifer@sh.itjust.works to c/privacy@lemmy.ml
 

Git records the local timezone when a commit is made [1]. Knowledge of the timezone in which a commit was made could be used as a bit of identifying information to de-anonymize the committer.

Setting one's timezone to UTC can help mitigate this issue [2][3] (though, ofc, one must still be wary of time-of-day commit patterns being used to deduce a timezone).

References

  1. Git documentation. git-commit. "Date Formats: Git internal format". Accessed: 2024-08-31T07:52Z. https://git-scm.com/docs/git-commit#Documentation/git-commit.txt-Gitinternalformat.

    It is <unix-timestamp> <time-zone-offset>, where <unix-timestamp> is the number of seconds since the UNIX epoch. <time-zone-offset> is a positive or negative offset from UTC. For example CET (which is 1 hour ahead of UTC) is +0100.

  2. jthill. "How can I ignore committing timezone information in my commit?". Stack Overflow. Published: 2014-05-26T16:57:37Z. (Accessed: 2024-08-31T08:27Z). https://stackoverflow.com/questions/23874208/how-can-i-ignore-committing-timezone-information-in-my-commit#comment36750060_23874208.

    to set the timezone for a specific command, say e.g. TZ=UTC git commit

  3. Oliver. "How can I ignore committing timezone information in my commit?". Stack Overflow. Published: 2022-05-22T08:56:38Z (Accessed: 2024-08-31T08:30Z). https://stackoverflow.com/a/72336094/7934600

    each commit Git stores a author date and a commit date. So you have to omit the timezone for both dates.

    I solved this for my self with the help of the following Git alias:

    [alias]
    co = "!f() { \
        export GIT_AUTHOR_DATE=\"$(date -u +%Y-%m-%dT%H:%M:%S%z)\"; \
        export GIT_COMMITTER_DATE=\"$(date -u +%Y-%m-%dT%H:%M:%S%z)\"; \
        git commit $@; \
        git log -n 1 --pretty=\"Autor: %an <%ae> (%ai)\"; \
        git log -n 1 --pretty=\"Committer: %cn <%ce> (%ci)\"; \
    }; f"
    


Cross-posts:

 

You can sort GitHub issues by most "upvoted" using this syntax:

is:issue is:open sort:reactions-+1-desc 

Thanks to gromenauer for making me aware of it in this GitHub comment.

Full documentation for sorting GitHub issues and pull requests can be found here.

EDIT (2024-08-27T05:20Z): There are also UI options that enable sorting by most "upvoted":

  • On desktop (through a web browser):

  • On mobile (through the app):

 

I'm looking for a cheap and portable tablet that I can use for writing. Microsoft Surface Pro tablets, at least around the gen 4 models, are rather cheap to buy used, and they seem decently well made. Naturally, were I to buy one, I would have to install Linux onto it.

I've been peripherally aware of the Linux Surface project for some time now. I looked at it recently, after having not for some time, and it seems that they have really made good progress compared to what I remember, and it's making me much more interested in trying to install Linux on a Surface Pro.

Having never owned a Surface Pro, I'm not sure which models are the most reliable and sturdy. I'm not looking for something that's the flashiest; I want something that works well. I want something pragmatic — something akin to the idea of an older era of Thinkpad (eg T460). I want a pen with low input delay and good accuracy, reliable and responsive touch controls, and a decent display. I was thinking the Surface Pro 4 might be a good choice, but it's hard to know as there aren't many videos out there of people installing Linux on them, so I'm wondering what your experience has been with Microsoft Surface Pro's and installing Linux on one.


Cross-posts:

 

In one of my posts, I noticed this removed comment:

I was curious what it was, so I checked the modlog, but it states that the last mod action in this community occurred a month ago:

What's up with this? Are mod actions being scrubbed from the modlog?

view more: next ›