From: Michel L. <wa...@us...> - 2001-09-03 09:58:16
|
Update of /cvsroot/libmpeg2/mpeg2dec-streams/twilight_zone/walken/mpeg1_slice In directory usw-pr-cvs1:/tmp/cvs-serv2944 Modified Files: README Log Message: actually I found a reference in mpeg1 making it clear that the general slice structure is NOT legal. So this test stream is bogus ! Index: README =================================================================== RCS file: /cvsroot/libmpeg2/mpeg2dec-streams/twilight_zone/walken/mpeg1_slice/README,v retrieving revision 1.1 retrieving revision 1.2 diff -u -d -r1.1 -r1.2 --- README 2001/09/03 05:30:46 1.1 +++ README 2001/09/03 09:58:09 1.2 @@ -6,23 +6,15 @@ profiles use the restricted slice structure - so in practice the general slice structure is never used. -The situation is not so clear with mpeg1 - this standard does not -formally define the notions of general and restricted slice -structures. It mentions in D.5.4 that there can be no gap or overlab -between slices - so this is equivalent to the restricted slice -structure in mpeg2 - however the mpeg1 annex D is not normative, and -the mpeg1 standard does not talk about that possibility anywhere else. - -So I believe the usage of a general slice structure is a loophole in -the mpeg1 standard, and that the for such a stream the decoder's -output between the coded slices is undefined, just as in the mpeg2 -standard. - -The libmpeg2 behaviour here is that it will not touch the pixels -betweent he coded slices, so they will keep whatever value they had -when vo_get_frame passed the picture. For this stream this results in -some ugly green blocks - however the mpeg2 reference decoder does -exactly the same thing, so I believe this is actually correct. +In mpeg1, the slices as defined in 2.4.1 are supposed to not overlap +or have gaps in-between, so the general slice structure is basically +illegal. This stream still uses it so the decoder's behaviour is (just +as in mpeg2) undefined. UCB's mpeg_play program seems to fill these non-coded blocks in black, -but I think this is only by chance not by design. +but I think this is only by chance not by design. libmpeg2, like the +mpeg2 reference decoder, has a different behaviour, it will not touch +the pixels betweent he coded slices, so they will keep whatever value +they had when vo_get_frame passed the picture. For this stream this +results in some ugly green blocks, but this is actually acceptable as +the stream is bogus. |