Packed bitstream - what the ... is that?

[maciek_m]

A newbie from Poland, after the quarantine, wants to greet everybody. Especially those who sweat to give us, lazy consummers, this great product.

And, behaving like a true newbie, I would like to post a question.

Could anybody try to explain what "packed bitstream" is really supposed to do?

What I understood from Crusty's FAQ/guide (and other information sources) is that packed bitstream is supposed to solve problems which it can also introduce itself (jerky playback). Not good enough for me. Most of explaintions concerning other issues are really fine and allow me to uderstand given option to some extend and start experimenting. With this one I don't have a clue.

In addition, I would like to be able to put my disks in a standalone some time in the future. So even if an option doesn't seem to influence the output now, it might be important in the future.

To make a long story short.
What is packed bitstream expected to do, really? How can I make sure if it really does it? Is it likely to be used in standalones?

[HarryM]

"Packed bitstream" is only better(?) order of I/P/B frames in videostream.
Conventionally is e.g.
IPBBPBBPI
123456789 (conventional order)



at packed bitstream is
IPPBBPBBI
125348679 (packed bitstream order)
The appropriate B-frames are ordered behind the two "necessary" P-frames.
Positive: You get only one frame delay.

[maciek_m]

Thanks a milion, however

In his FAQ, Crusty claims that:

"Closed GOV ensures that a p-frame is used before every new I-frame. This option should always be checked (otherwise you might end up with a frame sequence like PBIP where the B frame has a forward reference to an I-frame which makes no sense)."

Does it mean that packed bitstream introduces something that from "closed GOV point of view" is unwanted(i.e. a B-frame before I-frame)?

[sysKin]

Originally posted by HarryM
"Packed bitstream" is only better(?) order of I/P/B frames in videostream.
Conventionally is e.g.
IPBBPBBPI
123456789 (conventional order)

at packed bitstream is
IPPBBPBBI
125348679 (packed bitstream order)
The appropriate B-frames are ordered behind the two "necessary" P-frames.
Positive: You get only one frame delay. Nah HarryM, you're wrong. The order is kept the same.

The differece is "packing": first b-frame is packed together (in an avi) with its future reference (a p-frame most likely). Future reference is transmitted first because it has to be decoded first, but the frame you actually want to *see* is the b-frame. So, packing delivers the b-frame immiedietly, so it can also be decoded and shown on time.

Without packing, decoder gets future reference, but has to wait for the b-frame before it can display anything. This creates a one-frame lag, which makes such avi difficult to seek in (for example) virtualdub.

Hope that helps,
Radek

[maciek_m]

Yes, it does!

Now, am I right to assume, that such an improvement would be used in a standalone players? Or their efficiency/decoding speed is high enough not to employ such a technique? ('cos It's not implemented in standalones yet, is it?)

P.S. sysKin
Your name (Radek) implies you are of Polish origin. Are you?

[sysKin]

Originally posted by maciek_m
Now, am I right to assume, that such an improvement would be used in a standalone players? Or their efficiency/decoding speed is high enough not to employ such a technique? ('cos It's not implemented in standalones yet, is it?)It doesn't matter for them. Most players are able to fetch any number of frames they want, and decode them in any order they want. They can just read next AVI frame if that's what they feel like.
In VDub's case, it's VfW interface that gives problems: it doesn't allow decoder to read future frames, even if decoder needs them. Decoder is forced to output a picture based on the frames it's already seen.

Standalones will most likely prefer packed bitstream because that's what DivX5 uses. However, DivX5 only uses one b-frame, so any decoder can be confused if it finds a second b-frame (which is not packed anymore, there is no need).
Therefore, the safest way is to use 1 b-frame in packed mode - perfect DivX5 compatibility. Everything else might, or might not, give problems to poorly tested standalones.
P.S. sysKin
Your name (Radek) implies you are of Polish origin. Are you? Definitely correct :)

[maciek_m]

@sysKin
Of Polish origin, born in ... :)

Back to the topic
I'm not planning to get a standalone very soon, as I would like it to use some "fancy" technology, such as oggmedia for example. Obviously, it would have to be of tested quality and decent price at the same time:D.

Therefore, I guess I might risk using packed bitstream and more b-frames - if it really works people in DivX will have to use it sooner or later, won't they?

[HarryM]

P.S. sysKin
Your name (Radek) implies you are of Polish origin. Are you? [/B]

Name "Radek" is Slavonic origin generally (not only Polish). In Czech rep. we have many Radek's too.
:D :D

"Radek" is 24. most frequent first name in my country, 54 thousands(!) peoples (1.09% of male population).

[HarryM]

Originally posted by sysKin
Nah HarryM, you're wrong. The order is kept the same.

Hope that helps,
Radek

I'm sorry, my mistake.

[Wishbringer]

Originally posted by maciek_m
Now, am I right to assume, that such an improvement would be used in a standalone players? Or their efficiency/decoding speed is high enough not to employ such a technique? ('cos It's not implemented in standalones yet, is it?)
[/B]

Most Standalones based on Mediatek-Chips have problems with packed-bitstream and start to stutter. Some ESS based too.
But with newer firmware they play fine (but unfort. most lowcost players don't get updates).
So better leave packed-bitstream disabled while encoding to increase compability.

[maciek_m]

@Wishbringer
I understand your point, but ...
When I spend hours playing with various options, things as GMC, packed bitstream or compression curve, then my principle is best quality rather then maximum compatibility. So as long as I am able to play my disks in my player, and as I said, if I buy one it's going to be a capable one, I'm satisfied.

@HarryM
Gee, you must have made quite a research to get all this data.

Anyway, we got a kin overseas:)

[maciek_m]

Looks like I can safely use multiple b-frames in my XviD encodes, standalone-wise. Here is the quotation from a Doom9 portal :D news:

"heise online has interviewed DivX creator Gej at CeBit. He mentioned that DivX5.2 should be released in June, and have an improved psy model, support custom quant matrices and multiple b-frames."

[Jawor]

Fate, it seems, is not without a sense of irony.
Morpheus, The Matrix

Thanks to the new DivX codec standalone players will (?) decode XviD properly ;)

BTW, I'm Polish too :D

[maciek_m]

Hi, there is never too many ...

I should think so. So far the b-frames have been reported among the main factors underlying incompatibilities between the two coding methods.

Unfortunately, sth tells me that there are guys who are currently working on something they will put, lets say in the 1.1 release of XviD, which will dramatically improve quality of encoding and drastically reduce compatibility with DivX.

And I tell you, these guys are currently up to somthing, as they seem not to be very active in the forum - XviD 1.0 is coming!!

[gatormac]

I was thinking the same thing....its been very quiet from the big boys. Me thinks something is about to happen....

[sysKin]

Originally posted by gatormac
I was thinking the same thing....its been very quiet from the big boys. Me thinks something is about to happen.... Nothing unexpected is about to happen, we all know that XviD's code is ready for release. There are just some technical issues remaining before 1.0 final - once they are resolved, there will be an announcement and a tarball and probably some binary and that's it. Almost nothing new compared to rc3, most likely absolutely nothing new compared to current dev-api-4 tree.

In the meantime, I am back to what I like the most - bugadding! XviD 1.1 has been started, and although it's currently identical to dev-api-4 - oh you just wait, you'll see :devil: :devil: :devil:

:D Radek

[new_age]

Hello Guys!

I'm trying to understand why standalone players with older firmwares are shuttering with xvid packed bitstream.

Can someone explain me why it is happening? The reason is the 2 B frames and one is packed. Older mt1389 firmwares didn't expect another B frame?
I guess the decoded frame order is not right this is the reason for shuttering but in which order decode the frames the older non xvid packed bitstream compatible firmwares?

Like this is shuttering in an old MT1389 firmware:

0: I-VOP (0:00:00.000)
1: P-VOP (0:00:00.125)
B-VOP (0:00:00.041)
2: B-VOP (0:00:00.083)
3: N-VOP(D) (0:00:00.125)
4: P-VOP (0:00:00.250)
B-VOP (0:00:00.166)
5: B-VOP (0:00:00.208)
6: N-VOP(D) (0:00:00.250)

after unpacking with mpeg4modifier:

0: I-VOP (0:00:00.000)
1: P-VOP (0:00:00.125)
2: B-VOP (0:00:00.041)
3: B-VOP (0:00:00.083)
4: P-VOP (0:00:00.250)
5: B-VOP (0:00:00.166)
6: B-VOP (0:00:00.208)

and what is the purpose of the N-VOP(D) in this case?

regards,

NA

[foxyshadis]

It just means older mediatek systems don't support packed bitstream at all, because they choke on the null frames pb uses to keep sync; that's entirely why unpacking was added to mpeg4modifier. There's a discussion about it in the tool's thread.

[new_age]

Well they support DivX packed bitstream with 1 B-VOP. Only xvid packed bitstream with 2 B-VOPs are problematic for older mtk firmwares.

[barakori]

I think it's a bit hard to follow this thread to know what Packed Bitstream is. Also, an explanation using images could be quite beneficial. Therefore, I added such information into my blog at http://itsjustonesandzeros.blogspot.com/2007/01/what-is-packed-bitstream.html. Please see this post and tell me if you think there are any errors, or places where things could have been explained better.

[new_age]

Quite good. I only miss more info about why N-VOP is needed.
I also suggest to include a timecode in the pictures since after using packed bitstream the time code of each VOP won't be linear. It is descibed in the text but would much more easy to understand having timecode too.