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;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Libmpeg2-devel mailing list
> Libmpeg2-devel@lists.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;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Libmpeg2-devel mailing list
Libmpeg2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmpeg2-devel

Reply via email to