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 7th December 2017, 15:00   #381  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 2,493
Quote:
Originally Posted by StainlessS View Post
One comment on very short play with current ver$ [a few minutes only], its a bit annoying having to pause scrolling to have display update,
think that there must have been some mod to that since the earlier version I was using (from several months ago).
This is one of three annoying things that led me to alter and recompile VirtualDub myself (my instructions are still a sticky thread although it's out of date now).

Somewhere there is a condition that causes VirtualDub to give up on displaying a frame if it takes over 100ms, and you have scrolled onward in the meantime.

On the subject of AVI vs. MKV, doesn't MKV lack a frame index?
__________________
My AviSynth filters / I'm the Doctor

Last edited by wonkey_monkey; 7th December 2017 at 15:49.
wonkey_monkey is offline   Reply With Quote
Old 7th December 2017, 15:55   #382  |  Link
lansing
Registered User
 
Join Date: Sep 2006
Posts: 1,657
I found another bug with image export. When I loaded in a video and export a frame as single image, in the saving location window, the last output format was used as TIFF with its 2 setting "zip compressed" and "lzw compressed" enabled, and then when I clicked on a png file in the directory, the output format auto changed to png, but the settings didn't change.
lansing is offline   Reply With Quote
Old 7th December 2017, 16:06   #383  |  Link
AKBabel
Registered User
 
Join Date: Nov 2017
Posts: 14
Quote:
Originally Posted by shekh View Post
Encoding to what?
FFV1

Quote:
Originally Posted by shekh View Post
I experimented with 5000*2500@rgb48 converting to FFV1, and it used around 2GB for encoding. Are you trying with 32-bit version?
Yes, it was a 32bit version, also a 32bit system, as I found out now.
I’ll later try it with 64bit.
AKBabel is offline   Reply With Quote
Old 7th December 2017, 23:47   #384  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
Quote:
Originally Posted by lansing View Post
I found another bug with image export. When I loaded in a video and export a frame as single image, in the saving location window, the last output format was used as TIFF with its 2 setting "zip compressed" and "lzw compressed" enabled, and then when I clicked on a png file in the directory, the output format auto changed to png, but the settings didn't change.
Thanks, this is simple.

Quote:
Originally Posted by lansing
I encountered a bug, when I loaded in a 32 bit png, adjust the color using colormill, and then export it as single image out as png, the resulting image became all white.
This is interesting. In fact the image becomes transparent (not white) but you need to select dx9 display driver to be able to see it.

There are at least 3 problems:
1. the filter wipes alpha for no reason.
2. switching decode format to rgb24 does no help (this I will fix).
3. there is still no way to enable/disable alpha (will make something).
__________________
VirtualDub2
shekh is offline   Reply With Quote
Old 8th December 2017, 00:00   #385  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
Quote:
Originally Posted by davidhorman View Post
This is one of three annoying things that led me to alter and recompile VirtualDub myself (my instructions are still a sticky thread although it's out of date now).

Somewhere there is a condition that causes VirtualDub to give up on displaying a frame if it takes over 100ms, and you have scrolled onward in the meantime.
As I understand this problem, VD should display the frame when it is 100% decoded anyway as in the case with avisynth.
Display is not that slow to skip it.
__________________
VirtualDub2
shekh is offline   Reply With Quote
Old 8th December 2017, 13:43   #386  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 2,493
If you are on frame x, and use arrow keys or drag the slider to select frame y, it will start to decode frame y - but if, before it has finished, you arrow-key or drag to frame z, VirtualDub won't display frame y at all if the 100ms threshold is exceeded. Which is sort of reasonable, but makes it hard to scrub through the result of an intensive script, as you can't see where you are until stop dragging.

I forget the details, and the VirtualDub forum is now gone so I won't be able to find the post from Phaeron which told me which bit of the source code to change, but I do remember it was a 100ms threshold.

My other bugbear was that during encoding it displayed Time Elapsed, but not Time Remaining, which is by far the more useful number.
__________________
My AviSynth filters / I'm the Doctor
wonkey_monkey is offline   Reply With Quote
Old 10th December 2017, 17:15   #387  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
A) (vdfm 40716 x64 and x86) - Video => Decode format for pixel format isn't respected for 10bit 422

e.g
1) load a prores 10bit422 source
2) file => file information will say yuv422p10le using caching input driver (so far so good)
3) video => fast recompress will say using conversion yuv422p16-709 ; so you cannot encode yuv422p10le directly (e.g. you won't be able to export v210 or cineform 10bit422 without other conversions with normal or full recompress ). Video compression menu will also report yuv422p16-709 . This is unexpected because yuv422p10le should be direct from decode => encode . If you select video=> compression => uncompressed I would expect v210 out, but you dont get v210.
4) forcing video=>decode format to v210 doesn't "stick"


B) slight color shift when using cineform . Not a 601/709 issue, but a Cr shift, very slight move away from teal to red. Not sure if it's related to conversion, but it affects both native and gopro implementation when using vdfm . I'll do some more tests and report back.
EDIT: color shift was user error. Inconsistent decoder / viewing method / some dithering differences .

Last edited by poisondeathray; 10th December 2017 at 17:47.
poisondeathray is offline   Reply With Quote
Old 11th December 2017, 11:09   #388  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
Quote:
Originally Posted by poisondeathray View Post
A) (vdfm 40716 x64 and x86) - Video => Decode format for pixel format isn't respected for 10bit 422

e.g
1) load a prores 10bit422 source
2) file => file information will say yuv422p10le using caching input driver (so far so good)
3) video => fast recompress will say using conversion yuv422p16-709 ; so you cannot encode yuv422p10le directly (e.g. you won't be able to export v210 or cineform 10bit422 without other conversions with normal or full recompress ). Video compression menu will also report yuv422p16-709 . This is unexpected because yuv422p10le should be direct from decode => encode . If you select video=> compression => uncompressed I would expect v210 out, but you dont get v210.
4) forcing video=>decode format to v210 doesn't "stick"
I do not implement formats exactly as in FFMpeg. yuv422p16 in VDFM is perfect match format for everything from yuv422p9le to yuv422p16le with one caveat: instead of locking bitdepth I keep it as a per-frame metadata. If you feed yuv422p10le in and take yuv422p10le out of the pipeline, there is no scaling applied to pixel values. Except when this is needed for some filter. It is also possible to see the YUV values in filter preview through color picker so you can make sure it looks like 10-bit data (crop filter is good to access this feature because crop itself does not change pixels).
yuv422p10le -> yuv422p16 -> yuv422p10le is as direct as possible, there is nothing to worry about in this conversion.

yuv422p10le to uncompressed as v210: if you mean it should be auto-selected/default I agree. Uncompressed output setup needs some improvement. But you can select "v210" manually.

> forcing video=>decode format to v210 doesn't "stick"

This menu only triggers something when the option actually exists in the decoder.
Same if you open png image and select v210 as decoding format: this is not supported.
v210 decoding is implemented by VFW codecs and also by CineForm sdk.
__________________
VirtualDub2
shekh is offline   Reply With Quote
Old 6th January 2018, 19:22   #389  |  Link
WorBry
Registered User
 
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
@Shekh,

I've been running some tests with VDFM (40716), transcoding native 4K 10-bit 422 clips (from a Panasonic GH5 camera) to various 10-bit 422 formats, including Grass Valley HQX using the GV codecs pack:

https://www.edius.net/hqx.html

Although the codec per se supports 10-bit and 8-bit, 8-bit appears to be the only option with the HQX codec as it presents in the VDFM Compression listing.





Is this a limitation of the VFW codec, as accessible by third-party applications, or is there any possibility of accessing the 10-bit variant ?
__________________
Nostalgia's not what it used to be
WorBry is offline   Reply With Quote
Old 6th January 2018, 20:14   #390  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
HQX vfw codec does not support 10-bit mode. Don't know why they advertise it. I also tried to get an answer from their support with no luck.
shekh is offline   Reply With Quote
Old 6th January 2018, 22:07   #391  |  Link
WorBry
Registered User
 
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
OK thanks. No big deal. It's not my preferred intermediate format anyway.
__________________
Nostalgia's not what it used to be
WorBry is offline   Reply With Quote
Old 7th January 2018, 03:27   #392  |  Link
WorBry
Registered User
 
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
Something else I've observed with VDFM (40716 32bit & 40717 64bit) ; when transcoding native 4K and HD AVC (8-bit YV12, Rec709) clips to any YUV format, specular highlights get encoded black. Here's an example:

Source clip: UHD/60p AVC (8-bit, Rec709).mp4 clip shot on a GH5. VDFM frame grabs (resized to 1280x720) - click + cursor to enlarge

Original clip (Decode format YUV420-709):



MagicYUV (YUV 420) transcode (Normal Recompress, using conversion YUV420-709 > YUV420, no change in the component range):



Cineform Filmscan 1 transcode (Normal Recompress, using conversion YUV420-709 > YUYV (YUY2), no change in the component range.




See how the blown/specular highlights on the light bulbs and coming through the roof skylights are black.

And again, showing the respective AVISynth Histograms:

Original clip (DGDecodeNV > YV12):



MagicYUV (YUV 420) transcode:



Cineform Filmscan1 transcode (ConvertToYV12, interlaced=false):



I don't see this aberration (with VDFM 32bit) when the AVS decode script (Decode Format YUV420) is used as the input source for the transcodes. And it doesn't occur with 4K/HD-AVC (8bit) clips recorded with full luma range i.e. decode format YUV420-709-FS.

Sample (2sec) of above clip to test:
http://www21.zippyshare.com/v/77EZFJQ6/file.html
__________________
Nostalgia's not what it used to be

Last edited by WorBry; 7th January 2018 at 05:36.
WorBry is offline   Reply With Quote
Old 7th January 2018, 06:47   #393  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
Now I'm on mobile, will see this in few days.
shekh is offline   Reply With Quote
Old 8th January 2018, 22:21   #394  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Quote:
Originally Posted by shekh View Post
HQX vfw codec does not support 10-bit mode. Don't know why they advertise it. I also tried to get an answer from their support with no luck.
It does support 10bit, but it's not exposed in VFW module.
You would need codec SDK which is not publicly available.
kolak is offline   Reply With Quote
Old 8th January 2018, 23:23   #395  |  Link
dipje
Registered User
 
Join Date: Oct 2014
Posts: 268
I have a Vapoursynth script outputting RGB48. If I open it in 40716 (x64) it seems to open fine as B64a (as it should IIRC).

Now, I want to try the Cineform encoder, so I set compression to Cineform RGB 12bit (also tried with RGBA 12bit), with the 'input delivery' set to 16bit. The output format selection seems to be RGB64, which is fine.
When I try to save (either to .avi or to .mov) VDFD crashes directly at the start.

Am I doing something wrong or is this a known problem?
dipje is offline   Reply With Quote
Old 10th January 2018, 04:35   #396  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Quote:
Originally Posted by dipje View Post
I have a Vapoursynth script outputting RGB48. If I open it in 40716 (x64) it seems to open fine as B64a (as it should IIRC).

Now, I want to try the Cineform encoder, so I set compression to Cineform RGB 12bit (also tried with RGBA 12bit), with the 'input delivery' set to 16bit. The output format selection seems to be RGB64, which is fine.
When I try to save (either to .avi or to .mov) VDFD crashes directly at the start.

Am I doing something wrong or is this a known problem?
This works for me in either MOV, AVI container

I don't have 'input delivery' in my cineform dialog box (I'm using Go Pro Cineform (native) . It says "intermediate bit depth" and it's set to 16

Re-importing the export is correctly identified correctly as rgb 12bit
poisondeathray is offline   Reply With Quote
Old 10th January 2018, 04:52   #397  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Quote:
Originally Posted by WorBry View Post

Sample (2sec) of above clip to test:
http://www21.zippyshare.com/v/77EZFJQ6/file.html

For me, it just crashes, regardless of export codec. Both x86, x64 versions

But works ok (without highlight issue) when fed through vapoursynth or avisynth

I think it has to do with the caching input driver
poisondeathray is offline   Reply With Quote
Old 10th January 2018, 09:20   #398  |  Link
dipje
Registered User
 
Join Date: Oct 2014
Posts: 268
Quote:
Originally Posted by poisondeathray View Post
This works for me in either MOV, AVI container

I don't have 'input delivery' in my cineform dialog box (I'm using Go Pro Cineform (native) . It says "intermediate bit depth" and it's set to 16

Re-importing the export is correctly identified correctly as rgb 12bit
Ah crap, so what is broken on my system..
With input delivery I mean the same setting as you, intermediate bitdepth.

Do you have / use an alpha channel in all of this ? I'm feeding it 'dry' non-alpha rgb48 which vapoursynth wraps in b64a for VfW. Maybe I should try with a dummy alpha channel.

Another (very minor) thing. Opening a .vpy file now requires me to explicitly select the avisource reader. Just opening the .vpy gives an ffmpeg error, so I guess the ffmpeg input driver tries to open vapoursynth scripts now. This wasn't always the case.

edit might it even that there is an avx(2) codepath or something enabled in the cineform RGB mode that my old i7 doesn't support?

Last edited by dipje; 10th January 2018 at 15:15.
dipje is offline   Reply With Quote
Old 10th January 2018, 13:54   #399  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Quote:
Originally Posted by poisondeathray View Post
This works for me in either MOV, AVI container

I don't have 'input delivery' in my cineform dialog box (I'm using Go Pro Cineform (native) . It says "intermediate bit depth" and it's set to 16

Re-importing the export is correctly identified correctly as rgb 12bit
Cineform requires 16bit data input, but data is stored at 12bit precision. It doesn't support as far as I understand 12bit RGB data, like e.g. ffmpeg. It uses common b64a format. This is most likely why you are seeing 16bit.
kolak is offline   Reply With Quote
Old 10th January 2018, 15:15   #400  |  Link
dipje
Registered User
 
Join Date: Oct 2014
Posts: 268
Quote:
Originally Posted by kolak View Post
Cineform requires 16bit data input, but data is stored at 12bit precision. It doesn't support as far as I understand 12bit RGB data, like e.g. ffmpeg. It uses common b64a format. This is most likely why you are seeing 16bit.
The problem isn't the 16bit input (which I get, and I am delivering it 16bit RGB).

My problem is VDFM crashing on my system when I render / save it to a file
dipje 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 23:41.


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