View Full Version : 720p60 - Can you play this x264 file smoothly?
Jay Bee
25th May 2006, 00:46
Hi, I finally managed to register here. :) (not an easy feat considering the confirmation emails from doom9 are corrupted and the "contact an admin" emails bounce):angry:
On to my problem: I have been looking for ways to reencode proper 720p60 HDTV MPEG2 content down to more sane sizes. The problem is that the files I create with x264 play fine on my system using Overlay Mixer but not when using any VMR modes. This leads me to believe that the problem is with my graphics card or driver. So simple question: can you play this file play without dropping frames at 60 fps in VMR9 mode and what are your system specs?
14 MB NASA clip:
http://rapidshare.de/files/21308211/abc_720p60.mp4.html
My specs are:
AMD Opteron 144 @2.6 Ghz
Geforce 6600 GT 128 MB AGP
Asrock Dual SataII
512 MB RAM
Video Decoders tested: CoreAVC Pro, FFDshow
Thx for your time.
P.S: I have created an almost identical thread in the MPEG-4 AVC section because I am having exactly the same problem with XviD.
Dark Eiri
25th May 2006, 00:54
With ffdshow, yes.
P4 3.4 GHz HT
1 GB RAM
ATi Radeon X1600 with H.264 Acceleration.
Revgen
25th May 2006, 01:15
Plays at 60fps with CoreAVC Pro. Then again I have a Dual-Core setup that CoreAVC takes advantage of. I don't know what it does on Single-Core systems.
*.mp4 guy
25th May 2006, 02:45
VMR9 (and 7) uses a lot more cpu power per pixel then overlay does, so VMR9 isn't well suited for HiDef content.
imcold
25th May 2006, 03:46
With ffdshow, yes.
P4 3.4 GHz HT
1 GB RAM
ATi Radeon X1600 with H.264 Acceleration.
Afaik decoder must be programmed to use the hardware acceleration, and ffdshow isn't.
futurex
25th May 2006, 06:08
Afaik decoder must be programmed to use the hardware acceleration, and ffdshow isn't.
that's right. i think newest ffdshow builds do dual core though
Jay Bee
25th May 2006, 09:50
With ffdshow, yes.
P4 3.4 GHz HT
1 GB RAM
ATi Radeon X1600 with H.264 Acceleration.
Which decoder were you using?
Plays at 60fps with CoreAVC Pro. Then again I have a Dual-Core setup that CoreAVC takes advantage of. I don't know what it does on Single-Core systems.
Which GPU are you using?
VMR9 (and 7) uses a lot more cpu power per pixel then overlay does, so VMR9 isn't well suited for HiDef content.
I would have thought that most of the rendering takes place on the GPU. But maybe it is the CPU that is taking the hit. I guess that's what I'm trying to find out here, I just need a few more posts.
Eretria-chan
25th May 2006, 13:05
The CPU has to decode the content. With GPU acceleration, it offloads some onto the GPU.
Ya, I can play it. ~50% CPU Usage with CoreAVC. My system is: Athlon 64 X2 3800+ and GeForce 7800GT.
Revgen
25th May 2006, 14:49
Which GPU are you using?
CoreAVC doesn't support GPU yet. It will in the future. Only CPU for now.
imcold
25th May 2006, 18:37
Which decoder were you using?
he said ffdshow -> libavcodec
Dark Eiri
26th May 2006, 00:06
So my radeon's H264 accel isn't working? CoreAVC does support it?
Maybe I'll try the Cyberlink H264 Codec for ATi soon, it seems fine.
Eretria-chan
26th May 2006, 15:59
CoreAVC doesn't support GPU acceleration yet...
Sharktooth
26th May 2006, 16:04
no... it's all software decoding... and dont think the cyberlink decoder will be faster coz of HW h264 acceleration ;)
W3ird_N3rd
26th May 2006, 16:34
Actually it is (with nVidia): http://www.behardware.com/news/8117/coreavc-stronger-than-avivo-purevideo.html
That comparison was apparently done on Athlon 64 FX-55, which is a single-core processor. On dual-core and SMP systems CoreAVC is probably faster.
Revgen
26th May 2006, 20:45
On dual-core and SMP systems CoreAVC is probably faster.
It is faster.
I can vouch for it.
Jay Bee
26th May 2006, 23:14
CoreAVC doesn't support GPU yet. It will in the future. Only CPU for now.
I know. I was just thinking that since my CPU seems to handle the decoding fine in Overlay mode that the problem may have something to do with the GPU that does the scaling and rendering etc. Another reason why I think that this is quite probable is because the exact same problem persists with 720p60 XviD, not only with AVC. XviD should be easier on my CPU which isn't exactly a slug either. Oh and another thing I forgot to mention: even Overlay doesn't work smoothly if I deactivate AGP fast-writes in the BIOS. This again points towards the GPU as the troublemaker.
Up to now only people who can play the file have responded and none of them has the same GPU or CPU as me so I don't really know the answer yet.
DeadRinga
28th May 2006, 03:32
My dual opteron 250 plays this fine. I'm using CoreAVC Pro 1.0. On a side note, it actually plays HD x264 better than HD XviD because the XviD decoder isn't SMP-Capable.
ramicio
24th February 2011, 22:35
Bringing this back from the dead, I can't play 720p60 stuff without dropping out frames.
The set up :
- i7 920
- 3 GB RAM
- GeForce 8600 GT (PCIe x16 2.0, 512 MB, 540 MHz core, 1188 MHz shader, 400 Mhz memory)
- Newest version of MPC-HC x64
- Newest version of ffdshow x64
- Newest nVidia drivers
- CoreAVC 2.0.0
I don't think it's in the decoding. I will get dropped frames here and there just letting it sit any play on some scenes. This is watching self-encoded x264 SNL rips, so not a lot of motion. Every output filter in MPC-HC will drop frames. Some worse than others. EVR Custom is probably the worst, then VMR9, then Overlay Mixer. Windows is freshly installed. The decoder used has no bearing on dropped frames amount.
Do I need a more powerful video card? I hope not. If so, what would be damn good but affordable? $200 is not affordable. I don't care about 3d performance whatsoever. It's a shame there aren't video cards geared towards just 2d. I have to keep growing in size with cards because they all focus on 3d gaming BS just so I can keep up with HD video playback! I'm sure they could be a lot less powerful if they had to focus only on 2d with some optimized architecture for that purpose.
And I can't get avisynth64 working with MPC-HC.
Oh, and my x264 command is as follows : "x264 --crf 17.0 --profile high --level 4.1 --vbv-maxrate 40000 --vbv-bufsize 40000 --threads 12 --sar 1:1 --output "output.264" "input.avs""
kieranrk
24th February 2011, 23:33
720p60 plays fine with DXVA.
ramicio
25th February 2011, 01:50
If I use ffdshow with ffmpeg-mt it drops frames. If I use the DXVA decoder of ffdshow it drops frames. If I use CoreAVC it drops frames. It tells me it's the renderers, not the decoding. I can even play files back while some encoding process is going on and frame droppage will be equal, so it's not that decoding is slow. It's not constant, it's just 1 every other second or five. Some complex scenes drop frames A LOT. Is there a way to test decoding speed only?
Did a test with graphedit x64, and ffdshow is blazingly fast. The same scene that drops frames can be decoded at slightly over 100 fps, WHILE encoding with x264 in the background with 12 threads. Now even that video renderer window skips frames, but it doesn't report as dropping them, so it's all in whatever is displaying the video.
kieranrk
25th February 2011, 02:02
Try a different demuxer.
ramicio
25th February 2011, 02:31
Why would the demuxer affect rendering performance when it's clear that the decoding performance is up to snuff? And what other splitter is there for matroska? Isn't MPC-HC's matroska splitter still based off Haali?
kieranrk
25th February 2011, 03:25
Why would the demuxer affect rendering performance when it's clear that the decoding performance is up to snuff? And what other splitter is there for matroska? Isn't MPC-HC's matroska splitter still based off Haali?
Sometimes it just does, though admittedly I've seen it more on ts files than mkv files. No, mpc-hc's splitter is separate code.
ramicio
25th February 2011, 16:05
Well it has no effect whatsoever switching between MPC-HC's internal matroska splitter and Haali. Why can't any system I've ever had keep up with what I wanted to throw at it? It's not this video card is that outdated.
Sharktooth
25th February 2011, 16:09
are you on win7 or win Vista? if so try disabling Aero during playback.
nm
25th February 2011, 16:23
Why can't any system I've ever had keep up with what I wanted to throw at it? It's not this video card is that outdated.
Most likely it's not the card that causes the issue but something at the software side.
Have you also tried a player that doesn't depend on DirectShow? VLC or MPlayer(-mt), for example.
Sharktooth
25th February 2011, 16:41
also, have you updated your videocard drivers?
ramicio
25th February 2011, 17:18
I said earlier I have the newest drivers because this is like a week or two old install of Windows. 266.58.
Blue_MiSfit
25th February 2011, 20:55
Please do not resurrect 4 year old threads to troubleshoot issues like these. I'll let it go this time.
Also, this belongs in the software players forum. (moved)
Which renderers have you tried? I'd suggest trying all of them.
Derek
ramicio
25th February 2011, 23:01
If you don't want threads to be able to be "resurrected" then they should be stowed away in a read-only archive...if the thread remains open it is fair game.
I stated in my original post the renderers I've tried. EVR Custom, VMR-9 Renderless, Overlay Mixer, and System Default, which was the worst one. I could understand things not being fast enough but that would result in a slow framerate, not a dropped frame every few seconds. Every system I've ever had has stuttered like this when the video is cutting something edge.
Blue_MiSfit
27th February 2011, 06:01
Differing schools of netiquette, I suppose.
Referring to your original post is harder to do when it's not at the top of the thread :)
Anyway, I'm not seeing what version of Windows you're running. I understand it's a new install, but is it XP, Vista, 7? Your system is more than beefy enough to handle this without any hardware assistance.
You mentioned AviSynth 64 with MPC-HC, which leads me to ask: are you using x86 or x86_64 playback chains (MPC-HC, ffdshow etc)? I'd strongly urge you to use x86, since there's simply not much improvement to be had in this department, and the 32 bit chain is much more thoroughly tested by the community.
By all means, run a 64 bit OS though!!!
In my opinion, if you're having problems like this, there may be something goofy going on with your system. Have you done things like memtest, checked PSU voltages, checked to make sure your CPU isn't underclocked for some reason?
Also, you mention x264 encoding while watching video - this is fine provided you reduce x264's process priority after executing it. It's rather greedy by default! :devil: Are you in the habit of doing other "heavy lifting" type things while encoding?
This is fixable, definitely. We just need to get inside your head a little more!
Derek
ramicio
28th February 2011, 02:22
- Windows 7 Ultimate x64 is my OS.
- MPC-HC is x64, ffdshow is x64, yet MPC-HC won't open my avisynth (x64) stuff, so I just use VirtualDub x64 to preview things.
- I only mentioned playback during encoding to try to display my computer's ability to decode video at greater-than-playback framerate while resources are taxed.
- I get frame dropout with my 720p60 encodes when my system is free, not encoding anything, aside from maybe an explorer window and Firefox window being open (which have no bearing on the GPU's ability to render video.)
- I use x64 stuff for encoding because it IS much faster for me, like 15-20%.
- I'm thinking this is just a problem with the video card. It IS almost 4 years old soon.
- It shouldn't matter what kind of video I'm decoding as long as the decoder can keep up, and it can, by a long shot. All the renderer gets fed is uncompressed video, the renderer has no idea if the video was h.264, VC-1, MPEG2, etc.
BTW, how would I even run my mentioned x64 stuff on a x86 OS? ;) I'll post more later on testing with an x86 version of MPC-HC. I'm just waiting for xvidvideo.ru to be back up from maintenance. Maybe I should make my own thread, since this is ancient and it's expected that anything newer should be able to deal with this.
UPDATE: x86 stuff drops frames and skips, too. I just noticed the video will stutter randomly without reporting dropped frames.
Blue_MiSfit
28th February 2011, 05:01
Indeed, encoding in 64 bit is a good thing. Decoding is a different story :devil:
What about playing back through GraphEdit?
I'd suggest trying the following chain (all in 32 bit)
Source -> Haali Splitter -> ffdshow video decoder (with all filters disabled and H.264 decoding set to use "ffmpeg-mt" -> EVR
See if at least that can give you smooth playback.
Your video card may be old, but it's certainly adequate for these tasks. My old laptop had the simplest mobile version of the GeForce 8 series in it, and it could play 1080p stuff just fine, provided I used ffmpeg-mt or CoreAVC (no DXVA or CUDA), and Haali Renderer.
If you're still having issues... well.. you shouldn't be ;) I wish I could offer more advice. Check out all your hardware
That reminds me... what kind of display are you feeding, and what do you have the refresh rate set to?
Good luck
ramicio
28th February 2011, 06:04
1080p24 or even 1080p30 is a lot less of a task to a video card than 720p60.
I'm using a 1440x900 LCD monitor and it's set to 60 Hz.
Graphedit doesn't report any dropped frames. The framerate reported is slightly over 60. It still visually drops frames, though. The EVR renderer doesn't work in Graphedit. This should have nothing to do with x86 vs. x64. The 32-bit testing drops frames in both my player and graphedit, too.
namaiki
28th February 2011, 09:54
Is Aero enabled or disabled? What about if you use ReClock?
OvejaNegra
28th February 2011, 15:44
please check if you have Vsync enabled on the renderer, try disable it, it worked for me with all the 60 fps videos
ramicio
28th February 2011, 16:35
Aero is enabled and will stay enabled. How is disabling VSync ever a good thing? I will also never touch ReClock. I'm not a fan of altering audio.
I'm trying ReClock. It can't detect the video inside the file, though, so I have to manually set the speed. It keeps it from reporting dropped frames, so maybe the appearance of stuttering is just from the source, although that doesn't make much sense. I can scroll through a sequence that stutters frame by frame and there will indeed not be skipped fields, so it's not like the source of the encode provided duplicate fields. So there is still a problem. I've come to the conclusion that stuttering video doesn't mean it's going to report them as dropped frames. I'm thinking all ReClock does is mess with the audio for sync issues.
namaiki
1st March 2011, 10:17
I'm thinking all ReClock does is mess with the audio for sync issues.
What Reclock does (I don't know if you do or don't know. I think you do, but I'll write some stuff anyway):
Let's say that your monitor's refresh rate is 61.8Hz (that is somehow what the screen on my laptop sets itself to when asked for '60Hz') and the video is 59.94fps. There's going to be perhaps a stutter a second because the frame rate is not matched. What Reclock does in this case is that it speeds up the video so that instead of playing at 59.94fps, it's going to play at 61.8fps. Stutter is gone, but audio is altered to play faster. You can have pitch correction for that, or you can have it disabled.
Anyway, were you testing with MPC-HC 32-bit's EVR Custom Pres. video renderer? Try play a 29.970/30fps file first. If your refresh rate is less than the fps of the video, ReClock will have trouble detecting the frame rate. In that case, in MPC-HC while playing the file, press Ctrl+Down Arrow and the video will be played at half speed. This will allow ReClock to detect the frame rate. You can press Ctrl+R afterwards to reset the speed.
Anyway, that's all only to test if you can get rid of the dropped frames.
TL;DR
Dropped frames because your screen's refresh rate is less than that of the video.
-
Question:
I'm curious about what rate Aero runs at (60.000Hz or at the rate of the monitor - 61.8Hz).
-
Potentially related screenshots:
61.8Hz
http://img687.imageshack.us/img687/6812/intz.th.png (http://img687.imageshack.us/img687/6812/intz.png)
59.6Hz (one dropped frame every ~3 seconds without Reclock)
http://img39.imageshack.us/img39/6537/sdfsdfsdfd.th.png (http://img39.imageshack.us/img39/6537/sdfsdfsdfd.png)
In the same situation, if I disable VSync there is stuttering instead of a single clean frame drop.
ramicio
1st March 2011, 16:08
My monitor's actual frequency at 60 Hz is 59.918 Hz. This all should have nothing to do with stuttering video. Every TV has a different actual refresh rate yet the video still functions flawlessly outside of the computer world without dropped frames or tearing. As you can see with your own screen shots ReClock sets the frame rate to closest integers, it doesn't clock anything exactly. It stretches the audio to try to be EXACT, not match the video to the hardware. This is what VSync is for. I already uninstalled ReClock because it didn't help at all. A dropped frame means it doesn't make it to the monitor whatsoever. If it was a problem of mismatched exact clocks then the interval between dropped frames would be exact. It's not. The stuttering would be uniform, too, it's not.
Are any of the GeForce 200's a huge upgrade to the 8600 GT?
namaiki
1st March 2011, 16:20
As you can see with your own screen shots ReClock sets the frame rate to closest integers, it doesn't clock anything exactly.
On the screen with refresh rate 61.814Hz, ReClock changed the video to 61.813fps.
On the screen with refresh rate 59.600Hz, Reclock changed the video to 59.600 fps.
Look in the red text in the top left corner, which is MPC-HC's EVR-CP statistics. The number in the ReClock GUI (31.000 fps and 30.000 fps) is not accurate in the way that you are thinking.
(Display: 1280x800@62 -> 31.000 fps and Display: 1280x800@60 -> 30.000 fps)
ReClock matches the video exaclty to the screen's refresh rate (http://forum.slysoft.com/showpost.php?p=252933&postcount=67) which is why there is a reason for audio to be compromised (not that you will hear it).
If it was a problem of mismatched exact clocks then the interval between dropped frames would be exact. It's not. The stuttering would be uniform, too, it's not.
I don't get any stuttering when VSync is enabled. On my PC, however, when not using Reclock the interval between dropped frames is exact and constant and consistent.
ramicio
1st March 2011, 16:47
I don't buy it. None of this still changes the fact that my video stutters... There are moments where the frame rate appears to have halved for a second or so. Much like if you just take every other field of an interlaced source, it will look strobed because there is no motion blur. And the video not detecting has nothing to do with my refresh rate being lower. Some videos detect, some don't. All of the files were encoded and muxed with the same software and same settings within a week's time.
ramicio
2nd March 2011, 02:26
ReClock or not, VSync does what everyone seems to think ReClock does. VSync changes the framerate of the video. Without ReClock my 59.94 FPS video still plays back at 59.919 FPS, which is the exact Hz of my monitor.
http://timramich.com/framedrop01.png
http://timramich.com/framedrop02.png
In the first image you can see the frame rate is off. When the graph spikes like it does the frame rate drops to that 59.447 FPS. When that clears to the left off the screen, it jumps right back up to 59.919 FPS, as seen in the second picture. The video playback is not smooth whatsoever, despite the frame rate being spot on. I exaggerate. The normal person may not care so much, but I DO notice it. Even the graph scrolling is not smooth. It's hard to describe without seeing in person. I have very very reactive eyes, I can notice a much higher frequency than the average person!
Also, why does the graph go up then fade down, over and over, at an exact interval? It does it for every frame rate!
namaiki
2nd March 2011, 02:35
EVR-CP matches the frame rate of the video to your screen, however as the speed of the audio is not changed, frames from have to be dropped to keep up with the audio.
Are you using multiple monitors?
ramicio
2nd March 2011, 02:38
Nope, 1 monitor.
namaiki
2nd March 2011, 02:39
Anyway, on my PC I get a single dropped frame where the red line drops.
What resizer are you using for EVR-CP in MPC-HC options? If you're using one of the PS 2.0 resizers, try Bilinear (not Bilinear - PS 2.0).
ramicio
2nd March 2011, 02:45
Just plain bilinear, the default. I get no dropped frames anymore, except on loading a new, uncached file, but it's just stuttery. It's getting hard to explain. The motion is just not smooth, and would probably be better off at 30 Hz with motion blur. It drops frames like crazy with CoreAVC, so I'm just using ffdshow with ffmpeg-mt.
So, here's the logic in my brain... the decoder can keep up. If it can't then you get dropped frames. I get no dropped frames, so the decoder is perfectly capable. People are saying my video card is easily capable of rendering 720p60. What else am I missing?
namaiki
2nd March 2011, 02:50
Could you upload a sample of mentioned video?
ramicio
2nd March 2011, 02:51
Just for the hell of it I enabled the "disable Aero" option in the renderer settings, just to be cooperative to the earlier Aero question. Well don't you know it, motion is smooth. The frame rate jumps around a lot more, but no dropped frames, and all motion is smooth. Now what's the solution for me to be able to play smooth video with Aero?
Blue_MiSfit
2nd March 2011, 03:36
0_o
Perhaps your GPU really is a bottleneck here. I'd be quite shocked!
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.