[MPlayer-users] Trouble with HD-PVR recordings

[Charlie Gunyon]

>> Anyhow yes, -mc 1 and -demuxer lavf -nocorrect-pts works for the
>> sample there but it's seriously low bitrate.  I've uploaded a
>> different sample in Matroska (still h264 and AC3) with a higher
>> bitrate at http://www.charlieg.net/downloads/tv.mkv.
>
> Note that the important difference between your first sample and this one is not
> the bit-rate but the container.

I understand the idea of container formats, but the real difference
here is what MPlayer's defaults are.  Is this information documented
anywhere?

> For MPEG transport streams, the native demuxer (demuxer mpegts) and
> nocorrect-pts are default (correct-pts is always default for demuxer lavf), for
> matroska files, demuxer lavf is default, and correct-pts is (also) default for
> the native demuxer (demuxer mkv).
> You already know that correct-pts is bad for PAFF, so you always need
> nocorrect-pts for PAFF in matroska. You also know that while some PAFF samples
> (like the ones you uploaded) do not need mc 1 with demuxer lavf, it is often
> needed and does not hurt very much.

I tried taking -mc out:

mplayer -vo vdpau -vc ffh264vdpau -demuxer lavf -nocorrect-pts -v
tv.mkv >output.log

and still got A-V desync and SLOW message.

> Since you did not post complete, uncut output of your mplayer command (including
> your command line), I can only guess that your system _is_ too slow for software
> decoding if you get this message.

I uploaded it here: http://www.charlieg.net/downloads/output.log, but
I really think that my system is not too slow as this sample plays
just fine in Windows using VLC, or using the CoreAVC for Linux
software.

>> - mplayer -vo vdpau -vc ffh264vdpau -mc 1 -demuxer lavf -nocorrect-pts
>> tv.mkv (SLOW message and A-V desync)
>
> Are you sure? Could this be a problem with a too low refresh rate of your
> screen? Did you test export VDPAU_NVIDIA_NO_OVERLAY=1?
> I will test with my Pentium III 500, but that will take some time.

Neat trick, that helped a lot!  Is that documented anywhere?

> De-interlacing of 1080 streams is always expensive, no matter if done in CPU or
> GPU. It is not possible (for deint>1) on my PCI-E G98, but I will not protest:
> On a range from €22,60 to €500, my card is around €26, so I cannot expect it to
> de-interlace every stream (without dropping frames).

Yeah I'm starting to figure this out.  You can't use CPU deinterlacing
when using VDPAU decoding can you?

>>
>> And I avoided the SLOW message and A-V desyncs, but playback was quite
>> choppy.  I assume this is due to 'skipframe=nonref' but if this is the
>> result I don't see it as a solution.
>
> I tried to say it before: You cannot ask the system to drop as many frames as
> possible and complain about dropping frames.

Yeah I understand the concept of "frame skipping" or alternately
"frame dropping" but I thought I wasn't asking it to drop as many
frames as possible, just the non-reference ones.  I guess I didn't
realize how many that was, the docs really aren't clear about this at
all.  Also I thought that '-framedrop' was supposed to drop as many
frames as necessary.

Thanks,
-Charlie