|
|
| fccHandler |
 Posted: Nov 3 2003, 06:45 PM |
 |
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
| QUOTE |
Current build (1.5.8, stable):
[features added]
* DirectDraw support is disabled when Terminal Services
or Remote Desktop clients are detected to work around
a DirectX clipping bug.
* Re-enabled places bar on open and save dialogs.
* Disabled FPU state warning and made the fixup silent.
WAY too many drivers are screwing up the FPU unit.
* Edit lists can now be omitted from configuration
files without needing to close the source file.
[bugs fixed]
* Main window is disabled during MPEG-1 scan to prevent
crash if main window is closed.
* Previous-key and next-key movement commands were not
correct for B-frames in an MPEG-1 file.
* Fixed decoding of MPEG-1 B-frames at the start of
GOPs with broken_link set.
* Palette change blocks no longer appear as garbage
video streams. In-stream palette changes are still
not supported, however.
* biSizeImage was incorrect when using fast recompress
in YV12 mode.
* Sequence appends failing on the first file now throw
an error rather than a warning.
[regressions fixed]
* A race condition in the fast write code occasionally
resulted in spurious write errors.
* Fixed swapped 00db/00dc tags in AVI output.
* Fixed display of 8-bit paletted video.
* Program starts under Windows 95 again.
|
http://www.virtualdub.org
--------------------
May the FOURCC be with you... |
|
| Morsa |
| Posted: Nov 3 2003, 08:30 PM |
|
|
Moderator of the Vdub support board
Group: Moderators
Posts: 640
Member No.: 246
Joined: 9-September 02
|
Looking at the new specs, etc at Phaeron's page, I wonder if someday an output with 10 bit per color channel would be supported, at least at image sequence level.
I know it sounds stupid now, but remember my begging for PNG output for Vdub.The only one that payed attention was Suiryc (from VdubMod at its beginning).
Now I see it is the Hot topic!!
I ask for room for adding 10 bit support because every graphic card and TFT (including TV's) is moving that way, needless to say video formats too(Digital Betacam, HDCAM SR,Mpeg2, even DV 10 bit is being discussed!). |
|
| i4004 |
| Posted: Nov 3 2003, 09:42 PM |
|
|
Advanced Member
Group: Members
Posts: 2432
Member No.: 4935
Joined: 24-June 03
|
| QUOTE (Morsa @ Nov 3 2003, 10:30 PM) | Now I see it is the Hot topic!!
|
for whom?
also,since when do display devices work directly with bits
(no matter how much of them)?
are your tubes doing bits?
tft's?
but sure,if it'll make better images make them 64bit per channel (  )
--------------------
my signature:
 |
|
| Morsa |
| Posted: Nov 4 2003, 02:42 AM |
|
|
Moderator of the Vdub support board
Group: Moderators
Posts: 640
Member No.: 246
Joined: 9-September 02
|
???? What are you talking about?
This has nothing to be with bits and tubes, blah,blah,blah...
TFT= LCD display. |
|
| fccHandler |
| Posted: Nov 4 2003, 05:09 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
@phaeron:
Regarding the new "fast recompress" YV12 support, I noticed that VirtualDub 1.5.8 queries for UYVY, YUYV and YUY2 before checking YV12. But shouldn't the YV12 query come first? My logic is, if a codec supports YV12 at all, then it is probably the native color space of the compressor. (MPEG-1 -2 and -4, for example.) AFAIK it would be extremely rare if a codec (like Huffyuv) which uses the other formats internally would also support decompression to YV12, via downsampling or whatever. In fact, I can't think of any case where querying YV12 before the other formats would be a bad idea.
I guess my real gripe is, in the current Dub code it seems unlikely that YV12 will ever get used, since MPEG-1, -2, DivX, and XviD (all native YV12 codecs) will return success for one of those other non-native formats first.
--------------------
May the FOURCC be with you... |
|
| i4004 |
| Posted: Nov 4 2003, 05:37 AM |
|
|
Advanced Member
Group: Members
Posts: 2432
Member No.: 4935
Joined: 24-June 03
|
| QUOTE (Morsa @ Nov 4 2003, 04:42 AM) | ???? What are you talking about?
This has nothing to be with bits and tubes, blah,blah,blah...
TFT= LCD display. |
you said
"I ask for room for adding 10 bit support because every graphic card and TFT (including TV's) is moving that way"
and i said that tubes and display devices are not workign with bits directly.....do correct me if i'm wrong....the bits don't light up the screen....rgb light emitters do...
.........
anyhow,why do you need 10 bit support?
--------------------
my signature:
|
|
| phaeron |
| Posted: Nov 4 2003, 05:46 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
YV12 should be chosen when Avisynth outputs it directly. I didn't move it above UYVY/YUY2 because those are more stable in codecs than YV12, and you can't currently choose between them. YV12 support in general will improve in the next experimental version, which supports YV12 natively in its image library and can use YV12 overlays.
Turns out there is another new screwup in this version: VDFastMemcpyPartialMMX2 in system/source/a_memory.asm is missing a "neg ecx" instruction that causes it to crash PIII+/Athlon+ systems if the display row width isn't a multiple of 8 bytes. It needs to go right before "rep movsb." Arrgh.
So, new release, same time next week? I guess I'll get to roll in Suiryc's "move to next key" fix now.... 
|
|
| Suiryc |
| Posted: Nov 5 2003, 01:27 PM |
|
|
Developer of VirtualdubMod
Group: VirtualdubMod Team
Posts: 222
Member No.: 468
Joined: 10-October 02
|
| QUOTE | fccHandler
Regarding the new "fast recompress" YV12 support, I noticed that VirtualDub 1.5.8 queries for UYVY, YUYV and YUY2 before checking YV12. But shouldn't the YV12 query come first? My logic is, if a codec supports YV12 at all, then it is probably the native color space of the compressor. (MPEG-1 -2 and -4, for example.) AFAIK it would be extremely rare if a codec (like Huffyuv) which uses the other formats internally would also support decompression to YV12, via downsampling or whatever. In fact, I can't think of any case where querying YV12 before the other formats would be a bad idea. |
| QUOTE | phaeron
YV12 should be chosen when Avisynth outputs it directly. I didn't move it above UYVY/YUY2 because those are more stable in codecs than YV12, and you can't currently choose between them. |
phaeron is right. The main purpose of YV12 is for AviSynth clips which colorspace is YV12. In this case there is no problem.
Checking YV12 first would also be used when both input and output codecs support it ... and you were wondering when it could be a bad idea.
I can tell you a case where checking YV12 first is bad, and that's with .... guess what ? DivX 5 \o/
I noticed that the DivX 5 codec (that we devel all love since the 5.1 version :>) would answer 'OK' when being asked (VfW) to decompress/recompress in YV12 (i.e. your input video is DivX 3/4/5 and you recompress to DivX 5). But the codec would screw up the video channels (maybe decompressing to I420 instead of YV12, dunno) and giving a 'blue-tinted' clip.
We (in VirtualDubMod) ask for YV12 first ;p, so we had to somewhat disable decompressing/recompressing of DivX video using YV12 
| QUOTE | phaeron
So, new release, same time next week? I guess I'll get to roll in Suiryc's "move to next key" fix now.... |
 Well I happened to notice this bug and proposed a fix .. but you found a better and easier fix
--------------------
OGM tools, VirtualDubMod [SourceForge : Tracker/DL] (FAQ)
Don't forget the Needed DLLs for VirtualDubMod. Post bugs/requests in our Tracker.
We give 100% of your donations to the Open Source community |
|
| fccHandler |
| Posted: Nov 5 2003, 03:57 PM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
| QUOTE (Suiryc @ Nov 5 2003, 09:27 AM) | Checking YV12 first would also be used when both input and output codecs support it ... and you were wondering when it could be a bad idea.
I can tell you a case where checking YV12 first is bad, and that's with .... guess what ? DivX 5 \o/
I noticed that the DivX 5 codec (that we devel all love since the 5.1 version :>) would answer 'OK' when being asked (VfW) to decompress/recompress in YV12 (i.e. your input video is DivX 3/4/5 and you recompress to DivX 5). But the codec would screw up the video channels (maybe decompressing to I420 instead of YV12, dunno) and giving a 'blue-tinted' clip.
We (in VirtualDubMod) ask for YV12 first ;p, so we had to somewhat disable decompressing/recompressing of DivX video using YV12 |
I just tried a DivX 5.0.5 to DivX 5.0.5 fast recompress in my version (which checks YV12 first) and there was no problem. I know it used YV12 because the input window was blank during the recompression. Whatever "screwed up" colors you saw, they seem to have fixed it.
--------------------
May the FOURCC be with you... |
|
| sh0dan |
| Posted: Nov 13 2003, 09:12 AM |
|
|
Avisynth Developer
Group: Vdubmod Alpha Testing Team
Posts: 41
Member No.: 327
Joined: 20-September 02
|
IIRC the last version that had this problem was DivX 5.02.
|
|
| Suiryc |
| Posted: Nov 13 2003, 04:23 PM |
|
|
Developer of VirtualdubMod
Group: VirtualdubMod Team
Posts: 222
Member No.: 468
Joined: 10-October 02
|
Maybe.
After 2-3 versions having the same problem I gave up testing DivX each time
--------------------
OGM tools, VirtualDubMod [SourceForge : Tracker/DL] (FAQ)
Don't forget the Needed DLLs for VirtualDubMod. Post bugs/requests in our Tracker.
We give 100% of your donations to the Open Source community |
|
