OSD does not correctly indicate progress of show, shows as being fully complete

[gaberubin@…]

Since upgrading to .25, all my recordings made under .25 apparently do not have correct seektables. The OSD shows that the program is completed at any point in the program and is full. I can seek but I have no indication where in the program I am. I have tried to rebuild the seek table, but that does not help. This problem is described here: ​http://www.gossamer-threads.com/lists/mythtv/users/514043#514043

I have made a 50 meg clip as requested here: ​http://mustbethemoney.mine.nu:8080/colbertclip.mpg and rebuilt the seek table on that, although the progress indicator shows very weird information for this clip.

[stephen.ecob@…]

I was experiencing a similar bug, but with LiveTV not with recorded shows.

The problem appeared after installing MythTV 0.25

The symptom seems the same: Skip Back and Skip Ahead both work fine but the progress indicator always shows you're at the very end of the buffer (ie what's being transmitted now)

I upgraded to the latest 0.25-fixes on June 7th 2012 and the problem has gone away - the progress indicator now works fine!

Thank you MythTV developers! :-)

[stuartm]

Reported to be fixed

[stichnot]

Reopening as there is still a problem with the sample referenced in the ticket.

I have noticed similar issues with Live TV, and they may very well have been fixed by recent changes. However, the colbertclip.mpg sample still shows a ridiculously large duration. Most likely there has been a regression in ffmpeg. Running mythffmpeg on the sample:

mythtv@mythmaster:/storage/videos/cctest$ mythffmpeg -i colbertclip.mpg
ffmpeg version git-2012-06-02-d6a4d9e Copyright (c) 2000-2012 the FFmpeg developers
  built on Jun  4 2012 05:59:00 with gcc 4.4.3
  configuration: --prefix=/usr/mythtrunk --enable-libx264 --enable-libmp3lame --compile-type=profile
  libavutil      51. 56.100 / 51. 56.100
  libavcodec     54. 23.100 / 54. 23.100
  libavformat    54.  6.101 / 54.  6.101
  libavdevice    54.  0.100 / 54.  0.100
  libavfilter     2. 77.100 /  2. 77.100
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 15.100 /  0. 15.100
  libpostproc    52.  0.100 / 52.  0.100
[mpegts @ 0x9fef3c0] PES packet size mismatch
Input #0, mpegts, from 'colbertclip.mpg':
  Duration: N/A, bitrate: N/A
    Stream #0:0[0x7c1]: Audio: ac3, 0 channels
    Stream #0:1[0x7c2]: Video: mpeg2video, 90k tbn
At least one output file must be specified

But running an older version of ffmpeg that happens to be installed:

mythtv@mythmaster:/storage/videos/cctest$ ffmpeg -i colbertclip.mpg          
ffmpeg version git-2011-12-07-d9ced9f, Copyright (c) 2000-2011 the FFmpeg developers
  built on Dec  6 2011 16:25:12 with gcc 4.4.3
  configuration: --enable-gpl --enable-libfaac --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-nonfree --enable-postproc --enable-version3 --enable-x11grab
  libavutil    51. 30. 0 / 51. 30. 0
  libavcodec   53. 41. 0 / 53. 41. 0
  libavformat  53. 24. 0 / 53. 24. 0
  libavdevice  53.  4. 0 / 53.  4. 0
  libavfilter   2. 51. 0 /  2. 51. 0
  libswscale    2.  1. 0 /  2.  1. 0
  libpostproc  51.  2. 0 / 51.  2. 0
[mpeg2video @ 0x9432160] mpeg_decode_postinit() failure
    Last message repeated 36 times
[mpegts @ 0x92dcaa0] PES packet size mismatch
 
Seems stream 3 codec frame rate differs from container frame rate: 59.94 (60000/1001) -> 59.94 (60000/1001)
Input #0, mpegts, from 'colbertclip.mpg':
  Duration: 11:52:27.02, start: 44900.580778, bitrate: 9 kb/s
  Program 1
    Stream #0:0[0x840]: Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, 5.1(side), s16, 384 kb/s
    Stream #0:1[0x842]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 24000 kb/s, 59.96 fps, 59.94 tbr, 90k tbn, 119.88 tbc
    Stream #0:2[0x7c1]: Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, stereo, s16, 384 kb/s
    Stream #0:3[0x7c2]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 24000 kb/s, 54.56 fps, 59.94 tbr, 90k tbn, 59.94 tbc
At least one output file must be specified

Initial analysis shows that AvFormatDecoder::OpenFile?() calls av_estimate_timings() which calls estimate_timings() which calls estimate_timings_from_pts(). That presumably fails because the duration ends up AV_NOPTS_VALUE, which is translated as a ridiculously large duration in the progress bar.

[stichnot]

Let's recheck the status of this after the next ffmpeg update.

[jyavenard]

I get exactly the same result with mythtv 0.25.3:

FFmpeg version git-v0.25.3-23-g0b60406, Copyright (c) 2000-2011 the FFmpeg developers
  built on Dec 11 2012 23:12:39 with gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
  configuration: --runprefix=../Resources --enable-libmp3lame --disable-lirc --disable-distcc --prefix=/Users/jyavenard/Work/mythtv/.osx-packager/build --cc=/Applications/Xcode.app/Contents/Developer/usr/bin/gcc --cxx=/Applications/Xcode.app/Contents/Developer/usr/bin/g++ --qmake=/Users/jyavenard/Work/mythtv/.osx-packager/build/bin/qmake --extra-libs=-F/Users/jyavenard/Work/mythtv/.osx-packager/build/lib --extra-cxxflags='-D IGNORE_SCHEMA_VER_MISMATCH=1 -D IGNORE_PROTO_VER_MISMATCH=1' --firewire-sdk=/Users/jyavenard/Work/mythtv/.osx-packager/build/lib --compile-type=debug
  libavutil    50. 39. 0 / 50. 39. 0
  libavcodec   52.113. 1 / 52.113. 1
  libavformat  52.101. 0 / 52.101. 0
  libavdevice  52.  2. 3 / 52.  2. 3
  libavfilter   1. 76. 0 /  1. 76. 0
  libswscale    0. 12. 0 /  0. 12. 0
  libpostproc  51.  2. 0 / 51.  2. 0

Seems stream 1 codec frame rate differs from container frame rate: inf (1/0) -> nan (0/0)
Input #0, mpegts, from '/Users/jyavenard/Downloads/colbertclip.mpg':
  Duration: N/A, bitrate: N/A
    Stream #0.0[0x7c1]: Audio: ac3, 0 channels
    Stream #0.1[0x7c2]: Video: mpeg2video, 90k tbn
At least one output file must be specified

This doesn't seem to be a problem introduced in 0.26 as mentioned earlier

[stichnot]

I'm changing the status back to Fixed after further investigation.

It may be an artifact of how the colbertclip sample was produced, but it turns out that even 0.24 does not show a correct progress bar for this sample.

Nonetheless, this is a good sample to use for ongoing development and testing. To properly deal with videos with non-constant frame rates, use of repeat_pict frames, and possibly other properties, we are moving in the direction of precomputing necessary information in the markup table (either during recording or via mythcommflag --rebuild), and using it for time display and seeking, falling back to the display timecodes embedded in the video file if necessary.