FOLLOW UP: I forgot to mention a few VITAL pieces of the test setup. I hope to clarify all that here, as well as discuss some awesome suggestions people here and on social media made. ------------------------------------------------ NOTES FROM COMMENTERS (I'll update the post as these change):- One suggestion is it might work on Mac's, as Apple’s implementation of Thunderbolt 3 has the ability to do full duplex via a single cable.I don't have the ability to run these cards on a Mac, but maybe I should try plugging both TB ports from the enclosure into the PC (as opposed to using the second one for daisy-chaining)? The Live Gamer Bolt only has one TB port, as I assume it's using the full speed of TB3 and doesn't want to drop speed by sharing the port. - Sonnet mentions that TB3 only supports 4 PCIe lanes. That would explain why the Datapath card couldn't get full speed, but the Live Gamer 4K is a PCIe x4 card, so it SHOULD have worked: ua-cam.com/video/YPyo_1xzIzg/v-deo.html - One very basic-but-plausible suggestion is that since both of my motherboards are 590 chipsets, maybe the problem is solved in Z790 or higher? I've tested other chipsets, but not in such a controlled environment as this one. THINGS I FORGOT TO MENTION IN THE VIDEO (or got wrong) - I tried MULTIPLE, name-brand, full-speed-rated Thunderbolt cables from 3ft to 6ft. This was a huge point that could have easily been the point of failure if I was always using the same cable. I feel really stupid not mentioning it...but I tried the cables that came with the enclosures, as well as two other brands. - In the ASUS motherboard, the Thunderbolt card would only work in the second PCIe x16 slot. It wasn't recognized at all in the first one. - I mentioned 4K60 lossless / 4:4:4 is about 30gbps, but I think it's lower. Most importantly, there have been Thunderbolt NVMe drives that transfer more data than 4K60 lossless...so regardless of the actual bandwidth, it should be less than max. - I know I said "gigabyte" instead of "gigbit" by accident a few times. I decided to leave it in, mostly because making edits, re-rendering, re-uploading and re-watching to verify takes a LOT more time than people think...but also, I like driving trolls crazy. Maybe that's immature, but I'd love to see how YOU'D react, seeing a neverending stream of hate sent your way. This is my way of vetting "ackshuwally" trolls, as well as people who can't take a joke. If you don't like it, comment about it here. I promise I won't just mute you and move on...I'll totally read it. Won't that make you feel nice?
LTT is setting up their testing labs to prove just these things. I think your request at the end for your friends, including Linus, to help you was spot on.
Seems like a latency issue, it must grab and issue a transfer request over thunderbolt, but added protocol latency must make it miss a next frame request periodically. So proccess of operation is: grab a frame from frame buffer and then send frame in response to request, and next frame request takes to long to request(due to latency, as next request can only happen when last frame was fully transmitted) and because frame was missed it internally duplicates it(but it isn't marked as duplicated, because it was latency not resource constraint on bandwidth). Full bandwidth can be realised on full on continuos data streaming, where latency of requesting(or pushing) next frame doesnt exsist. Wheres video frames have time gaps in between. Hence it works internally on motherboard, where there is no added protocol overhead. Being a packetised protocol, it makes sense for such issue to occur. If you guys wondering, if it affects displays connected to thurderbolt, it doesn't because it uses a different protocol to drive them generally. Instead a Displayport Alt mode is used as a dedicated video transfer protocol, which avoids dropping frames. It comes at expensive of some bandwidth on thunderbolt. As it reserves some physical wiring. So it doesn't have to compete with packets of thunderbolt. (Though I am not 100% sure on this)
@@RetroRGB Perhaps easiest way to test it is using a fast ethernet card(server grade stuff for 10Gb), both to test bandwidth, and it both can be used to test latency. Though youl need 2 computers with same cards. An SPF compatible card should work. Though latency can be likely tested on lower end cards too, dont need to go full server tier. Latency is fairly easy to test, issue packet and get reply and time it as precisly as possible. There will be OS jitter, due to packet processing, but capturing enough on Thunderbolt dock and both on motherboard PCI-e should provide latency numbers, which are fairly accurate. If latency can impact video capture, it should be fairly measurable. In other theory, a dedicated test equipment just for thunderbolt testing with special software can be used, but thats basically unobtanium. Whereis using ethernet cards and a just a controlled network and very short round trip reply.
Everyone is talking about the intention of the video here, meanwhile I am side eyeing that 'prototype 4Kscaler'. Let's hope it's a sign of a certain product maybe getting a larger bit of news about its release later this year.
The thunderbolt connection to the motherboard is PCIe 4x, isn't it? Intel specified that it should be gen 3 lanes, which means 8Gb/s per lane, or 32Gb/s total. Thunderbolt publicity material indicates the other is 8Gb/s being reserved for DisplayPort video (even if not being used). Thus, 40Gb/s was never really effectively the advertised speed. That said, it seems to me that you should only need about 12Gb/s for 2160p60 8 bit RGB capture, and other people certainly benchmark TB3 SSDs going faster than that.
I'm not sure if I missed it in testing, but it'd be great to connect a 4k60 display to the Thunderbolt ports on the enclosure and measure if there are more dropped frames. Using a DisplayPort to USB-C cable should suffice. This would confirm the DisplayPort bandwidth being reserved over the TB4 bus.
Sonnet has a video explaining TB3 vs TB4, and why they are using the former. ua-cam.com/video/YPyo_1xzIzg/v-deo.html. Not sure if it's related to what you're writing.
Looks like this thunderbolt capture card relies on the GPU in your system for actual capture duties. So, potentially a bandwidth limitation over the PCIe bus. Could be using Chipset instead of CPU lanes for the thunderbolt chipset. Might also be a weird format being streamed over the bus as well. We have limited insight into what format it's sending the raw data.
Maybe this isn't a bandwidth limitation, per se, but an issue of latency? I'm not sure exactly how video capture works, but in my mind it's basically a reverse of video rendering, so you take an image on screen, put it into a memory buffer, and then when you have a full image you send it over either PCIE or thunderbolt to be encoded and stored. Maybe the image size of a fully uncompressed 4k video frame is such that in some cases at 60fps, you need to empty the buffer before thunderbolt is ready to have the frame sent to the computer (maybe the prior frame is still being processed because it got there later than it otherwise would have with PCIE interfacing?). So if each frame is taking 1-2ms longer to get into the PC because it has to go through a thunderbolt controller in addition to the PCIE interface, eventually those milliseconds add up and you have to flush a buffer before the frame can be sent. I know a decent amount of testing has been done going the other way, looking at performance of a GPU in a thunderbolt enclosure versus a PCIE slot, and there's always a significant loss. I believe a lot of those losses are attributed to the limited bandwidth, but I'm sure the fact that the GPU has to go through a thunderbolt controller to get to the PCIE bus doesn't help either.
I was thinking something along these lines as well. Thunderbolt 3 can obviously *output* 4K60 4:4:4. In fact, I'm using a Thunderbolt dock with a 4K TV connected to it right now.
If you want a less expensive software than can do forward and back frame by framing Keyframe MP and Keyframe Pro are great for that. I work in animation and that's what we use. Works with a lot of codecs.
I know that you might have already checked this, but did you try the thunderbolt card in the top x16 PCIe slot? The clip you showed of which slot the card plugged into might be running off the chipset, which is sharing bandwidth with ethernet, USB, SATA, WiFi and is only a x4 link from the chipset to the CPU, which by itself would be fine for thunderbolt, but might not be enough with everything else going on.
@@RetroRGB that is odd, I wonder if the system thinks the card is a GPU and is falling over itself trying to treat it as one, but I'm just hypothesising. A good person to talk to would be Wendell at level1techs, he's a wizard at this kind of stuff.
This is a really great experiment! So far, I never had any use case that reached the thunderbolt limits. Even the most demands uses, like GPU enclosure, I see 20% less performance on benchmarks with my RTX 3070, but I never noticed any difference when I'm actually playing a game. My conclusion from this video is: if I want to have a dedicated high-end work solution, I'll only use PCIe and even dedicated lanes for those crazy scenarios. For any non-crazy scenarios, thunderbolt and USB-4 are the way to go.
I have doubts LTT would/could add a video on something like this to their production schedule, this does echo something from their recent gen 5 SSD video. While the the interconnect could theoretically handle the full bandwidth I believe it was 14 GBps (gigabytes), the dive only got up to 12 GBps because of limitations with the controller, NAND flash, and the like. So while thunderbolt could theoretically do 40 Gbps (gigabits), I doubt much of any devices can actually saturate that once computational, and other (that I don't know) overhead is taken into consideration.
Great video, i hope either epos or ltt can shed some light on this by doing more testing. also in the description the conclusion timestamp doesn't have a colon and thus the chapter doesn't appear
I took a look at the specs for the motherboards, and it looks like in your initial setup, the thunderbolt adapter was running off a PCIE 3.0 slot (x4 max) that's connected to the chipset. The onboard thunderbolt also goes through the chipset on the MSI board. That said, your capture card didn't have any issues in the same slot in your first test, so it seems that doesn't matter, though it's clear that PCIE 3.0 x4 (or maybe x1 - not sure how your capture card connects) has enough bandwidth, so PCIE 4.0 is not a hard requirement for the card itself. I'm taking a long shot in the dark, but it almost makes me wonder if it's something dumb and hard to troubleshoot like latency (cable vs. direct PCIE connection). I'd think it'd be almost 0 for the cables, so instead maybe the thunderbolt controllers can't keep up even if the cables and other parts can. I'm not sure if the software would ever know that it's getting a duplicate frame because the encoder isn't what's having trouble. Anyway, it's an interesting test because from some brief research it seems you should only need 12 gigabits per second for the quality you were trying to achieve. That's substantially less than the advertised top speed of 40. I wonder if there's an asterisk in the marketing that says "up to" just like you get from internet service providers.
Great point about the PCI slot, but yeah, that’s why I was trying to keep the tests as close as possible and use both slots. I DID try the thunderbolt card in the top slot too and it didn’t work at all. I forgot to put that in the video… …and I also forgot to put my cable testing in there too :/ I was using multiple 3-ft cables that are name brand and rated at full speed. I feel dumb for forgetting to mention that really important point.
@@RetroRGB Yeah fair enough. Anecdotally I think modern boards expecting an actual GPU in the top slot and nothing else may be a not too uncommon occurrence. It's not the first time I've heard of it, at least. I figured you tried multiple cables since that's usually the easiest cheapest thing to do when you start troubleshooting. That's why I wonder if it's the actual thunderbolt controller chips themselves that are to blame, which I guess would basically prove the point of the video.
@@RetroRGB That'd be great. It seems like you've got some great suggestions from other people for who might be able to help look into it, in addition to your own contacts so hopefully we'll see a definitive answer in the coming weeks or months.
I use media player classic to frame advance all the time but I've never known that there was a keyboard shortcut for it, I usually just click the frame advance button with my mouse to go 1 frame at a time and never had issues with that
This might be a really stupid question...but where's the "frame advance" button? The "Step" button is even less reliable for me than ctrl-right. Maybe we're using different software - I'm using MPCHC.
@@RetroRGB sorry it was the step button I was referring to and I've never seen issues with it like what you were talking about when using ctrl-right. I have the latest build of MPCHC which I thought was not getting updates anymore until it did this past January. the only time I've seen the step button not work as a frame advance is whenever I use lagarith for a recording and it skips every duplicate frame. other than that I've not had issues using the step button
You should test it with both the capture card and M.2 drive are using PCIe lanes from the CPU and not the chipset. You would need to plug the thunderbolt card into the first 16x slot the GPU was in and check which M.2 slot uses CPU lanes on your motherboard. Edit: Also, removing the GPU will have zero effect on lanes used by a card in the lower slots. The GPU uses CPU lanes and the lower slots use chipset lanes. It may free up lanes for the NVMe drive if it's plugged into the slot that uses CPU lanes. Also, did you check if the NVMe slot is set to use 2 or 4 lanes? The fact that the card directly plugged in worked fine means your conclusion may be correct.
It may be an issue with first generation thunderbolt 4 devices along with first generation TB4 driver issues. I am saying this becuase for a while, I was looking for a new external ssd drive that uses either usb4 or thunderbolt 4. The first thing I noticed was almost none of the drives maxed out the 40gbs bandwidth on TB4. I also noticed most of these drives also support usb4. And sometimes certain ssd external drives had better performance on usb4 than TB4. The bitcube indiegogo drive that technically isn't even released yet was reported to use an updated chip design that gets better TB4 performance. (Although still not maxing out the TB4 bandwidth) The point I'm trying to make is that these first generation chips maybe need to be improved on to get the full speed. Maybe it's possible to get this full speed by the 3rd revision of the device translation chip. If that is the case then that kinda sucks becuase if you are buying devices now to get a certain amount of bandwidth, then you may have to spend more money later to get an updated TB4 device that has a better chip that can take the full bandwidth. What would really be bad is if they need to create a TB4.1 standard just to fix the 40gbs issue. That would suck becuase you expected the bandwidth on the original TB4 and not on an update.
I swear that I was just thinking all night last night which way is best way to hook up a live gamer pro or elgato 4k mk2 to my rog zephyrus laptop or if my 5700g dedicated graphics would be good enough to act as my capture/streaming pc?
If you don’t need uncompressed color / lossless video, Thunderbolt will work perfect. So, streaming is even possible at 4K60. Just not true archival work.
You didn't mention it, but I presume that Bob being Bob, you tried different thunderbolt cables? Even if nobody cares, it's still something that should work but doesn't.
I spent a lot on multiple cables of different sizes that were all name brand and rated at 40gbps. But I totally should have mentioned that in the video. Sorry!
Not that surprised that they would over-advertise in marketing. The thing is that 4k 60 uncompressed is not needed for most people right now… Especially online. I guess just to archive your own footage at home maybe?
Virtualdub and avi file formats are not gonna be good tools for testing this kind of thing, if I was going to test this way with video footage I would use ffmpeg, mkv and x264 at the least just because they are known quantities that will not produce random frame drops like Virtualdub/avi has done since the 90s For what it's worth I use my 4k60 display over thunderbolt 4 (rgb not subsampled) every day without issue. I would be surprised if the frame drops were real and not artifacts of the software and hardware used
All of that is false and I proved it all in the video. First, 4K60 WILL work fine over TB without framedrops…at 4:2:2 or lower. The issue is 4K60, 4:4:4. …and I tried every encoding format out there. The problem isn’t UTVideo. And if it WAS a problem, it wouldn’t have tested perfect when used internally.
@@RetroRGB I guess you didn't want feedback on testing like you said in the video, Its so weird how hostile you are to this stuff... But again, virtual dub + avi, and again I run 4k60 without sub sampling daily. And I've experienced a lot of situations myself where virtual dub and or avi have caused problems with video encoding, including frame drops. You can continue on this path if you want, I'm trying to help? Maybe just *try* with ffmpeg and mkv and see where that gets you, instead of jumping on some random commentor. Or don't and ignore me that's fine too
I’ll admit, I didn’t take the time to make sure my reply was as polite as it could have been…but I was right: The encoder had NOTHING to do with the framesdrops, which I proved twice in the video.
FOLLOW UP: I forgot to mention a few VITAL pieces of the test setup. I hope to clarify all that here, as well as discuss some awesome suggestions people here and on social media made.
------------------------------------------------
NOTES FROM COMMENTERS (I'll update the post as these change):- One suggestion is it might work on Mac's, as Apple’s implementation of Thunderbolt 3 has the ability to do full duplex via a single cable.I don't have the ability to run these cards on a Mac, but maybe I should try plugging both TB ports from the enclosure into the PC (as opposed to using the second one for daisy-chaining)? The Live Gamer Bolt only has one TB port, as I assume it's using the full speed of TB3 and doesn't want to drop speed by sharing the port.
- Sonnet mentions that TB3 only supports 4 PCIe lanes. That would explain why the Datapath card couldn't get full speed, but the Live Gamer 4K is a PCIe x4 card, so it SHOULD have worked: ua-cam.com/video/YPyo_1xzIzg/v-deo.html
- One very basic-but-plausible suggestion is that since both of my motherboards are 590 chipsets, maybe the problem is solved in Z790 or higher? I've tested other chipsets, but not in such a controlled environment as this one.
THINGS I FORGOT TO MENTION IN THE VIDEO (or got wrong)
- I tried MULTIPLE, name-brand, full-speed-rated Thunderbolt cables from 3ft to 6ft. This was a huge point that could have easily been the point of failure if I was always using the same cable. I feel really stupid not mentioning it...but I tried the cables that came with the enclosures, as well as two other brands.
- In the ASUS motherboard, the Thunderbolt card would only work in the second PCIe x16 slot. It wasn't recognized at all in the first one.
- I mentioned 4K60 lossless / 4:4:4 is about 30gbps, but I think it's lower. Most importantly, there have been Thunderbolt NVMe drives that transfer more data than 4K60 lossless...so regardless of the actual bandwidth, it should be less than max.
- I know I said "gigabyte" instead of "gigbit" by accident a few times. I decided to leave it in, mostly because making edits, re-rendering, re-uploading and re-watching to verify takes a LOT more time than people think...but also, I like driving trolls crazy. Maybe that's immature, but I'd love to see how YOU'D react, seeing a neverending stream of hate sent your way. This is my way of vetting "ackshuwally" trolls, as well as people who can't take a joke. If you don't like it, comment about it here. I promise I won't just mute you and move on...I'll totally read it. Won't that make you feel nice?
LTT is setting up their testing labs to prove just these things. I think your request at the end for your friends, including Linus, to help you was spot on.
Seems like a latency issue, it must grab and issue a transfer request over thunderbolt, but added protocol latency must make it miss a next frame request periodically. So proccess of operation is: grab a frame from frame buffer and then send frame in response to request, and next frame request takes to long to request(due to latency, as next request can only happen when last frame was fully transmitted) and because frame was missed it internally duplicates it(but it isn't marked as duplicated, because it was latency not resource constraint on bandwidth).
Full bandwidth can be realised on full on continuos data streaming, where latency of requesting(or pushing) next frame doesnt exsist. Wheres video frames have time gaps in between.
Hence it works internally on motherboard, where there is no added protocol overhead.
Being a packetised protocol, it makes sense for such issue to occur.
If you guys wondering, if it affects displays connected to thurderbolt, it doesn't because it uses a different protocol to drive them generally. Instead a Displayport Alt mode is used as a dedicated video transfer protocol, which avoids dropping frames. It comes at expensive of some bandwidth on thunderbolt. As it reserves some physical wiring. So it doesn't have to compete with packets of thunderbolt. (Though I am not 100% sure on this)
That's a good idea! I'd personally have no way to test it, but maybe someone else with the right equipment could?
@@RetroRGB Perhaps easiest way to test it is using a fast ethernet card(server grade stuff for 10Gb), both to test bandwidth, and it both can be used to test latency. Though youl need 2 computers with same cards. An SPF compatible card should work. Though latency can be likely tested on lower end cards too, dont need to go full server tier.
Latency is fairly easy to test, issue packet and get reply and time it as precisly as possible. There will be OS jitter, due to packet processing, but capturing enough on Thunderbolt dock and both on motherboard PCI-e should provide latency numbers, which are fairly accurate. If latency can impact video capture, it should be fairly measurable.
In other theory, a dedicated test equipment just for thunderbolt testing with special software can be used, but thats basically unobtanium. Whereis using ethernet cards and a just a controlled network and very short round trip reply.
Everyone is talking about the intention of the video here, meanwhile I am side eyeing that 'prototype 4Kscaler'. Let's hope it's a sign of a certain product maybe getting a larger bit of news about its release later this year.
The thunderbolt connection to the motherboard is PCIe 4x, isn't it? Intel specified that it should be gen 3 lanes, which means 8Gb/s per lane, or 32Gb/s total. Thunderbolt publicity material indicates the other is 8Gb/s being reserved for DisplayPort video (even if not being used). Thus, 40Gb/s was never really effectively the advertised speed. That said, it seems to me that you should only need about 12Gb/s for 2160p60 8 bit RGB capture, and other people certainly benchmark TB3 SSDs going faster than that.
I'm not sure if I missed it in testing, but it'd be great to connect a 4k60 display to the Thunderbolt ports on the enclosure and measure if there are more dropped frames. Using a DisplayPort to USB-C cable should suffice. This would confirm the DisplayPort bandwidth being reserved over the TB4 bus.
Sonnet has a video explaining TB3 vs TB4, and why they are using the former. ua-cam.com/video/YPyo_1xzIzg/v-deo.html. Not sure if it's related to what you're writing.
I can't believe I missed that video! Thanks for sharing! I just tweeted them to ask.
@@RetroRGB Glad it helped.
Looks like this thunderbolt capture card relies on the GPU in your system for actual capture duties. So, potentially a bandwidth limitation over the PCIe bus. Could be using Chipset instead of CPU lanes for the thunderbolt chipset. Might also be a weird format being streamed over the bus as well. We have limited insight into what format it's sending the raw data.
Maybe this isn't a bandwidth limitation, per se, but an issue of latency? I'm not sure exactly how video capture works, but in my mind it's basically a reverse of video rendering, so you take an image on screen, put it into a memory buffer, and then when you have a full image you send it over either PCIE or thunderbolt to be encoded and stored. Maybe the image size of a fully uncompressed 4k video frame is such that in some cases at 60fps, you need to empty the buffer before thunderbolt is ready to have the frame sent to the computer (maybe the prior frame is still being processed because it got there later than it otherwise would have with PCIE interfacing?). So if each frame is taking 1-2ms longer to get into the PC because it has to go through a thunderbolt controller in addition to the PCIE interface, eventually those milliseconds add up and you have to flush a buffer before the frame can be sent.
I know a decent amount of testing has been done going the other way, looking at performance of a GPU in a thunderbolt enclosure versus a PCIE slot, and there's always a significant loss. I believe a lot of those losses are attributed to the limited bandwidth, but I'm sure the fact that the GPU has to go through a thunderbolt controller to get to the PCIE bus doesn't help either.
I was thinking something along these lines as well. Thunderbolt 3 can obviously *output* 4K60 4:4:4. In fact, I'm using a Thunderbolt dock with a 4K TV connected to it right now.
If you want a less expensive software than can do forward and back frame by framing Keyframe MP and Keyframe Pro are great for that. I work in animation and that's what we use. Works with a lot of codecs.
I know that you might have already checked this, but did you try the thunderbolt card in the top x16 PCIe slot? The clip you showed of which slot the card plugged into might be running off the chipset, which is sharing bandwidth with ethernet, USB, SATA, WiFi and is only a x4 link from the chipset to the CPU, which by itself would be fine for thunderbolt, but might not be enough with everything else going on.
Yes. And I should have mentioned that :/ It actually wouldn’t work in the top slot. Not sure why, but I did try.
@@RetroRGB that is odd, I wonder if the system thinks the card is a GPU and is falling over itself trying to treat it as one, but I'm just hypothesising.
A good person to talk to would be Wendell at level1techs, he's a wizard at this kind of stuff.
Well, either way, the second motherboard with integrated TB did the same thing, so it’s not that. And yeah, I’d love to talk to them about it!
Fucken love this guy!
This is a really great experiment!
So far, I never had any use case that reached the thunderbolt limits.
Even the most demands uses, like GPU enclosure, I see 20% less performance on benchmarks with my RTX 3070, but I never noticed any difference when I'm actually playing a game.
My conclusion from this video is: if I want to have a dedicated high-end work solution, I'll only use PCIe and even dedicated lanes for those crazy scenarios. For any non-crazy scenarios, thunderbolt and USB-4 are the way to go.
Based on my testing up to this point, I completely agree with your conclusion. And thanks for watching!
I have doubts LTT would/could add a video on something like this to their production schedule, this does echo something from their recent gen 5 SSD video. While the the interconnect could theoretically handle the full bandwidth I believe it was 14 GBps (gigabytes), the dive only got up to 12 GBps because of limitations with the controller, NAND flash, and the like.
So while thunderbolt could theoretically do 40 Gbps (gigabits), I doubt much of any devices can actually saturate that once computational, and other (that I don't know) overhead is taken into consideration.
He says LTT helped with testing this. It would be great to see LTT Labs investigate this.
@@alextirrellRI What's the timestamp for when he says that?
Great video, i hope either epos or ltt can shed some light on this by doing more testing. also in the description the conclusion timestamp doesn't have a colon and thus the chapter doesn't appear
Oh crap, thanks for the head's up!!! Timestamp fixed!
I took a look at the specs for the motherboards, and it looks like in your initial setup, the thunderbolt adapter was running off a PCIE 3.0 slot (x4 max) that's connected to the chipset. The onboard thunderbolt also goes through the chipset on the MSI board. That said, your capture card didn't have any issues in the same slot in your first test, so it seems that doesn't matter, though it's clear that PCIE 3.0 x4 (or maybe x1 - not sure how your capture card connects) has enough bandwidth, so PCIE 4.0 is not a hard requirement for the card itself.
I'm taking a long shot in the dark, but it almost makes me wonder if it's something dumb and hard to troubleshoot like latency (cable vs. direct PCIE connection). I'd think it'd be almost 0 for the cables, so instead maybe the thunderbolt controllers can't keep up even if the cables and other parts can. I'm not sure if the software would ever know that it's getting a duplicate frame because the encoder isn't what's having trouble.
Anyway, it's an interesting test because from some brief research it seems you should only need 12 gigabits per second for the quality you were trying to achieve. That's substantially less than the advertised top speed of 40. I wonder if there's an asterisk in the marketing that says "up to" just like you get from internet service providers.
Great point about the PCI slot, but yeah, that’s why I was trying to keep the tests as close as possible and use both slots. I DID try the thunderbolt card in the top slot too and it didn’t work at all. I forgot to put that in the video…
…and I also forgot to put my cable testing in there too :/ I was using multiple 3-ft cables that are name brand and rated at full speed. I feel dumb for forgetting to mention that really important point.
@@RetroRGB Yeah fair enough. Anecdotally I think modern boards expecting an actual GPU in the top slot and nothing else may be a not too uncommon occurrence. It's not the first time I've heard of it, at least. I figured you tried multiple cables since that's usually the easiest cheapest thing to do when you start troubleshooting. That's why I wonder if it's the actual thunderbolt controller chips themselves that are to blame, which I guess would basically prove the point of the video.
I’m curious about that too! I’ll keep testing, but hopefully a channel with an actual budget for hardware could help too :)
@@RetroRGB That'd be great. It seems like you've got some great suggestions from other people for who might be able to help look into it, in addition to your own contacts so hopefully we'll see a definitive answer in the coming weeks or months.
I use media player classic to frame advance all the time but I've never known that there was a keyboard shortcut for it, I usually just click the frame advance button with my mouse to go 1 frame at a time and never had issues with that
This might be a really stupid question...but where's the "frame advance" button? The "Step" button is even less reliable for me than ctrl-right. Maybe we're using different software - I'm using MPCHC.
@@RetroRGB sorry it was the step button I was referring to and I've never seen issues with it like what you were talking about when using ctrl-right.
I have the latest build of MPCHC which I thought was not getting updates anymore until it did this past January.
the only time I've seen the step button not work as a frame advance is whenever I use lagarith for a recording and it skips every duplicate frame. other than that I've not had issues using the step button
I use the "portable" version. Maybe that's my problem? I appreciate the response either way.
Prototype 4K scaler... 💀
You should test it with both the capture card and M.2 drive are using PCIe lanes from the CPU and not the chipset. You would need to plug the thunderbolt card into the first 16x slot the GPU was in and check which M.2 slot uses CPU lanes on your motherboard.
Edit: Also, removing the GPU will have zero effect on lanes used by a card in the lower slots. The GPU uses CPU lanes and the lower slots use chipset lanes. It may free up lanes for the NVMe drive if it's plugged into the slot that uses CPU lanes.
Also, did you check if the NVMe slot is set to use 2 or 4 lanes?
The fact that the card directly plugged in worked fine means your conclusion may be correct.
It may be an issue with first generation thunderbolt 4 devices along with first generation TB4 driver issues. I am saying this becuase for a while, I was looking for a new external ssd drive that uses either usb4 or thunderbolt 4. The first thing I noticed was almost none of the drives maxed out the 40gbs bandwidth on TB4. I also noticed most of these drives also support usb4. And sometimes certain ssd external drives had better performance on usb4 than TB4. The bitcube indiegogo drive that technically isn't even released yet was reported to use an updated chip design that gets better TB4 performance. (Although still not maxing out the TB4 bandwidth) The point I'm trying to make is that these first generation chips maybe need to be improved on to get the full speed. Maybe it's possible to get this full speed by the 3rd revision of the device translation chip. If that is the case then that kinda sucks becuase if you are buying devices now to get a certain amount of bandwidth, then you may have to spend more money later to get an updated TB4 device that has a better chip that can take the full bandwidth.
What would really be bad is if they need to create a TB4.1 standard just to fix the 40gbs issue. That would suck becuase you expected the bandwidth on the original TB4 and not on an update.
I tried multiple drivers across many setups.
I swear that I was just thinking all night last night which way is best way to hook up a live gamer pro or elgato 4k mk2 to my rog zephyrus laptop or if my 5700g dedicated graphics would be good enough to act as my capture/streaming pc?
If you don’t need uncompressed color / lossless video, Thunderbolt will work perfect. So, streaming is even possible at 4K60. Just not true archival work.
@RetroRGB Thanks Bob! I appreciate the reply.
You didn't mention it, but I presume that Bob being Bob, you tried different thunderbolt cables?
Even if nobody cares, it's still something that should work but doesn't.
I spent a lot on multiple cables of different sizes that were all name brand and rated at 40gbps. But I totally should have mentioned that in the video. Sorry!
@@RetroRGB No need to be sorry :)
Is it possible for a mere mortal like me to build a YuzukiLOHCC PRO card, or is the MS2130 chip unobtainable?
Not that surprised that they would over-advertise in marketing. The thing is that 4k 60 uncompressed is not needed for most people right now… Especially online. I guess just to archive your own footage at home maybe?
Agreed. 99.9% of Thunderbolt users won’t run into any problems. Still, I’m a nerd and I wanted to text :)
I’d expect no less from you. Honestly I am very sensitive to lag or dropped frames too, so I understand completely
Virtualdub and avi file formats are not gonna be good tools for testing this kind of thing, if I was going to test this way with video footage I would use ffmpeg, mkv and x264 at the least just because they are known quantities that will not produce random frame drops like Virtualdub/avi has done since the 90s
For what it's worth I use my 4k60 display over thunderbolt 4 (rgb not subsampled) every day without issue. I would be surprised if the frame drops were real and not artifacts of the software and hardware used
All of that is false and I proved it all in the video. First, 4K60 WILL work fine over TB without framedrops…at 4:2:2 or lower. The issue is 4K60, 4:4:4.
…and I tried every encoding format out there. The problem isn’t UTVideo. And if it WAS a problem, it wouldn’t have tested perfect when used internally.
@@RetroRGB I guess you didn't want feedback on testing like you said in the video, Its so weird how hostile you are to this stuff...
But again, virtual dub + avi, and again I run 4k60 without sub sampling daily. And I've experienced a lot of situations myself where virtual dub and or avi have caused problems with video encoding, including frame drops.
You can continue on this path if you want, I'm trying to help? Maybe just *try* with ffmpeg and mkv and see where that gets you, instead of jumping on some random commentor. Or don't and ignore me that's fine too
I’ll admit, I didn’t take the time to make sure my reply was as polite as it could have been…but I was right: The encoder had NOTHING to do with the framesdrops, which I proved twice in the video.