noreply at mythtv
Jan 9, 2013, 1:38 PM
Post #6 of 9
(53 views)
Permalink
|
|
Re: Ticket #10833: DVB-T radio programs time display and cutlist problems
[In reply to]
|
|
#10833: DVB-T radio programs time display and cutlist problems
------------------------------------------------+--------------------------
Reporter: John Veness <John.Veness.mythtv@…> | Owner:
Type: Bug Report - General | Status: new
Priority: minor | Milestone: unknown
Component: MythTV - General | Version:
Severity: medium | 0.25-fixes
Keywords: | Resolution:
| Ticket locked: 0
------------------------------------------------+--------------------------
Comment (by Roger Siddons <dizygotheca@…>):
Joe's issue (to which John also alludes) is a separate problem; that
skipping/jumping in radio is very unresponsive. Single skip/jumps can take
1/3 - 1 sec, but a series of consecutive jumps can take up to 7 secs.
Frequently the OSD is not displayed (because the display request times
out). This is markedly slower than skipping in a TV programme.
The problem is a consequence of
http://code.mythtv.org/trac/changeset/d207a0bddddac4cb015746e2a4b4e5f841897c8c/mythtv,
which limits the ringbuffer block size for low bitrates.
UK DVB-T Radio is often 192 Kbs (ie. BBC 3/4) with significant DSMCC_B
data (reporting a bitrate of 0). The above change limits the ringbuffer to
4 Kb reads, so the decoder thread takes a long time to read a frame
(!GetFrame) and will not respond to the seek request until it has
finished.
I have attached a debug log of 26/fixes (with extra debug code) which
demonstrates the issue. The test case is a series of single skips and
jumps followed by rapid ones (2 Hz) on a 192 Kbs radio programme (BBC
Radio 4). Seek requests are marked by '''!DoPlayer''' and they are
completed by '''!ClearAfterSeek'''. This is a good proxy for the UI
responsiveness.
Sample timings (secs between request/response) for this scenario: each
column is a skip/jump attempt; rapid jumps are shown in a single cell.
||= 192 Kbs Radio (4K block) =||0.33||0.3||0.43, 3.1||0.82, 0.13,
6.16||0.12, 5.67, 7.57||2.6, 7.5, 7.5||
||= 192 Kbs Radio (32K block) =||0.3||0.34||0.3, 1.1||0.33, 0.4, 0.44,
0.14, 1.2, 1.6||0.5, 0.46, 0.44||0.3, 0.37, 0.5, 1||0.3, 0.35, 0.34, 1,
0.8||
||= TV (384K block) =||0.03||0.26||0.02, 0.09||0.09, 0.17, 0.11,
0.11||0.02, 0.06, 0.09||0.34, 0.68, 1.91||
The Radio (32K block) timings were obtained by hacking the optimisation
code to use a minimum 32K block.
Apart from the poor 4K figures, note the variability of all the times and
the progressive deterioration with multiple skips in all cases.
Interestingly, a 64 Kbs radio stream (!TalkSport) with a 2K block size
performs much better, possibly because it doesn't contain so many data
packets.
The issue is not apparent in master because of
http://code.mythtv.org/trac/changeset/98b1a775cd53aaa9dca1939d4ffa24de7f1add64/mythtv,
which overrides the reported bitrate (192 Kbs) with one derived from the
filesize (1413 Kbs), resulting in a 32K read block now being used.
The attached patch monitors seek requests whilst reading a frame. It
aborts the long read as soon as a seek is detected (the frame will be
discarded anyway). All skips/jumps now complete in less than 0.1 secs.
Presumably the latter change will not be back-ported: this patch therefore
solves the slow skip issue for 25/fixes & 26/fixes. For master this patch
just makes skip/jumps snappier, more uniform and guards against slow reads
locking the UI out.
--
Ticket URL: <http://code.mythtv.org/trac/ticket/10833#comment:5>
MythTV <http://code.mythtv.org/trac>
MythTV Media Center
_______________________________________________
mythtv-commits mailing list
mythtv-commits [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-commits
|
