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
