Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 ASP

Reply
 
Thread Tools Search this Thread Display Modes
Old 18th March 2004, 12:16   #1  |  Link
maciek_m
Registered User
 
Join Date: Feb 2004
Location: Poland
Posts: 48
Packed bitstream - what the ... is that?

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?
maciek_m is offline   Reply With Quote
Old 18th March 2004, 13:40   #2  |  Link
HarryM
Registered User
 
Join Date: May 2002
Location: Czech rep.
Posts: 390
"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.
__________________
Czech DivX/XviD discussion club
HarryM is offline   Reply With Quote
Old 18th March 2004, 13:53   #3  |  Link
maciek_m
Registered User
 
Join Date: Feb 2004
Location: Poland
Posts: 48
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)?
maciek_m is offline   Reply With Quote
Old 18th March 2004, 14:21   #4  |  Link
sysKin
Registered User
 
sysKin's Avatar
 
Join Date: Jun 2002
Location: Adelaide, Australia
Posts: 1,167
Quote:
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
__________________
Visit #xvid or #x264 at irc.freenode.net
sysKin is offline   Reply With Quote
Old 18th March 2004, 14:39   #5  |  Link
maciek_m
Registered User
 
Join Date: Feb 2004
Location: Poland
Posts: 48
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?

Last edited by maciek_m; 18th March 2004 at 14:41.
maciek_m is offline   Reply With Quote
Old 18th March 2004, 14:58   #6  |  Link
sysKin
Registered User
 
sysKin's Avatar
 
Join Date: Jun 2002
Location: Adelaide, Australia
Posts: 1,167
Quote:
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.
Quote:
P.S. sysKin
Your name (Radek) implies you are of Polish origin. Are you?
Definitely correct
__________________
Visit #xvid or #x264 at irc.freenode.net
sysKin is offline   Reply With Quote
Old 18th March 2004, 15:21   #7  |  Link
maciek_m
Registered User
 
Join Date: Feb 2004
Location: Poland
Posts: 48
@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.

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?

Last edited by maciek_m; 18th March 2004 at 15:42.
maciek_m is offline   Reply With Quote
Old 18th March 2004, 15:51   #8  |  Link
HarryM
Registered User
 
Join Date: May 2002
Location: Czech rep.
Posts: 390
Quote:
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.


"Radek" is 24. most frequent first name in my country, 54 thousands(!) peoples (1.09% of male population).
__________________
Czech DivX/XviD discussion club

Last edited by HarryM; 18th March 2004 at 15:54.
HarryM is offline   Reply With Quote
Old 18th March 2004, 15:53   #9  |  Link
HarryM
Registered User
 
Join Date: May 2002
Location: Czech rep.
Posts: 390
Quote:
Originally posted by sysKin
Nah HarryM, you're wrong. The order is kept the same.

Hope that helps,
Radek
I'm sorry, my mistake.
__________________
Czech DivX/XviD discussion club
HarryM is offline   Reply With Quote
Old 18th March 2004, 16:01   #10  |  Link
Wishbringer
Silent Reader
 
Wishbringer's Avatar
 
Join Date: Dec 2003
Location: Germany
Posts: 295
Quote:
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.
Wishbringer is offline   Reply With Quote
Old 19th March 2004, 09:57   #11  |  Link
maciek_m
Registered User
 
Join Date: Feb 2004
Location: Poland
Posts: 48
@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

Last edited by maciek_m; 19th March 2004 at 10:00.
maciek_m is offline   Reply With Quote
Old 22nd March 2004, 10:37   #12  |  Link
maciek_m
Registered User
 
Join Date: Feb 2004
Location: Poland
Posts: 48
multiple b-frames in DivX

Looks like I can safely use multiple b-frames in my XviD encodes, standalone-wise. Here is the quotation from a Doom9 portal 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."
maciek_m is offline   Reply With Quote
Old 22nd March 2004, 15:53   #13  |  Link
Jawor
Ex-ter-mi-nate!
 
Jawor's Avatar
 
Join Date: Jan 2004
Location: www.videoaudio.pl
Posts: 218
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
__________________
Please excuse if my English is crappy.

Archive of my Xvid builds

http://www.videoaudio.pl
Jawor is offline   Reply With Quote
Old 22nd March 2004, 16:03   #14  |  Link
maciek_m
Registered User
 
Join Date: Feb 2004
Location: Poland
Posts: 48
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!!

Last edited by maciek_m; 22nd March 2004 at 16:08.
maciek_m is offline   Reply With Quote
Old 23rd March 2004, 12:58   #15  |  Link
gatormac
Registered User
 
Join Date: Feb 2004
Posts: 123
I was thinking the same thing....its been very quiet from the big boys. Me thinks something is about to happen....
gatormac is offline   Reply With Quote
Old 23rd March 2004, 13:11   #16  |  Link
sysKin
Registered User
 
sysKin's Avatar
 
Join Date: Jun 2002
Location: Adelaide, Australia
Posts: 1,167
Quote:
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

Radek
__________________
Visit #xvid or #x264 at irc.freenode.net
sysKin is offline   Reply With Quote
Old 4th January 2007, 05:15   #17  |  Link
new_age
SW & FW developer/modder
 
new_age's Avatar
 
Join Date: Mar 2002
Posts: 178
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

Last edited by new_age; 4th January 2007 at 05:25.
new_age is offline   Reply With Quote
Old 4th January 2007, 13:23   #18  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
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.
foxyshadis is offline   Reply With Quote
Old 4th January 2007, 13:49   #19  |  Link
new_age
SW & FW developer/modder
 
new_age's Avatar
 
Join Date: Mar 2002
Posts: 178
Well they support DivX packed bitstream with 1 B-VOP. Only xvid packed bitstream with 2 B-VOPs are problematic for older mtk firmwares.
new_age is offline   Reply With Quote
Old 29th January 2007, 18:29   #20  |  Link
barakori
Registered User
 
Join Date: Sep 2003
Location: Israel
Posts: 24
What is Packed Bitstream?

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....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.
barakori is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 18:42.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.