View Full Version : XviD decoder will not drop frames properly
agraham
23rd February 2005, 06:21
I'm having a problem with the XviD decoder:
I'm playing movies on my crappy 366MHz notebook, and it's only got the power to render about 75% of the frames on your typical episode of 24.
But instead of dropping 25% of the frames, instead the video plays 25% slower than normal. The audio plays at the normal speed. After about ten or twenty seconds when they are a few seconds out of sync, the audio will skip skip skip in order to slow down and let the video catch up, or more rarely, the video will jump up to the next keyframe in order to catch up. More rarely both will happen.
Now I know that for technical reasons you can't just drop drames out of MPEG movies (each frame is a delta from the previous one) unless a keyframe occurs...
But the thing is the XviD decoder is passing right over most of the keyframes without using the opportunity to catch up. I've looked at the movie in VirutalDub and there is a key frame every couple of seconds, with every scene cut, just as you would expect.
As a test, I decoded an ep and reencoded it in DivX 5. When I play the DivX movie, the CPU is maxed out and the stats show that many of the frames are being droppped. But the video looks great except for the odd bit of choppyness. The audio and video tend to stay in sync since (I assume) the video catches up with every keyframe.
This isn't a good solution for me tho, since I have to encode all night long on this hunk of junk just to watch one episode.
So... Is this an actual bug in XviD? Is the decoder unable to look ahead in the stream to see if there is a keyframe and if so, to drop invervening frames if the video stream is behind in real time? Or is there a setting somewhere that I can turn on to make it behave like the DivX decoder?
I've tested this in Zoom player, MPC and WMP9.
Ark
23rd February 2005, 09:55
AFAIK Xvid decoder is not (yet) fully optimized for speed, so we only have to wait, developers are working on other things ATM.
This is because IMHO if your system can't fully reproduce all frames in a video, the output will be not good whatever is the way the decoder handles them... so i'll not call this a "bug"!
*.mp4 guy
23rd February 2005, 10:02
Considering The amount of encoding time it takes to make these files why not just reduce the resolution suitably to speed up encoding/decoding performance? This seems like the best solution to me.
Ark
23rd February 2005, 10:07
Also remember that options like Qpel, B-frames and GMC make decoding slower
stephanV
23rd February 2005, 11:09
you can also try a less cpu intensive decoder like ffdshow. Or use a player like VLC. turn off pp too.
akupenguin
23rd February 2005, 12:58
B-frames do cost a little extra CPU-time, but in this case they would actually help: You can skip decoding of some or all B-frames if needed, without messing up any other frames.
But if you're encoding only for playback on slow computers, then yes, use lower resolution and no qpel/gmc.
Sharktooth
23rd February 2005, 13:27
... or standalone software players based on linux, such as Movix or Geexbox.
Just download the ISO, burn it, boot from that CD-Rom and insert the media containing the movie. *BANG* you're done :)
Prettz
23rd February 2005, 21:11
Originally posted by Sharktooth
... or standalone software players based on linux, such as Movix or Geexbox.
Just download the ISO, burn it, boot from that CD-Rom and insert the media containing the movie. *BANG* you're done :)
I don't think it's fair to say "*BANG* you're done" after such a large list of time-consuming steps. :rolleyes:
agraham
24th February 2005, 04:54
I think my point was missed, so let me restate it a bit simpler:
If I play an XviD movie that maxes out my CPU the video plays too slow, but the audio doesn't. This makes them go out of sync instantly and it's impossible to watch.
If I play the same movie encoded with DivX, the video and audio both play at the correct speed.
DivX drops frames when CPU load is over 100% wheras XviD just slows down.
The DivX behaviour is _much_ better since the movie is actually watchable.
If I want to reencode the movies, the best thing for me to do is encode them in MPEG-2 since my MPEG-2 decoder has hardware support on my laptop. I can watch the movies full rez full frame rate with only 75% CPU usage.
But if I don't want to reencode the movies, I can only watch DivX movies, not XviD movies, since the XviD ones are unwatchable.
So I guess I was hoping someone would have a miracle button I could press which would make XviD's behaviour like DivX's when the CPU is pegged.
I guess that ain't happening, so I'm putting the call out to XviD developers if any are listening: the DivX behaviour in this case is much better than XviD's, so if there's any way to copy it, that would rock.
stephanV
24th February 2005, 10:13
then why dont you decode XviD with DivX (or try ffdshow as i mentioned earlier)? Its all MPEG4...
agraham
25th February 2005, 10:40
I did some tests and had some interesting results:
I took a 913 frame snippet from a "24" XviD and used three different decoders in ZoomPlayer (all post-processing was turned off, and overlay support was confirmed on):
First I used the default XviD codec: result: ZoomPlayer reports that 773 out of 913 frames were rendered. Looked like crap, played about 20% slow. Sound out of sync.
Then I tried the DivX codec. I did this by checking "Support Generic MPEG-4" in the decoder properties. result: the same. 792 frames out of 913 rendered. Plays slow. Out of sync. This was a surprize to me. I thought the DivX codec would play it right.
Then I tried the ffdshow/libavcodec. result: crap. 536 out of 913 frames rendered. Only half the video had played when the audio stream ended.
So then I thought.. maybe the difference is that qpel and gmc stuff. So I reencoded the snippet using XviD's default settings (QPEL off, GMC off) but with target bitrate of 1610.
Through XviD and DivX codecs:
Better, but still not great. 850 out of 913 frames rendered. Sync off a bit.
Through ffdshow/libavcodec:
Crap once again. Barely half the frames rendered.
I made another compression, this time turning off B-VOB (which is b-frames, right)
Results:
Through XviD:
Definately better than with B-frames on. This one is almost watchable.
Through DivX:
Not bad at all. Most scenes are clipped by a few milliseconds, as the decoder jumps up to the next scene, but the audio for the most part stays in sync. Definately watchable.
Through ffdshow/libavcodec:
Crap.
So finally I figured since the XviD and DivX decoders are pretty evenly matched, it must be XviD vs. DivX files themselves, not the decoder that makes all the difference, so I made another encode using DivX, default settings, but once again with a bitrate of 1610.
Through XviD codec:
I couldn't figure out how to play this video through the XviD codec. I selected "DivX FourCC Support" in the decoder props, but the DivX decoder still takes it.
Through DivX codec:
Great. Probably the best so far. ZoomPlayer reported that every frame was rendered, but I know that's not true because it was doing the typical "catch up at everyframe" snapping. But it looked fairly smooth and the sound stayed in sync to withing a few milliseconds all the way through.
Through ffdshow/libavcodec:
Surprize! It was crap.
Lessons:
- when encoding for underpowered systems, in theory B-frames should make things smoother because they can be dropped, but in reality they don't because they aren't
- DivX decoder beats XdiV for underpowered systems, but it's a close race.
- DivX files play better than XdiV on underpowered systems, byte for byte.
- ffdshow has a rep for efficiency that doesn't seem to hold up in this case
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.