Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#209 non standard compliancy issues with .mp4 creation

closed-fixed
nobody
None
5
2014-08-16
2004-07-28
bond
No

i noticed the following issues with the creation of .mp4
files:

- when muxing mpeg-4 video streams with b-frames
into .mp4 the "ctts" atom has to be produced, carrying
the time offsets
ffmpeg doesnt do this, altough its mandatory

- when importing mpeg-4 video streams placed in .avi
to .mp4, ffmpeg doesnt remove the VOL from every
keyframe (the vol is placed on every i-vop in .avi),
altough its not allowed to store the vol that way
together with the video data in .mp4, so any muxer has
to remove it

Discussion

  • bond
    bond
    2005-03-14

    Logged In: YES
    user_id=786427

    other issues i noticed:

    - the mandatory IODS atom is missing

    - in esds.decConfigDescr.objectTypeId there is always
    (independantly of the input video stream) the same ID set:
    advanced simple profile @ level 5: 32 (0x20)
    would be nice if ffmpeg would be able to read out and set the
    object type signalled in the bitstream

    - in esds.decConfigDescr.maxBitrate/avgBitrate the bitrate is
    always set to zero, altough ffmpeg is already able to
    calculate the bitrate, as it displays a bitrate after the muxing
    process

    - something doesnt seem to be correct in
    esds.decConfigDescr.decSpecificInfo.info. i am not sure but it
    seems as if it isnt set at all, which has to be the case!

    - when stream copying from .avi, mpeg-4 part 2 video streams
    dont get signalled as "mp4v" as defined in the standard but
    with their avi fourcc in the STSD atom (tested with xvid)
    when stream copying raw mpeg-4 video streams "mp4v" gets
    used

    - when stream copying raw mpeg-4 video streams there
    doesnt get the mandatory STSS atom created (sync sample
    atom)
    when stream copying mpeg-4 part2 video streams from .avi
    thats the case

    - things, like creation time aso are not set, but thats also not
    really important

     
  • bond
    bond
    2005-03-14

    Logged In: YES
    user_id=786427

    i also noticed problems with the keyframes when seeking on
    ffmpeg created .mp4 files:
    the mp4 parsers of videolan, mplayer and 3ivx all show me
    typical "missing keyframe" problems when seeking (only a
    part of the pic is displayed, the other part is from the pic
    shown before the seeking)
    mplayer also gives me a "first frame is no keyframe" warning.
    (the .mp4 parser from nero doesnt want to open the file at all,
    but that might be a different issue)

    of course the first frame is a keyframe in the input (i tested
    mpeg-4 streams encoded with nero, divx5 and xvid, which
    didnt show this problem when being muxed into .mp4 with
    mp4box and mp4creator)

    also this occurs independently of the used mpeg-4 encoder,
    or whether muxing from raw or .avi, or whether the stream
    uses b-frames or not

     
  • bond
    bond
    2005-06-25

    Logged In: YES
    user_id=786427

    "- something doesnt seem to be correct in
    esds.decConfigDescr.decSpecificInfo.info. i am not sure but it
    seems as if it isnt set at all, which has to be the case!"

    the missing decspecificinfo.info only seems to be the case
    when muxing raw part2 video to .mp4
    when encoding with mpeg-4 to .mp4 its written

     
  • bond
    bond
    2005-07-05

    Logged In: YES
    user_id=786427

    my findings on avc/h.264:

    when encoding:
    - the mandatory and very important avcC atom is missing

    - the mandatory ctts atom is missing when using b-frames,
    which shows the frame timestamps

    - there are two frames missing when using 2 b-frames (might
    be an encoder issue, as when i use exactly the same input
    with other encoders i get the correct output framenumber),
    which is the cause for the duration not matching the input

    - a wrong, not existing h.264 profile/level gets signalled:
    ObjectTypeIndication 0x21, which seems to be a mpeg-4
    part2 profile/level

    - the creation/modification time is always set to jan 1 1970

    when muxing from raw avc stream:
    - the mandatory and very important avcC atom is missing

    - the mandatory stss atom is missing, which carries the
    keyframe positions

    - the mandatory ctts atom is missing when using b-frames,
    which shows the frame timestamps

    - a wrong, not existing h.264 profile/level gets signalled:
    ObjectTypeIndication 0x21, which seems to be a mpeg-4
    part2 profile/level

    - the creation/modification time is always set to jan 1 1970

     
  • Logged In: YES
    user_id=282150

    please open a new bug for the h.264 related issues

     
  • bond
    bond
    2005-07-11

    Logged In: YES
    user_id=786427

    well if you look at the problems you see that they are very
    similar or better said the same most of the time for both part2
    and part10 video, so i assume most things can be fixed for
    both formats at one time

     
  • Logged In: YES
    user_id=282150

    ok, but why dont you fix the mp4 muxer and send us a patch?
    you seem to understand the details of mpeg4/h264 in mp4
    quite well ...

     
  • bond
    bond
    2005-07-11

    Logged In: YES
    user_id=786427

    i would if i would know how to code ;)

     
  • bond
    bond
    2006-02-04

    Logged In: YES
    user_id=786427

    the current situation with mpeg-4 asp:
    most issues are the same in most cases

    -------------------------------------

    when encoding with libavcodec mpeg-4:
    - the mandatory ctts atom is missing when using b-frames,
    which shows the frame display timestamps
    (stss atom is there)

    - there seems to be a GOV header placed together with every
    keyframe which afaik isnt allowed, as the headers and the
    plain video must be stored seperately from each other
    (the VOL, VOSH aso seems to be seperated already from the
    video data correctly)

    - in esds.decConfigDescr.avgBitrate the bitrate is always
    set to zero, altough ffmpeg is already able to calculate
    the bitrate, as it displays a bitrate after the muxing
    process.
    the average bitrate used on the stream should be stored
    there (maxbitrate seems to be set to the bitrate defined by
    the user atm)

    - the mandatory, but not that important, IODS atom is
    missing

    - the creation/modification time is always set to jan 1
    1970 (not that important)

    -------------------------------

    when encoding with xvid mpeg-4:
    - the mandatory ctts atom is missing when using b-frames,
    which shows the frame display timestamps
    (stss atom is there)

    - in esds.decConfigDescr.avgBitrate the bitrate is always
    set to zero, altough ffmpeg is already able to calculate
    the bitrate, as it displays a bitrate after the muxing
    process.
    the average bitrate used on the stream should be stored
    there (maxbitrate seems to be set to the bitrate defined by
    the user atm)

    - there are two frames missing when using 2 b-frames, when
    using 1 b-frame 1 frame is missing, when not using b-frames
    no frames are missing...

    - the mandatory, but not that important, IODS atom is
    missing

    - the creation/modification time is always set to jan 1
    1970 (not that important)

    ---------------------------------

    when muxing from raw asp streams:
    - the mandatory ctts atom is missing when using b-frames,
    which shows the frame display timestamps
    (stss atom is there)

    - there seems to be a GOV header placed together with every
    keyframe in the mp4 if the raw m4v stream also has this
    combination (as produced by libavcodec) which afaik isnt
    allowed, as the headers and the plain video must be stored
    seperately from each other
    (the VOL, VOSH aso seems to be seperated already from the
    video data correctly - tested with raw libav and xvid
    streams which have these combinations)

    - in esds.decConfigDescr.maxBitrate/avgBitrate the bitrate
    is always set to zero, altough ffmpeg is already able to
    calculate the bitrate, as it displays a bitrate after the
    muxing process

    - the mandatory, but not that important, IODS atom is
    missing

    - the creation/modification time is always set to jan 1
    1970 (not that important)

    - when importing a raw xvid/divx stream that was once
    packed in avi there are two things which need to be removed
    but ffmpeg doesnt:
    1) the dummy n-vops caused by packed bitstream, which
    causes the output stream to have more frames than the input
    2) the "DivX503b1393p" userdata signalling packed bitstream
    or at least remove the "p" (which some decoders use for
    detecting packed) packed bitstream isnt allowed in mp4

    ---------------------------------

    when muxing from avi asp streams:
    - when muxing from .avi, mpeg-4 part 2 video streams dont
    get signalled as "mp4v" as defined in the standard but with
    their avi fourcc in the STSD atom (tested with xvid and
    libav)
    therefore also the decConfigDescr aso is wrong and the file
    totally unuseable

    - the mandatory ctts atom is missing when using b-frames,
    which shows the frame display timestamps
    (stss atom is there)

    - ffmpeg doesnt unpack packed bitstream avi files (packed
    bitstream isnt allowed in mp4). ffmpeg has to do three
    things in this case:
    1) unpack the two packed frames and store them seperately
    2) remove the dummy placeholder n-vops caused by packed
    bitstream
    3) remove the "DivX503b1393p" userdata signalling packed
    bitstream or at least remove the "p" (which some decoders
    use for detecting packed)

    - the mandatory, but not that important, IODS atom is
    missing

    - the creation/modification time is always set to jan 1
    1970 (not that important)

     
  • bond
    bond
    2006-02-04

    Logged In: YES
    user_id=786427

    to make it short, the remaining important open issues with
    asp are:
    - ctts atom creation with b-frames
    - stripping of gov from movie data

    - importing from avi issues (fourcc, packed bistream)

     
    • status: open --> closed-fixed
     
  • Logged In: YES
    user_id=282150

    ok lets see, there are many issues which have been mentioned
    in this bugreport, if some are left please open new and
    SEPERATE reports for each or ill just close-invalid then

    ctts: fixed
    VOL: fixed
    packed bitstream: this isnt valid mpeg4 in mov nor avi, and
    there is a seperate feature request for it
    GOV: please quote the spec which says its not allowed

     
  • bond
    bond
    2006-03-02

    Logged In: YES
    user_id=786427

    most of the here mentioned issues are definitely not fixed
    (stss, avcc and many others...)

    about the ones you mentioned:
    i have tested the new ctts code and its definitely not
    working (correctly) in all cases
    also the vol stripping is not done in all cases where its
    needed

    also i dont really want to waste my time for starting
    spereate bug reports for issues that mostly belong to one
    thing: the mp4 muxer
    also noticing that noone seems to care about those bug
    reports anyways

    that said i am in contact with baptiste coudurier (who
    wrote the ctts patch) helping him where i can to clean the
    current mov/mp4 muxing mess up
    simply closing that bug report wont make the issues go
    away...

     
  • Logged In: YES
    user_id=282150

    * 1 issue 1 report, bugreports are intended to simplify our
    work not to be a scratchpad for you to dump all bugs you
    know for component x, if you disagree you are free to fork
    and then try to deal with 10 unrelated bugs spread over
    various comments in a report

    * if you know of an issue with ctts, report it in a way
    which can be reporduced not (it doesnt work in some cases),
    same for VOLs

    * you are not wasting your time if you write clean seperate
    and reproduceable bugreports

    * closing this fixes the issue in the original report and
    several parts mentioned in comments, the remainder doesnt
    belong in this report