Mpeg encoding from a DV format causes more blockinessgreenspun.com : LUSENET : Video CD : One Thread |
Does anyone know if DV video cameras do some sort of data compression?? I have been making MPEG files from my VHS tapes by capturing with a DC30 card, then using the Panasonic MPEG encoder. The results have been fairly good. But I just bought a DV camcorder, and I thought that since I can now capture from S-video out of this camera with higher resolution, I would get better results. However, there seems to be a LOT more blockiness around moving objects in the encoded MPEG file. Much more than from VHS composite inputs. I am wondering if this is because of compression used by the DV format.Any Clues??????
-- Bruce Kuhn (bkuhn@westell.com), January 13, 2000
Bruce since no one else has commented......I assume you are capturing using the same DC30 settings, are you using square pixels or the Dig format option? The quality of course gets better as the data rate goes up. I would suggest that with analogue captures at full frame you need to achieve at least 4M/s to complete with what DV at 3.6M/s gives as a source for VCD's. Svideo inputs to the DC30 in general will be of a higher standard than composite and I do not think they should be mixed as I get the impression your using svideo for your DV and composite for the other which may require different source setting to get the best result.
Using the Svideo connection will generally show up more faults than the composite. The comp output can be of a much lower standard than the Svideo even though the spec may quote 400+ lines. Actually my friends TRV 900 Sony was very different on composite output, amazing when it was of a lower standard under test than my D8 which cost half.
I have a DC20 (5 years nearly) and that only has the square pixel option but my DV analogue captured/edited vision was better than I got from a straight hi8. I currently use the DV Pyro so the DC20 has now been put to rest in the rubbish bin, I always wished I had a DC30 as I would probably not gone digital because the results would be better than my 3M/s DC20 vision.
My videocd's have been great from both sources but at times I have had problems with slow pans or zooms being blocky or full of artifacts when converted to VCD - I am using the Panasonic encoder waiting for LSX to get it right for mpeg-1 in an update of version 3. One of the best checks of any encoder is the slow pan & zoom and some fail the test completely. You will need to experiment to get the best of both worlds.
-- Ross McL (rmclennan@esc.net.au), January 17, 2000.
Ross,Thanks for the response. Yes, I am using the same settings, and I have tried both square and rectangular pixels. I have a SCSI video hard drive, and use a VERY fast data rate. I have been capturing at 4:1 compression at full screen (640X480), or at 2.5:1 at half screen 320X240). 2.5:1 at half screen is the fastest the DC30 will allow. The DC30 capture with the Panasonic encoder has worked great so far. When I record off of DVD with s-video, and make a VCD, the picture quality is great!! It has not been bad with my old 8mm video camera, so I just assumed my new DV camera would be better. Instead it was worse.
I did notice when I play back from the DV camcorder, there is a white outline around moving objects. It is very faint, but it is there. It seems as though this is what is causing the blockiness when converting to the MPEG stream. Since I owned the DC30 before I bought this new camera, I thought I would just do the analog capture. I have not yet bought a firewire card to try transferring the DV info to the computer, because I do not have any free slots available. But, I may pull out a card just to try that.
Bottom line is that I am very happy with the job the DC30 and Panasonic encoder have done in the past. I'm just trying to find out why it is so bad with the DV camcorder. BTW, I owned a Dazzle DVC before the DC30. It usually did and "ok" job (but not as good as the DC30). So I hooked it back up to see how it handled the output. It looked like CRAP!!! There is something about that signal that MPEG encoders do not like. I just need to figure out what.
Thanks again, Bruce
-- Bruce Kuhn (bkuhn@westell.com), January 17, 2000.
I'm kind of new to this board but wanted to give my story. I have a DV500 and have the same problems you are having with artifacts. I believe the root to this problem (in my case) is the DV camcorder. The picture gets fuzzy indoors (even with what I would think is decent lighting). The fuzzyness gets turned into blockyness when encoding to MPEG. I consulted cannon on this issue and they basically said it is normal to have a fuzzy picture indoors and suggested I add a video light to my Ultura. Is your problem more prevelant with video taken indoors? If so, you might want to try better lighting. I certainly don't claim to be an expert, but I have done a lot of research and tried all kinds of capture boards. I have found the consumer level DV camcorders are not quite as good as I had hoped.
-- JD (hwood99@yahoo.com), January 17, 2000.
I had the same blockiness problem when there was lots of motion. Solved most of it by using VirtualDub to deinterlace and resize the captured image. Unfortunately, VirtualDub doesn't seem to handle the MS DV CODEC, so I had to convert the captured video to UNCOMPRESSED .AVI, then open it in VirtualDub. Afterwards, I used the Panasonic MPEG encoder to create the VCD files.Other editors might be able to deinterlace (blending the fields) also.
-- David Martin (dgmartin@lvcm.com), April 24, 2000.
This may help , the MS-DV codec by default halfs the video resolution it should be 720x576 from most dv cams , this also seems to affect some encoders Panasonic being one of those affected ( check video stated in panasonic), the res can be changed to full by editing the registry as follows ; [HKEY_CURRENT_USER\Software\Microsoft\DirectShow\DVDecProperties] "PropDisplay"=dword:000003e8.try it it really does work ! I do have the registry hack as a file if anyone wants to email me .
Usual warnings about mucking with the registry apply
-- Neil Thrower (neil_thrower@ocsl.co.uk), June 05, 2003.