Log in

View Full Version : Major problem - choppyness!


Wolferous
29th March 2004, 21:39
Recently I have tried using the XviD 1.00RC3 codec, without any luck whatsoever. All the videos I encode, turn out to play back with jerky/choppy video, not smooth at all. I have been unable to figure out the source of my problem.

The source is progressive and film, whereas IVTCing is the right thing to do. If I do not IVTC, I see the obvious interlaced frames, when scrolling through virtualdub frame by frame, whereas if I IVTC, every frame looks good.

The choppyness results whether or not I add the audio, obviously even more choppy with the audio, especially if it is AC3 audio. One thing that has been suggested to me is that I am using the wrong interleaving values when I mux the audio stream into the video, but this is not the case, I use a preload value of 64ms before the video starts, and interleave every 64ms. It is choppy without audio anyways, so that is irrelevant.

I have noticed the videos I encode, they play significantly more smoothly if decoded with XviD 1.00beta3, than 1.00RC3. But nevertheless, it is STILL rather choppy.

I used to use 1.00beta3 exclusively, then I decided to try RC3, this is when my problems arrose. When I encoded movies/videos etc, in 1.00beta3, the result was always very smooth, when played back. I decided to uninstall 1.00RC3 and go back to beta3, but the problem remained! Now my 1.00beta3 encodes are choppy, even if I try using an older version of XviD. I am very frustrated!! I am considering formatting my machine and starting all over, never to touch 1.00RC3 ever again.

Previous encodes I did with 1.00beta3 in the past when I had no problems, still play smoothly, if I decode them with 1.00RC3 or 1.00beta3. But now that I have this problem, if I encode a video using 1.00beta3, it plays back choppy even when decoding with beta3, not nearly as much as if I encode with 1.00RC3 and decode with 1.00RC3, but it is choppy.

It doesn't matter if I do 1cd or 2cd rips (about 800-1400kbps is the bitrate). I've noticed that the encodes I do with 1.00RC3 are choppy in any scene where there is motion, whereas (now that I have this strange problem) 1.00beta3 encodes are choppy but mostly only in scenes where the camera pans and the whole picture on the screen changes (It wasn't like this until I installed 1.00RC3 and then uninstalled it and went back to 1.00beta). I noticed that previous encodes I have done using beta3 that turned out to be smooth, in places where the camera makes a huge pan and the whole picture changes, it is a smooth transition. I approximated the distance in pixels of how far objects were moving in the scenes where there's a huge camera panning in encodes I have done previously in 1.00beta3, and encodes that I now have been trying to do in beta3. Frame by frame analysis shows that the panning in both (differnt videos however) are about the same, but the encode I did previously when played back in windows media player, is smooth, whereas my recent encode using the same codec is choppy!!

NO I am not using fddshow filters at all, I completely uninstalled that codec, I uninstalled the divx3 codec as well, along with deleting the .ax files that go along with them and unregistering them acordingly if it was needed. I am starting to run out of ideas, if I try to lower the resolution in which I encode, it doesn't make any difference.

I have a celeron 1.1ghz, with 512mb of ram, when the video plays back choppy, CPU usage is only around 50%, so I don't think CPU here is the issue.

Any ideas? Anyone?

Someone suggested to me that I should disable b-vops (b-frames), I haven't tried this yet, but will soon.

Wolferous
30th March 2004, 01:10
I figured it out!
All I had to do was disable b-frames! (B-VOP)
and problem solved
:)

lordadmira
30th March 2004, 02:58
Hmm. Using B-frames "shouldn't" cause any problem like that. I rig my encodes to make as many B frames as possible and they play back fine(except bugs) at DVD res on Celeron 1.4.

Wolferous
30th March 2004, 03:07
they shouldn't, but they do, I tried messing around with the settings for the B-frames, and nothing I did helped the problem, so for me, the solution is to just not use b-frames at all then.

gizmotech
30th March 2004, 12:41
Even though you've said you've removed ffdshow it doesn't sound like it.

Every problem I've ever heard of w/ users relating to b-frames has been to the ancient builds off ffdshow that either didn't correctly support b-frames, or packed bitstream was enabled.

Either way, I'd search a bit more on your system before disabling the feature.

gizmo

malkion
30th March 2004, 13:30
might this be a packed bitsteam issue found under B-VOPs settings, instead of b-frames itself (with it's related fix elsewhere)?

communist
30th March 2004, 15:48
Originally posted by malkion
might this be a packed bitsteam issue found under B-VOPs settings, instead of b-frames itself (with it's related fix elsewhere)?
Older ffdshow builds are known to not properly playback xvid streams with more than 2 consecutive b-frames if packed bitstream was enabled for the encode. Either turn it off or use newer ffdshow build that have this issue fixed to decode - shouldn be problem anymore :)

Wolferous
1st April 2004, 02:53
I am NOT using fddshow filters! I completely removed them.
When I play back XviD videos I encode, I go into the properties in ms media player and I see that Xvid MPEG-4 decoder is decoding the video, no instance of fddshow is in there.

As far as 2 consecutive b-frames goes, I get this problem wiht 1 consecutive b-frames as well.

I did notice however, that I had packed bitstream enabled, perhaps this was my problem! I will go do some testing.

Mango Madness
1st April 2004, 07:33
try using the latest cvs builds. Use MPC to playback. Encode with mkv and see if the problem arises.

communist
1st April 2004, 15:41
Originally posted by Wolferous
I am NOT using fddshow filters! I completely removed them.
When I play back XviD videos I encode, I go into the properties in ms media player and I see that Xvid MPEG-4 decoder is decoding the video, no instance of fddshow is in there.

As far as 2 consecutive b-frames goes, I get this problem wiht 1 consecutive b-frames as well.

I did notice however, that I had packed bitstream enabled, perhaps this was my problem! I will go do some testing.
If you are really using XviD to decode then packed bitstream + more than 2 consecutive b-frames should not be the cause of the problem.

Wolferous
2nd April 2004, 05:26
Originally posted by Mango Madness
try using the latest cvs builds. Use MPC to playback. Encode with mkv and see if the problem arises.

what are the latest "cvs" builds?
what is "mkv"?

xlee
2nd April 2004, 09:59
Use Media Player Classic. Go to Options->Filters->Overrides and make sure XviD MPEG-4 Decoder is checked.

I would be careful using Matroska (mkv) for testing purposes. You can get "choppy" frames with the wrong Matroska splitters.

jimmy basushi
2nd April 2004, 23:53
are you using avi container or mp4 ? mp4 have b-frame problems.

use matroska(mkv) and use the pack (http://packs.matroska.org) for decode. newest ffdshow is fast, and work well with xvid. get from here (http://athos.leffe.dnsalias.com/)

Wolferous
3rd April 2004, 03:15
I use MS Media Player 6.4.09.1128
I have yet to try matroska.

My problem seems to have been fixed, I can now encode using B-Frames, as long as I keep 'Packed bitstream' UNCHECKED, what does it do anyways? And why was it causing problems with choppy playback?

I have noticed, when I previously had encoded video using packed bitstream, not only was it very choppy when I played it back, but my CPU usage was ~50-60%, which doesn't make much sense.

bond
3rd April 2004, 14:03
Originally posted by jimmy basushi
are you using avi container or mp4 ? mp4 have b-frame problems.why should mp4 files have problems with b-frames?

SeeMoreDigital
3rd April 2004, 14:13
Originally posted by jimmy basushi
...are you using avi container or mp4 ? mp4 have b-frame problems. This is not true at all.

Obviously you are not up to speed regarding the .mp4 container. I suggest you refer to bonds excellent information about it. And then come back and say sorry!

Cheers

bond
3rd April 2004, 14:15
Originally posted by SeeMoreDigital
And then come back and say sorrylol, no need for that of course :D

jimmy basushi
4th April 2004, 11:43
sorry, i was refering to this thread (http://forum.doom9.org/showthread.php?s=&threadid=69339&highlight=b+frame+mp4) but i took it out of context again. i also remember seeing a conversation about b-frames in mp4 that showed a lag but i search and cant find it.

i read this site to improve my english i still make mistakes and read wrong tho.

SeeMoreDigital
4th April 2004, 12:01
Originally posted by jimmy basushi
...i read this site to improve my english i still make mistakes and read wrong tho. No problem!

I read stuff wrong all the time too. And I am English :)

The sad fact is, there has been a lot of bad mouthing regarding the .mp4 container. And like with most bad mouthing, even when it's subsequently proved to be wrong, the "mud sticks"!

Lets hope we can make you into another convert.

Cheers

bond
4th April 2004, 12:06
Originally posted by jimmy basushi
sorry, i was refering to this thread (http://forum.doom9.org/showthread.php?s=&threadid=69339&highlight=b+frame+mp4) but i took it out of context again. i also remember seeing a conversation about b-frames in mp4 that showed a lag but i search and cant find itthe problem is not caused by the mp4 container but by a bad muxer (mp4creator and the on it based mp4ui) which isnt able to correctly mux b-frames into mp4 sometimes

HalfHuman
8th April 2004, 15:48
that choppiness thingie can be solved by deactivating the damn "packed bitstream". do not deactivate the whole b frames thingie cause u know those really help.
i did a 2h30m encoding on one cd
it looked horrible without those b-frames no matter how much i shank the image.
greets.