LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This 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.

Notices


Reply
  Search this Thread
Old 11-10-2009, 01:23 PM   #16
DragonM15
Member
 
Registered: Sep 2003
Location: USA
Distribution: Slackware (Multiple Versions)
Posts: 455

Original Poster
Rep: Reputation: 31

Quote:
Originally Posted by H_TeXMeX_H View Post
So basically you would have to run each command with a different logfile name so that they dump data gathered from the first pass to separate files ... imagine if they write to the same file, like happens by default.

Also if you are using mplayer to play videos you can run something like this to reduce pixelation:

Code:
mplayer -vo gl:cscale=1:lscale=1:yuv=4 -vf pp -autoq 100 -dr file.avi
You can also try "yuv=3" instead of 4 if the colors are in black and white. This works best with nvidia card and drivers.
coincidentally I do use mplayer to playback my videos. I will give that a try when I get back home.

Quote:
Originally Posted by Shadow_7
Low bitrates will yield pixelation. You can forgo some pixelation by changing the colorspace / numbers of colors in use. Or by changing the resolution. Simpler data yields better compression. A higher quality source does too. I capture from my TV card in HuffYuv, then compress that to DVD quality. A bit of a space hog(40GB+ per hour), but yeilds decent results.

So what results would you be happy with? Change the colorspace to 16 bit B&W (-pix_fmt gray16le in ffmpeg) and save a ton of bits in the result. Not always desireable, but sometimes good enough. When space is more important than than content.

$ ffmpeg -pix_fmt list
For some shows I could see this being beneficial I would think. I am changing the resolution to be 560x320 in order to keep with the 720x480 ratio that it is saving the video as. So, currently I am using:
Code:
mencoder input.mpg -nosound -vf pp=ci,scale=560:320 -ovc x264 -x264encopts pass=1:qp=30:trellis=1:nr=500:subq=6:partitions=all:8x8dct:me=umh:frameref=6:bframes=3:b_pyramid:weight_b -o NUL && mencoder input.mpg -oac copy -vf pp=ci,scale=560:320 -ovc x264 -x264encopts pass=2:qp=30:trellis=1:nr=500:subq=6:partitions=all:8x8dct:me=umh:frameref=6:bframes=3:b_pyramid:weight_b -o output.avi
As it stands now, if I play a video converted with this it looks great on the TV, but of course if I play this video on my computer it does look pixelated if made full-screen. I will try the mplayer command later today to see if that clears anything up.

As a side-note, should I try to scale the picture down to 640x480 initially even though it is capturing at 720x480? That should shave off some space right?
 
Old 11-11-2009, 05:45 AM   #17
H_TeXMeX_H
LQ Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292
When you scale images / frames you should either crop or maintain the aspect ratio to avoid coneheads and the like.
 
Old 11-13-2009, 01:13 AM   #18
DragonM15
Member
 
Registered: Sep 2003
Location: USA
Distribution: Slackware (Multiple Versions)
Posts: 455

Original Poster
Rep: Reputation: 31
Would you recommend converting from 29fps to 23? Or would that be more hassle than its worth?

Thanks
 
Old 11-13-2009, 07:15 AM   #19
H_TeXMeX_H
LQ Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292
I recommend that you stay with the input fps. Lowering the fps will drop frames and this usually makes the movie stutter especially during active scenes.
 
Old 11-13-2009, 09:37 AM   #20
H_TeXMeX_H
LQ Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292
Also just as a side note, I've been messing around with x264 encoding and I've found probably the best tradeoff in quality/speed ratio is:

Code:
qp=25:subq=6:frameref=5:bframes=3:8x8dct:b_pyramid:weight_b:keyint=240:direct_pred=auto:mixed_refs:trellis=1:threads=auto
I've also noticed that the threads= option doesn't affect quality noticeably, but does affect speed noticeably, so you should leave it on. Also possibly adding nr= option for noisy input. You can also use a lower frameref= for non-anime, minimum value 2 for the other stuff to work properly. Oh, and keyint= should be 10 x FPS in most cases. Also, to speed up pass 1 you can use lower values for many of the options, this will not really affect output quality significantly.

Last edited by H_TeXMeX_H; 11-13-2009 at 09:39 AM.
 
Old 11-13-2009, 02:09 PM   #21
DragonM15
Member
 
Registered: Sep 2003
Location: USA
Distribution: Slackware (Multiple Versions)
Posts: 455

Original Poster
Rep: Reputation: 31
Speed isnt too much of a concern for me, unless it takes days for a single video or something. I am more concerned about quality/size. With that in mind, your latest post seems to still look good while keeping the size to a minimal. I will do a couple more test-runs and see how they turn out. What does a show being anime have to do with the framerefs?

Thanks for all the help!
 
Old 11-13-2009, 02:50 PM   #22
H_TeXMeX_H
LQ Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292
Oh, well they say in the man page that:

Quote:
frameref=<1−16>


Number of previous frames used as predictors in B- and P-frames (default: 1). This is effective in anime, but in live-action material the improvements usually drop off very rapidly above 6 or so reference frames. This has no effect on decoding speed, but does increase the memory needed for decoding. Some decoders can only handle a maximum of 15 reference frames.
So, it should be used where there are high numbers or repetitive consecutive frames i.e. anime. Or, at least it is most effective here. You'll get better compression with a high number for this like 5 or 6, but it will show most if you're encoding anime, otherwise it might not save much.

If you want maximum quality, then you'd do:

Code:
qp=25:subq=7:frameref=6:bframes=3:8x8dct:b_pyramid:weight_b:keyint=240:direct_pred=auto:mixed_refs:trellis=1:threads=auto:partitions=all:me=umh
setting qp= accordingly to match the output size you want. It's probably gonna be slow. I tested something like this with only one thread and it would take about 1 hour encoding for 1/2 hour of video. It's much faster with 4 threads (or set to auto). Doing anything more than the above is likely not going to improve quality anymore. You can also try trellis=2 but it may be quite slow.

Last edited by H_TeXMeX_H; 11-13-2009 at 02:57 PM.
 
Old 11-17-2009, 01:37 AM   #23
DragonM15
Member
 
Registered: Sep 2003
Location: USA
Distribution: Slackware (Multiple Versions)
Posts: 455

Original Poster
Rep: Reputation: 31
I figured out what the largest problem (and maybe only problem) was with my quality. I kept getting video's that were extremely pixelated and couldnt figure out why. I finally decided to take out the deinterlacing section, and like magic all pixelation was gone! The best part is that with the encoded avi, you cant even tell that it is interlaced (in comparison to its mpeg counterpart). As of now I am using:
Code:
mencoder input.mpg -nosound -vf scale=560:320 -ovc x264 -x264encopts qp=25:subq=7:frameref=6:bframes=3:8x8dct:b_pyramid:weight_b:keyint=290:direct_pred=auto:mixed_refs:trellis=1:threads=auto:partitions=all:me=umh -o NUL && mencoder input.mpg -oac copy -vf scale=560:320 -ovc x264 -x264encopts qp=25:subq=7:frameref=6:bframes=3:8x8dct:b_pyramid:weight_b:keyint=290:direct_pred=auto:mixed_refs:trellis=1:threads=auto:partitions=all:me=umh -o output.avi
I will continue to tinker with the different qp values and see what kind of results I get now that I am not deinterlacing.

Thanks for all your help
 
Old 11-17-2009, 02:54 AM   #24
H_TeXMeX_H
LQ Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292Reputation: 1292
Yeah, you should usually avoid deinterlacing unless you absolutely have to. It usually cuts FPS in half and quality as well.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
mencoder & x264 help steve51184 Linux - Software 14 05-21-2009 04:58 AM
Green screen after video conversion, AVI to MP4 using Mencoder,Mplayer,FFmpeg,x264, manuken Linux - Newbie 4 10-29-2008 06:40 PM
Mencoder: x264 [error]: no ratecontrol method specified PsypherPunk Linux - Software 1 01-12-2008 08:45 AM
Converting DVD to x264 w/ Mencoder out of sync? carl0ski Linux - Desktop 1 01-12-2007 07:04 AM
Why can't I get 720x480 on my TV-OUT? newmoon Linux - General 0 07-28-2005 01:59 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 08:23 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration