|
|
| phaeron |
| Posted: Mar 13 2006, 03:26 AM |
 |
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Promoted 1.6.13/exp + fixes to 1.6.14/stable. Enjoy.
| CODE | Build 24415 (1.6.14, stable): [March 12, 2006]
[features added]
* Added option to choose different disk I/O modes to tradeoff slower speed
for better compatibility and system response.
* Added /capfileinc switch to set filename and increment its trailing
number to avoid existing files.
[bugs fixed]
* Added workaround for video codecs that read beyond the end of the input
buffer during Huffman/VLC decoding.
* Fixed intermittent problems with writing AVI files to a network drive.
|
|
|
| Razor88 |
| Posted: Mar 13 2006, 04:49 AM |
|
|
Unregistered
|
thanks paeron I was waiting for the stable. |
|
| stephanV |
| Posted: Mar 13 2006, 10:04 AM |
|
|
Spam killer ;)
Group: Moderators
Posts: 4348
Member No.: 8917
Joined: 18-February 04
|
Many thanks!
Is this expected to be the latest release for the 1.6 line? Or do you still have some plans for it?
--------------------
useful links:
VirtualDub, Input plugins and filters, AviSynth, AVI-Mux GUI, AC3ACM by fcchandler, VirtualDub FAQ |
|
| KornX |
| Posted: Mar 13 2006, 11:55 AM |
|
|
Advanced Member
Group: Members
Posts: 41
Member No.: 2043
Joined: 18-January 03
|
ah, let's give it a try...
thx Avery
@fcchandler
I guess u mod this one too?
Looking forward to it...
KornX
--------------------
There are only 10 types of people;
Those who do and those who don't understand binary. |
|
| meilin |
| Posted: Mar 14 2006, 04:15 AM |
|
|
Unregistered
|
thx Avery  |
|
| Loadus |
| Posted: Mar 14 2006, 05:30 PM |
|
|
Advanced Member
Group: Members
Posts: 352
Member No.: 10881
Joined: 1-July 04
|
Wow. Looking good. My thanks to Avery also.
--------------------
deviantART behance |
|
| Pharaoh Atem |
| Posted: Mar 19 2006, 10:18 PM |
|
|
Advanced Member
Group: Members
Posts: 114
Member No.: 17757
Joined: 7-January 06
|
I have released a new revision of my VirtualDub (official) installer. It has been updated to the latest stable! Hopefully, fccHandler will update his modified version of VirtualDub to the latest stable as well...
--------------------
Enano CMS - the CMS that focuses on what matters most: content. |
|
| jevans6964 |
| Posted: Mar 21 2006, 01:02 AM |
|
|
Unregistered
|
Anyone notice macroblocking ( looks like the bottom 2 or 4 lines ) on the bottom of the frame when a scene pans left or right?
I started using 1.6.14 and noticed these errors. I went back to 1.6.13 and re-encoded the content using the same job list ( just reset to "waiting" from "done" ) and they are gone.
I am using Divx 6.1, DGIndex 147b4, Decomb 5.2.1, Zoomplayer 4.5.0, and vsfilter 2.33.
The content is being cropped and bi-cubic resized via avs script to 716 x 404.
I posted here since I didn't see a topic for 1.6.14 bugs in the bug reports section.
I'll keep a clip just in case someone wants to take a look at it.
Thanks,
John |
|
| phaeron |
| Posted: Mar 21 2006, 06:05 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
The changes in the codebase between 1.6.13 and 1.6.14 are very minimal and there none that I could see that could explain this behavior. Any chance you had an Nth-pass mode enabled on the job? If so, the video codec may have improved quality in the subsequent 1.6.13 pass using information that it gleaned when doing the encode under 1.6.14.
|
|
| jevans6964 |
| Posted: Mar 21 2006, 07:21 AM |
|
|
Unregistered
|
I forgot to mention that these were 2-pass encodes.
Yes. I thought of this and deleted the map, the small .avi, and the statistics files for the jobs before re-encoding with 1.6.13. The only thing I kept in the encode directory from the previous 1.6.14 pass were the demuxed .ac3, the .d2v file, the .avs script, and the .vob files.
Is there any other files I should have deleted?
Just to verify, I am going to re-install 1.6.14 and do another encode of one of the jobs and compare the results of the first 1.6.14 pass. It may have just been an isolated problem with that batch of encodes.
On that same topic. Would it be a problem if I don't assign a name for these map & stats files? In other words, does VD clear those out each time it goes to encoding a first pass? I am guessing it does since the option to give the .log files a name ( just see a temp files folder location now ) disappeared with the 1.6.xx versions.
Ex. Does VD do this?
Job 1 >> 1st pass - encode 1
Job 2 >> Nth pass - encode 1
>> overwrite map and stats files
Job 3 >> 1st pass - encode 2
Job 4 >> Nth pass - encode 2
... |
|
| stephanV |
| Posted: Mar 21 2006, 07:47 AM |
|
|
Spam killer ;)
Group: Moderators
Posts: 4348
Member No.: 8917
Joined: 18-February 04
|
| QUOTE | | On that same topic. Would it be a problem if I don't assign a name for these map & stats files? In other words, does VD clear those out each time it goes to encoding a first pass? I am guessing it does since the option to give the .log files a name ( just see a temp files folder location now ) disappeared with the 1.6.xx versions. |
This is handled by the DivX codec. VirtualDub doesn't even know you are doing a multi-pass.
With a resolution of 716x404 I would blame the decoder/encoder, not VirtualDub. Although, I don't know why it would work with 1.6.13.
--------------------
useful links:
VirtualDub, Input plugins and filters, AviSynth, AVI-Mux GUI, AC3ACM by fcchandler, VirtualDub FAQ |
|
| frank10 |
| Posted: Mar 21 2006, 05:34 PM |
|
|
Advanced Member
Group: Members
Posts: 148
Member No.: 14177
Joined: 19-February 05
|
I just downloaded this new VD version and I noticed it has changed the capture AV sync correction.
I didn't make a lot of captures with 1.6.14 but on the first I did, I noticed an improved sync: before I had (with my Terratec Cinergy600 and VD 1.6.11) always 1 or max 2 frames dropped at starting of capture and this corresponded in about 40-80ms of not-sync in the final video. Now it seems to never drop a frame at start of capture but there is always 1 frame inserted, but at the end my file is in sync in a range of 3-7ms.
I.e. 2h:00:57:60 in video and 2h:00:57:57 in the audio track.
But another time I had this behaviour: 1 frame inserted at the beginning and after about 2h:30', I found out a total of 7 frames inserted (zero dropped frames). When I looked at the video, I found the 'inserted' frames (= duplicated frames, isn't it?), searching with the command to find dropped ones and in fact they are labeled 'D'.
Anyway at the end I got 7ms in AV sync. So congratulations phaeron! 
So, is this a normal behaviour or should I change something in the settings to reach perfect sync and no inserted-dropped frames  ? Is it normal to search dropped frames to find inserted ones and to label them the same?
|
|
| jevans6964 |
| Posted: Mar 21 2006, 05:49 PM |
|
|
Unregistered
|
| QUOTE (stephanV @ Mar 21 2006, 07:47 AM) | This is handled by the DivX codec. VirtualDub doesn't even know you are doing a multi-pass.
With a resolution of 716x404 I would blame the decoder/encoder, not VirtualDub. Although, I don't know why it would work with 1.6.13. |
I was thinking the same thing but the only app. I upgraded before I noticed the problem was VDub. I'll get on the Divx forum to see how the codec handles multiple-pass encodes and whether it wipes those files before starting over with a 1st pass. I'm pretty sure it does since the content and dates on these logs change when a new 1st pass is started.
The errors were there on that 2nd encode BUT in different places, so it IS something random going on with the Divx 6.1 codec. It has been problem after problem with that new codec. All the upgrades between the old Divx 5.2.1 to the 1st update to Divx 6.1 were useless for me since using VobSub subtitles resulted in a crash. I fought with the Divx Team for 4 or 5 months on this trying to convince them that it was the codec, not vsfilter or ZoomPlayer.
So far the encodes using 1.6.13 are clean, BUT I have to to A LOT of viewing to do yet to make 100% sure. Keep in mind that you really have to look to see these artifacts as they can easily be hidden by the bottom progress / button bar ( Zoom Player minimalist skin ) when it is active. |
|
| phaeron |
| Posted: Mar 22 2006, 06:44 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
@frank10:
The confusion is due to what exactly "dropped" and "inserted" means. If the hardware device can't find a free buffer to hold an incoming frame, it drops the frame — which the capture app then has to detect and substitute a dummy frame in the output file. So, depending on which part of the capture process you're referring to, it's either a dropped frame or an inserted frame. There is no indication in the AVI file if the capture app drops an extraneous frame. Only recent versions of VirtualDub report frame drops/inserts as distinct in capture mode, thus the confusion.
@jevans6964:
Try using a video frame height that's a multiple of 16. Most video encoders work in fixed block sizes, and if the frame size isn't an integral number of blocks, it has to pad the bottom and right to a full number of blocks. Normally you don't see this because the extra video data is cropped off on decoding. The manner in which this padding is done can affect the compression of the border blocks, though, and if it's not done well, those blocks may artifact more than the rest of the picture. In particular, using blank or even uninitialized data will result in worse artifacting than extension. If the video codec is failing to initialize that border data correctly, it might explain why you're seeing a difference, as the memory allocation pattern in 1.6.14 is probably slightly different than 1.6.13.
|
|
