converting Dv-Avi/Dvd Mpeg2 to Xvid format

[manono]

I had downloaded the test 2a xvid.avi. Before you removed it, I guess. I apologize for the "tall and thin" question. You were right that the player had been changed. I had been fooling around with it earlier and had forgotten to set it back to default.

the thin bars top and bottom on that image is because the vlc player and my lcd screen are 16x10, not 16x9

No, the thin bars are there because they're encoded into the video.

I just got the 2 newer samples. The Test_2_Xvid.avi still has the black bars encoded into the video. I didn't quite understand some of the things you said earlier:

the mpeg was shot in a dv cam 720x576 pal 4x3 native.

But it shows as 16:9, 720x576, and resizes properly only if considered to be 16:9.

even tho i cropped the mpeg2 file from 720x576 to 720x416, it will still show in G-Spot as being 720x576 when checking the properties of the file, but if you check the Xvid file, it shows it as 720x416 in G-Spot codec seeker.

This is the part I don't understand. The MPEG file is 720x576. You're not saying it's been cropped and reencoded as another MPEG, are you? The AVI has been resized, yes, to 720x416, but it hasn't been cropped, as near as I can tell.

My recommendations are to crop the black, and resize if for AVI to a lower resolution. I did a test cropping 18 rows of black from both the top and bottom and then resizing to 656x336 and it looked fine. Of course I used an AviSynth script to do that. I would also lower the contrast considerably, and use a higher quant. I tested with quant 3 and the video looked fine. However, for that passage the average bitrate was 4716 with the peak at 6535 - much improved but still not good enough. To use the Home Theater profile you'll have to run 2 passes, I think, and lower the average bitrate (and maybe the resolution) still further.

[glenpinn]

Hehe, that small sample averages over 7700 and peaks at over 10000. I'm surprised that the hardware players don't freeze up entirely during that passage. Or do they? .

i can assure you the dvd player and the noontek player are both perfectly fine playing those files, i have never has any freezing on anything i play.

i ran G-Spot ver that wedding file xvid and man it was like 7500 bitrate, the mpeg file was only 6000, no wonder the Xvid was a bigger file size.

anyway, the 170 mpegs are 165gb total and the Xvid folder is 115gb in size.

[jagabo]

I would also lower the contrast considerably

I'm still waiting to download the MPG file (only have the AVI so far) but lowering the contrast in TMPGEnc won't work because it does all its filtering in RGB after conversion with a rec-601 matrix. TMPGEnc can reduce the brightness but there will be no details in the blown out areas. The black level appears to be too high too.

[glenpinn]

I would also lower the contrast considerably

I'm still waiting to download the MPG file (only have the AVI so far) but lowering the contrast in TMPGEnc won't work because it does all its filtering in RGB after conversion with a rec-601 matrix. TMPGEnc can reduce the brightness but there will be no details in the blown out areas. The black level appears to be too high too.

i have not done anything regards filters on that file, thats how it was filmed, straight from my camea, into tmpgenc after being captured in dv-avi using WinDv 1.2.3.

i only cropped it.

im trying to get some screenies to show you how the camera films in cinema mode and why i crop the bars off it to take it from 720x576 (native 4x3 mode) to 720x405 (406 and 416 in some cases)

this is how its imported to the pc in dv-avi from my camera (16x9 cinema or letterbox mode)


this is it after cropping the black bars (80 lines top and bottom) to get it to 416 height.
in tmpge the black bars are 69 lines each, so when they are cropped off completely it leaves a resolution of 720w x 438 high, so i go a bit further and crop 80 of each to get it to 416, or i would take off 86 and 85 to get 720x405.


if the cropped Xvid has bars encoded into it then why does it play on WS tv without bars, i assumed VLC just has a preview screen that is 16x10 not 16x9, hence the thin bars.

[glenpinn]

I just got the 2 newer samples. The Test_2_Xvid.avi still has the black bars encoded into the video. I didn't quite understand some of the things you said earlier:

the mpeg was shot in a dv cam 720x576 pal 4x3 native.

But it shows as 16:9, 720x576, and resizes properly only if considered to be 16:9.

ok the video is filmed in 720x576 native 4x3 mode (not 720x576 native 16x9 mode) but i used the cinema mode that adds the bars to appear like its widescreen (fake widescreen or letterbox)

i imported the dv-avi into tmpge and use the crop tool to cut off the black bars (80 lines top and bottom) which takes the file to 720 x416 (576-160 = 416) i know its not true 16x9 but use it for this example

i then encode it to pal 16x9 output not pal 4x3 output so it becomes 16x9 resolution (near enough in this case)

when that same mpeg2 file is imported back to tmpge and i select Xvid output, the file is output to 720x416 resolution because thats the size it was cropped to for the mpeg output.

[manono]

if the cropped Xvid has bars encoded into it then why does it play on WS tv without bars,

Your TV set's overscan. Either that or your players are cropping or not 1:1 pixel mapping. Or both. You want to see what it really looks like? Open it in VDub(Mod). There you'll see the unvarnished video.

i then encode it to pal 16x9 output not pal 4x3 output so it becomes 16x9 resolution (near enough in this case)

Ah, so you did reencode it to a 16:9 MPEG. That explains a lot. What's the point? If the final output is to be an XviD video, better would be to use the original video as the source for the XviD encode.

Anyway, when studying these things to find ways to help, the source video is needed, not something you've already worked on. Maybe in the process of reencoding it you're the one that blew out the whites. And most people, when converting PAL 4:3 to PAL 16:9, crop 72 rows of pixels from both the top and bottom. All these little adjustments you're making only compound the aspect error.

[manono]

...but lowering the contrast in TMPGEnc won't work because it does all its filtering in RGB after conversion with a rec-601 matrix. TMPGEnc can reduce the brightness but there will be no details in the blown out areas. The black level appears to be too high too.

Sure, if it was filmed with the whites already blown (and I'm not convinced it was, since we have yet to see the source), then nothing will bring back the lost detail. But you can make it easier to watch. As it is it hurts the eyes to watch it.

[jagabo]

i have not done anything regards filters on that file, thats how it was filmed, straight from my camea, into tmpgenc after being captured in dv-avi using WinDv 1.2.3.

OK, I have the MPG file now.

The levels are off in the MPG file and probably the original DV AVI too. DV camcorders often record with levels too high. Here's a luma graph of the original MPG file (no AR adjustments here):



and after adjustment with AviSynth's ColorYUV(off_y=-15, gain_y=-6):



Notice how the luma in the first image comes nowhere near the proper black level, the left brown bar (except the letterbox bars which are at the right black level). And how the brightness extends into the right brown bar. The luma should all be between the two brown bars.

Of course, this is all based on this one short clip. You would have to examine a wider range of shots to fine tune the levels.

Here's a quick target quantizer 4 (so it fits within the file size limit here) conversion with Xvid.

Load_Stdcall_plugin("C:\Program Files\AviSynth 2.5\plugins\yadif.dll")
MPEG2Source("Test_2_mpg.d2v")
ColorYUV(off_y=-15, gain_y=-6)
Yadif(mode=0, order=1)
BilinearResize(720,412)
Crop(0,14,-0,-14)

quick.avi

[glenpinn]

[quote="manono"]

Anyway, when studying these things to find ways to help, the source video is needed, not something you've already worked on. Maybe in the process of reencoding it you're the one that blew out the whites. And most people, when converting PAL 4:3 to PAL 16:9, crop 72 rows of pixels from both the top and bottom. All these little adjustments you're making only compound the aspect error.

ok i just filmed some garden stuff (close up and distanc panning) on my gs70 and cutting a short segment from the dv-avi captured using win-dv 1.2.3 and will upload it to my RS account for both of you to download if you want it.
then you will get the untouched footage filmed in this camera, and be aware again, this cam films in native 4x3 (not 16x9) so the bars are there because i set the cam to film in letterbox, or cinema mode which adds the bars to help me film within a 16x9 frame. if i dont use this mode, i get a full height video file without bars.

i will also upload my tmpge mpeg2 file, uncropped and encoded @ 4x3 ratio (as the camera films in 4x3 mode)

i will also upload the output mpeg2 @ 8000br and an Xvid @ 3.0 target quantizer (both converted from the dv-avi source)

the dv-avi file is cropped to 720x406 (86 off top and 84 off bottom) and from that i output the mpeg2 file @ 16x9 @ 8000br, and the Xvid is then encoded at 720x406 with target quant of 3.0 for this exercise.

the black bars cropped off in tmpge results in aimage of 720x438, so i cropa bit more off because the bars on my dv-avi are only 64 top and 74 bottom in the tmpge cropping tool, leaving the picture at 720x438.
tmpge cropping tool wont allow me to crop to odd numbers (it only goes up or down in multiples of 2) so for this exercise i cropped off 86 at the top and 84 off the bottom resulting in a 720x406 image.

if i crop 72 lines off both top and bottom as you mentioned, i will get an resolution of 720x432 ??? which is just a bit smaller than the output i get in tmpge by cropping off the bars only which ends up at 438.

i thought it better to crop down to as close to 720x405 as i could because that is the correct 16x9 ratio.

BTW, just to be clear about color and contrast etc, in that other mpeg i sent you both, it was the original mpeg2 encoded from the original dv-avi taken from the tape filmed in my camera (a small panny gs70) and all i did was crop 80 lines off top and bottom to get it to 720x416, and no filtering was done with colors/contrast, i didnt touch any of that stuff, just cropped the black bars off and output to mpeg2 @ 6000br.

also, i cant convert any of my files to Xvid from the original dv-avi files because i dont have them, which is why i have to convert from my mpeg2 files, otherwise i would be outputting from the dv-avi files.

will post back when everything is finished and uploads completed.

thanks for your patience guy.

here is my dv-avi taken from my camera in playback, and i use paint to show you the sizes of the frames, bars etc.

[glenpinn]

ok i tried cropping off only 72 lines on both top and bottom of my new mpeg2 clip (results in 720x432) and it plays in VLC without bars at all, if i crop only the bars off at 720x438 i get a thin bar either side but not top and bottom, and at 720x416 and 406 i get thicker bars top and bottom but not the sides.

so obviously, my bloody stupidity was cropping at 416 or 406 to get it closer to the correct 16x9 aspect ratio (720x405)

so why does it output the mpeg2 to 16x9 using 720x432 without bars and at 406 or 416 i get bars ???

i output that 720x432 cropped dv-avi file to Xvid at that same resolution and in VLC i still get the bars top ad bottom.
i take it i need to crop more off for the Xvid output (il try 720x412)

trying it all new before i upload anything.

[manono]

ok i tried cropping off only 72 lines on both top and bottom of my new clip (results in 720x432) and it plays in VLC without bars at all, if i crop only the bars off at 720x438 i get a thin bar either side but not top and bottom, and at 720x416 and 406 i get thicker bars top and bottom but not the sides.

so obviously, my bloody stupidity was cropping at 416 or 406 to get it closer to the correct 16x9 aspect ratio (720x405)

so i assume i output that 720x432 cropped file to Xvid at that resolution ???

trying it all new before i upload anything.

When converting PAL 4:3 to PAL 16:9 for MPEG-2 you crop 72 from both the top and bottom, resize to720x576, and then encode as 16:9. I have no idea whether or not you can do that entirely within TMPGEnc as I don't (and would never) use it.

No, you don't assume i output that 720x432 cropped file to Xvid at that resolution. You crop away all the black bars and then do a proper AVI resize. Probably to something like 704x400 or some other roughly 1.78:1 resolution. We'll have to see the untouched DV AVI to be sure exactly how to crop and resize it for AVI though. The sooner you learn AviSynth the sooner you'll stop this incoherent and mostly wrong rambling of yours.

[glenpinn]

When converting PAL 4:3 to PAL 16:9 for MPEG-2 you crop 72 from both the top and bottom, resize to720x576, and then encode as 16:9. I have no idea whether or not you can do that entirely within TMPGEnc as I don't (and would never) use it.

ok no matter what i was cropping to, this box here shows how i output the mpeg2, i use the settings box to set the bitrate and 2 pass options, but there is no option to output to anything other than 720x576, it must resize the cropped file at that setting.

as i also mentioned, the black bars in my dv-avi are 64 top and 74 bottom in the cropping preview window, so i will crop 70 top and 74 bottom so im not left with 2 lines of black on the bottom of the image.

the file is cropped 70+74 (720x432) then output to 720x576 @ 16x9 @ 8000br (plays without any bars)

[manono]

the file is cropped 70+74 (720x432) then output to 720x576 @ 16x9 @ 8000br (plays without any bars)

Ok. The reason you got bars when you cropped down to 416 or 406 was because you were cropping too much and TMPGEnc was adding black to bring the height back to 432 before resizing back to 720x576. I guess it likes that cropping of a total of 144 rows of pixels (no black bars after resizing). And as you discovered, not all sources crop 72 top and bottom nicely, as sometimes the video isn't exactly in the middle. Perhaps I should have mentioned that the crops are supposed to total 144. However, this will wreak havoc on the interlaced video as you're cropping improperly. Both the top and bottom crops should be multiples of 4. Maybe this isn't important as TMPGEnc works in RGB. jagabo knows more about that than do I.

These are just more reasons why I much prefer doing these things in AviSynth, rather than letting the program do the cropping and resizing (or other filtering) for me. Do we know what resizer it uses? I know it used to be a very bad one, but maybe it's improved of late, or maybe you can choose the resizer.

[glenpinn]

However, this will wreak havoc on the interlaced video as you're cropping improperly. Both the top and bottom crops should be multiples of 4. Maybe this isn't important as TMPGEnc works in RGB. jagabo knows more about that than do I.

ok in tmpge (my camera) the bars are not equal top and bottom as i mentioned before, top is 64 and bottom is 74, so to avoid the thin bar at 72 on the bottom, ill got up to 76, and take the top crop from 72 to 68, both being multiples of 4, and still retain the crop of 144 lines total.

EDIT:

ok so now im understand how it works now guys, been flat out here trying experiments.

ok i am uploading the 16 second dv-avi test file (60mb)
also 2x mpeg2 files (15.7mb) and the Xvid file (10.5mb)

they will be ready soon.

i took the new 720x432 cropped dv-avi (68 top and 76 bottom) and output to various Xvid sizes, and finally got a size of 720x396 and it had no bars top/bottom, if i go to 398 or higher i get thin bars top/bottom and if i go lower than 720x396 i get bars on the sides, so it seems 396 is the ideal height for my Xvids from a 720x432 dv-avi or mpeg2.

i took my existing cropped 406 and 416 mpeg files (with the bars top and bottom) and cropped an extra 18 lines top and bottom (36 total) and output to Xvid at 720x372 which gave me no bars either way, so those mpeg files ill re-do them that way.

(just burning them to a dvd to test on my WS tv)

and fwiw, i will be starting my journey with avisynth as soon as i can get all this sorted out.
can you guys point me to what i need as far as software goes, i used to have virtualdubmod and virtualdub but that was ages ago, and a guide for scripting with avisynth if possible.

another question, why do you guys recommend using a lower resolution than 720xXXX for Xvid output, i always thought one should always retain the original 720xXXX where possible.

i just assumed keeping the original size was better for Xvid output.

EDIT: just output the 720x432 dv-avi to Xvid at 704x388 and at 640x352 and no bars, if i go any higher or lower than these sizes i get the thin bars either top/bottom or on the sides, depending if i go higher or lower.

(640x352 is a very common 16x9 dvd to Xvid rip size from what i have seen)

[G)-(OST]

To help make avisynth easier to use, I use AvsP, check it out in the tools list.

glenpinn, Check your PM

Denis

[manono]

another question, why do you guys recommend using a lower resolution than 720xXXX for Xvid output, i always thought one should always retain the original 720xXXX where possible.

You've got a very hard to compress source. The higher the resolution, the harder it is to compress and the more likely it'll play with stuttering during the complex parts. Personally, if I were trying to get an XviD AVI out of it that'll play on a standalone without stuttering, I'd go 624x352 or even lower, based on what I've seen of it so far. You could use the higher resolutions but the tradeoff will be either macroblocking, mosquito noise, and other artifacts during playback, stuttering during the high bitrate parts, or both.

Read everything here:

http://avisynth.org/mediawiki/Main_Page

Then read it again. As G)-(OST says, there are 3rd party apps out there to help with the script writing. AvsP is one of the best. FitCD is good when you have to do some cropping/resizing/adding of borders.

[glenpinn]

another question, why do you guys recommend using a lower resolution than 720xXXX for Xvid output, i always thought one should always retain the original 720xXXX where possible.

You've got a very hard to compress source. The higher the resolution, the harder it is to compress and the more likely it'll play with stuttering during the complex parts. Personally, if I were trying to get an XviD AVI out of it that'll play on a standalone without stuttering, I'd go 624x352 or even lower

yeah i output to 640x352 (its borderless) as explained in my previous post, and burnt all 3 Xvid outputs to try on tv now.

720x396
704x388
640x352

my uploads to RS are just about done.

EDIT: nah blast it, all 3 Xvid files on my tv's still have that jerking/stuttering on closeup objects when panning the camera fast.
it doesnt make any difference if its 720x396 or 640x352, still identical.
even at 624x352 i get thin bars top and bottom, 640x352 i dont.

the 720x432 mpeg2 files are great, smooth as pie on playback on all my tv's.

remember, this was the new dv-avi i shot today, cropped 68+76 to 432 and output to Xvid at 3.0 quant.

[glenpinn]

ok here are the RS download links guys.

take what you need, but as i see it at the moment, these are the best i can get from that TEST dv-avi source file, using the software im currently using.
if avisynth can do it better then i will start using it, when i have larnt how to use it.

01. TEST dv-avi filmed in 720x567 native 4x3 mode (60mb)
http://rapidshare.com/files/242126109/01-TEST__dv-avi_.avi

02. 720x576 dv-avi (no cropping) output to mpeg2 @ 4x3 @ 8000br (16mb)
http://rapidshare.com/files/242149019/02-mpeg2_720x576_no_crop___4x3___8000br_vbr.mpg

03. 720x576 dv-avi cropped to 720x432 (68 top-76 bottom) output to 16x9 mpeg2 @ 720x576 @ 8000br (16mb)
http://rapidshare.com/files/242151964/03-mpeg2_crop_720x432___16x9___8000br_vbr.mpg

04. 720x432 dv-avi output to Xvid at 720x396 @ 3.0 quant (9mb)
http://rapidshare.com/files/242154541/04-dv-avi_720x432_to_Xvid_720x396___3.0_quant.avi

05. 720x432 dv-avi output to Xvid at 704x388 @ 3.0 quant (8.5mb)
http://rapidshare.com/files/242157316/05-dv-avi_720x432_to_Xvid_704x388___3.0_quant.avi

06. 720x432 dv-avi output to Xvid at 640x352 @ 3.0 quant (7mb)
http://rapidshare.com/files/242160458/06-dv-avi_720x432_to_Xvid_640x352___3.0_quant.avi

07. 720x432 dv-avi output to Xvid at 480x264 @ 3.0 quant (4mb)
http://rapidshare.com/files/242164058/07-dv-avi_720x432_to_Xvid_480x264___3.0_quant.avi

[jagabo]

so why does it output the mpeg2 to 16x9 using 720x432 without bars and at 406 or 416 i get bars ???

Because PAL DV pixels are not square. The 720x576 frame contains a 4:3 image but the ratio of 720:576 is not 4:3, it's 5:4. The relation ship between the storage aspect ratio (frame size, SAR), pixel aspect ratio (PAR, shape of each pixel), and display asepect ratio (DAR, shape of the final displayed image) is:

DAR = SAR * PAR

or rearranging:

DAR/SAR = PAR

so a 4:3 video in a 720x576 frame the individual pixels have an aspect ratio of:

(4/3) / (720/576) = PAR
1.3333 / 1.25 = PAR
~1.0667 = PAR

So your calculated 405 pixel height has to be modified by the PAR

405 * 1.0667 = 432.

TMPGEnc knows this, and knows that DVD MPEG pixels are not square, so it makes all the appropriate adjustments.

For Xvid output you can just crop away the black bars and set the Xvid PAR to 4:3 PAL. A good player will adjust the DAR correctly.

I recommend you use something with an obvious aspect ratio for testing. Film a sphere (soccer ball, basketball), a car tire directly from the side, a square object, etc. This makes AR errors obvious. The object in question should be near the center of the frame, not off in the corner somewhere.

Use a bitrate viewer to examine the bitrate of your videos.

Try switching to single B frames. Some players have problems with 2 B frames, especially with packed bitstream.



Also try 2 B frames without packed bitstream.

And lastly, note that the max bitrate a player can handle when playing MPEG 2 vs when playing MPEG 4 are not the same. MPEG 4 decoding is much more complicated.

Did your 480x264 xvid file play smoothly?

[glenpinn]

ok i have taken note of everything so far, need time to work on these fine tunings bits.

AND m8, no the 480x264 didnt play any smoother than the 720x396, same stuff happening.

ill go do some more testing, but for the best part, 150 of the 170 mpeg2 files i converted to 16x9 i still have the original 4x3 files on a spare hdd in my drawer, so i can take those and re-crop them at 432 (correctly) then output to mpeg2 again, but the other 20 were cropped at 416 or 406 from the original dv-avi file and output to 16x9 size and i dont have the avi any more, so i cant change those, i tried already and no matter what i do now (crop the bars again) i still get black bars, so i can live with it.

least i know next time to crop only 144 lines from the original for mpeg2 then output the 720x432 file to 720x396 for Xvid.

bbl when ive done more tests.

and also, im now looking at buying a full HD camera, there are a lot of small consumer/pro-sumer cams out there that shoot in H264 but i need to research them b4 getting one, its a big step and i want to make the right choice, regarding format, and the storage method the cam films onto.

[jagabo]

the 480x264 didnt play any smoother than the 720x396, same stuff happening.

Then bitrate spikes probably aren't your (only) problem. I suspect you player doesn't like multiple consecutive B frames and packed bitstream. Try using MPEG4Modifier to unpack the 480x264 video and see if that plays smoothly.

[glenpinn]

the 480x264 didnt play any smoother than the 720x396, same stuff happening.

Then bitrate spikes probably aren't your (only) problem. I suspect you player doesn't like multiple consecutive B frames and packed bitstream. Try using MPEG4Modifier to unpack the 480x264 video and see if that plays smoothly.

just unpacked the bitstream of that file and nothing changed.

the settings i was using on those Xvids i did was BVOPs 2 and packed bitstream enabled.

i just tried those other settings with the packed bitstream and BVOPs and again, no change ???

im going to leave BVOPs on 1 and disable packed bitstream and keep trying more with this.

the thing i know at least so far is that 720x396, 720x388, 640x352 and 480x264 are the correct Xvid sizes for outputting my 406/416 mpegs and the new ones i do at 432, as they all play without bars.

just have to get this jittering fixed, if possible, but at least i understand a heap more now so i have various options to play with, then avisynth to play with.

[jagabo]

Start at the bottom and work your way up until you figure out what the problems are.

Make a 320x192 at a 400 kbps CBR with no B frames and no audio. If that plays smoothly add mp3 audio at 128 kbps CBR. It that plays smoothly step up to 1 B frame, both packed and unpacked. Etc.

[glenpinn]

Start at the bottom and work your way up until you figure out what the problems are.

Make a 320x192 at a 400 kbps CBR with no B frames and no audio. If that plays smoothly add mp3 audio at 128 kbps CBR. It that plays smoothly step up to 1 B frame, both packed and unpacked. Etc.

hey, should i drop the 48000/224 audio to 44100/128 for the Xvids ??? (probably a silly idea tho)

and yeah, at least i now have the ammo i need to work with for testing, but ill be gone for a few days working away away from home and wont get much time on the pc, but by weeks end ill try to get more testing done, as its a little time consuming at times, and the family life takes a bit of a hit too, cos i sit up till 3am some mornings doing this stuff.

ill be back in a few days with any updates, so thanks for everything till now, i know im a pain in the butt, and im not good at explaining stuff too well, but i try.

cheers guys and thanks for your time, i do appreciate it.

[glenpinn]

hey guys, i have tried outputting a sample of the wedding mpeg to Xvid at 720x396 with the following settings and all has an average bitrate of 4500 to 4700

i also tried 480x264 with the same settings using a target quantizer of 4.0 and all resulted in average bitrate between 1400 to 1600

target quant 3.0 - 1 bvop - pack bitstream
target quant 3.0 - 2 bvop - pack bitstream
target quant 3.0 - 1 bvop - no bitstream
target quant 3.0 - 2 bvop - no bitstream
target quant 3.0 - disable BVOPs totally (just thought i would try it)

i decided the target quantizer of 3.0 was good enough output quality, looking at the mpegs and Xvids side by side, and obviously wont have quite the massive bitrate spikes that were obvious on the 2.0 target quantizer quality.

on both 720x396 and 480x264 the dvd player and noontek hdd media players both still play them jittery on extreme bits, but overall in most of the mpegs there isnt a lot of this wedding type footage, and where there is, i guess im going to have to deal with it for now, least for the short term till i sort it out.

NOW b4 i do anything else, which of the above outputs (in your opinion) "SHOULD" be closest to the correct setting for these mpeg2 to Xvid outputs. hopefully one of them must be considered better than the others.

before i want to start output using Avisynth etc, im going to take the test dvd disc to several family members places who have different types/brands of dvd players and see what they do on those, and if still the same issue, then we start again.
if i get a positive result on one of them, then we work on the output setting that seems to work best on that player.

im also taking it to my brothers house tonight to try it from his HTPC setup in his loungeroom straight to his 42" HD plasma/lcd which ever it might be (its not a full HD tv btw)

will post back later on.

[jagabo]

NOW b4 i do anything else, which of the above outputs (in your opinion) "SHOULD" be closest to the correct setting for these mpeg2 to Xvid outputs. hopefully one of them must be considered better than the others.

None of them is more correct than the others. They are simply different choices.

In Target Quantizer mode, the more B frames you use the lower the bitrate will turn out. This is because B frames are encoded with a higher quantizer (lower quality). The idea being that you won't notice one or two lower quality frames flash by in realtime playback, the quality is cleaned up again by the next P or I frame. (Also, the ability to reference earlier or later frames theoretically allows more bitrate savings. In practice though, the lower quality is the major reason B frames lower the bitrate.)

Packed Bitstream is a matter of how the B and P frames are packaged within the AVI file. Microsoft's VFW library is based on a one-frame-in-one-frame-out model. It reads one frame worth of compressed video from the file, decompresses it, then hands the decompressed frame to the calling program. Within an Xvid AVI file I frames are encoded in their entirety like JPEG images. B and P frames only encode the differences between frames. With only P frames each P frame encodes the differences between the current frame and the frame immediately before it. This is not a problem for VFW. But when you add B frames to the mix, the B frames can encode the differences between an earlier I/P frame OR a later I/P frame. So the later I/P frame must be decoded before the B frames can be decoded. This causes problems for VFW.

So in a sequence like IBBP the I frame must be decoded first, the P frame is decoded second (it contains only the differences itself and the I frame), then the two B frames can be decoded (they will reference the I frame or the P frame).

Packed Bitstream is a kludge to get around the fact that the two B frames can't be decoded until the P frame has been decoded. Groups of B and P frames are saved within the AVI file as if they are a single frame. Then two Null frames are added as placeholders for the missing frames. When decoded by VFW it reads the first frame of compressed video (the I frame) and hands it to the Xvid decoder. The Xvid decoder decodes it and passes it to the calling program. Then VFW reads in the next frame of compressed video. But this frame of data actually contains 3 frames, the two B frames and the P frame. The P frame is decoded then then two B frames. All three saved within the Xvid decoder. The first B frame is returned to the calling program but the Xvid decoder remembers that it has two more frames ready. Then VFW reads in the first null frame and hands it to Xvid. Xvid ignores that frame but returns the second B frame. Finally, VFW reads the next null frame, and Xvid returns the final P frame.

Out of order decoding isn't a problem for DirectShow (used by most software players) since it was designed to handle out of order decoding. (Microsoft still includes VFW in all its operating systems but it hasn't been updated in many years. Typically, editors use VFW because it's simpler than DirectShow.)

Some players can't play B frames at all (very early Divx/DVD players, cell phones, portable players, etc). Some can only handle 1 B frame, some 2. Some requires packed bitstream, some only play without packed bitstream, some don't care either way. The safest bet is to use no B frames but this will cost you in bitrate. Second safest is 1 B frame with packed bitstream. Divx Home Theater certification requires the ability to play 1 B frame with packed bitstream.

[glenpinn]

Some players can't play B frames at all (very early Divx/DVD players, cell phones, portable players, etc). Some can only handle 1 B frame, some 2. Some requires packed bitstream, some only play without packed bitstream, some don't care either way. The safest bet is to use no B frames but this will cost you in bitrate. Second safest is 1 B frame with packed bitstream. Divx Home Theater certification requires the ability to play 1 B frame with packed bitstream.

ok i actually decided on 1 B Frame and packed bitsteam (Xvid uses 2 B Frame with packed bitstream as defautl) as it just seemed like a logical combination (dont ask why) but your speel above just re-enforced this somewhat, and i have already finished converting all my sons rock band gigs from mpeg2 to Xvid with target quant of 3.0 and 1 B Frame, packed bitstream enabled.

watching those on tv, i cant tell any difference between the mpeg2 and the Xvids, and most were shot indoors under low light, the bitrates were not that high on average, apart from a 3 set gig they played on the lawns at college last year, but it was filmed from 50 feet away so no extreme stuff was in it like that wedding clip i showed you.

overall there wont be too much of that jerking on many of the files, so for now ill be happy with what i have, but i didnt get a chance yet to try my new test files done today on other dvd players or my brother HTPC.

Im also keeping them at 720x396 for now, till i decide whether to go down to 640x352 and output to 4.0 target quant, as in my testing i tried this and they still looked very good.

i was always hesitant to drop from dvd resolution down to lower res because i honestly thought they wouldnt look too good, given that my mpegs and the Xvids will all be played on HD widescreen tv some day and will need to be upscaled, and was always worried how the lower res files would look on HD tv.

anyway, thanks again for the help/advice, much appreciated again.

bbl with any more news.