Unofficial VirtualDub Support Forums [Powered by IB Forums]

Printable Version of Topic
Click here to view this topic in its original format

Unofficial VirtualDub Support Forums > Testing / Bug Reports > Test Thread: Virtualdub 1.7.x

Posted by: phaeron Oct 17 2007, 05:26 AM

Note: VirtualDub 1.7.X is now live as 1.8.0 experimental -- please use the released version until the 1.8.1 test thread is launched!

Alright, enough of this "stable" crap. Time to show what I've been working on in the other branch.

Why's it called 1.7.X? Because I don't know when it'll be released. So far, it looks like it'll be at least 1.7.8.

Notable new features in this version:

Video filters can now access video frames out of order and can change frame rate. There is still no support for multiple source frames yet, but this does allow for bob deinterlacing filters.
Multiple audio streams are now supported -- the source audio option is now a submenu. For those of you writing input drivers, hopefully you checked the stream number in GetAudioStream()....
The WAV audio option is now an "audio from other file" option, and can take video files that have audio tracks as well. Now we get to see which input drivers are reentrant.
There are now internal decoders for A-law, mu-law, MPEG layer II, and MPEG layer III audio, for when external audio codecs aren't available for those formats. Prioritization relative to audio codecs can be controlled in Preferences, AVI. (This was requested for the AMD64 build, but it is available in the X86 build as well.)
True VBR audio read/write support, including direct mode. The warning's still there right now, but it will most likely go away. This is not yet available to input driver plugins since I haven't added API extensions for it, so input drivers returning IsVBR()==true will still use "psuedo-VBR" mode.
MP3 files can be used directly. Right now this always uses VBR mode, although I plan to add CBR mode support (actually, it's there, but I don't have a way to enable it yet). Also, this is only active if you have a bare MP3 stream -- if it's a WAV file, the WAV handler currently handles it.

Please include all feedback in this thread.

Posted by: fccHandler Oct 17 2007, 05:41 AM

Wow, that looks fun. I'll goof around with it tomorrow (I'm pretty beaten tonight). Thanks!

Posted by: Placio74 Oct 17 2007, 06:19 AM

That's great!
Thank you very match.

Posted by: XYZ Oct 17 2007, 12:00 PM

I have been waiting for this very long time. Thank you very much! I just have few notices, if you don't mind.

- To eliminate a need for VirtualDubMod, it would be nice if you implement at least same options for audio stream manipulation as VirtualDubMod. So, there is missing Add/Delete stream (you have only a replace possibility). Not to mention that your demultiplexer is not logically organized, it is in wrong menu (File / Export / Raw audio), and not giving proper file extension depending of content.

- File / File Information show characteristics only for first audio stream, even if I choose second one in Audio / Source audio.

- When I open AVI file, I get warning message about VBR, even when audio is uncompressed PCM (1.7.6 version don't display warning message with same AVI file).

- If I try to append AVI files with two audio streams - VD crash. I have tried 3 different AVI files, each of them is spllited on 2 or 3 parts, and VD crash with every one. VirtualDubMod works fine with two of them, and with one of them it displays error message about different audio formats but it not crash (AVI-Mux GUI correctly joins even this one). If you wish, I can paste crashinfo file here.

Anyway, this is really great what you did. Thanks again.

Posted by: neuron2 Oct 17 2007, 12:49 PM

Posted by: FievelMousey Oct 17 2007, 08:12 PM

I get a error that this one caint capture video to AVI what up with that.

Looks like its not switching over to codecs usable only in capture mode. It is showing all looks like as it does when recompressing video in non capture mode.

Posted by: Moitah Oct 17 2007, 11:18 PM

I modified the FLV and WMV plugins to return false for GetVideoSource and set mFlags to VDInputDriverDefinition::kFlagSupportsVideo | VDInputDriverDefinition::kFlagSupportsAudio. When I do File > Open video file and pick the file, VirtualDub http://www.moitah.net/misc/crashinfo-v.txt with both instead of saying File does not have a video stream. Also when I do Audio > Audio from other file and pick a FLV/WMV, VirtualDub http://www.moitah.net/misc/crashinfo-a.txt when I click play.

BTW the 0.6 SDK documentation for kFlagSupportsAudio says:
This indicates to the host that this plugin should be included in features that load files for video.

All these new features are great, nice work.

Posted by: neuron2 Oct 18 2007, 12:53 PM

Posted by: phaeron Oct 19 2007, 05:06 AM

Sorry, been slammed with work the past couple of days. Thanks for all the great feedback so far, though!

I rewrote the AVI index code pretty heavily in 1.7.X, so it's got some bugs... that's what's fouling append, and large AVIs have issues too. Working on getting those fixed (and some proper unit tests in place).

Capture not working, crash with no-video file: Will be fixed in next drop.

There are no docs for the new filter features yet, because it isn't finalized and I haven't had a chance to update the docs properly (I'd like to merge it into the plugin SDK). The updated header is in src\h\vd2\plugin\vdvideofiltold.h. These are the pertinent definitions:

CODE

#define VIRTUALDUB_FILTERDEF_VERSION (12)

typedef sint64 (*FilterPrefetch )(const FilterActivation *fa, const FilterFunctions *ff, sint64 frame);

typedef struct FilterDefinition {
...
FilterDeserialize deserializeProc;
FilterCopy copyProc;

FilterPrefetch prefetchProc; // (V12)
} FilterDefinition;

class VFBitmap {
public:
...
DWORD dwFlags;
HDC hdc;

uint32 mFrameRateHi; // Frame rate numerator (V12)
uint32 mFrameRateLo; // Frame rate denominator (V12)
sint64 mFrameCount; // Frame count; -1 if unlimited or indeterminate (V12)
...
};

The key is that paramProc can change the FrameRateLo/Hi/Count fields in the fa->dst structure, if the API version is at least V12. This causes the frame rate and/or length of the output stream to change. There is also a new prefetchProc that allows greater control over the source frame associated with each output frame. If prefetchProc is not supplied, the source frame is assumed to be the one with the closest mid-frame timestamp to that of the output frame.

Posted by: fccHandler Oct 19 2007, 07:03 PM

As a test, I modified my MPEG-2 plugin by adding kFlagSupportsAudio, so it appears in the "audio from other file" dialog. Then I started 1.7.X and opened an MPEG-2 movie. Then I used the "audio from other file" dialog to load the audio from another MPEG-2 movie. It all seemed to work well, until I tried to quit VirtualDub. Here's the crashlog:

http://fcchandler.home.comcast.net/crash.zip

(The zip includes a debug build of the MPEG-2 plugin with kFlagSupportsAudio turned on.)

The crash only happens if I quit with the audio file still open. If I select "no audio" to release the audio file, then it doesn't crash when I quit.

Posted by: dum Oct 19 2007, 11:02 PM

Thanx a lot!!! You are making a great tool for us!

Posted by: fccHandler Oct 20 2007, 06:21 AM

Since we're being all experimental and stuff, here is an experimental version of MPEG2X plugin 2.0, which tries to take advantage of some of the new features of VirtualDub 1.7.X:

http://fcchandler.home.comcast.net/Plugins/MPEG2X/MPEG2X.zip
http://fcchandler.home.comcast.net/Plugins/MPEG2X/MPEG2X-source.zip

There is no "choose audio" dialog anymore. Instead, all supported audio streams (MPEG, AC-3, and LPCM) are parsed and presented to the 1.7.X host upon request. Indexing still works (I think). I haven't tested jobs yet. Crash reports, bugs, and/or suggestions for improvement are all welcome.

@phaeron:
Something I found lacking in 1.7.X is a method for the plugin to determine which audio stream is currently selected in VirtualDub, so it can display that stream's properties in its File Information dialog.

Posted by: phaeron Oct 20 2007, 07:38 AM

New drop with bug fixes:

http://www.virtualdub.org/beta/VirtualDub-1.7.X-test2.zip
http://www.virtualdub.org/beta/VirtualDub-1.7.X-test2-AMD64.zip
http://www.virtualdub.org/beta/VirtualDub-1.7.X-test2-src.7z

Posted by: Gromozeka Oct 20 2007, 10:48 AM

Audio file not play!
Audio is from vob - ac3

Posted by: Placio74 Oct 20 2007, 11:34 AM

QUOTE (Gromozeka @ Oct 20 2007, 10:48 AM)

Audio file not play!
Audio is from vob - ac3

You have installed AC3 ACM codec?

VirtualDub-1.7.X-test2, MPEG2X plugin and AC-3 ACM Codec - i'm can play and hear AC3 audio (contain in VOB) without any problems...

Posted by: Gromozeka Oct 20 2007, 11:48 AM

QUOTE

You have installed AC3 ACM codec?

Yes! VirtualDub 1.7.6 stable play ac3 from this vob
But this ac3 from vob to avi compessed

Posted by: Placio74 Oct 20 2007, 12:07 PM

QUOTE (Gromozeka @ Oct 20 2007, 11:48 AM)

QUOTE

You have installed AC3 ACM codec?

Yes! VirtualDub 1.7.6 stable play ac3 from this vob
But this ac3 from vob to avi compessed

Ehm... any sample file?

Posted by: XYZ Oct 20 2007, 12:26 PM

Great! VD now don't crash and I can append almost all AVI files with two audio streams. But there is still one problematic:

http://img521.imageshack.us/my.php?image=virtuialdub1nc9.png

VirtualDubMod has also a problem with same AVI file. I think this is because one audio stream is a little shorter then another (40:08.448 vs 40:08.416), and both of them are a little shorter then video stream (40:08.887):

http://img89.imageshack.us/my.php?image=virtualdubmod1qe5.png

BTW, AVI-Mux GUI can append this AVI without a problem.

Posted by: heustess Oct 20 2007, 10:36 PM

@phaeron:
I noticed a little difference in the jobs script syntax.

VirtualDub 1.7.6 syntax:
VirtualDub.audio.SetSource("C:\\sample.wav");

VirtualDub 1.7.X-test2 syntax:
VirtualDub.audio.SetSource("C:\\sample.wav", "");

Also have you thought about an option to normalize the audio?

Posted by: phaeron Oct 21 2007, 01:59 AM

@XYZ:
The length is not the problem. The error message tells you exactly what prevents the append. Doing a verbatim append of two clips that have different declared data rates results in a sync change between video and audio, full stop.

@heustess:
V1.7.X test-1 introduced an additional overload of audio.SetSource() to allow the input driver to be specified. This is necessary in case you have a file that can be read by multiple input drivers and you force a specific one in the file dialog. This wasn't necessary in earlier versions because only the WAV driver was ever used. The 1.7.6 one-argument syntax is still supported, but it auto-selects the best available input driver for the file.

Regarding normalize: sure, thought about it, but I don't mention it since it's not implemented Keep in mind that I can't instantly add every feature I hear about.

Posted by: FievelMousey Oct 21 2007, 02:14 AM

Crash when I tried capture video

http://webpages.charter.net/fievelmousey/Crash.jpg

Here is a weird one look below in capture mode says audio is unknown and i caint change it.

http://webpages.charter.net/fievelmousey/AudioUnknown.jpg

VirtualDub crash report -- build 28583 (release)
--------------------------------------

Disassembly:
00422240: 86bc0000003bc1 xchg [eax+eax-3ec50000], bh
00422247: 754e jnz 00422297 (VDCaptureData::WaveCallback+197)
00422249: 8b8e84000000 mov ecx, [esi+84]
0042224f: 8b11 mov edx, [ecx]
00422251: 8b4218 mov eax, [edx+18h]
00422254: ffd0 call eax
00422256: 8b8ed0000000 mov ecx, [esi+d0]
0042225c: 0b8ed4000000 or ecx, [esi+d4]
00422262: 89868c000000 mov [esi+8c], eax
00422268: 7511 jnz 0042227b (VDCaptureData::WaveCallback+17b)
0042226a: 8b560c mov edx, [esi+0ch]
0042226d: 55 push ebp
0042226e: 55 push ebp
0042226f: 6801800000 push 00008001
00422274: 52 push edx
00422275: ff1540765900 call dword ptr [00597640]
0042227b: 83467401 add dword ptr [esi+74h], 01h
0042227f: 89aec0000000 mov [esi+c0], ebp
00422285: 89aec4000000 mov [esi+c4], ebp
0042228b: 89aea8000000 mov [esi+a8], ebp
00422291: 89aeac000000 mov [esi+ac], ebp
00422297: 8b442428 mov eax, [esp+28h]
0042229b: 017c2424 add [esp+24h], edi
0042229f: 2bc7 sub eax, edi
004222a1: 3bc5 cmp eax, ebp
004222a3: 89442428 mov [esp+28h], eax
004222a7: 0f8fe3feffff jg 00422190 (VDCaptureData::WaveCallback+90)
004222ad: eb79 jmp 00422328 (VDCaptureData::WaveCallback+228)
004222af: 8b8e6c010000 mov ecx, [esi+16c]
004222b5: 3bcd cmp ecx, ebp
004222b7: 7416 jz 004222cf (VDCaptureData::WaveCallback+1cf)
004222b9: 8b8670010000 mov eax, [esi+170]
004222bf: 6800b75900 push 0059b700
004222c4: 68e0e0e000 push 00e0e0e0
004222c9: 50 push eax
004222ca: e881dc0c00 call 004eff50 (VDRTProfiler::BeginEvent)
004222cf: 8b7c2428 mov edi, [esp+28h]
004222d3: 8b8e8c000000 mov ecx, [esi+8c]
004222d9: 33d2 xor edx, edx
004222db: 8bc7 mov eax, edi
004222dd: f7b690000000 div eax, dword ptr [esi+90] <-- FAULT
004222e3: 8b542424 mov edx, [esp+24h]
004222e7: 8b19 mov ebx, [ecx]
004222e9: 50 push eax
004222ea: 8b431c mov eax, [ebx+1ch]
004222ed: 57 push edi
004222ee: 52 push edx
004222ef: 55 push ebp
004222f0: ffd0 call eax
004222f2: 8b8e6c010000 mov ecx, [esi+16c]
004222f8: 3bcd cmp ecx, ebp
004222fa: 740c jz 00422308 (VDCaptureData::WaveCallback+208)
004222fc: 8b9670010000 mov edx, [esi+170]
00422302: 52 push edx
00422303: e887d70c00 call 004efa8f (VDRTProfiler::EndEvent)
00422308: 8d4718 lea eax, [edi+18h]
0042230b: eb07 jmp 00422314 (VDCaptureData::WaveCallback+214)
0042230d: 8b442428 mov eax, [esp+28h]
00422311: 83c018 add eax, 18h
00422314: 33c9 xor ecx, ecx
00422316: 014638 add [esi+38h], eax
00422319: 114e3c adc [esi+3ch], ecx
0042231c: 0186a8000000 add [esi+a8], eax
00422322: 118eac000000 adc [esi+ac], ecx
00422328: 8b442410 mov eax, [esp+10h]
0042232c: 50 push eax
0042232d: ff1568735900 call dword ptr [00597368]
00422333: 8b4c2414 mov ecx, [esp+14h]
00422337: 5f pop edi
00422338: 5e pop esi
00422339: 5d pop ebp
0042233a: b001 mov al, 01h
0042233c: 5b pop ebx
0042233d: 64890d mov fs:[ebp], ecx

Built on KOS-MOS on Fri Oct 19 23:24:28 2007 using compiler version 1400

Windows 5.1 (Windows XP x86 build 2600) [Service Pack 2]

EAX = 000044e8
EBX = 00b6b570
ECX = 00b6ab60
EDX = 00000000
EBP = 00000000
ESI = 0012f984
EDI = 000044e8
ESP = 0438faa8
EIP = 004222dd
EFLAGS = 00010246
FPUCW = ffff027f
FPUTW = ffffffff

Crash reason: Integer Divide-by-Zero

Crash context:
An integer division by zero occurred in module 'VirtualDub'.

Pointer dumps:

EBX 00b6b570: 0059b9b0 0059b99c 0059b98c 00b6e160 00000000 00bc0532 00b6a390 00000001
ECX 00b6ab60: 005af6f4 00000000 00000000 00000000 00620075 00310020 0037002e 0058002e
ESI 0012f980: 00000112 0059b728 0059b72c 00000000 00000000 00b6b570 7e41ea8d 0012faa0
ESP 0438faa8: 000044e8 0012f984 03570008 00b6b570 0012fa64 0438fb88 00589f18 00000000
0438fac8: 00425314 03570008 000044e8 0002d690 00000000 0438fb98 ffffffff 00b6b574
0438fae8: ffffffff 01610000 002f0003 0438fb98 00000018 0438fbbc 7c800000 0438fba8
0438fb08: 01610000 00690048 00200074 00530045 00410043 00450050 006f0020 00200072

Thread call stack:
004222dd: VDCaptureData::WaveCallback()
00425314: VDCaptureProject::CapProcessData2()
00450050: YUVCodec::DecompressEx()
004254b1: VDCaptureProject::CapProcessData()
00542555: VDCaptureResyncFilter::CapProcessData()
00540e02: VDCaptureAudioRateEstimator::AddSample()
00422719: VDCaptureStatsFilter::CapProcessData()
0055479d: VDCaptureDriverVFW::WaveCallback()
73b830d0: avicap32!capCreateCaptureWindowA [73b80000+1e3b+1295]
73b83af7: avicap32!capCreateCaptureWindowA [73b80000+1e3b+1cbc]
7e418806: USER32!GetDC [7e410000+86b7+14f]
7c80b683: kernel32!GetModuleFileNameA [7c800000+b4cf+1b4]

-- End of report

Posted by: heustess Oct 21 2007, 02:51 AM

QUOTE (phaeron @ Oct 21 2007, 01:59 AM)

Keep in mind that I can't instantly add every feature I hear about.

I completely understand. I am amazed at all the features you have implemented and how quickly you work out the bugs. Thanks for your quick response to questions.

Posted by: squid_80 Oct 21 2007, 05:37 AM

QUOTE (phaeron @ Oct 17 2007, 03:26 PM)

There are now internal decoders for A-law, mu-law, MPEG layer II, and MPEG layer III audio, for when external audio codecs aren't available for those formats. Prioritization relative to audio codecs can be controlled in Preferences, AVI. (This was requested for the AMD64 build, but it is available in the X86 build as well.)

MP3 files can be used directly. Right now this always uses VBR mode, although I plan to add CBR mode support (actually, it's there, but I don't have a way to enable it yet). Also, this is only active if you have a bare MP3 stream -- if it's a WAV file, the WAV handler currently handles it.

Hooray! I can ditch my half-assed attempts to get mpeg audio decoding working and see how it should be done. One request though: can we directly load mp2 audio as well as mp3?

Posted by: XYZ Oct 21 2007, 08:00 AM

QUOTE (phaeron @ Oct 21 2007, 01:59 AM)

phaeron, I have two AVI files which I want to append. This two AVI files was made by splitting one AVI file. This source AVI file was made in one go, with same audio bitrate, same audio codec, same sample rate, same audio bit depth... Splitting of this source AVI file on two parts was with a help of some video splitter program in Direct stream copy mode. I want just opposite - to join this two parts of same video source.

Problem is in fact that this video has two audio streams. If I save both of this AVI parts without one audio stream (e.g. with a help of AVI-Mux GUI), I could append new AVI files with VirtualDub(Mod) without problem.

Please, could you tell me how AVI-Mux GUI can append this two parts with two audio streams without any problem? AVI-Mux GUI also cannot join every possible AVI files, but only those with same video resolution, audio sample rate... This is obvious limitation of Direct stream copy mode. But, I think there is another problem with this AVI files, not audio datarate as you telling me.

Posted by: phaeron Oct 22 2007, 04:54 AM

No new features, but a couple of quick bug fixes.

http://www.virtualdub.org/beta/VirtualDub-1.7.X-test3.zip
http://www.virtualdub.org/beta/VirtualDub-1.7.X-test3-AMD64.zip
http://www.virtualdub.org/beta/VirtualDub-1.7.X-test3-src.7z

There was another bad bug in the new AVI indexing code that was preventing large AVI files from working properly, and I fixed the reported bugs in the capture module. I also fixed a bug that prevented MPEG-2 layer II audio from working with the built-in MPEG audio codec.

In addition, this version has a significantly improved MPEG audio parser that is more robust against junk in the stream and can also produce the MPEG-1 audio format (tag 0x0050) as well as the MP3 format (tag 0x0055) if it detects layer I or layer II audio frames in the stream. Note that *.mp2 isn't in the filename filter right now, so you'll have to override the file type if you're trying to pull in MPEG layer II audio with that file name extension. The 0x0050 format is even less documented than the 0x0055 format, but so far 1.7.X seems to be able to interop both ways with the DirectShow MPEG audio splitter and decoder, which is a good sign. In theory this means that direct stream copy of audio from MPEG to AVI is now possible, but I haven't thought through the ramifications yet. Still have a bunch of TODOs on this feature, such as figuring out a way to choose between CBR/VBR, and how to resolve the conflict between the WAV and MP3 input drivers for the annoying case of MP3-in-WAV.

As for the dual audio stream append issue, that's not something that I've tested, but it shouldn't be a problem... all streams are joined independently. I'll see if I can reproduce this issue.

Posted by: FievelMousey Oct 22 2007, 05:34 AM

Ok capture works but I have no codecs showing up only can use uncompressed.

EDIT

This was weird now they showing up so must be something comes and goes as I closed capture mode reopened it up now they showing

Posted by: XYZ Oct 22 2007, 08:21 AM

phaeron, if you take a look on my first screenshot, you will see that difference between datarates is very small (24001 bytes/sec vs. 24000 bytes/sec). If I remember correctly, I saw something similar before, even when I tried to append AVI files with only one audio stream. Could it be possible that your compare code is too precise? Maybe you should round the result to 3 or 4 significant digits.

Posted by: XYZ Oct 22 2007, 10:02 AM

QUOTE (phaeron @ Oct 21 2007, 01:59 AM)

Regarding normalize: sure, thought about it,

It would be nice if audio volume change could be lossless, at least for MP3. I suppose that you know for open sourced MP3Gain.

Posted by: pintcat Oct 22 2007, 10:01 PM

It's getting better and better! I checked the new versions the last few days and till now VDub 1.7.X-test3 worked absolutely flawless to me (even the new MPEG2 plug-in did so). Also, I'm very glad about some of the new features in this version, like the handling of multiple audio streams and the ability to import several audio formats as separate streams. Too bad, AC3 isn't supported. Maybe not yet?
Anyway, thanx for this great piece of software!

Posted by: fccHandler Oct 22 2007, 10:13 PM

QUOTE (pintcat @ Oct 22 2007, 06:01 PM)

Too bad, AC3 isn't supported.

I made an audio plugin for AC-3 last night, but I haven't made a web page for it yet. You're welcome to test it out:

http://fcchandler.home.comcast.net/AC3.zip

This plugin will ONLY work with VirtualDub 1.7.X.

Posted by: heustess Oct 23 2007, 12:00 AM

@fccHandler:

Please clear up my ignorance. What is the difference between your AC-3 ACM Codec and your AC-3 plugin? Are both needed? How should we test the AC-3 plugin to be helpful?

Posted by: fccHandler Oct 23 2007, 03:00 AM

AC3ACM actually has nothing to do with VirtualDub. It's a driver which works through the Windows Audio Compression Manager interface (ACM for short). It doesn't talk to anyone but the ACM, and it knows nothing about what programs are using it. VirtualDub just happens to be one example of a program that uses the ACM to compress and decompress audio, and that's where they connect. Without the codec, Windows has no ACM driver to decode compressed AC-3 audio, and VirtualDub's queries to the ACM will fail.

The AC-3 plugin is strictly for the test version of VirtualDub 1.7.X, and (just like other file input plugins) it allows VirtualDub to open a file type that it doesn't normally support. In this case, it allows you to open raw .ac3 files via VirtualDub's new "Audio from other file" dialog. You only need the plugin if this is something that you are wanting to do.

Posted by: heustess Oct 23 2007, 03:21 AM

@fccHandler:
Thanks for clearing up my confusion over your AC-3 ACM Codec and your AC-3 plugin. They both should prove quite useful.

Posted by: FievelMousey Oct 23 2007, 04:06 AM

Does or will they be any support ever Studio Plus 700-PCI capture card if not the end of using Virtualdub has come for me as I have moved to that card and can no longer test unless supported in future builds

Posted by: heustess Oct 23 2007, 07:49 PM

@fcchandler:

I am using the latest test VirtualDub and test AC-3 plugin as well as all your other latest plugins and AC-3 ACM Codec. I demuxed a vob into m2v and ac-3. I loaded the m2v into VirtualDub and selected the ac-3 as the audio. When I deselected "Cut off audio when video stream ends" VirtualDub gave me an error at the end of decoding (Attempt to read past end of video). The avi had very noticable audio problems when played back on Windows Media Player. I tried it again this time selecting "Cut off audio when video stream ends". There was no VirtualDub error message, but the audio problems still showed up playing the avi in Windows Media Player.

Posted by: pintcat Oct 23 2007, 08:16 PM

@fccHandler: Thank you very much for the new plug-in, I didn't expect any reaction that fast! And it worked well for me. I just tested some direct stream copy processes with XviD-AVI and AC3 audio and I didn't notice any problems. Will check it a bit harder the next days...

A general question about VDub 1.7.X: Since it handles multiple audio tracks per video, is it possible to add multiple audio tracks from an external source? Because with the "Audio from other file..." option you can add only one.

Posted by: fccHandler Oct 23 2007, 08:21 PM

QUOTE (heustess @ Oct 23 2007, 03:49 PM)

VirtualDub gave me an error at the end of decoding (Attempt to read past end of video).

Actually that error comes from my MPEG-2 plugin, and it should be easy to fix. Were you using v1.9, or the test version "MPEG2X" for VirtualDub 1.7.X? (They're somewhat different internally.)

QUOTE

The avi had very noticable audio problems when played back on Windows Media Player.

What sort of audio problems did you hear? Meanwhile, I'll see if I can reproduce what you're doing.

Posted by: heustess Oct 23 2007, 08:33 PM

@fccHandler

I was using the test version "MPEG2X". The avi in Windows Media Player 11 got way out of sync and sometimes was silent. This was at its worst when seeking to different parts of the avi with Windows Media Player 11.
I just tried the same test with MPEG-2 plugin v1.9 and got the same results.

Posted by: fccHandler Oct 23 2007, 08:52 PM

My mistake; the "attempt to read past end of video" error actually comes from the AC-3 plugin! I had to download the .zip I posted two nights ago to reproduce it, because it's been fixed in the code I have now. I'll post it officially sometime tonight.

I can't reproduce the audio playback problem in WMP, but it may depend on what DirectShow filter you have for AC-3. On my system, it's something called "CyberLink Audio Decoder (ATI)". Do you see any audio problems when you open your AVI in VirtualDub and play it there?

EDIT: Another thought... If you perform all of the same operations using VirtualDub-MPEG2, does the resulting AVI play OK then?

Posted by: heustess Oct 23 2007, 09:40 PM

@fccHandler:

The avi will not play in VirtualDub. VirtualDub-MPEG2 does not have this problem when tested the same way.

Posted by: fccHandler Oct 23 2007, 10:30 PM

Hmm... I just did the same test myself (VirtualDub 1.7.X versus VirtualDub-MPEG2) and except for a few expected places, the resulting AVIs were bit-for-bit identical. But one difference really stood out:

VirtualDub 1.7.X didn't fill in the dwSampleSize field in the audio stream header, instead it used zero. VirtualDub-MPEG2 used the value from nBlockAlign. That might very well explain why WMP11 doesn't like it.

BTW, here is the build I'm currently using:
http://fcchandler.home.comcast.net/Plugins/AC3/AC3.zip (28 KB)
http://fcchandler.home.comcast.net/Plugins/AC3/AC3-source.zip (25 KB)

EDIT: And you're right, that AVI written by VirtualDub 1.7.X won't play back in VirtualDub 1.7.X.

Posted by: rfmmars Oct 24 2007, 05:09 AM

This is what I am seeing, using ffdshow MJPEG codec in 1.7x, it records fine but when that clip is brought into 1.7x test 3, just black screen, 1.67 read that clip ok.

EDIT: The frameserver install problem is back......it will frameserve as long as you have installed it before with an older VD.

Richard

Posted by: phaeron Oct 24 2007, 05:11 AM

Don't think dwSampleSize is the problem here -- it's a bug in the input driver plugin code for audio streams. Will be fixed in 1.7.7.

Update:
Haven't looked into the frameserver install issue yet, but here's a version of 1.7.X that's synced to the 1.7.7 branch, including the plugin audio dwStreamSize fix:

http://www.virtualdub.org/beta/VirtualDub-1.7.X-test4.zip
http://www.virtualdub.org/beta/VirtualDub-1.7.X-test4-AMD64.zip
http://www.virtualdub.org/beta/VirtualDub-1.7.X-test4-src.7z

Posted by: heustess Oct 24 2007, 09:43 AM

Using the new VirtualDub 1.7.X-test4, MPEG2X plugin, AC-3 plugin, and WMV plugin (input is the same demuxed m2v and ac-3 as mentioned before) both VirtualDub and Windows Media Player 11 now open and play the avi just fine with no sync problems. Good job guys!

Posted by: rfmmars Oct 24 2007, 01:07 PM

1.7x Test 4,

Frameserver install working again BUT I was about to post a problem with test 3 when I saw Test 4.

Both have the same problem. When marking a range to delete, it takes out the correct amount of frames BUT the wrong frames.

For example you have a 500 frame clip and you want to take out the first 100, well it takes out 100 frames BUT not the right ones.

EDIT: I though it might be the import front end but I tested with a Mpeg2 and a WMV clips, same problem. Mpeg2 edits ok with 1.67

Richard

Posted by: heustess Oct 24 2007, 04:00 PM

@rfmmars:

Have you tried first saving as an uncompressed avi then taking out the frames from the new avi and saving to a second avi? Key frames may be adjusting your range.

Posted by: XYZ Oct 24 2007, 08:16 PM

phaeron, there is reported one problem with VirtualDub yesterday on the videohelp site: http://forum.videohelp.com/topic339074.html

I tried to reproduce this problem, and I got same error message, only values are different.

http://img250.imageshack.us/my.php?image=virtuialdub2ut5.png

It is manifesting with all versions of VirtualDub, not only this experimental. I am mentioning this problem here because I think it is related to my post about a problem with appending two files with two audio streams.

Here is a description what I tried. I have one short sample (~25 sec, 302 frames), XviD with only one audio stream MP3 CBR. Its frame rate is 23.976 fps. I set "Change frame rate to (fps)" to half of the original frame rate (11,988 fps), and set "Convert to fps" to the original frame rate (23.976 fps). In that way, resulting AVI file should have same frame rate as original and should have every frame duplicated, so it is reproduced in slow motion. I saved file with Direct stream copy and checked it - it really has same frame rate (23.976 fps, 604 frames).

When I tried to append a saved AVI file to the original one, I got error message saying that video streams have different sampling rate. As with my previously reported problem, difference is really very small (23.97602 vs. 23.97600).

After that I tried same AVI sample with converted audio to PCM, and I got same error message. I was not lazzy, and I tried to save both AVI files without audio stream. When I tried to append such files I got same error.

Next, I tried another sample which has 25 fps (same process for creating slow motion file) and problem didn't occurred. I tried that sample with MP3, AC3 and PCM audio - there was not any error, append worked without any problem.

EDIT: I hate this to say, but I just tried AVI-Mux GUI and it appended AVI files without a problem, even first sampe (23.976 fps).

EDIT2: Avidemux also append first sample successfully. VirtualDubMod cannot, but this was expected as it share many of the VirtualDub code.

Posted by: rfmmars Oct 24 2007, 08:26 PM

QUOTE (heustess @ Oct 24 2007, 10:00 AM)

@rfmmars:

Have you tried first saving as an uncompressed avi then taking out the frames from the new avi and saving to a second avi? Key frames may be adjusting your range.

I am comparing apples to apples. Same clip, same range edits fine in 1.67 but not 1.7x test 3 & 4, in other words you can't edit at all with these versions.

EDIT: Test4 now plays ffdshow Mjpeg.

Richard

Posted by: XYZ Oct 24 2007, 09:11 PM

rfmmars, I just tried one XviD file with MP3 and its editing works fine. I tried Direct stream copy (key frames on both ends), as well as Fast recompress with Smart rendering (first and last arbitrary frames). I got result file with exact frames which I selected. Could you tell me how to reproduce your problem?

Posted by: rfmmars Oct 24 2007, 10:47 PM

QUOTE (XYZ @ Oct 24 2007, 03:11 PM)

I have 1.67, 1.76 , 1.7x test4, and Vd(mpeg2 1.5.10 build 18294) all installed, the Mpeg2 clip is all I frames.

Its not missing by a frame or two, lets say I have a 500 frame clip and the first scene is 100 frames long, and I want to cut it out, so I mark the begining out to the 100th frame to be deleted, it shows the blue line over that range. I hit delete, and now I have 400 frames left, but the first 100 frames are still there, the scene is still there, but it has deleted 100 frames somewhere else.

I don't remember if 1.7x test 1 or test two had this problem since these releases had other problems.

So with the same clip or other clips made with other codecs, 1.67, 1.76, and Virtualdub(mpeg2) there is no problem, it is as simple as that, I know what I am doing, I use "VD jobs" tens of times a week to process my movie footage.

Now I haven't installed the 1.7x (testx) on my other four workstations, so I will do that tonight and bring you all up to date tomorrow.

Richard

Posted by: fccHandler Oct 24 2007, 11:14 PM

I can reproduce this too, with 1.7.X test4. It doesn't happen in 1.7.6.

EDIT: XYZ, same time post!

You don't need to do anything special. Just open any AVI and delete the first hundred or so frames.

Posted by: XYZ Oct 24 2007, 11:14 PM

rfmmars, I am not saying that you don't know what you are doing. I just wanted to reproduce this problem which you detected.

How did you load MPEG-2 file into 1.6.7 version of VirtualDub? AFAIK only 1.7.6 has correct support for input plug-ins. You first talked about MJPEG, then you mentioned frameserver, now you are telling me about MPEG-2 file. I am ready to help in this, but I don't know what to test. Which application is frameserving, VirtualDub or AviSynth or some another? And which is a client?

EDIT: OK, forget my questions. You are right, I can confirm this bug. First time I tried to save selected part of the file, not to delete selected part.

I tried test 1, 2, 3 & 4. All have same problem.

Posted by: rfmmars Oct 24 2007, 11:37 PM

QUOTE (fccHandler @ Oct 24 2007, 05:14 PM)

I can reproduce this too, with 1.7.X test4. It doesn't happen in 1.7.6.

EDIT: XYZ, same time post!

You don't need to do anything special. Just open any AVI and delete the first hundred or so frames.

fccHandler,
Yes I tried it on three other workstations with the same results. I even made a divx file, no change, thank for taking the time to reproduce the problem.

XYZ, I am not doing double talk, there was a problem with displaying "ffdshow Mjpeg", thats why I mention it,its fixed. The Mpeg2 file was brough up since it was a I frame only. So how did you get a "divx" to edit since I have the same problem with the Divx made off of the mpeg2 file?

The easy way to test is to delete the first scene, you will see that it deletes the correct number of frames but the scene is still there.

I am sure all of us want to help the author build the best mouse trap. He and I don't always see "eye to eye" but I am always on his side.

I never post without triple checking the problem out to make sure its not my cockpit error.

Richard

Posted by: phaeron Oct 25 2007, 05:52 AM

The cutting issue turned out to be a simple problem. Amusingly, I couldn't figure out what was wrong at first -- because I had expected the output to be wrong, but it was only the preview that was wrong. I broke it when I added the frame rate change support to the video filter API; specifically, it's wrong when you have no video filters. The rendered output is always correct.

Fixed versions:
http://www.virtualdub.org/beta/VirtualDub-1.7.X-test5.zip
http://www.virtualdub.org/beta/VirtualDub-1.7.X-test5-AMD64.zip
http://www.virtualdub.org/beta/VirtualDub-1.7.X-test5-src.7z

I couldn't reproduce any problems with the frameserver -- I ran the 1.7.X setup program with the 1.7.X DLLs, and it seemed to work OK. Only thing I can think of: do remember to run it as an administrator (run elevated under Vista).

As for the frame rate on join issue, what's happening is that you can't actually enter in the frame rate that you need. Frame rates in AVI are stored as a ratio of two numbers, which allows it to exactly represent several important frame rates. The 23.976 fps that you have is most likely 24000/1001. The frame rate dialog only allows decimal frame rates. I modified the frame rate adjust field with fraction support code, but I haven't gotten to doing that for the convert section yet. There are two ways you can hit this frame rate exactly: you can either do a second pass with the frame rate adjust field having the exact fraction, or you can save a config file and edit it directly, as the underlying engine does support arbitrary fractions for the frame rate conversion target and it's only the UI that doesn't.

Posted by: XYZ Oct 25 2007, 08:10 AM

phaeron, you missed a point of my post.

1. Your compare code in appending routine is too sensitive.

2. Two another software have not any problem appending files. VirtualDub has it.

This is not a problem to me. I know solution how to avoid this using another software. This is a problem for beginners, as it is mentioned on videohelp site. This a problem for you, because you will receive same complaining in the future.

Sorry if I was annoying. I just wanted to help, but if you don't want this, it is alright to me.

Posted by: rfmmars Oct 26 2007, 01:06 AM

So far no problems with 1.7x test 5

Richard

Posted by: phaeron Oct 26 2007, 03:38 AM

QUOTE (XYZ @ Oct 25 2007, 01:10 AM)

I didn't have a problem with your earlier post, but I do with this one. Drop the attitude. You want to talk technical issues, that's great. Don't get pissed off when I don't answer exactly how you expect. You reported a problem, I replied with the technical explanation of what's going on. I don't need a lecture about how to manage my development.

Posted by: fccHandler Oct 26 2007, 09:08 PM

phaeron:

I have a strange problem with my WMV plugin, and I've been struggling with it for days now. I don't know if it's the plugin or VirtualDub, but I believe the plugin is doing everything right. I've put together a repro case with my latest (not yet released) WMV plugin, although it happens with the released version too:

http://fcchandler.home.comcast.net/repro.zip (5.52 MB)

To repro:
- Put WMV.vdplugin in the plugins32 folder
- Start VirtualDub (1.7.6 or 1.7.X)
- Open the "portland" clip
- Press "output playback"

When I do this, the audio stutters badly. Yet it only seems to happen if I play it from the first frame, with all settings at default. And it may be my imagination, but it seems to get better, then worse, in parallel with the complexity of the audio as it plays.

I'm seeing this with a lot of my low bitrate WMVs, some are even worse than this one. Lots of things affect it too. If I begin "output playback" from the second keyframe, everything is fine. If I switch audio to "Full Processing Mode," it helps in some cases. Increasing the Audio / Interleaving / Preload value often helps too. I hope you can repro...

Can you offer any insight about what is happening, and whether it's fixable? I suspect it has something to do with low bitrate WMA in general. My WMV audio source returns IsVBR() = true.

Posted by: heustess Oct 28 2007, 05:03 AM

@fccHandler:

Please don't take offense, but I know that you are working hard to get the audio skew info exactly right. I tested 17 non-zero skew vobs with the old vStrip program. vStrip reported the skew (delay) on each 1 more than your mpeg-2 plugin did. For example when your plugin reports a delay of -206, vStrip reports a delay of -207. Hopefully this means that you are 1 more accurate than vStrip. I thought you might find this of interest.

EDIT: VirtualDub-MPEG2 1.6.19 reports the exact same audio skew (delay) values as vStrip for the 17 vobs.

Posted by: fccHandler Oct 28 2007, 11:59 PM

It's a rounding bug. When the skew is negative, the MPEG-2 plugin will be off-by-one 50% of the time. Thanks for pointing it out; I'll fix it in the next release.

Posted by: phaeron Oct 29 2007, 08:16 AM

The reason for the playback stuttering is that VirtualDub is unable to correctly determine the local bitrate of the VBR stream, and the audio playback buffer either hits an overflow or underflow condition. This is a side effect of having preview bolted on the side of the rendering engine -- the interleaver is still active. If you change the audio mode to full processing mode, the variable bitrate nature is stripped out prior to that point and things work. It shouldn't actually affect the data written out in either case, although it will affect interleaving in the direct case (which won't work well anyway).

This was one of the things that took me a while to fix for the internal plugins in 1.7.X, which I eventually did by adding an additional VBR mode -- true VBR, versus 1.7.6's psuedo VBR -- and changing the audio playback timing code to use timestamps instead of samples. True VBR mode is not exposed in the plugin API yet, unfortunately, but it's something I plan to add (has to wait until at least next weekend, I guess :-/ ). I might also be able to work around the issue also by making more use of the VBR time-to-position and position-to-time conversion functions -- might not be a bad idea anyway, as it would also improve interleaving for the psuedo VBR case.

Posted by: XYZ Oct 30 2007, 01:54 AM

I am sorry, I didn't wanted to sound harsh and impertinent. I already decided to leave this forum because my posts are misinterpreted, maybe because of my lack of English. I have just one additional note about different approaches of several software for appending files, if you don't mind. I extracted only video streams checking:

1. VirtualDub\source\AVIReadHandler.cpp - AVIReadHandler::AppendFile

CODE

if (fccOld != fccNew)

if ((sint64)pasn_old->hdr.dwScale * pasn_new->hdr.dwRate != (sint64)pasn_new->hdr.dwScale * pasn_old->hdr.dwRate)

if (pasn_old->hdr.dwSampleSize != pasn_new->hdr.dwSampleSize)

if (hdr1.biWidth != hdr2.biWidth || hdr1.biHeight != hdr2.biHeight)

if (hdr1.biCompression != hdr2.biCompression)

I put here VirtualDub's lines of code only for better comparation.

2. AVIMux_GUI\AVIMux_GUIDlg_AddFileList.cpp - CAVIMux_GUIDlg::OnAddFileList

CODE

// check if number of streams is the same
if (a1->GetNbrOfStreams() != a2->GetNbrOfStreams())

// check if video resolution is the same
if (dwX[0] != dwX[1] || dwY[0] != dwY[1])

// check if video compression formats are the same
if (a1->GetFormatTag(0) != a2->GetFormatTag(0)) {

// check if framerate is the same. If it is not, only MKV output is possible
if (!bVFR && fabs((double)a1->GetNanoSecPerFrame() - (double)a2->GetNanoSecPerFrame()) > 1000)

In AVI-Mux GUI there is similar check for the number of streams, video resolution and the type of compression as it is in VirtualDub, but frame rate is calculated as double type and rounded to microseconds per frame. There is not a check for SampleSize.

3. avidemux\ADM_editor\ADM_edit.cpp - ADM_Composer::addFile

CODE

/* check for resolution */
if( info0.width != infox.width || info0.height != infox.height )

In Avidemux there is no check for the number of streams (you could try to append files with one and two audio streams, but second part of the resulting AVI will be bad)! There is no frame rate check (you can mix 25 and 12.5 fps without a problem, frame rate of the appended file is converted to the frame rate of the first file). There is no check for a type of compression (you can try to mix XviD and Indeo or even MPEG2, but second part of the resulting AVI will be bad)! Copy mode and Smart Copy are used, which is another way to get the smart rendering.

I am not saying that some approach is better or not. Especially, I don't want to say that VirtualDub is doing badly. I already said that VirtualDub is great software and I like it very much. As I said, I just wanted to help in some way to get it even better. But, never mind. I'd not disturbing you anymore.

Posted by: olnima Oct 30 2007, 09:15 AM

@XYZ:
I don't know if I get You right but what is the point to combine two avi-segments if the 2nd part of the avi is bad?
I like it more the existing way - means if VD let me append an avi-segment I can be shure that the resulting avi is good and usable.

greetz
Olnima

Posted by: and22 Oct 30 2007, 09:38 AM

I have problems with 1.7.X test5. When I use curve editor, effect is sometimes applied several hundreds frames earlier (or later) and not at current frame as expected. Moreover, when I save settings from File menu, quit VD, run VD and load settings again, curve settings do not work. I tested that with Delogo filter but I think that is a common problem. Those don't happen in 1.7.6.

to phaeron:
First, thank you for implementing preview in several of your internal filters (I asked you of that some time ago) - it's much easier to work with them now. I could not do that earlier as for unknown reason my registration on this forum was removed (as well as all my posts) and today only I registed again.
Second, as for curve editor, - color of vertical lines in curve editor (which indicate each separate frame) is very close to black color of background. As I often work frame by frame it's very important to see each frame but now it's very difficult. Is it possible if you make color of those frame lines little bit brighter?

And last. When saving settings, size of input and output panels is not saved. Because of that one has adjust them every time he starts VDub again. Will it be difficult for you to implement such feature as saving size (scale) of input and output panels in *.vdf file f.e.?

Posted by: XYZ Oct 30 2007, 12:18 PM

QUOTE (olnima @ Oct 30 2007, 09:15 AM)

I don't know if I get You right but what is the point to combine two avi-segments if the 2nd part of the avi is bad?
I like it more the existing way - means if VD let me append an avi-segment I can be shure that the resulting avi is good and usable.

I decided not to actively participate in this forum anymore, but if you ask me a question, I suppose that you want an answer from me. I think if you read my posts in this thread from the beginning that you could find an answer, but it is not hard for me to repeat.

1. I have two AVI files which I want to append. These AVIs are parts of the same AVI file which was previously splited in Direct stream copy. I want just opposite - to append this two parts into one AVI file. VirtualDub refuses that, other two mentioned software don't. Resulting AVI file appended by this two software is not bad at all, it plays perfectly. Reported difference by VirtualDub because it refuses to append AVI files is very small (24001 bytes/sec vs. 24000 bytes/sec).

2. After reading post on videohelp, I decided to reproduce mentioned problem. I described what I did in every detail. Please, try by yourself and you will see a same error message of VirtualDub when you try to append such files. Same as previous - resulting AVI file which is appended by another two software is not bad, it plays perfectly. Again, reported difference is very small (23.97602 vs. 23.97600 samples per sec).

You are right, I don't want to get bad AVIs either. But, these two situations has nothing similar with my last post. Avidemux could append AVI files without almost any checking. I tried to append two AVI files with different number of audio streams and different video formats just for experiment, not because I need such thing.

Maybe you are wondering why some video software has something like this. It is obvious, and has a name "Smart rendering" or "Smart copy" as is its name in Avidemux. It is another story why this "Smart copy" don't works as it should in Avidemux. But tell me, wouldn't be great if video software could append two AVI files recompressing only needed parts and not complaining about its formats? I already posted suggestion about that in this thread:
http://forums.virtualdub.org/index.php?act=ST&f=11&t=14731

Posted by: neuron2 Oct 30 2007, 01:02 PM

Posted by: dchrbv Nov 2 2007, 06:58 AM

HI

It's my first post in this forum.
I usually only read other posts, but the reason for writing this is that I agree with XYZ regarding the "problem" he is describing. I casually use virtualdub (since a ..long... while) to join multiple avi files and have noticed that the program would not join avi files with a difference of only 0.0000x frames, even it produced the files itself in a batch process, with exactly the same settings. I download every time a new version in the hope phaeron implements something like a "are you sure" dialog with permits a join even if the program detects this difference. This would be a nice addition, because just of the lack of this function, I have to seek for another program for joining, but none is so easy to use and trustworthy in the output like virtualdub.
The last time I saw this problem was after converting in batch some identical wmv files, wchich I've just transformed into avi (divx) using fccHandler WMV plugin. Even if virtualdub says that every single frame has a frame rate of 29.97000 when loading individual files, it won't load the next file because it reports that the appended file has a 29,96900 frame rate.

Thank you

Posted by: phaeron Nov 2 2007, 05:36 PM

QUOTE (dchrbv @ Nov 1 2007, 11:58 PM)

Even if virtualdub says that every single frame has a frame rate of 29.97000 when loading individual files, it won't load the next file because it reports that the appended file has a 29,96900 frame rate.

This sounds like a different problem -- irregardless of how strict the append is, it shouldn't be reporting a different frame rate. Do you have a reproducible case for this?

Posted by: dchrbv Nov 2 2007, 09:58 PM

The problem I've described earlier was produced with Virtualdub 1.7.6 and 1.7.x and WMV plugin 1.3. I have updated the WMV plugin to 1.4 and I can't save the avi file anymore without resizing it - the source WMV file has a 720x540 pixel size - error message is "The source image format is not acceptable (error code -2)". I don't think this is related with what I said earlier.
Previously (with 1.3 plugin) I could save the file directly, without resizing, but the target avi did have a 640x480 pixel size (I didn't insert a resize filter), and that were the files I couldn't join. If I now apply a resize filter it works - and the joined file is OK.
What I meant is exactly what XYZ described (it would be a nice feature, if tehnically possible) - the posibility to choose wherther to continue or not the joining due to such a small difference in frame rate. I will search this weekend for older files with which I've had in the past the mentioned problem of recoding and not joining - what I usually I do is to convert multiple files to a common sampling avi and join them - I like the easy way in Virtualdub to quickly remove unwanted overlapping frames.
I hope I've made myself clear - I'm only a casual English speaker

Posted by: squid_80 Nov 18 2007, 02:50 AM

Is it expected behaviour for timeline edits to not affect the audio if it's an external source (loaded via "Audio from other file")? Even if the source is loaded before the edits are applied?

Edit: Never mind, too many late nights, didn't realize audio from other source was staying active when I switched files.

Posted by: squid_80 Nov 18 2007, 10:22 AM

Ok, a real bug this time: load a video, add a filter that changes the framecount/framerate (such as ela doubler), add another filter and open the cropping dialog for that filter. The cropping dialog timeline only shows the original number of frames.

Posted by: squid_80 Nov 18 2007, 11:02 AM

QUOTE (phaeron @ Oct 21 2007, 11:59 AM)

V1.7.X test-1 introduced an additional overload of audio.SetSource() to allow the input driver to be specified. This is necessary in case you have a file that can be read by multiple input drivers and you force a specific one in the file dialog. This wasn't necessary in earlier versions because only the WAV driver was ever used. The 1.7.6 one-argument syntax is still supported, but it auto-selects the best available input driver for the file.

This doesn't seem to work; saving the processing settings does indeed write out virtualdub.audio.setsource("file", "") but when trying to load the .vcf it throws an error: Overloaded method SetSource(string, string) not found.

I removed the else { } clause from around mAudioInputDriverName = pSelectedDriver->GetSignatureName() in VDProject::OpenWAV (project.cpp) and added another overload for func_VDAudio_SetSourceExternal (args "0ss") in script.cpp and that seems to fix it.

Posted by: Fizick Nov 19 2007, 08:06 PM

dchrbv,
abcAVI Tag Editor allows changing of FourCC video codec signatures, AVI frame rate (playback speed) and video frame size.
http://abcavi.kibi.ru/

Posted by: phaeron Nov 20 2007, 07:52 AM

QUOTE (squid_80 @ Nov 18 2007, 04:02 AM)

Damn, that was stupid. For that, I owe you a test build.

http://www.virtualdub.org/beta/VirtualDub-1.7.X-test6.zip
http://www.virtualdub.org/beta/VirtualDub-1.7.X-test6-AMD64.zip
http://www.virtualdub.org/beta/VirtualDub-1.7.X-test6-src.7z

Changing project.cpp actually isn't the fix I went with... what's supposed to happen is that if you choose autoselect when opening the file, it still chooses autoselect in the job. This means that by default if you use a plugin to create a job and that plugin goes away, VirtualDub can still open the wave file with a different one. Not sure it matters much, but that's at least what the video side does.

Good catch on the cropping dialog w/ frame rate change bug... guess I might as well rewrite that dialog too. In case you don't know, writing raw Win32 UI really sucks, and I'm not one to use UI toolkits, partly because I think most of them suck almost as much as bare Win32. That's a rant for a blog entry, though (because I blog oh so much).

Veedub Time™ has been a bit scattered, so thus has been the work, but a few things in this build:

The filter list dialog has been rewritten and now allows individual entries to be temporarily enabled or disabled. I also replaced the listbox with some autosizing list view goodness.
Did some work on the MP3 input code to make it more robust (damn layer I free form), and also fixed a stupid mistake where I accidentally disabled optimization on the decoder code. I did a little optimization on it too, and then went back and fixed the stuff I broke when I optimized it.
I adapted the pitch scaler code and wrote a new time stretch filter. The pitch scaler was actually a time stretcher with a crappy bilinear resampler on the end to correct the time length; this mainly just rips that off, so it does what people actually want in practice with better quality and a little less hassle.
The stretch audio filter, along with the new time stretch filter, now use much higher internal stepping precision and allow many more digits to be entered in the configuration dialog.
A few commands can be used during preview, most notably dragging the time bar and the mark-in/mark-out commands. This doesn't work as well as I'd like, since I'm pretty restricted in what I can allow due to threading issues -- in particular, hitting mark-in/out actually causes the preview to stop and restart, and it's a little off right now... but I'm seeing if someone finds it useful as-is, since it was requested.
Plugins can now export true VBR audio. I hadn't gotten a chance to actually try this and it's not documented, but you can find the new interfaces if you dig into src/h/vd2/plugin/vdinputplugin.h. You have to implement an AsInterface() query to the new interfaces and then set the magic flag that indicates the new (er, old) scheme for returning VBR samples. The new interfaces and structs aren't final yet, so don't ship production plugins that export them....
I fixed a bug in the 128-bit integer multiply routines that I happened to find while screwing around with fast division. I don't think this actually affected anything, which is why it's not in the change list, although in theory it might have affected audio resampler accuracy slightly in capture mode if you were doing a really long capture. The bug's in carry propagation out of one of the high bytes, so it'd be pretty hard to hit.

I did a little work on allowing plugins to delegate video decoding to VirtualDub, but there's a mess in VideoSource.cpp I have to clean up first, so nothing visible yet. I intend for that to get into 1.7.X before ship.

Looking at 1.7.7, there's not much on the pile, but I might try pushing it out some time this weekend. Given the relatively slow rate of check-ins into that branch, I'm thinking that 1.7.X might become 1.7.8.

Posted by: rfmmars Nov 27 2007, 01:15 AM

I have long waited for the ability to turn off and on a filter, and thats works great. However you can never edit in the filter again, double clicking doesn't do anything. You can delete the filter and bring it in again but can adjust it only one time.

1.7x-6

Richard

Posted by: squid_80 Nov 27 2007, 01:17 AM

Can't you use the configure button?

Posted by: rfmmars Nov 27 2007, 01:47 AM

Yes but I never had to do that before...........much faster to double click on each filter when editing.

Richard

Posted by: phaeron Nov 27 2007, 05:45 AM

Ah, just a little bug introduced when I swapped out the listbox for a listview -- will be fixed in next drop.

Posted by: DarrellS Dec 15 2007, 02:56 PM

Any chance of adding the script editer that VirtualdubMod uses? This is a very usefull tool.

Posted by: phaeron Dec 26 2007, 05:45 AM

Merry Christmas! Or Happy Festivus, or Wintereen-mas, or whatever you celebrate.

Quick update for the holidays:

http://www.virtualdub.org/beta/VirtualDub-1.7.X-test7.zip
http://www.virtualdub.org/beta/VirtualDub-1.7.X-test7-AMD64.zip
http://www.virtualdub.org/beta/VirtualDub-1.7.X-test7-src.7z

The big update this time is that this release provides support for direct YCbCr filtering. Filters can choose to support formats other than RGB32 (and not necessarily including RGB32), and the filter system will automatically convert as needed to accommodate this. You can see this if you add the "resize" filter, which has been updated to support direct YCbCr resampling. If you change the input color format to 4:2:0 planar YCbCr and then enable the new "show formats" option in the filter list, it will show (YV12) on input and output to the resize filter. Turn on the interlaced mode, and the resize filter will force its input to YV24. This also works in capture mode, which has a new option to use the output format from the filter chain rather than always forcing 24-bit.

I had to rewrite the resampler fairly significantly to support planar YCbCr, so I wouldn't be surprised if there were a bug or two lurking. The AMD64 build in particular may be completely broken -- I haven't had a chance to test it. I also did some optimizations on the YCbCr-to-RGB conversion path, but those do have unit tests.

No official docs or SDK updates are available yet for the new filtering support, although I'm working on trying to update the old video filter docs and integrate them into the plugin SDK. You'll have to pull the headers from the source code right now (src\h\vd2\plugin\vdvideofiltold.h) if you want to experiment. The primary additions are new mpPixmap/mpPixmapLayout fields in the fa->src and fa->dst fields, and new FILTERPARAM_NOT_SUPPORTED and FILTERPARAM_SUPPORTS_ALTFORMATS constants for paramProc. Existing filters that don't return FILTERPARAM_SUPPORTS_ALTFORMATS will continue to work, but VirtualDub will force a conversion to RGB32 on entry to the filter. If anyone wants to experiment, let me know and I can supply preliminary docs.

Additional notes:

Double-click bug in video filter list is fixed.
BI_BITFIELDS decoding is now done internally (in case anyone cares....)
Input plugins can now defer video codec selection to VirtualDub. The mechanism is fairly simple: return NULL/false from CreateVideoDecoder(). Plugins can optionally implement IVDXStreamSourceV3 to provide a preferred codec fccHandler value.
Removed the VBR-in-AVI warning.
Added support for non-standard 15 fps MPEG-1 videos.

1.7.X has been in testing phase for a bit too long, so I'm likely going to try to go for a feature freeze so I can stabilize things for a release.

Posted by: Barough Dec 26 2007, 09:18 AM

Thnx 4 the new test version phaeron.

Just a little question........ have the support for CBR MP3's been enabled yet?

Posted by: phaeron Dec 26 2007, 08:22 PM

Oops, no. I'd better work on that.

Posted by: Barough Dec 26 2007, 08:26 PM

QUOTE (phaeron @ Dec 26 2007, 09:22 PM)

Oops, no. I'd better work on that.

Posted by: blob2500 Dec 28 2007, 02:28 AM

Thanks phaeron for this test version

In the next version will be add also the support to import MP3 (CBR/VBR) audio with sample rate lower 32kHz?

Posted by: phaeron Dec 28 2007, 07:35 AM

Current dev tree version now has explicit CBR/VBR control, may poop out another build soon. Working on the video filter portion of the plugin SDK right now, although writing docs takes sooooooooo long!

I'm not aware of current versions having an issue with audio below 32KHz. Such audio streams are actually use the MPEG-2 LSF (low sampling frequency) extension, and I did have some bugs initially with processing those streams, but they should have been fixed a while ago. If you've still got an audio clip that doesn't work properly, I can take a look at it and try to fix the problem.

Posted by: Barough Dec 28 2007, 02:28 PM

Thnx 4 the info. Looking forward 2 a new Build.

Posted by: blob2500 Dec 28 2007, 03:36 PM

Thank you Phaeron for reply

I have problem with any MPEG-2 audio imported and muxed. I watched AVI file output in MediaPlayerClassic and some other players too, but it don't seek audio properly.

IMHO, I think the problem is in the muxing with imported audio: I think if audio is an MPEG-2 layer 3 and nBlockAlign=1152 then two audio frames (576 samples x 2 = 1152) per AVI chunk are necessary to be set accordingly with nBlockAlign and dwScale values, in "muxing as VBR" (instead one frame per chunk , for MPEG-1 VBR audio) .

With VDubMod I have not this problem, but it sets 1 frame audio per chunk and nBlockAlign=576 accordingly. But I'm not sure if these are the bests values for MPEG-2 layer 3 VBR audio in AVI.

Excuse me if my english is not good...

Posted by: phaeron Dec 28 2007, 09:13 PM

Mmm, no, it doesn't work that way.

For VBR audio to work, nBlockAlign doesn't have to be set to either 1152 or 576. It only has to be set to a value that is greater than the largest audio frame. The reason that 1152 and 576 are convenient is that it makes the frames per second fraction exact for MPEG audio, i.e. 48000/1152. In fact, always choosing 1152 or 576 can actually break the scheme because there are rare combinations of sampling rate and bit rate that can cause audio frames to exceed those values.

I'll make some LSF files and test it again. It's probably just a bug in the code that sets dwRate -- that value needs to receive the same multiplier as nBlockAlign.

Updated:

Well, that was interesting. Almost thought I'd had it until I ran into the quirk that is MPEG-2 layer II audio.

New version:
http://www.virtualdub.org/beta/VirtualDub-1.7.X-test8.zip
http://www.virtualdub.org/beta/VirtualDub-1.7.X-test8-AMD64.zip
http://www.virtualdub.org/beta/VirtualDub-1.7.X-test8-src.7z

A new dialog now appears when importing MP3 audio, allowing selection between VBR and CBR. This version also has a /capfilealloc switch for preallocation on the command line.

Posted by: Barough Dec 29 2007, 08:02 AM

Thnx 4 the new Test Build. Will have a look on it l8r 2day

Posted by: blob2500 Dec 29 2007, 10:59 AM

Thanks phaeron for info and the new test build

Posted by: Barough Dec 29 2007, 11:51 AM

Just did a couple of quick tests and muxing a xvid video with a CBR MP3 stream works just gr8. No issues @ all. But muxing a xvid video with VBR MP3 stream doesn't work. The result is that the audio sounds like crap. The original audio stream is just fine.

[EDIT]
Doesn't make any different if i use the Auto function or setting if it to VBR manually in the dialog

Posted by: phaeron Dec 29 2007, 09:44 PM

Do you have any details on the source MP3, or a sample I can check?

Posted by: Barough Dec 29 2007, 09:47 PM

QUOTE (phaeron @ Dec 29 2007, 10:44 PM)

Do you have any details on the source MP3, or a sample I can check?

I can upload the file to FileFactory 4 ya

[EDIT]
Here's the VBR MP3 file
http://www.filefactory.com/file/670ebc/

Also when muxing in a VBR stream so is there no audio value size in the Status Window

Posted by: phaeron Dec 30 2007, 09:32 PM

Alright, I muxed in the mp3 file with test-8, and the only thing I saw that went wrong is stuttering during preview with audio in direct mode. Full processing mode works OK. I don't see what's wrong here, besides the preview stuttering. What exactly were you seeing?

Posted by: Barough Dec 30 2007, 11:03 PM

It seems like it's the latest VLC that dont like this file for some reason. VLC have worked just fine here without any issues earlier. This file plays perfectly in the latest Media Player Classic and Gom Player.

In VLC so did the audio stutter the whole time when i tried the file that have the VBR MP3 audio stream. The other file that have a CBR MP3 audio stream plays perfectly.

Both these files was created through Direct Stream Copy.

[EDIT-1]
I just muxed the 'problematic' files in VDubMod & AVI-Mux GUI and the output file in both cases plays perfectly in VLC. Will prepare another set of files and test 'em in Test 8

[EDIT-2]
Gave the new set of file the same procedure and the result was exactly the same.

CBR Mux
Audio Size is displayed in the Status Window
user posted image

VBR Mux
Audio Size is NOT displayed in the Status Window
user posted image

In my opinion so is something weird going with v1.7.x when muxing in a VBR MP3 stream

Posted by: pintcat Dec 31 2007, 12:36 AM

I've checked VDub 1.7.X-test8 a bit (thank you so much for this one!) and found a little odd behavior in the cropping mode: When I try to crop a picture (no matter which filter I use or which type of video is loaded), the cropping bars don't remove parts of the picture, but they resize it in the particular direction. After closing the cropping and filter window the frame remains at the same size as before, but the picture is completely deformed!

Posted by: phaeron Dec 31 2007, 09:18 AM

http://www.virtualdub.org/beta/VirtualDub-1.7.X-test9.zip
http://www.virtualdub.org/beta/VirtualDub-1.7.X-test9-AMD64.zip
http://www.virtualdub.org/beta/VirtualDub-1.7.X-test9-src.7z

Two separate issues... the 0 bytes in the status window was a tiny buglet, while the VLC issue was something else. For the technically curious, the issue is that VideoLAN doesn't interpret dwSampleSize in an audio stream the same way as DirectShow -- it interprets it the "pure" way as dwSampleSize=0 means VBR, whereas Microsoft's AVI parsers always ignore dwSampleSize for audio streams. I was setting it to nBlockAlign, and changing that to 0 fixed the incompatibility. Not really optimal for the VLC guys to have their player interpreting that field differently than DirectShow, though.

I also fixed the cropping display issue, which was related to cropping with YCbCr input, but vertical cropping is still broken in that case and I need to take a look at that. I'm more worried by the realization that the input format can invisibly affect the cropping -- if you're in YV12 it can still crop, but only to 2x2 precision. I wonder if I should have an option to force a finely croppable format (RGB32 or 4:4:4 YCbCr) or have a visible warning on the crop dialog.

Posted by: Barough Dec 31 2007, 10:44 AM

Just had a quick test of the new Build and it works gr8 now. Thnx

Posted by: blob2500 Dec 31 2007, 12:50 PM

Thanks phaeron for this fix. AVI with VBR didn't work on my standalone dvd player if dwSampleSize is not "0". It works now

Posted by: kewl Jan 1 2008, 01:23 AM

What is striking is that everything is developed by yourself with no call to 3rd party code.
Phaeron thanks for this great improvements and congrats!

Posted by: Barough Jan 2 2008, 06:36 AM

@ phaeron

Do u think it will be long b4 we see a new stable release?

Posted by: phaeron Jan 2 2008, 10:17 PM

Well, that's an interesting question.

1.7.8 only has two fixes queued up at the moment, both of which are for capture mode. One of them is fairly big (memory corruption after error), but not really enough for me to push out at the moment. 1.7.X is basically feature-complete at the moment, but I couldn't push that out as stable. So, basically, right now it looks like 1.7.X will become either 1.7.8/experimental or 1.8.0/experimental (probably the latter, given how much has gone into it). 1.8.1 would then be the first opportunity for 1.7.X features to hit a stable branch.

What do people here think? Anyone still seeing new bugs in 1.7.X they want squashed?

Posted by: Barough Jan 3 2008, 02:56 AM

Thnx for your reply.
With all the new features in it so does a v1.8.0/Experimental Release sounds best me @ the current time. So my vote is that v1.8.1 will be a Stable release.

Posted by: squid_80 Jan 3 2008, 03:23 AM

QUOTE (phaeron @ Jan 3 2008, 08:17 AM)

What do people here think? Anyone still seeing new bugs in 1.7.X they want squashed?

The cropping dialog still doesn't like framerate changes. Also it doesn't respect timeline edits, which is a bit of a pain.

Posted by: phaeron Jan 3 2008, 05:28 AM

http://www.virtualdub.org/beta/VirtualDub-1.7.X-test10.zip
http://www.virtualdub.org/beta/VirtualDub-1.7.X-test10-AMD64.zip
http://www.virtualdub.org/beta/VirtualDub-1.7.X-test10-src.7z

Fixes the vertical YCbCr cropping bug and framerate related issues in the cropping dialog. Still doesn't respect timeline edits, but I might have to push on that one -- it's not easy to fix, since in order to do so I have to attempt to propagate the edit list backwards to the beginning of the filter entry, taking account any frame rate changes in between... ugh.

Posted by: squid_80 Jan 3 2008, 09:07 AM

Fair 'nuff then, as long as one of the two is fixed I'm happy. Both of them combined meant I couldn't actually scroll to the section of the video I was working on when trying to crop.

Posted by: kewl Jan 5 2008, 11:59 PM

I agree Phearon let's go with the 1.8.0 experimental, you'll also get more feedback and bug reporting. This is such a powerful release it is worth an experimental release rather than waiting for the remaining issues to be all cleared.

Posted by: T&T Jan 6 2008, 02:25 PM

Dear Phareon,

I have tested the /capfilealloc argument added in 1.7.X.test10. I think it is not working properly.

In 1.7.7 if I set this option manually the output file size become the given size, during capturing the system load is cca. 30-40% and at the end the file size become the size of the captured bytes.

In 1.7.X.test10 if I set /capfilealloc argument in command line it works contraverted. The file size is growing (not preset to the given value), the system load is 60-70% (as it would be if this parameter is not set) and at the end the file size become the preset value. Even if I capture a 30 s film the file become 18 000 MB as I added to /capfilesize.

Good byte!

TT

Posted by: phaeron Jan 7 2008, 08:38 PM

Hmm, seems to work for me. This allocates a 10MB capture file and then captures with it:

CODE

vdub /capture /capfile e:\test.avi /capfilealloc 10 /capdevice screen /capstart 1s /x

Did you place the /capfilealloc switch after /capfile?

Posted by: T&T Jan 8 2008, 09:00 AM

Dear Phareon,

no! I did something like this:

CODE

VirtualDub.exe /capture /capfile test.avi /capstart 50s /x /capfilealloc 1000

and later

CODE

VirtualDub.exe /capture /capfile test.avi /capstart 50s /capfilealloc 1000 /x

I'll try to put the /capfilealloc right after the /capfile option as You have written...

THX!

TT

Posted by: T&T Jan 8 2008, 11:06 PM

Hi,

I've tested what You suggested:

CODE

'/cygdrive/c/Program Files/VirtualDub_1_7_X_test10/VirtualDub.exe' /capture /capfile 'test.avi' /capfilealloc 1000 /capstart 52s /x

It really worked nicely concerning the file sizes. At first it allocated 1000 MB and at the end the file was cut to cca. 77 MB.

But there is a little problem. If I set the allocation size and stop condition manually then VDub uses 29-39% CPU. If I set them and start capturing automatically from command line it uses 55-62%. Even if I set the allocation size from command line and I set the stop condition manually it also uses the lower value.

This is misthical...

THX!

TT

Posted by: phaeron Jan 9 2008, 11:33 AM

Not that surprising. NTFS sucks and all, but 30% of a modern CPU is a bit much for the filesystem to be using.

Does the real-time profiler show anything obvious between capturing with and without preallocation? (It's in the Capture menu.)

Posted by: T&T Jan 10 2008, 10:15 AM

Dear Phareon,

QUOTE

NTFS sucks and all, but 30% of a modern CPU is a bit much for the filesystem to be using.

What I don't understand why there is difference if I set the preallocation size manually or from the command line.

QUOTE

Does the real-time profiler show anything obvious between capturing with and without preallocation? (It's in the Capture menu.)

I started real-time profiler during the capture, but I do not understand what I ought to see... :-) Can U drop me a link about some doc?

TIA && Good byte!

TT

Posted by: phaeron Jan 10 2008, 10:30 AM

QUOTE

What I don't understand why there is difference if I set the preallocation size manually or from the command line.

Neither do I. VirtualDub has special optimizations to reduce file allocation code during capture -- it grows the file 16MB at a time, and it uses an alternate call that bypasses pre-zeroing -- so this shouldn't be happening continuously anyway.

Do you have a virus scanner running? Have you tried adding AVI files in your capture folder to the exclusion list?

QUOTE

I started real-time profiler during the capture, but I do not understand what I ought to see... :-) Can U drop me a link about some doc?

You need to start it before the capture. It'll come up anyway if you start it during the capture, but it'll be missing information.

What the real-time profiler shows is snapshots of what VirtualDub is doing at different times. Different bars show up that mean different tasks that VirtualDub does during the capture. For example, V-Compress is video compression, and V-Filter is video filtering. There are markers showing divisions in milliseconds, and the longer the bars are, the more time a task is taking. This gives you an idea what's taking CPU time, or what's periodically taking too long and screwing up your capture.

What you're looking for is bars that only show up or are longer when you don't preallocate the file. A-Write and V-Write correspond to audio and video writes, respectively. The arrow keys change the resolution of the snapshot.

Posted by: squid_80 Jan 10 2008, 01:37 PM

I'm getting a crash when I try and direct stream copy an avi when the very first frame is a drop frame (stupid h264 in avi). I tried changing VDDubIOThread::ReadNullVideoFrame a bit:

CODE

VDRenderVideoPipeFrameInfo frameInfo;
frameInfo.mLength � = 0;
frameInfo.mDisplayFrame �= displayFrame;
frameInfo.mTimelineFrame = timelineFrame;
frameInfo.mSrcIndex � = sourceIndex;
frameInfo.mbFinal � = true;

if (displayFrame >= 0) {
�frameInfo.mRawFrame � = -1;
�frameInfo.mFlags � = (vsrc->isKey(displayFrame) ? 0 : kBufferFlagDelta);
�frameInfo.mDroptype � = vsrc->getDropType(displayFrame);
�// Following line has been moved from above
�frameInfo.mTargetFrame �= vsrc->displayToStreamOrder(displayFrame);
} else {

Now it saves the file without crashing, but the new file is nothing but drop frames.

Edit: Bold tags don't work in code sections on this forum.

Posted by: Barough Jan 16 2008, 06:15 PM

@ phaeron

Maybe a little progress report on how things r going?

Posted by: phaeron Jan 17 2008, 04:26 AM

Sorry, I was sick for over two weeks and also got sidetracked on a couple of things, so I'm afraid there's not much progress here.

Posted by: VladSh Jan 17 2008, 01:24 PM

Hello, I again concerning a audio stream plug-in "stretch".

Restriction on quantity of decimal signs is really removed.
But the plug-in works only in a stretching mode. To set a negative number for audiostream compression (for example 0.01 or -1.01) on it turns out.
Whether it is possible to add such possibility?

Whether it will be possible to supplement it?

Posted by: phaeron Jan 18 2008, 04:08 AM

Huh? The stretch value is a factor. A value of 0.01 means that you're asking the plugin to compress the audio to 1% of its original length, and -1.01 would be 101% in reverse if it were supported. To compress, you use a value between 0 and 1.

Posted by: Barough Jan 18 2008, 04:11 AM

QUOTE (phaeron @ Jan 17 2008, 05:26 AM)

Sorry, I was sick for over two weeks and also got sidetracked on a couple of things, so I'm afraid there's not much progress here.

Thnx for the reply. Hope that u get feel better and get back on ur feets soon.

Posted by: mariushudea Jan 19 2008, 10:47 AM

When compressing a movie, the text in the Perf tab in the Compression status doesn't seem right, it appears like this:

Optimizing for
Read mode
Video streaming enabled
Audio streaming

I also mentioned in the blog, if I have a sequence of images and at the open dialog I uncheck the Load linked segments, should Virtualdub still assume that I want all images loaded in sequence?

Create test video , RGB cube

Save as... XVID 800kbps chroma motion, high quality for b-frames, no audio ... at about 80% i checked Show decompressed output, the message that the display will appear at the next keyframe appeared, a keyframe passed at the output was not showed and after a few seconds Virtualdub crashed.

Probably related to the xvid patch mentioned a few pages before. Crashinfo.txt is here:
http://savedonthe.net/download/11/crashinfo.txt

The second attempt checked show decompressed output right at the start, after the first keyframe it showed frames for a few seconds then crashed again, output is here:

http://savedonthe.net/download/12/crashinfo.txt
1.7.2 - 28312/release

The last frame of any video on my computer is always blue (the overlay color?), even in test videos... is something wrong in my settings or this is by design?

For example, with the test video Create chroma subsampling, the bar at the bottom starts at 0 and the preview image says Frame 0 but when i scroll to the end , the final frame is 1000 and it's blue, although the movie has in total 1000 frames ( from 0 to 999). The text below the bar says Frame 1000 (0:00:33:367)

If I use Lagarith Lossless codec, and check show decompressed output, the decompressed video never shows even though all frames are keyframes (it's because it's vfw codec and not direct show?).

Posted by: squid_80 Jan 19 2008, 11:23 AM

Yep that's the show decompressed output vs. xvid crash. Perhaps you can confirm for Phaeron if it's fixed in http://www.virtualdub.org/beta/VirtualDub-1.7.8-test4.zip since I've been slack and haven't followed up on my own bug report.

That last frame isn't actually there, it's just a placeholder for the end of video. Something about cuts being endpoint exclusive if I remember rightly.

Posted by: mariushudea Jan 19 2008, 11:33 AM

Build 28322

Tried several times compressing with XVID the RGB cube.

Never crashed but also never showed the decompressed video output although there were several keyframes in the Video tab. Maximum i-frame interval is set to 250 in the xvid's configuration.

Correction: The video appears correctly after a keyframe is detected, but only if the "Show output video" is also checked.

Posted by: phaeron Jan 19 2008, 09:28 PM

Yes, the last frame is a one-after frame. If it weren't present, it would never be possible to include the last frame in a selection.

The fix in the test-4 build is working then? You do need "show output video" to be checked for decompression view to be visible, right now.

Posted by: mariushudea Jan 21 2008, 08:23 PM

Yes, test-4 fix works.

I've stumbled across http://www.4p8.com/eric.brasseur/gamma.html, it was submitted to Slashdot.

Out of curiosity, I tried resizing that picture of Dalai Lama from the page with Virtualdub using the Resize filter and indeed, the picture was all gray.

Does what this guy says apply to video as well? I'm not sure I really understood what he's talking about, I'd be really interested if you could give your feedback on this.

Posted by: phaeron Jan 21 2008, 10:42 PM

Yes, it does apply, and yes, VirtualDub does suffer from the same issue. However, there are a few points I should make on this subject.

First, the effect is much more subtle on actual imagery. The example given is an extreme case since it consists of an alternating checkerboard. It can be a problem on any sort of video, but I doubt you'd see the difference in practice, and there are much bigger transgressions generally involved in video processing, such as black/white levels and sloppy rounding.

Second, the error depends on the color space used to encode the video. If you're really concerned about linear vs. gamma space you would not want the resampler to be handling this problem -- you would want to convert from gamma space into linear space at the start of the rendering pipeline and keep it there until the very end. All linear filters will exhibit this issue, including blurs and sharpens.

Third -- and this is the ugly problem -- 8-bit per channel is nowhere near enough precision to handle conversions between linear space and gamma space. Jim Blinn has a nice article in his Dirty Pixels book where he shows that in order to maintain full 8-bit precision in gamma=2.0 space you need 17 bits in linear space. To properly switch to a linear space you thus need at least 96 bits/pixel. This is beyond the ability of most fast video processing libraries and imposes serious performance penalties.

Bilinear vs. bicubic resampling is a similar issue, really. Mathematically bicubic is far superior, and there are corner cases where bicubic is visually superior, such as gradient determination. For most video, though, the visual difference between bilinear and bicubic is minor and nowhere near that of bilinear vs. point sampling.

Posted by: phaeron Jan 27 2008, 04:03 AM

New version posted:

http://www.virtualdub.org/beta/VirtualDub-1.8.0-test1.zip
http://www.virtualdub.org/beta/VirtualDub-1.8.0-test1-AMD64.zip
http://www.virtualdub.org/beta/VirtualDub-1.8.0-test1-src.7z

This is the first release candidate for 1.8.0/experimental.

Changes in this version:

Merged in fixes from 1.7.8 (which isn't out yet, but will probably go out soon).
I fixed a nasty bug where doing edits in direct mode and saving only part of the timeline via selection could result in excess frames pushed back in by the rendering engine. (Basically, it's using the wrong frame number to determine where frames have to be added back in, so it adds in more than are necessary to satisfy key frame restrictions.) I considered fixing this for 1.7.8, but punted because it became too risky and it's been in there for a while, so the fix will go out first in 1.8.0.
Fixed some bugs regarding preview and filters that change frame rates.
Merged ela doubler and ela doubler 2 filters into bob doubler and added config settings for field polarity.
Filter cropping now has fast and precise modes. Fast mode has the same behavior as the previous test build in that it will round off the cropping bounds depending on the incoming format; precise mode will instead automatically perform a format conversion as necessary, always doing the exact crop requested. For instance, if the incoming video is YV12, the filter engine may convert it to either YV16 or YV24 in order to do the crop. The default is precise mode.
squid_80's direct mode null frame crash is fixed.
Fixed slight delays when starting renders in command-line mode.

All feedback welcome.

One bug that isn't fixed in this version is that if you have a filter that changes the frame count, input preview doesn't work. In fact, any video mode other than full processing mode may reference the wrong frames. The reason is that I painted myself into a corner by making the timeline use post-filtered frames, which is incorrect when a filter is altering the frame translation. I thought long and hard about this and came to the conclusion that post-filtered frames are the way to go, because otherwise frame-doubling filters are annoying to use, but I need to do enough work to fix this problem that I think it'll have to wait until 1.8.1. I need to rewrite the IVTC engine too because it also doesn't interact well with frame doubling, although it needs a lot of help in general, and realistically I care a lot more about field doubling working than IVTC working.

Posted by: Barough Jan 27 2008, 05:29 AM

Thnx for the new v1.8.0 Test 1, will take a look @ it during the coming week

Posted by: olnima Jan 29 2008, 07:37 AM

Hi phaeron,
a few versions ago You solved a bug which has made it again into new 1.8test1:

if I want to fade-in a captured video by using the curve-editor and "fill" - filter, everything is ok. But if I cut the beginning afterwards, I also cut away my fading.

In the old thread about this
http://forums.virtualdub.org/index.php?act=ST&f=15&t=13729&hl=&#entry55732

this was your answer:
<
Looking at the code, though, I think I know what's going on. Did you delete frames before the start of the video? I think the code is using the source frame instead of the timeline frame to check the filters, and if you shift the frames that'll break the check.
>

//edit1: second bug is the following:
if i save the processing-settings with filter "fill" and "blend" and two points (in and out for fading), "blend" and the two points are ignored when re-importing these saved-processing settings.

example:
>
VirtualDub.video.filters.Clear();
VirtualDub.video.filters.Add("fill");
VirtualDub.video.filters.instance[0].Config(0,0,0,0,0x000000);
declare curve = VirtualDub.video.filters.instance[0].AddOpacityCurve();
curve.AddPoint(0, 1, 1);
curve.AddPoint(50, 0, 0);
VirtualDub.audio.filters.Clear();
<
this is saved correctly (don't know if it is correct but saving vcf-file results in the same code as in older versions),
but if I re-import it, the filter-setting "blend" and the points are lost (ignored).

Hope You know what I mean
Olnima

Posted by: phaeron Jan 30 2008, 07:14 AM

Nice catches. Curve bug was the same, but the underlying cause was different.

http://www.virtualdub.org/beta/VirtualDub-1.8.0-test2.zip
http://www.virtualdub.org/beta/VirtualDub-1.8.0-test2-AMD64.zip
http://www.virtualdub.org/beta/VirtualDub-1.8.0-test2-src.7z

Posted by: olnima Jan 30 2008, 08:11 AM

...nice fixes

, thank You, seems to work - means that I will post here if it doesn't.

Btw: Any chance to implement an option to create a vcf-file for making a fade-in at the beginning AND a fade-out always at the end of the avi without knowing its total number of frames (after cutting)?

Thanks again,
Olnima

Posted by: mariushudea Jan 30 2008, 05:45 PM

In Virtualdub 1.7.7, if you check Show output video and Show decompressed output and the codec can not decode content (x264 encoder for example), then the proper message appears :

Unable to display compressed video: no decompressor is available to decode the compressed video

The problem is that after this happens, the output video never shows, no matter what checkbox I select. I should see the output video if I check only "Show output video"

Posted by: phaeron Jan 31 2008, 09:08 AM

@mariushudea:
Thanks, bug fixed. You'll see the fix in the next test release if I push one out.

@olnima:
Unlikely, I'm afraid. The reason is that I've found that doing end-relative things like that are bug fountains -- basically I end up having to write a bunch of code to keep updating the absolute position from the relative position, which invariably goes wrong. The end-of-selection was an example, which was a constant headache.

What you're asking for can be done right now by editing the script directly, using VirtualDub.video.length -- it's just that I don't think I'll be creating a UI for that.

Posted by: olnima Jan 31 2008, 09:27 AM

Thanks for the suggestion, editing vcf-file manually (without having an ui) would be more than enough.
Problem is, if I load video and vcf-file via commandline, I will loose end-points after cutting.
After playing around a bit I found out, that "VirtualDub.video.length" also holds the number of source-frames instead of the timeline-frames.
Can You change this behavior too analog to the upper mentioned and solved "curve-bug"?
With this I could load a 2nd vcf-file after cutting, only for fading-out at the end.

Olnima

Posted by: phaeron Feb 1 2008, 07:40 AM

Can't do that, because it would break backwards compatibility. That's what VirtualDub.subset.length is for, though.

Posted by: olnima Feb 1 2008, 08:02 AM

Just tried it out, "subset.length" does exactly what I want, thank You very much for your help.

Olnima

P.S.: Just a question: I found

"VirtualDub scripting language reference, v0.7".

Is this the latest documentation?
I ask, because "subset.length" and "video.length" aren't described there.

Posted by: trodas Feb 2 2008, 06:58 PM

I would like to say one point about the scaling. First at all, take the picture of Dalailama and scale it down using nearest neighbour way. You get this:

user posted image

Conclusion - you can trick the scale routines, if you want to. But the original image was ready and made for the trick of "disappearing" - and it was also of very poor quality, when come to depth of it. It was very, very gray to start with.

Also the scale down to 129 pix wide from 258 - exactly halving it to make the trick.

My observation over the years is - that with the scale picture usualy lost some brightness and contrast. So my scale-down Photoshop macro containing +4 to brightness and +6 to contrast - and of course sharpen +40 - if the scale is drastic, +15 if it is small.
I think my photos (sorry, only booring computer stuff, porn later

)
http://capsmod.net/forum/viewthread.php?tid=121&extra=page%3D2
http://capsmod.net/forum/viewthread.php?tid=69&extra=page%3D1
http://capsmod.net/forum/viewthread.php?tid=130&extra=page%3D2
http://trodas.wz.cz/index.php?act=ST&f=16&t=337&s=
http://capsmod.net/forum/viewthread.php?tid=267&extra=page%3D1
http://capsmod.net/forum/viewthread.php?tid=266&extra=page%3D1
http://capsmod.net/forum/viewthread.php?tid=169&extra=page%3D1
http://capsmod.net/forum/viewthread.php?tid=167&extra=page%3D1
http://capsmod.net/forum/viewthread.php?tid=81&extra=page%3D1
http://capsmod.net/forum/viewthread.php?tid=80&extra=page%3D1
http://capsmod.net/forum/viewthread.php?tid=76&extra=page%3D1
...somewhat confirm that this is the correct way to go.

phaeron - as far as the v1.8.0-test2 go, I did not find anything different (yet) - no new error - good - except one problem with the DirectShow input filter. When movie is loaded using your filter, then the preview does not work. There is only the white-bloack gradient when seeking and when stop, then there is the frame on witch one stop previously in the VDub, check there:
http://img527.imageshack.us/my.php?image=vdub180test2slightprevihu9.jpg

(no, at the moment - considering the seeking - are the credits there, not the start of the unplug scene, right?)

But I will continue to use the testing version, just to be able submit some (hope usefull) bugreports

The bug is related ONLY to the DirectShow input plugin. It never happen with normaly opened file.

PS. I forget to mention that the preview worked well with the DirectShow input plugin with VDub 1.7.7 build 28312, IIRC.

Posted by: phaeron Feb 2 2008, 09:32 PM

I'll take a look at what's going on with the DirectShow input plugin.

As for the scaling issue, that's expected behavior. Nearest neighbor mode picks the nearest available pixel, and it turns out that when you use a scaling factor of 2:1, the sampling point is exactly in the middle of each 2x2 block of pixels. Which pixel is picked depends on the convention used by the scaler, and depending on whether the scaler rounds up or down in each axis you can get any of the four pixels. No single convention is any better than the other -- if you were to make such an argument, I could simply flip the picture to negate it. The only behavior that is clearly worse is not being consistent between each 2x2 block, which you'll sometimes see in 3D accelerators, but that's not happening here.

Posted by: mariushudea Feb 2 2008, 11:01 PM

Since trodas posted a picture with the resize filter, i remembered I wanted to ask if this is by design or a bug...

The resize filter no longer adjusts the preview window when the sizes are changed. IN VIrtualdub 1.6.15, when I changed a value and pressed Tab moving the focus to another control, the preview window would show the changes.

I kind of got used to instant preview and now I have to click on Hide preview and click again the Preview button to see the new preview.

Posted by: phaeron Feb 3 2008, 01:07 AM

You just have to hit apply (Alt+A), not hide and show the preview. This was a change I made a while back.

The reason I made this change is that it was too easy to accidentally add extra digits onto one of the numbers and then hit Tab or otherwise click on another control, at which point the program would either crash or bring the entire system to its knees processing a 480320x240 bitmap.

Posted by: phaeron Feb 4 2008, 06:38 AM

@trodas: The filter preview bug is a bug in the DirectShow input driver. I'll post a fixed version in the thread for that plugin.

Posted by: rfmmars Feb 4 2008, 06:32 PM

I don't use this filter very much however using ACDsee plugin gives a black screen using 1.8.1 Test, will try 1.8.2 test.

EDIT: Same problem with 1.8.2 Test

Richard
photorecall.net

Posted by: mariushudea Feb 5 2008, 02:10 AM

Virtualdub 1.8.0-test2

Tools > Create test video ... > 3:2 Pulldown (TFF)
Video > Framerate > Inverse telecine (...) > Reconstruct from fields - adaptive
Video > Compression >x264 Encoder > Multipass - First Pass
File > Save as AVI

Progress window shows 800 frames being processed
Show output video doesn't work, show compressed output doesn't work.

After encoding completed:

Video > Compression > x264 Encoder > Multipass - Nth Pass
File > Save as AVI

Virtualdub stops working with the following error:

http://savedonthe.net/view/25/vdub_framecount.png

Messages say:

2nd pass has more frames than 1st pass 1000 vs 798.

Note the 798 value, the status window said 800 before, the second time the window doesn't appear.

After both windows are closed Virtualdub is usable.

If the Inverse telecine option is not selected, both 1st pass and 2nd pass work and the output is shown (not sure about the decompressed output, probably not because x264 can't decode).

small visual bugs

http://savedonthe.net/view/26/capture_05022008_034742.png

I'm not sure if Virtualdub uses an input buffer, in the Performance tab I see only AVI output buffering.

I use Huffuv a lot and I was wondering, would implementing an input buffer (i'm thinking something like 64-128MB - I have 2GB of memory installed) help compression speed?
When I set the output buffering to the maximum value, it speeds up conversions to Huffyuv with probably about 10-15%

My usual work with Huffyuv involves converting several small clips to huffyuv and applying logo on them, then joining together the pieces and compressing to xvid.

Posted by: phaeron Feb 5 2008, 07:46 AM

Alright, new build:
http://www.virtualdub.org/beta/VirtualDub-1.8.0-test6.zip
http://www.virtualdub.org/beta/VirtualDub-1.8.0-test6-AMD64.zip
http://www.virtualdub.org/beta/VirtualDub-1.8.0-test6-src.7z

Don't worry about the missing releases; they're being used in another thread.

@rfmmars:

QUOTE

I don't use this filter very much however using ACDsee plugin gives a black screen using 1.8.1 Test, will try 1.8.2 test.

Err... ACDsee plugin?

@mariushudea:

QUOTE

2nd pass has more frames than 1st pass 1000 vs 798.

Note the 798 value, the status window said 800 before, the second time the window doesn't appear.

After both windows are closed Virtualdub is usable.

The goofy UI behavior is from the x264 codec opening its own error window and then returning a generic error to VirtualDub. For some reason codec authors never feel the need to actually label their dialogs as coming from the codec.

I found and fixed the bug that caused the wrong number of frames to be reported to the codec, so try this build. I used r736 of x264 to test.

Visual bug is fixed.

QUOTE

I'm not sure if Virtualdub uses an input buffer, in the Performance tab I see only AVI output buffering.

I use Huffuv a lot and I was wondering, would implementing an input buffer (i'm thinking something like 64-128MB - I have 2GB of memory installed) help compression speed?
When I set the output buffering to the maximum value, it speeds up conversions to Huffyuv with probably about 10-15%

It does have an input buffer, but it's very small (~2MB) and doesn't act the same way as the write buffer. I'm not sure how much an input buffer would help.

The only real way in which read/write buffers help is in reducing the amount of seeking that the hard drive does. Seeks are death to hard drive performance -- a hard drive that does more than 20MB/sec at sequential I/O can drop to under 2MB/sec throughput under heavy seeking. For this reason, it is very advantageous to keep seeks low by feeding it large requests at a time. In practice, a chunk size between 1-4MB is enough to reduce seeks low enough to be a non-issue; the remainder of the buffer is only necessary to keep the CPU from waiting on the hard drive to process a chunk, and so somewhere between 4-16MB is about max needed.

An input buffer would probably help somewhat, but there are a few additional factors. One, the write buffer itself helps a lot because there's generally only two streams active (read + write) and by keeping its own I/O blocked, it frees up big blocks of time for the reader to get lots of back-to-back requests in. The main cause of seeking during any sort of copy-like operation is the read and write streams fighting over the same hard drive, which is the main reason that the file copy in Windows Explorer has historically sucked for big files. Two, there are generally two read operations active on the input file -- video and audio -- and that makes it tougher to buffer the input. If done improperly, the buffering can lower performance by reading too much extra data that must be thrown away. This can be disastrous over a network. Three, buffering tends to involve an additional memory copy, which can eat CPU.

There are a couple few interesting scenarios that enhanced input buffering could address. It would lower the system impact whenever something else needs the disk -- VirtualDub can be quite a disk hog -- and it can also lower the system swap-o-rama effect by reducing the strain on the disk cache.

It's interesting to think about, but I hadn't gotten around to actually ever trying to improve it.

Posted by: rfmmars Feb 5 2008, 06:04 PM

Besides ACDsee giving a black screen, the same problem exits with "Autolevel" which is a hack of ACDsee. with "Autolevels" thing may look ok when closing the filter box it, but will either go black or lock the timeline, uncheck it and the timeline unlocks.

Also simular problems with "DNR mmx"

I had a Xvid file which when imported gave a MP3 stream error, when I burned the DVD, it had a linera audio offset. Importing the same file into VD 1.67 the message was that the clip had a audio offset and gave me the amount and solution, please make a change back to this error message for the next release.

The above tested with VD 1.8.6 Test

Thx

Richard

Posted by: Gromozeka Feb 5 2008, 07:16 PM

QUOTE

I found and fixed the bug that caused the wrong number of frames to be reported to the codec, so try this build. I used r736 of x264 to test.

Phaeron, you used r736 of x264 to test from this:
http://www12.atwiki.jp/lunatilia/pages/70.html
This build have much big bug's

or this:
http://sourceforge.net/projects/x264vfw/
This build have not bug's and very good functionality

Igor

Posted by: phaeron Feb 6 2008, 05:01 AM

@Gromozeka:

QUOTE

Phaeron, you used r736 of x264 to test from this:
http://www12.atwiki.jp/lunatilia/pages/70.html
This build have much big bug's

Huh? What makes you say that? I used the one off the SourceForge site. In any case, those bugs don't matter if the issue in question is resolved on both builds.

@rfmmars:

QUOTE

Besides ACDsee giving a black screen, the same problem exits with "Autolevel" which is a hack of ACDsee.

Ah, I know what you're talking about now. If you could, please be explicit about the exact name of the filter you're using -- a download link would be even better. The reason I was confused is that ACDsee is a well-known image viewing application that does not, as far as I know, function as a VirtualDub plugin.

The issues with the filters you've raised is likely a compatibility problem with the new filter system that supports YCbCr filtering. I think I know how to fix this, though. It's definitely a release blocker.

QUOTE

I had a Xvid file which when imported gave a MP3 stream error, when I burned the DVD, it had a linera audio offset. Importing the same file into VD 1.67 the message was that the clip had a audio offset and gave me the amount and solution, please make a change back to this error message for the next release.

Which error message are you receiving, exactly? If it's this one:

CODE

[!] AVI: Stream 1 (audio) has a non-zero start position of 65536 samples
(+1486 ms). VirtualDub does not currently support a non-zero start time
and the stream will be interpreted as starting from zero.

...that, as far as I know, is unchanged in 1.8.0. If you're not getting this message when 1.7.x did, please use the Tools > Create Sparse AVI... function to produce an analysis file of the AVI and post it somewhere or email it to me so I can figure out what's going on.

QUOTE

The above tested with VD 1.8.6 Test

Posted by: Gromozeka Feb 6 2008, 07:01 AM

phaeron

QUOTE

Huh? What makes you say that? I used the one off the SourceForge site. In any case, those bugs don't matter if the issue in question is resolved on both builds.

For information Bugnaster's just in case

Posted by: phaeron Feb 6 2008, 09:25 AM

http://www.virtualdub.org/beta/VirtualDub-1.8.0-test7.zip
http://www.virtualdub.org/beta/VirtualDub-1.8.0-test7-AMD64.zip
http://www.virtualdub.org/beta/VirtualDub-1.8.0-test7-src.7z

Changes in this version:

Fixed compatibility problems with filters. (Technical details: XRGB8888 is now always forced to be bottom-up on entry to a filter unless that filter supports the new format arbitration.)
The filter dialog now shows [C] next to a filter when implicit conversion is happening. The three cases that can cause this: the filter doesn't support the direct input format, the filter doesn't support format arbitration and the incoming RGB32 bitmap is top-down in memory, and precise crop is active on a YUV input with a rect that doesn't fall nicely on block boundaries.
More AVI reindexing fixes.

Posted by: kkdd Feb 6 2008, 01:35 PM

phaeron
you are the man

TNX very very much
you are doing a good job with VirtualDub-1.8.0-test7

TNX

Posted by: olnima Feb 6 2008, 03:21 PM

(Blanked by administrator -- keep snide comments to a minimum, please)

Posted by: BugMaster Feb 6 2008, 04:28 PM

phaeron
I have problems with preview filtered (preview output) after going at first to end and then to beginning. Rendering becomes very slowly. As I understand the trigger of the problem is positioning on the last frame (the dummy frame after the video). The problem doesn't appear if disable "DirectX for display panes" option or enable "Use Direct3D" / "Use OpenGL". I use default settings (tested after deleting HKCU\Software\Freeware). Also problem fix itself after minimizing VirtualDub window and restoring (or switching to another application).

System:
Windows XP Pro SP2
ATI Radeon 9600
ATI Catalyst 6.11

P.S. Version 1.7.7 also suffers from this problem.

Posted by: BugMaster Feb 6 2008, 05:01 PM

Also found bug with playing animated GIFs. First time it played OK, but if you push play button immediately after first play (don't changing position) the strange things began (it starts infinite loop of start/stop playing and changing menus).

Posted by: rfmmars Feb 6 2008, 05:57 PM

Thanks for fixing the "filter " problem, however the message problem is not fixed. The message below doesn't give me enough informaton about a problem. Source clip is Xvid

Using VD 1.8.7 Test

http://img114.imageshack.us/my.php?image=mp3errorjq8.jpg

Same clip using VD 1.67 gives me the problem and how to correct.

http://img87.imageshack.us/my.php?image=vbrerrorta7.jpg

Thanks for your time.

Richard
photorecall.net

Posted by: phaeron Feb 7 2008, 04:55 AM

@rfmmars:

QUOTE

Thanks for fixing the "filter " problem, however the message problem is not fixed. The message below doesn't give me enough informaton about a problem. Source clip is Xvid.

Oh, that warning. The reason the VBR warning is gone is that 1.8.0 now supports VBR audio in AVI natively, so the audio error that was noted before no longer happens in VirtualDub. In your case, though, you're dealing with another device that doesn't support VBR either. I'll have to think about this a bit; maybe I can put the warning back in, toggleable by option in preferences.

@BugMaster:

QUOTE

Weird. This is related to the changes I made to allow the timeline to be scrubbed during playback. I can reproduce this locally, so I'll take a look at it.

Update:
http://www.virtualdub.org/beta/VirtualDub-1.8.0-test8.zip
http://www.virtualdub.org/beta/VirtualDub-1.8.0-test8-AMD64.zip
http://www.virtualdub.org/beta/VirtualDub-1.8.0-test8-src.7z

VBR warning is back and can now be switched off in Options, Preferences, AVI.
Found and squashed bug that was causing the weird playback-keeps-restarting problems.
I also found a nasty bug in the rendering engine that was causing the video pipeline to bottleneck on the audio pipeline in some cases. Those of you working with high disk bandwidth scenarios (direct/direct or lossless video) may see a little bit of speed boost here. Might backport this to 1.7.8 if it makes enough of a difference.

Posted by: Gromozeka Feb 7 2008, 10:02 AM

phaeron
Many programs work with avisynth (yv12), for example Hcencoder, Megui and other.
When I use frameserver on an output I receive rgb24 but why if now resize, crop work in yv12?

Posted by: phaeron Feb 8 2008, 04:38 AM

No technical reason... the frameserver's just fairly low in priority and I haven't worked on it in a while, other than to keep it from breaking.

Posted by: rfmmars Feb 8 2008, 06:25 AM

Very happy now, I get two messages for the price one, SUPER!!!

Richard
photorecall.net

Posted by: Gromozeka Feb 8 2008, 07:20 AM

phaeron

QUOTE

No technical reason... the frameserver's just fairly low in priority and I haven't worked on it in a while, other than to keep it from breaking.

Mine a duty to inform you. Accept please this fact on a note!
Thanks

Posted by: Moitah Feb 12 2008, 07:03 PM

QUOTE (phaeron @ Dec 26 2007, 12:45 AM)

Input plugins can now defer video codec selection to VirtualDub. The mechanism is fairly simple: return NULL/false from CreateVideoDecoder().

Works great when the codec is present. When it's not, VirtualDub brings up an "Out of memory" error message box. Shouldn't it say "Couldn't locate decompressor for format..."?

Posted by: phaeron Feb 13 2008, 06:02 AM

http://www.virtualdub.org/beta/VirtualDub-1.8.0-test10.zip
http://www.virtualdub.org/beta/VirtualDub-1.8.0-test10-AMD64.zip
http://www.virtualdub.org/beta/VirtualDub-1.8.0-test10-src.7z

This is the first release candidate for 1.8.0. (It's not final because I need to get 1.7.8 out first, dammit.)

Changes:

Fixed Moitah's out-of-memory plugin bug.
Some fairly major changes to the filter system to fix compatibility bugs. In particular, Deshaker works again.
The help file has been updated with the new video filter functionality.

Posted by: kkdd Feb 13 2008, 10:39 AM

who i can save 2 auido streams with "VirtualDub-1.8.0-test10"?
i have AVI with 2 audio and i want to keep tham
who can i do it?

phaeron,
U fix a bug whan i need to cut AVI clip and VirtualDub was crush, but now, NO MOOR!!
more ezy to go back and forward whan i need to cut clips
U FIX THE VBR :-)
if i found a bug i let u know

TNX for your time
and your greet Job

Posted by: olnima Feb 13 2008, 02:45 PM

QUOTE (kkdd @ Feb 13 2008, 10:39 AM)

who i can save 2 auido streams with "VirtualDub-1.8.0-test10"?
i have AVI with 2 audio and i want to keep tham
who can i do it?

Hi kkdd,
did You try "direct streamcopy" to keep your audio untouched?

Olnima

Posted by: kkdd Feb 13 2008, 04:07 PM

yes i try "direct streamcopy" to keep my audio untouched
but in the menu Audio - Source audio i have stream 1 & stream 2 but if i want to save the clip than VD save it with 1 Stream
if i choos stream 2 than VD save the stream 2 without stream 1
never together

Posted by: Barough Feb 18 2008, 02:56 PM

@ phaeron
Now when v1.7.8 have been released, do u think it will be long b4 we'll see a v1.8.0 Stable release.

Posted by: phaeron Feb 19 2008, 05:46 AM

Sorry, but it'll be out when it's out -- if I find showstoppers the process restarts. I found a pretty bad bug this weekend with rounding in the resampler in YCbCr mode, for instance.

Posted by: Barough Feb 19 2008, 09:24 AM

Bugs can sneak in everywhere, so it's understandable.

Posted by: T&T Feb 19 2008, 11:02 AM

Dear Phareon,

Sorry not answering to Your comment some times ago, but my family increased by 33% and I had to assimilate a lotta brand new things. :-)

QUOTE

But there is a little problem. If I set the allocation size and stop condition manually then VDub uses 29-39% CPU. If I set them and start capturing automatically from command line it uses 55-62%. Even if I set the allocation size from command line and I set the stop condition manually it also uses the lower value.

This is misthical...

I tired to test this (even I launched the Real-Time profiler as You suggested), but sometimes the CPU usage was high, sometimes low. I tried to launch 1.7.6 and 1.7.X with different settings. At the end I think I found the difference!

When I start the manual capturing process I do the following:
* I launch VDub
* File/Capture AVI
* P (set preview), and I set the preview acceleration to the next line under "Off" (something like odd lines in interlaced mode). Unfortunatelly in the Off mode the refresh of pictures are very slow on my PC.
* I set the caputre filename (F2)
* I set the preallocation size (Alt+F, A)
* I set the stop condition to the needed seconds
* I launch capture press (F6 and then Enter). I set VDub not to show the captured pictures on the screen during the capture porcess.

In this case the CPU will eat cca. 30-50% on my PC.

If I not set the preview acceleration (launching manually or starting VDub setting the command line options) then the CPU usage insreases to 70-85% and it often causes the audio to be dropped behind.

I do not understand why affects the CPU usage of capture process if I set the preview acceleration even if the pictures are not shown during the capture process.

Thanks in Advance!

TT

Posted by: olnima Feb 19 2008, 07:04 PM

QUOTE (T&T @ Feb 19 2008, 11:02 AM)

...but my family increased by 33%...

Tata, congratulations, 33,3% male or female? Next time it's only 25%, so your family-increasing decreases

. Best wishes for You and your family,

Olnima

Posted by: Moitah Feb 19 2008, 07:33 PM

QUOTE (phaeron @ Dec 31 2007, 04:18 AM)

For the technically curious, the issue is that VideoLAN doesn't interpret dwSampleSize in an audio stream the same way as DirectShow -- it interprets it the "pure" way as dwSampleSize=0 means VBR, whereas Microsoft's AVI parsers always ignore dwSampleSize for audio streams. I was setting it to nBlockAlign, and changing that to 0 fixed the incompatibility.

There should be a way for audio source plugins to set dwSampleSize = 0 also (if kFlagVariableSizeSamples is set, I guess).

Posted by: phaeron Feb 20 2008, 06:20 AM

@T&T:
Preview acceleration consumes additional CPU because it has to copy video frames around. Omitting that overhead when the video is not actually displayed is not currently implemented.

@Moitah:
Good catch -- I've just added this to the code base.

Posted by: T&T Feb 20 2008, 09:24 AM

Dear Phareon,

QUOTE

@T&T:
Preview acceleration consumes additional CPU because it has to copy video frames around. Omitting that overhead when the video is not actually displayed is not currently implemented.

Would it be possible to omit this overhead sometime? According to my tests this would reduce the CPU consumption during caption a lot!

TIA!

TT

Posted by: phaeron Feb 21 2008, 03:31 AM

I've added this feature request to the list for consideration in a future version.

Posted by: sonical Feb 24 2008, 02:27 PM

I've just checked 1.8.0 test 10 version and besides new features, found also new bugs (absent in 1.7.8):

This time regarding filter-->crop feature.

1.) it causes strange problem with "motion blur" built-in filter. If lower part of the image is cut before the filter, filter seems to have the processing loop for Y still set to full image Y span. Processed images have the cropped bottom part visible in the blur "tail" from the upperside of the image.

Just did a screen grab of the problem, yet cannot add a picture here - so can only send it over email.

If there's any filter after it, the same processing problem is visible in it's preview.

2.) selecting a crop feature after a filter that has been disabled (via the new tickbox column in 180) gives no cropping preview (just a flat out gray field), yet cropping settings work and everything gets filtered right

Posted by: -SPM-Mad Feb 24 2008, 10:30 PM

I hope you do not mind some feedback from me: (testbuild 10)

It is more than FANTASTIC to see preperations for different colordepth filterchains. Thank you so much ^,^
But am I the only one who thinks 48bit (or 64bit if it fits better with the registers) is stupid?

It is also funny to see how you can play with random physic stuff and manage to implement it in a serious way in a videocutting/filtering tool. The testvideos are really nice for deinterlacer-testing. Gave me a chance to test your new frame-inserting filters like the bob doubler. Seems solid to me =)

-When trying to create somethign artistic (the power of boredom) from your snowflakes, I managed to crash VD by loading processing settings:
http://pastebin.com/m1d0507aa
I used the 3:2 Pulldown Bottom Field First test-movie and VD crashed when loading this processing settings.
(crashreport: http://pastebin.com/m404ae5c8)

And just adding 'blur' and trying to load this processing settings, it also reports an error.

-Using the perspective filter the built-in preview shows garbage, but earlier versions had this problem too and it is not really affection the filter itself at all.

I tested some capturing and other filters but did not mange to find anything else yet.

Greetings
-SPM-Mad

Posted by: sonical Feb 24 2008, 11:36 PM

Hmm, well 48bit/pix (16bit/chan) sounds very reasonable for me. Besides any HDR-related stuff, for an 8-bit/chan target, 16bit/chan processing pipeline is actually a resonable requirement, if quality matters.

It is very easy to prove as well, just play around with two different filters working with levels (f.ex. one histogram eq, another one for color correction etc). Swap the filtering order. See the differece. When one of the filtera lightly changes values even a little, and the other one has to convert everything to HSV, resulting hue/saturation error boosts a lot.

Another simple example could be: what filter order would you choose for applying: chroma smoothing (after sharply subsampled source) and levels histogram eq to boost mids?

chromasmoothing-->levels : you will get filtered chroma channels with higher noise, due to errors introduced after converting the filtering results from the first filter to 8 bits, and then boosting them. So the result is not optimal.

levels-->chromasmoothing : you will still get (but otherwise) noisier picture due to boosting and introducing additional rounding errors after levels and then filtering.

any order when in 16bit/chan : booster boosts, filter filters, resulting picure has all 256 levels/chan "live" after final rounding, everyone is happy.

Posted by: phaeron Feb 25 2008, 01:56 AM

Alright guys, time's up -- 1.8.0 is live on SourceForge. Fetch! In the meantime, keep the feedback coming, and I'll start a 1.8.1 thread once a new test release is ready.

Current bug status:

Overlap issues with motion blur: fixed in 1.8.0 final.
Crop/disable bug: fixed in 1.8.0 final.
Exception crash with SPM-Mad's VCF: confirmed, will fix for 1.8.1. Problem is caused by bogus config statement for "blur more" filter.

The random physics stuff I just put in because I needed something halfway interesting for the video. If you look closely, you can see a bug where the balls hop a little bit when they jump off the edge of the triangle -- there's an issue with the collision detection that I didn't bother to fix. I'd like to put in something for audio too but I have no idea what to put in.

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.

Posted by: sonical Feb 25 2008, 04:02 PM

Hooray! Thanks, Phaeron. All the most visible things fixed.

Too baaad I am so out-of-C - i'd realy like to do some audio test generators. I man like simple physical modeling, analog modeling and TR-like drums synthesizer with some fixed progressing pattern. Rather effective to test various codecs and their performance as well (as hell), as the most of them fail to sound good when there is very sharp and distorted drums and soft complex string textures behind. Depending on volume of the background textures, something allways gores wrong - with the drums or with the texture. (switching between fast-framerate/low-precision and normal-framerate/normal-precision for ATRAC and MPEG audio). Both encode ultimately bad in WMA-type crap (except where there is AAC behind it - in newer files), and in most cases Vorbis does the best job.

For the people to find out what sounds the best - we could include such a thing inside, too.

Besides complex things - there could be classic testsas well - 1k sine, a-weighted and c-weigthed noise, some sine-modeled chord and such.

Yet my issue is that it seems I am stuck with pascal for this life

Just talked in an another thread with mr. Neuron2 about the same issue regarding writing filters.

Posted by: sonical Feb 25 2008, 11:37 PM

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.

First I was little confused, then checked the build number and compared to 1.8.0 test10 and ensured the one I downloaded from sourceforge was The One (build 29393).

Posted by: -SPM-Mad Feb 26 2008, 12:12 AM

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.

@sonical

It is still an experimental version. Please be paitent.

@phaeron

I am not familar with your internal rendering engine. I can imagine that higher color precision might be harder to handle. And if we start talking about real professional colormanagement and stuff like this here, it will get alot further that I intended.

When it comes to more bits per pixel, I am actually not interested in standard colorspaces nor perfect performance nor that all the internal filters can handle it. Just anything that allows a tiny bit more to reduce the rounding-artifacts with some crazy filterchains I sometimes used. A simple support that future external filters might be able to pick up.

But I also have to mention that this is not on top of my wish-list, so no need to hurry =)

*Thumbs up* from me

Posted by: sonical Feb 26 2008, 12:32 AM

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.

Posted by: phaeron Feb 26 2008, 06:25 AM

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.

Posted by: sonical Feb 26 2008, 11:48 AM

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]

Posted by: Loadus Feb 27 2008, 02:27 PM

QUOTE (phaeron @ Feb 24 2008, 07:56 PM)

Holy bitdepth, batman.

Sounds like OpenEXR in, OpenEXR out (feature request maybe, someday, ya know) ...

Thanks for the new version, Phaeron!

Posted by: T&T Feb 27 2008, 11:30 PM

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!

Posted by: mariushudea Mar 1 2008, 04:05 PM

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

Posted by: phaeron Mar 1 2008, 10:55 PM

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.

Posted by: mariushudea Mar 2 2008, 06:50 PM

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.

Posted by: phaeron Mar 3 2008, 02:15 AM

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-1.8.1-test1-AMD64.zip
http://www.virtualdub.org/beta/VirtualDub-1.8.1-test1-src.7z

(Job Control is a bit messed up in this version, so please don't try it for other purposes.)

Posted by: mariushudea Mar 3 2008, 08:50 PM

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.

Posted by: mariushudea Mar 5 2008, 05:35 PM

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.

Posted by: phaeron Mar 6 2008, 08:14 AM

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.

Posted by: Simba Mar 7 2008, 10:13 PM

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

Posted by: ic_guy Apr 15 2008, 06:34 PM

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?

Posted by: Moitah Apr 15 2008, 11:41 PM

@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.

Posted by: phaeron Apr 16 2008, 05:18 AM

Will be fixed in 1.8.1.

Posted by: ic_guy Apr 16 2008, 11:43 PM

Thanks for the info! I was messing with a tiny little thing, basically an animated cursor, else would have never known or cared about an extra 100K,

By the way, setting superindex entry limit to zero results in a divide by zero crash.