Playback of interlaced TV broken (from r22881)

[Davin McCall <davmac@…>]

Playback of interlaced TV (live TV or recording) is broken. Video plays too quickly and goes out of sync with audio. This occurs since r22881, however, that change is not actually faulty, it just exposes an additional bug.

The problem is that m_double_framerate (in mythtv/libs/libmythtv/NuppelVideoPlayer.cpp) doesn't get set correctly when an interlaced scan mode is set, since it is initialized to interlaced and SetScanType? returns without correctly setting m_double_framerate if the scan type matches the current type.

As a result m_double_framerate is false and the AVSync method doesn't recognize that two fields need to be displayed each frame interval.

Patch attached.

[Davin McCall <davmac@…>]

Patch for #7644

[anonymous]

Replying to Davin McCall <davmac@…>:

Playback of interlaced TV (live TV or recording) is broken. Video plays too quickly and goes out of sync with audio. This occurs since r22881, however, that change is not actually faulty, it just exposes an additional bug.

The problem is that m_double_framerate (in mythtv/libs/libmythtv/NuppelVideoPlayer.cpp) doesn't get set correctly when an interlaced scan mode is set, since it is initialized to interlaced and SetScanType? returns without correctly setting m_double_framerate if the scan type matches the current type.

As a result m_double_framerate is false and the AVSync method doesn't recognize that two fields need to be displayed each frame interval.

I, too, have seen this problem on select ATSC broadcast channels. The problem was not present in release 0.21, and has been visible since upgrading to 0.22 yesterday. I'll try applying the patch and report on whether it works.

Here are the statistics reported by FFMPEG for a clip exhibiting problem:

[scott@eowyn myth_playback_issue]$ ffmpeg -vstats -i 5071_20091120160000.mpg FFmpeg version 0.5-30.fc9, Copyright (c) 2000-2009 Fabrice Bellard, et al.

configuration: --prefix=/usr --libdir=/usr/lib --shlibdir=/usr/lib --mandir=/usr/share/man --enable-shared --enable-gpl --enable-postproc --enable-swscale --enable-avfilter --enable-avfilter-lavf --enable-pthreads --enable-x11grab --enable-vdpau --disable-avisynth --disable-libamr-nb --disable-libamr-wb --enable-libdc1394 --enable-libfaac --enable-libfaad --enable-libfaadbin --enable-libgsm --enable-libmp3lame --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --extra-cflags=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables --disable-stripping --extra-cflags=-I/usr/include/nvidia-graphics --extra-ldflags=-L/usr/lib/nvidia-graphics libavutil 49.15. 0 / 49.15. 0 libavcodec 52.20. 0 / 52.20. 0 libavformat 52.31. 0 / 52.31. 0 libavdevice 52. 1. 0 / 52. 1. 0 libavfilter 0. 4. 0 / 0. 4. 0 libswscale 0. 7. 1 / 0. 7. 1 libpostproc 51. 2. 0 / 51. 2. 0 built on Mar 17 2009 07:05:36, gcc: 4.3.0 20080428 (Red Hat 4.3.0-8)

Seems stream 0 codec frame rate differs from container frame rate: 119.88 (120000/1001) -> 59.94 (60000/1001) Input #0, mpegts, from '5071_20091120160000.mpg':

Duration: 00:59:56.35, start: 50395.716533, bitrate: 11657 kb/s Program 1

Stream #0.0[0x31]: Video: mpeg2video, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 17808 kb/s, 59.94 tbr, 90k tbn, 119.88 tbc Stream #0.1[0x34](eng): Audio: ac3, 48000 Hz, 5.1, s16, 384 kb/s Stream #0.2[0x35](spa): Audio: ac3, 48000 Hz, mono, s16, 96 kb/s Stream #0.3[0x36](fre): Audio: ac3, 0 channels, s16

At least one output file must be specified

[markk]

(In [22895]) Revert r22881 and r22891 until a complete and thoroughly tested fix is available. Closes #7644. Closes #7635.

[Davin McCall <davmac@…>]

Regardless of whether the problem in the title is solved by reverting r22881 and r22891, the underlying logic flaw fixed by the patch attached to this ticket still exists.

[Johnny Stenback <mythtv@…>]

This does appear to fix the av sync problem that was introduced by r22881 and 22891, which I tested and reported as working... They worked fine for DVD playback, but I never tested watching recordings or live tv :( This patch does fix the av sync problem when watching recordings and live tv for me, and I did see the problem before applying this patch.