Why isn't panning smooth

[sbp]

Hi I capture directly from my Medion TV_card Phillips SAA7134 directly into PicVideo MJPEG - quality settings at 15.
But I have problems because whenever the film have some camera panning, then the results is "jerky" - Why is this happening?

I have checked the CPU usage during capture it is about 80% and never reaches 100%.

I have the same problem (a little worse) if I try to capture directly into XVID. And here the CPU usage sometimes reaches more than 90%

(Windows XP Pro, AMD Barton 2500, 512 DDR, 120 GB Maxtor, myHTPC and GotTV)
NB Sound is captured in MP3.
Thanks Steen

[trevlac]

How do you play the clip to see the jerky results?

What is the source footage? eg. a cartoon.

[sbp]

Thanks for the reply

I use Zoomplayer to view the capture, when captured in PicVideo - I use the PicVideo decompressor, when viewing XVID-files I use the XVID decoder.
I have noticed that the CPU usage during decoding rises in the moments when the panning becomes "jerky" - but never more than 60%.

I have also tried to add Reclock direct filter - it doesn't solve the problem - but maybe it is a little better, it's hard to tell the difference.
Steen

[trevlac]

My Guess ...

Zoomplayer is a direct show app. The Microsoft codec may very well be decoding the PIC mjpeg. If I recall, PIC stores the field order differently than MS or Morgan. When there is a pan, this would probably be noticeable even on a progressive display. I'm guessing that Zoom deinterlaces for you. If the source was something that really did not have a high frame rate (like a cartoon), this would probably be worse.

Maybe others can give more ideas.

[sbp]

Ok.

But which encoder do you advise me to try for direct capture from a TV-card?
After reading in this forum many people seems to think that PicVideo is well suited for this.

Steen

[trevlac]

Pic is considered to be very good. I have used it, but not really for playback. You can get the latest version of as little as $14, or at most $28. This one lets you change the field order, in case the one you have does not.

http://www.pegasusimaging.com/picvideofaq.htm#Q5

There is a FAQ where they say make sure it is the default mjpeg codec is checked in the pic config box. You might try that.

I am quite sure that your issue is field order. If you are making the xvid from the mjpeg, you should have some option somewhere for changing the field order before you re-encode. Avisynth can do this for you.

I was hoping someone who actively uses pic would jump in ... and say what happens with directshow playback. I'm not sure if older versions of PIC are direct show.

[Boulder]

Originally posted by sbp
But which encoder do you advise me to try for direct capture from a TV-card?

PicVideo is very good, no doubt. It's just not meant for capturing and then watching, you should encode the captured clip to some other format like XviD, DivX, MPEG-1 or MPEG-2 for playback purposes.

You might also like to try higher settings than Q15, Q19 is generally recommended, even Q18 if HD space is an issue.

[sbp]

Thanks for your suggestions

The field order - I have been reading about this, as far as I could understand, this only seemed important for interlaced material? But do you think I should try to swap field order?

Would it be better to use the Morgan MJPEG encoder?

Finally; I have checked the filter properties from inside Zoom-player when viewing my capture, it is played through the PciVideo Decompressor.

Steen

[Boulder]

Try opening the clip in VirtualDub. Does the motion look jerky when you advance frame by frame?

Your capture might be interlaced or progressive. You'll have to determine it before making any assumptions regarding an incorrect field order;)

[sbp]

I'm sure it is interlaced, it looks OK on the TV, but if I view the clip on my computer monitor there is interlace lines.

I will try to look at the frames in VirtualDub, I'll let you know.

Steen

[sbp]

Hi after vieweing the capture in Virtual dub, it seems to me that the reason for the "jerky" movements during panning is caused during the encoding.
Whenever there is a jerky spot in the capture, I observe two identical frames right efter each other - but how does that happend?

I would have thought that maybe I had lost a frame here and there, but it seems like I have more frames than I should have?

I have also tried to capture in Morgan MJPEG - with similar results.

(I live in PAL country, Denmark) capture at 640x480)

Steen

[Boulder]

Since you live in a PAL country, always capture at n x 576. I suggest 720x576.

So the identical frames can also be found in the capture? That's a dropped frame if I'm not mistaken. These dropped frames could be caused by capturing only 480 lines as the computer or your capture card probably captures 576 lines and then resizes to 480 which is really bad.

[sbp]

OK thanks for your suggestion. I can see that I have the opportunity to capture at 702x576 or 720x576, maybe I should try both.

But how can a dublicate frame be a lost frame, I thought that the encoder simply would drop the frame, and then encode the next one?

Steen

[Boulder]

1) Is the duplicate in the capture file?

2) What do you use to encode the clip?

3) What is your script, if you have one?

4) If you don't use Avisynth, what is your processing method?

5) What encoding settings do you use?

The answers to these questions should help a lot;)

[sbp]

Thanks for your patience

1. Yes the dublicate frame is in the captured file

2. I use a TV-viewing program called GotTV, where you from a drop down list can choose between the installed encoders - here I chose PicVideo,

So 3 and 4. I don't use a script, just press the record button, and then it is recorded directly by the encoder.

5. PicVideo, at settings 16 (I have also tried 18 and 19 dosn't change anything).

To follow up on your latest suggestion, I think that you were correct, it is better to record at 720x576.

Furthermore, I should add that I also compress the audio into MP3 - actually it seems better if I don't and use PCM.
But if I choose Microsoft CCITT A-Law and u-Law it is better than MP3 and nealy as good as PCM-audio (I don't know what these audio-codecs are, but they seem better that the MP3 encoder I'm using now) Lame ACM - an old one, because I can't get the newer ones to work.

So it seems that the audio encoder is also involved. Could it be like the video and the audio encoders sort of encodes at different speeds, so that the video must put in an extra frame, in order to continue to be in sync? Because I have no sync problems.

I have tried to choose different speeds for the MP3 encoder 48, 44 22 kHZ but it doesn't seem to help.

Steen

[Boulder]

Well then, according to the fact that the dupe is in the capture as well, it is a dropped frame. Most capture programs compensate the drop by duplicating the previous frame so that the a/v sync is kept.

When I talked about encoders, I meant, what do you use for final output? In practice, MJPEG and HuffYUV are meant for files that are to be processed further, for example encoded to XviD, DivX, MPEG1 or MPEG2. That's also the reason why you should use Q19 in PicVideo in order to get as good quality source for processing as possible while keeping the filesize smaller than an uncompressed format.

You should also capture the audio in PCM and encode it to MP3 separately, preferably with LAME.

[sbp]

Thanks

I see now what you mean.

The way I use most of my captures is like a VHS, to record a show when you are not at home, then view it once with your family, and then erase it.
Therefore, I don't usualy process it further, only very rarely I capture a movie that I want to keep - and then I use VirtualDub and transcode it to XVID.

Do you know what is the the fastest audio-encoder, for real-time capture?

Steen

[jggimi]

Linear PCM (.wav) format is usually the "fastest" since there is no compression of the audio.

See the Capture FAQ (http://forum.doom9.org/showthread.php?s=&threadid=32575) for a discussion of dropped frames.