[mythtv-users] Intermittent playback skips and log errors

Steve networks1 at cox.net
Tue Nov 29 15:36:07 UTC 2011


On Nov 28, 2011, at 7:56 AM, Mark Lord <mythtv at rtr.ca> wrote:

> On 11-11-27 09:47 AM, steve wrote:
>> On 11/25/2011 9:35 PM, Mark Lord wrote:
>>> On 11-11-25 12:19 PM, steve wrote:
>>>> I am having a problem playing back recorded (via HDPVR) shows.  There is
>>>> intermittent dropping out of audio and perhaps a brief skip in the video
>>>> then playback continues.  The log is filled with hundreds of entries like
>>>> 
>>>> 2011-11-22 06:42:11.701 [h264 @ 0x35326f4f20]non-existing PPS referenced
>>>> 2011-11-22 06:42:11.701 [h264 @ 0x35326f4f20]sps_id out of range
>>>> 2011-11-22 06:42:11.701 [h264 @ 0x35326f4f20]non-existing SPS 32 referenced in b
>>>> uffering period
>>>> 2011-11-22 06:42:11.701 [h264 @ 0x35326f4f20]non-existing PPS 0 referenced
>>>> 2011-11-22 06:42:11.701 [h264 @ 0x35326f4f20]decode_slice_header error
>>>> 2011-11-22 06:42:11.701 [h264 @ 0x35326f4f20]no frame!
>>>> 2011-11-22 06:42:11.753 [h264 @ 0x35326f4f20]mmco: unref short failure
>>>> 
>>>> I researched this, and it seems to be related to VDPAU somehow, but I can't find any consistent recommendation for a fix.  I have the latest NVIDIA drivers installed.  Anyone have idea about how to address this?
>>> 
>>> I've noticed this *began* happening for some h264 files on my own system
>>> at some point this fall.  I regularly build mythtv from the latest 0.24-fixes
>>> sources,
>>> and until perhaps July/August 2011 everything was fine on the stuttering front.
>>> But as of October, some files that used to play perfectly now have the issue.
>>> 
>>> A workaround I've found for it is to enable "-v all" logging for mythfrontend.
>>> That's right -- turn on all of the debug messages to try and track down the issue,
>>> and the issue itself goes away.  For me at least.  :)
> ..
>> Thanks but I tried this fix and it didn't work for me.  It's odd because 
>> some recordings play just fine, whereas others stutter so much it's 
>> difficult to watch them.  I've tried lowering number of backend jobs to 
>> 1 and setting processor load to low in setup in case it's a processor 
>> issue, but nothing seems to affect it.
> ..
> 
> Yeah, I poked around with it some more last night and discovered
> that the logging trick worked only for a couple of videos that
> had only minor audio loss issues.
> 
> Lots of other videos still had intermittent audio regardless.
> So I checked with mediainfo on those, and discovered that all of
> the jerky-audio files were used AAC for audio, at bit rates > 100kb/sec.
> 
> So I figure the issue has to do with bad AAC decoding or something in mythtv
> or in the libraries it uses for AAC.
> 
> Easy fix:  run ffmpeg to convert the audio tracks to AC3.
> I wrote a shell script to do this last evening, and the results
> are just fine -- everything I tried it on was instantly cured.
> 
> Here's the script.  Requires the "mediainfo" command.
> Feed it a list of video path/filenames as input.
> Output is to same_name.avi, or same_name-new.avi if old file was a .avi:
> 
> #!/bin/bash
> # Fix stuttering audio:
> 
> while [ "$1" != "" ]; do
>        f="$1"
>        shift
>        aformat=$(mediainfo --inform="Audio;%Format%" "$f")
>        if [ "$aformat" = "AAC" ]; then
>                fname="${f%%.???}"
>                out="$fname.avi"
>                [ "$f" = "$out" ] && out="$fname-new.avi"
>                ffmpeg -i "$f" -vcodec copy -acodec ac3 -ab 384k "$out"
>        else
>                echo "$f: not AAC, skipped ($aformat)"
>        fi
> done
> 

Do you run that manually or is it automatically triggered somehow?


More information about the mythtv-users mailing list