From Issue #150October 2006
mplayer -ao pcm -vc null -vo null max.dv
MPlayer SVN-r29237-4.4.1 (C) 2000-2009 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.
File not found: 'max.dv'
Failed to open max.dv.
Exiting... (End of file)
Also tried sudo with the same result.
Son :) max.dv is the name of the file you're processing. That the name of his (author's) file. Maybe your file has a different name?
Why don't you try replacing the max.dv with the name of your file!?
It is very pleasing to see solid and rapidly growing Free Software / open source support for H264 video encoding standard. There are multiple options for doing H264 under GNU/Linux. The completeness of implementation is also getting better - for example handling of interlaced video had been finally improved in 2009 for libavcodec - it decodes *supposedly* H264 specification compliant Mobilygen MG1264 audio/video codec chip produced streams now - you can check MG1264 MP4 samples here - http://www.linuxmedialabs.com/LMLCD/MG1264samples/ - if D1 (full resolution) samples are NOT playing back for you properly it means that your version of libavcodec / mplayer is not recent enough :-) These are full D1 2000 Kbps samples and one 500 Kbps CIF sample, which should playback well everywhere, except from QT player maybe.
Although this article shows the way to use H264 software encoding based on x264 tool, I think it's a good place to ask author and readers about other known Linux H264 hardware devices - for either PCI / PCI-E bus or USB bus - any H264 done in hardware and usable under Linux for integration - with GNU/GPLed drivers like LML26415 PCI card has, or even binary-only non-free drivers or transparent interfaces like RTP/RTSP streams etc. We are building various multi channel video processing systems and having additional choices for H264 standard (720x480/576) and especially high definition video (1920x1080) done in *hardware* for very low CPU overhead is very important. Although hardware design and OEMing is fun thing to do and we enjoy every moment of it :-), sometimes it's desirable to use something that is already available - if only it's Linux friendly. I would appreciate any feedback here or sent to my email email@example.com
I have one question. Is posible to improve the quality of a avi raw, compressing this in mp4? I have seen in some places taht people download the avi raw and convert it to mp4 codec and the result is better than the source (avi raw). I tried to do this with x624 and similar options like you, but the result is the same than the raw.
Thanks and sorry for my english :S
no it is not unless you use some filters, but you have to remember that h264 and xvid aren't lossless codecs so each time you re-encode something using these codecs you lose quality
What happened to the two wires which were crossing the top of the clock tower ? You can see them in the DV image but missing in the xvid and x264.
I generally use mencoder to convert interlaced 720:480 m2v transport streams to x264 AVIs. I would like to use this method to make Quicktime friendly files, but mencoder says "Skipping Frame!" (which it always does with this video source) which results in mp4 files in which every other frame is blank. Is there an easy way around this? I've played around with the usual pullup and deinterlace filters that I use to make AVIs, but no luck...
A solution is to use -of rawvideo with mencoder's native x264 encoder and then mux it all up with MP4Box... If I use the same quicktime-friendly settings I get a quicktime-friendly MP4 out in the end.
I enjoyed your article, but I think there is a subtle problem with your examples. You start with a DV stream whose natural resolution is 720x480. This seems to be 3:2 aspect ratio, but the stream is designed to play back at 4:3 aspect ratio or 640x480 resolution. This has to do with the legacy of NTSC video having more pixels per inch along a horizontal scan line than vertically across scan lines. I'm not sure, but I don't think H.264 has an aspect ratio flag to account for this issue (MPEG-2 does have such a flag). As a result, I think all of your H.264 output files are stretched horizontally by 720/640. To get the correct result, you probably have to tell the encoder to output a file with a 4:3 aspect ratio. You don't seem to be doing that in the examples.
You can set this ratio by specifying the "sample aspect ratio" to x264 using --sar, and also by specifying the "pixel aspect ratio" to MP4Box using :par. I believe these both effect the aspect ratio in the same way. The calculation of the aspect ratio will depend on the properties of the source video clip. More discussion of aspect ratios here. H.264 does have support for aspect ratio signalling, but it of course depends on the decoder to interpret it correctly. For small web clips, it is often best to just resize the source video so that the aspect ratio is 1:1, which will be displayed correctly by any decoder which understands h264.
As one example, Quicktime 7 will not respect these aspect ratio settings, and part of the article deals with issues of compatibility with Quicktime. Although you can set the aspect ratio in the .mp4 file, it will still appear incorrectly when played in the Quicktime player. To fix this problem, open the properties of the video file in Quicktime and manually specify the correct horizontal and vertical dimensions, then save the file (the ability to do this may be restricted to Quicktime Pro). This (non-standard) method will correct the aspect ratio (for Quicktime-playback only).