x264 and mencoder, mplayer not playing nice with x264. [Archive]

Thasp

11th February 2007, 00:35

emerging mplayer in gentoo with x264 use flags, even after compiling x264, doesn't recognize x264 or -x264encopts.

Compiling it by hand with ./configure --with-x264libdir=/usr/local/lib && make && make install gives me no errors, but mplayer and mencoder don't actually show up, or work. Compiling by hand with ./configure gives me

libmpcodecs/libmpencoders.a(ve_x264.o): In function `x264enc_set_param':
ve_x264.c:(.text+0x513): undefined reference to `x264_param_parse'
ve_x264.c:(.text+0x627): undefined reference to `x264_param_parse'
ve_x264.c:(.text+0x63b): undefined reference to `x264_param_parse'
libmpcodecs/libmpencoders.a(ve_x264.o): In function `config':
ve_x264.c:(.text+0x799): undefined reference to `x264_param_parse'
collect2: ld returned 1 exit status
make: *** [mencoder] Error 1

I've been googling and reading man pages for over an hour, and I'm nowhere ahead of where I started. I know what settings I want to use and the command line for them but they are no use if I can't move past these errors. :( No man page, or FAQ seems to give me any relevant information.

I tried following the instructions on the bottom of this page, to no avail http://www.mplayerhq.hu/DOCS/HTML/en/video-codecs.html#codec-x264-encode

11th February 2007, 10:54

Compiling it by hand with ./configure --with-x264libdir=/usr/local/lib && make && make install gives me no errors, but mplayer and mencoder don't actually show up, or work.
This installs the mplayer and mencoder binaries to /usr/local/bin. Have you tried running them from there: /usr/local/bin/mplayer? If that works but simply calling mplayer doesn't, /usr/local/bin is not in your PATH.

You could also take a look at the ebuild and see how it tries to compile with x264 support. Send a fix or bug report to the package maintainer.

SatansChild

11th February 2007, 14:41

Try using the berkano overlay instead of compileing from the standard portage builds, this will pull the most recent code from cvs/svn repositories. Last time I checked the builds gentoo gave you by default for x264 where missing features (the one I wanted was multithreading).
x264 mplayer/mencoder & ffmpeg all tend to be interdependant so you need to compile them all from source coming from the same or close to the same date.

Thasp

14th February 2007, 08:59

Thanks for your advice, things work fie after compiling them myself. I ran svn on ffmpeg, then x264, then mencoder to get the latest builds and compiled them myself. I had a feeling I should have used slackware as I had in the past, the only thing I trust to compile things is myself.. but gentoo makes certain compilations easy, which was why I used it.

I still can't get two things working, though. I can have RC5-72 use both cores(distributed computing thing), but not x264. I set the threads to 0, auto, 2, 10, but it only uses one core. :(

Secondly, I did read the manpage for mencoder but I am very confused on how I would specify my own decimate value, opposed to telling mencoder how it should search for frames to be cut. I usually run selecteven to notch a source down to 29.970 FPS, then decimate by 5 to knock it down to 23.976 FPS. With other sources, I just use the decimate option, and I always have telecide after selecteven in my script. I am not sure how to import this into linux encoding, but I hope to learn.

14th February 2007, 10:30

I still can't get two things working, though. I can have RC5-72 use both cores(distributed computing thing), but not x264. I set the threads to 0, auto, 2, 10, but it only uses one core. :(
Configure x264 with --enable-pthread (see ./configure --help for other build settings).

Secondly, I did read the manpage for mencoder but I am very confused on how I would specify my own decimate value, opposed to telling mencoder how it should search for frames to be cut. I usually run selecteven to notch a source down to 29.970 FPS, then decimate by 5 to knock it down to 23.976 FPS. With other sources, I just use the decimate option, and I always have telecide after selecteven in my script. I am not sure how to import this into linux encoding, but I hope to learn.
If your source is telecined, you should use one of the pullup/IVTC filters that MPlayer/MEncoder offers. See: http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-telecine.html
If the source is interlaced, use -vf pp=fd, -vf pp=lb or for better quality, -vf yadif=3:1,mcdeint=0:1:10,framestep=2 (bottom field first) or -vf yadif=3:0,mcdeint=0:0:10,framestep=2 (top field first).

Thasp

15th February 2007, 04:35

Thanks, I can't believe I forgot to check the configure options.

Right now, for a 1080i source I have telecide()
decimate(cycle=5) in my script before whatever resolution resize filter I put in, and for a 720p source I have selecteven()
telecide()
decimate(cycle=5) before whatever resize filter I choose to put in. I've always been confused about what the telecide part did - I know decimate takes out one frame every 5, and selecteven is like decimating by two. I think I should read up more on this, if I understood what my avisynth scripts were doing better, I'd probably understand the mencoder man pages better.

edit: I deleted every x264 lib and bin I could find with slocate, and I could still encode x264.. I recompiled it after this with multiple threads enabled, set threads =3, then 2, then 20 just for the hell of it and I still get 97-100% usage on one CPU core. It shows mencoder, not x264, as a process in top. Maybe I should be compiling mencoder/mplayer to support multiple CPUs...?

edit 2: I now have multithreaded working, just switched a few things around in the command line. :)

15th February 2007, 09:57

Right now, for a 1080i source I have telecide()
decimate(cycle=5) in my script before whatever resolution resize filter I put in,
For telecined 1080i, you should use pullup like the MEncoder documentation suggests (this is the same thing you do with the AviSynth script). If the original source is not film but interlaced video, you'll need to deinterlace instead of doing inverce telecine.

and for a 720p source I have selecteven()
telecide()
decimate(cycle=5)
To do this in MEncoder, try: -ofps 24000/1001 -vf framestep=2,decimate=1:1000:1600:.001 or perhaps this: -ofps 24000/1001 -vf decimate=2:1000:1600:.001. I have never encoded 720p60 sources, so I don't know if either of these work well. You may need to search around for better suggestions. Again, if the original source is not film, the actual framerate is probably 60 fps and you can either encode that directly or drop every other frame with -vf framestep=2.

Thasp

15th February 2007, 23:09

Thanks a lot for all your help.

Thasp

16th February 2007, 23:06

I have almost everything working now. All of my content was film, not video, so I used this line for a one pass test encode to see if I received acceptable output(the quality level will be for my first pass, with higher quality settings for the second).

Now my only issue is this error doing twopass encodes.. x264 [warning]: Error: 2pass curve failed to converge
x264 [warning]: target: 3308.00 kbit/s, expected: 2310.60 kbit/s, avg QP: 10.0037
x264 [warning]: try reducing target bitrate or reducing qp_min (currently 10)

17th February 2007, 12:06

What kind of a sample did you try to encode? Perhaps it was too short or too compressable (qp_min=10 was not low enough). Did the first pass look fine and did it reach the bitrate you asked for?

Thasp

17th February 2007, 19:34

I forgot to edit my post, I fixed that by defining the bitrate in the first and second pass.

Now my only issue is muxing the mkv file that it spits out with AC3 audio to matroska. I get errors about it being VFW, I have to switch it to AVC, they give an mp4box command for me to use. I installed as many mp4 tools as I can and the command they tell me to use starting with mp4box doesn't work.. it's weird.

I can force it to mux the output video with the audio to mkv, but is this bad in any way?

19th February 2007, 12:08

I can force it to mux the output video with the audio to mkv, but is this bad in any way?
Yes, sync will not be correct (it depends on the number of b-frames) and the file might not be compliant in the future.

However, recent versions of mkvmerge should support better importing of H.264 streams (http://forum.doom9.org/showthread.php?t=120648) from AVI container, and from an elementary stream file (.264). Update to MKVToolNix 2.0.0 and it should work fine without having to use MP4Box. If it still complains about AVI, try writing an elementary stream with MEncoder (-of rawvideo -o output.264).

Thasp

20th February 2007, 00:40

the new mkvmerge gives this

Error: 'close1.mkv' track 0: This AVC/h.264 contains frames that are too big for the current maximum NALU size. You have to re-run mkvmerge and set the maximum NALU size to 3 for this track (command line parameter '--nalu-size-length 0:3').

I followed the instructions and got a file that played in media player classic, that crashed vlc, with perfect sync.

That mencoder line you gave, do I use that while I am encoding or run that after the finished file is encoded? I have been telling mencoder to output to mkv this whole time.

Thanks again.

20th February 2007, 01:18

That mencoder line you gave, do I use that while I am encoding or run that after the finished file is encoded? I have been telling mencoder to output to mkv this whole time.
MEncoder can't output to MKV. It writes AVI files unless you tell it to do something else with the -of parameter while encoding.

Thasp

20th February 2007, 02:52

Using -of the way you told me gets an odd error.

My command line was mencoder -o finaltest.264 -of finaltest.mpg -nosound -oac copy -vf pullup,softskip,scale=1280:720 -ovc x264 -ofps 24000/1001 -x264encopts subq=1:partitions=all:8x8dct:me=umh:frameref=1:bframes=3:b_pyramid:weight_b:bitrate=3308:threads=0:pass=1

Error was

MEncoder dev-SVN-r22215-4.1.1 (C) 2000-2006 MPlayer Team
CPU: Dual Core AMD Opteron(tm) Processor 165 (Family: 15, Model: 35, Stepping: 2)
CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2

Option of: Unknown suboption finaltest.mpg
Error parsing option on the command line: -of

Exiting... (error parsing command line)

This line

mencoder -of finaltest.mpg -o finaltest.264 -nosound -oac copy -vf pullup,softskip,scale=1280:720 -ovc x264 -ofps 24000/1001 -x264encopts subq=1:partitions=all:8x8dct:me=umh:frameref=1:bframes=3:b_pyramid:weight_b:bitrate=3308:threads=0:pass=1

Gets me

MEncoder dev-SVN-r22215-4.1.1 (C) 2000-2006 MPlayer Team
CPU: Dual Core AMD Opteron(tm) Processor 165 (Family: 15, Model: 35, Stepping: 2)
CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2

Option of: Unknown suboption finaltest.mpg
Error parsing option on the command line: -of

Exiting... (error parsing command line)

If I output to 264 without using the -of option, is it still writing to avi?

20th February 2007, 09:58

No, you need to type -of rawvideo without substituting rawvideo. -of selects the output format, like it is explained in the manual page. To see the possible values, run mencoder -of help.

So, your command line would be:
mencoder finaltest.mpg -o finaltest-pass1.264 -of rawvideo -nosound -vf pullup,softskip,scale=1280:720 -ovc x264 -ofps 24000/1001 -x264encopts OPTIONS:turbo=2:pass=1
mencoder finaltest.mpg -o finaltest.264 -of rawvideo -nosound -vf pullup,softskip,scale=1280:720 -ovc x264 -ofps 24000/1001 -x264encopts OPTIONS:pass=2
Other notes:
You had -nosound and -oac copy in the same command line. They are mutually exclusive, so -oac copy is ignored. Anyway, -oac copy could not be used with -of rawvideo since the video elementary stream can't contain an audio track.
It is easier to use the turbo switch in x264encopts to switch off unnecessary features for the first pass than it is to write two different sets of parameters manually.
I recommend CRF encoding instead of running two passes, unless you need to fit the encodes to a specific filesize

Thasp

21st February 2007, 01:56

Thanks for the info. It's hard to find everything in the manual page. :( I've been getting useful info on other things, but it's easy(for me, at least) to miss stuff in such a large manual.

I need the encodes to be specific filesize to backup to DVDR - my HTPC box is full. :(

I tried running both passes with this subq=6:trellis=2:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid:weight_b:bitrate=3308:threads=0

It took over eight hours.. twice the time the desktop takes(and the desktop is only 25% faster CPUwise in encoding with the same parameters), the desktop uses megui + HQ slow/slower profiles. The HQ slow profile looked a lot better than the settings above. It was closer to the source - the mencoder one seemed like a TV in best buy with its color cranked up all the way to impress customers.. too much. Side by side, it's subjective, but when aiming for transparency to the original, in an ABC test(original, megui, mencoder with same filesize on megui/mencoder), mencoder got stomped. :( Is there anything glaringly wrong with the above settings? I am confused as to what makes the encode worse with mencoder, perhaps I am missing a crucial option somewhere?

Thanks again for all your help.

21st February 2007, 09:02

I tried running both passes with this subq=6:trellis=2:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid:weight_b:bitrate=3308:threads=0

It took over eight hours.. twice the time the desktop takes(and the desktop is only 25% faster CPUwise in encoding with the same parameters), the desktop uses megui + HQ slow/slower profiles.
Was it multithreaded (used all of the available CPU time, if you have a dual core system)? Did you specify turbo=1 or turbo=2 for the first pass? Also note that HQ-slow(er) profiles have trellis=1, not 2, and HQ-slow has only 3 reference frames. Convert the MeGUI profiles to corresponding MEncoder settings if you want to compare encoding speed.

The HQ slow profile looked a lot better than the settings above. It was closer to the source - the mencoder one seemed like a TV in best buy with its color cranked up all the way to impress customers.. too much. Side by side, it's subjective, but when aiming for transparency to the original, in an ABC test(original, megui, mencoder with same filesize on megui/mencoder), mencoder got stomped. :( Is there anything glaringly wrong with the above settings? I am confused as to what makes the encode worse with mencoder, perhaps I am missing a crucial option somewhere?
I don't think the difference is in x264 encoding options, but in preprocessing or perhaps in colorspace conversions if the contrast/brightness was different. Could you post screenshots of the differences, or even better, upload video clips to RapidShare or some other file hosting service?

Thasp

21st February 2007, 21:45

Both computers have a dual core CPU, and for both x264 uses at least 70% CPU, to 99 depending on the pass and the time of encoding. I didn't specify turbo for either.

I would upload clips or show screenshots, but wouldn't it be copyright infringement to do this with TV shows from the last year? Or is there a limit to how long the clip can be? Are there any mpeg2 HD clips I can use for testing?

The contrast/brightness was the same, it was just the color. So much red where it shouldn't be.

21st February 2007, 22:33

I would upload clips or show screenshots, but wouldn't it be copyright infringement to do this with TV shows from the last year? Or is there a limit to how long the clip can be? Are there any mpeg2 HD clips I can use for testing?
Yes, it could be interpreted as copyright infringement, but it is quite common to post frames or short sequences (10 seconds or so) for testing purposes. I haven't heard of anyone being sued for that, but do what you think is appropriate.

Public domain or Creative Commons -licensed HD video is a bit hard to find, but this blog contains links to some useful clips: http://opensourcevideo.blogspot.com/
(note that the 720p files are progressive 30 fps video, so no need to do IVTC or decimate).

The contrast/brightness was the same, it was just the color. So much red where it shouldn't be.
That is very strange. Does the source look fine if you play it back with MPlayer and the same filters that you use with MEncoder? How about without filters? Post a bad frame and the corresponding source frame to ImageShack.

Thasp

22nd February 2007, 00:40

If a moderator finds this unfit for posting, please feel free to delete link to the the clip upon reading my post - my intention was never to draw attention or trouble.

The reason I used the more reference frames and higher trellis on mencoder was to see if it did worse with "better" settings. I evened it out a bit more, 3 reference for mencoder, trellis 1

This is the original ten second clip.

removed

Here is megui @ 3000 kbps, two pass, HQ slow

removed

Here is mencoder with the following settings

mencoder -of rawvideo testforbadmencoder.mpg -o testforbadmencoder.264 -nosound -vf decimate=2:1000:1600:.001 -ovc x264 -ofps 24000/1001 -x264encopts subq=6:trellis=1:partitions=all:8x8dct:me=umh:frameref=3:bframes=3:b_pyramid:weight_b:bitrate=3000:threads=0:turbo=2:pass=1

mencoder -of rawvideo testforbadmencoder.mpg -o testforbadmencoder.264 -nosound -vf decimate=2:1000:1600:.001 -ovc x264 -ofps 24000/1001 -x264encopts subq=6:trellis=1:partitions=all:8x8dct:me=umh:frameref=3:bframes=3:b_pyramid:weight_b:bitrate=3000:threads=0:pass=2

removed

Tell me when you've grabbed them so I can delete, and thanks again.

22nd February 2007, 01:13

The reason I used the more reference frames and higher trellis on mencoder was to see if it did worse with "better" settings. I evened it out a bit more, 3 reference for mencoder, trellis 1
I checked the settings from the files (strings -100 x264-encoded_file) and the remaining differences are: me_range=16 (12 in HQ-slow), deblock=0,0 (-2,-1 in HQ-slow) and direct_pred=spatial (auto in HQ-slow).

Tell me when you've grabbed them so I can delete, and thanks again.
No problem, got the files. However, I don't see any difference in color levels. Haven't checked with a comparison tool, but I really don't see a difference even when comparing the two side-by-side, frame-by-frame. Perhaps you could post a screenshot of what it looks like on your end? Did you use the same player to play the files on the same system?

Edit: If you are playing two videos at the same time, note that only one window can use overlay and the other will use a video blitter engine. These two methods usually have different color level settings that can be tweaked through display driver settings (at least for overlay -- blitter levels are usually not tweakable).

Thasp

22nd February 2007, 01:42

Wow, neither do I. Something had to have changed.

I just began using the -of rawvideo option properly for this encode - perhaps that made the difference. I will do the full file over again with those options and see how it comes out.

I will be happy if that is all it takes to fix the problem. Thanks a lot for all the advice and for checking out the files.

P.S.

Jack is badass. :D

Thasp

27th February 2007, 19:56

Now I have a new problem.

I tried adding --default-duration 0:24000/1001fps to my mkvmerge command line. I have mencoder outputting plain rawvideo streams, not avi files. The audio is blatantly out of sync in both players, the video streams show up at 25 FPS when I calculate total frames in file by length of the file in seconds.

edit: I just tried writing an avi stream to fix this issue - no dice. :( the new mkvmerge won't even encode it at all, it says it needs a size of 0:3 and if I set it to 0:3 or 0:4, it still complains about that nonsense.

edit 2: I just tried using MP4Box to turn the original stream into an MP4, then the MP4 into an mkv with the ac3 - no dice there either.

edit 3: After calculating the frames and the time vlc/mpc display, it is obviously trying to play it back at 25 FPS in spite of me telling it otherwise.

edit 4: (lots of edits :)) I just tried telling it to write only the video to mkv with the 24/1001 FPS option, in both command line mkvmerge in linux and GUI mkvmerge in windows - this is going nowhere. mkvmerge blatantly ignores my setting of framerate.

edit 5: I tried setting the framerate to 23.97650 with mp4box, then muxing the mp4 with the ac3, but the mp4 still went at 25 FPS. The command lines I posted above should be for 23.976 FPS video. I don't know why all of these programs insist on shoving PAL on me, but it's becoming a real pain in the ass.

To test, I tried using quenc and ifoedit with this and making a DVD out of it, that worked in an xbox, and it synced up perfectly.

28th February 2007, 08:06

edit 5: I tried setting the framerate to 23.97650 with mp4box, then muxing the mp4 with the ac3, but the mp4 still went at 25 FPS. The command lines I posted above should be for 23.976 FPS video. I don't know why all of these programs insist on shoving PAL on me, but it's becoming a real pain in the ass.
Have you tried muxing the raw .264 stream to MP4 with MP4Box -fps 23.976 -add in.264 out.mp4. Then mux that to Matroska with mkvmerge. Use mkvinfo to see that the framerate is correct. Then mux the AC3 audio in. After this the framerate should be fine, but there may still be small sync issues due to the way you drop frames in MEncoder.

Thasp

28th February 2007, 20:14

I did that. I tried muxing the audio in the mp4, and muxing the mp4 with no audio(that I made from the rawvideo) with the ac3 in mkvmerge.. nothing does it. -noskip doesn't do a thing either.

28th February 2007, 20:40

Thasp

28th February 2007, 21:12

I only notice sync issues in large clips. Even 5 minute clips are fine, but 43 minute videos are disgusting.

I am trying mpeg2 as a codec now, to see if the issue is in the x264 encode or the pre-feeding-it-to-x264 processing.

edit: Confirmed it. regardless of what codec I use(xvid, x264, or mpeg2), and how I mux it(mp4, mkv), there are still sync problems. I read the documentation, I read the MAN pages, I searched several forums, but now I am out of time and patience to continue playing the "find the solution to the obscure linux problem game." :( Hopefully I can get VMware working on that computer so I don't have to deal with mencoder's nonsense.

28th February 2007, 23:51

Ok, then the source of the problem is probably the decimate filter. It would be nice if someone wrote a real 60p 3:2 pulldown filter, but in the meantime we need to use other tricks. Maybe this would work better: http://www.pchdtv.com/forum/viewtopic.php?p=9667#9667

Thasp

28th February 2007, 23:56

I went back on my word 100% soon after having hit "post quick reply" - I am trying again

mencoder -of rawvideo 24.mpg -o 24.264 -noskip -nosound -vf decimate=2 decimate=5 -ovc x264 -ofps 24000/1001 -x264encopts subq=6:trellis=1:partitions=all:8x8dct:me=umh:frameref=3:bframes=3:b_pyramid:weight_b:bitrate=3134:threads=0:pass=1:turbo=2

mencoder -of rawvideo 24.mpg -o 24.264 -noskip -nosound -vf decimate=2 decimate=5 -ovc x264 -ofps 24000/1001 -x264encopts subq=6:trellis=1:partitions=all:8x8dct:me=umh:frameref=3:bframes=3:b_pyramid:weight_b:bitrate=3134:threads=0:pass=2

mkvmerge 24.264 24.ac3 -o 24.mkv

I don't know if that does it. it gave no errors, so maybe it will work? Probably not - so I will add a second encode in using that one you linked to. I bookmarked it before I gave up, but since someone else is using it, I will try it now. It would be awesome to wake up and find a working encode.

Thanks again.

Thasp

1st March 2007, 12:13

I tried doing a quick video encode with this just to check sync mencoder -of rawvideo 24.mpg -o 24betterfilter.264 -noskip -nosound -vf tinterlace,pullup,softskip -ovc x264 -ofps 24000/1001 -x264encopts subq=1:8x8dct:me=dia:frameref=1:bframes=3:b_pyramid:weight_b:threads=0:turbo=2 and not only is it out of sync now but it changed the resolution/AR from what it was before.. it's 1280x1440 instead of 1280x720(original) and I never told it to resize the video.

I tried another encode with different options, does this tell anything?

mencoder -of rawvideo 24.mpg -o 24betterfilter.264 -noskip -nosound -vf tinterlace,pullup,softskip,scale=1280:720,dsize=1280:720 -ovc x264 -x264encopts subq=1:8x8dct:me=dia:frameref=1:bframes=3:b_pyramid:weight_b:threads=0:turbo=2
MEncoder dev-SVN-r22215-4.1.1 (C) 2000-2006 MPlayer Team
CPU: Dual Core AMD Opteron(tm) Processor 165 (Family: 15, Model: 35, Stepping: 2)
CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2

success: format: 0 data: 0x0 - 0xb9ecf804
MPEG-PS file format detected.
VIDEO: MPEG2 1280x720 (aspect 3) 59.940 fps 19000.0 kbps (2375.0 kbyte/s)
[V] filefmt:2 fourcc:0x10000002 size:1280x720 fps:59.94 ftime:=0.0167
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1, osd: 1, aspect: 0.000000, round: 1
Opening video filter: [dsize=1280:720]
Opening video filter: [scale w=1280 h=720]
Opening video filter: [softskip]
Opening video filter: [pullup]
Opening video filter: [tinterlace]
==========================================================================
Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough
VDec: vo config request - 1280 x 720 (preferred colorspace: Mpeg PES)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
The selected video_out device is incompatible with this codec.
Try appending the scale filter to your filter list,
e.g. -vf spp,scale instead of -vf spp.
VDecoder init failed :(
Opening video decoder: [libmpeg2] MPEG 1/2 Video decoder libmpeg2-v0.4.0b
Selected video codec: [mpeg12] vfm: libmpeg2 (MPEG-1 or 2 (libmpeg2))
==========================================================================
VDec: vo config request - 1280 x 720 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
SwScaler: reducing / aligning filtersize 1 -> 4
SwScaler: reducing / aligning filtersize 1 -> 4
SwScaler: reducing / aligning filtersize 9 -> 8
SwScaler: reducing / aligning filtersize 9 -> 8
[swscaler @ 0xd686e0]SwScaler: BICUBIC scaler, from yuv420p to yuv420p using MMX2
[swscaler @ 0xd686e0]SwScaler: using 4-tap MMX scaler for horizontal luminance scaling
[swscaler @ 0xd686e0]SwScaler: using 4-tap MMX scaler for horizontal chrominance scaling
[swscaler @ 0xd686e0]SwScaler: using n-tap MMX scaler for vertical scaling (YV12 like)
[swscaler @ 0xd686e0]SwScaler: 1280x1440 -> 1280x720
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 3DNow!
New_Face failed. Maybe the font path is wrong.n 0mb A-V:0.000 [0:0]
Please supply the text font file (~/.mplayer/subfont.ttf).
subtitle font: load_sub_face failed.
Pos: 5.2s 755f ( 0%) 50.01fps Trem: 73min 187mb A-V:0.000 [1029:0]

2nd March 2007, 07:51

That should be fine. If the sync issues are still there, here are some suggestions:

1. I'm beginning to wonder if the problem is actually in MPlayer's MPEG-TS demuxer. There are often small errors in MPEG-TS captures even when the reception is good, so the files should be preprocessed with a good demuxer that fixes the streams. ProjectX does that well, and I would always use it on digital television (SD and HD) caps no matter what I encode the streams with. However, if you don't have sync issues when playing the source with MPlayer, this is probably not the cause of your problem.

2. I found another thread where people are doing what you are trying to do: http://forum.doom9.org/showthread.php?p=951020
Try SatansChild's command lines (without the third pass and the overkill parameters) and perhaps ask there if others are having similar problems. Harddup is probably quite useful since it is mentioned (http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-dvd-mpeg4.html#menc-feat-dvd-mpeg4-muxing-filter-issues) in the MEncoder documentation concerning A/V sync issues.

3. Perhaps you'll need to encode or copy audio at the same time. This is often suggested when people have sync issues with MEncoder, so it might be necessary in this case. So, output to AVI and use -oac copy instead of -nosound (remember to remove -of rawvideo). Try playing the AVI with MPlayer or VLC. There may be a constant difference in A/V sync from the beginning due to AVC-in-AVI hacks when using b-frames.

SatansChild

2nd March 2007, 18:14

nm is correct, all my testing has shown me that you must use both harddup and -noskip when you export to a rawvideo format. The reson for this is that when you export to avi mencoder does internal av syncing ( that is what the AV # at the end of the line is when mencoder outputs to avi ), when you output to rawvideo mencoder can not do this so if any frames are skipped it will end up with desynced audio. This is contrary to the advice I have seen many other places on the net, but allmost universaly comes from someone used to useing mencoder for avi encodeing.

You should also be carefull with the paramters you specify for ivtc/pullup type filters when your source is hd braodcast. When your local cable/sat/antenna broadcaster recieves thier stream they recieve it in a much higher bitrate then when they send it out to you, at wich point they reencode it to the broadcast bitrate (some do this in realtime some don't), this is important because it means that frames that should be identical are not (realtime compression artifacts ect...) which may not work well with the dafault setings of many filters and you may end up with video that is not exactly 24000/1001 fps. Setting -ofps when you use harddup and -noskip will not help it will just set the framerate flag in the output video leaving you with video that plays too fast/too slow. What is really needed here is a filter like neuron2's FDecimate for avisynth which allows you to set the desired output framerate and the decimate threshold which will duplicate and/or drop frames as necessary to maintain both the desired fps and audio sync.

As to possible issues with mencoders TS demuxer, you may also be right with this one nm. I usually don't run into it as I convert to normal mpeg when I edit out commercials anyway. A quick test with a raw TS stream seems to confirm this although mplayer plays it back fine if I just watch it.

Thasp

2nd March 2007, 20:51

I have never played the source with mplayer. The computer is a router. Since it has a dual core CPU, and a gig of fast RAM, using it for routing only would be criminal waste, so I am trying to get this working on it. I have done all the playback with VLC and MPC on the windows desktop, which is usually too swamped to be encoding files.

The router doesn't have X11, or any GUI installed.

I have mpeg2repair for windows. I don't use it because, with megui/avisynth, I have never had these issues, but I'll see if running it through there then encoding it fixes the issue.

I forget the exact error I received when trying to copy to avi, but it said a frame thing was too big, or the audio bytes were too big, and would stop in the middle, or skip something and I'd wind up with 50 MB output. I forget how long it was - but far short of the 43 minutes it should have been.

I tried harddup and -noskip, it looked/worked the same.

Thanks again for the advice, I will try more things over the weekend to get a good stream.

Thasp

4th March 2007, 02:15

I tried this and got sync. I haven't done an AB test for quality... but I have sync. It sounds right. IT'S ALIVE! :D

mencoder 24_Fixed.mpg -vf pp=ac,framestep=2,filmdint=dint_thres=256,harddup -ovc x264 -x264encopts bitrate=3136:threads=auto:pass=1:turbo=2:frameref=3:bframes=3:nob_pyramid:direct_pred=auto:partitions=all:8x8dct:subq=6:mixed_refs:nodct_decimate -nosound -ofps 24000/1001 -noskip -of rawvideo -o FIXTHATSHIT.264
mencoder 24_Fixed.mpg -vf pp=ac,framestep=2,filmdint=dint_thres=256,harddup -ovc x264 -x264encopts bitrate=3136:threads=auto:pass=2:frameref=3:bframes=3:nob_pyramid:direct_pred=auto:partitions=all:8x8dct:subq=6:mixed_refs:nodct_decimate -nosound -ofps 24000/1001 -noskip -of rawvideo -o FIXTHATSHIT.264

MP4Box -fps 23.976025 -add FIXTHATSHIT.264 FIXTHATSHIT.mp4

mkvmerge FIXTHATSHIT.mp4 24_Fixed.ac3 -o 24.mkv

The filenames are suspect of my level of frustration at the time.

I put it into mpeg2repair than used that command line. I am going to try the same thing without mpeg2repair so I can see if that is what fixed it. If not, then I know it is that specific commandline, give or take a few options, that I have to use for 720p 60fps content. I wish I knew what in god's name pp=ac,framestep=2,filmdint=dint_thres=256 was doing. I'd read through the man pages but right now I'm all man'd out... I could go a lifetime without reading another man.

edit: The video quality is awful.. everything gets made kind of overreddish and full of color. Allow me to provide a five second sample of the original, and this.

http://thasp.net:8080/messedupmencoder/

edit 2: maybe it's just me, but what I am using in MPC for x264 just sucks. In VLC, they look the same, and in MPC, the mpeg looks great and the x264 looks awful. I think it's on my end, but if anyone in here could chime in, I would vastly appreciate it.

I couldn't get the cut position exact, so I included two samples for each from a similar part of the stream. The one done with mencoder has awful color in MPC

edit 3: It apparently has nothing to do with using mpeg2repair - the unrepaired stream with the same encode options was fine. It must be something else.

Thasp

31st March 2007, 09:16

Ok, slight problem. Encoding 720p source is fine. Encoding 1080i source causes all sorts of issues.

date
mencoder tv.mpg -sws 9 -vf pullup,softskip,crop=1912:1068:4:4,scale=1280:720:0:0:4 -ovc x264 -x264encopts bitrate=3359:threads=auto:pass=1:turbo=2:frameref=3:bframes=3:nob_pyramid:direct_pred=auto:partitions=all:8x8dct:subq=6:mixed_refs:nodct_decimate -nosound -ofps 24000/1001 -noskip -of rawvideo -o tv.264
mencoder tv.mpg -sws 9 -vf pullup,softskip,crop=1912:1068:4:4,scale=1280:720:0:0:4 -ovc x264 -x264encopts bitrate=3359:threads=auto:pass=2:frameref=3:bframes=3:nob_pyramid:direct_pred=auto:partitions=all:8x8dct:subq=6:mixed_refs:nodct_decimate -nosound -ofps 24000/1001 -noskip -of rawvideo -o tv.264
MP4Box -fps 23.976025 -add tv.264 tv.mp4
mkvmerge -o tv.mkv tv.mp4
date

Gets me no audio sync, but proper ivtc

mencoder testing.mpg -sws 9 -vf pp=filmdint=io=30001/1001:24000/1001,softskip,crop=1904:1072:8:4,scale=1280:720:0:0:4 -fps 30000/1001 -ofps 24000/1001 -ovc x264 -x264encopts bitrate=3084:threads=auto:pass=1:turbo=2:frameref=3:bframes=3:nob_pyramid:direct_pred=auto:partitions=all:8x8dct:subq=6:mixed_refs:nodct_decimate -nosound -ofps 24000/1001 -noskip -of rawvideo -o testing.264
mencoder testing.mpg -sws 9 -vf pp=filmdint=io=30001/1001:24000/1001,softskip,crop=1904:1072:8:4,scale=1280:720:0:0:4 -fps 30000/1001 -ofps 24000/1001-ovc x264 -x264encopts bitrate=3084:threads=auto:pass=2:frameref=3:bframes=3:nob_pyramid:direct_pred=auto:partitions=all:8x8dct:subq=6:mixed_refs:nodct_decimate -nosound -ofps 24000/1001 -noskip -of rawvideo -o testing.264
MP4Box -fps 23.976025 -add testing.264 testing.mp4
mkvmerge -o testing-newest-even-newer.mkv testing.mp4

Gets audio sync, but messed up ivtc. Some of the ivtcs do absolutely nothing.

I am testing

mencoder tv.mpg -vf pp=lb,filmdint=dint_thres=256,pp=ac,scale=1280:720,harddup -ovc x264 -x264encopts bitrate=3359:threads=auto:pass=1:turbo=2:frameref=15:bframes=5:nob_pyramid:direct_pred=auto:partitions=all:8x8dct:subq=7:mixed_refs:nodct_decimate -nosound -ofps 24000/1001 -noskip -of rawvideo -o tv.264
mencoder tv.mpg -vf pp=lb,filmdint=dint_thres=256,pp=ac,scale=1280:720,harddup -ovc x264 -x264encopts bitrate=3359:threads=auto:pass=3:frameref=15:bframes=5:nob_pyramid:direct_pred=auto:partitions=all:8x8dct:subq=7:mixed_refs:nodct_decimate -nosound -ofps 24000/1001 -noskip -of rawvideo -o tv.264
mencoder tv.mpg -vf pp=lb,filmdint=dint_thres=256,pp=ac,scale=1280:720,harddup -ovc x264 -x264encopts bitrate=3359:threads=auto:pass=3:frameref=15:bframes=5:nob_pyramid:direct_pred=auto:partitions=all:8x8dct:subq=7:mixed_refs:nodct_decimate -nosound -ofps 24000/1001 -noskip -of rawvideo -o tv.264
MP4Box -fps 23.976025 -add tv.264 tv.mp4
mkvmerge -o tv.mkv tv.mp4 tv.ac3 now, as recommended in the post in the other thread.

31st March 2007, 11:59

IVTC on 1080i should be easy. The documentation (http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-telecine.html#menc-feat-telecine-encode-mixedpt) doesn't recommend -noskip, so you should probably drop that. If it still doesn't work, perhaps encoding with audio (-oac copy) to AVI does. Then you could remux to Matroska afterwards.

Thasp

1st April 2007, 00:55

I think I have something working.

I have one last, stupid question, about cropping.

With avisynth, it's

Crop(4,4,-4,-8)

to take 4 off the left, top, right, and 8 off the bottom.

With mencoder, I see the cropping command. Say, crop=1904:1072:8:4

But I am not sure how this works. Does this mean it is taking 8 off of the left and right evenly, and 4 off of the top and bottom evenly on a 1080i 1920x1080 source? This is what I guessed it was all along.

Thanks again for the assistance. :)

1st April 2007, 13:00

With mencoder, I see the cropping command. Say, crop=1904:1072:8:4

But I am not sure how this works. Does this mean it is taking 8 off of the left and right evenly, and 4 off of the top and bottom evenly on a 1080i 1920x1080 source? This is what I guessed it was all along.
Yes, the values specify the cropped area as width:height:left:top in pixels where left and top are pixel coordinates in the original source image.

In this particular case you could also use crop=1904:1072 without left:top. Then MPlayer/Mencoder will center the cropped area automatically so that it removes the same amount of pixels (+/- 1 in case of odd resolutions) from top/bottom and left/right.

Thasp

5th April 2007, 19:04

Each of the following commands gave me out of sync 1080i --> 720p x264 with mencoder. :(

mencoder crap.mpg -sws 9 -vf pp=filmdint=io=30001/1001:24000/1001,softskip,crop=1904:1064:8:8,scale=1280:720 -ovc x264 -x264encopts bitrate=3150:pass=1:turbo=2:threads=auto:frameref=3:bframes=3:nob_pyramid:direct_pred=auto:partitions=all:8x8dct:subq=6:mixed_refs:nodct_decimate -nosound -ofps 24000/1001 -of rawvideo -o crap.264

mencoder crap.mpg -sws 9 -vf pp=filmdint=io=30001/1001:24000/1001,softskip,crop=1904:1064:8:8,scale=1280:720 -ovc x264 -x264encopts bitrate=3150:pass=2:threads=auto:frameref=3:bframes=3:nob_pyramid:direct_pred=auto:partitions=all:8x8dct:subq=6:mixed_refs:nodct_decimate -nosound -ofps 24000/1001 -of rawvideo -o crap.264

mkvmerge -o crap.mkv crap.264 crap.ac3 --default-duration 0:24000/1001fps

mencoder crap.mpg -sws 9 -vf filmdint=io=30001/1001:24000/1001,softskip,crop=1904:1064:8:8,scale=1280:720 -ovc x264 -x264encopts bitrate=3150:pass=1:turbo=2:threads=auto:frameref=3:bframes=3:nob_pyramid:direct_pred=auto:partitions=all:8x8dct:subq=6:mixed_refs:nodct_decimate -nosound -ofps 24000/1001 -of rawvideo -o crap2.264

mencoder crap.mpg -sws 9 -vf filmdint=io=30001/1001:24000/1001,softskip,crop=1904:1064:8:8,scale=1280:720 -ovc x264 -x264encopts bitrate=3150:pass=2:threads=auto:frameref=3:bframes=3:nob_pyramid:direct_pred=auto:partitions=all:8x8dct:subq=6:mixed_refs:nodct_decimate -nosound -ofps 24000/1001 -of rawvideo -o crap2.264

mkvmerge -o crap2.mkv crap2.264 crap.ac3 --default-duration 0:24000/1001fps

mencoder cra[.mpg -sws 9 -vf pp=filmdint=io=30001/1001:24000/1001,softskip,crop=1904:1064:8:8,scale=1280:720 -ovc x264 -x264encopts bitrate=3150:pass=1:turbo=2:threads=auto:frameref=3:bframes=3:nob_pyramid:direct_pred=auto:partitions=all:8x8dct:subq=6:mixed_refs:nodct_decimate -nosound -fps 30000/1001 -ofps 24000/1001 -of rawvideo -o crap3.264

mencoder crap.mpg -sws 9 -vf pp=filmdint=io=30001/1001:24000/1001,softskip,crop=1904:1064:8:8,scale=1280:720 -ovc x264 -x264encopts bitrate=3150:pass=2:threads=auto:frameref=3:bframes=3:nob_pyramid:direct_pred=auto:partitions=all:8x8dct:subq=6:mixed_refs:nodct_decimate -nosound -fps 30000/1001 -ofps 24000/1001 -of rawvideo -o crap3.264

mkvmerge -o crap3.mkv crap3.264 crap.ac3 --default-duration 0:24000/1001fps

I saw a lot of this as it was encoding.

demux_mpg: 30000/1001fps NTSC content detected, switching framerate.

I am now trying this. I did a first quick onepass try at low res/low settings so it'd go quick so I'd have baseline to test with. I don't know if it's 100% in sync because the video is so disgusting, but it was at least within 200ms.. I'll see if it's eact when it finishes. This encoding method also gave me

demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.

mencoder crap.mpg -vf pullup,softskip,crop=1904:1064:8:8,scale=1280:720, -ovc x264 -x264encopts pass=1:turbo=2bitrate=3150:threads=auto:pass=1:turbo=2:frameref=3:bframes=3:nob_pyramid:direct_pred=auto:partitions=all:8x8dct:subq=6:mixed_refs:nodct_decimate -nosound -ofps 24000/1001 -noskip -of rawvideo -o pleasework2.264
mencoder crap.mpg -vf pullup,softskip,crop=1904:1064:8:8,scale=1280:720, -ovc x264 -x264encopts pass=2:bitrate=3150:threads=auto:pass=1:turbo=2:frameref=3:bframes=3:nob_pyramid:direct_pred=auto:partitions=all:8x8dct:subq=6:mixed_refs:nodct_decimate -nosound -ofps 24000/1001 -noskip -of rawvideo -o pleasework1.264
MP4Box -fps 23.976025 -add pleasework2.264 pleasework2.mp4
mkvmerge -o pleasework2.mkv pleasework2.mp4 crap.ac3

Also, if I use mkvmerge directly with

mkvmerge -o pleasework2-2.mkv pleasework2.264 crap.ac3 --default-duration 0:24000/1001fps Opposed to the mp4box/mkvmerge combo above, it is ridiculously out of sync, with mkvmerge 2.*(forget the exact version). Weird.

Thasp

9th April 2007, 06:39

Ok, now I am finally beginning to understand the problem with 1080i I am having. I haven't had the time to test with full clips lately, so I decided to try on one 10 second clip where the jittering inherent in film source --> 1080i sticks out more.

filmdint does a better job than pullup/ivtc at not outputting dupe frames, but can't do what uncomb() and telecide do in avisynth.. and vice versa. even detc was able to do a nicer job than filmdint, which the documentations suggests is the best filter, but perhaps I'm using it incorrectly?

Is there a way to use filmdint's ivtc with something other than filmdint's ability to decomb the fields?

morph166955

12th April 2007, 04:16

i've been having a similar issue...and i have a possible fix for you. at the end of your video filter chain put "framestep=1". some how it fixes the output so that its proper on mine.

EDIT: correction, had to run it this way to fix a colorspace problem:

-vf scale=x:y,crop=x:y:a:b,pullup,framestep=1,format=i420 -ofps 24000/1001 -ovc raw -of rawvideo -nosound

see if that works for you

Thasp

12th April 2007, 06:17

You scale and crop before ivtc and decomb? Interesting, thanks. :)

morph166955

12th April 2007, 06:32

the source that I used that on was progressive and I'm pretty sure all you need to fix your glitch is the framestep=1,format=i420 part of that at the end of the chain. there was something with doing pullup before scale that caused a bug on my setup (i think its my video output driver, it would create an improper video window for some reason). give it a whirl though both ways i guess...just be sure the two i just listed above are at the very end of the chain since those are the more critical ones i think.

namistai

20th April 2007, 04:45

I had similar desync problems when creating rawvideo. I solved my problem by using -oac copy instead of -nosound. You still end up with raw video and when I merge my audio and video I get sync. Give it a shot. And don't put it in an avi, I understand that's a no-no with h264.

Also, I'm not sure how you're creating your ac3 file. If you're using mplayer -dumpaudio you shouldn't. Use something along the lines of:
mencoder -oac copy -ovc copy -of rawaudio -o audio.ac3

p.s. I would have posted this earlier but I forgot about it while waiting 5 days so I could make first post after registering...

Thasp

20th April 2007, 04:52

I actually use windows to on the other computer. I run dgindex on something I edit with videoredo and send it over to the linux machine. the video originates on the windows machine and is edited here so it's not extra work.

with filmdint, I have no sync issues, but I have the issue of something green showing up on the top of a 1080i source. with pullup I do, but no green nonsense. My question being, if filmdint can get sync right without -oac copy, why can't pullup, ivtc, detc, or divtc with any set of options? I reported (http://bugzilla.mplayerhq.hu/show_bug.cgi?id=798) the filmdint bug, but have little faith that it will get looked at anytime soon.

That said, I will try your suggestion - thanks a lot! :)

Thasp

21st April 2007, 08:50

-oac copy worked outputting to avi when using lavc.

Using -oac copy and outputting to rawvideo with x264, with the exact same -vf options, gets me no audio(as I expected). However, I can't remux it with sync either. The sync degrades to the end of the episode, where it's about 250 ms late. I tried getting the audio out of the same mpeg2 source using dgindex, and the mencoder method you mentioned, with the same issue. I have to encode to avi it seems for sync. :(

I tried different options, tried muxing to mp4. Muxing the 264 rawstream to mp4 then to mkv gets distortion at the end so bad, that I can't see anyone, much less tell if sync was maintained. I either get odd distortion on certain parts of the clip, out of sync, or a VLC crash. I wish mencoder could output to matroska like x264 in windows. I'll update if I get anything working.

edit time. Alrighty.

a) -oac copy output to avi = audio sync, but jittery.

b) Your suggestion with the rawstream = messed up output, or out of sync by 250ms output.

c) The latest svn of mplayer doesn't acknowledge the filmdint bug at all. :(