Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
As mentioned in an earlier thread, I've been playing around with a DVB-S card for about a week. I've worked out most of the initial problems I ran into, but now another one has cropped up.
Some broadcasts use H.264 video, rather than the more common MPEG-2. MPlayer plays it, but the audio and video go badly out of sync. It looks like the video is only running at half speed. I don't think this is due to a lack of CPU or video card power, because top shows only 76% utilization, and the desync still happens even if I disable video output (-vo null), or even if I transcode with MEncoder (the resulting file is desynched).
If it matters, the video I'm trying to watch is in 1080i resolution at 29.97 fps.
Those specs should be enough, this is weird. Have you tried playing around with the nvidia settings (e.g. Anti-aliasing and stuff like that)? I would not know of anything else you could possibly try, sorry. One moment, maybe you need a realtime kernel, I need one of those because I do audio recording, with ardour. Maybe that could help? The latency on stock linux kernels is too high, maybe that is a possible solution. Then again, I have a core2quad 2.3Ghz, 6Gb Ram, Ge9800GT, and my work linux has an ordinary debian kernel, I sometimes don't bother rebooting into my "home" linux and watch tv over ADSL. I have HD content I watch with vlc, have not seen this happen on my system, it should technically be the same thing, hm. When I watch HD content fullscreen, my CPU use is at ~35%.
Haven't done much of anything with the video driver config other than setting up my dual-head display, but as I mentioned in the original post, I don't think the video card or driver has anything to do with this, since I can play HD MPEG-2 video just fine, and this problem occurs even when I disable video output.
I just tried VLC and that actually seems to be even worse than mplayer. CPU usage goes up to about 104% according to top and the video plays at about 2 FPS. During one test it actually crashed X, with dmesg showing several "machine checks".
Are you running a kernel optimized for an i386? or 686 or better?
Distro version of mplayer? Or compiled from source?
Does -noaudio for mplayer make a noticeable difference (cpu usage)? If it's AAC audio, some implementations of it are in a lot of flux and some are not optimized well. To the point of almost taking longer to decode the audio than it does to decode the video.
* the latest ffmpeg gives garbled video output. SVN r20373 works better.
* I tried building a 32-bit ffplay binary in a chroot, and that uses much less CPU (102% vs. 130%).
* Building a 32-bit mplayer seems to make no difference vs. 64-bit.