[MPlayer-users] Request info / Bug report : How SMPlayer reads "sequence header" & "sequence extension" from mpg ?

[Nico Sabbi]

Il lunedì 4 gennaio 2010 14:13:52 Alain-Pierre CHERTIER ha scritto:
> Hello everybody,
>
> I'm looking for method(s)/object(s)/function(s) involved by MPlayer
> to retrieve informations
> from an MPEG file, especially how it will read information fields
> from "sequence header" (start_code 0x00001B3)
> and "sequence extension" (start_code 0x000001B5), because I obtain
> a 6X speed factor when trying to read
> an MPEG video file which was encoded as 5 frames per second as
> MPlayer is thinking of a 30 fps video stream file...
>
> I think it is because MPlayer (or 3rd-party library functions used
> by MPlayer ?) don't use properly mixed info between
> "sequence header" and "sequence extension" which are well present
> in the MPEG file and have reliable detailed
> information about the video stream according to MPEG standard...
>
> Here below are valid informations in the MPEG file that don't seem
> to be taken into account properly by MPlayer:
>
> inside "sequence_header":
>
>   frame_rate_code = 5 (=> "frame_rate_value = 30 fps", if ignoring
> or miss-interpreting
>                                              extension data
> information in the "sequence extension"...)
>
> inside "sequence_extension":
>
>   frame_rate_extension_n = 0
>   frame_rate_extension_d = 5
>
> as specified in the MPEG standard, the formula to calculate the
> effective "frame_rate" shall be
>
>   frame_rate = frame_rate_value * (frame_rate_extension_n + 1) /
> (frame_rate_extension_d + 1)
>
>   with "frame_rate_value" being hard-coded and deriving from
> "frame_rate_code", as specified by the MPEG standard.
>
> With implementing the right standard formula, frame_rate shall be
> calculated as :
>
>   30 * (0 + 1) / (5 + 1) = 30 * 1 / 6 = 5 fps      
> yyyeeeeeesssssssssss !!!
>
> I recompiled MPlayer (on a Linux platform) with "-g" gcc compile
> flag, hopping to debug/run it step by step with "ddd",
> but I didn't find what object/function is effectively reading or
> not reading the "sequence extension" data
> to correct 1st level information data read from the "sequence
> header".
>
> As more information to you, please notice that the interesting
> "MediaInfo" tool seems to have (same) problem
> in its version 0.7.26 about mixing "sequence header" and "sequence
> extension" information, not (yet) applying
> the right standard MPEG formula, deciding by mistake to take
> "frame_rate_extension_n / frame_rate_extension_d"
> ratio from "sequence extension" as frame rate ( ! ) and ignoring
> frame_rate_code (frame_rate_value) from "sequence header"
> because "frame_rate_extension_n" is zero ! So, MediaInfo displays
> an invalid "0 fps" frame rate as a result from
> "0 / 5" division ! I sent an email about that to the french
> developper maintaining the MediaInfo tool
> (suggesting to him what modification to apply to source code to
> obtain the right frame rate value,
> as I tested/validated this modification by recompiling my own
> standard copy of MediaInfo source code).
> He replied to me, acknowledging for suggested modification.
>
> Hopping anybody can have a look at official source code of MPlayer
> and post an (approved) update,
> many thanks in advance, it may allow me to play "slow" videos which
> are ok against MPEG stream packet
> format, but unfortunately, almost all multimedia players are not ok
> with such "slow" encoded video streams !?
> VLC is hanging with such vids, only Windows Media Player from
> Microsoft seems to sometimes accept decoding & displaying
> of such vids at the right 5 fps frame rate display speed, but
> surprisingly announcing a 30 fps frame rate (!?) in the info
> window,
> like SMPlayer/MPlayer...
>
> It shall be noticed that other data information fields shall have
> to be also examined against being defined
> partly in "sequence header" and partly in "sequence extension":
>
> a good example (with potential "difficulty") is the "bit rate"
> which is defined as a 30bit value by the MPEG standard,
> with 18 lowest bits named as "bit_rate_value" ( ! ) in the
> "sequence header" and higher 12 bits "bit_rate_extension"
> in the "sequence extension"...
>
> 'hope my post can help to build a new version of MPlayer, because
> for now, I have to add the "-fps 5" option to MPlayer
> to properly decode/render our slow 5 fps mpeg stream, but we would
> have a transparent solution/way to play such streams
> without to have to specify the "-fps ?" option because we don't
> know the right fps before pre-decoding input files...
>
> Kind regards & many thanks in advance.
>
> Alain-Pierre
> <apclinux at gmail.com>

IIRC the MPEG parsing code was never updated to correctly handle the 
framerate extension, and (still IIRC) not even ffmpeg handles it