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. |
25th December 2014, 17:15 | #2662 | Link |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
|
Thanks very much for the Alpha version...
Looking good, just one minor cosmetic thing: On startup the software still checks if Imago is present and issues a warning if it is not. No big deal... Merry Christmas + a Happy New Year to everyone here on the forum! Cheers manolito |
30th December 2014, 16:39 | #2664 | Link |
Registered User
Join Date: Nov 2010
Location: Brazil
Posts: 92
|
Hi, @MrC
Congratulations on this project! A great design. I am using Windows 10 64 bits ... an "insider". And I'm really enjoying it ... even if it is hard to forget Win7. When running AVStoDVD comes the message: "Warning VB6 Common Controls not found!" I also tested the compatibility mode for Win7 and Win8, but did not work. The error message remained. Recalling that the Win10 supports most of the programs supported by Win7. Did this error would not have anything to do with DirectX 9c or DirectX 10, which I have not installed? Ah! The program continues enabled in "Task Manager" .... and I have to force its closure .... Ctrl+Alt+Del. Happy New Year to everyone... with good health and much happiness. Last edited by jandor; 30th December 2014 at 17:04. |
30th December 2014, 19:20 | #2665 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,416
|
VB6 = Visual Basic 6, not DirectX. Considering its age, Microsoft probably stopped shipping the runtime for it by default in Windows 10.
Try installing this first: http://www.microsoft.com/en-us/downl....aspx?id=24417 |
30th December 2014, 20:14 | #2666 | Link | |
Registered User
Join Date: Nov 2010
Location: Brazil
Posts: 92
|
Quote:
I installed the VB6 (32-bit), but it didn't work. Thanks! |
|
31st December 2014, 00:10 | #2667 | Link |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
|
Looks like I discovered a small (cosmetic) issue with the new ffmpeg based muxing routine.
If my project consists of more than one title and I have selected "Muxed MPEG2 File" as the output, the muxing window for the second, third and all following titles shows wrong sizes and the progress bar is way off. Example: I have two titles in my project. The combined (audio + video) size of the first title is 3400 MB, the size of the second title is 800 MB. The muxing window for the first title shows the correct size of 3400 MB, but for the second title the muxing window shows a size of 4200 MB instead of the correct size of 800 MB. Of course the progress bar also displays funny values, but the resulting MPEG file is OK. Cheers manolito Last edited by manolito; 31st December 2014 at 00:13. |
1st January 2015, 01:51 | #2668 | Link | |
Registered User
Join Date: Nov 2010
Location: Brazil
Posts: 92
|
Quote:
At some point I thought about it... since I'm trying to use the portable version. Solutions have already been expressed by MrC.. http://forum.doom9.org/showpost.php?...postcount=1958 http://forum.videohelp.com/threads/2...=1#post2069025 Thanks! |
|
1st January 2015, 20:28 | #2669 | Link |
AVStoDVD Dev
Join Date: Apr 2006
Location: Italy
Posts: 1,302
|
@jandor
Glad to read that you have figured out what was the problem. Actually I could add the option to register the mscomctl.ocx library at runtime. Definively useful in these days, when Win7 is no more equipped with. The Office suite still contains the ocx, but not everybody have Office installed. BTW thanks for reporting the general compatibility of AVStoDVD with Win10 64bit. @manolito Thanks for the bug report Have a great 2015, guys Bye |
5th January 2015, 20:02 | #2670 | Link |
AVStoDVD Dev
Join Date: Apr 2006
Location: Italy
Posts: 1,302
|
Release 2.8.0 Final is out. Change log:
- Some bugs fixed - Revision of Tracks ID naming and Streams Order numbering - Added 'Fix Subtitles Errors' option in 'Edit Title'/'Subtitles' (previously fixing routine was mandatory) - Added better support to extended ASCII chars (thanks to manolito) - Added few System Info details to project log file - Added 'Demux File' tool - Added support to 5.0 channels audio output - Added a sanity check on input video time vs frames count - Added a sanity check on manual crop values (must be even) - Replaced ffdshow and Haali Media Splitter with LAV Filters 0.63 in Installer Package - Replaced ImagoMPEG-Muxer with FFmpeg for all MPEG2 output muxing - Removed ImagoMPEG-Muxer from Installer and NoIntall packages - Removed "_0" project/DVD name suffix on first project trial - Improved support to LAV Filters (add audio mixer adjust routine at runtime) - Improved support to SubRip SRT subtitles (musical notes and removal of <font> formatting) - Improved Muxing MPEG2 routine (multi audio track support) - Improved 'Fix SRT' routine for SubRip subtitles - Improved support to DVD compliant DTS audio tracks - Improved log activity on many sections - Changed maximum number of Titles from 99 to 64 to reflect BatchMux limitation - Updated license to Creative Commons Attribution-NonCommercial 4.0 International, plus added some clarifications about distribution of 3rd party software. - AVSMeter updated to release 1.8.3 - VB6 Common Controls updated to release 6.1.98.34 Bye |
6th January 2015, 03:25 | #2671 | Link |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
|
Nice, thanks a lot for the new stable version...
Just did some short test runs, everything looks cool. The muxing window now displays correct values for multiple titles. Another thing totally unrelated to the current stable version: Do not update ffmpeg to the latest point release 2.5.2 By default AVStoDVD uses ffmpeg CBR mode for high bitrates above 6500 kbps. This does invoke padding sometimes, especially if the frame size is VCD or Half-D1. With the latest ffmpeg versions I get this error: [mpeg2video @ 0591dc20] stuffing too large Video encoding failed and the encoding aborts. The last ffmpeg version which does not have this problem is from 2014-09-28. I really wonder why the ffmpeg developers felt that they had to address this padding issue, because while not being too elegant the resulting encodes worked quite well -at least for me. Cheers manolito Last edited by manolito; 6th January 2015 at 17:28. |
7th January 2015, 13:29 | #2672 | Link |
AVStoDVD Dev
Join Date: Apr 2006
Location: Italy
Posts: 1,302
|
@manolito
thanks for the feedback. So the latest FFmpeg release without the error msg is 20140928-git-3edb9aa, correct? Bye |
7th January 2015, 19:47 | #2673 | Link |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
|
That's correct, this is the very last version without the error. The next version is from Oct 2nd 2014, and this one and all later versions show the issue.
I don't know what you might do to make AVStoDVD compatible with the latest ffmpeg versions. If you omit the "minrate" parameter you will get VBR instead of CBR. You could also just reduce the specified CBR bitrate, but by how much? This would probably only work by try and error... I already tried to find a command line switch to disable padding altogether, but I could not find anything. Cheers manolito |
8th January 2015, 10:15 | #2674 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,416
|
The error message itself has been around for a very, very long time. A cursory Google search showed results from 2007 that referenced the warning with a build from 2004. What happened on September 28th and 29th* were that some memory optimizations and VBV compliance stuff were committed to mpegvideo_enc.c, and those altered (what I presume were) the allocation procedures enough to make this noticeable.
*the commits: http://git.videolan.org/?p=ffmpeg.gi...8cc78441b186e7 http://git.videolan.org/?p=ffmpeg.gi...979af8791ce962 http://git.videolan.org/?p=ffmpeg.gi...3b7a4ca9566d5c Whatever the actual issue, it seems to be proportionally linked to resolution, as after some more testing, 352x240 starts throwing it at 6333k 352x288 starts throwing it at 7194k 352x480 starts throwing it at 10637k, which is too high for DVD compliant video (in other words, AVStoDVD should never be able to encounter it for 352x480 or any higher resolution, since the buffer size needed to trigger it increases along with frame size). 352x576 starts throwing it at 12359k 704x480 starts throwing it at 19246k 720x480 starts throwing it at 19637k 704x576 starts throwing it at 22689k 720x576 starts throwing it at 23158k Anyone feel like graphing that number sequence and see if a more concrete pattern emerges? Because this is starting to look a lot less like an actual bug and a lot more like a limit imposed by the math being used for some part of the frame allocation (you could argue that would technically be a 'bug', but there'd have to be a limit somewhere, and so either you get 'the limit is set too low' or 'this is actually what the spec requires'). The difference in resolution vs. the bitrate where this appears seems to be about the same as the ratio of the difference between the last paired resolution/bitrate limit in the sequence**. Not being the exact ratio is probably a simple rounding issue. **what I'm saying here is, (704x480x24) / (720x480x24) = 0.977777778 19246 / 19637 = 0.980088608 Quite honestly, a Quarter-D1 frame doesn't need a bitrate that high - usually, even just 2000kbps is enough (for anime content at least), since the resolution would soften the image so much that 2000kbps is already pretty generous. And since Quarter-D1 is the only case that AVStoDVD would run into, it might be a good idea to add some bitrate logic based on resolution that lowers it down to a sane level for frame sizes that small. |
8th January 2015, 19:46 | #2675 | Link |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
|
Thanks qyot27 for this detailed explanation and analysis. I just checked the bitrate thresholds for VCD frame sizes, you are right on the money (as always...).
This means for AVStoDVD that it should be easy to implement a workaround. Just a simple Code:
IF framesize=352x288 AND bitrate >7150 THEN set bitrate=7150 Thanks again manolito |
10th January 2015, 17:49 | #2678 | Link | |
Registered User
Join Date: Apr 2013
Posts: 346
|
Process Aborted At Authoring
I have MKV’s of TV episodes, created by MakeMKV, that were taken directly from the DVD’s. With every attempt to convert these back into a DVD format, AVStoDVD (v 2.8.0) aborts the process at the authoring step.
I saw an old post, by MrC, that suggested Quote:
I have tried setting it to create chapters with a single episode and it works fine. However, when I do two or more video files, there is persistent aborting at the authoring point. I can provide logs, but other posts have indicated that the two logs (DVD and BatchMux) don't provide useful information. Last edited by Danette; 10th January 2015 at 20:22. |
|
10th January 2015, 20:42 | #2679 | Link |
Registered User
Join Date: Mar 2004
Location: Italy
Posts: 953
|
There should be two other files in your environment to inspect in case of authoring issues:
"C:\Users\Primary\AppData\Local\Temp\DVD_MuxMan.mxp" "C:\Users\Primary\AppData\Local\Temp\DVD_MuxMan.log" The first one is the MuxMan script file (input to MuxMan), the second one is the log file created directly by MuxMan during the authoring activities. This last one should tell (hopefully) something more about the issue... Cheers, SD |
10th January 2015, 22:05 | #2680 | Link |
Registered User
Join Date: Apr 2013
Posts: 346
|
I checked, but no such entries in that directory. In fact, I scanned my hard drive for them and nothing was found. There are BatchMux files there, but they are similar (in information) to the BatchMux files generated when the abort occurs and placed in the folder containing the empty DVD output.
Last edited by Danette; 10th January 2015 at 22:11. |
Thread Tools | Search this Thread |
Display Modes | |
|
|