View Full Version : x264 encoding slows clip down?
Sok4R
11th April 2007, 08:47
Today i had a strange problem with encoding with the x264-codec.
I've downloaded megui and updated everything. With the Encoding Guide by fei ( Here (http://www.shaolinproductions.org/index.php?option=com_content&task=view&id=33&Itemid=16) and Here (update) ("http://www.shaolinproductions.org/index.php?option=com_content&task=view&id=41&Itemid=16)) I thought nothing could go wrong, but i was wrong.
Uncompressed, the clip hat a lenght of 44sec (just wanted to test). After first encoding with 2700kbs, the quality was horrible (1280x720@30fps) but the lenght was the same, so i tried another one with 3500kbs. But the output-clip had a lengh of 53sec! The clip seemed to be slow down a bit and sync with the music was lost.
Has anyone experienced this problem before? Its really strange, espacially because one time the output has the normal lenght, the otherone its a bit longer.
Dark Shikari
11th April 2007, 11:32
Have you checked to see if the FPS got changed?
S”nTė£
11th April 2007, 14:26
Quality horrible at 2700kbps? That's really strange, something else must be interfering :s
DarkZell666
13th April 2007, 09:51
Ehm, wait a minute, he's encoding 720p material. 2700kbps isn't what I call "too much". "Hardly enough" is more accurate if you ask me (especially if it's DV ...).
@Sok4R: What does a CRF20 encode give (quality and final bitrate) ? Did you set the deinterlacing properly ? What sort of content is it (sports/movie/anime/DV ...) ? What do you actually call "horrible" (screenshots are welcome) ? Once you've answered all these, a solution/explanation might just automagically appear =)
I don't have a clue about the synch problem though ... sorry about that one ^^'
quake74
13th April 2007, 10:12
Uncompressed, the clip hat a lenght of 44sec (just wanted to test). After first encoding with 2700kbs, the quality was horrible (1280x720@30fps) but the lenght was the same, so i tried another one with 3500kbs. But the output-clip had a lengh of 53sec! The clip seemed to be slow down a bit and sync with the music was lost.
Has anyone experienced this problem before? Its really strange, espacially because one time the output has the normal lenght, the otherone its a bit longer.
I have two suggestions: as always try with different players (mplayer/vlc/etc) and also try to play the avs file (say with media player classic) you created just to pinpoint whether the problem is.
Sok4R
16th April 2007, 19:28
Have you checked to see if the FPS got changed?
well, just checked them and they have changed.
uncompressed movie has 30fps, output has 25fps - and i have no clue why.
the quality thing: it's footage out of the game Quake 3 Arena, that means fast-paced content, only very few "slow" scenes - very hard to compress. here is a screenshot out of vlc:
http://img403.imageshack.us/img403/3509/vlcsnap187883zn7.jpg
those strange edges: i just found out that this is because of the crappy-standard codec used for editing in adobe premiere (cinepak codec by radius) - now i know that uncompressed or huffyuv is much better - with more size of the clips, yes, but the end-quality is it worth.
to save some space with the encoding, i use some motion-blur in the video. it's already in the uncompressed footage, made with the game-engine itself (or some mod, because q3-engine is open-source). so i get a nice motion blur with low fps.
to see the "horrible" quality at its best, look at the walls at the left and right side. i think they look bad (even if with the knowledge that i used motion blur), especially compared to other movies (2 good examples: Get Quaked 3 (http://www.own-age.com/vids/6212) and Unity (http://www.own-age.com/vids/video.aspx?id=8904) ).
i also uploaded two profiles of megui i used to encode:
http://www.sok4r.de/temp/x264_test1.xml
http://www.sok4r.de/temp/x264_test2.xml
right now i'm testing the crf-thing. i'll be back when it is finished.
Update: encoding just finished:
fps-problem is the same, but the quality is insane :eek: , aswell as the filesize. 60mb for 53sec, is well, a bit or two to much.
DarkZell666
16th April 2007, 20:52
Haha, so half of the mystery is solved then, Q3 game caps are one of the hardest-to-compress sources you can find ^^'
You'll have to downsize I guess, or live with the insane filesize, that's all there is to it ... ^^' Since you're doing HD-Ready, you can use crf 24 or 26 safely I believe, the quality should be more than acceptable and the filesize should come down quite a bit.
For your fps problem, I suspect something went wrong during the muxing process with YAMB. You need to specifiy the "-fps 30" switch somewhere to MP4box (YAMB is: Yet Another MP4 Box), since mp4box defaults to 25fps when muxing.
Sok4R
17th April 2007, 13:31
i tried to force mp4box to use "-fps 30" by editing the commandline in yamb, but it didn't worked.
next i tried to open the raw clip made by megui, and guess what? this clip has a lenght of 53sec. thats why i think the failure is somewhere in my encoding-settings, but i can't find anything. i played a bit with the settings, but nothing changed anything in that way.
DarkZell666
17th April 2007, 14:22
Perhaps MeGUI didn't set the directshowsource fps properly in the avisynth script then :
You should have something looking like :
DirectShowSource("yourhuffyuvcapture.avi", fps=30.0)
(and I suppose you actually have 25 instead of 30).
Or even better :
AVISource("yourhuffyuvcapture.avi")
ConvertToYV12()
(AviSource doesn't need a framerate to be specified, so you don't risk getting it wrong :p).
I'm not familiar with MeGUI at all so I can't really tell you where you should be looking, but the framerate can be specified at 3 places:
- During decoding (this is the directshowsource fps parameter as I pointed to you above).
- During encoding (x264 exposes a --fps parameter).
- During muxing (mp4box also exposes a -fps parameter).
x264 should theoretically get it's fps info from the avs script, which is why I suspect the avs script is wrong. Maybe you should try manually editing MeGUI's command-line and adding that --fps parameter to x264 (it will override the fps given by the avs script).
However ... I'm surprised that setting -fps 30 in mp4box didn't work since it should override any "fps" info that is in the raw video.
Edit: I've just had a try setting a custom fps value on a raw h.264 stream in YAMB (rev from 20070311) and it isn't taken into account in the final mp4 file either (I get a 25.0fps mp4 file) ... dunno if it's a bug or a simple "limitation", but you're gonna have to fix the problem at decoding/encoding time ... :rolleyes:
Edit2: I've just remembered avc2avi (get it here (http://mirror05.x264.nl/Sharktooth/x264/utils/avc2avi_r594.7z), see the x264 daily builds sticky) should to the trick. Mux the raw .264 stream into avi with avc2avi and mux that avi with your audio in YAMB and it should be ok :)
avc2avi asks for a framerate, which you should set to ... 30 of course :p
Sok4R
18th April 2007, 13:20
my avs-script looks the same as yours (with different filename, of course =).
i checked yamb again i saw my mistake.
after checking "view or edit mp4box command line", i wrote "-fps 30" bind the file-path and closed the window. i should have left it open, because now it works fine =)
thanks for help! :thanks:
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.