<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi all,<br>
<br>
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...).<br>
<br>
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<br>
<br>
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.<br>
<br>
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.<br>
<br>
Sure enough, applying my questionable PTS hack* made the problem go
away this time, too :)<br>
<br>
* Patch 0001 in<br>
<a class="moz-txt-link-freetext" href="http://mailman.videolan.org/pipermail/vlc-devel/2011-January/078463.html">http://mailman.videolan.org/pipermail/vlc-devel/2011-January/078463.html</a><br>
<br>
<br>
Thus, the conclusion is that the commit ecc645ccce... correctly
fixes the original stutter bug that was introduced by 8f85c827...<br>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
Possible explanations that come to mind are:<br>
<br>
a) Any NTSC anime utilizing repeat_pict is simply authored
incorrectly, or<br>
<br>
b) Something goes wrong in the decoder.<br>
<br>
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.<br>
<br>
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 ;)<br>
<br>
-J<br>
<br>
<br>
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 :)<br>
<br>
<br>
-------- Original Message --------
<table class="moz-email-headers-table" border="0" cellpadding="0"
cellspacing="0">
<tbody>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">Subject: </th>
<td>Slight timing regression, still</td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">Date: </th>
<td>Wed, 16 Mar 2011 23:48:35 +0200</td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">From: </th>
<td>Juha Jeronen <a class="moz-txt-link-rfc2396E" href="mailto:juha.jeronen@jyu.fi"><juha.jeronen@jyu.fi></a></td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">To: </th>
<td>Mailing list for VLC media player developers
<a class="moz-txt-link-rfc2396E" href="mailto:vlc-devel@videolan.org"><vlc-devel@videolan.org></a></td>
</tr>
</tbody>
</table>
<br>
<br>
<pre>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
</pre>
</body>
</html>