xvid_encraw settigs SAP compatibles

[alfixdvd]

What settings are SAP compatible ?

[unskinnyboy]

Depends on your brand and what it can play. What will work for my SAP, may not work for your SAP.

The usual things on which SAPs b0rk are, off the top of my head: >= 2 B-frames, Packed Bitstream, QPEL (newer ones should be OK with it), GMC (100% non-compatible), CQMs, non-MoD16 resolution, and width > 720px. All of these may not be applicable for your SAP.

I suggest you make a test CD/DVD with different encodes with settings which you think might work, try to play them on your SAP, and see which ones b0rk and which ones don't. You can also search the forums with your SAP model number to see if there are any threads about it.

[alfixdvd]

thanks

[Selur]

btw. does Xvid honor max bitrate and vbv restrictions in current versions?

[unskinnyboy]

btw. does Xvid honor max bitrate and vbv restrictions in current versions?It should. What makes you think it doesn't?

[plugh]

btw. does Xvid honor max bitrate and vbv restrictions in current versions?
Unfortunately, no.

The biggest issue is that vbv constraint is applied as a scaling operation before rate control. Therefore, the code that attempts 'on the fly' to make frames larger in order to avoid undersizing can produce segments that violate the previously applied vbv constraint. (BTW, the same occurs with weighted zones).

http://forum.doom9.org/showthread.php?t=118419

[unskinnyboy]

Unfortunately, no.

The biggest issue is that vbv constraint is applied as a scaling operation before rate control. Therefore, the code that attempts 'on the fly' to make frames larger in order to avoid undersizing can produce segments that violate the previously applied vbv constraint. (BTW, the same occurs with weighted zones).

http://forum.doom9.org/showthread.php?t=118419Doesn't 2nd pass alt fix it though?

[plugh]

'2nd pass alt' was my attempt to address the issue.

However, that is a seperate plugin that has been incorporated into a number of builds (squid80's encraw, celtic_druid's vfw), but it is not part of the "Xvid ... current versions" selur asked about.

Largely my fault for not submitting it, but there is still a chunk of work I want to do first (see page 3 of that thread) when I can get the time. I've also thought about submitting current rev and doing other part seperately, but it's not like people are clamoring for it...

[unskinnyboy]

'2nd pass alt' was my attempt to address the issue.Yes, I know.

However, that is a seperate plugin that has been incorporated into a number of builds (squid80's encraw, celtic_druid's vfw), but it is not part of the "Xvid ... current versions" selur asked about.OK. I (mis)interpreted "Xvid ... current versions" to be "available Xvid builds", and like you said xvid_encraw (although MeGUI doesn't expose the option) and c_d's VfW builds has it.

Largely my fault for not submitting it, but there is still a chunk of work I want to do first (see page 3 of that thread) when I can get the time. I've also thought about submitting current rev and doing other part seperately, but it's not like people are clamoring for it...I have no use for it myself, since I never use VBV, but others may. I think you should commit alt 2 pass to CVS and then continue the rest of your work off of the CVS. As long as it doesn't affect the normal 2nd pass, this should be OK. In the longer run, you and the rest of the devs could work together and fix the VBV issue in the normal 2nd pass itself.

EDIT: Forgot to ask - did you ever bring this up in [XviD-devel]? I don't remember seeing this. If not, you should.

[plugh]

(although MeGUI doesn't expose the option)
I don't use MeGUI, but I thought it had incorporated support for altpass2 (see page 3 of thread)
I think you should commit alt 2 pass to CVS and then continue the rest of your work off of the CVS. As long as it doesn't affect the normal 2nd pass, this should be OK. In the longer run, you and the rest of the devs could work together and fix the VBV issue in the normal 2nd pass itself.
xvidcore has no provisions for alternate plugins, which is why my code currently resides in encraw.exe or (custom) xvidvfw.dll. (This is the same situation as with the lumimasking vs VAQ plugin) So, by 'submitting it' I *mean* update xvid to "fix the VBV issue in the normal 2nd pass itself".

FWIW, I went to a LOT of effort to make my update compatible with the current 2nd pass code - by changing a number of #defines it can pretty much be reverted back to existing behaviour. (I also did it this way so interested parties could visually inspect and operationaly evaluate the various changes.)

Unfortunately, I can't see any clean way to conditionalize the other changes I've contemplated. They would require a more fundamental redesign of that module.
EDIT: Forgot to ask - did you ever bring this up in [XviD-devel]? I don't remember seeing this. If not, you should.
Well personally, I greatly dislike mailing lists, so no I haven't. But I also know that some devo's watch / participate in this forum, and I've made both the problem analysis and the code available here. If there is interest on their part in this stuff, both me and the code are easy enough to find ;)

[ronnylov]

I just want to say that the 2nd pass alt option have been very useful for me and it makes my standalone player work without problems (when I also set other options correct). Thank You Plugh!

It took a while until I found that my player really needs the packed bitstream option turned on to play everything smoothly. Qpel works on my player but it seems to need some extra CPU power, so I turn it off when encoding at higher resolution. My player does support resolutions above >720 px. Some audio formats like AAC seems difficult to decode so I use mp2 audio for better video decoding performance. As already said, do experiment with different settings, your player may be different than others.