[mythtv-users] analog recordings won't play with some devices (long and confusing)
belcampo
belcampo at zonnet.nl
Tue May 11 20:03:11 UTC 2010
D. Hugh Redelmeier wrote:
> I have two MythTV backends that record analog signals using Hauppauge
> tuners and am having trouble playing the recordings with various
> non-Myth devices.
>
> Mysteries:
>
> - why can mplayer not play some of my recordings from MythTV 0.22
> while it can play recordings from MythTV 0.20?
>
> - why can Linux-based XBMC not play my recordings with MythTV 0.22 but
> it can play recordings from MythTV 0.20? Yet OSX-based XBMC can
> play them.
Because the OSX-based version will have additional codecs which the
precompiled linux-based version lacks. Self compiling XBMC is the solution.
>
> - why can WDTV not play any of my MythTV recordings (albeit with two
> different failure modes)?
>
>
> Details (very long!):
>
> Recording systems:
>
> (1) an old MythTV 0.20 setup (32-bit system Fedora Core 5).
> Uses a PVR-250 and a few Adaptec VideOH! AVC 2410 cards (a lot
> like a PVR-150).
> Recording Profile: width 352, Height 480, CODEC MPEG-2,
> Stream Type MPEG-2 PS, Aspect Ratio 4:3,
> (video) Avg bitrate 2251, Max bitrate 3009,
> (audio) sampling rate 3200, type Layer 2, Bitrate 384Kb/s,
> SAP/bilingual main language, Volume (%) 90.
>
> (2) a newer Mythbuntu with MythTV 0.22 (64-bit).
> Uses the analog sections of two Hauppauge HVR 1600 tuners.
> The driver for the tuners is from the hg repository since
> the one in Ubuntu's kernel isn't stable.
>
> (a) default recording profile. Similar to (1) except
> width 480, Avg bitrate 4500, Max bitrate 6000,
> Sampling rate 4800. I didn't choose this, it just happened.
>
> (b) recording profile adjusted to be closer to (1) but some
> divergence remains:
> Avg bitrate 2200, Max bitrate 3200, Sampling rate 4800
> (Sampling rate cannot be adjusted.)
>
>
> Playback systems:
>
> (i) Mythbuntu with MythTV 0.20 -- suitable for playing back recordings
> from (1). Cannot play recordings from (2) since MythTV versions are
> required to match. (Transport protocol: Myth)
>
> (ii) Mythbuntu (2) can act as its own front end. Cannot play
> recordings from (1) because the MythTV versions differ.
> (Transport protocol: Myth)
>
> (iii) mplayer on a variety of Linux systems (transport protocol: http,
> NFS, or direct file-system access).
>
> (iv) AppleTV (MacOSX) running XBMC (transport protocol: UPnP or Myth
> -- I'm not sure)
>
> (v) Acer Revo (Atom + nVidia Ion) running XBMC under 64-bit Linux with
> nVidia proprietary X driver. (transport protocol: UPnP or Myth).
> (Similar results running XBMC on (2) with an nVidia proprietary
> driver.)
>
> (vi) WD-TV live; firmware 1.02.21 and earlier (transport protocol: UPnP or SMB)
>
>
> Observations:
>
> (i) works fine as a frontend for (1) but not (2) (version clash)
>
> (ii) similarly works fine for (2) but not (1) (version clash)
>
> (iii) has worked well for (1). I've used Mythweb to give me a URL to
> feed mplayer.
>
> It did not work for (2a). It always failed with the error
> message:
> Too many video packets in the buffer: (4096 in 7900000 bytes).
>
> Googling lead me to this thread
> <http://www.mythtv.org/pipermail/mythtv-users/2010-March/282720.html>
> which lead me to play with the recording profile, creating (2b).
>
> mplayer works with (2b). I find this quite mysterious.
>
> (iv) works well for both (1) and (2)
>
> (v) works well for (1) but not (2)
> It seems odd that XBMC on OSX works but not on Linux.
>
> The failure mode is:
>
> - XBMC doesn't correctly know the length of the recording
>
> - playing fails part way through a recording.
> Sometimes quite early, sometimes as much as an hour in.
> Sometimes the failure is just a stop, sometimes a constant
> stuttered repeat happens.
>
> (vi) fails for (1). I described this in this thread:
> <http://www.mythtv.org/pipermail/mythtv-users/2009-December/275129.html>
> I still have no answers to those questions.
>
> Fails for (2) differently. It starts to play, sound and picture,
> but after a few seconds the image freezes and the sound crackles
> and stops.
>
> Other oddities:
>
> - why does the WDTV think it can handle recordings from (2a) and (2b)
> but not (1)?
>
> - why does the HVR-1600 analog section driver only allow a 48000 audio
> sample rate? I think that the hardware is very similar to the
> PVR-150 that does allow various audio sample rates.
>
> - mediainfo, applied to a recording from (1) and from (2b), shows no
> differences that look material.
If that's true then only the container can be the source of the
problems. ffmpeg and applications relying on it's libraries, most
includinf mythtv do, has/had 'poblems' in writing compliant containers.
As a test you could remux your source with tsMuxeR/tsMuxerGUI to a
compliant MPEG-TS container, with MP4Box to a compliant mp4 container
and with mkvtools to a copmpliant matroska container. Then at least all
mplayer and XBMC and probably WD-TV Live problems should be solved.
I do have a PopCornHour which is more or less identical to the WD-TV
Live and is also critical about compliant container formats.
>
> Is there a tool to check standards conformance of a video recording?
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
More information about the mythtv-users
mailing list