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. |
17th April 2019, 21:44 | #841 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
Yes, the additional gray frame is just virtual, it was already so in Avery Lee's original, for a reason ... I believe you have to be able to set the end of a cut range behind the last frame to be exported.
|
18th April 2019, 00:34 | #842 | Link |
Registered User
Join Date: Mar 2015
Posts: 775
|
This was mentioned few pages back
There is "zoom timeline" mode which can be handy for other purposes but you can also do this: right after opening source press Go->Zoom selection. The virtual frame will be out of reach.
__________________
VirtualDub2 |
19th April 2019, 02:48 | #844 | Link |
Formerly davidh*****
Join Date: Jan 2004
Posts: 2,496
|
It's because setting an in-point is inclusive (the frame selected will be in the trimmed clip) but the out-point is exclusive (the frame selected will NOT be in the trimmed clip). This makes a certain amount of sense from a mathematical point of view - if you want a 50-frame clip, you select your in-point, then jump ahead 50 frames and selected your out-point.
Avisynth's in- and out-points are both inclusive, which is why trim(0,100) produces a 101-frame clip, not a 100-frame clip. That feels less sensible to me. |
1st May 2019, 12:57 | #845 | Link |
Registered User
Join Date: Mar 2015
Posts: 775
|
New build (43602), took a bit long to arrive.
In "other fixes" addressing some issues raised in the thread: 1) Blending inaccuracy in fflayer filter: fixed. (The original question was about logo, it still has the problem). 2) Quick saving of images: the File->Save image now offers unique (numbered) filename, also File->Save image (skip dialog) shortens the operation even more. 3) FFMPEG's compression options don't work with Fast recompress Mode: fixed.
__________________
VirtualDub2 |
13th May 2019, 18:48 | #846 | Link |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
Could we have ProRes presets updated so they better match official profiles (in this case ProRes_ks is better). It will be slower, but more Apple alike.
We need color tag as well, so parameters like this for ProRes HQ: -metadata:s "encoder=Apple ProRes 422 (HQ)" -vendor apl0 -movflags write_colr -c:v prores_ks -flags "+bitexact" Then also have interlaced box (+field order) to tick which adds: -vf "setfield=1, fieldorder=tff" -top 1 -flags "+ildct+ilme+bitexact" *tff or bff (and top 1 or 0) This way we enforce proper interlaced encoding. I'm not sure about this bit, but if you can set: AVFormatContext.flags |= AVFMT_FLAG_BITEXACT. |
13th May 2019, 19:56 | #847 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
@shekh
I noticed main menu > File is very large, it might make sense to use some sub menus. The icon looks nice (how did you create it?) and everything scales very well using 288 DPI, I wonder how hard it is doing all this with plain win32, even with advanced layout controls I had many difficulties using WinForms to implement High DPI. Avery Lee is known to be an excellent dev, did you have a good experience working with his code base?
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists |
13th May 2019, 20:09 | #848 | Link | |
Registered User
Join Date: Mar 2015
Posts: 775
|
Quote:
Any hint how to do this? proresenc_kostya.c has prores_quant_matrices, do you mean to change that? > -metadata:s "encoder=Apple ProRes 422 (HQ)" -vendor apl0 -movflags write_colr -c:v prores_ks -flags "+bitexact" From this I understand: -movflags write_colr: ok -vendor apl0: ok "encoder=Apple ProRes 422 (HQ)": can you help with all possible strings? -c:v prores_ks: this is what I used anyway -flags "+bitexact": can you provide any background on what it means? > -vf "setfield=1, fieldorder=tff" -top 1 -flags "+ildct+ilme+bitexact" setfield: ok fieldorder: ok ildct+ilme: ok top: as I read it belongs to chroma location which can have 7 different values. This is disturbing option. I think it is better if it is understood by the pipeline. Wondering how big is this problem? Can you have in practice only 422-top or anything else?
__________________
VirtualDub2 |
|
14th May 2019, 01:05 | #849 | Link | ||
Registered User
Join Date: Mar 2015
Posts: 775
|
Quote:
Quote:
DPI works automatically with standard controls like dialog with fonts and buttons. But it is a lot of trouble when doing any custom graphics. The timeline toolbar (position control) had a lot of scaling issues, I changed big part of its code. Overall IMO working with plain win32 GUI is like assembly, it is very slow to code but the documentation is mostly perfect and it can work. Bitmaps with system colors (like toolbar icons) that can scale: https://github.com/shekh/VirtualDub2....cpp#L132-L161 And then of course I maintain the created bitmap and redo it again if any scaling or system color parameters change. Not too bad thanks to LR_LOADMAP3DCOLORS flag, otherwise would require to decode down to pixels and remap colors. Few dozen more lines of code... In better GUI systems all this is standard function which doesn't need any implementation at all (not sure how is WinForms). Did I have a good experience working with the code base: I had all kinds of experiences. In most part I feel comfortable. I still don't know how to treat library names. Ami, Asuka, Dita, Kasumi and so on. Are these his girls? (ok got it, most likely anime heroes) To me looks like nonsense1, nonsense2, ... I never remember which one I need. I hate almost everything about coding style: use of white space especially tabs, hungarian notation, multi-line parameter lists... I like that the project is easy to build (very few dependencies). I like parts which are very simple, e.g. direct use of win32 API etc.
__________________
VirtualDub2 |
||
14th May 2019, 09:26 | #850 | Link | |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
Quote:
You control it with -profile:v flag. Options are here: https://ffmpeg.org/ffmpeg-codecs.html#ProRes If you specify both: profile and Q then Q overwrites profile (so for official profiles we want just profile flag). Q allows you to make any quality ProRes files up to almost lossless, but this is outside Apple official profiles (still useful to have as advanced mode). ProRes_ks better simulates Apple one as it has bitrate restrictions. Ffmpeg prores uses higher bitrate which provides bit better quality, but it rather poorly simulates official encoder. Maybe you can have both as an option. In this case use number for profiles as text naming doesn't work for prores encoder: [0 - apco, 1 - apcs, 2 - apcn (default), 3 - apch, 4 - ap4h, 5 - ap4x]. Apco is proxy profile, apcs is LT. Strings for all official naming: Proxy profile="Apple ProRes 422 Proxy" LT profile="Apple ProRes 422 LT" Standard profile= "Apple ProRes 422" HQ profile= "Apple ProRes 422 HQ" 4444 profile="Apple ProRes 4444" 4444QX profile="Apple ProRes 4444 XQ" bitexact will remove Software=Lavfxxxx metadata in MOV container. Can be useful, but not essential. top is not about chroma location, but field order, so it basically tells ffmpeg to set field order flagging. It's somehow the same as fieldorder=tff and may be redundant, but it's safer to have it as well. Both should be aligned and have tff(1) as default (bff is needed very rarely). Least note- color tags are written by the default based on resolution/fps. You can force them as well using correct flagging: https://trac.ffmpeg.org/wiki/colorspace. Default behaviour is fairly good though (at least for HD, PAL/NTSC SD formats). Last edited by kolak; 14th May 2019 at 10:46. |
|
14th May 2019, 22:17 | #851 | Link |
Registered User
Join Date: Mar 2015
Posts: 775
|
@kolak
It seems everything is clear, added request to self https://sourceforge.net/p/vdfiltermod/tickets/244/
__________________
VirtualDub2 |
14th May 2019, 22:17 | #852 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
@shekh
Thanks for the insight. In the DivX and XviD days, VirtualDub was the main encoding app used by StaxRip.
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists |
14th May 2019, 22:31 | #853 | Link | |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
Quote:
|
|
17th May 2019, 10:57 | #854 | Link | |
Registered User
Join Date: Oct 2015
Posts: 54
|
Quote:
During the encoding in ffmpeg I'm forced to use the PRORES_METADATA https://ffmpeg.org/ffmpeg-bitstream-...s_005fmetadata |
|
17th May 2019, 12:59 | #855 | Link | |
Registered User
Join Date: Mar 2015
Posts: 775
|
Quote:
__________________
VirtualDub2 |
|
18th May 2019, 00:10 | #856 | Link | |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
Quote:
If source has known parameters then ffmpeg by default will write them into private ProRes headers (as long as supported). In order to have this info also on container level you need to use "movflags write_colr" and tell ffmpeg what you want there with: -color_primaries, -color_trc, -colorspace options (otherwise it will write default values which is Rec.709 or Rec.601 depending on resolution). If parameters are missing on the source file then you need to tell ffmpeg what they are on input and what you want on output (+ info for movflags as in 1st case). It's bit crap that you need 2 sets of flagging in order to have 100% correctly flagged ProRes file (on container and private headers). Of curse those values should be always aligned. Example 1 (source without known flagging): ..... -vf colorspace=iall=bt2020:all=bt2020 -color_primaries 9 -color_trc 14 -colorspace 9 in this case we tell ffmpeg that our source is Rec.2020 (iall) and we want to keep it this way (all) and also add flagging on container level as Rec.2020. Example 2: (source with known flagging as Rec.2020): -color_primaries 9 -color_trc 14 -colorspace 9 In this case we need just info for movflags option as private headers will be set to match source. There are many options for colorspace filter which also allows for conversion between different color spaces. Doc: https://ffmpeg.org/ffmpeg-all.html#toc-colorspace You can achieve the same with zimg scaling as well which is very high quality filter. In both filters key point is fact that source flagging needs to be known- be on source or set by you. Without it you will have errors as ffmpeg won't know what to start with. All of this applies to prores and prores_ks encoders. Last edited by kolak; 18th May 2019 at 00:20. |
|
18th May 2019, 10:22 | #858 | Link |
Registered User
Join Date: Mar 2015
Posts: 775
|
Thanks for info. Btw, to differentiate encoders it is better to say prores_ks or prores_aw (they are named by author initials)
__________________
VirtualDub2 |
19th June 2019, 14:00 | #860 | Link |
Formerly davidh*****
Join Date: Jan 2004
Posts: 2,496
|
VirtualDub2 behaves strangely with this AviSynth+ script:
Code:
blankclip(pixel_type="rgbaps") invert converttoyv12 If you change converttoyv12 to converttoy8, you get colourful garbage, which may indicate an AviSynth+ problem but I'm not sure (since I can't read the output of "info" to determine what colourspace I've ended up with), but the redrawing issue with converttoyv12 indicates some kind of trouble with VirtualDub2 not sensibly handling unexpected data. ---------------------------------------------- Edit: confusion abounds because converttoyv12/y8 don't actually change the bit depth, so the problem is just that VirtualDub2 doesn't display (or throw an error for) float data. Last edited by wonkey_monkey; 19th June 2019 at 15:51. |
|
|