[ExtractStream] Possible end of ZSS development...

[Jim Hauxwell]

Hi,

I've decovered where you are going wrong in your interpretation of the GOP
decode dependancies.

The B's at 2 & 3 require the I at 1 and P at 4, the B's at 5 and 6 require
the P's at 4 and 7. The B's at 8 and 9 require the P's at 7 and 10. B's at
11 and 12 require P at 10 and I at 13. The B's 8 and 9 are not dependant on
the I in GOP two, but the B's 11 & 12 do.

I think, to get resyncronisation, you are possibly going too deep into this
problem. I am under the impression (and I've only been looking at this for
about two weeks now) that the PES headers are perfectly valid. The only
'problem' with them is that the video PES headers are marked as having 0
length, which according to the spec means 'get the size from the transport
stream'. This 16bit value could be filled in and then the two program
streams remuxed back, without altering the original PTS information. This
should produce in sync streams when played on a complient player.

Jim



>And get :
>
>GOP I P B B P B B P B B GOP I B B P B B P B B
> 1 4 2 3 7 5 6 10 8 9 13 11 12 16 14 15 19 17 18 <- these
>values represent the temporal decode order

>So in your example the Closed flag should be 0, as you do require the next
I
>frame in the subsiquent GOP to decode the two last B frames.

Not in your order, you don't. The Bs at 2 and 3 require the I and P at 1
and 4. The Bs at 5 and 6 need the P at 4 and the P at 7. The Bs at 8 and
9 needs the P at 7 and the P at 10. They have no need for the I in
GOP2. By definition if you are in DTS order, they shouldn't, since if you
are correct and the frames are in decode order than all the info they need
has ALREADY been supplied to the decoder before they arrive.

After doing more checking, I think you are right about the order. The
temporal sequence number within the frames is saying so.

Checking temporal sequence based on the header for the frame :

I 2
B 0
B 1
P 5
B 3
B 4
P 7
B 5
B 6
P 9
B 7
B 8
P 11
B 9
B 10
P 14
B 12
B 13

The GOP is marked as open NOT because the last B frames require the next
I-Frame, but because the first 2 B frames have a backward reference to the
last P or I frame in the previous GOP? The question that arises is what is
the formal MPEG definition of that flag?

Ok, better. This is finally beginning to make sense. In this case,
looking at the PES time-stamps again :

1 PES Video Header Found....Result = 1212.855556 I
2 PES Video Header Found....Result = 1146.111111 B
3 PES Video Header Found....Result = 1179.477778 BP
4 PES Video Header Found....Result = 1246.211111 B
5 PES Video Header Found....Result = 1279.577778 BP
6 PES Video Header Found....Result = 1346.311111 B
7 PES Video Header Found....Result = 1379.677778 BP
8 PES Video Header Found....Result = 1446.411111 B
9 PES Video Header Found....Result = 1479.777778 BPB
10 PES Video Header Found....Result = 1546.511111 B
Next GOP Header
11 PES Video Header Found....Result = 1579.888889 I

And re-ordering :
B @ 2 PTS 1146
B @ 3 PTS 1179
I @ 1 Frame PTS 1212
B @ 4 Frame PTS 1246
B @ 5 Frame PTS 1279
P @ 3 Missing PTS? 1312
B @ 6 PTS 1346

Hmmmm... I still get the nagging feeling that something is still wrong with
this picture....



To unsubscribe from this group, send an email to:
ExtractStream-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/