|
|
| porcazzo |
| Posted: Oct 14 2002, 12:16 AM |
 |
|
Unregistered
|
hi all
i usually capture movies from my tv (pal, 25 fps)
sometimes they need to be deinterlaced , sometimes not.
static quality is ok
but
almost always horizontal movements are not fluid
tipycal example:
1)a person in the middle of the screen is walking towards left or right
2)he remains in the middle of the screen and the background moves
3) the background is "jumpy"
how can i fix this ?
should i increase the frame rate and insert "missing", interpolated frames?
thanks  |
|
| fccHandler |
| Posted: Oct 14 2002, 05:56 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
 Hello, and welcome to the forums!
Your problem sounds like telecine to me. If so, a proper "inverse telecine" might fix it. Unfortunately, I'm NTSC here in USA, and I'm not sure how telecine is utilized in PAL broadcasting (or even if it is). A search on the Web might help. Otherwise, let's just hope some PAL people respond.
--------------------
May the FOURCC be with you... |
|
| Morsa |
| Posted: Oct 14 2002, 11:04 PM |
|
|
Moderator of the Vdub support board
Group: Moderators
Posts: 640
Member No.: 246
Joined: 9-September 02
|
Pal doesn´t need pulldown and that sort of things.
A film (24 fps) is converted to Pal as 25 fps directly.
So you end with 25 full frames and a movie 4% shorter.
Sometimes with a homemade telecine you may got some problems with some fields (50 fields per second), but not with professional telecine. |
|
| Stefan |
| Posted: Oct 28 2002, 03:37 PM |
|
|
Advanced Member
Group: Vdubmod Alpha Testing Team
Posts: 215
Member No.: 142
Joined: 27-August 02
|
Where do you see the errors?
When you see the error on TV and with deinterlaced video only, then the field order might be wrong.
Try to produce two output videos. One with and one without VD internal filter "field swap" applied before you deinterlace. Compare the results on TV again.
Problem still there? OK. Then the hard way. There are 8 different "sources" for this type of problems. All these problems can be solved with patience and the advanced processing options of the "smart deinterlacer (Donald Graft)" filter.
Stefan
|
|
| pathfinder |
| Posted: Oct 30 2002, 04:28 AM |
|
|
Unregistered
|
Unfortunately the author of the original question didn't mention if the jumpy capture is accompanied with massive (4-5 successive) frame loss on the jumps. I had a similar problem until yesterday - the scene behind a person in the center of the screen would jump as it moves. And it would happen even during preview (without capture!!!) During capture (even with audio-video synch turned off) the jumps would be accompanied with frame loss. The weird thing was that massive frame loss occurred mostly when the amount of movement in the movie was moderate - the background scene moved neither too fast nor slow. It was weird because during preview no software codecs are used and while capturing only huffyuv is used which doesn't aim to process movement.
Yesterday I found that in my case it was caused by setting 'Maximum Bandwidth' in the capture device options to 7 MB/s (maximum offered). It's unlikely that my computer (PIII 850 MHz, audio captured through the sound card) was not able to eat the stream. Then most probably it's caused by the chip in the capture device. I remembered that in Nogatech's/Zoran's documentation to USBVision chip (I use Belkin's Video Bus II) they mention somewhere that the chip has an internal buffer to store frames until the USB interface is ready to transfer them and if the interface doesn't catch up with frame production rate the chip will have to drop them. In some other place they say that the chip compresses each frame with ratio of about 1:11. I doubt that their proprietory compression algorithm is dependant on the amount of movement in the scene, still it's seems to be the only logical point in the preview process (overlay) where frames may be dropped, since the rest of the system is never loaded more than 3-5 % while preview. Perhaps the chip's compressor doesn't catch up with frame digitization rate. Lowering maximum bandwidth to 6.5 MB/s changes something in the chips compression parameters (also mentioned in the documentation), an the system looses no more than 5 frames per 15 minutes of TV signal capture which looks to be accidental (audio synch turned off). By the way, 6.5 Mb/s was the default bandwidth right after driver installation.
Another possibility of jumpy scenes and frame loss could lye in poorly filmed/broadcasted video. If there are TV specialists here, I'd appreciate, if you could advise, what will happen on TV screen if a TV set doesn't receive field/frame synch impulses in the TV broadcast or if a frame is not transmitted by a VCR? Will it blink?
|
|
| Kippesoep |
| Posted: Oct 30 2002, 03:31 PM |
|
|
Moderator of the Virtualdub support forum
Group: Moderators
Posts: 447
Member No.: 441
Joined: 6-October 02
|
An imperfect source might cause dropped frames, but I think the limited bandwidth of the USB bus is to blame here. If the resolution is too high, there is simply more data than can be transmitted over USB, even after compression and frames must be dropped. Dropped frames are very noticeable when panning. |
|
| pathfinder |
| Posted: Oct 31 2002, 03:57 AM |
|
|
Unregistered
|
Right, they are most noticeable during panning!
However, I wonder how USB bandwidth could be blamed when out of 12 MB/s of total USB bandwidth only 7 MB/s are used for video data pipeline. Especially considering that the manufacturer designed the device to transmit 7.5 MB/s (stated in the documentation for the chip) of video data, plus additional 512 kB/s for audio and 2 Mb/s for 'bulk data' (can't remember clearly, but sounds like teletext). |
|
| Kippesoep |
| Posted: Oct 31 2002, 06:33 AM |
|
|
Moderator of the Virtualdub support forum
Group: Moderators
Posts: 447
Member No.: 441
Joined: 6-October 02
|
USB bandwidth is not 12 MB/sec, but 12 Mb/sec (1.5 MB/sec). That's not enough for full-resolution uncompressed video.
|
|
| pathfinder |
| Posted: Oct 31 2002, 09:18 AM |
|
|
Unregistered
|
So what's the USB bandwidth? I am a bit confused with the last post. Right 7 MB/s is not enough for full resolution uncompressed video, but I was actually speaking about 352X288 (quarter resolution) 25 FPS hardware compressed video. 7 MB/s must be enough for that, since the manufacturer decided to burn this algorithm in a chip. And with all mentioning of the 'additional' pipes for audio and bulk data, I forgot to say that I don't use them, thus leaving 42% of the USB bandwidth unused - isn't it a safe margin to guarantee that USB bus will never get congested? |
|
| pathfinder |
| Posted: Oct 31 2002, 09:24 AM |
|
|
Unregistered
|
Ok, I was wrong, the video data pipeline is 7Mb/s and not 7 MB/s (I checked the specs for the chip again) |
|
| Kippesoep |
| Posted: Oct 31 2002, 05:17 PM |
|
|
Moderator of the Virtualdub support forum
Group: Moderators
Posts: 447
Member No.: 441
Joined: 6-October 02
|
352x288 = 101376 pixels,
@25fps = 2534400 pixels/sec
7Mb/sec = 917504 bytes/sec
that means you have less than 3 bits per pixel. All colour spaces (RGB, YUY etc) available will use much more than that. The only compression that may be successful is (M)JPEG, which is commonly available on USB devices. As you can imagine, though, it's a pretty tight fit. I'm not surprised frames are dropped. |
|
