Re: grey squares on video

Dan Dennedy <[email protected]> Tue, 26 Jan 2010 11:31:14 -0800
Newsgroups gmane.comp.video.kino.devel
Message-ID <[email protected]>
On Tue, Jan 26, 2010 at 10:28 AM, Gene Heskett <[email protected]> wrote:
> On Tuesday 26 January 2010, Carl Karsten wrote:
>>On Tue, Jan 26, 2010 at 11:53 AM, Dan Dennedy <[email protected]> wrote:
>>> On Tue, Jan 26, 2010 at 6:08 AM, sattress <[email protected]> wrote:
>>>> Hello,
>>>> I am a kinetic sculptor that works with discarded technology. I make
>>>> videos of my sculptures, particularly those that are hired by
>>>> restaurants. I have
>>>
>>> That is awesome! The picture you attached is intriguing.
>>>
>>>> used windows (found copies of win 98SE and W2k). I am trying to move to
>>>> linux. The last hurdle, and the one that I have failed to clear multiple
>>>> times is capturing video. I have been lent a Panasonic NV-DX100 digital
>>>> video camera (PAL/dv) and have made many videos that other have enjoyed
>>>> using u-lead and nero.
>>>>   In shifting to Linux, I have run kino on different PC's and laptops
>>>> with different distros. I can capture and make mpeg files. At all
>>>> stages, and in all my attempts, I have five grey squares that sit
>>>> solidly and
>>>> unattractively through all the stages of capturing editing and
>>>> rendering. I
>>>
>>> I think I have seen the problem you describe, but I do not see it in
>>> the image you attached. Is it supposed to be in the image, or was that
>>> just a promotional image?
>>
>>I think I see it.   I circled 2 examples.

I was trying to say that if there is a problem in the image sent, then
it is not the same problem I have seen with corrupt or missing DV data
most likely during capture. Of course, I saw the quantization
blockiness of the JPEG compression. He also claimed he sees this
problem in Kino during the playback and editing before any more
heavily compressed exporting.

P.S. The capture code intentionally maintains a static buffer of the
size of one DV frame, and then it places each packet received by
FireWire into its proper place in that frame buffer. That way, if
there was some missing packets, then the packets of some previous
frame may very well likely be there. This gives the impression of
"holes" in the frame where you can see parts of a previous frame, but
it will at least keep some DV in there to keep it constant bitrate and
therefore easy to seek and edit. It ought to also make decoders
complain less and not crash.

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com