[mythtv] Enabling mythtranscoder

[Craig Longman]

Geoffrey Hausheer wrote:

>On Sat, 31 May 2003 01:57:06 -0400, "Craig Longman craigl-at-begeek.com
>|mythtv/1.0-Allow|" > geoffrey, i'm working on many updates to the
>transcoder, it had a few 
>  
>
>>problems with it, as well as some enhancements that were needed.  i'm 
>>just wrapping up the changes to support hardware encoded to 
>>mpeg-4/rtjpeg, and then can start working on converting from mpeg-4 and 
>>rtjpeg.  it shouldn't be too much more difficult, now that i have the 
>>structure i need, although the handling of 'raw' stuff is handled quite 
>>differently for some reason, so it may give me trouble.
>>    
>>
>
>Actually, I was talking about making changes to the transcoder-thread
>(which is also what Isaac was referring to).  Are you making any changes
>there?  The only backtrace I've seen in the mailing-list logs is because
>the transcoder is getting bad program information.  Haven't looked into
>it yet to figure out how that can happen, but I wasn't planning on
>touching the Reencode or mythtranscode stuff at all (if that fails, it
>causes no harm to the system, so it's not as show-stopper)
>
the main crashes i saw were related to the program info (as you 
mention), which is now fixed, and some objects not being initialized in 
nupplevideorecorder (the commercial detection and the rtjpeg comperssor 
i think was the other one).  the first one is fixed, the second i still 
have to fix and/or ask what issac et. all wants to do about it.

>Anyhow, Reencode file certainly could use a serious amount of work, and
>if you are doing it, that is great.
>
yes, primarily getting cutlist support working.  sounds simple, but 
getting the audio and video in sync, and working even when there are 
breaks in the audio has been tough.  i just really need to make sure 
that the time estimates of the encoded files works properely, i seem to 
have some trouble with that still.

>The 'raw' stuff is handled
>differently because there is no reason to degrade audio quality if we are
>transcoding from mp3->mp3 by decoding and encoding it again.
>
yes, i understand that.  but its a completely different code path, so 
getting the audio/video syncing fixed in that is more tough.  it would 
be simplier/more maintainable if the data was simply retrieved as raw or 
decoded first, then procesed through the same path.  i might try and do 
that, but i'm not sure i have access to the necessary info, which is 
maybe why its done the way it is.

i use a hardware card, so i'd like to get it to the point where i can 
mix'n'max also, re-encode the video to mpeg-4, but keep the layer2 audio 
stream untouched, although i'm not sure the player can handle that.  i'm 
hoping that the lame libs can deal with layer2 as well as layer3, but 
that's going to be in a slightly later release... ;-)

cheers,

    CraigL->Thx();