2009-09-18, 15:27
(Mentioned VLC because it would seem to indicate the data is there in the file somewhere to help get it right...)
Short description: An MPEG2 TS file remuxed by VLC from an EyeTV recording of a BBC HD programme - plays perfectly in VLC (Linux and Mac), but in XBMC (Linux with VDPAU and Mac) playback is perfect but the sound is consistently off by a fraction of a second, which is quite noticeable when someone talks in-vision.
I notice when I play the file in VLC that the sound starts playing a moment before the video window opens, and wonder if the problem is that XBMC isn't doing that - isn't, perhaps, taking note of the start of the video and audio tracks being offset in time? (Wild guess.)
Background / Long Description:
Given in case someone can see a better way to achieve what I'm actually after! :-)
Objective:
I want to record BBC HD programming using EyeTV on the Mac and play it back in its original transmission quality (ie: not transcoded down) on XBMC. Transcoding down (eg: to AppleTV) already works perfectly; this is all for when I don't want to compromise.
What used to work:
For a while I was able to simply export from EyeTV using its "Native Formats (No Re-encoding)" export option (ie: to remux the video and audio into an MPEG4 container). XBMC would then play back the resulting .mp4 files perfectly.
What went wrong:
But near the beginning of August the BBC changed the encoder they're using on BBC HD, and ever since then, the "Native Formats" export has produced a file which XBMC and VLC cannot play.
(I have a ticket open with Elgato about this but even when I opened it I didn't really think it was their fault; just that they were possibly best-placed to fix it. I also doubt there's much use complaining to the BBC - they're already inundated with complaints since the new encoders went on-stream, which they're pretty much staunchly denying are causing any real problems - I imagine they'd be even less bothered when the only problem someone has is with playing recordings!)
It turns out that whatever tools I use to try to remux that h.264 data into an MPEG4 container, VLC and XBMC won't play it, even though they can both play the original transport stream.
(NB: I can't use the original transport stream directly because BBC HD also broadcast as the first audio track a narration for visually-impaired people; and XBMC naturally chooses this track to play. It also tries to render the transmitted subtitles, but it goes horribly wrong.)
In the end, the nearest to success I got to, was to use VLC on Linux (didn't work on the Mac version) to remux the video and desired audio track into a new MPEG2 TS file. An example commandline to do this is:
VLC on either platform (Mac or Linux) will then play this back with perfect lipsync. But the audio starts slightly early, or the video starts slightly late, depending on your point of view.
XBMC on either platform (Mac or Linux) will play it back; picture and sound are each perfect, but off by a fraction of a second, with the audio lagging slightly, I think. (If I sound unsure it's because it's close; just off by enough to be able to tell it's wrong.)
NB: mplayer on my Linux workstation (not the xbmc-live box) can't play the video at full frame rate, and the video quickly lags very badly, so I couldn't use that to compare. Slightly surprising as VLC was able to play it back at full frame rate even scaled down to the 1680x1050 screen. (that machine has an old nVidia interface, GeForce 6100 - not VDPAU-capable)
XBMC on the Mac is the latest released version, ie 9.04.1
XBMC with VDPAU on the box under the TV is from the svn ubuntu repository thus:
They're both showing the same audio offset so my guess is whatever's behind it hasn't been addressed since the last stable release and isn't affected by platform specifics.
Short description: An MPEG2 TS file remuxed by VLC from an EyeTV recording of a BBC HD programme - plays perfectly in VLC (Linux and Mac), but in XBMC (Linux with VDPAU and Mac) playback is perfect but the sound is consistently off by a fraction of a second, which is quite noticeable when someone talks in-vision.
I notice when I play the file in VLC that the sound starts playing a moment before the video window opens, and wonder if the problem is that XBMC isn't doing that - isn't, perhaps, taking note of the start of the video and audio tracks being offset in time? (Wild guess.)
Background / Long Description:
Given in case someone can see a better way to achieve what I'm actually after! :-)
Objective:
I want to record BBC HD programming using EyeTV on the Mac and play it back in its original transmission quality (ie: not transcoded down) on XBMC. Transcoding down (eg: to AppleTV) already works perfectly; this is all for when I don't want to compromise.
What used to work:
For a while I was able to simply export from EyeTV using its "Native Formats (No Re-encoding)" export option (ie: to remux the video and audio into an MPEG4 container). XBMC would then play back the resulting .mp4 files perfectly.
What went wrong:
But near the beginning of August the BBC changed the encoder they're using on BBC HD, and ever since then, the "Native Formats" export has produced a file which XBMC and VLC cannot play.
(I have a ticket open with Elgato about this but even when I opened it I didn't really think it was their fault; just that they were possibly best-placed to fix it. I also doubt there's much use complaining to the BBC - they're already inundated with complaints since the new encoders went on-stream, which they're pretty much staunchly denying are causing any real problems - I imagine they'd be even less bothered when the only problem someone has is with playing recordings!)
It turns out that whatever tools I use to try to remux that h.264 data into an MPEG4 container, VLC and XBMC won't play it, even though they can both play the original transport stream.
(NB: I can't use the original transport stream directly because BBC HD also broadcast as the first audio track a narration for visually-impaired people; and XBMC naturally chooses this track to play. It also tries to render the transmitted subtitles, but it goes horribly wrong.)
In the end, the nearest to success I got to, was to use VLC on Linux (didn't work on the Mac version) to remux the video and desired audio track into a new MPEG2 TS file. An example commandline to do this is:
Code:
vlc /net/melusine.local/Volumes/Vault/Remux\ Workspace/Source/Desperate\ Romantics\ -\ 4\:6\,\ Drama.eyetv/0000000010320415.mpg --audio-track 1 --sout 'file/ts://dr4.mpg'VLC on either platform (Mac or Linux) will then play this back with perfect lipsync. But the audio starts slightly early, or the video starts slightly late, depending on your point of view.
XBMC on either platform (Mac or Linux) will play it back; picture and sound are each perfect, but off by a fraction of a second, with the audio lagging slightly, I think. (If I sound unsure it's because it's close; just off by enough to be able to tell it's wrong.)
NB: mplayer on my Linux workstation (not the xbmc-live box) can't play the video at full frame rate, and the video quickly lags very badly, so I couldn't use that to compare. Slightly surprising as VLC was able to play it back at full frame rate even scaled down to the 1680x1050 screen. (that machine has an old nVidia interface, GeForce 6100 - not VDPAU-capable)
XBMC on the Mac is the latest released version, ie 9.04.1
XBMC with VDPAU on the box under the TV is from the svn ubuntu repository thus:
Code:
xbmc@spriggan:~$ apt-cache policy xbmc
xbmc:
Installed: 9.04.3+svn22528-jaunty2
Candidate: 9.04.3+svn22528-jaunty2
Version table:
*** 9.04.3+svn22528-jaunty2 0
500 http://ppa.launchpad.net jaunty/main Packages
100 /var/lib/dpkg/statusThey're both showing the same audio offset so my guess is whatever's behind it hasn't been addressed since the last stable release and isn't affected by platform specifics.
)