Re: [GATOS]Re: Displaced frames in captured video with ffmpgeg and km: AIW PRO 8MB

[Nikolai Z. <s0...@ho...>]

Hi Francisco,
Sunday, 18 April, 2004, 20:33:15, you wrote:
[...]
> Video: End of filestem load 30.9 %  
> 2:00 (35.5 MB), system load 30.9 %  
> Audio: End of file
> 2:00 (35.5 MB), system load 30.9 %  
> mp1e: Done.
> 1+0 records in
> 1+0 records out

> Results:

> 1. When I start xawtv or avview, the overlay winodow has less pixels that
> the real capture window. I mean that I can't see the hole video
This happens to me sometimes too, I'm too lazy to dig into it as
it can be "cured" by maximizing and then restoring xawtv, on my
box at least. I think it is just overlay scaler gets misconfigured.

> picture/frame, only one part is displayed in the window. If I choose PAL
> encode and S-VIDEO input and close xawtv settings menu, the video overlay
> shows more pixels (The hole PAL frame, altough using the same window size,
> and therefore I suppose that prevousy only part of the frame was shown and
> scaled to fill the window). Well, all this explanation is to say that the
> captured video doesn't cover the full frame size.  I think that is cropped
I'd suppose it is more likely that you need to specify more exact
arguments to mp1e, depending on your video standard. mp1e tries to
automatically correct capture size if the requested/default value
can not be used as is, but typically this automagic will only provide
some very _minimal_ usability.

> in the X axis (horizontally, perhaps 640 pixels instead of 720??). I don't
> know if it is also vertically croped because that effect is less
> noticiable.
Most likely cropping 768 to 384 (horizontally) happened in your case.

> 2. There are no displaced frames. WOW!
> 3. There appear to be some dropped frames as the movement is sometimes
> choppy, but the audio is more or less on sync.
mp1e should have reported framedrops percent then.

> 4. This time, no machine lock-up.
Cool!

> Conclusions:

> 1. Something in your code works avoiding the displacement effect in actual
> km code.
> 2. ffmpeg doesn't work with it.
This is really strange. I haven't used ffmpeg for some time but
still I'd suppose it should work. Perhaps you might need to adjust
arguments you specify for ffmpeg.

> 2. There seem to be dropped frames and some part of the frme is cropped
> out (problem with PAL settings?).
See above.
-- 
Best regards,
 Nikolai Zhubr