|
|
| Monoton |
| Posted: Feb 13 2005, 06:53 PM |
 |
|
Unregistered
|
First my deep thanks to the author(s) and support team of VirtualDub for the excellent program!
Dare to place here a few words of experience that could possibly help to improve VDub even further. All the following relates to my (inexperienced) operation with 1.6.3 and 1.6.4 experimental versions of the program. When VDubing an old MPEG-1 movie (352x288, 25 fps) which contained in the middle a high contrast black-and-white scene -- an artist seen almost "shining" upon a completely black background, about 1 min in length -- I've encountered a strange sudden 'collapse' of the picture. Several seconds after the beginning of the scene the picture suddenly became splashed with a large number of rectangles or blocks, both BW and coloured, with about 25-30% of the frame surface covered by the blocks. The splashes continued about half time of the scene, with grey and white blocks in the lower part of the frame and coloured mostly on the right side (hope this detail could help). This behavior could only be avoided if encoding that very scene completely separately from the preceding movie parts, plus switching on the "Use choma motion" in Advanced settings. However, this didn't work if trying to encode the complete movie. The I-frame rate variation (75-300), bitrate (600-3000 kbps) or pass mode changes (1-pass or internal 2-pass) or codec change (Xvid or MPEG-4 from ffdshow, both January 2005) did not affect the result. What was possibly the most strange for me -- that BOTH input and output screens of VDub showed splashing during the processing, in both passes in 2-pass mode.
The splashing effect is absent in the 1.5.10 version. All the available players do play the movie absolutely correctly, without any annoying blocks or splashes.
There seems to be no solution to the problem in the forum. The problem could also be related to the previous November topic:
http://forums.virtualdub.org/index.php?act...=ST&f=15&t=8332
With my deep respect! |
|
| fccHandler |
| Posted: Feb 13 2005, 08:21 PM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
If the picture collapses in BOTH input and output panes then it's a fault in VirtualDub's decoder, or a bad piece of data in the MPEG-1 file. Your Xvid compression settings have nothing to do with it.
If it doesn't appear in VirtualDub 1.5.10 but it does appear in 1.6.3 then surely something has changed. (The thread you linked to also suggests that.) I asked that guy for a sample of his MPEG, but he never provided it. Are you able to link a small MPEG which demonstrates the problem?
--------------------
May the FOURCC be with you... |
|
| phaeron |
| Posted: Feb 13 2005, 11:08 PM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Yes, a small MPEG sample would be of immense help here. It definitely sounds like a problem with incorrect references in my MPEG-1 decoder.
Do you see any frames in the surrounding area that show up as [r] next to the timestamp at the bottom? This is called a "broken link" and indicates frames that are marked as non-decodable due to editing. Support for these is relatively recent and I might have goofed up there.
|
|
| Monoton |
| Posted: Feb 14 2005, 04:06 AM |
|
|
Unregistered
|
Thanks for your prompt replies. Sorry I'm not so fast - living could be a dozen hours away  . I understood a picture could help, and thus had made one earlier when was trying to find out who's guilty. Could you please advise me how to transfer it or even a file of that scene? I'm new to the board and could miss - is there a possibility to post a screenshot or a movie clip? Maybe this could help other people guess that they were meeting this too. I also could send these to someone's mail within a few hours from now - please advise me.
With best regards! |
|
| Monoton |
| Posted: Feb 18 2005, 04:34 PM |
|
|
Unregistered
|
To continue the topic from Feb.13 concerning flashes of rectangles observed when processing an MPEG-1 file with latest versions of VDub: below I give references to a cut of that original MPEG movie that contains the scene, and to a VDub screenshot showing splashes. In addition:
(1) I have checked that behavior with a number of machines, and found the effect being stably present in all cases. Since roumors were that different code optimisations could lead to different errors on Intel vs AMD based machines, I also tried processing on computers of different platforms, and found the 'splashing' behavior to be platform-independent. None of the two grands can relax.
(2) The same piece of the movie, which was cut off the original file by TMEGenc via "MPEG tools" (h-m, I've had discovered a lot of new related software for myself), if saved without the sound track, was always processed absolutely normally, without any splashes. Sound's interesting?
(3) A note on the file hosting: the hoster informs that downloads cannot be resumed, so don't use any multichannel download program. Next, there's an 90-second delay built-in in the download pages - don't worry, it's a feature and not a bug. Hope the thing will work.
Link to the page with a splashing screenshot:
http://rapidshare.de/files-en/638795/VDub_...enshot.jpg.html
Link to the page with the 23-sec scene (3 seconds before the scene were found to be necessary), 3.7 Mb in length:
http://rapidshare.de/files-en/638979/Cut_f...r_VDub.zip.html
Hope this will be of help,
Monoton |
|
| fccHandler |
| Posted: Feb 19 2005, 12:53 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
That's gotta be a VirtualDub 1.6.4 bug. It's weird though, because I only see your "splashes" the first time I play through the video immediately after starting VirtualDub. The second time I play it, no splashes. Or if I step through the whole video frame-by-frame, and then play, I see no splashes.
My guess is that some decoder element (which gets initialized later) is not being initialized at first playback.
--------------------
May the FOURCC be with you... |
|
| Monoton |
| Posted: Feb 19 2005, 05:01 AM |
|
|
Unregistered
|
fccHandler:
I actually saw no rectangles if playing by VDub (could never see these), but instead in the AVIs output, no matter what codec (tried 6 or 7), but very reliably, not only during the 1st run. Only once I did saw the absence of the splashes during my test encoding, which immediately came back again on the next try.
Monoton |
|
| phaeron |
| Posted: Feb 19 2005, 06:01 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
It turns out that when this occurs is entirely random, and it's only by chance that it happened here.
The bug itself has actually been in the code base since 1.5.5, when I rewrote the MPEG-1 decoder. The decoder detects the end of a frame, or rather a slice, by detecting 23 zero bits after a macroblock. It used to be that the decoder would append four bytes to the end of the source data to ensure this, which was rather nasty; in the second decoder I made this part of the parser instead. Or, rather, was supposed to. It's not being initialized properly anymore which means that the decoder is running off the end of the frame and decoding garbage instead. Problem is, I significantly improved the error recovery logic in the decoder, so 99% of the time it detects the error and kills the decoding before it can screw up the frame.
It just happens in this case that when buffers are aligned properly -- which is more likely to happen if you have a fast system -- the reused frame buffers produce a frame which contains 00 00 01 01 within the last four bytes of the frame, which causes the MPEG-1 decoder to restart decoding of the frame from the top. (The overwrite is allowed because that also happens when slice recovery occurs.) If your system is slower or you are scrubbing on the timeline, the data doesn't line up in this configuration and the bug doesn't occur.
Thanks for the bug report. It'll be fixed in 1.6.5.
|
|
| fccHandler |
| Posted: Feb 19 2005, 08:06 PM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
P.S. I noticed another bug while playing with this MPEG, but I forgot to post it above. When I click the next and previous keyframe buttons, they take me to b-frames.
--------------------
May the FOURCC be with you... |
|
| phaeron |
| Posted: Feb 19 2005, 10:14 PM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Hmm.... that one's actually a display bug. It's using the stream number to look up the frame type rather than the display number. If you check the frame numbers of the key frames against 1.5.10, they're actually correct. |
|
