[Bug 723352] codecparsers_h264: Framerate estimation enhancement

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=723352
  GStreamer | gst-plugins-bad | git

Aurélien Zanelli <aurelien.zanelli> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #267713|0                           |1
        is obsolete|                            |

--- Comment #2 from Aurélien Zanelli <aurelien.zanelli at parrot.com> 2014-04-11 12:44:41 UTC ---
Created an attachment (id=274089)
 View: https://bugzilla.gnome.org/attachment.cgi?id=274089
 Review: https://bugzilla.gnome.org/review?bug=723352&attachment=274089

H264 framerate estimatio proof of concept

I updated proof of concept, it apply on master and it only show framerate
calculation because, at this moment, I am not really sure how to add it to
current parser since we need SPS, Pic timing (if present) and slice header.
Hence I think it's better to have your point of view before going further.

For now, I propose to remove current framerate calculation from
gst_h264_parse_sps_data() (codecparser_h264). By doing this, we will only have
the framerate in h264parse element after parsing a slice header.
As a consequence, we will have to update caps each time we parse a slice header
if framerate changed.
Moreover, if we have frame_mbs_only flag equal to 0, we can have in the same
sequence both frame and field (ie field_pic_flag equal to 0 and 1). So I am a
little worried about instantaneous framerate changes.
Also I noticed that we can have some issue when h264parse will be set to
passthrough mode.

Another way could be to make the method to estimate the framerate public and
let the user choose when to update framerate.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.