[mythtv-users] Intermittent playback skips and log errors
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
>>> 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:
> # Fix stuttering audio:
> while [ "$1" != "" ]; do
> aformat=$(mediainfo --inform="Audio;%Format%" "$f")
> if [ "$aformat" = "AAC" ]; then
> [ "$f" = "$out" ] && out="$fname-new.avi"
> ffmpeg -i "$f" -vcodec copy -acodec ac3 -ab 384k "$out"
> echo "$f: not AAC, skipped ($aformat)"
Do you run that manually or is it automatically triggered somehow?
More information about the mythtv-users