ISO playback problems

[Jim Stichnoth <stichnot@…>]

I recently observe 3 problems when playing ISO DVD rips.

1. Widescreen videos (16x9) switch to 4x3 aspect ratio at some point, which seems to be repeatable. I suspect it happens when a subtitle shows up in the stream. See attached mythfrontend1.log output for clues. This happens with Slim and VDPAU Normal profiles. One can "fix" this by selecting H.Stretch from the Adjust Fill menu.

2. ISOs with several titles take a long time to start up, and also to jump to the main menu. See attached mythfrontend2.log output, where the time between 06:55:32 and 06:56:08 (36 seconds) is spent on the "Please Wait...." screen.

3. Jumping within an ISO video sometimes has accuracy problems. For example, pressing "50i" to jump to the 50-minute mark may jump to the 46-minute point (but a subsequent "50i" usually jumps to the right point). This is unpredictable and often happens only during the first jump (if it happens at all). This is especially unfortunate when it happens as a result of the initial bookmark seek when playback starts. Through experimentation, this seems to be a problem seeking to the desired frame, and not a problem converting between frame number and elapsed time.

MythTV Version : v0.25pre-2327-g305ef56-dirty
MythTV Branch : master
Network Protocol : 66
Library API : 0.25.20110607-2
QT Version : 4.6.2
Options compiled in:
 linux release use_hidesyms using_alsa using_jack using_oss using_pulse using_pu
lseoutput using_backend using_bindings_perl using_bindings_python using_bindings
_php using_dvb using_firewire using_frontend using_hdhomerun using_hdpvr using_i
ptv using_ivtv using_joystick_menu using_lirc using_mheg using_opengl_video usin
g_qtdbus using_qtwebkit using_v4l2 using_v4l1 using_x11 using_xrandr using_xv us
ing_bindings_perl using_bindings_python using_bindings_php using_mythtranscode u
sing_opengl using_vdpau using_ffmpeg_threads using_live using_mheg

[otto@…]

1. Widescreen videos (16x9) switch to 4x3 aspect ratio at some point, which seems to be repeatable. I suspect it happens when a subtitle shows up in the stream. See attached mythfrontend1.log output for clues.

This sounds like the same issue as in #9843.

[Jim Stichnoth <stichnot@…>]

2. ISOs with several titles take a long time to start up, and also to jump to the main menu. See attached mythfrontend2.log output, where the time between 06:55:32 and 06:56:08 (36 seconds) is spent on the "Please Wait...." screen.

This seems to be related to storage groups, as performance is just fine over NFS without SG. Adding "-v file,extra" logging suggests that dvdnav is doing tons of seeking and the new ringbuffer code isn't dealing with it very well.

[robertm]

Replying to Jim Stichnoth <stichnot@…>:

2. ISOs with several titles take a long time to start up, and also to jump to the main menu. See attached mythfrontend2.log output, where the time between 06:55:32 and 06:56:08 (36 seconds) is spent on the "Please Wait...." screen.

This seems to be related to storage groups, as performance is just fine over NFS without SG. Adding "-v file,extra" logging suggests that dvdnav is doing tons of seeking and the new ringbuffer code isn't dealing with it very well.

This part is a dupe of #9437...

[markk]

Replying to Jim Stichnoth <stichnot@…>:

Can I just point out that adding 3 different issues to 1 ticket is not helpful.

I recently observe 3 problems when playing ISO DVD rips.

1. Widescreen videos (16x9) switch to 4x3 aspect ratio at some point, which seems to be repeatable. I suspect it happens when a subtitle shows up in the stream. See attached mythfrontend1.log output for clues. This happens with Slim and VDPAU Normal profiles. One can "fix" this by selecting H.Stretch from the Adjust Fill menu.

Does this happen spontaneously while watching a sequence? or does it happen after jumping to a chapter or manually skipping?

2. ISOs with several titles take a long time to start up, and also to jump to the main menu. See attached mythfrontend2.log output, where the time between 06:55:32 and 06:56:08 (36 seconds) is spent on the "Please Wait...." screen.

This is a known issue that I've spent far too long trying to resolve. When playing back over a storage group, the libmythdvdnav object gets a RemoteFile? object from mythtv to load the iso over the network. This uses a readahead thread to buffer playback but it is painfully inefficient at dealing with the various seeks and file checks that libmythdvdnav needs to do when examining the file structure etc. Blu-ray playback has a similar problem.

The quick and dirty fix is to not use the readahead thread. This will generally reduce startup times to less than a second but you will almost certainly get playback issues due to the lack of buffering - especially at cell boundaries.

If anyone has any other suggestions, I'm all ears.

3. Jumping within an ISO video sometimes has accuracy problems. For example, pressing "50i" to jump to the 50-minute mark may jump to the 46-minute point (but a subsequent "50i" usually jumps to the right point). This is unpredictable and often happens only during the first jump (if it happens at all). This is especially unfortunate when it happens as a result of the initial bookmark seek when playback starts. Through experimentation, this seems to be a problem seeking to the desired frame, and not a problem converting between frame number and elapsed time.

I can't reproduce this - can you try and narrow down the circumstances which trigger it?

[Jim Stichnoth <stichnot@…>]

Replying to markk:

1. Widescreen videos (16x9) switch to 4x3 aspect ratio at some point, which seems to be repeatable. I suspect it happens when a subtitle shows up in the stream. See attached mythfrontend1.log output for clues. This happens with Slim and VDPAU Normal profiles. One can "fix" this by selecting H.Stretch from the Adjust Fill menu.

Does this happen spontaneously while watching a sequence? or does it happen after jumping to a chapter or manually skipping?

Spontaneously. See a 20MB excerpt of Aladdin (1992) at ​https://docs.google.com/leaf?id=0BxETmfuHvGPQNWRiNzBhYjAtNjBlZC00NWE5LTkyMjctYzZjY2ZjYmVkNjk1&sort=name&layout=list&num=50 . The aspect ratio changes at the 29-second mark, just before the first caption/subtitle is displayed. Same behavior with or without storage groups.

3. Jumping within an ISO video sometimes has accuracy problems. For example, pressing "50i" to jump to the 50-minute mark may jump to the 46-minute point (but a subsequent "50i" usually jumps to the right point). This is unpredictable and often happens only during the first jump (if it happens at all). This is especially unfortunate when it happens as a result of the initial bookmark seek when playback starts. Through experimentation, this seems to be a problem seeking to the desired frame, and not a problem converting between frame number and elapsed time.

I can't reproduce this - can you try and narrow down the circumstances which trigger it?

OK, I was afraid of this. I'll open a new ticket when I find out more.

[Github]

Use the current video aspect ratio if the video stream is reset.

In AvFormatDecoder?, if a stream change is detected and no new/replacement video stream is found, we choose some sensible defaults and tell the player about the change. The video aspect ratio is however reset to the default 4/3 - which immediately changes the currently displayed frames. Instead use a pre-existing aspect ratio, which will be 4/3 by default if we haven't yet determined something more sensible.

This is only likely to be an issue with DVD playback, where we often get stream updates piecemeal from the demuxer - the streams are reset and some new audio streams added (no video found) and the new video stream is added a 'short' period of time later.

Refs #9854

Branch: master Changeset: d3b95c8e6d7ec39333ba7af4a473c0849c853355

[Github]

DVD: Refactor forced video aspect ratio code.

Instead of using custom code to force the aspect ratio during dvd playback (usually used to force still frames to 16:9), just monitor the aspect ratio within DVDRingBuffer and use it to override the stream aspect ratio in AvFormatDecoder?.

Other than simplifying the player code, this avoids another potentially buggy and costly call directly from the decoder thread into the player.

Refs #9854 Refs #9268

Branch: master Changeset: b944b041c8987ea135076c1af63bb905a50d7a1d

[Jim Stichnoth <stichnot@…>]

Replying to markk:

Replying to Jim Stichnoth <stichnot@…>:

2. ISOs with several titles take a long time to start up, and also to jump to the main menu. See attached mythfrontend2.log output, where the time between 06:55:32 and 06:56:08 (36 seconds) is spent on the "Please Wait...." screen.

This is a known issue that I've spent far too long trying to resolve. When playing back over a storage group, the libmythdvdnav object gets a RemoteFile? object from mythtv to load the iso over the network. This uses a readahead thread to buffer playback but it is painfully inefficient at dealing with the various seeks and file checks that libmythdvdnav needs to do when examining the file structure etc. Blu-ray playback has a similar problem.

The quick and dirty fix is to not use the readahead thread. This will generally reduce startup times to less than a second but you will almost certainly get playback issues due to the lack of buffering - especially at cell boundaries.

If anyone has any other suggestions, I'm all ears.

Mark,

Please have a look at the mythfrontend log attached to #9864, ​http://code.mythtv.org/trac/raw-attachment/ticket/9864/mythfrontend.log.gz . Besides the problem addressed in that ticket, there is evidence of another performance problem. There are many bursts of successive mythfile_seek calls seeking to the same location. Usually the "OPT1" case in FileRingBuffer::Seek() is triggered, but as soon as the readahead thread fills up the buffer, this optimization fails and ResetReadAhead?() is called, and the pattern starts all over again. I believe that if we could avoid resetting the readahead thread, the startup time for this ISO would drop from ~15 seconds down to 1-2 seconds.

[Jim Stichnoth <stichnot@…>]

Attached is a patch that demonstrates a very crude "fix". It modifies RingBuffer::ReadBufFree?() such that the readahead thread never fills up the entire buffer, and so the OPT1 case is triggered whenever possible. With this patch in place, every one of my ISO videos will completely load up within 5 seconds, which is on a par with non-ISO startup speeds.

I wonder if this direction would help with BD playback as well.

[markk]

Jim

Thanks for your perseverance on this:)

Are you using that patch on both the frontend and backend? or just the frontend. I've just tested it here and it makes no noticeable difference on my (remote) dev box.

I've also attached a different patch that does work for me - generally speaking it halves the startup time over a slowish wifi connection. Still far from perfect on some discs though.

Can you try the remotedvd patch and see what impact it has for you? (with clean master and maybe in conjunction with your patch)

thanks and regards

Mark

[Jim Stichnoth <stichnot@…>]

Replying to markk:

Are you using that patch on both the frontend and backend? or just the frontend. I've just tested it here and it makes no noticeable difference on my (remote) dev box.

I was testing it across the whole system -- backend and frontend at the same time.

I've also attached a different patch that does work for me - generally speaking it halves the startup time over a slowish wifi connection. Still far from perfect on some discs though.

Can you try the remotedvd patch and see what impact it has for you? (with clean master and maybe in conjunction with your patch)

Using clean master (v0.25pre-2493-gcebfb7f) plus either or both patches, gives the same improved performance. I.e., ~5 seconds to start up my worst ISO test file, versus ~15 seconds with unpatched master.

[Jim Stichnoth <stichnot@…>]

It appears that the patch in #9437 (​http://code.mythtv.org/trac/attachment/ticket/9437/9437_remote_dvd_speedup_v1.diff) fixes the slow DVD/ISO loading problem. Without either that patch or Mark's remotedvd.diff patch, ISO loading is still very slow. I suggest closing this ticket, as issue 1 has been solved and I have a hard time reproducing issue 3.

[markk]

Issue 1 was fixed in:

b944b041c8987ea135076c1af63bb905a50d7a1d

Issue 2 was fixed in:

da49d7999ba1f2cede500dbd78fdb2dbc88adaee and d1537a588ef346e2d581eabd92dc9d24f0c50e09 and e8f6baf050fe97853a1dbbbb44e1d2ca6904fcee

Issue 3 was largely fixed in:

4b0803be0c0974c1849c297064eeb96bf7817b9b