INTERACT FORUM
More => Old Versions => Media Center 17 => Topic started by: h8maintenance on November 05, 2011, 05:11:47 pm
-
Hi,
I'm very happy with Red October in MC16 and was hoping for some improvement in MC17. I don't know if I'm alone in this but I'm having trouble achieving jumping smoothly back/forward n.seconds for .ts .m2ts .bdmv playback. The jumps for these formats work with the audio being normally responsive while the video lags/freezes several seconds before catching up. This function works flawlessly for all other video formats such as .mkv, .avi, .mp4, .mpeg... with whichever method used, Windows Merit based or Red October. Interestingly, if I remux the .ts or .m2ts file to .mkv (no re-encoding whatsoever thus zero change except putting the video in a 'mkv' container) , Red October handles the jumping operations normally like with every other video formats.
I have:
Win 7 64-bit Enterprise
Asus P6T Deluxe v2
Intel Core i7 920
12GB OCZ Intel Extreme Edition RAM Triple Channel
nVidia GeForce 8600 GTS
Asus Xonar HDAV 1.3
Direct Show/Filters installed:
MPC custom filters manual installation
Haali
CoreAVC 3.0.1
LAV Splitter and Filters
Arcsoft audio filters
I don't have FFDShow installed because I prefer to tweak everything.
madVR when used is only the one downloaded by Red October
I have tested with Red October Standard and HQ, and also both with advanced options and additional filters but to no avail. So for instance to play a .ts video and achieving a smoother jumping back or forward operation than with Red October, I use the Direct Show Selection Method: Advanced - Windows Merit Based instead of Red October:
- Direct Show Filter Settings:
MPC - Video Decoder and Haali Media Splitter
madVR as renderer
- Playback graph:
MPC-MPA Decoder Filter
CoreAVC Video Decoder
madVR
I don't think my hardware specs or system configuration are the cause of the problem because remuxed videos work as expected and really hope that it could be easily corrected.
-
Anyone? Am I the only person having this problem?
Or some official support would be very much appreciated, even just an acknowledgment of the issue.
-
I don't know the answer. The machine is certainly powerful enough.
Are you using 17.0.31?
I play video a lot on an i3 and don't see the problem.
-
I have the same problem with most high bitrate video files. Have a Core2Duo E6300 now, upgrade to Q8400 is in the post. I'll let you know if that helps.
-
Thank you so much to both of you for taking the time to give me your feedback. I was feeling quite lonely out there ;)
re: JimH
Yes, I (always) use the latest development of v16 and v17.
re: audunth
Indeed, you are correct the issue is only present with high bitrate video files, i.e. for me with blu-ray videos or their remuxed version.
What really chafe me is that the issue does not exist if the high bitrate video has been remuxed in a .mkv container but only if it is in a .ts or .m2ts (or for blu-ray discs the .index or .bdmv file) format.
Without any specific logic and just for the sake of trying, I randomly tweaked the number of seconds to jump (3,4,5,6,8,9,10...) to see if it could improve the immediacy and synchronicity of the jumps but no, the problem is still the same.
I really don't know how to tackle the problem anymore therefore your thoughts or inputs are immensely appreciated.
-
Yes, I (always) use the latest development of v16 and v17.
It's helpful if you post the full version of whatever you're testing. 17.0.31, for example. At any given time, several versions could be considered latest.
-
Sure JimH & thanks for reminding me to be specific. I'm currently using v16.0.181 and v17.0.31.
-
As a test, try using a lower latency audio setting.
WASAPI - Event Style or ASIO with 20ms of buffering, for example.
Also, test with VideoClock on and off (Options > Video).
-
Changed the audio settings to WASAPI - Event Style with 25 ms buffering, made no difference. (Was using WASAPI before.)
Picture still has to play catch-up when skipping on a lot of files. It's worse on some formats and high bitrates, but even on a standard MKV 720p file it can stutter a little bit when skipping, especially if hitting the left/right arrow multiple times at once. Internal or external hard drive does not matter, although it's maybe a little worse over network. And the audio doesn't stutter, only the video.
Decided to return the Q8400 and instead ordered a new Z68 motherboard with 8 GB RAM and a Core i5 2500K, so we'll at least find out if it's hardware related :)
EDIT: Btw also using 17.0.31. Have had this problem for as long as I can remember. Oh, and I forgot to mention, sometimes the audio gets out of sync after a jump or starting a movie again after stopping it so I have to do another jump to get it back in sync. That's a lot more annoying than the stuttering itself!
-
You may find this problem is resovled with an upcoming change that is part of the LAV Splitter and is expected to be in MC V0.33:
- Fixed a bug that caused MPEG-2 and VC-1 parsers to produce wrong timestamps after a seek
-
Hi all,
Sorry for coming back late to report. I did some extensive testing following Matt's suggestions and some of my own:
Wasapi event style with 20ms buffering
Asio with 20ms buffering
VideoClock on and off
Results: nothing improved, and VideoClock ON even worsen the problem.
Note: I don't have any other program running when doing these tests.
Thanks audunth for testing with me on the matter. I concur with all your findings (except network because I don't have any).
I have to come to the conclusion that this is not a hardware issue, especially with our specs.
I decided to try with videos other than blu-rays and remuxed some from DVDs I have, to see if it only affects very high bitrate videos. For instance, an episode of "The X-Files" DVD with video at ±4,750 Kbps (that's 3-5 times lower than for a BD video) and maximum bitrate ±9,800 Kbps, remuxed to .mkv plays with no jumping hiccups while re-encoded to .ts at <3,000 Kbps bitrate stutters with the jumps.
I believe it's a problem with the specific .ts and .m2ts format decoding and not low or high bitrate resolution. If it were a problem with high bitrate resolution, it would affect the decoding even in the .mkv container too.
@jmone: fingers crossed here ;) although I currently think it's a video filter issue because I have slightly smoother jumps, although not perfect, with CoreAVC video decoder handling the video decoding while using the Windows Merit Base option with Advanced Direct Show Selection Method.
-
FYI - in my expereince it is the splitter that can cuase these issues but dependant on how the various downstream Decoders respond to the timecodes created impacts how it looks. The other issue is the general impact on the setup. I have no such probs with m2ts etc - they all play perfectly fine.
-
Playback is fine for me too. I have issues with the jumping n.seconds or randomly at any point in time and only with the two aforementioned extensions.
Hopefully the LAV splitter update will solve the issue indeed.
-
Just tried with v17.0.33. There is no change for me, the disconnect between audio (perfect as previously noted) and video (freeze + lagging) is still present :(.
-
...only I think there is a bug in V33, as others have reported it did not upgrade the LAV Filters for them....
-
Oh, good you mentioned that. I therefore did a manual copy of v0.39 files to the JRiver LAV plugins folder. My setup is up to date, v17.0.33 with LAV v0.39.
The jumps are better in that the splitter forces the decoding to mark a pause of about 1 second with no immediate audio rendering like previously done (step #1) then "responds to the timecodes" by fetching the requested time jump. At this stage, there is on average a lag of 3-4 seconds where the audio is effectively rendered while the video is frozen right at the point where it will catch-up with the audio (step #2) and then the final step (#3) where all is in sync again. This makes the option to jump 5 seconds for instance obviously moot.
It is a nice but mostly cosmetic improvement. The problem is still there. It is perceived as less annoying because expectations are managed (the steps) as compared to the random jerks with versions ante to 0.39. From time to time, there are some perfect jumps though very rare. I guess it is due to the right timing between the moment the command is sent and the time codes in the video frames I suppose (please don't hit me, I'm just guessing here). Eventually, a future version of the LAV splitter will bring the baby home for me on this front (thanks Nevcariel :-* for all your good work with your wonderful LAV splitter and decoder).
-
Hello all,
I am currently running MC 17.0.46 (updated to 17.0.64 and same problem)and have also problems with play back of m2ts and bdmv files.
Strange because when I play them from Windows Media Player it works fine, but with MC 17 the "sound" is out before the "picture"
Also the frames/movie are jumping.
I played a Blu Ray on the HTPC and it worked fine with MC 17, I ripped it and also the RIPPED version worked well!!??
So what is wrong with the downloaded ones? I took it from NAS on my SSD and still not perfect, so no LAN issue.
Who can help me?
?
-
I am currently running MC 17.0.46 (updated to 17.0.64 and same problem)and have also problems with play back of m2ts and bdmv files.
Strange because when I play them from Windows Media Player it works fine, but with MC 17 the "sound" is out before the "picture"
Also the frames/movie are jumping.
I played a Blu Ray on the HTPC and it worked fine with MC 17, I ripped it and also the RIPPED version worked well!!??
Update;
I think that the issue is related to the size of the to be played file. The files that give problem are all 8GB or more. The working ripped version has splitted the file in 8 parts. Does this make sense....if yes how to solve it?
So what is wrong with the downloaded ones? I took it from NAS on my SSD and still not perfect, so no LAN issue.
-
Good luck with this.
I have the almost exact opposite problem, skipping forward/back in DVDs causes a similar behavior, and the functions work properly on .ts and .mpg files.
See: http://yabb.jriver.com/interact/index.php?topic=68801.0
It appears we both have problems (possibly related, although quite different) not experienced by many users... :(
If there is anything I can do, info, logs, etc. that may help, please let me know.