Improve closed caption performance

[Jim Stichnoth]

High CPU usage when displaying "real-time" character-by-character CEA-708 captions, with "-v vbi", on an Atom frontend, resulting in stuttering. May also be true for CEA-608 captions. Unacceptable.

[Jack Thomasson <jkt@…>]

In 30f6e33cc25191a8b57492cdc1868845eaa713d8/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available

[Jim Stichnoth]

A fundamental issue here is that the amount of work to render one subtitle can vary wildly, depending on the number of differently-formatted chunks in the subtitle, and the complexity of formatting in osd_subtitle.xml. For the latter, larger fonts, shadows, and outlines make rendering more expensive.

Since there are always many video frames between different subtitles, the processing time for one subtitle may cause a dropped frame, even when the average per-frame overhead is small.

The best way to deal with this may be to offload as much processing as possible into a helper thread, being careful to avoid non-thread-safe MythUI work in the helper thread. Performance-tuning the single-subtitle work is also worthwhile, but probably can't be the only approach since we are largely at the mercy of the subtitle provider, the themer (osd_subtitle.xml complexity), and the user (subtitle zoom factor in the Playback OSD).

[Jim Stichnoth <jstichnoth@…>]

In 3325c09b2fc070179047f678a02ee6feaed5cfd7/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available

[Jim Stichnoth <jstichnoth@…>]

In 9380024634ce98b7c5f5d3ff08a9672f80a1217e/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available

[Jim Stichnoth <jstichnoth@…>]

In e623425dfe4ef279a6c1362ef907b3723c3a0158/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available

[Jim Stichnoth <jstichnoth@…>]

In 2c8c898f5d2f4b76f06a978a09830599dff530b5/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available

[Jim Stichnoth <jstichnoth@…>]

In 2427afde4690eeb87d3a2af28951cc8bd9d1369b/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available

[Jim Stichnoth <jstichnoth@…>]

In ce8183ca568ecb246d9ce479c09b430cd9b5d6a4/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available

[Jim Stichnoth <jstichnoth@…>]

In 6181935764d9eb330e4bb08d80435be429b314f9/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available

[Jim Stichnoth <jstichnoth@…>]

In 181ac7f15c160ed162f8932574b8c30497fae727/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available

[Jim Stichnoth <jstichnoth@…>]

In cfc3b7c8e50038d52b739077068ffa7a8f82fd56/mythtv:

Error: Processor CommitTicketReference failed

GIT backend not available

[Jim Stichnoth]

Closing this as fixed, because I can't see any more to do. Description of experiments and results follows.

Adding timing to the subtitle creation pipeline showed that the dominant stage is the painting of the text chunks, in MythPainter::DrawTextPriv(). This is invoked for a new string that is not already in the string image cache. This was sped up by 3325c09 when drawing outlines.

If MythPainter::DrawTextPriv() can't be sped up further, the next approach is to try to spread the work over multiple frames where possible, to minimize stuttering. One approach is to use a background helper thread. However, the helper thread is limited to non-MythUI work, so it's only marginally helpful in reducing the latency. Therefore the helper thread idea was abandoned.

Another approach is to pipeline the work across multiple Pulse() calls in the UI thread. A cost model can be used to throttle the amount of work done each Pulse(). The benefit is that if a subtitle includes multiple chunks, the drawing of the chunks can be spread across time. Unfortunately, this approach led to flashing and other visual artifacts on rapid "real-time" captioning, despite lots of experimentation to try to tune and synchronize the delay timing. As a result, this approach was also abandoned (especially after it didn't improve stuttering on an ION system).

One more approach was tried. It was observed that for these real-time paint-on captions, each caption is usually almost identical to the previous caption, with just 2 characters added to the bottom line. The idea is to try, if possible, to create the same set of chunks as the last caption, with one extra chunk for the (two) new characters, thereby using the string image cache as much as possible. Unfortunately, this also did not actually help in reducing the stuttering.

In the end, the only thing that reliably eliminated the stuttering was to decrease the excessive amount of VB_VBI logging output, particular for cc708 captions.