|
|
| stephanV |
| Posted: Jan 11 2005, 03:06 PM |
 |
|
Spam killer ;)
Group: Moderators
Posts: 4348
Member No.: 8917
Joined: 18-February 04
|
Changelog:
Build 22945 (1.6.3, experimental): [January 10, 2005]
[features added]
* Capture: DirectShow driver now supports audio passthrough (Audio >
Enable Audio Playback) for devices with integrated audio capture.
* Capture: DirectShow driver supports capture from sound cards.
* Capture: Reduced graph rebuilding in DirectShow driver for better
performance.
* Capture: Video/audio source and audio input selection is now
supported.
* Capture: More settings are automatically saved or savable through
Device > Device settings.
* Capture: Noise reduction, field swap, and luma squish can be toggled
during capture.
* Improved asynchronous file write code for better performance and
smoother timing in capture.
[bugs fixed]
* Capture: Adjusted audio resampling timing for better accuracy.
* Capture: Fixed intermittent crash when audio resampling rate goes
very high.
* Capture: Fixed erratic resampling and display when capturing with
audio compression and with audio peak meter displayed.
* Capture: VFW driver now suppresses default preview display when
display acceleration is active.
* Capture: Fixed crash when exiting capture mode with video histogram
enabled.
* Capture: DirectShow driver did not stretch display window properly.
* Capture: DirectShow driver now supports the "set custom format"
command.
* Capture: DirectShow driver now works with stop preferences.
* Capture: Disabled normal nice-in-background behavior for accelerated
display.
* Capture: Added workaround for process hang with WDM drivers that need
their video port pins rendered.
* Capture: Histogram was broken for UYVY format video.
[regressions fixed]
* Fixed crash when decompressing compressed audio with timeline edits.
* Fixed 'movi' chunk error on append.
* B-frame support was broken.
* Fixed crash when adjusting crop parameters for a filter without a
video loaded.
* Fixed some update problems in the clipping control.
* Capture: Multi-segment capture wasn't working for the third segment
and beyond.
* Capture: Fixed crash when changing video format through capture driver
dialog while preview acceleration is active.
read more here
--------------------
useful links:
VirtualDub, Input plugins and filters, AviSynth, AVI-Mux GUI, AC3ACM by fcchandler, VirtualDub FAQ |
|
| siwalters |
| Posted: Jan 12 2005, 05:37 PM |
|
|
Unregistered
|
Avery - superb.
I never thought this day would arrive - shame on me 
I can finally use my WinTV card in Win2000 instead of Win98 
I have done a quick capture and it seems to work- yippee.
I'll post any bugs/suggestions in the other threads.
MAGIC!!!!!
regards
Simon
|
|
| fccHandler |
| Posted: Jan 13 2005, 05:26 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
What he said.
I just tried my first capture with 1.6.3 and it went perfectly. Outstanding work!
The only problem I ran into was that I kept hitting the F6 key to start capture (I'm so used to it). What do you think about changing F5 to F6?
--------------------
May the FOURCC be with you... |
|
| phaeron |
| Posted: Jan 13 2005, 07:07 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Glad to hear it's working well for some people. Anyone tried the tuner/input support?
I'll just make both F5 and F6 work. F6 would be a really bad place to put anything else, anyway.
Known bugs in 1.6.3 capture module so far:
- Audio device menu is in the wrong place (fix queued)
- Cropping filter dialog acts erratically and crashes or doesn't update properly (fixes queued)
- Capture settings dialog is still broken -- click on framerate in lower right as workaround (fix queued)
- DirectShow module truncates global_time to 32-bit, which doesn't affect video but does cause the audio resync code to go haywire at 35min. (fix queued)
- Sync mode settings aren't saving yet
- Time-left meter is not taking FAT 4GB limitation into account -- need to reformat HD on the P4 HT machine, grrr....
|
|
| krage |
| Posted: Jan 14 2005, 07:22 AM |
|
|
Unregistered
|
Great Work!
This the realy first time i can capture under XP without many droped frames.
After many hours nice work a problem occured:
I want crop - no PreviewPic and after OK all changes (Resolution, Compression) are back to standard (listed in known Bugs).
After first time this bug occured (fortuity?) all my captured Videos are twist 180º! (with all Resolution, all Compression)
Thanks
Gerold
WinXP DirectX 9c
Haupauge WinTV
Format YUY2
|
|
| phaeron |
| Posted: Jan 14 2005, 07:39 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Ah, I forgot about this one. When cropping is enabled and RGB filtering is disabled, VirtualDub has to relinearize the pixmap for storage. It always does so inverted, but that's only appropriate for RGB and is wrong for YCbCr formats like YUY2. A fix has been queued for this as well. It should go away if you reset all cropping bounds to 0/0/0/0, which disables cropping.
|
|
| krage |
| Posted: Jan 17 2005, 08:29 AM |
|
|
Unregistered
|
Yes, with crop-Value 0 now is no rotation.
Since I crop, my CPU usage is explode. In my first trys with 1.6.3 CPU-usage ~60%, after crop >100%
(with "No Display", also again with crop-Value 0)
Release 1.5.10 stay on CPU-usage ~60%. Use the Versions same Parameter from Registry?
Thanks
Gerold |
|
| phaeron |
| Posted: Jan 17 2005, 09:02 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
1.5.10 and 1.6.3 share some common Registry settings, but the crop rectangle is not one of them, because 1.5.10 never saved that setting. You might try the real-time profiler and see if it shows what is taking so much CPU time; a rogue filter would be my guess.
|
|
| krage |
| Posted: Jan 18 2005, 06:51 AM |
|
|
Unregistered
|
Well, the Real-Time-Prifiler shows a Part "V-Filter" and realy "RGB-Filtering" was enabled. Now with "no Display" the CPU-usage with ~70% is OK.
With "Preview" it's still to high and many droped frames (Vfw with and without directshow + with and without Preview accerlation)
I tryed so many to solve the Problems after crop. What settings could affect the Preview performance?
I think my Grafic-Card is old and a new one can solve this Problem.
Thanks for your realy fast help
Gerold |
|
| krage |
| Posted: Jan 21 2005, 06:51 AM |
|
|
Unregistered
|
Pressing Alt + Right Arrow or Alt + Left arrow and i stay on the keys, Virtualdub 1.6.3 will show the Frames, but after any Seconds it stops and after pressing the keys and stay on it again Virtualdub dont want play the frames fast behind each other.
Greetings
Gerold
Posts in Vdub-Homepage ask for User and Password? |
|
| phaeron |
| Posted: Jan 21 2005, 08:39 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
You mean it updates sparsely? 1.6 has some logic to prevent the app from locking up if you are seeking through a highly compressed AVI; previously the app would simply freeze while decompressing the ~300 frames from the last keyframe, and potentially it could take a very long time. Unfortunately, this also means that holding down a seek key isn't as smooth as it used to be. I might be able to rework it so that the seek keys compute offsets from the current seek target rather than the current slider position, which would limit how far they could outrun the decoder and as a bonus prevent the keys from queuing up long after you have released them (which they also did in 1.5).
The password on the comment form is to stop the texas hold-em link spam crap I was getting. The text right above the button tells you what the authentication info is (user/(blank)).
|
|
| krage |
| Posted: Jan 22 2005, 04:14 PM |
|
|
Unregistered
|
I make some Samples:
Output Preview is off.
Codec PicVideo MJPG Codec (every Frame is a Keyframe) 384x288 9667kbps
If i hold down Alt+Right Virtualdub works well to 30 second, then it stops. After each Seconds i relaise the Keys, it shows the Frame at 1minute 48second.
Codec PicVideo MJPG Codec (every Frame is a Keyframe) 384x288 1486kbps
If i hold down Alt+Right Virtualdub works well to 30 second, then it shows slow one Frame by another.
Panasonic DV Codec 720x576 28633kbps
If i hold down the right Key Virtualdub do not show the Frames, the data is too much and it stay in start position.
Virtualdub 1.5.10 works well with the samples above.
Is this a bug for all user or a special on my Computer and its Settings (Graphic, Directx, Bios, ...) ?
On Monday i will test on another PC.
Greetings
Gerold
AMD1200
Elsa Geforce2 MX
DirectX9c
|
|
| fccHandler |
| Posted: Jan 24 2005, 05:40 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
I've encountered a fatal problem with VirtualDub 1.6.3, though it's difficult to describe...
While trying to capture a 2-hour movie, weird behavior started to appear around 35 minutes 47 seconds. The frame count (and all other text indicators) would pause for a moment, then race very quickly to catch up, pause again, then race again. This behavior continued, and growing alarmed, I stopped the capture. I hurriedly renamed that capture file, and started a new capture. Once again at ~35:47 the same behavior appeared. Surprisingly, no video frames were dropped in either capture.
But examining the files after the fact, I found that their audio is corrupted (sped up) after exactly 35:47.626. Just for laughs, I loaded the "sped up" audio into Cool Edit and experimented with slowing it down by changing the sampling rate. The audio had been captured at 44100 Hz, with audio resampling enabled. Curiously, slowing the corrupt portion to 1/10 speed (4410 Hz) seemed to make the pitch sound correct. 
I'll be doing additional experiments later to try and narrow down the cause. For one thing, I want to see if I can capture 35+ minutes with other DShow/WDM capture programs.
Furthermore, it hasn't escaped my notice that the timing is frighteningly consistent with the reported "35-minute" version of the infamous 71 minute bug. But in my case, the video was still capturing fine; only the audio stream suffered.
Right now I'm a little discouraged to have to go back to VirtualDub-MPEG2 1.5.10. But fortunately my movie will be broadcast again tomorrow.
--------------------
May the FOURCC be with you... |
|
| phaeron |
| Posted: Jan 24 2005, 06:20 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
O-ho-ho-ho... I get to tell a moderator that he should have used the search function.
I already noted this particular bug in my known-issues list in my Jan 13th post in this thread -- to repeat, it's caused by an accidental 32-bit truncation in the DirectShow module. The reason for the 10x compression is that the resync controller is hard-limited to factors between [0.1, 10.0] to prevent it from crashing, and the time base wraparound causes it to slam against the range limiter. The video is not affected because the video portion works off of video timestamps, while the audio resync module uses the global clock (audio is not timestamped in VFW).
I've been spending the last few days poring over the DirectShow docs for information on reference clocks trying to fix the SAA713x. I think I've got a workable solution now, but I have to test against the other three capture devices I have installed to make sure I didn't break something else. |
|
| fccHandler |
| Posted: Jan 24 2005, 06:57 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
 DOH!
(fcc runs away and hides...)
--------------------
May the FOURCC be with you... |
|
