GV-USB2 only captures progressive?

[jagabo]

By the way, you can convert your 59.94 fps video to 29.97 fps by opening it in VirtualDub and selecting Video -> Frame Rate -> Process Every Other Frame (decimate by 2). Also select Video -> Direct Stream Copy. Then File -> Save Video. The result will be a normal 29.97 fps, bottom field first, interlaced video.

[Alwyn]

▲ Liked.

[lordsmurf]

It’s very confusing to say the least.

Use VirtualDub, and that's what most folks use (and have used since the 2000s).

[Alwyn]

Use VirtualDub, and that's what most folks use (and have used since the 2000s).

I wouldn't be surprised if @Lovethisnation has the same problem.

[oln]

I don't know if it's related but with with my avermedia U3 card, the 25 fps options don't show up in amarecTV after booting the machine until I open virtualdub and set the device to PAL in the device settings there first for whatever reason. I have not had that happen with the GV-USB2 that I use on the same machine though.

[lordsmurf]

I don't know if it's related but with with my avermedia U3 card, the 25 fps options don't show up in amarecTV after booting the machine until I open virtualdub and set the device to PAL in the device settings there first for whatever reason. I have not had that happen with the GV-USB2 that I use on the same machine though.

Try Crossbar Thing.

[lovethisnation]

@lovethisnation, I say again, delete AmarecTV.ini and restart it.

If that doesn't work, In Device Manager, "uninstall" the GV-USB 2, reboot your machine, then re-install the GV-USB2.

1. I deleted AmarecTV.ini and restarted it, it didn't work
2. I uninstalled GV-USB2 and restarted then re-installed GV-USB2 and that didn't work either.
3. I deleted AmarecTV and re-installed and that didn't do it either.

The driver version I get from the website download 1.1.0.193.8 does not have an option to select the 24.97 FPS using AmerecTV. Perhaps other prior versions did, but not this one. However, it does let me change the textbox but I have to manually type in the textbox and click ok. I verified the capture at 24.97 after i did this.

[lovethisnation]

By the way, you can convert your 59.94 fps video to 29.97 fps by opening it in VirtualDub and selecting Video -> Frame Rate -> Process Every Other Frame (decimate by 2). Also select Video -> Direct Stream Copy. Then File -> Save Video. The result will be a normal 29.97 fps, bottom field first, interlaced video.

Thank you! By the way, how did you render the avc.mkv file sample file you did. The quality is amazing and the video is smooth. I tried to replicate my own version in VirtualDub but I can't play the file back in windows media. What codec/settings did you select to compress and save the video?

[jagabo]

how did you render the avc.mkv file sample file you did. The quality is amazing and the video is smooth.

Nothing special. I rendered the script in the earlier post with x264 via ffmpeg using one of my drag/drop batch files:

Start /b /low "ffmpeg" "ffmpeg.exe" -y -benchmark -init_hw_device qsv=hw -filter_hw_device hw -v verbose ^
    -i %1 ^
    -c:v libx264 -preset slow -crf 18 -g 50 -sar 10:11 ^
    -colorspace smpte170m -color_trc smpte170m -color_primaries smpte170m -color_range tv ^
    -acodec aac ^
    "%~dpn1.avc.mkv"

After fixing the source frame rate problem QTGMC is responsible for the smooth motion and clean edges.

[lovethisnation]

how did you render the avc.mkv file sample file you did. The quality is amazing and the video is smooth.

Nothing special. I rendered the script in the earlier post with x264 via ffmpeg using one of my drag/drop batch files:

Start /b /low "ffmpeg" "ffmpeg.exe" -y -benchmark -init_hw_device qsv=hw -filter_hw_device hw -v verbose ^
    -i %1 ^
    -c:v libx264 -preset slow -crf 18 -g 50 -sar 10:11 ^
    -colorspace smpte170m -color_trc smpte170m -color_primaries smpte170m -color_range tv ^
    -acodec aac ^
    "%~dpn1.avc.mkv"

After fixing the source frame rate problem QTGMC is responsible for the smooth motion and clean edges.

wait what, I'm sorry i'm lost. The way i rendered files was using vdub and selecting one of the compression methods (.264) and save video but your code is foreign to me. What do you mean by drag and drop batch files?

Update: Please see new post where i included new screenshots https://forum.videohelp.com/threads/410128-Error-when-trying-to-playback-h264-mp4-video-Help

I'm sorry i'm not familiar with ffmpeg.exe batch coding. i use Vdub2 for everything. Did you encode the file using 420 or 422 pixel format? I don't get any errors in WMP playing your file but when i convert mine I do. I essentially want to replicate what you did but i don't understand how to. Thank you.

[lovethisnation]

I'm opening another post to keep it in the scope of rendering/compression settings since I now have errors when trying to playback an .mp4 file in Windows Media. I think the capturing question I posted initially had been answered. I could not get AmerecTV to display the 29.94 FPS option in the settings with the latest driver, however, the GV-USB2 device does capture at that frame rate and it definitely captures interlace analog video.

Here's the new thread. See you guys there. https://forum.videohelp.com/threads/410128-Error-when-trying-to-playback-h264-mp4-video-Help

[lovethisnation]

how did you render the avc.mkv file sample file you did. The quality is amazing and the video is smooth.

Nothing special. I rendered the script in the earlier post with x264 via ffmpeg using one of my drag/drop batch files:

Start /b /low "ffmpeg" "ffmpeg.exe" -y -benchmark -init_hw_device qsv=hw -filter_hw_device hw -v verbose ^
    -i %1 ^
    -c:v libx264 -preset slow -crf 18 -g 50 -sar 10:11 ^
    -colorspace smpte170m -color_trc smpte170m -color_primaries smpte170m -color_range tv ^
    -acodec aac ^
    "%~dpn1.avc.mkv"

After fixing the source frame rate problem QTGMC is responsible for the smooth motion and clean edges.

After much efforts, i still think your method rendered better results than what I have been doing in VirtualDub2 to convert the video. Not sure if it's all psychological now. I see that your code mentions colorspace " -colorspace smpte170m -color_trc smpte170m -color_primaries smpte170m -color_range tv ^" and that is interesting. I would appreciate if you can send me some guidance on how to replicate what you did because i have no idea how you did it. Thank you.

[jagabo]

ffmpeg.exe is a command line encoding program with dozens of encoders and muxers built in. What I quoted is a batch file for Windows that uses ffmpeg to encode the video to h.264 and audio to aac, in a MKV container. Copy the text into a text editor, like Notepad, and save it with .BAT as the extension. You can then drag/drop an AviSynth script onto the batch file and it will be encoded to an mkv file. If ffmpeg.exe isn't in your search path you will have to specify exactly where it is in the batch file. Instead of just "ffmpeg.exe" on the first line give the full path, something like: "C:\Program Files\ffmpeg64\bin\ffmpeg.exe". You'll need to download ffmpeg if you don't have it already.

If you put the batch file in Windows' SendTo folder you can right click on a AviSynth script (or any A/V file) and select Send To -> Name.BAT, where Name is whatever you named the batch file. A CLI window will open up and you'll see it start encoding. You'll also see a new file appear in the same folder as the AVS script, with .avs.mkv added to the base name. This is a very handy way of encoding AVS scripts without starting up an editor, selecting the AVS script, selecting the encoders and thier settings, and finally encoding.

[Sharc]

After much efforts, i still think your method rendered better results than what I have been doing in VirtualDub2 to convert the video. Not sure if it's all psychological now.

There should be no difference IMO if you selected the same encoder settings in VirtualDub2, like --preset slow, --crf 18, and same GOP length of 50. The default color space settings of VirtualDub2 correspond to smpte170m and TV color range.

[jagabo]

There might be small differences depending on the version of the x264 encoder used in the two programs. Generally the older the vesion the worse the quality. The version I'm using is 4 years old. But you'd have to pretty far back to see significant differences.

If you use a very large number of threads you will get reduced quality. For example a 64 thread encoding will deliver lower quality than a 4 thread encoding. But it's well into the double digits before it's noticable.

Older versions of VirtualDub always converted incoming YUV video to RGB when in Full Processing Mode. That would cause a very small drop in quality as the video would be converted back to YUV 4:2:0 before encoding with x264. Use Fast Reencode instead to prevent that.

[bar72]

@lovethisnation Just picked up a GV-USB2 and I'm having the exact same issue with the latest driver using Windows 10 64bit. Rolled back from driver gvusb2_112.exe to gvusb2_111.exe and now have PAL 720x576 25fps.

gvusb2_112 shows driver as 1.1.0.193 dated 6/7/2021
gvusb2_111 shows driver as 1.1.0.93.5 dated 28/6/2010

https://www.iodata.jp/lib/software/g/1780.htm

Just click Windows 7 on the drop down and download driver 111. Runs under Win 10 also. You'll need to enter serial no from the card then driver should download. hth


[Attachment 73299 - Click to enlarge]

[lordsmurf]

IDK whether AmarecTV is more reliable than vdub,

It's not. It's just different.

I think it gets over-suggested, and the negatives are ignored (while VirtualDub negatives are played up). There are other alternatives I'd explore first, such as iuVCR. But most "VirtualDub issues" are user error, wrong settings, and the fact that capture software isn't one-size-fits-all and dummy proof.

The main issue seems to be that this Japanese capture card works best with this Japanese program.

[lollo]

IDK whether AmarecTV is more reliable than vdub,

It's not. It's just different.

Is different, I showed its architecture in old posts, together with the architecture of VirtualDub and virtualVCR. I can post again the details of the internal procedures if you write again your non sense about "Transport stream manipulation", "Broadcast program", "Streaming software" and similar non sense of yours.
And is more reliable.

I think it gets over-suggested, and the negatives are ignored (while VirtualDub negatives are played up).

Because you obviously never used and then you cannot report any problem, link a post where the negatives are reported from any users.

There are other alternatives I'd explore first, such as iuVCR. But most "VirtualDub issues" are user error, wrong settings, and the fact that capture software isn't one-size-fits-all and dummy proof.

Because VirtualDub was originally designed for capturing audio and video with 2 different cards. All its timing options are useless for an integrated A/V capture card.

The main issue seems to be that this Japanese capture card works best with this Japanese program.

And ATI USB 600 as well: https://www.digitalfaq.com/forum/video-capture/12986-amarectv-virtualdub-inserts.html (just one example, there are others)
And Hauppauge USB Live-2 as well (my and others experiments), many posts about it
And Diamond VC 500 (my and others experiments) as well and most of the other cards as well (some of mine and other experiments), many posts about it.

[dellsam34]

Vdub is a great tool, but it's about damn time that someone needs to simplify it, It still has TV transmission standards options that no one needs, and a lot of new folks never understand what they are for. I don't think anyone is capturing from a TV tuner or a satellite set top box anymore. Also the options of frame sync are outdated and geared towards slow computers and hard drives, It should be setup for modern CPUs and HDD's. Having said all that vdub2 is a great editing tool and I use the $hit out of it.

[lollo]

I love VirtualDub as well, for capturing, and especially for editing. Just with modern cards and modern OSs, in term of capturing AmarecTV is far superior.

[lordsmurf]

I showed its architecture in old posts,

Link?

non sense about "Transport stream manipulation", "Broadcast program", "Streaming software" a

But those are actual aspects of video that need to be realized. When you mash together broadcasting and capturing, bad things can happen. Specifically, in this case, how intermittent data loss (of which dropped frames is one) is handled by the software. One stumbles through the lost data (as designed, for data flow continuity), the other halts/errors/logs on lost data (as designed, for absolute data integrity).

Empirical data suggests something is being glossed over, when any software magically "doesn't drop frames" or "doesn't lose sync" compared to other software that is known to properly log issues (and drops or sync loss can be replicated). This conversation reminds me of certain insane Covid-19 comments about testing. "We have too many cases because of testing. We need to test less!" (paraphrased). You cannot simply not log data, and then falsely assume a lack of logging "fixes" anything.

Because you obviously never used

Not correct.

Because VirtualDub was originally designed for capturing audio and video with 2 different cards.

Not correct. There were several USB 1.1 cards from the late 90s that were integrated AV, and supported by VirtualDub back when I first used it in the early 00s. I actually disliked VirtualDub back then, and that's a reason I used ATI MMC for AIW cards for years before reattempting VirtualDub later releases.

All its timing options are useless for an integrated A/V capture card.

Mostly false. There are a few cards that will not behave no matter what you do, but it's usually not any better with AmaRecTV either.

I love VirtualDub as well, for capturing, and especially for editing. Just with modern cards and modern OSs, in term of capturing AmarecTV is far superior.

But it's equally old clumsy software. Often unstable, actually, though no worse than anything else we all still use.

It's not superior, just different. Value it for those differences.

________

I do not understand why you constantly attempt to turn any capture software conversation, that lacks gushing glowing comments about AmaRecTV, into an argument. Video capture should not be a religion. It's fully about tools. Understanding what the tools can and cannot do, what the tools excel and suck at. AmaRecTV is not some flawless software written by the gods. It has flaws, caveats, concerns.

I just want others to recognize these facts, not get a false impression about a perfection that does not exist.

I never said not to use it.

In video, sometimes we have to use the least-worst option. No best exists, no perfection exists.

[Alwyn]

But it's equally old clumsy software.

I don't agree. The real test is when you try to write a guide. AmarecTV is flat, has a few tabs to complete and that's it. It just works. Virtual Dub, on the other hand, is a nightmare. Just read Sanlyn's guide on your site to see how complex it really is. Just your descriptions of the timing screen shows you what I mean.

I was going to write a guide for capturing with Vdub but given it's complexity, and the fact that there have been too many random posters complaining about sync issues, I decided against it.

There are other alternatives I'd explore first, such as iuVCR.

I did. I couldn't get it to capture 720 width, only 320. Uninstalled.

[dellsam34]

Don't use iuVCR, Use iuVCS, it's newer. It too geared towards tuner cards like vdub but it's slightly simplified.

[lollo]

I showed its architecture in old posts,

Link?

To understand the routines used by the capture software, the DirectShow filter graph must be "hacked". You can do this using a specific DLL, called DirectShowSpy.dll. You then run the software, and while it is capturing you can extract its built graph.
This link can be used as reference, there are others: http://alax.info/blog/777

Here the architecture of the 3 main capture sofware:

VirtualDub 1.9.11:



AmarecTV 3.11:



VirtualVCR2.6.9:



The architecture is similar, but the filter used for capturing the audio is different in VirtualDub, to allow the internal software-synch of the audio and video streams, often causing problems.

When you mash together broadcasting and capturing, bad things can happen.

In addition, you can also note that your non sense about "broadcast" / "streaming" architecture is really out of contest, and just "smoke in the eyes" to confuse newbies.

Specifically, in this case, how intermittent data loss (of which dropped frames is one) is handled by the software. One stumbles through the lost data (as designed, for data flow continuity), the other halts/errors/logs on lost data (as designed, for absolute data integrity).

That was easily verified, by myself and by others. Capture twice once with VirtualDub, once with AmarecTV. Compare the captures frame-by-frame, to be sure that the number of the frames are the sames, and there are mo missing packets (dropped frames) or added packets (inserted frames). Verify that the AmarecTV captures are in synch, while VirtualDub capture are not.
Repeat that using all VirtualDub timing settings.
Just as easy as that, using facts and not words

Empirical data suggests something is being glossed over, when any software magically "doesn't drop frames" or "doesn't lose sync" compared to other software that is known to properly log issues (and drops or sync loss can be replicated). This conversation reminds me of certain insane Covid-19 comments about testing. "We have too many cases because of testing. We need to test less!" (paraphrased). You cannot simply not log data, and then falsely assume a lack of logging "fixes" anything.

AmarecTV drops/inserts frames when signal is bad, just like VirtualDub. It cannot perform any magic, because the Windows architecture does not allow anything else:
https://learn.microsoft.com/it-it/windows/win32/directshow/video-capture?redirectedfrom=MSDN
https://learn.microsoft.com/it-it/windows/win32/directshow/capturing-video-to-an-avi-f...ectedfrom=MSDN
https://learn.microsoft.com/it-it/windows/win32/directshow/combining-video-capture-and...ectedfrom=MSDN

Reports must always be turned on in VDub and AmarectTV to understand what happens. The second outputs a detailed text files where you can check the major happenings

Because you obviously never used

Not correct.

If you say it...

Because VirtualDub was originally designed for capturing audio and video with 2 different cards.

Not correct. There were several USB 1.1 cards from the late 90s that were integrated AV, and supported by VirtualDub back when I first used it in the early 00s. I actually disliked VirtualDub back then, and that's a reason I used ATI MMC for AIW cards for years before reattempting VirtualDub later releases.

Once more, VDub was originally designed for separated audio and video cards capturing. Then the option
"Automatically disable resynch when integrated audio/video capture is detected"
has been introduced, never really reliably working, especially with moderns cards and OSs.

All its timing options are useless for an integrated A/V capture card.

Mostly false. There are a few cards that will not behave no matter what you do, but it's usually not any better with AmaRecTV either.

Once more, there is no need to implement and then use VirtualDub "resynch mode:" with modern cards having A/V integrated.

I do not understand why you constantly attempt to turn any capture software conversation, that lacks gushing glowing comments about AmaRecTV, into an argument. Video capture should not be a religion. It's fully about tools.

I do not care about AmarecTV. Is just a tool for me, as you properly said. But I just hate when your spread your lies in the capture forums, about it being a broadcast transport stream software or similar. The same when you say Hauppauge USB Live-2 has several hardware revisions. The same when you say IOData GV-USB2 is not working well for NTSC.

No religion, no personal attack to you. I just love truth and facts.

Understanding what the tools can and cannot do, what the tools excel and suck at. AmaRecTV is not some flawless software written by the gods. It has flaws, caveats, concerns.

I absolutely agree. I often use my own capture software, developed by me through GraphEditNext.
Of course, it has its flaws, caveats, concerns as well.

This is one of its architecture:

In video, sometimes we have to use the least-worst option. No best exists, no perfection exists.

I absolutely agree. What happens is just that in general AmarecTV is better than VirtualDub for A/V synch.

[lollo]

...

edit: content deleted, because I posted a reply in the wrong thread

[Sharc]

Virtual VCR is another blast from the past geared towards synching Video and Audio derived from individual master clocks. I used it successfully those times.
https://virtualvcr.sourceforge.net/

[lollo]

Yes, old good times!

[lordsmurf]

The architecture is similar, but the filter used for capturing the audio is different in VirtualDub, to allow the internal software-synch of the audio and video streams, often causing problems.

Okay.

But explain this: If this was purely software based, then why does external frame TBC correct the issue in almost all cases? Because as far as I can tell, this makes everything you're saying about the software routes moot.

I can only see it as being an edge case, where certain capture cards (or more likely specific systems) have capture software conflicts. And in those cases, captures can't, and won't, be affected by external TBC. It would drop regardless of the presence of TBC, if truly a software issue.

That then begs the opposite question. If we know TBC corrects, and that software alone cannot correct, what is AmaRecTV doing to not lose sync in those situations? Because it's not a TBC, has zero TBC functionality. That then alludes to data handling in a broadcast sense, which is designed to not lose sync, at the sacrifice of some data. Graphs do not prove or disprove this data handling.

Testing all of this will require a control group that includes frame TBC. Given the nature of video, if would be very possible, even likely, that A/B testing with frame TBC would give the same video results (remembering that audio is not affected, complete passed or bypassed). So that would make frame-by-frame scrubbing moot.

Sources to test with must also not be anything that has reduced framerates, such as animation or even progressive movies.

If you want to prove me wrong, I'm fine with it. But serious testing will be required for it.
Like most people (even though few admit to it), I only know a few things extremely well. And I've been doing video capture for almost 25 years now in an extremely serious way. There have been times where I would be disagreed with, even by multiple people, for years. A few times, I even started to doubt myself. But it would come out later that I was correct all along. So I'm far less inclined to believe I'm wrong on some of this stuff, without some high-level testing.

I'm stating/asking you this in a very non-confrontational scientific manner, so please give me the same courtesy. People can stay friendly, or even been friends, and disagree, or even think the other incorrect. Just try to remember that. There's no reason to snipe at each other. I have no ill will towards you.

[lollo]

But explain this: If this was purely software based, then why does external frame TBC correct the issue in almost all cases? Because as far as I can tell, this makes everything you're saying about the software routes moot.

No software can correct a signal problem. That's why the only serious comparisons made are with workflows including TBC, and considered. When we talk about A/V synch problems in VirtualDub is with capture chain including TBCs. Unstable signals or bad workflows are ignored on my side.

You just have an example in your forum: https://www.digitalfaq.com/forum/video-capture/12986-amarectv-virtualdub-inserts.html

That then alludes to data handling in a broadcast sense, which is designed to not lose sync, at the sacrifice of some data. Graphs do not prove or disprove this data handling.

Re-read again my previous post.

There are no drops in the compared captures. You always forget that I have a solid reference (a DVB-S dump of the same program brodcasted some year later), and I can compare exactly frame by frame. And in any case the compared captures from AmarecTV and VDub match frame-by-frame.

AmarecTV does nothing magic and cannot fix errors in the stream. If there are drops it may not be able to compensate a/v asynch, although maybe a little better than VirtualDUb.

Is just that VirtualDub has problems even with stable signal with modern OSs and modern cards. You do not understand this, and deny the facts even in front of the evidences.

But serious testing will be required for it.

We can organize a conf call and set-up together a testing session if you wish, and repeat some experiment on both sides to compare results. Then we can exchange the test tapes to repeat double check the results. PM me if interested.

Just try to remember that. There's no reason to snipe at each other. I have no ill will towards you.

Same for me. I seriously respect you, but when you deny the facts introducing non sense, lies, out of contest concept and all your arsenal of "I was correct all along" without providing results, I just cannot avoid to reply.

[lordsmurf]

We can organize a conf call and set-up together a testing session if you wish, and repeat some experiment on both sides to compare results. Then we can exchange the test tapes to repeat double check the results. PM me if interested.

Perhaps later, I can't now, but definitely something to re-visit, realistically next year.

Same for me. I seriously respect you, but when you deny the facts introducing non sense, lies, out of contest concept and all your arsenal of "I was correct all along" without providing results, I just cannot avoid to reply.

It's not nonsense/lies/etc, but rather obvious discrepancies in what we're each seeing. Variables are afoot.

Just so you know, in my Aug 20 post in this thread, I was very careful not to write anything you'd find overly objectionable (or so I thought), with the goal of us not hijacking another post in a circular disagreement. I'm very cognizant of your disagreement, and I was attempting to respect that. We can live in a world where facts (yours and mine) can yield conflicting results. For me, the issue is attempting to sort those, find how/why, not attack the messenger. So, for now, let's just table this.