Defaulting to 25fps is not a good idea, better don't have any framerate at all in those cases.

...and why is it not a good idea as most content would be at either 25 fps or 30 fps...please explain.  With no framerate the video is essentially at 1 fps (extreme slow motion). Please elaborate as to why it is not a good idea.

...also, the ffdec_mpeg4 plugin defaults to 25 fps if the framerate cannot be ascertained...is it then in error?

Yes, most content would be 25fps, 24fps, 30fps or 29.97fps. The problem is, that playback of all fps different than the one you've chosen will be still broken.

Does the MPEG4 spec say something about a default framerate if none is given? If not I'd say that we shouldn't assume a default because it will almost always be wrong.

30 fps content plays back fine at 25 fps with mpeg4videoparse and the Fluendo MPEG4 Codec with the fix from a Linksys WVC200 PTZ Camera.  I will look at the MPEG4 specification.  However, why then does the ffdec_mpeg4 GStreamer element default to 25 fps?  Since most content is 25->30 fps then fallback to 25 fps and print an WARN indicating that no framerate can be ascertained and that a default of 25 fps is being assumed.  Better yet, maybe a parameter to allow one to force the framerate.  ;-)  Whatever the outcome, I thank you for your prompt response to my submission...

It is possible to have MPEG-4 part 2 streams that have *no* timing information.

More likely, in this case, the decoder is ignoring the internal timestamping information in the stream.  Many low-end cameras do this instead of capturing at a constant frame rate.

David, so let's close this as NOTABUG? Or is there anything we can do better here?

We use the Fluendo Codec Pack and GStreamer in our media ports.  I have filed a bug report with Fluendo.  However, it would be a nice enhancement to mpeg4videoparse for one to be able to specify frame rate via a parameter.  I believe mplayer and vlc have such a parameter.  When I opened this as a bug I should have opened it as an "enhancement" as it clearly is not a bug.  I am all for closing this, but please give the frame rate parameter some consideration.

This is basically the same situation as in bug #587799, except that is MPEG4 here in stead of h264.  The 'remedy/trick' given there using existing components (capsfilter, stamp) works just as well here (and as such does not really need some custom framerate "parameter").

Mark:

This works well, however, I use Totem for playback and I believe that it uses playbin or playbin2.  So, how would the "stamp" element come into play in this case?

Best Regards,

Rob Krakora

Mark:

Also, how much more *overhead* does the "stamp" element add to the pipeline in regards to CPU usage?  ;-)

Best Regards,

Rob Krakora

In gstffmpegdec.c the following code is present...

  if (!ffmpegdec->context->time_base.den || !ffmpegdec->context->time_base.num) {
    GST_DEBUG_OBJECT (ffmpegdec, "forcing 25/1 framerate");
    ffmpegdec->context->time_base.num = 1;
    ffmpegdec->context->time_base.den = 25;
  }

...should it not be removed?

gstffmpegdec.c history...

https://bugzilla.gnome.org/show_bug.cgi?id=313970

In mpeg4videodec.c in gst-ffmpeg-0.10.11 the following code is present:

    if (get_bits1(gb) != 0) {   /* fixed_vop_rate  */
        s->avctx->time_base.num = get_bits(gb, s->time_increment_bits);
    }else
        s->avctx->time_base.num = 1;

In mpeg4videoparse.c the following code is present:

  GET_BITS (&bs, 1, &bits);
  if (bits) {
    /* fixed time increment */
    int n;

    /* Length of the time increment is the minimal number of bits needed to
     * represent time_increment_resolution */
    for (n = 0; (time_increment_resolution >> n) != 0; n++);
    GET_BITS (&bs, n, &bits);

    fixed_time_increment = bits;
  } else {
    /* When fixed_vop_rate is not set we can't guess any framerate */
    fixed_time_increment = 0;
  }

If I change fixed_time_increment = 1 insteade of fixed_time_increment = 0 in the mpeg4videoparse.c code above with no other changes then the video stream with which I am having problems plays just fine with the Fluendo MPEG4 video codec.

Any more comments/suggestions?

Not really, randomly choosing 25 fps is not going to improve the situation much, you could as well choose 23.4567 fps or any other random value.

To be able to play back mpeg4 streams without any timing information at all you have to place them in a container format that contains the timing information and mpeg4videoparse will passthrough this timing information.

So IMHO we should just close this bug and keep everything as is. mpeg4 video streams without any timing information anywhere are pretty useless and shouldn't be produced by anything.

Hi Sebastian,

Fluendo has since added MPEG4 parsing to their MPEG4 Part 2 codec and this is no longer an issue for me.  I totally agree with your comments.  This bug report can be closed.

Best Regards,

Rob Krakora