Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Video freezing in Recording View #796

Open
FolkHistory opened this issue Apr 16, 2024 · 9 comments
Open

Video freezing in Recording View #796

FolkHistory opened this issue Apr 16, 2024 · 9 comments

Comments

@FolkHistory
Copy link

Video all looks fine in Passthrough View (and when capturing with Media Express) but in Recording View is freezing every few seconds then speeding up to correct itself.
I've tried all sorts of tests, upgrading, reinstalling etc. but am still stuck.

I'm getting these messages in the terminal log by the way

[v210 @ 0x7fb1ef705100] Application has requested 33 threads. Using a thread count greater than 16 is not recommended.
[Parsed_amovie_0 @ 0x7fb1f01061c0] Channel layout is not set in output stream 1, guessed channel layout is '7.1'

Could be relevant?
Any suggestions?

Thanks!
Nigel

@FolkHistory
Copy link
Author

Just adding some specs to this:

  • Mac Pro 2019 running Sonoma 14.4.1

  • Black Magic Desktop Video vers 12.9

  • BM Hardware - Ultrastudio 4K Extreme and Ultrastudio HD Mini (same issue with both)

  • I am capturing VHS PAL via Leitch DPS-575 SDI out
    File format Matroska FFV1 vers 3, 24 bit PCM
    QC Tools XML after recording

Video freezes in all of these views : Unfiltered, Visual, Audio + Video, Visual + Numerical (thought testing 4 was enough for now)

Also, if I run Vrecord with QC Tools XML set to concurrent, capture fails and I get the following errors as part of the log

[Parsed_amovie_0 @ 0x7fc094f04840] Channel layout is not set in output stream 1, guessed channel layout is '7.1'
    nan    :  0.000 fd=   0 aq=    0KB vq=    0KB sq=    0B f=0/0   
analyzing input file... -
                                                   0 of 100 %[matroska,webm @ 0x7fc094f04fc0] File ended prematurely
[matroska,webm @ 0x7fc094f04fc0] Seek to desired resync point failed. Seeking to earliest point available instead.

QCTools analysis is complete.q=    0KB vq=    0KB sq=    0B f=0/0   
Checking file conformance against FFV1 video policy...   0B f=0/0   
[Parsed_amovie_0 @ 0x7fc094f04840] EOF timestamp not reliable=0/0   
    Last message repeated 1 times

Thanks,
Nigel

@bravoalphatango
Copy link

Wanted to comment that the intermittent freezing during capture is still occurring with the most current version (v20241018) of vrecord. As Nigel mentioned it will freeze and then playback will speed up (as if fast forwarding) to catch up to where the tape is. This is happening on all of the computers I use (M1 MacBook Pro and both Intel MacMinis).

@privatezero
Copy link
Member

Hi @bravoalphatango - for you is this consistent across playback views the same as what was reported above?

@libbyhopfauf
Copy link
Member

libbyhopfauf commented Nov 13, 2024

@FolkHistory @bravoalphatango are you writing files to an external solid state or hard drive? or to the actual computer?

I have been experiencing this too for recording (we only use no filter for capture) and have noticed the freezing and then speeding up, but no issues with the files when they are reviewed post-capture. I did a bunch of testing today and this doesn't seem to happen during passthrough mode. (the playback gets really slow and laggy after about 5 minutes, but it's fine once it's reopened). For reference, we typically use numerical+visual mode for passthrough, but I tried all the various views and let a video play for a bit for each to see if there was any difference. I did some test captures where I wrote to the desktop and then wrote some to our 1TB Samsung solid-state drive (connected via USB-C). The files being written to the SSD consistently had this issue whereas it didn't seem to happen as often with writing to the Desktop (sometimes it didn't happen at all when writing to the Desktop). I'm going to try using fresh USB-C cables tomorrow for connecting the solid-state drives to the computers to see if maybe they have just reached the end of the line (seems weird that it would happen to both of them around the same time, but who is to say). Will update on how that goes! I started noticing it around the time of the upgrade as well.

Testing was done on a Mac Mini with M1 chip, running Sequoia 15.1. I noticed it on our other other M1 running Sonoma as well recently, but didn't have a chance to test it today.

@privatezero let me know if any other tests would be helpful! I haven't used any of our Intel Macs to capture in a long time since we only have two capture stations for analog, but can try that out too if it's helpful.

@FolkHistory
Copy link
Author

@libbyhopfauf writing to hard drive HDD. I've tried different drives but no difference. Capturing with Media Express doesn't display the issue so I assumed I could rule out any hard drive issues from that. Speed test results were fine too. As you say, no issues with the resulting files but something odd going on. Appreciate you looking into this.
Thanks,
Nigel

@bravoalphatango
Copy link

@libbyhopfauf the behavior I am seeing is similar to @FolkHistory: writing to a HDD hard drive, same results with different drives, speed tests are ok and the resulting files play back fine.

I am using an M1 Macbook Pro w/Sonoma 14.7 and two 2018 Intel Mac Minis w/Sonoma 14.7. All are using the v2024-20-18 of vrecord.

@privatezero I always use "Visual + Numerical" view so I will try different views when I am back onsite tomorrow.

@privatezero
Copy link
Member

Hi all - thanks for the testing, I'm still trying to figure out what the common variables are here since I can't reproduce any of the problems on my end (we have no issues with the view recording and no slow down in passthrough either). No idea if it is relevant, but I'm still on an intel machine.

@libbyhopfauf
Copy link
Member

libbyhopfauf commented Nov 14, 2024

@bravoalphatango @bravoalphatango thank you for confirming and sharing these details! I also tried different cables (including a brand new 20Gbps) and different solid-state drives, but was still experiencing the display freezing/speeding to catch up in the playback window during capture at fairly consistent intervals. Here are my specs below:

  • Mac Mini 2020, M1 chip
  • Sequoia 15.1
  • Samsung T7 Shield (2TB)
  • USB-C 3 to USB-C 3 cable (connecting SSD to Mac Mini)
  • examples of screen recordings and test files (titled with how they were captured, but let me know if you have any questions) - might take a bit for these to upload over our very slow wifi.

@privatezero There appears to be a direct correlation between the "fd" number increasing when the playback display freezes. One thing I was wondering about for a while, but was able to confirm during testing is that when the freezing occurs, in the Terminal readout readout the number for "fd = " increases as a sort of jump when the playback freezes (typically in increments of 4-6). In older versions of vrecord the Terminal used to note frames dropped, PTSD discrepancies, and buffer overruns when they occurred (as well as displaying a list of the timecodes for where the dropped frames or PTSD discrepancies occurred during capture as described by the sad cow). Does "fd" mean "frames dropped"? If so, was the feature to report any of these issues at the end with corresponding timecodes removed from this version of vrecord? I was assuming that "fd" doesn't mean "frames dropped" because there wasn't a warning and because the files play back normally in the same spot where this occurs (when reviewing files after capture). Does it possibly mean "frame delay" (similar to what our DPS-575 displays during capture on the main screen)? The screen capture below shows what I mean in comparison to the video not freezing if you write directly to the computer. Both are sped up and have the "fd" highlighted to show the difference for the duration of a longer recording (but the one of writing to the SSD plays back in normal time at the beginning to show the correlation between the freezing and the increase in "fd").

vrecord-freeze_write-to-Desktop.mp4
vrecord-freeze_write-to-SSD.mp4

@bravoalphatango
Copy link

bravoalphatango commented Nov 15, 2024

@libbyhopfauf and @privatezero I did some tests this morning on my laptop:

  • MacBook Pro 2021, M1 chip
  • Sonoma 14.7.1 (updated since last post)
  • LeCie Rugged Mini (4TB) HDD
  • USB-3 to USB-C cable (connecting HDD to MacBook)

I tested 4 views in vrecord recording locally to my computer and also recording to the HDD mentioned above. The viewed I tested were:

  • Unfiltered
  • Visual
  • Audio + Visual
  • Visual Numerical

I found that:

  • None of the views froze during passthrough mode
  • None of the views froze when recording locally to my MacBook (unfortunately I cannot do that for performing regular transfers)
  • All views froze when recording to HHD

Unfiltered
https://github.com/user-attachments/assets/1d328602-c0e4-470f-952e-f14e11c60ea8

Visual
https://github.com/user-attachments/assets/5ca14bbb-c3e7-4c5b-8d82-4f1b6815eaf8

Audio + Visual
https://github.com/user-attachments/assets/8ccf30a9-0877-4284-bcbd-bd1d1680e749

Visual Numerical
https://github.com/user-attachments/assets/9e05794a-98ed-400b-886c-1a13def7dc9f

Logs and MKVs for all files are here (please note I renamed them so the files are uniform and easier to differentiate so some of the filenames in the logs may differ from the current file names).

I will be performing transfers later today on some takes that were just baked on a different computer and different drive and will report back on how it goes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants