Difference between revisions of "Talk:V4L capturing"

From LinuxTVWiki
Jump to: navigation, search
m (more pedantic wording?)
(Live x264 capture comparison is hopelessly bogus: -- response)
Line 10: Line 10:
   
 
Sorry if this sounds harsh. I hope you will read this as constructive criticism from someone who's bad at diplomacy (me). What you're doing is valuable but the details really need work.[[User:Snacky|Snacky]] 22:44, 27 April 2006 (CEST)
 
Sorry if this sounds harsh. I hope you will read this as constructive criticism from someone who's bad at diplomacy (me). What you're doing is valuable but the details really need work.[[User:Snacky|Snacky]] 22:44, 27 April 2006 (CEST)
  +
  +
Hi Snacky,
  +
  +
Thanks for the feedback, which is very useful for the wiki. I've corresponded with the transcode developers and there's a lot that's not been properly implemented yet, starting with a separate x264 export module. I'm actually thrilled transcode can do it at all -- few people use it for v4l and the results are pretty good. With a proper v4l export module, we can expect much better results, and a much higher level of control.
  +
  +
As for mencoder, nobody I've asked (and I've really asked around on the different projects) have been able to figure out why x264 files encoded with mencoder won't stream with vlc -- it could be a local problem, but so far I don't have any firm reports of positive cases. So, test, tell us how you tested, and tell us what you find.
  +
  +
x264 is still making its way into the codebases of the various frontends and implementations are not perfect. It's worth testing and seeing what you actually get, and reporting bugs.
  +
  +
Liontooth, 20 May 2006.

Revision as of 21:16, 20 May 2006

Live x264 capture comparison is hopelessly bogus

The options used by each frontend (ffmpeg, mencoder, transcode) aren't even remotely comparable, mainly due to hidden defaults you probably weren't aware of.

"efficiency" and "file size" are almost completely interdependent (there is an extremely strong inverse correlation) so it makes no sense to have both columns. Try holding one of the two constant. I suggest holding "file size" constant since it's the easiest way to test.

All of these frontends use x264's ratecontrol, so the fact that you didn't get good results with transcode indicates you don't know how to use transcode. Neither do I, but I'm not the one who presumes to write a guide on it ;-)

I think it is safe to assume that most of the bullet points are a product of not knowing how to use each frontend.

Sorry if this sounds harsh. I hope you will read this as constructive criticism from someone who's bad at diplomacy (me). What you're doing is valuable but the details really need work.Snacky 22:44, 27 April 2006 (CEST)

Hi Snacky,

Thanks for the feedback, which is very useful for the wiki. I've corresponded with the transcode developers and there's a lot that's not been properly implemented yet, starting with a separate x264 export module. I'm actually thrilled transcode can do it at all -- few people use it for v4l and the results are pretty good. With a proper v4l export module, we can expect much better results, and a much higher level of control.

As for mencoder, nobody I've asked (and I've really asked around on the different projects) have been able to figure out why x264 files encoded with mencoder won't stream with vlc -- it could be a local problem, but so far I don't have any firm reports of positive cases. So, test, tell us how you tested, and tell us what you find.

x264 is still making its way into the codebases of the various frontends and implementations are not perfect. It's worth testing and seeing what you actually get, and reporting bugs.

Liontooth, 20 May 2006.