cipher
26th March 2008, 10:34
The current routine of muxing hddvd vc1 into a wmv container seems to be:
1. decrypt hddvd to evo files on hdd
2. demux to .vc1 29.97fps
3. usually have to pulldown to another .vc1, 23.976fps
(Edit: with eac3to's pulldown function back to being usable, these 2 steps can now be converged into 1.)
4. convert into .avi using vc12avi, segmented avi files,
5. combine all these avi files into 1 single avi files with vddubmod,
6. mux this avi to .asf with SolveigMM ASF Multipexer
7. add in audio and mux into .wmv with WM stream editor
It all works well. However, each of these steps reads and writes typically 14-18g data, that'll be around 100g data for each conversion of .vc1 -> wmv. So I'm just wondering if any of these steps in the future could be avoided, or "combined" on-the-fly, for saving time and reducing harddisk reading and writing? :rolleyes:
Thank you.
Regards,
cipher
1. decrypt hddvd to evo files on hdd
2. demux to .vc1 29.97fps
3. usually have to pulldown to another .vc1, 23.976fps
(Edit: with eac3to's pulldown function back to being usable, these 2 steps can now be converged into 1.)
4. convert into .avi using vc12avi, segmented avi files,
5. combine all these avi files into 1 single avi files with vddubmod,
6. mux this avi to .asf with SolveigMM ASF Multipexer
7. add in audio and mux into .wmv with WM stream editor
It all works well. However, each of these steps reads and writes typically 14-18g data, that'll be around 100g data for each conversion of .vc1 -> wmv. So I'm just wondering if any of these steps in the future could be avoided, or "combined" on-the-fly, for saving time and reducing harddisk reading and writing? :rolleyes:
Thank you.
Regards,
cipher