Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
21st January 2008, 09:35 | #2761 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Currently pulldown removal is default. But you can disable it by using the (undocumented) option "-keepPulldown". If removing the pulldown is really problematic for Blu-Ray authoring, I'll revert the default to not doing pulldown and will offer an option for removing pulldown instead. |
|
21st January 2008, 09:37 | #2762 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
|
|
21st January 2008, 09:53 | #2763 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
This one is complicated. Let me try to explain: ----------------------- Normally an EVO movie contains a video track which is encoded in 1080p24. There are normally exactly 24/1.001 frames per second in the video track. Furthermore the EVO container contains some timecodes for some video frames (but not for all). E.g. the container might say: "frame 305 has the timecode 0:01:50". Now there are different ways to remux such an EVO to MKV: (1) You could totally ignore the timestamps of the EVO container and just mux the movie as a constant stream of 1080p24 frames. Basically this is what mkvtoolnix does when you rewrite timecodes. It's a good approach cause you get very smooth playback with usually no micro stuttering issues. HOWEVER, there's no guarantee that you'll get perfect audio/video sync this way cause it's theoretically possible that there are gaps or overlaps in the EVO file. I mean it's possible that the EVO codes frame 10 to have timecode 0:01:50 and frame 11 to have timecode 0:01:55. So there would be 5 seconds worth of video frames missing in this case. Such cases do exist in real life. E.g. the Equilibrium HD DVD is such a beast. Now if you ignore the EVO timestamps and simply remux this to MKV the stupid way, the MKV will play 5 seconds shorter than the EVO would play. (2) The 2nd approach would be to strictly follow the timestamps of the EVO file. The problem with this is that only some video frames have timestamps but not all. So you need to guess the timestamps for the frames which don't have timecodes. This is what Haali's Media Splitter does. This is a bumpy ride, though, cause if you guess bad, it might happen that the timecodes are not fluid, which results in micro stuttering. E.g. when using the Haali Media Splitter -> Haali Matroska Muxer, it sometimes happens that frame e.g. 55 gets a timestamp in the final MKV file which is *later* than frame 56. Obviously this results in noticably stutter. (3) Now eac3to tries to find a good balance between (1) and (2). eac3to starts with the approach that the stream probably has no gaps or overlaps. So it applies very exact 24/1.001 timecodes to every frame. But at the same time eac3to also checks the EVO timestamps. If the EVO timestamps differ too much from where eac3to is going, eac3to notices that, outputs a warning message and corrects its timecode calculation accordingly. In your case eac3to has detected alternating gaps and overlaps of 2-3 frames. This shows how instable the EVO timecodes sometimes are. But it also shows that with your EVO file the EVO timestamps in the long run agree with eac3to's calculation because the overlaps and gaps even out over time. I've now modified eacto v2.16 a bit so that it is a bit more relaxed in trying to find gaps/overlaps. Hopefully that will fix the problem with this movie. If not, please let me know. ----------------------- Ouch, long explanation. Hopefully it was understandable! |
|
21st January 2008, 09:54 | #2764 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
eac3to v2.16 released
http://madshi.net/eac3to.zip Code:
* fixed "eac3to -test" crash * fixed "eac3to some.ddp some.wav" crash * made video gap/overlap detection a little more relaxed * WAV header is initialized to 4GB instead of 0GB (for stdout) * fixed incorrect "primary/secondary" text |
21st January 2008, 10:24 | #2765 | Link | |
Registered User
Join Date: Jul 2005
Posts: 32
|
Quote:
Good news is that eac3to can now directly process VC1 files. Bad news: now I can reconfirm the MKV muxing part of the process really doesn't like VC1 interlaced files. When I demux the EVO with eac3to into videostream.vc1 and do eac3to videostream.vc1 test.mkv I see basically the same problem as before (See my post 1080482): the muxing runs for a while and then hangs. I'm aware this problem is most probably not cased by the eac3to code, but somewhere in the muxer. Maybe you ever going to write a muxer as well In the mean time, what is a good way for me to produce a test case to feedback to the Haali developers? |
|
21st January 2008, 10:28 | #2766 | Link | ||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Just for your information: With v2.16 demuxing the VC-1 stream and then muxing it to MKV is not much different than asking eac3to to remux the VC-1 stream directly from EVO to MKV. The only difference is that when demuxing the VC-1 stream first, eac3to loses the chance to check for video gaps/overlaps. Last edited by madshi; 21st January 2008 at 10:31. |
||
21st January 2008, 12:11 | #2767 | Link | |
Registered User
Join Date: Jul 2007
Posts: 259
|
Quote:
The problem is described better here: http://forum.doom9.org/showthread.php?t=133974 Bugreport: www.earselect.se/bugreport.txt |
|
21st January 2008, 12:20 | #2769 | Link | |
Registered User
Join Date: Jul 2007
Posts: 259
|
Rainbow frames and glitches.
Quote:
So the blame is on mkvmerge for errors like "rainbow frames"? |
|
21st January 2008, 12:21 | #2770 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Which problem? Can you please be more specific? The one with AVC titles? The one with VC-1? Or the one with mkvtoolnix not working?
This should already be fixed with v2.16. Quote:
Ideally the gap/overlap warnings should only occur if there are real gaps/overlaps (as is the case with Equilibrium). If I'd ignore the gaps with Equilibrium, audio sync would be totally lost and totally unrecoverable. It's not just some msec, it's some seconds with Equilibrium. Anyway, those gaps/overlaps with the title you reported, are those still there with v2.16? I consider it a "bug" in eac3to, if such gap/overlap messages are appearing the way you reported. In the end eac3to should convert at least 99% of all movies without any such warnings. Equilibrium is the only title that I know where these warnings may "legally" occur. But I'm not sure. I've implemented this feature to be sure. |
|
21st January 2008, 12:24 | #2771 | Link | ||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
If you're talking about VC-1, things may be different. For your HD DVD VC-1 movie I'd like to have a sample, if the problem still occurs with v2.16. |
||
21st January 2008, 12:34 | #2772 | Link |
Registered User
Join Date: Jul 2007
Posts: 259
|
Sorry...
Million Dollar Baby HD DVD uses VC-1 and did with eac3to 2.13 end up with rainbow frames. Will try again with eac3to 2.16. Yes I read you long explanation...thanks for taking the time to clear things out. But what I really wanted to know is if I should remux all my titles again using this new method? Yes the problem with AVC titles like Ratatouille and Revolver is still there with latest beta. Don't know if VC-1 titles will work wthout introducing rainbow frames. But Ratatouille and Revolver did not work. |
21st January 2008, 12:50 | #2773 | Link |
Registered User
Join Date: Jan 2006
Location: Athens, Greece
Posts: 1,518
|
I am doing Million dollar baby now (v2.16)...
Code:
C:\Tools>eac3to F:\PEVOB1_1.EVO+F:\PEVOB1_2.EVO 2: dollar.mkv EVO, 1 video track, 2 audio tracks, 2:12:35 1: Joined EVO file 2: VC-1, 1080p24 /1.001 3: E-AC3, 5.1 channels, 640kbit/s, 48khz, dialnorm: -27dB, 133ms 4: E-AC3, 5.1 channels, 640kbit/s, 48khz, dialnorm: -27dB, 133ms Extracting primary video track... Muxing video to Matroska... Video has a gap of 9 frames at playtime 0:00:06. Video track 2 contains 190727 frames. eac3to processing took 50 minutes, 40 seconds. Done. ----- Last edited by nautilus7; 21st January 2008 at 14:07. |
21st January 2008, 13:47 | #2775 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
I don't think so. Maybe it would make sense to compare one movie wich new and old movie to check whether the new method works better or whether it's the same (or even worse - hopefully not!). But if the new method is not significantly better (which I don't think it is) there's no reason to redo everything.
|
21st January 2008, 14:13 | #2776 | Link |
Registered User
Join Date: Jan 2006
Location: Athens, Greece
Posts: 1,518
|
Million Dollar baby is done, but result is not good. First of all i updated the log in my previous post.
I can't play it correctly with mpc (it's crap - full of glitches). I can only decode VC-1 with WMVideo Decoder DMO right now and not ffdshow. (Something is wrong in my pc). But, i tried wmp11 and it plays it correctly. Well almost correctly. If i seek the track it either play ok or not. EDIT: I changed the video renderer in mpc from haali to vmr9 and now it behaves the same way like wpm11. I suppose the same combination of renderer/decoder is being used in both of them. I guess a 50 MB sample would be ok? Last edited by nautilus7; 21st January 2008 at 14:22. |
21st January 2008, 14:44 | #2777 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
A 50 MB sample is ok if the problem can be reproduced with that sample. I'm not talking about the Haali renderer, though. I'll not debug problems in the Haali renderer. Only VMR9 or EVR, please. |
|
21st January 2008, 15:15 | #2778 | Link |
Registered User
Join Date: Jan 2006
Location: Athens, Greece
Posts: 1,518
|
Well, with whole movie the problem is only seeking (vmr9). But with the sample playback is also a problem. If you find out out that the problem is not eac3to related, just skip it. Tell me if you can use any other decoder except VMVideo Decoder DMO with this sample, please.
Here's a 40 MB sample (it shrunk during upload ). Last edited by nautilus7; 21st January 2008 at 15:42. |
21st January 2008, 15:27 | #2779 | Link | |
Registered User
Join Date: Jul 2007
Posts: 259
|
Quote:
Did you use mkvmerge to add audio? If so, please test to not run the file through mkvmerge and see if you still have glitches. If you did not use mkvmerge. Please test run it through mkvmerge and check if it still plays fine with EVR or VMR9 Running it through mkvmerge often results in searchable files Last edited by rickardk; 21st January 2008 at 15:29. |
|
Tags |
eac3to |
|
|