|
|
| sonical |
| Posted: Feb 26 2008, 12:32 AM |
 |
|
Advanced Member
Group: Members
Posts: 143
Member No.: 23118
Joined: 23-February 08
|
I agree with -SPM-Mad about the color channel depth. It might get useful as soon as filter for sRGB<-->linearRGB conversion is added. It will certainly make even the resize filter to behave more correct. While for 8bit/chan such conversion is just pure fun - 256byte lookup table is completely sufficient, it will introduce huge errors in the processing spoiling the whole need for it.
In te current version of virtualdub, exact sRGB back and forth conversion can be done using "gadation curves" filter. However you will need to prepare exact formula generated curves for it and [import]. It ir, however, quite lossy due to the 8bit/chan limitation. Yet it's enough to check the effects of channel bit limitations.
So anybody questioning the loss can use a "Bit Drop" filter between back and forth conversions for fun. |
|
| phaeron |
| Posted: Feb 26 2008, 06:25 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
| QUOTE | | Heh, just check the new version. You forgot to remove the "this is experimental version" nag at startup - as it is not a "test 10" version any more. |
Actually, that's intended -- I've been tagging releases as experimental even before I started doing test releases.
|
|
| sonical |
| Posted: Feb 26 2008, 11:48 AM |
|
|
Advanced Member
Group: Members
Posts: 143
Member No.: 23118
Joined: 23-February 08
|
Ok, I just thought when "test 10" disappeared from the tail means that it is kind of a full featured release 
Anyways - the nag window about the experimental version is quite simple yet cleverly designed no checkbox no [ok] |
|
| Loadus |
| Posted: Feb 27 2008, 02:27 PM |
|
|
Advanced Member
Group: Members
Posts: 352
Member No.: 10881
Joined: 1-July 04
|
| QUOTE (phaeron @ Feb 24 2008, 07:56 PM) | | As for 48/64 filtering, the main blocking point is that VirtualDub's format version engine doesn't have any support for it. In the end, I'd probably support either 14-bit or 15-bit fixed point per channel, because full 16-bit unsigned is actually a bit annoying to handle efficiently in MMX, but I haven't looked into it much. Also, as I've said before, technically 14-16 bits isn't enough, because if you're trying to do linear processing, maintaining full 8-bit precision in gamma space actually requires 17 bits in linear space. |
Holy bitdepth, batman.
Sounds like OpenEXR in, OpenEXR out (feature request maybe, someday, ya know) ... 
Thanks for the new version, Phaeron!
--------------------
deviantART behance |
|
| T&T |
| Posted: Feb 27 2008, 11:30 PM |
|
|
Advanced Member
Group: Members
Posts: 39
Member No.: 22497
Joined: 26-November 07
|
Dear Phareon,
| QUOTE (phaeron @ Feb 21 2008, 03:31 AM) | | I've added this feature request to the list for consideration in a future version. |
I did some tests to estimate the CPU need of the preview overhead even if the display of captured images is turned off during capturing. I set the Video/No display option (I found it accidentally :-) ) before the capture was started. The CPU usage reduced from 40-50% to 30-40% on my PC. So it was reduced by cca. 10%!
Good byte! |
|
| mariushudea |
| Posted: Mar 1 2008, 04:05 PM |
|
|
Advanced Member
Group: Members
Posts: 54
Member No.: 22873
Joined: 19-January 08
|
I've forgot that I had Virtualdub 1.7.7 encoding a movie in the background and I've started Wolfenstein Enemy Territory, a free multiplayer game.
As soon as the game went full screen, Virtualdub crashed, as you can see from the crashinfo below.
http://savedonthe.net/download/18/crashinfo.zip
It's probably the game trying to use DirectDraw or DirectX to play the intro movie, because otherwise the game is completely OpenGL as far as I know.
It's also a bit stupid, because I shouldn't play games while encoding movies but I thought might as well send it to you, in case it helps you with something.
ps. the crashinfo says something about VDVideoDisplayMinidriverDirectDraw::InitOffscreen() . Note that both preview panels were disabled, i don't usually leave them enabled while converting, and I also think the conversion was made using fast recompress in yuy2
|
|
| phaeron |
| Posted: Mar 1 2008, 10:55 PM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
How reproducible is the problem? I think I know what's going on (device lost during overlay test), but I can't reproduce it myself.
|
|
| mariushudea |
| Posted: Mar 2 2008, 06:50 PM |
|
|
Advanced Member
Group: Members
Posts: 54
Member No.: 22873
Joined: 19-January 08
|
I've tried to reproduce it now and it worked on the first attempt.
In the link below you will find another crashinfo.txt and the job I am using when Virtualdub crashes.
http://savedonthe.net/download/19/avery.zip
The job list is a bit weird but i can assure you it works, it's generated by an application I made but it's output is correct
The idea of the job is:
1. convert a few clips to Huffyuv set on fast compression
2. Load a header clip, then append each clip followed by a small sequence, then append a footer clip
3. Convert to xvid ~800kbps
4. repeat step 2 without the header clip in such a way that the size of the final clip fits 47MB (the application determines if it needs to convert the sound to mono, lower sampling to 22kHz, resize and so on based on several factors to keep the video bitrate acceptable)
Ok, so after those clips are converted to Huffyuv, virtualdub joins all clips and starts compressing to XVID. Both preview panels are closed.
I selected Show Status Window, clicked through the tabs, remained on the Log (there I can see if it's fast recompression on YUY2)
I haven't tested if Virtualdub crashes before those clips are converted to huffyuv, only tested while the clips are joined and during conversion to xvid.
Ok, so now I start the game.
The game is Wolfenstein Enemy Territory, you can download it to test from here (it's free) if you don't have it :http://www.planetwolfenstein.com/files/files.shtml
After the game is installed, I usually delete or rename the intro movie so that the game loads faster, the file is in etmain\video\etintro.roq
Start game, select mods from the menu, select jaymod and click on Load.
The game acts as if it closes (out from full screen) and it restarts in full screen with jaymod loaded (other menus and so on).
When the menu is shown and the game is back in full screen, Virtualdub crashes.
If you don't have jaymod in the mods, you just have to connect to a couple of servers, if it's required it's downloaded automatically and installed, and will appear in the mods section. |
|
| phaeron |
| Posted: Mar 3 2008, 02:15 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Try this version for the ddraw crash issue:
http://www.virtualdub.org/beta/VirtualDub-...1.8.1-test1.zip
http://www.virtualdub.org/beta/VirtualDub-...test1-AMD64.zip
http://www.virtualdub.org/beta/VirtualDub-....1-test1-src.7z
(Job Control is a bit messed up in this version, so please don't try it for other purposes.) |
|
| mariushudea |
| Posted: Mar 3 2008, 08:50 PM |
|
|
Advanced Member
Group: Members
Posts: 54
Member No.: 22873
Joined: 19-January 08
|
I've ran it twice but not through job control, just a clip loaded and converting... and it didn't crash, no problems at all.
I'll do more tests when I have more time but I think the problem is solved. Thanks. |
|
| mariushudea |
| Posted: Mar 5 2008, 05:35 PM |
|
|
Advanced Member
Group: Members
Posts: 54
Member No.: 22873
Joined: 19-January 08
|
Tested more and it didn't crash... but I noticed that in the status window, the "Video Data: " item while compressing movie is not shown correctly, the KB/s always remains 0. |
|
| phaeron |
| Posted: Mar 6 2008, 08:14 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Dammit, broke that while fixing another bug. It's correct if your video is 1 fps... for everything else there's a / that should be a *. Will be fixed in 1.8.1.
|
|
| Simba |
| Posted: Mar 7 2008, 10:13 PM |
|
|
Newbie
Group: Members
Posts: 4
Member No.: 23183
Joined: 5-March 08
|
I don't really have any bug to report - using 1.8.0 flawlessly. Thanks for your great work
Just a little thing for the sake of completeness:
When demuxing with other programs they output *.mpa as the audio stream.
In my case it's a simple MPEG Layer II stream.
When renaming them to *.mp3 I can use them with VirtualDub's "Audio from other file..." just fine. But using the *.mpa directly gives me an error.
So adding *.mpa as an extionsion for audio files would be nice.
Sorry to bother you with such small things - I guess you've better things to do |
|
| ic_guy |
| Posted: Apr 15 2008, 06:34 PM |
|
|
Newbie
Group: Members
Posts: 2
Member No.: 23269
Joined: 20-March 08
|
Based on limited testing I find VirtualDub 1.7.8 always inserting 131096 byte JUNK chunks at the end of stream lists for both video and audio. Is this intentional?
|
|
| Moitah |
| Posted: Apr 15 2008, 11:41 PM |
|
|
Advanced Member
Group: Members
Posts: 210
Member No.: 8955
Joined: 20-February 04
|
@ic_guy: Yes, they are placeholders for the OpenDML 'super index'. The size reserved depends on the 'Superindex entry limit' setting in Options, Preferences, AVI. Just noticed there's a bug with that, by the way: the values in the 2 index entry textboxes are swapped when saving. |
|
