h264enc for Linux

[rberger]

Originally Posted by nm

MEncoder calls libx264's parameter parsing code, so all parameters are always supported and the syntax is basically the same as in x264.

It even seems to be *exactly* the same up to a few parameters where mencoder has it's own version or plain wouldn't allow the x286 parameter because it could interfere with mencoders own operation, like -passfile for --stats or --progress leading to premature exit since it would mess with mencoders output.

Apart from those few, x264 parameters seem to be handed down by mencoder untouched. The reason they may have different names in the mencoder docs is because some options are implemented with several names in x264 itself, like --filter being the same as --deblock. Apparently, you can always look into common/common.c in the x264 source tree to find out what is what.

Only x264 features that are not supported are the GTK+ GUI and Matroska and MP4 output since that part is handled by MEncoder.

Seems to me all those were never part of x264 proper. It's just an encoder library with a CLI.

However, MP4 output should work with libavformat's muxer (-of lavf -lavfopts format=mp4).

I wouldn't recommend that. As of SVN-r26492, mencoder's MP4 muxing is once again - and likely always has been - broken. It even warns about that.

There's always the possibility to encode video and audio separately with mencoder and mux with gpac/mp4box. This generally works pretty well with PAL sources, but the moment you do IVTC on NTSC material or other frame juggling filtering, you might run into A/V sync problems. In these cases, it really matters what options you feed to mencoder, and it becomes a kind of a trial and error situation.

See e.g. sections 14.1.9 and 14.1.12.1 here:
http://www.mplayerhq.hu/DOCS/HTML/en...dvd-mpeg4.html

and how people already have run into sync troubles
http://forum.doom9.org/showthread.php?t=122018
http://thread.gmane.org/gmane.comp.v...yer.user/48954
http://thread.gmane.org/gmane.comp.v...yer.user/49206

That's one of the reasons encoding on Linux still sucks, that while mencoder seems to be the most advanced full feature transcoding frontend (transcode being another) and often enough working quite well right out of the box, it might always unexpectedly fail in some only slightly subtle situation. MP4 muxing definitely seems to be one of those.

[nm]

Originally Posted by rberger

Seems to me all those were never part of x264 proper. It's just an encoder library with a CLI.

Well, they are part of x264, but not the core library (libx264). GUI and MP4 support need to be enabled when configuring the build (and they need external libraries, of course). Matroska output support is built-in to the CLI.

I wouldn't recommend that. As of SVN-r26492, mencoder's MP4 muxing is once again - and likely always has been - broken. It even warns about that.

Ok, I was actually thinking whether I should say that it might work or if it should work, and I opted for the latter since there were rumors that it now works. I wouldn't recommend using it either if there is doubt.

That's one of the reasons encoding on Linux still sucks, that while mencoder seems to be the most advanced full feature transcoding frontend (transcode being another) and often enough working quite well right out of the box, it might always unexpectedly fail in some only slightly subtle situation. MP4 muxing definitely seems to be one of those.

Avidemux is also worth trying, although it's more GUI-oriented. At least it can output MP4 properly

[rberger]

Originally Posted by nm

Avidemux is also worth trying, although it's more GUI-oriented. At least it can output MP4 properly

Right, thanks for the reminder. I looked at avidemux at one point during the past weeks, but wasn't that much impressed, don't ask me why.

Also, I silently assumed it would link against ffmpeg libraries anyways and hence offer no real functional advantage compared to mplayer. Doesn't seem to be the case though, albeit I'm not yet completely sure about that. If they really maintain own muxers working better than the ffmpeg variants, that would definitely be great (although I have a distinct feeling that linking against gpac would be the best thing all these projects could do, as it appears to be the most advanced and robust mp4 muxer).

Considering avidemux offers a CLI, which escaped me the other day, and they advertise scriptability, I'm almost ready to get a little excited.

If anybody shared their avidemux experiences, especially regarding AVC/AAC coding and MP4 muxing, I would sure appreciate it.

[nfm]

With ihq (Insane High Quality) preset mencoder crashes, uhq preset works fine. @nf and @rberger, thanks for good info, I dumped mp4 in favor of mkv in linux, although I still choose mp4 in windows.

Edit: Looks like mencoder crashes with custom x264 settings too:

#!/bin/bash
#

mencoder "/media/vol05/DVD Rips/MainMovie/INSIDE MAN/VIDEO_TS/VTS_01_2.VOB" -o /dev/null -fps 30000/1001 -ofps 24000/1001 -frames 1000 -vf pullup,crop=720:352:0:64,softskip,harddup -af volnorm=2 -oac faac -faacopts mpeg=4:br=110bject=2 -ovc x264 -x264encopts pass=1:bitrate=1000:ref=5:mixed-refs:no-fast-pskip:bframes=5:b-pyramid:b-rdo:bime:weightb:direct=auto:filter=-2,-1:subme=6:trellis=2artitions=p8x8,b8x8,i4x4,i8x8:8x8dct:me=umh:threads=auto:thread-inputrogress:no-dct-decimate:no-psnr:no-ssim -passlogfile ./h264.stats 2>/dev/null

mencoder "/media/vol05/DVD Rips/MainMovie/INSIDE MAN/VIDEO_TS/VTS_01_2.VOB" -o ./ouput.avi -fps 30000/1001 -ofps 24000/1001 -frames 1000 -vf pullup,crop=720:352:0:64,softskip,harddup -af volnorm=2 -oac faac -faacopts mpeg=4:br=110bject=2 -ovc x264 -x264encopts pass=2:bitrate=1000:ref=5:mixed-refs:no-fast-pskip:bframes=5:b-pyramid:b-rdo:bime:weightb:direct=auto:filter=-2,-1:subme=6:trellis=2artitions=p8x8,b8x8,i4x4,i8x8:8x8dct:me=umh:threads=auto:thread-inputrogress:no-dct-decimate:no-psnr:no-ssim -passlogfile ./h264.stats 2>/dev/null

Screw mencoder, looks like I have do try the old way, ffmpeg | x264.

[rberger]

Throw out 'thread-input' and 'progress', then try again (I mentioned the issue with progress above already).

[nm]

Originally Posted by rberger

Also, I silently assumed it would link against ffmpeg libraries anyways and hence offer no real functional advantage compared to mplayer. Doesn't seem to be the case though, albeit I'm not yet completely sure about that. If they really maintain own muxers working better than the ffmpeg variants, that would definitely be great

They use the lavf MP4 muxer, which works just fine AFAIK. The problem seems to be in MEncoder and its b-frame handling.

(although I have a distinct feeling that linking against gpac would be the best thing all these projects could do, as it appears to be the most advanced and robust mp4 muxer).

I doubt it would improve the situation in this case. GPAC is also a bitch to compile.

If anybody shared their avidemux experiences, especially regarding AVC/AAC coding and MP4 muxing, I would sure appreciate it.

Never had a problem with it for these purposes and this seems to be what most people are now using it for. Personally I prefer MEncoder, but that's because I already know the tricks to make it work.

[nm]

Originally Posted by nfm

Edit: Looks like mencoder crashes with custom x264 settings too:

In addition to rberger's solution, there are a few other things to change:

• When trying new stuff, don't redirect error messages to /dev/null. That is, remove "2>/dev/null" from the end of the command.
  Now you missed the helpful message "Option x264encopts: Unknown suboption progress" because of this.
• Use turbo=1 or turbo=2 for the first pass (or just use CRF instead of bitrate modes)
• Only use AVI output for H.264 if that's the last option. Try encoding audio and video separately (use -of rawvideo for H.264 ES output) and mux the resulting streams with mkvmerge or MP4Box.

Screw mencoder, looks like I have do try the old way, ffmpeg | x264.

How do you intend to do IVTC in that workflow? I'd replace ffmpeg with MEncoder for better filtering, even if you insist on calling x264 separately.

[rberger]

Originally Posted by nm

They use the lavf MP4 muxer, which works just fine AFAIK. The problem seems to be in MEncoder and its b-frame handling.

Which means the same muxer as mencoder. And the latter failed on me with the only x264 option specified being crf, which means zero b frames. Maybe it's mencoder, but frankly it'd surprise me.

Never had a problem with it for these purposes and this seems to be what most people are now using it for. Personally I prefer MEncoder, but that's because I already know the tricks to make it work.

Thanks for the feedback. In the meantime, I checked again and found once more that avidemux is not really what I want, effectively being too gui bound. The quest continues.

[nfm]

I got it to work, taking out 'thread-input' and 'progress' did the trick. Pardon me but I'm very much newbie in encodings, always will be
Regrading the "2>/dev/null", that' why I didn't see errors, now I understand that the standard output was redirected to /dev/null.

Use turbo=1 or turbo=2 for the first pass (or just use CRF instead of bitrate modes)

Will do nm, thanks.
I tried matroska container "-o output.mkv -of lavf" there's no audio when faac is used, there's a problem with audio resampling rate. I still haven't got gpac to compile. I'm no doom9 guru, but isn't there a problem storing b-frames within an avi? Is mencoder affected by this? I think I will go about encoding audio and video separately, and mux them into mkv. Again, nm and rberger, big thanks.

[rberger]

Don't apologize, I'm pretty much new to the subject myself, and we all have to start somewhere and somehow.

Regarding muxing into Matroska (mkv), I believe its not supported by mencoder. It only has a demuxer (i.e. it can read) for that container type, but not a muxer (can not write). If it had one, your command line would anyway look like this "-o output.mkv -of lavf -lavfopts format=mkv". But as said I'm pretty much sure that's not supported.

Look at the output of your mencoder run. At some point early on it likely tells you that it muxes into avi (the default output container format) since your options make no sense to mencoder. That's also likely the cause your sound isn't muxed in, because avi doesn't support AAC.

Regarding b frames and avi I don't know, being not that proficient with this format myself.

[nm]

Originally Posted by rberger

Which means the same muxer as mencoder. And the latter failed on me with the only x264 option specified being crf, which means zero b frames. Maybe it's mencoder, but frankly it'd surprise me.

Yes, MEncoder uses the same libavformat MP4 muxer, but it does work fine when used through ffmpeg and Avidemux. People use it all the time.

Thanks for the feedback. In the meantime, I checked again and found once more that avidemux is not really what I want, effectively being too gui bound. The quest continues.

Well, the only scriptable tool that is better than MEncoder for handling telecine and variable framerate scenarios is AviSynth (since its IVTC filters support writing timecode files). I'd suggest using it through Wine if you have an x86 system.

[nm]

Originally Posted by nfm

I'm no doom9 guru, but isn't there a problem storing b-frames within an avi? Is mencoder affected by this?

Yes, there are problems. If the audio is AVI-compliant, it can be muxed with H.264 video but the A/V sync may be off a little. This depends on how many B-frames the encoder uses in the first batch that it inserts, IIRC. AVI output may be the last option if you have otherwise problems keeping the sync when encoding hybrid NTSC sources (part 24000/1001 fps film, part 30000/1001 fps video).

[buzzqw]

@froggy1

just a simple request

would be possible to start h264enc (and btw xvidenc/divxenc) with only specify the input file ?

just start asking only the input file, then start asking pass/preset/audio/fps.. and so on
would be a little easier

one more: the script can check if a new version is released and download id

thanks

BHH

[microchip8]

Originally Posted by buzzqw

@froggy1

just a simple request

would be possible to start h264enc (and btw xvidenc/divxenc) with only specify the input file ?

just start asking only the input file, then start asking pass/preset/audio/fps.. and so on
would be a little easier

one more: the script can check if a new version is released and download id

thanks

BHH

unfortunately this is not possible at the moment as i'll have to rewrite a lot of stuff and i'm a bit lazy at the moment to do that... as for checking for a newer version, i think i can add this

[buzzqw]

thanks for your answer, i will glady wait :P

BHH

[Lokean]

Originally Posted by rberger

I looked at avidemux at one point during the past weeks,

Also, I silently assumed it would link against ffmpeg libraries anyways and hence offer no real functional advantage compared to mplayer. Doesn't seem to be the case though, albeit I'm not yet completely sure about that.

Avidemux uses an internal copy of the ffmpeg libraries (i.e. it doesn't link to the system ffmpeg).

[blaz]

froggy1's programs use dd or pv to create iso's from a dvd.

I've never heard of pv and am running into walls searching for it.

Can someone (froggy1?) point me to it (on the web ?) and maybe provide any advice as to whether it is preferable to dd.

One problem I'm having is copying older scratched dvds.

[microchip8]

well, i don't know which distro you use, but on openSUSE, pv is in the Packman repository. A search on rpmfind, finds this utility http://rpmfind.net/linux/rpm2html/search.php?query=pv

pv is an alternative to dd and displays a nice progress bar when making an ISO image out of a DVD. As for scratched DVDs, there's little I can do about it, it's beyond my control

[blaz]

Hmmm, I had looked at the pv package on debian but somehow: "PV ("Pipe Viewer") is a tool for monitoring the progress of data through a pipeline" didn't seem like what I was looking for.
But now on installing it and reading the man page, I see that it does a lot more than that.
Will give it a try. Thanks again.

[microchip8]

ChangeLog for version 8.4.4

* Small menu enhancements to the FPS settings
* Fixed wrong explanation for the temporal denoiser
* Removed support for the Sonic and SonicLS audio codecs since they
are experimental and far from complete for daily use
* Updated the man page