Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#7644 closed defect (fixed)

Playback of interlaced TV broken (from r22881)

Reported by: Davin McCall <davmac@…> Owned by: Janne Grunau
Priority: critical Milestone: unknown
Component: MythTV - Video Playback Version: head
Severity: high Keywords:
Cc: Ticket locked: no

Description

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.

Attachments (1)

patch2a.txt (591 bytes) - added by Davin McCall <davmac@…> 10 years ago.
Patch for #7644

Download all attachments as: .zip

Change History (5)

Changed 10 years ago by Davin McCall <davmac@…>

Attachment: patch2a.txt added

Patch for #7644

comment:1 in reply to:  description Changed 10 years ago by 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

comment:2 Changed 10 years ago by markk

Resolution: fixed
Status: newclosed

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

comment:3 Changed 10 years ago by 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.

comment:4 Changed 10 years ago by 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.

Note: See TracTickets for help on using tickets.