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!

[gotaserena]

Maybe that's it. I'm using 3ivx muxer. FWIW it doesn't make sense to use mp4 if I can't use B frames.

The Xcard handles anamorphic mp4's beautifully. And the chip isn't complaining to decode AAC (LC *and* HE) either.

[SeeMoreDigital]

Originally posted by gotaserena
Maybe that's it. I'm using 3ivx muxer. FWIW it doesn't make sense to use mp4 if I can't use B frames. Yep, the XviD encodes look damned good without b-frames anyway!

Originally posted by gotaserena
The Xcard handles anamorphic mp4's beautifully. And the chip isn't complaining to decode AAC (LC *and* HE) either. True, it's really great to see anamorphic Mpeg4 encodes working properly.

But all is not quite perfect.

I've noticed that pressing the fast-forward or fast-rewind keys can cause the Xcard to crash. Same happens if you press the 'pause' and 'frame advance' key.

Also, although 2ch audio in both AAC-LC and AAC-HE works fine. Unfortunately 6Ch AAC-LC is not correctly mapped and 6Ch AAC-HE will crash the card!

If you're interested I've put a few test files in Area 51 of my web site. And if you get stuck, getting MP4UI to work properly, I've just added a 'How to...' in Area 05.

I guess I should add my 576wide x 720high anamorphic encode to the site too!

Cheers

[sapient]

I don't think that the x-card supports he-acc fully... That is I think it only decodes the LC compatibility part. Correct me if I 'm wrong

[SeeMoreDigital]

Originally posted by sapient
I don't think that the x-card supports he-acc fully... That is I think it only decodes the LC compatibility part. Correct me if I 'm wrong Very true. The Xcard chipset was not designed for use with AAC-HE.

However, when you generate and play AAC-LC and HE files encoded between 32 and 64kbps, the HE files sound way better... very odd!

Cheers

[SeeMoreDigital]

Good News!

The guys over at Sigma are looking into the situation. For more information/future updates, please follow the thread below: -

http://www.sigmadesigns.com/dcforum/DCForumID7/780.html#8

Cheers

[gotaserena]

What can I say? I'm really having trouble duplicating this problem in my setup. This weekend I encoded the three specials on the WRC Mexico rally (lots of panning and cars moving, easy to pick problems in movement) and I could see no stuttering.

Setup: XviD RC-3, AAC sound in MP4 container.
Xcard: drivers 2.1, joveplayer 1.4
Output: PAL

To be fair I think the codec picked very few consecutive B-frames, but the result is nothing like the stuttering problems I had with the last beta before RC-1.

[SeeMoreDigital]

What b-frame settings are you using?

Cheers

[gotaserena]

Default. 2 B-VOP, 1.5xQ+1.0, Packet ON, Closed GOV ON.

[sapient]

Using the .mp4 container, at least with mp4ui results in a video stream that is identified simply as mpeg4 and not xvid. I think there was a previous report that mp4 worked fine. Version 1.3 of the driver's that also plays xvid just fine does not recognise xvid as such, just as a kind of divx (it actually asks you to add the xvid fourCC to its list of divx fourCCs). The problem exist with the new drivers and the avi container that preserves the xvid fourCC. It is obvious that the new drivers recognise xvid and treat it in some anorthodox way, probably in order to deal with certain quirks of the pre-beta xvid builds.

Unfortunately no one at sigma pays attention to MY posts over there...

[gotaserena]

Well, but MP4UI can't mux video streams with B-VOPs so the problem wouldn't show up, would it? Incidentally, the 3ivx muxer I'm using also labels the video "mp4v".

What strikes me as odd is that the problem is then with either the container or the way the XVID fourcc is treated by the xcard driver. This should have been an easy fix by the guys at sigma, at least while they don't rewrite the driver: just treat it as divx or rmp4!

[SeeMoreDigital]

Originally posted by gotaserena
Well, but MP4UI can't mux video streams with B-VOPs so the problem wouldn't show up, would it? Where have you heard this? The current version of MP4UI will mux such streams.

I can provide a link to such an encode if you want one!

Anyway. I would not describle the problem as 'stuttering'. It's more like 'jittering/tearing' at the bottom of the frame.

I've also tried changing the 4cc of the XviD encode to DivX, prior to muxing with MP4UI, but that did not help either!

However, I've found that if you 'export' the XviD video stream out of the MP4 container the encode will play with the Xcard without 'jittering/tearing' But it will now 'stutter'.

And then, if you mux this video stream back into an MP4 container, the Xcard will not play it - So nothing gained there then!

Cheers

[gotaserena]

I must be using an old version then. I'll check it up and report back.

[SeeMoreDigital]

Originally posted by gotaserena
I must be using an old version then. I'll check it up and report back. If you get stuck with the latest version of MP4UI. I've generated a quick 'How to... Guide' which is available in Area 05 of my web site.

Cheers

[bond]

dont use mp4ui/mp4creator for muxing mpeg-4 streams with packed bitstream enabled (xvid and divx5)!
the resulting file will not be a spec compliant mp4 file and therefore it can never be said if a player will handle it correctly or not!

for muxing packed bitstreams there is no way around using the 3ivx muxer (also try disabling the "compressing nvops" option)

[SeeMoreDigital]

Originally posted by bond
dont use mp4ui/mp4creator for muxing mpeg-4 streams with packed bitstream enabled (xvid and divx5)!
the resulting file will not be a spec compliant mp4 file and therefore it can never be said if a player will handle it correctly or not!

for muxing packed bitstreams there is no way around using the 3ivx muxer (also try disabling the "compressing nvops" option) Agreed!

The 3viX muxer has the ability to remove all those nasty Mpeg4 hacks (created by certain encoders), as you've already stated in your excellent MP4 Q&A Guide.

But what exactly are B-frames? This is what DivX says about them: -

"Bi-directional Encoding (B-Frames)
DivX 4.12 and earlier use only I-frames and P-frames to encode video content. The same is true of DivX 5.0.X.

DivX Pro 5.0.X, on the other hand, introduces the ability to use bi-directional frames ("B-frames"), resulting in compression ratio improvements of up to 20%.

B-frames construct their visual data using not only data from the previous frame (as with P-frames), but also using data from the next frame. Thus their "bi-directional" nature.

Using B-frames reduces the amount of data needed to encode a frame of video, and is especially good at encoding video sequences where moving objects reveal hidden areas.

I apologise for posting DivX info in an XviD thread, but it was the only info I could quickly find about b-frames

Personally speaking, until the XviD b-frames situation is resolved I will continue to generate encodes without them.

Also. I've never been able to see much difference (if any) when encoding with them, when using the Xcard. So I can't 'see' what all the fuss is about! :D

Cheers

[gotaserena]

I can mux the files without any problems with the new mp4UI (it turns out I had the old 0.9.7 version, while it's now on the 1.0.2), but the 3ivx splitter doesn't like them. The xcard driver doesn't either, the file with B-frames chokes heavily (that is beyond stuttering!) but the file without B-VOPs (but w/ packed bitstream on) plays nicely. Do you think I should turn it off by default when encoding?

More tests tomorrow.

P.S.: read the new posts, that will take care of the problem playing the files in the xcard. But I can't really be sure until I try. Stay tuned.

[SeeMoreDigital]

XviD with one b-frame seems to play without 'jittering/tearing' But they still 'stutter'....

I've tried many options but not found an XviD b-frame solution!

Cheers

[bond]

Originally posted by SeeMoreDigital
I've tried many options but not found an XviD b-frame solution!also not when muxing with 3ivx with "compress nvops" disabled?

[SeeMoreDigital]

Originally posted by bond
also not when muxing with 3ivx with "compress nvops" disabled? You got me!

No, I've not tried this option, as I still have not got into using GraphEdit!

I like to keep things as simple as possible. Because I am simple :D

Cheers

[gotaserena]

A-ha: I disabled this in 3ivx a long time ago.

Graphedit is plain simple, when you get used to it! :D

[shitowax]

Unhappy with 3ivx NVop compression ?

[bond]

well maybe the vfr can cause problems

[shitowax]

It can cause problem with lazy players that perform some wrong assumptions on frame duration. Or when you remux in deprecated CFR format ... ;)

[Jvdhorst]

Okay just for your information I have a update on RC4 bframes and Xcard, I posted this message on Sigmadesigns forum:

As the new RC of Xvid is just out, I just had to experiment once again . It seems that with drivers version 2.1, b-frame clips tear in the bottom of the screen or just crash the xcard. It couldn't be solved by enabling or disabling packed bitstream or closed GOV in the encoding settings. Interlaced or not, also doesn't make a difference. Contrary to RC3-encodes remuxing from avi to mp4 with 3ivx's muxer doesn't fix it.
However using driver version 1.3 of the xcard fixes a lot. For completely smooth playback packed bitstream and closed GOV need to be ENABLED with encoding: If packed bitstream is disabled there are still little hickups. When closed GOV is disabled the picture can sometimes freeze at the beginning of a clip.
The amount of consec b-frames doesn't matter. Even with 15 it works. If you have encodes without the two settings enabled during encoding remuxing them to mp4 also gives perfectly smooth playback.

I tried several clips and keep getting the same results. So in short:
The 2.1 drivers do not handle the RC4 b-frames well. It doesn't seem to be container or b frame settings dependant. The 1.3 drivers have specific demands on the stream concerning packed bitstream and closed gov when avi container is used.

The tests where all short so long term audio syncing problems have not been tested.

To read the follow up go to: http://www.sigmadesigns.com/dcforum/DCForumID7/808.html

[gotaserena]

For the first time I was able to reproduce the problem in my setup. It is very odd: the problem doesn't show up for reduced resolution clips (like 512x384 or smaller), but indeed it is there for full PAL (and probably NTSC) clips. I guess that the reason I wasn't noticing this is because I mainly re-encode my captures to 512x384 or smaller, and keep my full resolution clips in MPEG-2.

[daberti]

Originally posted by new_age
[B]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:..............



Same player here, with same firmware version and XviD-1.0-05042004 _Release Candidate 4 .
Same solution as yours ;)

[daberti]

Originally posted by daberti
Same player here, with same firmware version and XviD-1.0-05042004 _Release Candidate 4 .
Same solution as yours ;)

Latest news: under same conditions, without disabling B-frames but by enabling under AutoGk 1.19 the ESS standalone patch, max consecutive BVOPS=1, Packed Bitstream and Closed GOV checked I've had no playback hassles at all on DVD737 (Abyss long version).

[SeeMoreDigital]

daberti,

Thanks for your information, however I think it would have been more useful if it had been posted over in the Hardware Players (http://forum.doom9.org/forumdisplay.php?s=&forumid=73) section of the forum. This thread is about the Sigma Xcard!

Maybe some nice Moderator could move it!

Cheers

[daberti]

Originally posted by SeeMoreDigital
daberti,

Thanks for your information, however I think it would have been more useful if it had been posted over in the Hardware Players (http://forum.doom9.org/forumdisplay.php?s=&forumid=73) section of the forum. This thread is about the Sigma Xcard!

Maybe some nice Moderator could move it!

Cheers

Of course it coulda ! ;)
But it has not been a fault of mine, for the first OT -following your flavour- it would have been brought about by new_age...or not?
Then I'm not quite sure that the argument -as raised by new_age- would not require a crosspost.....
Anyway: sorry!