After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 348031 - rtpdepay does not add framerate capability
rtpdepay does not add framerate capability
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-libav
0.10.3
Other All
: Normal normal
: 0.10.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-07-19 16:57 UTC by Dan Fruehauf
Modified: 2006-07-19 17:13 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dan Fruehauf 2006-07-19 16:57:23 UTC
Please describe the problem:
rtpdepay as being a demux must set the framerate capability so other decoders and such coming after it can enable it. AFAIK - any other demux will set the framerate correctly.
The implications are ofcourse wider - like dropped frames and bad guessing of frame rate like ffdec_mpeg would do.

Steps to reproduce:
1. try running the following chain in front of an rtsp connection :
gst-launch -v rtspsrc location=rtsp://RTSP_URL ! rtpmp4vdepay ! ffdec_mpeg4 ! sdlvideosink
2. All frames will be dropped by sdlvideosink, except for frames marked as 'emergency' by base sink - those frames would be accepted and displayed because there's no other choice.



Actual results:
sdlvideosink would drop all frames because the default jitter is perhaps too small (but reasonable) and because the frames are late - ffdec_mpeg will try to guess an arbitrary framerate.

try adding also 'videorate' after decoding - which would yield no frames at all :
gst-launch -v rtspsrc location=rtsp://RTSP_URL ! rtpmp4vdepay ! ffdec_mpeg4 ! videorate ! sdlvideosink

Expected results:
Expected results are for the timestamps, duration and framerate to be set correctly by the rtpdepay family of plugins.

Does this happen every time?
Yes.

Other information:
Comment 1 Wim Taymans 2006-07-19 17:13:03 UTC
ffmpeg was not using incomming timestamps when the framerate was not set. This is of course completely wrong. The framerate is just a hint to calculate the duration and/or interpolate timestamps in case this information is not in the video data. Tested that above pipelines work fine now.

        * ext/ffmpeg/gstffmpegdec.c: (gst_ffmpegdec_lowres_get_type),
        (gst_ffmpegdec_skipframe_get_type), (gst_ffmpegdec_class_init),
        (gst_ffmpegdec_init), (gst_ffmpegdec_open),
        (gst_ffmpegdec_setcaps), (gst_ffmpegdec_negotiate),
        (gst_ffmpegdec_do_qos), (clip_video_buffer), (check_keyframe),
        (get_output_buffer), (gst_ffmpegdec_video_frame),
        (gst_ffmpegdec_frame), (gst_ffmpegdec_sink_event),
        (gst_ffmpegdec_chain):
        Make some enums const.
        Cleanups, refactoring.
        Better video frame clipping.
        Timestamp fixe: use timestamp from incomming buffer even if there
        is no input framerate given (as this is totally unrelated).