[vlc-devel] Soft field repeat?

[Juha Jeronen]

Hi all,

Update post.

I did some testing. It's exactly as I thought - Sol Bianca is 
occasionally requesting a field repeat, which requires the field 
dominance flip to match.

And the Angel Links and Silent Mobius OPs are a monstrosity. Both are 
partly soft-telecined and partly not, switching back and forth. Some of 
the frames in Angel Links look hard-telecined.

Silent Mobius requests the occasional lone field repeat while running 
true interlaced, and may switch to soft-telecined and back within just a 
few frames. I'd say the only way to render that one correctly is to use 
a field renderer.

For debugging, I added the following logging call to RenderIVTC() (just 
before cadence detection - doesn't really matter where and into which 
deinterlacer this goes, as it only prints out unmangled data from the 
input frames):

---8<---8<---8<---

     if( p_curr )
         msg_Dbg( p_filter, "FD %s, fields %d, duration = %dus", 
(p_curr->b_top_field_first ? "T" : "B"), p_curr->i_nb_fields, 
p_next->date - p_curr->date );
     else
         msg_Dbg( p_filter, "Next: FD %s, fields %d", 
(p_next->b_top_field_first ? "T" : "B"), p_next->i_nb_fields );

---8<---8<---8<---

Here's what I got from Angel Links OP:

---8<---8<---8<---

[0xa32238c] deinterlace filter debug: FD T, fields 2, duration = 33366us
[0xa32238c] deinterlace filter debug: FD T, fields 2, duration = 33366us
[0xa32238c] deinterlace filter debug: FD T, fields 2, duration = 33366us
[0xa32238c] deinterlace filter debug: FD T, fields 2, duration = 33366us
[0xa32238c] deinterlace filter debug: FD T, fields 2, duration = 33372us
[0xa32238c] deinterlace filter debug: FD T, fields 2, duration = 33366us
[0xa32238c] deinterlace filter debug: FD T, fields 2, duration = 33368us

---[snip]---

[0xa32238c] deinterlace filter debug: FD T, fields 2, duration = 50049us
[0xa32238c] deinterlace filter debug: FD T, fields 2, duration = 33366us
[0xa32238c] deinterlace filter debug: FD T, fields 2, duration = 33366us
[0xa32238c] deinterlace filter debug: FD T, fields 3, duration = 16689us
[0xa32238c] deinterlace filter debug: FD B, fields 2, duration = 33366us
[0xa32238c] deinterlace filter debug: FD B, fields 3, duration = 66735us
[0xa32238c] deinterlace filter debug: FD T, fields 2, duration = 50049us
[0xa32238c] deinterlace filter debug: FD T, fields 3, duration = 50049us
[0xa32238c] deinterlace filter debug: FD B, fields 2, duration = 33366us
[0xa32238c] deinterlace filter debug: FD B, fields 3, duration = 33366us
[0xa32238c] deinterlace filter debug: FD T, fields 2, duration = 33366us
[0xa32238c] deinterlace filter debug: FD T, fields 3, duration = 50050us
[0xa32238c] deinterlace filter debug: FD B, fields 2, duration = 50047us
[0xa32238c] deinterlace filter debug: FD B, fields 3, duration = 50049us
[0xa32238c] deinterlace filter debug: FD T, fields 2, duration = 16691us
[0xa32238c] deinterlace filter debug: FD T, fields 3, duration = 33366us
[0xa32238c] deinterlace filter debug: FD B, fields 2, duration = 33366us
[0xa32238c] deinterlace filter debug: FD B, fields 3, duration = 50050us
[0xa32238c] deinterlace filter debug: FD T, fields 2, duration = 50051us
[0xa32238c] deinterlace filter debug: FD T, fields 2, duration = 33366us

---8<---8<---8<---

Initially, it's the usual kind of stream with constant FD and no field 
repeats, but after a few seconds it switches to requesting a soft telecine.

The thing that doesn't make sense here are the ~17000us and ~67000us, 
corresponding to 1 and 4 fields. At 59.94, 2 fields should always be 
33366us and 3 fields 50050us.

Indeed, logging the increment computed by the PTS interpolator in 
DecodeVideo() (in modules/codec/avcodec/video.c) confirms that this is 
the case.

But logging the actually realized PTS diffs from the same place agrees 
with the nonsensical results that are also seen by the deinterlacer. So 
it seems something is going wrong there.

The problem occurs only for streams containing field repeats - for the 
usual kind of stream with always 2 fields per frame, the actually 
realized PTS diffs stay steady at ~33000us as expected.

Because the actual diffs are determined by adding the computed increment 
to p_sys->i_pts, the timestamp stored there must be occasionally 
incorrect - by exactly one field in either direction.

So far I have no idea what could cause that. I guess I'll keep looking, 
unless someone else already has an idea ;)

  -J