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.

 

Go Back   Doom9's Forum > Capturing and Editing Video > VirtualDub, VDubMod & AviDemux

Reply
 
Thread Tools Search this Thread Display Modes
Old 17th April 2019, 21:44   #841  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 18th April 2019, 00:34   #842  |  Link
shekh
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
shekh is offline   Reply With Quote
Old 18th April 2019, 23:30   #843  |  Link
lansing
Registered User
 
Join Date: Sep 2006
Posts: 1,657
Quote:
Originally Posted by shekh View Post
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.
The "go->zoom selection" option was grayed out when the script was first opened. It's just weird to have a frame on the timeline that doesn't belong to the clip.
lansing is offline   Reply With Quote
Old 19th April 2019, 02:48   #844  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 2,493
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.
__________________
My AviSynth filters / I'm the Doctor
wonkey_monkey is offline   Reply With Quote
Old 1st May 2019, 12:57   #845  |  Link
shekh
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
shekh is offline   Reply With Quote
Old 13th May 2019, 18:48   #846  |  Link
kolak
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.
kolak is offline   Reply With Quote
Old 13th May 2019, 19:56   #847  |  Link
stax76
Registered User
 
stax76's Avatar
 
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?
stax76 is offline   Reply With Quote
Old 13th May 2019, 20:09   #848  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
Quote:
Originally Posted by kolak View Post
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.
> Could we have ProRes presets updated so they better match official profiles

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
shekh is offline   Reply With Quote
Old 14th May 2019, 01:05   #849  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
Quote:
Originally Posted by stax76 View Post
I noticed main menu > File is very large, it might make sense to use some sub menus.
Agree, something needs to be moved or deleted.


Quote:
Originally Posted by stax76 View Post
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?
You mean the main icon? This was long trial and error. When I was almost fine with general look I made it as vector painting in Photoshop, then rasterized it in some practical resolutions, fixed some shapes, experimented with colors. The final image is combination of multiple resolutions. Down to 48x was easy from vector source, the smaller the more hand correction was necessary, and finally 16x I painted pixel by pixel.

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
shekh is offline   Reply With Quote
Old 14th May 2019, 09:26   #850  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Quote:
Originally Posted by shekh View Post
> Could we have ProRes presets updated so they better match official profiles

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?
Different profiles HQ, LT etc are basically encodes with specific Q level.
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.
kolak is offline   Reply With Quote
Old 14th May 2019, 22:17   #851  |  Link
shekh
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
shekh is offline   Reply With Quote
Old 14th May 2019, 22:17   #852  |  Link
stax76
Registered User
 
stax76's Avatar
 
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.
stax76 is offline   Reply With Quote
Old 14th May 2019, 22:31   #853  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Quote:
Originally Posted by shekh View Post
@kolak
It seems everything is clear, added request to self https://sourceforge.net/p/vdfiltermod/tickets/244/
Ok, thanks.
kolak is offline   Reply With Quote
Old 17th May 2019, 10:57   #854  |  Link
age
Registered User
 
Join Date: Oct 2015
Posts: 54
Quote:
Originally Posted by kolak View Post
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).
When I encode prores HQ with ffmpeg ( and virtualdub) it outputs always the same matrix "BT.470 System B/G".

During the encoding in ffmpeg I'm forced to use the PRORES_METADATA

https://ffmpeg.org/ffmpeg-bitstream-...s_005fmetadata
age is offline   Reply With Quote
Old 17th May 2019, 12:59   #855  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
Quote:
Originally Posted by age View Post
When I encode prores HQ with ffmpeg ( and virtualdub) it outputs always the same matrix "BT.470 System B/G".

During the encoding in ffmpeg I'm forced to use the PRORES_METADATA

https://ffmpeg.org/ffmpeg-bitstream-...s_005fmetadata
It is not the same as "-movflags write_colr"? Madness.
__________________
VirtualDub2
shekh is offline   Reply With Quote
Old 18th May 2019, 00:10   #856  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Quote:
Originally Posted by age View Post
When I encode prores HQ with ffmpeg ( and virtualdub) it outputs always the same matrix "BT.470 System B/G".

During the encoding in ffmpeg I'm forced to use the PRORES_METADATA

https://ffmpeg.org/ffmpeg-bitstream-...s_005fmetadata
Latest ffmpeg should set correct flags on private ProRes headers and MOV container level.
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.
kolak is offline   Reply With Quote
Old 18th May 2019, 00:22   #857  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Quote:
Originally Posted by shekh View Post
It is not the same as "-movflags write_colr"? Madness.
I thought it's but unfortunately it's way more complex (as described above).
kolak is offline   Reply With Quote
Old 18th May 2019, 10:22   #858  |  Link
shekh
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
shekh is offline   Reply With Quote
Old 18th May 2019, 23:11   #859  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
I think aw is more known as just prores in ffmpeg. Not sure. Ks is recognised as more Apple compliant.

Last edited by kolak; 18th May 2019 at 23:14.
kolak is offline   Reply With Quote
Old 19th June 2019, 14:00   #860  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 2,493
VirtualDub2 behaves strangely with this AviSynth+ script:

Code:
blankclip(pixel_type="rgbaps")
invert
converttoyv12
It seems to paint nothing in the panes (redrawing problems are evident if you drag the panes around, plus they darken when the window loses focus).

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.
__________________
My AviSynth filters / I'm the Doctor

Last edited by wonkey_monkey; 19th June 2019 at 15:51.
wonkey_monkey is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 17:49.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.