[mythtv-users] Does anyone know who supports Mytharchive?

[Paul Harrison]

Craig Huff wrote:
> On Thu, Aug 7, 2008 at 5:05 PM, Paul Harrison <mythtv at dsl.pipex.com> wrote:
>   
>> That sounds a lot like a bug that has already been fixed. What version
>> are you using?
>>
>> ...
>>
>> Paul H.
>>     
>
> Paul-
>
> Could you cite the bug(s) you're referencing and give me an idea of
> what MythTV version they first appeared in?  I generally use what Axel
> has in his stable RPM repository and would be most interested in
> giving MythArchive another try.  My previous attempts either failed to
> even produce a DVD or had the audio drift out of sync with the video.
>
> Craig.
>
>   

Pam was a little vague about the error but my initial thought was the 
problem with ffmpeg renaming the ac3 codec to liba52 which caused the 
script to fail. I can't remember the exact error message something like 
'Can't find all the required streams' or something like that.

For svn trunk
http://svn.mythtv.org/trac/changeset/17101

and for svn 0-21-fixes branch
http://svn.mythtv.org/trac/changeset/17102

The audio sync problem is a completely different problem cause by 
tortuous process the recording has to go though to get on the DVD.

Sometimes it works, sometimes it doesn't. Of cause I'd like it to work 
100% of the time, it already does for me using recordings from a PVR350  
:-) but sadly not for everyone, DVB-x recordings are another story 
though. When you begin to understand some the processes involved to get 
the recordings to DVD you may see why it can sometimes fail.

It should be made clear that the mythburn.py script doesn't do any 
processing of files itself but calls other tools to do the dirty work. 
Some of the tools involved in processing the recording to get them into 
a state where they can be added to a DVD include, mytharchivehelper, 
mythreplex, mythtransode, projectx, ffmpeg, mplex and dvdauthor and 
probably others I have forgot.    

The mpeg file as recorded by Myth from a PVR-x50 or from a ATSC/DVB-x 
broadcast contains packets of  video and audio data interleaved 
together. These packets contain the actual video/audio data and also 
headers that have presentation time stamp (PTS)  information that tell 
the player when each packet should be played out. The PTS timestamps are 
what keeps everything in sync.

When we create a DVD we _have_ to split the original file apart to get 
the individual audio and video streams. We do this for several reasons, 
the file may contain several audio streams and we only want one of them, 
the file may contain additional data streams that we don't require 
(teletext, subtitles, interactive data streams etc), we may have to swap 
the mp2 audio stream with an ac3 copy etc. We also have to insert the 
NAV packets that DVDs require and as far as I know the only way to do 
that is to split the streams then use mplex to remux them back together 
inserting the NAV packets along the way.

Unfortunately when you split a file like this all those PTS timestamps 
are lost making it impossible to guarantee that when you stitch 
everything back together (re multiplex) they will still be in sync. The 
tools we use to split the original file (demux) either mythreplex or 
projectx try to keep everything in sync by keeping track of the PTSs and 
comparing that with how long each stream is (in time) and either insert 
or delete audio packets to make sure each stream is the correct length.

Things are further complicated when the original file needs to be cut to 
top and tail the file and remove commercials. The problem there is the 
audio and video packets aren't necessarily the same length (in time). So 
when you cut a file there may be either some audio or video past the end 
of the cut that we don't want. If the demuxer doesn't keep track of 
these part packets the sync will progressively get out of sync after 
each cut.

There also seems to be a problem with some broadcasters streams 
confusing the demuxers. I don't know exactly what the problem is but it 
could be something to do with them changing the streams format during 
commercials or it could be PTS jumps around commercials are confusing 
them. It could simply be the streams are slightly corrupt due to poor 
reception and most players can detect and conceal these errors but the 
tools used by MythArchive assume perfect streams and so don't do enough 
error detection to correct any problems .

So basically fixing the audio sync problem is not easy.  It should be 
possible for someone with a  great deal of knowledge about mpeg streams 
to get mythtranscode and mythreplex to do a better job but that is 
beyond my knowledge.

It may be possible to find the magic combination of existing tools that 
will work together 100% of the time whatever is thrown at them. The last 
time I looked most of the tools used by MythArchive weren't being 
actively developed so we may be stuck with what we have. 

ffmpeg is actively being developed and it may be possible to better use 
it's capabilities either using the ffmpeg command line tool or using  
libavformat, libavcodec etc directly.  I noticed in the list of encoding 
formats 'dvd' I wonder if that creates a file including the NAV packets 
that can be passed directly to dvdauthor or is it just a plain mpeg PES 
file? Something to investigate if I ever get time.
 
Paul H.