|
|
| phaeron |
| Posted: Feb 19 2008, 05:46 AM |
 |
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
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.
|
|
| Barough |
| Posted: Feb 19 2008, 09:24 AM |
|
|
Advanced Member
Group: Members
Posts: 95
Member No.: 22677
Joined: 24-December 07
|
Bugs can sneak in everywhere, so it's understandable.
--------------------
 |
|
| T&T |
| Posted: Feb 19 2008, 11:02 AM |
|
|
Advanced Member
Group: Members
Posts: 39
Member No.: 22497
Joined: 26-November 07
|
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 |
|
| olnima |
| Posted: Feb 19 2008, 07:04 PM |
|
|
Advanced Member
Group: Members
Posts: 204
Member No.: 17204
Joined: 12-November 05
|
| 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 |
|
| Moitah |
| Posted: Feb 19 2008, 07:33 PM |
|
|
Advanced Member
Group: Members
Posts: 210
Member No.: 8955
Joined: 20-February 04
|
| 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). |
|
| phaeron |
| Posted: Feb 20 2008, 06:20 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
@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.
|
|
| T&T |
| Posted: Feb 20 2008, 09:24 AM |
|
|
Advanced Member
Group: Members
Posts: 39
Member No.: 22497
Joined: 26-November 07
|
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 |
|
| phaeron |
| Posted: Feb 21 2008, 03:31 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
I've added this feature request to the list for consideration in a future version.
|
|
| sonical |
| Posted: Feb 24 2008, 02:27 PM |
|
|
Advanced Member
Group: Members
Posts: 143
Member No.: 23118
Joined: 23-February 08
|
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
|
|
| -SPM-Mad |
| Posted: Feb 24 2008, 10:30 PM |
|
|
Advanced Member
Group: Members
Posts: 197
Member No.: 1332
Joined: 13-December 02
|
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 |
|
| sonical |
| Posted: Feb 24 2008, 11:36 PM |
|
|
Advanced Member
Group: Members
Posts: 143
Member No.: 23118
Joined: 23-February 08
|
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.
|
|
| phaeron |
| Posted: Feb 25 2008, 01:56 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
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.
|
|
| sonical |
| Posted: Feb 25 2008, 04:02 PM |
|
|
Advanced Member
Group: Members
Posts: 143
Member No.: 23118
Joined: 23-February 08
|
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.
|
|
| sonical |
| Posted: Feb 25 2008, 11:37 PM |
|
|
Advanced Member
Group: Members
Posts: 143
Member No.: 23118
Joined: 23-February 08
|
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). |
|
| -SPM-Mad |
| Posted: Feb 26 2008, 12:12 AM |
|
|
Advanced Member
Group: Members
Posts: 197
Member No.: 1332
Joined: 13-December 02
|
| 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 |
|
