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. |
18th August 2016, 23:21 | #2301 | Link |
47.952fps@71.928Hz
Join Date: Mar 2011
Posts: 940
|
Phew. So many updates for a lot of stuff.
I love the progress. A lot. Everything looks so promising. Great work, guys. The world is changing.
__________________
Win10 (x64) build 19041 NVIDIA GeForce GTX 1060 3GB (GP106) 3071MB/GDDR5 | (r435_95-4) NTSC | DVD: R1 | BD: A AMD Ryzen 5 2600 @3.4GHz (6c/12th, I'm on AVX2 now!)
|
18th August 2016, 23:33 | #2302 | Link | |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Quote:
__________________
AviSynth+ |
|
19th August 2016, 04:45 | #2303 | Link | |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
Quote:
What was giving me best performance was running Avisynth with 4 or 8 threads and splitting out the work between 2 DX engines (which saturates the GPU). Something is now different in the way memory behaves, but I can't pin-point what's different. |
|
19th August 2016, 13:06 | #2304 | Link |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Wow, I didn't think that the original nnedi was still being used.
Anyway, this bug report is retarded. - No mentioning of the Avisynth+ revision used - No script - No client with which the error occurred specified - Access violation in which module? Since you consider yourself a programmer, you should know better.
__________________
Groucho's Avisynth Stuff |
19th August 2016, 21:02 | #2306 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,309
|
I have a question about running external plugin. When is the destructor called ? If i have several external filters (from several dll files), is it possible that a destructor of a filter A is called when frames of another filter B are still do be processed (but all frames of A are finished), or are the destructors begin to be called ONLY when ALL the frames of ALL the filters are being processed ? (When everything is finished). This last seems the more logical, but i can't take it for granted.
|
19th August 2016, 21:40 | #2307 | Link |
Registered User
Join Date: Jul 2007
Posts: 552
|
Can someone explain me use cases for 10/12/14 bit pixel types? imho for processing it easier to use either 8-bit or 16-bit if higher precision is needed (there is no point to make processing at >8 and <16 bits as it would have same speed as 16-bit and will need special casing algorithms). Or this pixel types are really 16-bit and this is only metadata which doesn't really change position of most significant bit (i.e. 10-bit have real bits at 6..15 and zeroes at bits 0..5 and not real bits at 0..9 and zeroes at 10..15)? If this is not metadata than I don't understand why ConvertTo16bits() and ConvertTo16bits(bits=10) results in same byte output. Also why ConvertToYUV420/YUV422/YUV444 from 10-bit pixel type results in 16-bit pixel type.
|
19th August 2016, 22:13 | #2308 | Link | |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Quote:
10/12/14 formats follow Microsofts VUV description for higher bit-depths, and store valid bits in the MSBs of the two bytes for each pixel. These formats are not meant for processing in Avisynth, they just exist so that they can be output to (and be read from). So basically only conversion functions will have support for them. If you mean that based on your testing, some 16bit and 10bit conversion functions have the same output, I think that is because the implementation is not yet finished and code is still missing to handle all cases. But pinterf can provide more insight in this matter than me. He's still in the middle of implementation, he only seems inactive recently because he's on holidays with his family.
__________________
AviSynth+ Last edited by ultim; 19th August 2016 at 22:15. |
|
19th August 2016, 22:13 | #2309 | Link | |
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
Quote:
|
|
19th August 2016, 22:43 | #2310 | Link | |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
Quote:
__________________
See My Avisynth Stuff |
|
19th August 2016, 22:52 | #2311 | Link | |
Registered User
Join Date: Jul 2007
Posts: 552
|
Quote:
btw. what the point of this formats i.e. why not always mark them as 16-bit. Last edited by MasterNobody; 19th August 2016 at 22:57. |
|
19th August 2016, 23:17 | #2312 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
The individual 10/12/14 pix_fmt constants (AVS_CS_YUV422P10, etc.) are there mostly to ease auto-selection with applications like FFmpeg so the user doesn't have to second-guess swscale/avutil. For example, AVS_CS_YUV422P10 is directly matched to AV_PIX_FMT_YUV422P10 in the libavformat AviSynth demuxer, and there's no need for the user to invoke -pix_fmt and override anything. That's what the intention was for those constants.
Also, because existing implementations (f3kdb*, Dither**) are capable of outputting those depths directly, so the reconstituted output is reported as the same depth, given to FFmpeg as the same depth, and processed there in the same depth. *output_depth parameter *Dither_quantize Last edited by qyot27; 19th August 2016 at 23:26. |
19th August 2016, 23:33 | #2313 | Link | |
Registered User
Join Date: Jul 2007
Posts: 552
|
Quote:
|
|
20th August 2016, 00:09 | #2314 | Link | |
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
Quote:
Code:
/** * The following 12 formats have the disadvantage of needing 1 format for each bit depth. * Notice that each 9/10 bits sample is stored in 16 bits with extra padding. * If you want to support multiple bit depths, then using AV_PIX_FMT_YUV420P16* with the bpp stored separately is better. */ ... AV_PIX_FMT_YUV420P10BE,///< planar YUV 4:2:0, 15bpp, (1 Cr & Cb sample per 2x2 Y samples), big-endian AV_PIX_FMT_YUV420P10LE,///< planar YUV 4:2:0, 15bpp, (1 Cr & Cb sample per 2x2 Y samples), little-endian |
|
20th August 2016, 10:06 | #2315 | Link | |
Registered User
Join Date: Jul 2007
Posts: 552
|
Quote:
Code:
/** * Number of least significant bits that must be shifted away * to get the value. */ int shift; Code:
[AV_PIX_FMT_YUV420P10LE] = { .name = "yuv420p10le", .nb_components = 3, .log2_chroma_w = 1, .log2_chroma_h = 1, .comp = { { 0, 2, 0, 0, 10, 1, 9, 1 }, /* Y */ { 1, 2, 0, 0, 10, 1, 9, 1 }, /* U */ { 2, 2, 0, 0, 10, 1, 9, 1 }, /* V */ }, .flags = AV_PIX_FMT_FLAG_PLANAR, }, [AV_PIX_FMT_YUV420P10BE] = { .name = "yuv420p10be", .nb_components = 3, .log2_chroma_w = 1, .log2_chroma_h = 1, .comp = { { 0, 2, 0, 0, 10, 1, 9, 1 }, /* Y */ { 1, 2, 0, 0, 10, 1, 9, 1 }, /* U */ { 2, 2, 0, 0, 10, 1, 9, 1 }, /* V */ }, .flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_PLANAR, }, Last edited by MasterNobody; 20th August 2016 at 10:10. |
|
20th August 2016, 14:19 | #2316 | Link | |
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
You are right: plane = 0/1/2, step = 2 (2 bytes for a pixel), offset = 0, shift = 0, depth = 10 (and the last three members are deprecated).
That's confusing. So the layout is not conform the s274m standard where it is stored in the MSB: Quote:
Last edited by Wilbert; 20th August 2016 at 14:26. |
|
20th August 2016, 14:33 | #2317 | Link | |
Registered User
Join Date: Mar 2015
Posts: 775
|
Quote:
"NOTE -- This scaling places the extrema of R′, G′, B′, and Y′components at codewords 64 and 940 in a ten-bit representation" |
|
20th August 2016, 19:11 | #2318 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
Considering the fact that the FFmpeg patch produces a correct image when the AV_PIX_FMT_* and corresponding AVS_CS_* constants are tethered together, either the formats are not different and there's a breakdown in the description(s) somewhere, or any differences between them are trivial and ultimately do not matter. The conversion routines inside AviSynth+ haven't been completely fleshed out*, but using the external plugins that can resample and scale bitdepth, the content can be reconstructed into a proper image.
*this is what I mean (all seen through opening the script in ffplay): Version().ConvertToYV12().ConvertTo16bit() = correct image Version().ConvertToYV12().ConvertTo16bit(bits=10) = hot pink and white incorrect image Version().ConvertToYV12().f3kdb(output_depth=10,output_mode=2).ConvertFromDoubleWidth(10) = correct image Version().ConvertToYV12().Dither_convert_8_to_16().Dither_quantize(10,reducerange=true).Dither_out().ConvertFromDoubleWidth(10)>test.avs = correct image Also consistent with these results, is that using a value in ConvertFromDoubleWidth that does not match what the clip was scaled to in f3kdb or Dither results in an incorrect image. Last edited by qyot27; 20th August 2016 at 19:14. |
20th August 2016, 19:22 | #2319 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
What's probably happening is that ConvertTo16bit() is just simply outputting the wrong depth/byte size/memory location for anything other than 16 - in other words, that particular filter has a bug/is still WIP and needs to be fixed for 10/12/14. The vi.BitsPerPixel values that the libavformat demuxer relies on are correctly sized for X bit depth and do report the right sizes.
|
21st August 2016, 13:00 | #2320 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Quote:
|
|
Thread Tools | Search this Thread |
Display Modes | |
|
|