[FFmpeg-devel] [PATCH 1/3] ffplay: reimplement early frame drop

[Michael Niedermayer]

On Tue, Oct 25, 2011 at 12:58:41AM +0200, Marton Balint wrote:
> 
> On Mon, 24 Oct 2011, Michael Niedermayer wrote:
> 
> >On Mon, Oct 24, 2011 at 11:17:13PM +0200, Marton Balint wrote:
> >>
> >>On Sat, 22 Oct 2011, Michael Niedermayer wrote:
> >>
> >>>On Fri, Oct 21, 2011 at 11:33:21PM +0200, Marton Balint wrote:
> >>>>This patch reimplements early frame drop, it is now based on the current
> >>>>difference between the master clock and the video clock, and the pts of the
> >>>>current and the last displayed (or skipped) frame.  If the frame to be added to
> >>>>the queue is late after decoding, then we drop it early because later we would
> >>>>drop it anyway (unless it is the only frame in the picture queue).
> >>>>
> >>>>The current approach has only one downside that I know of, it does not handle
> >>>>well when the filters are changing significantly the pts of the frames, because
> >>>>we compare pts values from filtered and unfiltered frames.
> >>>>
> >>>>We also start using the pictq_mutex to ensure consistent video_current_pts,
> >>>>video_current_pts_drift, frame_last_pts, frame_last_dropped_pts and
> >>>>frame_last_dropped_pos values.
> >>>
> >>>the patches work fine, thanks for looking into this
> >>>
> >>
> >>Great, I pushed the patches to my stable branch.
> >
> >are they ready to be pulled or should i wait ?
> >
> 
> They are ready, pull please.

pulled, thanks

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20111025/53623771/attachment.asc>