On Sun, 2009-08-30 at 22:55 +0200, ezzetabi wrote: Hi,
> >From: Francesco Romani <fromani <at> gmail.com> > >Date: 2009-08-29 15:58:31 GMT (1 day, 4 hours and 29 minutes ago) > > First of all, thanks for the answer. You're welcome :) > I thought that transcode did duplicate or drop frames as needed, [...] It should, actually. > Here is the log: > - There are some ugly-looking warnings from alsa, what does it mean? It means that transcode was too quick (or too slow, can't remember yet) in draining the ALSA audio buffer. import_alsa is still pretty dumb (empowering is planned but still to come) so the message could pop out easily (and in facts it often does) but most of time AFAIK the practical effects of such warning are negligible. Summary: if the audio sounds good, ignore those warnings. > - There are also warning about bad pixel formats, but it does not seem > a problem. Yes. import_v4l2 tries to find a suitable pixel format and it eventually succeeds. Normal business here. > - You can see that there are no duped or dropped frames. That's the real problem so far. > - I used tcaud only because ffmpeg says it is a good idea. It is, at least for better forward compatibility. [...] > [transcode] encoded 154499 frames (0 dropped, 0 cloned), clip length 6179.96 s > > I am starting to lose hope, maybe this dc60+ device is simply unusable. > Any insight? Let's assume the device (and it's driver) are sane and this problem can be solved (in some way) in software. Are you interested in doing some experiments? I can't guarantee the final result, but I'll happily provide custom variants of import_v4l2 (which, if proven good, will of course be merged into the mainline) and support. I'll take some time (= days at very least), mostly because my spare time it's low. Bests, -- Francesco Romani // Ikitt http://fromani.exit1.org ::: transcode homepage http://tcforge.berlios.de ::: transcode experimental forge
