[MPlayer-users] Karaoke (cdg) support broken?

[The Wanderer]

On 2018-02-27 at 15:50, Alec Bennett wrote:

> I get an interesting error when I play the audio file along with the
> CDG video file:
> 
> mplayer ~/Karaoke/test.cdg -audiofile ~/Karaoke/test.mp3
> 
> I've tried the items suggested in the error message as best I can
> figure out, but maybe this makes sense to someone? My system
> definitely shouldn't be too slow, it's an i5 CPU with 8 gigs of RAM.
> 
> Error message with new warning appended:

>            ************************************************
>            **** Your system is too SLOW to play this!  ****
>            ************************************************

Is this the error/warning you were talking about?

As I understand matters, this just means that the gap between the
timestamp on the video stream and the timestamp on the audio stream has
gotten too large. That can be caused by many factors, not just system
slowness, but that was the major cause once upon a time and it's never
seemed worth updating the message to try to explain the many other
possible causes.

If the problem is with the video decoding and/or playback, and the video
file contains no audio track, then it's no surprise that playing the
video file alone wouldn't produce that message; the player doesn't have
any second source of timestamps to compare against.

On my system, if I play the the two together with the '-mc 10' option
thrown into the mix (before either of the other filenames) - to permit
the player to skip up to 5 seconds of video to keep it in sync with the
audio - I get what looks like reasonable playback. The bits of lyrics
which are present in the audio file sync up with the video.

(As far as I can tell, the lyrics get displayed a few seconds ahead of
time, and then turn blue at the moment when you're supposed to sing
them, and the only vocals in the audio file vocals are the ones which
are supposed to come from someone other than the lead singer. This seems
appropriate for karaoke.)

The console-reported video timestamps do behave in a bit of a wonky
fashion, but as far as I can tell that's because this video format
doesn't present a new timestamp until the next frame would be different
from the current one, and there's a fair bit of time (early on in the
video, in particular) where the displayed image doesn't seem to change.
(Which leads to the audio timestamp getting out of sync with the video
timestamp, by up to about five seconds.)

I don't get the originally-described choppy playback; with no audio file
and without -mc 10 I do get the initial "paint the logo on from left to
right" parts animating slower than they should, but with that second
source of timestamps and the freedom to drop 'frames' as needed, it
comes out comparable to (if not even smoother than) what I get from pycdg.

This is with MPlayer built from current SVN, three days ago, with
internal FFmpeg pulled from git on the same date. Whether the released
1.3.0 built in 2016 that you're apparently using would behave
differently I don't know.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-users/attachments/20180227/d96c9872/attachment.sig>