[patch] player slider show incorrect values (livetv)

[Jiri Fojtasek <jiri.fojtasek@…>]

Use framesplayed instead of pts to compute seconds played. This fixing incorrect or stalling time in osd playback slider during livetv DVB playback. The patch also removing portion of unused code (fixme, but it is not used anywhere else).

Jiri

[Jiri Fojtasek <jiri.fojtasek@…>]

the patch

[tralph]

Jiri, are you saying that the display time is correct for pre-recorded but not when using LiveTV?

[Jiri Fojtasek <jiri.fojtasek@…>]

Pre recorded is OK, watching livetv show correct until first program switch to another, and it remain broken until i restart livetv. Sometime it stop counting. I tracked it to pts normalization in avformat decoder. It is not adjusted when jump to program/ switch to program ocur. It show normalized pts from start of the livetv playback. Instead of adding lots of code to normalize pts when decoder is switching is imho better use frames played and wipe out useless code. Also normalized time from decoder does not show actual time where the playback are because it show value from last decoded frame added to the video queue.

Jiri

[tralph]

Jiri, there is a *very* good reason that we use PTS for the display time since it properly handles variable frame rate and frame repeats properly. Using a frame count is not accurate in many situations and I will not revert back to using such a flawed method. If pre-recorded works properly then your patch is not the best solution to this problem. So what's wrong with "pts normalization in avformat decoder."?

[Jiri Fojtasek <jiri.fojtasek@…>]

Replying to tralph:

Jiri, there is a *very* good reason that we use PTS for the display time since it properly handles variable frame rate and frame repeats properly. Using a frame count is not accurate in many situations and I will not revert back to using such a flawed method. If pre-recorded works properly then your patch is not the best solution to this problem. So what's wrong with "pts normalization in avformat decoder."?

In case of variable framerate you are right(i asked for fixme). So the solution will be reset decoder time base when switching/jumping to next program in livetv chain. Here is what exactly happen:

Program 1 length 5 minutes secondsplayed counting from 0 to 300 slider show secondsplayed/playbacklen (all is OK)

switchtoprogram()

Program 2 length 10 minutes secondsplayed counting from 300 to 900 slider show only playbacklen/playbacklen (wrong)

switchtoprogram()

Program 3 length 10 minutes secondsplayed counting from 901 to 1500 slider show only playbacklen/playbacklen (wrong)

When i hit pause slider still counting playbacklen/playbacklen

When i jump back to Program 2 slider stop and show only playbacklen/playbacklen of Program 2

Conclusion, since frames played is not usefull as time base, we need adjust time base to count from zero during jumptoprogram/switchtoprogram. Ill rework the patch to adjust disp_timecode to program playback boundaries.

Jiri

[tralph]

Jiri, what is the ic->start_time and ic->first_dts for each segment?

[Jiri Fojtasek <jiri.fojtasek@…>]

I added new verbose after disp_timecode calculation. Its still the same until i restart livetv:

2011-02-01 23:31:24.286 AFD: video timecode 3205421403 35615793 35615753
2011-02-01 23:31:24.286 AFD: ic->start_time=35234563100 stream->first_dts=3171149403 picframe->disp_timecode=380436
2011-02-01 23:31:24.395 AFD: video timecode 3205425003 35615833 35615793
2011-02-01 23:31:24.395 AFD: ic->start_time=35234563100 stream->first_dts=3171149403 picframe->disp_timecode=380436
2011-02-01 23:31:24.403 AFD: video timecode 3205428603 35615873 35615833
2011-02-01 23:31:24.404 AFD: ic->start_time=35234563100 stream->first_dts=3171149403 picframe->disp_timecode=380436
2011-02-01 23:31:24.414 AFD: video timecode 3205432203 35615913 35615873
2011-02-01 23:31:24.414 AFD: ic->start_time=35234563100 stream->first_dts=3171149403 picframe->disp_timecode=380436
2011-02-01 23:31:24.537 AFD: video timecode 3205435803 35615953 35615913
2011-02-01 23:31:24.537 AFD: ic->start_time=35234563100 stream->first_dts=3171149403 picframe->disp_timecode=380436
2011-02-01 23:31:24.549 AFD: video timecode 3205439403 35615993 35615953
2011-02-01 23:31:24.549 AFD: ic->start_time=35234563100 stream->first_dts=3171149403 picframe->disp_timecode=380436
2011-02-01 23:31:24.679 AFD: video timecode 3205443003 35616033 35615993
2011-02-01 23:31:24.679 AFD: ic->start_time=35234563100 stream->first_dts=3171149403 picframe->disp_timecode=381436
2011-02-01 23:31:24.683 AFD: video timecode 3205446603 35616073 35616033
2011-02-01 23:31:24.683 AFD: ic->start_time=35234563100 stream->first_dts=3171149403 picframe->disp_timecode=381436
2011-02-01 23:31:24.700 AFD: video timecode 3205450203 35616113 35616073
2011-02-01 23:31:24.700 AFD: ic->start_time=35234563100 stream->first_dts=3171149403 picframe->disp_timecode=381436
2011-02-01 23:31:24.706 AFD: video timecode 3205453803 35616153 35616113
2011-02-01 23:31:24.706 AFD: ic->start_time=35234563100 stream->first_dts=3171149403 picframe->disp_timecode=381436
2011-02-01 23:31:24.744 AFD: video timecode 3205457403 35616193 35616153
2011-02-01 23:31:24.744 AFD: ic->start_time=35234563100 stream->first_dts=3171149403 picframe->disp_timecode=381436
2011-02-01 23:31:24.762 AFD: video timecode 3205461003 35616233 35616193
2011-02-01 23:31:24.763 AFD: ic->start_time=35234563100 stream->first_dts=3171149403 picframe->disp_timecode=381436

[tralph]

Jiri, is that the same for all segments of the LiveTV chain? The log you provide looks like a very brief snapshot of a single segment.

[Jiri Fojtasek <jiri.fojtasek@…>]

Replying to tralph:

Jiri, is that the same for all segments of the LiveTV chain? The log you provide looks like a very brief snapshot of a single segment.

Yes, its for every segment the same. I run it about 10 minutes with 1 minute program resolution (10 segments), picframe->disp_timecode is increased every second +1000

[tralph]

Jiri, could you please add debug to NormalizeVideoTimecode? and include output for st->time_base.den, st->time_base.num, timecode, start_ts, ts and the return value? We should be seeing a different picframe->disp_timecode for every frame. I see the video timecode changing and need to understand why disp_timecode doesn't.

[tralph]

Jiri, the only reason I can think that start_time and first_dts would stay the same is if probing failed in avformatdecoder's OpenFile?. You could try increasing the testreadsize in mythplayer OpenFile? to see if it helps.

[tralph]

Jiri, I've identified the problem but going to think some more about the best fix. In the meantime you can force newtype = true in JumpToProgram/SwitchToProgram? in mythplayer.cpp. That will force each segment to get reprobed via OpenFile? and obtain the correct context information such as start_time.

[Jiri Fojtasek <jiri.fojtasek@…>]

Ill try all tips and debuging ...

As i understand, decoder timebase must reset on demand in ffmpeg context when new stream come in to the decoder ? Is it based on a header from begining of next mpeg file ?

[tralph]

fixed in 13722d797407ba130ff106bf27bb52bd5eca95de.

[Taylor Ralph]

Force reload of context and stream properties when switching between LiveTV segments.

When transitioning between LiveTV segments it is not safe to assume that the next segment has the same AVFormatContext and AVStream properties as the previous segment.

Fixes #9542.

Changeset: 13722d797407ba130ff106bf27bb52bd5eca95de

[danielk]

[13722d797] was reverted because it causes stuttering with all video formats and poor video quality after a transition with H.264. To track the pts time within a program we should be setting a start_pts time after every file transition (both when we skip forward or backward to a different ringbuffer. This value doesn't necessarily need to be in the context itself, it just needs to be what we refer to in calculating the time.

[tralph]

I've already removed the code that caused the reported issue so this ticket is no longer relevant.