On 1/6/06, Geoffrey Hausheer <[EMAIL PROTECTED]> wrote: > > I still have some recorded shows with a *really* bad signal. I'll try > > to transcode those shows too, but I don't believe mythtranscode can > > deal with that bad streams (missing picture and sound for seconds). > I'd be interested in how things go. I think even really bad streams > should process for the most part. There are conditions which wouldn't > work (specifically if we got more than 200 video frames without ever > seeing an audio packet, or if the audio and video streams themselves > have different timestamps. But other than that, I think we should be > able to handle most streams, and if not, I'd like to try to fix it.
Heh, ok, just for you ;) I've tried to transcode a rather bad file, it
only fails when -l is used. Used revision:
:2006-01-06 17:54:23.335 mythfrontend version: 8513M, 0.19.20051208-1
www.mythtv.org
mythtranscode -c 1065 -s 2005-12-22T23:45:00 -l -v all > /tmp/transcode.log
2006-01-06 17:32:23.026 Stream #0.2[0x194]: Data: 0x0000
2006-01-06 17:32:23.027 Skipping unsupported codec 2 on stream 2
2006-01-06 17:32:23.030 #0 PTS:23:05:11.199 Delta: 0.0ms queue: 22
2006-01-06 17:32:23.032 #1 PTS:23:05:11.181 Delta: 17.8111ms queue: 2
2006-01-06 17:32:23.190 Deadlock detected. One buffer is full when
the other is empty! Aborting
Log -v all is attached.
Adam
transcode.log.tar.bz2
Description: BZip2 compressed data
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
