b-frame stuttering with x-card playback

[sapient]

I have noticed that enabling b-frames in xvid (I am using the new xvid 1.0 beta2) results in visible stuttering of the video, when I play it back with my x-card. The problem disappears when I disable b-frames and is not visible at all when I play back the file with the xvid or ffdshow decoder. The problem does not seem to affect divx (version 5.11) as there is no stuttering with or without b-frames on the same clip encoded by divx.
Any idea why? Is this already known? Can it be fixed?

[sysKin]

Originally posted by sapient
Is this already known?YesCan it be fixed?Sure, just enable packed bitstream.

Radek

[sapient]

Thanks for the answer... I was away for the holidays and I just saw it.

I have already tried using the packed bitstream option but it made absolutely no difference. The stuttering was still there when playing back with the x-card. I was told in sigma's forum that xvid b-frames are not fully mpeg-4 compatible and that is the reason for the stuttering. Is this true?

[new_age]

Hello!

I've got the same result with playing xvid with b-frames on ESS based desktop dvd/mpeg4 players. (Like philips 737)

And only xvid b-frames! divx5 b-frames are ok.

NA

[Leak]

Originally posted by new_age
I've got the same result with playing xvid with b-frames on ESS based desktop dvd/mpeg4 players. (Like philips 737)

And only xvid b-frames! divx5 b-frames are ok.

Did you use the default B-frame settings for XviD? Most of the players using older chipsets can't cope with more than 1 B-frame and will play those in the wrong order (if at all), causing stuttering. The "problem" with DivX here is that it normally only uses 1 B-frame and thus doesn't cause this problem.

Try setting "Max consecutive BVOPS" to 1 and it should work, but of course you lose some of the space savings you get with more than 1 B-frame - but that is hardly XviD's fault.

(Disclaimer: I don't have a standalone DivX/XviD player yet, but this is what I read about the problem in this forum.)

np: Triosk Meets Jan Jelinek - One The Lake (1+3+1)

[new_age]

I've tried these settings:

(0)

BVOPs OFF

(1)

BVOPs:
----------------------------------------------
Max consecutive BVOPs: 1
Quantizer ratio (%): 1.50
Quantizer offset: 1.00

Packed bitstream: OFF
Closed GOV: ON
----------------------------------------------

(2) xvid default (except packed bit off)

BVOPs:
----------------------------------------------
Max consecutive BVOPs: 2
Quantizer ratio (%): 1.50
Quantizer offset: 1.00

Packed bitstream: OFF
Closed GOV: ON
----------------------------------------------


(0) OK
(1) and (2) are the same (wrong) result on standalone mpeg4 (philips 737, fw: 4.1.19, ESS chipset)

(1) and (2) are playable but the playback is the same as mentioned above

NA

[bond]

new_age

now also try
Max consecutive BVOPs: 1
Packed bitstream: ON

that would be the same b-frame setting as divx5 uses

[new_age]

Hello!

The player is still Philips DVD737 (ESS based player) with 4.1.9 firmware.

I've tried 5 different setting with the same video:

[1] divx5.1.1 with B-Frames -> Plays fine
VIDEO: DX50
B-VOP: Yes
S(GMC)-VOP: No
QuarterPixel: No
Frame Size: 704 x 576
Average Bitrate Per Sec: 1486 kb/s
Frames Rate: 25.000
Color Depth: 24
Total Frames: 3014

[2] divx5.1.1 without B-Frames -> Plays fine
VIDEO: DX50
B-VOP: No
S(GMC)-VOP: No
QuarterPixel: No
Frame Size: 704 x 576
Average Bitrate Per Sec: 1488 kb/s
Frames Rate: 25.000
Color Depth: 24
Total Frames: 3014

[3] xvid 1.00beta3 without B-Frames -> Plays fine
VIDEO: XVID
B-VOP: No
S(GMC)-VOP: No
QuarterPixel: No
Frame Size: 704 x 576
Average Bitrate Per Sec: 1512 kb/s
Frames Rate: 25.000
Color Depth: 16
Total Frames: 3014

[4] xvid 1.00beta3 with B-Frames -> same wrong playback
----------------------------------------------
Max consecutive BVOPs: 1
Quantizer ratio (%): 1.50
Quantizer offset: 1.00

Packed bitstream: ON
Closed GOV: ON
----------------------------------------------
VIDEO: XVID
B-VOP: Yes
S(GMC)-VOP: No
QuarterPixel: No
Frame Size: 704 x 576
Average Bitrate Per Sec: 1466 kb/s
Frames Rate: 25.000
Color Depth: 16
Total Frames: 3014

[5] xvid 1.00beta3 with B-Frames -> same wrong playback
----------------------------------------------
Max consecutive BVOPs: 2
Quantizer ratio (%): 1.50
Quantizer offset: 1.00

Packed bitstream: ON
Closed GOV: ON
----------------------------------------------
VIDEO: XVID
B-VOP: Yes
S(GMC)-VOP: No
QuarterPixel: No
Frame Size: 704 x 576
Average Bitrate Per Sec: 1460 kb/s
Frames Rate: 25.000
Color Depth: 16
Total Frames: 3013

I don't know whether it is a player firmware specific error or xvid problem. It would be nice if someone with other ESS chip standalone player could try.

NA

[Leak]

Originally posted by new_age
I don't know whether it is a player firmware specific error or xvid problem. It would be nice if someone with other ESS chip standalone player could try.

I know I'm just being curious here, but exactly how is the fact that "packed bitstream" was used stored inside the file with both DivX and XviD?

I've got some dim memories that it was one character in a text string stored in the file - so if XviD and DivX use different strings and the player only "understands" packed bitstream when it gets DivX's packed bitstream string then that could be the cause of the problem.

Of course, sysKin or one of the other developers could shed more light on this. :)

np: Sole - Save The Children (Bottle Of Humans)

[chem]

Hi
There is no playback problem for Xvid 1.0 files with X-card then using older driver release 1.3 for it with packed bitstream and any number of b-frame. With driver 2.0b playback is smooth only after muxing video into mp4 without sound. With driver 2.1 this mp4 file plays shuttering. May be i did something wrong but after muxing
into mp4 file with mp3 sound it did not play at all neither
DivX nor Xvid files. i tried to use 3ivX muxer and MP4UI.

[new_age]

I've captured how Philips dvd737 plays back xvid 1.00beta3 B-Frames. Where can I upload them? (If anyone interested)

704x576 ~520KB PNG files

regards,

NA

[bond]

Originally posted by chem
May be i did something wrong but after muxing into mp4 file with mp3 sound it did not play at all neither DivX nor Xvid files. i tried to use 3ivX muxer and MP4UI.dont use mp4ui with packed bitstream files (no matter if divx5 or xvid)! the output mp4 will not be compatible!
3ivx is the only correct mp4 muxer for that

btw search for see more digital's posts, according to him mp4 perfectly works on his xcard

[Wolfman]

new age I have ess player and I have yet to find out how to encode xvid properly .. stuttering is common..BTW is it noticeable to the end-user that xvid is using 16bit color depth and not 24bit??:confused:

[Zhnujm]

bframes (packed or not) are working fine with my Yamada 6100 (ESS based).
With older firmwares there were some errors in the picture with bframes, maby thats the problem with the Philips 737.

[new_age]

What is your firmware version?

NA

[Wolfman]

I have no problem playing back things encoded by other peoples. I howver cannot find the magic formula for my own xvid encodes.. any suggestions welcome... versions...locations... and guides...???:(

[new_age]

Guess what: www.doom9.org, xvid guide OR here the newbie faq.

NA

[Koepi]

And of course the search function is your friend, you could solve your pseudo-mystery about 16 or 24 bits very easily, it's been discussed very often here.

(Just a hint: all "end user" mpeg[1|2|4] use YV12 colour space which has exactly _12_ bits[there _is_ a studio profile which can encode into different colorspaces [[YUV 4:4:4 for example]] in mpeg2]. So your encoding app does something wrong as you seem to convert from YUV2.)

Koepi

[Wolfman]

Unfortunately none of those deals with encoding/playback on a standalone they all deal with PC playback/encoding. I have so far figured out that gmc and qpel are no-no's but the b-frames question.. b-frames are ok on divx but on xvid they seem not to work or only 1 consecutive works ?? new-age says b-vops off.. I have searched and asked and have not got a definitive answer to xvid encoding settings for playback on dvx6100 (ess based). Also which version of xvid ?? older one or newer one which is claimed to be standalone compatible .. at what settings.. there are known versions of divx eg 5.0.2 5.1.0 5.1.1 available from thier site.. however there appear to be different versions /releases available from various places both official and unofficial of the xvid codec. I have the latest december firmware.

[mikeX]

from what i understand setting max b-vops @ 1 in combination with packed bitstream and closed gov should make the stream divx 5 compatible as far as b-frames are concerned (talking about xvid 1 beta offcourse)

[Gaia]

I have Kiss player and no problems with XviD b-frames(no matter what b-frames settings i use). I can see very small stuttering(usually you can hardly see it) sometimes without packed bitstream but with packed bitstream enabled playback is perfect.

[Zhnujm]

Originally posted by new_age
What is your firmware version?


The version 4.1.27.1C.0.
AFAIK there was at least 1 new update for the Yamada after the last Philips update.

[sapient]

mikeX said
setting max b-vops @ 1 in combination with packed bitstream and closed gov should make the stream divx 5 compatible as far as b-frames are concerned

It should but it doesn't.
Xvid with these settings is still choppy on a x-card with the latest drivers... New age reports the same a few posts back. So there is obviously something different about xvid b-frames. I hope someone from the xvid team gives a definitive answer but syskin hasn't come back to the thread after his first post and koepi ignored the actual topic of the thread in favor of being snippy.

I still haven't tested the older 1.3 x-card drivers as chem suggested. I 'll report back as soon as I do, but this still doesn't answer the question of what is different about xvid b-frames and whether it will be eliminated on a future version or if it is an intended feature of xvid.

[sysKin]

Originally posted by sapient
I hope someone from the xvid team gives a definitive answer but syskin hasn't come back to the thread after his first post and koepi ignored the actual topic of the thread in favor of being snippy.It's not about ignoring anyone, it's about not having anything useful to say. XviD's b-frames are mpeg-4 compiliant, or at least all software says so. XviD-in-avi has always been a trick (or two different tricks), and as far as I know, packed bitstream works the same way as in DivX5.
I don't know anything more that could help.

Radek

[sapient]

@syskin:
Any answer is better than no answer. Thanks

@x-card owners
I can now confirm chem, at least partially. Drivers 1.3 of the x-card play back xvid with any number of consecutive b-frames and packed bitstream enabled just fine. The newest drivers, version 2.1, produce stuttering in all xvid clips with b-frames, with any number of consecutive b-frames and with or without packed bitstream enabled.
I guess that this is something for sigma's tech support rather than the xvid team.
The fact that divx with b-frames plays just fine with the 2.1 drivers indicates, though, that there really is some kind of difference between divx and xvid b-frames, even when all xvid settings are set to match those known for divx.

[Koepi]

sapient:

don't behave like anyone here owes you anything. This isn't the case, and instead of saying "thank you for the gift" you're whining.

Your conclusion that there is something different between xvid and divx bframes is wrong. The drivers just may treat them differently.

@all:
So now that the case is a clear thing for sigma support and has nothing to do with xvid (in the sense of being flawed), please head over to their support - you can expect something from them, because you paid for the product.

Regards
Koepi

[sapient]

koepi,

When you make a promise, even implicitly (in this case that xvid should meet certain standards of playback performance), you should not be surprised that people whine when you break them. Anyway, whining seemed to get me what I wanted (an answer), so it seems it worked ;)

[begu]

Well I also can confirm the problem. No matter what setting in xvid, it will not playback smooth on x-card. And this is for sapient, I thank the Xvid team for AWESOME codec, nice work.

Well there seems to be something wrong in the sigma's drivers. I have tried this also: set the FourCC in Xvid properties to DX50, it doesn't help.

Note: sometimes I did manage to get the smooth playback using 1 b frame. Try FF/RW and PLAY/PAUSE buttons, it may occassionally start smooth playback.

And I did notice this also: when keeping PCM soundtrack in AVI together with xvid 1 bframe, the playback is usually better and can be altered to smooth using FF/RW etc. buttons. However CBR MP3 sound with same video clip causes the stuttering, that cannot usually be smoothed with FF/RW etc. button presses.

I tried different interleaving values too, using virtual dub. It did affect, but in bad direction.

I will look the See more digital's info about mp4 container.

[Koepi]

begu:

did you try the old 1.3 drivers like sggested by chem and sapient? They should work fluent no matter how many bframes you used.

Regards
Koepi

P.S.: maybe someone can post a link to the driver page where this old driver is available, i can put that into the FAQ then. Thank you.

[sapient]

Version 1.3 of the x-card drivers can only be found in sigma's ftp:

ftp://ftp.sigmadesigns.com/Xcard/

The relevant files are XC_1_3w1.zip and XC_1_3w2.zip for win9x and XC_1_3k1.zip and XC_1_3k2.zip for win2k/XP.

[new_age]

The B-Frame shuttering on Philips DVD7373 (ESS chip, firmware 4.1.19) definitely a firmware bug. My friend tried the same xvid avi with b-frames (that gives on Philis the problem) on Yamada 6x000 with newer firmware and it played fine.

So I'll still prefer xvid than divx5. And now divx5 is about 3-6 times slower than xvid my only way is xvid.


However I don't understand that this ESS chips can play GMC in divx5 and can't play in xvid. :confused: Maybe it is also a firmware bug. :mad:

NA

[Wolfman]

AFAIK divx GMC uses 1 warp point whereas xvid uses up to 3, ESS however can only handle 1. I am repeating this parrot fashion as I know nothing of warp points (except for my days in star fleet academy). my guess is that warp points are "bends" in motion estimate trails, which is what Global Motion Compensation is all about.

[begu]

I'm trying to move from AVI container to .mp4.
Tried test using graphedit and 3ivx filters for Xvid 1 bframe and AAC audio. Played nicely with xcard and latest 2.1 drivers. Will try soon more tests with longer files, FF/RW, AV-sync and more b-frames.

I think it's time for .mp4 for me and xcard now. Of course for highest quality, I prefer not to use b-frames (xcard is connected to sanyo plv-z1 projector and compression artifacts are more visible in big screen -> forces me to use bitrates over 2000 kbps for some titles, eg. LOTR II needed 2700 kbps avg for anamorphic, no resize encoding)

[gotaserena]

B-Frames in mp4 will stutter anyway when played in the xcard.

[begu]

Hmmm.. I tried some tests, and I did not have any stuttering, but the clips were short.

I did not manage to create .mp4 from long over 2 GB AVI file. It was xvid 1 b-frame and PCM audio, created with latest virtualdubmod using avisynth and DVD2AVIdg. The graphedit crashed... :/

I used the 3ivx filters (audio encoder and mp4 muxer) in graphedit.

However I manged to do short .mp4 clips with 1 b frame. It did NOT stutter anyhow in Xcard. But it used AAC audio.

And there is more, I used ffmpeg with 1 to 3 bframes in AVI container, it did NOT stutter in xcard. I tried both PCM and MP3 CBR audio.

Note: I did not use packed bitstream in ffvfw (it was gryed out by the way).

Will do more tests soon.

[gotaserena]

The problem may be on my end. I have tried only the XviD 1.0 betas in mp4 (AAC audio as well -- it was my reasoning for trying it anyways.) They stutter more than in the .avi container. But I haven't noticed that they would stutter even in the avi -- I haven't been running much of the newly encoded stuff through the Xcard.

Later on I runned some tests with a show I recorded and noticed the stutter even when I used avi as a container. I also used the new drivers from X-card. dev-api-3 still works pretty well in avi, as I would imagine DivX too. Still have to try them in mp4, tho.

At any rate I imagine that the flood is going on at the sigmadesigns forum. I would love to see the problem solved till next weekend, when the WRC season starts. At least Koepi's latest unstable dev-api-3 was working for me and I can always go back to it.

[gotaserena]

Bad news...

The word is going on in the sigma forum that the B-frames in XviD are not mpeg-4 compliant, contradicting what SysKin and Koepi said above.

Bottom line: nobody will look at this problem, at least for the time being. Hope that the old drivers work.

[sysKin]

I am pretty sure that they will steal some new xvid/mplayer code and will make it working.

[begu]

gotsarena:
I do it this way:
- create AVI with PCM 2 channel sound (WAV) using virtual dub or Flask(for fast encodings)
- use 3ivx muxer and AAC audio encoder in graphedit to create mp4 file

It plays fine in xcard, but there is an issue with maximum bitrates in 3ivx muxer. So that prevents me to do good quality (high bitrate) encodings. But the bug will be fixed soon in next version.

Will try some more tests soon.

I tried ffvfw in AVI and it plays smooth on xcard. I used even 3 consecutive b-frames and no packed bitstream. No issues at all in fast tests. I will do more deep analysis soon.

So I would suggest the following:
- for maximum quality and speed use xvid and mp4 container (don't go over 8000 kbps in maximum peak bitrate because of the bug in 3ivx muxer)
- for slower encoding use ffvfw in AVI

And I'm using latest 2.1 drivers from sigma.
Yes, I know sigma sucks in terms of drivers and programming thei 'own' code. But the actual hardware is nice. And they did steal some code in the past and I think they will do it again -- some lazy coders or lack of time/money it is for sigma's support.

P.S sorry for misinformation, I wrote about ffmpeg, but of course it is ffvfw, sorry for confusion (I'm new to ffvfw encoding, and remembered the name wrong :( )

EDIT: of course You can aus 'AS Level 5' at Xvid settings to avoid going above 8000 kbps, and then use current 3ivx muxer

[begu]

Well, some problems reamain with 3ivx muxer.
I tried AS@level 5 (limits the bitrate to 8000 kbps) in xvid, and it did crash the 3ivx muxer in graphedit. So something else is wrong with it. Will look into it tomorrow.

Hopefully the new version of 3ivx muxer will arrive soon.

[Leak]

Originally posted by begu
AS@level 5 (limits the bitrate to 8000 kbps)

Actually, it doesn't. Bitrate limiting according to profiles is not implemented yet in XviD.

np: Yello - Unreal (The Eye)

[begu]

Well, that explains the problem with 3ivx muxer in graphedit. So I will wait for the 3ivx to update the muxer for the >8000kbps bug or the Xvid to bring support for profiles.

I tired some tests more:

- Xvid with 3 b-frames muxed to MP4 -> little jerking/tearing in the bottom of the picture
- Xvid with 2 b-frames muxed to MP4 -> less jerking/tering
- Xvid with 1 b-frame muxed to MP4 -> almost none jerking

I assume that the Sigma's processor can't handle so much b-frames (but more I suspect the buggy drivers). Note: the jerking/tearing occured only at the beginning (the first 30-40 seconds) of the 3 min clip.

However using ffvfw in AVI and 3 b-frames did play smooth (it was wav PCM sound).
I tried muxing the ffvfw AVI to MP4 and AAC, and it was ok. So it is not the AAC audio or MP4 causing tearing in the beginning of the clip, when using Xvid. Well this is odd, but there must be some minor differencies between ffvfw and xvid. Will do more tests in the weekend. The fix must come from the Sigma, that is for sure. But I have to wait long for that.

[gotaserena]

Hei Begu

I don't know what happened, but the new muxer from 4.5.1 and the new RC1 seem to produce mp4s that won't stutter on the Xcard. I'll be running some more encodings -- specially at full D1 -- during the weekeend so we can see if there was any progress there.

Now I have to go to lengthy discussions with the "ministry of finance" to decide whether I should shell out 7 bucks for the 3ivx filter package. It is a fair price to pay to bid AVI goodbye :)

Oletteko Helsingissa?

[SeeMoreDigital]

Hello everyone

I just wondered if there any new developments regarding the original issues in this thread?

Cheers

[sapient]

The new RC2 of xvid produces less stuttering, IMHO, but its still there. I am talking about an .avi container and the 2.1 drivers. I haven't tried mp4.

[SeeMoreDigital]

Originally posted by sapient
The new RC2 of xvid produces less stuttering, IMHO, but its still there. I am talking about an .avi container and the 2.1 drivers. I haven't tried mp4. Is this with or without B frames?

[sapient]

with... that's the title of the thread, right?
With 1 b-frame you must pay attention to notice the stuttering, but its still there. With 2 or more it becomes obvious.
I am always testing with packed bitstream on.
There is and never was any problem without b-frames as far as I know.

[SeeMoreDigital]

Originally posted by sapient
with... that's the title of the thread, right?
With 1 b-frame you must pay attention to notice the stuttering, but its still there. With 2 or more it becomes obvious.
I am always testing with packed bitstream on.
There is and never was any problem without b-frames as far as I know. It never hurts to make sure!

Yep, I still get a slight problem with XviD 'Jumbo' encodes when B-frames are enabled. But nothing like as bad as before.

I'm going to try some more b-frame tests tomorrow. I'll report back.

I'm currently generating an 2pass 720x576 anamorphic (16:9 AR) encode of StarWars 1 (without b-frames), which if all goes according to plan, when I mux the stream into an MP4 container (with AAC audio) the encode should automatically open up at the correct AR on my 16:9 TV.

Cheers

[gotaserena]

So far so good here... No stuttering on my side, but then I ran basically small vcd and svcd-resolution clips.

Incidentally, is anybody having trouble using XviD decoder on mp4 files? Mine look horribly blocky for the first 10 or so frames, which makes me think that something is going wrong with the first keyframe. But lately it is even crashing on the stream. 3ivx, DivX and ffdshow are working fine, though.

[SeeMoreDigital]

Originally posted by gotaserena
...So far so good here... No stuttering on my side, but then I ran basically small vcd and svcd-resolution clips. You're lucky, my XviD b-frame tests were not very successful!

Originally posted by gotaserena
...Incidentally, is anybody having trouble using XviD decoder on mp4 files? Mine look horribly blocky for the first 10 or so frames, which makes me think that something is going wrong with the first keyframe. But lately it is even crashing on the stream. 3ivx, DivX and ffdshow are working fine, though. No problems here, when I generate XviD encodes without b-frames!

I'm using MP4UI to mux my 'anamorphic' XviD and 3viX video streams, with AAC into an MP4 container!

The 2pass 720x576 anamorphic (16:9 AR) encode I generated of StarWars 1 worked very well. So well in fact, I decided to have a go at generating an 576wide x 720high anamorphic (16:9 AR) encode.

I was expecting this encode to look pretty crap, but to my surprise it turned out to be very watchable... It's quite amazing how far you can stretch a horizontal pixel!