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. |
10th January 2017, 17:12 | #2821 | Link | ||
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,316
|
Quote:
Quote:
Thanks for your work on this upgraded version. I've tested only the modes avaibles on the Decode format menu, that's why i've tested 16 bits 4:2:0. Thanks for the links with all VDubMod version. Last edited by jpsdr; 10th January 2017 at 17:25. |
||
10th January 2017, 17:19 | #2822 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
New test build
Avisynth plus r2372-dev 20170110 r2372dev (vdubmod14 VfW test)
Last edited by pinterf; 10th January 2017 at 22:29. Reason: VDubHack |
10th January 2017, 17:43 | #2823 | Link | |
Registered User
Join Date: Mar 2015
Posts: 775
|
Quote:
video data is too short (w*h*6 bytes, should be w*h*8 bytes) > Note: OPT_VDubPlanarHack=true may still be needed for Virtualdub for YUV planar outputs other than YV12 or else U and V planes are exchanged I dont know, who is guilty? The Y3[10][10] output works with magic, but requires hack with avs+
__________________
VirtualDub2 |
|
10th January 2017, 17:50 | #2825 | Link | |
Registered User
Join Date: Mar 2015
Posts: 775
|
Quote:
But I have to apply it now, is this expected?
__________________
VirtualDub2 |
|
10th January 2017, 20:50 | #2826 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
1.) OK, Y416 is now really done but cannot test, vdub says: XYUV64 output is not implemented. Using vdubmod 38494.
2.) (plane hack) It looks something like this in the avs source Code:
// Old VDub wants YUV for YV24 and YV16 and YVU for YV12. if (parent->VDubPlanarHack && !vi.IsYV12()) { plane1 = PLANAR_U; plane2 = PLANAR_V; } else { // Set default VFW output plane order. plane1 = PLANAR_V; plane2 = PLANAR_U; } |
10th January 2017, 21:39 | #2827 | Link | |||
Registered User
Join Date: Mar 2015
Posts: 775
|
"XYUV64 output is not implemented" is message from output (dubbing) part, why you see it?
Has nothing to do with raw/avs input. I think there is misunderstanding, Y3[10][16] is not 16-bit YV16, it has YUV plane order while YV16 has YVU plane order. Quote:
Quote:
Quote:
There is no reason for Y3[10][16] to be affected by VDubPlanarHack since it is brand new fourcc.
__________________
VirtualDub2 |
|||
10th January 2017, 21:56 | #2829 | Link |
Registered User
Join Date: Mar 2015
Posts: 775
|
Thanks, I too often forget about play button.
__________________
VirtualDub2 |
10th January 2017, 22:04 | #2830 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
Quote:
instead of !vi.IsYV12() In the 8 bit world the latter was enough. What about YV411? (Y41B) |
|
11th January 2017, 01:07 | #2832 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,316
|
Something came to my mind, i've checked in avisynth.h and didn't see any information about it.
Standard/normal YUV mode is 16..235 for Y and 16..240 for UV. You can have a "full range" mode, but it's "unusual" or not the standard. VDub has in its color mode a difference for the YUV mode between full range or limited range. I didn't see anything like this in avisynth. Have i missed it (in that case where is it), or is it just that there is not a such thing ? If there is not something to chose between full or limited range, can we assume that the behavior in this case is the standard/common behavior, meaning the limited range ? What are the specifications for the extended bit range ? Are they also limited, or are they just only full range by default ? If limited, how is the range ? Is it proportional (16-240 becomes 4096-61440 in 16 bits) or fixed (16-240 becomes 16-65520 in 16 bits) ? That make me realise that since the begining, at least the resample and nnedi3 filters are prone to produce incorrect results, as they clip only to 0-255, meaning they can produce out of range values in case of YUV data (but not in case of RGB data, of course). So, what is exactly the situation about these points ? |
11th January 2017, 01:54 | #2833 | Link |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
Avisynth has functions to convert between full and limited range (just pointing that out, because it does seem like you might have somehow missed this) but does not have metadata flagging to keep track of which range a given clip has.
YUV limited range ("TV range") numerical limits for bitdepths above 8 are quite well-defined (see f.ex. the H.264 standard). For any bitdepth, the luma offset is Code:
16 * (2^(bitdepth - 8)) Code:
219 * (2^(bitdepth - 8)) Full range YUV on the other hand isn't well defined at all. It's been discussed extensively in this thread before, see here and a number of posts forward. Last edited by TheFluff; 11th January 2017 at 02:09. |
11th January 2017, 09:42 | #2834 | Link | |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,316
|
Quote:
Thanks for the others informations. Last edited by jpsdr; 11th January 2017 at 11:32. |
|
11th January 2017, 13:35 | #2835 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
Quote:
I tried with this simplified script: Code:
Colorbars(pixel_type="YV12") SetFilterMTMode("FFT3dGPU", 3) FFT3DGPU(sigma=4,bt=3) Prefetch(6) This was already mentioned, related link: https://forum.doom9.org/showthread.p...25#post1671525 Debug log with Prefetch(6) until the sad finish, which occured in fft3dgpu.dll when frame number 7 was requested from it. Code:
ColorBars::GetFrame 0 ColorBars::GetFrame 3 ColorBars::GetFrame 2 ColorBars::GetFrame 1 ColorBars::GetFrame 1 ColorBars::GetFrame -1 ColorBars::GetFrame 5 ColorBars::GetFrame 4 ColorBars::GetFrame 4 ColorBars::GetFrame 4 ColorBars::GetFrame 2 ColorBars::GetFrame 1 ColorBars::GetFrame 0 ColorBars::GetFrame 6 ColorBars::GetFrame 4 ColorBars::GetFrame 6 ColorBars::GetFrame 5 ColorBars::GetFrame 7 ColorBars::GetFrame 1 ColorBars::GetFrame 0 ColorBars::GetFrame 7 ColorBars::GetFrame 8 ColorBars::GetFrame 3 ColorBars::GetFrame 7 Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 2 child=007302F8 frame=0A4BF9E8 vfb=0900AEF8 videoCacheSize=0 SeekTime :0.068393 Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 1 child=007302F8 frame=0A4BF8B0 vfb=006B6D20 videoCacheSize=0 SeekTime :0.069542 ColorBars::GetFrame 2 ColorBars::GetFrame 6 ColorBars::GetFrame 13 ColorBars::GetFrame 1 Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 6 child=007302F8 frame=0A4BFAB8 vfb=0900AEB8 videoCacheSize=0 SeekTime :0.075657 ColorBars::GetFrame 8 Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 0 child=007302F8 frame=0A4BFA50 vfb=0900C178 videoCacheSize=0 SeekTime :0.077987 Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 4 child=007302F8 frame=0A4BF918 vfb=0900A4F8 videoCacheSize=0 SeekTime :0.078408 Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 3 child=007302F8 frame=0A4BF980 vfb=0900C1B8 videoCacheSize=0 SeekTime :0.078792 Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 5 child=007302F8 frame=0A4BFB20 vfb=0900ADF8 videoCacheSize=0 SeekTime :0.078573 ColorBars::GetFrame 8 Exception thrown at 0x02DF1FDA (FFT3dGPU.dll) in AVSMeter.exe: 0xC0000005: Access violation reading location 0x00000000. This post got a bit long, but interesting to see what happens in the background: Without Prefetch (non-MT): Code:
ColorBars::GetFrame -1 ColorBars::GetFrame 0 ColorBars::GetFrame 1 ColorBars::GetFrame 0 ColorBars::GetFrame 2 Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 0 child=090A34B0 frame=005CF580 vfb=08E3F838 videoCacheSize=0 SeekTime :0.025495 ScriptEnvironment::GetNewFrame NEW METHOD EXACT hit! VideoFrameListSize= 1 GotSize= 460831 FrReg.Size= 1 vfb=08E3F838 frame=005CF580 SeekTime:0.000010 frame 005CF580 RowSize=640 Height=480 Pitch=640 Offset=24 ScriptEnvironment::GetNewFrame returning frame. VideoFrameListSize was 1 ColorBars::GetFrame 1 ColorBars::GetFrame 3 Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 1 child=090A34B0 frame=005CF580 vfb=08E3F838 videoCacheSize=0 SeekTime :0.006794 ScriptEnvironment::GetNewFrame NEW METHOD EXACT hit! VideoFrameListSize= 1 GotSize= 460831 FrReg.Size= 1 vfb=08E3F838 frame=005CF580 SeekTime:0.000006 frame 005CF580 RowSize=640 Height=480 Pitch=640 Offset=24 ScriptEnvironment::GetNewFrame returning frame. VideoFrameListSize was 1 ColorBars::GetFrame 2 ColorBars::GetFrame 4 Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 2 child=090A34B0 frame=005CF580 vfb=08E3F838 videoCacheSize=0 SeekTime :0.006903 ScriptEnvironment::GetNewFrame NEW METHOD EXACT hit! VideoFrameListSize= 1 GotSize= 460831 FrReg.Size= 1 vfb=08E3F838 frame=005CF580 SeekTime:0.000016 frame 005CF580 RowSize=640 Height=480 Pitch=640 Offset=24 ScriptEnvironment::GetNewFrame returning frame. VideoFrameListSize was 1 ColorBars::GetFrame 3 ColorBars::GetFrame 5 Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 3 child=090A34B0 frame=005CF580 vfb=08E3F838 videoCacheSize=0 SeekTime :0.006695 ScriptEnvironment::GetNewFrame NEW METHOD EXACT hit! VideoFrameListSize= 1 GotSize= 460831 FrReg.Size= 1 vfb=08E3F838 frame=005CF580 SeekTime:0.000005 frame 005CF580 RowSize=640 Height=480 Pitch=640 Offset=24 ScriptEnvironment::GetNewFrame returning frame. VideoFrameListSize was 1 ColorBars::GetFrame 4 ColorBars::GetFrame 6 Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 4 child=090A34B0 frame=005CF580 vfb=08E3F838 videoCacheSize=0 SeekTime :0.005836 ScriptEnvironment::GetNewFrame NEW METHOD EXACT hit! VideoFrameListSize= 1 GotSize= 460831 FrReg.Size= 1 vfb=08E3F838 frame=005CF580 SeekTime:0.000005 frame 005CF580 RowSize=640 Height=480 Pitch=640 Offset=24 ScriptEnvironment::GetNewFrame returning frame. VideoFrameListSize was 1 ColorBars::GetFrame 5 ColorBars::GetFrame 7 Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 5 child=090A34B0 frame=005CF580 vfb=08E3F838 videoCacheSize=0 SeekTime :0.006020 ScriptEnvironment::GetNewFrame NEW METHOD EXACT hit! VideoFrameListSize= 1 GotSize= 460831 FrReg.Size= 1 vfb=08E3F838 frame=005CF580 SeekTime:0.000005 frame 005CF580 RowSize=640 Height=480 Pitch=640 Offset=24 ScriptEnvironment::GetNewFrame returning frame. VideoFrameListSize was 1 ColorBars::GetFrame 6 ColorBars::GetFrame 8 |
|
11th January 2017, 15:12 | #2836 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
New dev build
Avisynth Plus r2380-dev 20170111 r2380
Now practically all color formats can be shown in vdubmod. If a specific bitdepth does not exist, it will be converted on-the-fly, and some alternative output formats can be hinted with OPT_xxx variables. For details see readme. (I'd like to separate github releases from these 'daily' builds. Albeit this version is quite usable, there were huge refactorizations and earthquake e.g. in Overlay, so I'd like to wait a bit more) |
11th January 2017, 18:50 | #2837 | Link | |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
Quote:
Planar RGB (components can be kept in separate memory blocks, the same pixel will have the same offset in all components, needs to be calculated only once per pixel): Code:
RRRR...RRRR GGGG...GGGG BBBB...BBBB Code:
(R,G,B)(R G,B)(R,G B)(R,G,B) ... Code:
(R,G,B,A) (R,G,B,A) (R,G,B,A) ... Last edited by LigH; 11th January 2017 at 19:01. |
|
11th January 2017, 19:13 | #2838 | Link |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
VS only supports packed RGB for backwards compatibility with Avisynth and for output. Internally in a filtering framework there is no reason whatsoever to ever use packed. Just unpack on input and pack on output if you have to - my gut feeling says that for any but the most trivial filters that's going to be insignificantly slower than filtering packed (and you can drop a dumb extra code path too). There are most likely no particularly useful or interesting RGB only filters anyway, so breaking things shouldn't be a big deal.
|
11th January 2017, 22:45 | #2839 | Link |
Registered User
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 805
|
But what is the point then in using packed in Avisynth, which is about processing video, not displaying it? If the input serves packed, then immediately "unpack" it. And pack it again for the output if needed.
Is there any reason for the user to ever convert to packed RGB? And if there are rare cases, why not just have one type of planar "ConvertToRGB24" (/32/48/64) function, and require "packed=true" for packed? It's easier to remember from previous experience that RGB48 is 16-bit per component RGB without alpha, than remembering whatever the name of the planar versions are (tried to google them for this post, but didn't find them fast enough). Having everything the same type (planar?) makes things easier for the user. Last edited by ajp_anton; 11th January 2017 at 22:48. |
11th January 2017, 23:09 | #2840 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
Many VfW compatible tools don't support planar RGB. They can't handle it. It was not supported by Microsoft in a blank installation of most Windows versions (I am not even sure if there are any supporting VfW codecs as of today). I would even believe, if the semi-pro home users did not insist in it, hardly any professional software company would have cared about it... So, for ancient compatibility's sake, AviSynth still must be able to output packed RGB. The most compatible way of displaying images in Windows, DIB = "Device Independent Bitmaps", was invented with packed-pixel RGB and palette formats only, AFAIK. Planar RGB is a rather recent invention, I believe...
YUV based formats are useful for real-life content, whereas RGB based formats are common for computer generated content. Just imagine screen recordings of a game or an application's user interface. Recording that in a YUV based format, especially with the most common 4:2:0 chroma subsampling and TV range, would limit the color saturation and chrominance resolution, blurring and fading 1-pixel wide colored lines. |
|
|