'packed bitstream' yes or no ??

[Heini011]

Hi folks,

i had tested the 'packed bitstream' option with xvid 1.0 beta 2. with this i can save round about 3% space at q2-mode. i had no problems to play my encodes with ffdshow alpha, but i lost the ability to play the video on a old 500 mhz machine.

what is with the ffdshow-bug, on which circumstance occurs this? could it be, that this bug never get fixed and xvid 1.0 encodes plays not correctly on xvid versions in future?

i had read many postings about this feature and some people says, that 'packed bitstream' is necessacy to play encodes with b-frames correctly on stand-alone player. other says exactly the opposite. what is right?

i would like to use xvid with packed bitstream generally for archiving, but i worry about compatibility-problems.

any advice were welcome.

thanks, heini011.

[Teegedeck]

Originally posted by Heini011
i had tested the 'packed bitstream' option with xvid 1.0 beta 2. with this i can save round about 3% space at q2-mode.
Welcome to the forum, Heini011!

This would be amazing - because packed bitstream does not mean any type of compression but just a different way of storing B-frames. You don't gain (or save) anything with this option except for easier editability in VDub.

There shouldn't be compatibility problems with XviD DSF itself. I don't know anything about how hardware-players behave in regard to packed bitstream.

[Doom9]

teegedeck: hardware players seem to like packet bitstream.. even sigma players can handle multiple consecutive b-frames when you use packed bistream, without things can get choppy if you go above 1 b-frame

[Teegedeck]

Thanks for helping out!

[MfA]

It is a DIVX compatibility mode aimed at AVIs, since hardware players are designed for DIVX it is not a big surprise to see them using the information (although it isnt really a given, the "packed" bitstream just adds some useless information which can be easily inferred from the rest of the bitstream).

[Leak]

Originally posted by Teegedeck
Welcome to the forum, Heini011!

This would be amazing - because packed bitstream does not mean any type of compression but just a different way of storing B-frames.

Since this is about storing only - is there a way to convert a non-packed bitstream encoding to a packed bitstream one and vice versa? Or at least, could something like that be implemented without having to recompress the video?

(If it helps with standalone players, this would probably be very helpful if you've already encoded a lot without it... :))

np: nix

[Heini011]

i have tested this option with longer encodes again.

sorry: there are no differences in file-sizes and even on a fast PC (1.8 GHz Athlon) the 'packed bitstream' video plays not fluently width ffdshow.

so, if the ffdshow bug doesn't get fixed, we need the ability to play xvid 1.0 encodes correctly with future versions of xvid or we must make 2 encodes: one for pc without p.b. and one for stand-alones with p.b. :-(

could the xvid developer promise future support of xvid 1.0 encodes ? that would be great!!

greetings, Heini011.

[Heini011]

can i change this option between first and second pass ?

[sysKin]

Originally posted by Heini011
can i change this option between first and second pass ? There shouldn't be any problem.
Originally posted by Leak
Since this is about storing only - is there a way to convert a non-packed bitstream encoding to a packed bitstream one and vice versa? Or at least, could something like that be implemented without having to recompress the video?It's not difficult, but such application doesn't exist yet. I'd watch matroska guys who seem to be creating tools for reading and de-packing mpeg-4 avis - if they ever finish their "native streams" and allow muxing such streams back to avi, you'd get a choice - packed or not.

Or maybe mp4 guys are making some tools like that?

Radek

[Stux]

Originally posted by sysKin
There shouldn't be any problem.
It's not difficult, but such application doesn't exist yet. I'd watch matroska guys who seem to be creating tools for reading and de-packing mpeg-4 avis - if they ever finish their "native streams" and allow muxing such streams back to avi, you'd get a choice - packed or not.

Or maybe mp4 guys are making some tools like that?


3ivx D4 4.5 already supports bitstream unpacking. Basically when you mux a packed video stream into an MP4 it is unpacked, as a matter of course.

I wouldn't expect packing to increase compression efficiency :-\, if anything it should decrease it almost negligibly.

[sysKin]

Originally posted by Stux
3ivx D4 4.5 already supports bitstream unpacking. Basically when you mux a packed video stream into an MP4 it is unpacked, as a matter of course.Hehe yes ;) but if you ever made mp4->avi converter (I dunno what for, but IF) you'd probably have two options: packed or not.
In the end, it could be used for avi->avi packed/unpacked conversions :)

Now that I think of it, you'd have to change mpeg4's user data - at least xvid detects packed bitstream by finding DivX<version>b<build>p in user data... you'd have to add/remove this info somehow. Oh well.

Radek

[bond]

as i understand it

divx5's way to put b-frames in avi (packed bitstream) is a hack
xvid's way (no packed bitstream) is the way b-frames are meant to be in a mpeg-4 stream (and how they are also in .mp4)

thats why i prefer the default xvid way (no packed bitstream)

[Stux]

Originally posted by sysKin
Hehe yes ;) but if you ever made mp4->avi converter (I dunno what for, but IF) you'd probably have two options: packed or not.
In the end, it could be used for avi->avi packed/unpacked conversions :)

Now that I think of it, you'd have to change mpeg4's user data - at least xvid detects packed bitstream by finding DivX<version>b<build>p in user data... you'd have to add/remove this info somehow. Oh well.

Radek

We considered that... then we decided since DivX5 works fine without us rewriting that, we wouldn't bother ;). Our muxer policy is not to edit the VOL. So since we leave the 'p' in the VOL the hypothetical MP4->AVI converter could reconstruct the packed bitstream when it was initially packed.

Anywho, you can probably connect mp4 splitter->avi muxer, but I have no idea what the AVI muxer will do when it hits a VFR frame

[LeonMcNichol]

Does checking packed bitstream correct the bframe decoder lag you get when loaded in virtualdub and avisynth?

[Heini011]

Hi,

@changing p.b. option in second pass:

i had encoded a video with packed bitstream in 2-pass mode and made then a new second pass without p.b. the quality of this second encode was sligthly decreased. so i made a new 2-pass encoding. when i compare the xvid stat file from first pass with and without packed bitstream, then i see little differences in i and p-framesizes and the last frame from the video is missing, when i don't use packed bitstream. so it is not really a good idea, to change this option between frist and second pass.

with packed bitstream:

Frames : 133.431
Size : 1.687 MB, - 1.728.003 KB
MaxFrSize : 108 KB, - 1.886 KB/s
I-Frames : 1.140 - 52.711 KB
P-Frames : 47.467 - 1.094.339 KB
1B-Frames : 7.360 - 94.820 KB
2B-Frames : 73.642 - 477.840 KB
3B-Frames : 3.822 - 8.294 KB

without packed bitstream:

Frames : 133.430
Size : 1.687 MB, - 1.727.713 KB
MaxFrSize : 108 KB, - 1.886 KB/s
I-Frames : 1.140 - 52.693 KB
P-Frames : 47.466 - 1.094.061 KB
1B-Frames : 7.360 - 94.820 KB
2B-Frames : 73.642 - 477.842 KB
3B-Frames : 3.822 - 8.297 KB


---
Originally posted by LeonMcNichol
Does checking packed bitstream correct the bframe decoder lag you get when loaded in virtualdub and avisynth?

with packed bitstream this messages don't appear and you can easilier cut the encode with virtualdub.

greetings, Heini011.

[Heini011]

remark:

if someone find the xvid first-pass statistics usefull, i wrote a very little command-line tool (http://www.veganismus.com/reina/pc-site/XDstat.EXE) for that purpose.

greetings, Heini011.