[vlc-devel] Update on the remaining timing issue

[Juha Jeronen]

Hi all,

First, a brief recap of what this is about: for some reason, there
seemed to be a slight difference in timing, which was causing framerate
doublers to run less smoothly in HEAD than they did in January (3f50c72...).

Testing with [d304fd2ecdcf6fac6d79cfcc735123ae15d64142] (today's HEAD),
streams without repeat_pict seem to work fine now. They work also from
DVD images, with subtitles enabled. There is the occasional late frame
that gets dropped (causing a glitch, unpredictably), but this is fair
enough - I guess it's just saying that I need a real computer for
running VLC with a framerate doubler, instead of a netbook :P

Streams with repeat_pict are a different story, but it seems this is not
anything introduced by changes to the video output, as I first
suspected. Instead, it's caused by the 16ms/66ms issue I mentioned
earlier - which has not changed.

To recap this part: instead of a steady stream of 33ms (2 fields at 60i)
or 50ms (3 fields) frame durations, if any pict_repeats are present in
the stream, some frames get durations of 16ms or 66ms (seen by logging
the PTS diffs from a history-enabled deinterlacer). This does not match
i_nb_fields*field_duration, which causes the framerate doubler to
glitch. These glitches occur predictably, always at the same stream
position.

Sure enough, applying my questionable PTS hack* made the problem go away
this time, too :)

* Patch 0001 in
http://mailman.videolan.org/pipermail/vlc-devel/2011-January/078463.html


Thus, the conclusion is that the commit ecc645ccce... correctly fixes
the original stutter bug that was introduced by 8f85c827...

I suspect I might have screwed up while testing earlier, and a) tested
only with streams with no repeat_pict, or b) tested with a local
development version including the PTS hack. Either option would explain
why (the version I thought was) 3f50c72... ran smoothly.


What remains is the mystery why repeat_pict sometimes causes the PTSs to
be incorrect. I sent some short samples to Laurent a while back, and
about one of them (which came from the anime Angel Links), he said in an
email that the PTSs in the stream itself do not make sense.

I've now seen this issue in Angel Links and Stellvia, both of which
utilize soft telecine, and in Silent Mobius, which only uses field
repeats to save space on the DVD.

Possible explanations that come to mind are:

a) Any NTSC anime utilizing repeat_pict is simply authored incorrectly, or

b) Something goes wrong in the decoder.

Option b) sounds more likely. I think we need this working for proper
DVD anime support, because, although not as common as a hard telecine
(which is taken care of by IVTC), it seems that the occasional show uses
repeat_pict.

I'm interested in fixing the problem if my skillz are up to it. I tried
to understand the relevant parts back in January, but couldn't then come
up with a better solution than the ad hoc PTS hack, which just sweeps
the problem under the proverbial carpet. Maybe I should try again,
unless someone else wants to ;)

 -J


P.S. In the original message (included below for convenience), I meant
of course [8f85c827640f78e4b5bdc8e83c733ff62c624b7b] and not
81f8f88d654bc5..., which had nothing to do with this. Well, both begin
with an 8 :)


-------- Original Message --------
Subject: 	Slight timing regression, still
Date: 	Wed, 16 Mar 2011 23:48:35 +0200
From: 	Juha Jeronen <juha.jeronen at jyu.fi>
To: 	Mailing list for VLC media player developers <vlc-devel at videolan.org>



Hi all,

After the ecc645ccce... bugfix, I'm still seeing slightly more uneven
timing when compared to 3f50c72... from January.

Consequently, Phosphor (and also Bob) doesn't work as well as it used
to. Instead of glitching a few times per hour as before (which I suspect
might be due to the clock source), I'm now getting a few glitches per
minute. My observations so far are that it doesn't always occur at the
same position in the stream, and it occurs more often for DVD images
than "pure" video files (e.g. extracted test clips).

I suspect the problem is probably due to some other change in
81f8f88d654bc5... that wasn't undone by ecc645ccce..., but I'm not
certain about that. In any case, it's caused by something between
3f50c72... and ecc645ccce...

I will try to track it down. This requires a git bisect with a re-apply
of Phosphor at every step (for testing), and additionally a re-apply of
the diff from ecc645ccce... for every step that is 81f8f88... or later
(to rule out the bug introduced in 81f8f88... and fixed in ecc645ccce...).

I'm planning to have the time to do this either tomorrow, or early next
week. I'll post the results when I'm done.

 -J


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20110406/6b1b4389/attachment.html>