|
|
| phaeron |
| Posted: Jul 10 2005, 10:55 PM |
 |
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Quick service pack.
| CODE | Build 23604 (1.6.9, stable): [July 10, 2005]
[bugs fixed]
* Extended workaround for Huffyuv joining problems to capture mode
(pre-zeroing format block).
* Hex editor would warp to a random location when using the mouse wheel for
the first time.
* Currently displayed frame was not updated after a reload (F2).
* Fixed errors when opening YCbCr (YUV) videos that had nonstandard bit
depth or image size values in the frame header.
* YV16 input is now supported; previously it could be written but not
re-read.
[regressions fixed]
* Fixed sporadic audio compression errors at end of render. |
|
|
| i4004 |
| Posted: Jul 11 2005, 12:03 AM |
|
|
Advanced Member
Group: Members
Posts: 2432
Member No.: 4935
Joined: 24-June 03
|
| QUOTE | | * Currently displayed frame was not updated after a reload (F2). |
that's cool.
i wanted to mention this, but i didn't found it too big of an issue. i need to scroll anyway, to see if my temp.smoothers removed the noise.
--------------------
my signature:
 |
|
| fccHandler |
| Posted: Jul 12 2005, 05:41 PM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
This minor bug is still there: Hitting Nextkey and Prevkey in an MPEG file, it thinks the frame is a B-frame.
--------------------
May the FOURCC be with you... |
|
| phaeron |
| Posted: Jul 13 2005, 04:21 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
I think that's actually a display bug. The frame it jumps to is correct, but the frame number is being doubly translated from display order to decode order.
|
|
| fccHandler |
| Posted: Jul 13 2005, 07:23 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
| QUOTE (phaeron @ Jul 13 2005, 12:21 AM) | | I think that's actually a display bug. |
I know it is, because we discussed it at the end of this thread.
Senile much?
j/k my friend! 
--------------------
May the FOURCC be with you... |
|
| jdcooke1 |
| Posted: Jul 20 2005, 04:53 PM |
|
|
Unregistered
|
" Currently displayed frame was not updated after a reload (F2)."
Yes, thank you for this, it helps when working with AviSynth.
take care
jdc
|
|
| fccHandler |
| Posted: Aug 6 2005, 08:45 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
I have a bug to report, at least I think it's a bug. You'll need an AVI with stereo MP3 audio to reproduce it:
- Open AVI
- Set Video to Direct Stream Copy
- Set Audio to Full Processing Mode
- In Audio / Conversion, click "Mono"
- In Audio / Compression, click MPEG Layer-3 and select any mono format.
When I try to save the file, I get "Error initializing audio stream decompression: The requested conversion is not possible."
That doesn't seem right, because intuitively I thought this was the correct™ way to convert stereo MP3 to mono MP3 in VirtualDub. And if I now go back and click the "No change (stereo)" option in the conversion dialog and try to save again, it works.
My installed MP3 codec is the Fraunhofer codec which comes with WMP10.
--------------------
May the FOURCC be with you... |
|
| phaeron |
| Posted: Aug 6 2005, 07:52 PM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Hmm, I couldn't reproduce that. Mind telling me the audio format of the source file and of selected output?
I did find and fix another bug for 1.6.10 that caused compression errors to be tagged as decompression errors, but it's still an error, so the fix wouldn't really have helped here.
|
|
| fccHandler |
| Posted: Aug 7 2005, 12:22 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
I put a test AVI here. It was created in VirtualDub 1.6.9 using my current MP3 codec, and it fails in the manner previously described.
The output format I've been selecting is:
"MPEG Layer-3"
64 kBit/s, 44100 Hz, Mono, 8KB/s
Format ID: 0x0055
Bytes per block: 1 bytes
Data rate: 8000 bytes/sec
Granularity: 8000.0 blocks/sec
But since last night I'm noticing that ALL of the MP3 formats fail if the "Mono" button is selected in Audio / Conversion. It's strange that you can't reproduce it, because the error is very consistent here. Could the codec cause it? Right-clicking on my l3codecp.acm identifies it as version 3.3.0.44, Copyright © 2004 Fraunhofer IIS.
If I get time tonight I'll try to track it down in the debugger. (Currently I'm busy investigating whether I want to code some feature i4004 requested...)
--------------------
May the FOURCC be with you... |
|
| fccHandler |
| Posted: Aug 7 2005, 02:32 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
I did a trace, and here's what happens in w32audiocodec.cpp...
It calls acmStreamOpen() at least twice:
The first time it passes the stereo MP3 source format and a 16-bit stereo PCM destination format, and receives a decompressor handle from FhG. So far so good.
The second call (to fetch a compressor) is the one that fails. It passes an 8-bit mono PCM source format, and the mono MP3 destination format I chose in the "Compression" dialog. But I'm guessing the FhG codec doesn't support 8-bit PCM, so it fails.
(That also explains why ALL of the destination formats fail, because it's actually the source format that is objectionable.)
Selecting "Precision = 16-bit" in the Audio / Conversion dialog fixes it, but IMHO something's not right about this scenario. Why would it ask the decompressor to produce 16-bit PCM, then ask the compressor to accept 8-bit PCM?
I'm still mystified that you couldn't reproduce it. Perhaps you have installed an MP3 codec that accepts 8-bit PCM?
--------------------
May the FOURCC be with you... |
|
| Moitah |
| Posted: Aug 7 2005, 03:49 AM |
|
|
Advanced Member
Group: Members
Posts: 210
Member No.: 8955
Joined: 20-February 04
|
Small feature request: it would be nice if you could use Ctrl+C to copy from the box with the frame number/time at the bottom of VirtualDub's main window instead of having to right click -> "Copy". |
|
| Moitah |
| Posted: Aug 11 2005, 04:50 AM |
|
|
Advanced Member
Group: Members
Posts: 210
Member No.: 8955
Joined: 20-February 04
|
| QUOTE (Moitah @ Aug 6 2005, 10:49 PM) | | Small feature request: it would be nice if you could use Ctrl+C to copy from the box with the frame number/time at the bottom of VirtualDub's main window instead of having to right click -> "Copy". |
I just realized this would be a problem since Ctrl+C is already assigned to copying frames. But here's an idea: when Ctrl+C is pressed, if text is highlighted in the IDC_FRAME box, copy from there (and unhighlight the text), and if not have it work as before (shortcut for Edit menu -> Copy). |
|
| phaeron |
| Posted: Aug 11 2005, 06:40 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
@fccHandler:
Still unable to repro. I was using l3codeca.acm to test, but I installed WMP10 to get l3codecp.acm just for you. (Nice of Microsoft to display an MSN Music EULA dialog with a non-functional "I Decline" button.) The l3codecp version is the same as yours. I can't think of a reason why 8-bit would get snuck in there. Can you trace up the stack and determine where the 8-bit PCM format is coming from?
@Moitah:
I'm not comfortable with the idea of keyboard focus sensitive keystrokes in the main window — especially since you wouldn't think of the read-only timestamp window as accepting input. Visual Studio .NET does this all over the place, where the menus and keyboard shortcuts change furiously whenever you click on various components, and it's really disconcerting. |
|
| fccHandler |
| Posted: Aug 12 2005, 12:05 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
| QUOTE (phaeron @ Aug 11 2005, 02:40 AM) | | Can you trace up the stack and determine where the 8-bit PCM format is coming from? |
Looks like it comes from the AudioStreamConverter constructor, which is being called from line 767 of Dub.cpp. I set a breakpoint there and saw it pass "is_16bit" = false to the constructor. That seems to cause the Converter to output 8-bit audio. Does it not do this on your system?
--------------------
May the FOURCC be with you... |
|
| phaeron |
| Posted: Aug 12 2005, 05:32 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Aha, now I know what's going on. The audio converter converts interleaved samples, so it has to convert both precision and channel count at the same time. In order to still allow you to change only one of the parameters, code attempts to fill in the "no change" parameter with the source value. Except that it does it based on the compressed source, for which wBitsPerSample is not accurate. This change to dub.cpp should do the trick:
| CODE | if (!bUseAudioFilterGraph) {
// Attach a converter if we need to...
if (aInfo.converting) {
+ bool is_16bit = aInfo.is_16bit;
+ // fix precision guess based on actual stream output if we are not changing it
+ if (opt->audio.newPrecision == DubAudioOptions::P_NOCHANGE)
+ is_16bit = audioStream->GetFormat()->wBitsPerSample > 8;
if (aInfo.single_channel)
audioStream = new_nothrow AudioStreamConverter(audioStream, is_16bit, aInfo.is_right, true);
|
There are still some UI issues related to the precision being predicted incorrectly, but this should stop the error.
|
|
