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. |
24th October 2003, 10:46 | #161 | Link |
Registered User
Join Date: Oct 2001
Location: Outside the Bush INSanatory - Lisbon
Posts: 330
|
Ok, my doubts on DVDShrink's deep analysis compression method were answered here.
So what's it all about? DVDShrink performs a first pass where it calculates the engine's maximum and minimum compression for every frame in the source. That's why it can take as long as half a(n)? hour. With that information, it's very easy to set the compression uniformly across all frames on the second pass. That easy! |
24th October 2003, 13:35 | #162 | Link |
Moderator
Join Date: Oct 2001
Location: England
Posts: 3,285
|
Very useful thread duartix thanks, doesn't sound too complex at all. Should be able to implement that, just came back and now have a week off (assuming the software I wrote for the client doesn't fall over ). So I should be able to work on it lots over the next week...Lots of interesting/thought provoking discussion, since I've been away, keep it coming...
-Nic |
24th October 2003, 13:51 | #163 | Link |
Registered User
Join Date: Jul 2002
Location: Oz
Posts: 4
|
bitrate 10200kbps to high for DVD
I have tried using this a few times to trascode my mpegs that I have accidently created to large, this all goes fine except when I import it into DVDAuthor it tell me that it's max is 10200kbps and the DVD max should be 9800kbps, even if I do it at 20% still the same. So something a bit odd.
I tried an old bitrate program as well and the same was reported. |
24th October 2003, 20:38 | #166 | Link |
Moderator
Join Date: Oct 2001
Location: England
Posts: 3,285
|
@int21h et al: I converted ReQuant into C++ code...but it's quite a bit slower than the C also allowed me to do some tests with the Intel Compiler...which makes it a helluva lot faster than VC6.
http://nic.dnsalias.com/ReQuant_src.zip is the C++ version and the old C version, for you to play with, I moved some of the more interesting functions to the top of ReQuant.cpp The C++ version won't make it into ReJig, but it may be useful for testing quality... (I did a fc and the C++ version and C version report the same output, which is good, if you can make the C++ version the same speed let me know). Back to IFO parsing stuff, then onto rate control (Surprised no one has tried double clicking the right mouse button in ReJig to see what I was upto before I went away... ) -Nic |
24th October 2003, 21:19 | #169 | Link |
VSOP
Join Date: Jul 2002
Posts: 92
|
SORRY to tell but it doesnt work. Tried two times and in the end, when it all was at full (100%) I get an error msg.
When I pick an IFO (first one) then get an m2v that is way bigger then the original. (used an allready shrinked set of files, movie only) The m2v itself should be appr 3.6GB. Last edited by JvD; 24th October 2003 at 21:23. |
24th October 2003, 22:04 | #170 | Link | |
Still Laughing
Join Date: Oct 2001
Location: Around
Posts: 1,312
|
Quote:
|
|
25th October 2003, 00:22 | #171 | Link |
Moderator
Join Date: Oct 2001
Location: England
Posts: 3,285
|
@int21h: Haven't profiled it, could be that now it doesn't use static variables everywhere, etc the compiler can't optimise as well, etc...take a look, ill just keep with the C code for now, my C++ code doesn't help the readability (<--is that a word ) much.
@JvD: Well it's only the test stuff, so I doubt it would work, but it has worked fine for me, any more info you could give me would be great (like the error msg it said, the percentage you set it to before hitting reencode, the buttons and the order in which you pressed them etc etc). Thanks |
25th October 2003, 15:43 | #172 | Link |
Custom User Text:
Join Date: Aug 2002
Posts: 161
|
Another Line of code
Nic I had to add another line of code, mike
Code:
for ( iter = lstM2VFiles.begin(); iter != lstM2VFiles.end(); iter++ ) { // Add the Jobs in CJob Job; Job.csInputFile = *iter; Job.csInputFile.Replace("nopull.",""); //<- mike Job.fCompressionFactor = m_fCompressionFactor; // Create suggested output filename Job.csOutputFile = *iter; int nDot = Job.csOutputFile.ReverseFind('.'); if ( nDot != -1 ) { Job.csOutputFile = Job.csOutputFile.Left(nDot); } //Job.csOutputFile += "_ReJig.m2v"; int nNopull = Job.csOutputFile.Find("nopull"); if ( nNopull != -1 ) Job.csOutputFile += ".mpv"; else Job.csOutputFile += ".mpv.m2v"; mike |
25th October 2003, 17:15 | #173 | Link |
Registered User
Join Date: Apr 2003
Location: Totolalandia
Posts: 96
|
Bug Found!!!
@Nic:
I don't know if others had notice, that when transcoding with this tool, the transcoded file is somehow JUMPY. I carefully check it when running the ".m2v" file with Power DVD. I notice that every 3 or 4 seconds, the movie tend to jerk or jump. You can notice this specially when the camera is moving horizontally. First I noticed it when playing the movie in my Sony DVD player. I confirmed it, playing it through Power DVD, and using also other movie. Both transcoded movie are NTSC, and the compression was adjusted to 58% and 60% respectively. Maybe the framerate is altered or changed, however no audio sync problem is detected... Last edited by m1482; 25th October 2003 at 17:17. |
25th October 2003, 18:39 | #174 | Link |
Moderator
Join Date: Oct 2001
Location: England
Posts: 3,285
|
It is a bug that was kind of noticed before, but obviously does not happen often, or we would have heard more about it...I need to get it to reoccur here for me to find the problem. What was the name and region of the DVD (or material) you were transcoding?
(if it happens often enough, maybe it would be easy enough for you to cut a bit out of the original source and send it to me?) Cheers, -Nic |
25th October 2003, 18:55 | #175 | Link |
Custom User Text:
Join Date: Aug 2002
Posts: 161
|
@nic
I have a couple of movies that I also have this problem with. One is StarWars Episode I. Another one that might be a problem is "The Core" I recompressed the video with rejig and Horizontal camera movement seems fuzzy and jerky. I just finished running it through IC8 and I am going to compare it now. I can send you a segment of these if you want? mike |
25th October 2003, 23:40 | #176 | Link | |
Registered User
Join Date: Jun 2003
Posts: 150
|
Quote:
Last edited by DVDRFreak; 25th October 2003 at 23:42. |
|
26th October 2003, 00:06 | #177 | Link |
Moderator
Join Date: Oct 2001
Location: England
Posts: 3,285
|
Yup, that's an interesting point...anyone that gets jerkyness, could you try demuxing it to M2V first (with DVD Decrypter or whatever) and then ReJiging it. That way ill be able to pinpoint where the problem is...
If you can send me any problem clips that would be great mmgrover. Cheers, -Nic |
26th October 2003, 01:10 | #178 | Link |
Registered User
Join Date: Jun 2003
Posts: 150
|
@Nic
It's the engine I think. When you compress at high compression levels it happens to me also. Tested it on NARC. Used decryptor to rip first chapter compressed it at 77% it is Ok. Compressed it at 50% still it is Ok. Compressed it at 40% and the picture starts to go jumping around like it is in fast forward. |
26th October 2003, 01:51 | #179 | Link |
Registered User
Join Date: Apr 2003
Location: Totolalandia
Posts: 96
|
@Nic and DVDRFreak:
I discovered something... First I demultiplex with VStrip and transcode again using 58 anf 70%. The problem persist!!! Then when I was concluding that the problem was with the transcoder I check the demux m2v file created by VStrip, and the problem begins there!!! So, is the demuxing program use in Rejig the same or similar as VStrip??? |
26th October 2003, 04:21 | #180 | Link |
....
Join Date: May 2002
Location: Australia
Posts: 2,797
|
just some thoughts following on from Int21's comments.
instead of tying variable requant to motion you could base it on original GOP size compared to average VBR for whole mpg/vob. that is if the original GOP is say 10% larger than the average then requant less than target value and if the GOP is 10% smaller than average requant a bit more. then use the values as a payback system to hit the target average. this would need to be limited in payback amount to try and keep to target closely.asuming the original compression VBR ratios were based on quality for all motion etc this would help maintain quality with high motion scenes, especially using large compression amount. |
Thread Tools | Search this Thread |
Display Modes | |
|
|