frame_rate_extension_n

	Hello.  I'm browsing through the SVN trunk for libmpeg2,
revision 1171.  My reference document is ISO 13818-2.  I'm
looking at the
frame rate calculation in "libmpeg2/header.c".  I
understand that
libmpeg2 calculates a reciprocal, called frame_period.  What
bothers
me is the frame rate extension adjustment in the routine
sequence_ext,
in the following line:

    sequence->frame_period =
        sequence->frame_period * ((buffer[5]&31)+1) /
(((buffer[5]>>2)&3)+1);


1)	It modifies frame_period in place.  If it is possible to
have
	two or more extension headers after a single sequence
header
	(I haven't yet figured out if the ISO spec says anything
about
	this possibility), then it seems to me that each frame
rate
	(frame_period) adjustment should start with the value from
the
	last sequence header (from my reading of section 6.3.3 of
the spec).
	The current libmpeg2 code would compound them, and this
seems
	incorrect.

2)	Based on section 6.2.2.3 of ISO 13818-2,
frame_rate_extension_n
	is a 2-bit field located before the 5-bit
frame_rate_extension_d
	field.  That implies that the correct way to extract this
field
	is:

        ((buffer[5]>>5)&3)

	not:

	((buffer[5]>>2)&3)


	According to the standard, these fields should be 0 for
standard profiles (table 8-5, table E-3), but I imagine that
libmpeg2
should apply these adjustment factors as defined by the
specification
in case there are video streams in which they are nonzero
(Sony comes
to mindm based on patent applications).

					Craig Milo Rogers

------------------------------------------------------------
-------------
This SF.net email is sponsored by the 2008 JavaOne(SM)
Conference 
Don't miss this year's exciting event. There's still time to
save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;1987
57673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Libmpeg2-devel mailing list
Libmpeg2-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmpeg2
-devel

Hi Craig,

On #1, I think we're good -- you can only have one
sequence_extension 
following a sequence_header. See 13818-2, clause 6.3.1 
("sequence_extension() shall only occur immediately
following a 
sequence_header()").

On #2, I think that's a real bug (that would, as you point
out, only 
affect bitstreams not conforming to a defined profile). I
agree it should 
be (((buffer[ 5 ] >> 5) & 0x03) + 1).

-Keith

On Sat, 3 May 2008, Craig Milo Rogers wrote:

> 	Hello.  I'm browsing through the SVN trunk for
libmpeg2,
> revision 1171.  My reference document is ISO 13818-2. 
I'm looking at the
> frame rate calculation in
"libmpeg2/header.c".  I understand that
> libmpeg2 calculates a reciprocal, called frame_period. 
What bothers
> me is the frame rate extension adjustment in the
routine sequence_ext,
> in the following line:
>
>    sequence->frame_period =
>        sequence->frame_period *
((buffer[5]&31)+1) / (((buffer[5]>>2)&3)+1);
>
>
> 1)	It modifies frame_period in place.  If it is
possible to have
> 	two or more extension headers after a single sequence
header
> 	(I haven't yet figured out if the ISO spec says
anything about
> 	this possibility), then it seems to me that each frame
rate
> 	(frame_period) adjustment should start with the value
from the
> 	last sequence header (from my reading of section 6.3.3
of the spec).
> 	The current libmpeg2 code would compound them, and
this seems
> 	incorrect.
>
> 2)	Based on section 6.2.2.3 of ISO 13818-2,
frame_rate_extension_n
> 	is a 2-bit field located before the 5-bit
frame_rate_extension_d
> 	field.  That implies that the correct way to extract
this field
> 	is:
>
>        ((buffer[5]>>5)&3)
>
> 	not:
>
> 	((buffer[5]>>2)&3)
>
>
> 	According to the standard, these fields should be 0
for
> standard profiles (table 8-5, table E-3), but I imagine
that libmpeg2
> should apply these adjustment factors as defined by the
specification
> in case there are video streams in which they are
nonzero (Sony comes
> to mindm based on patent applications).
>
> 					Craig Milo Rogers
>
>
------------------------------------------------------------
-------------
> This SF.net email is sponsored by the 2008 JavaOne(SM)
Conference
> Don't miss this year's exciting event. There's still
time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;1987
57673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Libmpeg2-devel mailing list
> Libmpeg2-devellists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libmpeg2
-devel
>

------------------------------------------------------------
-------------
This SF.net email is sponsored by the 2008 JavaOne(SM)
Conference 
Don't miss this year's exciting event. There's still time to
save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;1987
57673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Libmpeg2-devel mailing list
Libmpeg2-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmpeg2
-devel