[mythtv-users] nuvexport problems

[Paul Harrison]

David Watkins wrote:
> On 31/07/07, Ben Edwards <funkytwig at gmail.com> wrote:
>   
>> I used to use nuvexport very successfully however I am having real
>> problems.  I have tried using the stock ffmpeg for Ubuntu feisty,
>> compiling it myself and using the one from medibuntu archives.
>> Whatever I do, svcd, vidx, divx ... the results always look like 5th
>> generation VHS copies!  I generally accept the defaults.
>>
>> I also dont seem to be able to get mytharchive working without lipsync
>> problems (c other posting) so I have no way of archiving stuff;(
>>
>>     
>
> I've never used mytharchive and I don't do much transcoding at all but
> I can offer a couple of suggestions to attack your lip-sync issue.  I
> record from DVB-T in the UK.
>
> 1)  If your source is DVB then I'd recommend always doing a lossless
> transcode first from within mythtv.  It doesn't degrade the quality,
> doesn't take very long (even on low-powered hardware) and seems to
> make any subsequent processing much more reliable.
>
>   

MythArchive will do this automatically if the source file is a TS file
like you get from DVB.
 
> 2)  Find out if your lip-sync error is consistent.  For example I
> transcode some material for my PSP (using mencoder) and have a
> completely consistent 300ms offset between sound and picture (can't
> remember which way), which I can fix by supplying the correct offset
> in the mencoder command line.  To find out what the offset is, either
> mplayer or xine (maybe both) have the ability to delay or advance the
> soundtrack, so you play your file, keep adjusting the delay until it
> looks right and read off the offset value.  If it turns out that, for
> your mytharchive settings, the offset was consistent then you could
> get your hands dirty and try and find a way to add the offset to
> mytharchive.
>
>   
MythArchive from SVN both trunk and fixes branch will now try to
calculate what the sync offset was before splitting a file and applies
the same sync offset when its remuxed back together. The fixes branch
version does that automatically but in the trunk version you currently
need to change a flag from 'False' to True' to enable it.

> Even with the small amount of transcding I do I've had lots of
> problems.  The main issue seems to be consistency, some recordings
> transcode well, others don't, even though they play well in mythtv.
> My suspicion is that it's all down to errors in the MPEG 2 files so I
> assume transcoding is more critical of errors than watching.
>
>   

That's true. A player may show some artifacts but will usually recover
from stream corruption but many tools that are used to process these
streams can't handle these errors and either carry on blindly using the
corrupt data, give up or sometimes just crash.
  
Paul H.