|
|
| DrGuz |
| Posted: Aug 3 2013, 07:16 PM |
 |
|
Newbie
Group: Members
Posts: 9
Member No.: 25655
Joined: 8-June 09
|
Versions:
VirtualDub 1.10.3 and 1.10.4-test11
Windows XP(SP3) 32-bit
Symptom:
In the "Video > Filters..." dialog, when the checkbox "Show image formats" is set, results are inconsistent.
Issue 1: If color depth is YUY2, filters only report YUYV if an AVI file is loaded. Otherwise they report RGB32.
Issue 2: If settings.vdscript file is loaded before AVI, filters report YUYV as expected. If AVI is loaded first, then settings, filters report RGB32.
Issue 3: Color depth "Autoselect" chooses RGB32, when AVI file is natively YUV and no filters require conversion.
Issue 4: Filter "convert format" reports same color depth for input and output. Expected input to match output of previous filter.
Reproduce:
My test AVI file was compressed with Xvid-1.2.2 (16:23:59, Jun 7 2009), unrestricted profile, single-pass encoding, target bitrate 10000kbps. MediaInfo v0.7.33 reports this file as "YUV 4:2:0".
Test case 1
- Launch fresh VirtualDub
- add Filter "field swap"
- observe Filter shows RGB32 (ok)
- set Color Depth to YUY2/Same
- observe Filter shows RGB32 (seems wrong)
- open "Xvid.AVI"
- observe Filter shows YUYV (ok)
Test case 2
- Launch fresh VirtualDub
- open "Xvid.AVI"
- add Filter "field swap"
- observe Filter shows RGB32 (ok)
- set Color Depth to YUY2/Same
- observe Filter shows YUYV (ok)
- "File > Save processing settings" as "test.vdscript"
Test case 3
- Launch fresh VirtualDub
- open "Xvid.AVI"
- Load "test.vdscript" (includes "field swap", color depth YUV2/Same)
- observe Filter shows RGB32 (seems wrong)
- observe Color Depth is YUY2/Same
- change Color Depth to 24-bit RGB/Same
- observe Filter shows RGB32 (ok)
- change Color Depth back to YUY2/Same
- observe Filter shows YUYV (ok)
Test case 4
- Launch fresh VirtualDub
- Load "test.vdscript" (includes "field swap", color depth YUV2/Same)
- observe Filter shows RGB32 (seems wrong)
- open "Xvid.AVI"
- observe Filter shows YUYV (ok)
Test case 5
- REPEAT test case 4
- change Color Depth to Auto/Same
- observe Filter shows RGB32 (seems wrong)
Test case 6
- REPEAT test case 4
- add Filter "convert format", choose 32-bit RGB
- observe "field swap" output shows YUYV (ok)
- observe "convert format" input shows RGB32 (seems wrong)
- observe "convert format" output shows RGB32 (ok)
|
|
| raffriff42 |
| Posted: Aug 3 2013, 07:53 PM |
|
|
Advanced Member
Group: Members
Posts: 384
Member No.: 35081
Joined: 25-June 12
|
>MediaInfo v0.7.33 reports this file as "YUV 4:2:0"
MediaInfo uses the ffmpeg library I believe - but the VfW codec that VirtualDub sees could be outputting RGB. What does VirtualDub "AVI Info" show..?
Try the file using the FFmpeg Input plugin. |
|
| dloneranger |
| Posted: Aug 3 2013, 08:24 PM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
| QUOTE | | Issue 1: If color depth is YUY2, filters only report YUYV if an AVI file is loaded. Otherwise they report RGB32. |
That's just a display inconstancy, YUY2 and YUYV are the same thing
The code's been developed over quite a long time, and there are a few like that
| QUOTE | | Issue 2: If settings.vdscript file is loaded before AVI, filters report YUYV as expected. If AVI is loaded first, then settings, filters report RGB32. |
Loading settings isn't triggering the 'open video' path in the code, so the colour depth is the same as when loaded
| QUOTE | | Issue 3: Color depth "Autoselect" chooses RGB32, when AVI file is natively YUV and no filters require conversion. |
Yes, rgb is a higher priority than the yuv formats
This is because the code has developed over time, and once upon a time rgb was the only choice
| QUOTE | | Issue 4: Filter "convert format" reports same colour depth for input and output. Expected input to match output of previous filter. |
That's because it's not the filter doing the conversion
The filter's just saying 'i only accept x as a format' and virtualdub's converting it before the filter gets it
The convert format filter doesn't actually 'do' anything at all apart from only accepting one format of video
(Most filters work this way for conversion of formats)
Each filter has a list of what video formats it accepts, and virtualdub will do a 'best fit' between one filter and the next
If you want to accurately track the format conversions in the filter list, add 'null transform' filters in between each real filter
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| DrGuz |
| Posted: Aug 4 2013, 12:27 AM |
|
|
Newbie
Group: Members
Posts: 9
Member No.: 25655
Joined: 8-June 09
|
raffriff42, I installed FFInputDriver.vdplugin but I'm not sure how to verify it is getting loaded or working correctly. (I extracted the contents of "ffinputdriver-bin-0.7-32.zip" into my VirtualDub folder, I see the .vdplugin within the "plugins32" subfolder.)
I cannot actually find a menu command named "AVI Info" ... I presume you mean "File > File Information..."?
| QUOTE | Video:
Frame size, fps (µs per frame): 704x480, 29.970 fps (33367 µs)
Length: 1298 frames (0:43.31)
Decompressor: Xvid MPEG-4 Codec (XVID)
Number of key frames: 5
Min/avg/max/total key frame size: 44605/74189/123255 (363K)
Min/avg/max/total delta size: 2767/41566/132833 (52486K)
Data rate: 9996 kbps (0.06% overhead) |
Looks like it's still relying on the Xvid codec; but if I try to run VirtualDub (1.10.4-test11) in a different sandbox without that codec, it cannot open the AVI file:
---------------------------
Couldn't locate decompressor for format 'XVID' (unknown)
VirtualDub requires a Video for Windows (VFW) compatible codec to decompress video. DirectShow codecs, such as those used by Windows Media Player, are not suitable.
---------------------------
|
|
| dloneranger |
| Posted: Aug 4 2013, 12:59 AM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
To use any of the input plugins
Select the file in the open file dialog
Change the 'files of type' to the required plugin
Ok the dialog
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| DrGuz |
| Posted: Aug 4 2013, 01:03 AM |
|
|
Newbie
Group: Members
Posts: 9
Member No.: 25655
Joined: 8-June 09
|
dloneranger, thanks for your quick reply!
| QUOTE | That's just a display inconstancy, YUY2 and YUYV are the same thing
The code's been developed over quite a long time, and there are a few like that
|
Ah, I think you misread. I know YUV terminology has been historically inconsistent, I have no problem with that. 
I meant to point out that having an AVI file loaded or not seems to affect whether the filters are honoring the Color Depth setting. With a file, they match (YUV), and when the file has not yet been loaded they report RGB instead. This may be moot; I'm not aware of any processing that can be meaningfully done when there is no AVI file, but I mentioned it in case this triggered an "a-ha" cleanup opportunity for someone famliar with the code.
| QUOTE | Loading settings isn't triggering the 'open video' path in the code, so the colour depth is the same as when loaded
|
So, "yes it's a bug" or "no that's normal"? Seems like a problem if loading a Color Depth setting vs. clicking it in the Color Depth dialog produce two different behaviors. Especially since the dialog reflects the same status either way (see test case 3).
Meanwhile, there is a perfectly good workaround: always load settings before loading a video.
| QUOTE | Yes, rgb is a higher priority than the yuv formats
This is because the code has developed over time, and once upon a time rgb was the only choice
|
I see. I would suggest that "Autoselect" could be improved to choose the least-transformative option, rather than enumerating possibilities until one doesn't fail, but this would be a very low priority request.
For now, caveat dubber: set your color depth explicitly if you care.
| QUOTE | That's because it's not the filter doing the conversion
The filter's just saying 'i only accept x as a format' and virtualdub's converting it before the filter gets it
The convert format filter doesn't actually 'do' anything at all apart from only accepting one format of video
(Most filters work this way for conversion of formats)
Each filter has a list of what video formats it accepts, and virtualdub will do a 'best fit' between one filter and the next
If you want to accurately track the format conversions in the filter list, add 'null transform' filters in between each real filter
|
Good suggestion, and thanks for explaining a bit of the internal workings there.
|
|
| raffriff42 |
| Posted: Aug 4 2013, 01:04 AM |
|
|
Advanced Member
Group: Members
Posts: 384
Member No.: 35081
Joined: 25-June 12
|
>I presume you mean "File > File Information..."?
Yes, sorry! I shouldn't have trusted my memory.
Under File Information, check Video Stream / Pixel Format...
|
|
| DrGuz |
| Posted: Aug 4 2013, 01:17 AM |
|
|
Newbie
Group: Members
Posts: 9
Member No.: 25655
Joined: 8-June 09
|
| QUOTE (dloneranger @ Aug 4 2013, 12:59 AM) | To use any of the input plugins
Select the file in the open file dialog
Change the 'files of type' to the required plugin
Ok the dialog |
Excellent, that's done it. Thanks!
FFMpeg reports "yuv420p", which is consistent with MediaInfo. Repeating test case 2 now shows that "Autoselect" is choosing "YUV422" instead of "RGB32". I wonder, does this mean FFMpeg is declining a request to decompress to RGB, so VirtualDub goes down the list until YUV422 works? Or does Xvid somehow express a preference for RGB, which Autoselect (correctly) doesn't bother challenging? It's not clear to me when colorspace conversions are being done within the codec or by VirtualDub itself, but I probably shouldn't care.
It's also mildly curious that yuv420 becomes YUV422, but it doesn't really bother me. I presume it's like RGB24 being treated as RGB32 with fake alpha; better performance, same data integrity.
|
|
| dloneranger |
| Posted: Aug 4 2013, 01:46 AM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
| QUOTE | | .....snip... file has not yet been loaded they report RGB instead |
Yeah - the filters have to be given some basic information even if there's no actual video and rgb's just the default
Re setting script not triggering a colour depth change
Sorry, I have no idea if it's by design or not 
I'm not quite sure how autoselect picks a format
But one of the nice things is that you can download the source code and rewrite any bits you don't like
Not sure if you know this (or if it would be useful to you), but you can get virtualdub to autoload a script file with you fave settings in
Set all your codecs/settings etc as you like them
Optionally - add all you fave filters to the list in the order you use them, then untick them all (this will give you a quick tick the box way of having a fave filter list)
Save processing settings somewhere - just going to use c:\mysettings.vdscipt as an example here
Make a shortcut to virtualdub on the desktop
Right click the shortcut and select properties
At the end of the target box type in {space}/s{space}"c:\mysettings.vdscipt"
Ok the dialog
Now your shortcut will load all those settings (saves a bit of time)
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| phaeron |
| Posted: Aug 18 2013, 07:20 PM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Regarding the various test cases:
- Test case 1: Yes, this is just an artifact of the dialog. If no video file is loaded, it assumes a 320x240, 32-bit RGB input. I should probably just change this to not display anything as it's of dubious use to show the effects on such a video.
- Test case 4: This is a bug in the scripting path -- it doesn't reinitialize the filter graph after changing the input format. Actual renders to disk shouldn't have a problem as the filter graph is always reinitialized.
- Test case 6: This is due to the way the 'convert filter' filter works. It works by forcing the filter graph itself to do the conversion, so the input format and output format are always shown as the same. The [C] on the left indicates that an implicit conversion is taking place on input.
|
|
