Welcome Guest ( Log In | Register )


Important

The forums will be closing permanently the weekend of March 15th. Please see the notice in the announcements forum for details.

Pages: (26) « First ... 8 9 [10] 11 12 ... Last » ( Go to first unread post )
Ffmpeg Input Driver, Experimental driver based on ffmpeg libs
« Next Oldest | Next Newest » Track this topic | Email this topic | Print this topic
raffriff42
Posted: Dec 13 2013, 06:22 PM


Advanced Member


Group: Members
Posts: 384
Member No.: 35081
Joined: 25-June 12



QUOTE (dloneranger @ Dec 13 2013, 02:28 PM)
We could just measure the height and if >=720 then return a 709 format to virtualdub
That'd mean using an out of spec value for the format and could be unpredictable on earlier versions that don't support those formats

It seems to work ok but I wouldn't want to distribute/support such a hacky plugin  sad.gif

The other way would be to return a standard yuv format, but internally to ffmpeg plugin do some 709->601 conversion
Downside for that is you'd always be using 601 when thats not what you want and you wouldn't know if any conversions had taken place or not

Thoughts ?

Phaeron, Oct 14, 2009: The whole reason of FOURCC codes is to prevent this mess smile.gif
 
     Top
dloneranger
Posted: Dec 13 2013, 06:43 PM


Moderator


Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07



Until the sdk's sorted out, there's currently no way to officially say 'this video is 709' just one of the formats on the list a few posts back

So we can only bodge it one of two ways

Return the 709 version that's used in virtualdub itself even though it's breaking the sdk contract
Pro the filters etc can see the format as 709 or 601 and do their appropriate thing with it
Con unsupported, old versions of virtualdub may barf

Do a 709-601 conversion in the plugin itself and return the standard format
Pro doesn't break any rules
Con you're going to get a 601 version and won't know if it's been converted etc

Can't say I'm happy with either choice tbh
Pragmatically though, you may just go 'I don't care, as long as I get the right colours - gimme!'

Heck, if you wanted to fill up the options dialog, you could make it the users choice for all of that
It's still horrible though

Trouble with the fourcc system is that you them for all the variants eg yuv420 with full range and 709

--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3
 
    Top
jpsdr
Posted: Dec 14 2013, 09:49 AM


Advanced Member


Group: Members
Posts: 335
Member No.: 20490
Joined: 23-December 06



QUOTE (dloneranger @ Dec 13 2013, 02:28 PM)
1) virtualdub plugin sdk doesn't have anything but 601 for the yuv formats in it

Euh...

Sorry, SDK v1.2, in vdplugin.h :
CODE


namespace nsVDXPixmap {
enum VDXPixmapFormat {
 kPixFormat_Null      = 0,
 kPixFormat_XRGB1555     = 5,
 kPixFormat_RGB565     = 6,
 kPixFormat_RGB888     = 7,
 kPixFormat_XRGB8888     = 8,
 kPixFormat_Y8      = 9,
 kPixFormat_YUV422_UYVY    = 10,
 kPixFormat_YUV422_YUYV    = 11,
 kPixFormat_YUV444_Planar   = 13,
 kPixFormat_YUV422_Planar   = 14,
 kPixFormat_YUV420_Planar   = 15,
 kPixFormat_YUV411_Planar   = 16,
 kPixFormat_YUV410_Planar   = 17,
 kPixFormat_YUV422_UYVY_709   = 22,
 kPixFormat_Y8_FR     = 24,
 kPixFormat_YUV422_YUYV_709   = 25,
 kPixFormat_YUV444_Planar_709  = 26,
 kPixFormat_YUV422_Planar_709  = 27,
 kPixFormat_YUV420_Planar_709  = 28,
 kPixFormat_YUV411_Planar_709  = 29,
 kPixFormat_YUV410_Planar_709  = 30,
 kPixFormat_YUV422_UYVY_FR   = 31,
 kPixFormat_YUV422_YUYV_FR   = 32,
 kPixFormat_YUV444_Planar_FR   = 33,
 kPixFormat_YUV422_Planar_FR   = 34,
 kPixFormat_YUV420_Planar_FR   = 35,
 kPixFormat_YUV411_Planar_FR   = 36,
 kPixFormat_YUV410_Planar_FR   = 37,
 kPixFormat_YUV422_UYVY_709_FR  = 38,
 kPixFormat_YUV422_YUYV_709_FR  = 39,
 kPixFormat_YUV444_Planar_709_FR  = 40,
 kPixFormat_YUV422_Planar_709_FR  = 41,
 kPixFormat_YUV420_Planar_709_FR  = 42,
 kPixFormat_YUV411_Planar_709_FR  = 43,
 kPixFormat_YUV410_Planar_709_FR  = 44,
 kPixFormat_YUV420i_Planar   = 45,
 kPixFormat_YUV420i_Planar_FR  = 46,
 kPixFormat_YUV420i_Planar_709  = 47,
 kPixFormat_YUV420i_Planar_709_FR = 48,
 kPixFormat_YUV420it_Planar   = 49,
 kPixFormat_YUV420it_Planar_FR  = 50,
 kPixFormat_YUV420it_Planar_709  = 51,
 kPixFormat_YUV420it_Planar_709_FR = 52,
 kPixFormat_YUV420ib_Planar   = 53,
 kPixFormat_YUV420ib_Planar_FR  = 54,
 kPixFormat_YUV420ib_Planar_709  = 55,
 kPixFormat_YUV420ib_Planar_709_FR = 56,

 kPixFormat_VDXA_RGB   = 0x10001,
 kPixFormat_VDXA_YUV   = 0x10002
};
};


I'm using it for more than a year... 2 years at least i think.
 
     Top
dloneranger
Posted: Dec 14 2013, 11:08 AM


Moderator


Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07



There's only 1.1 on the sdk page http://www.virtualdub.org/filtersdk.html


--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3
 
    Top
jpsdr
Posted: Dec 14 2013, 01:30 PM


Advanced Member


Group: Members
Posts: 335
Member No.: 20490
Joined: 23-December 06



A long time ago, phareon put in a post a link to SDK v1.2, probably around the time he introduced a lot of new features.
Don't remember in what part of the forum it was, but most likey in a post in "Fiters Developpement" or "New VirtualDub version".
Or... if you want, get it here : http://jpsdr.free.fr/XBMC/VDPluginSDK-1.2.rar
 
     Top
dloneranger
Posted: Dec 14 2013, 01:43 PM


Moderator


Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07



I thought there was a newer one, and mentioned it in a few posts above where I thought it was using an old one
But then when I went to look 1.2 was not listed so I thought I was just crazy/tired and imagined it wink.gif

Wonder why it's not on the main page? Hope it's a 'forgot' not because of problems

Thanks for the link

--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3
 
    Top
jpsdr
Posted: Dec 14 2013, 02:17 PM


Advanced Member


Group: Members
Posts: 335
Member No.: 20490
Joined: 23-December 06



I've update all my filters and using it since a long time.

But, you may still encounter some of the new formats not totaly correctly handled.

The last two issues i've encounter "recently", but solved since, was crash when cropping YV12-BT709, and extended format not handle properly by resize filter.

But, if no one begin to use these new formats, they'll somehow never be tested.

So, it's probably not because a forget, more likely he wants to put it only when 100% sure that every new things is handle properly, and not issue left.
 
     Top
dloneranger
Posted: Dec 14 2013, 02:56 PM


Moderator


Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07



Ok, here's a test version if anyone wants to play with it

It tries to detect 601/709 and limited/fullrange but not many videos I have actually have them marked at all
So, there's also an extra tick box in the options to assume a height>=720 means 709 colourspace

See what you think

https://dl.dropboxusercontent.com/u/1702491...iverTest709.zip

--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3
 
    Top
j85
Posted: Dec 15 2013, 10:01 AM


Newbie


Group: Members
Posts: 2
Member No.: 37550
Joined: 11-December 13



Thanks for getting the more important stuff fixed! As for

QUOTE (dloneranger @ Dec 14 2013, 02:56 PM)
Ok, here's a test version if anyone wants to play with it

It tries to detect 601/709 and limited/fullrange but not many videos I have actually have them marked at all
So, there's also an extra tick box in the options to assume a height>=720 means 709 colourspace

See what you think

https://dl.dropboxusercontent.com/u/1702491...iverTest709.zip


I did some testing of this.

When the input is 8-bit 4:2:0 YCbCr and I have the decompression format in the color depth dialog set to "autoselect," it seems to work as advertised for the most part. But if the decompression format is set to RGB24, there is an conversion to RGB using the BT.601 matrix regardless of whether the source is BT.601, BT.709, or unspecified. This is clearly not the right behavior, although of course I don't know if it can be fixed on the plugin end. If it's set to one of the 4:2:0 YCbCr options, it is imported without any conversion.

For 10-bit 4:2:0 YCbCr (common in anime fansubs), with the decompression format set to "autoselect," the autoselected format is 24-bit RGB, and it converts using the BT.601 matrix. If the decompression format is set manually to one of the 4:2:0 YCbCr options, there is no conversion other than truncation (or perhaps dithering) to 8 bits.

The height>=720 rule behaves similarly when enabled. But there are definitely some situations where this rule shouldn't be applied. For example, if I understand correctly, Theora and VP8 always use the BT.601 matrix, but ffmpeg doesn't report them as being BT.601. So this version of the plugin treats them as BT.709 if they have height>=720. This might be something that would be better fixed in ffmpeg, though, by having it report the matrix when it's knowable based on the codec used.

It's also possible to explicitly flag an H.264 video as using the BT.601 color matrix. FFmpeg identifies these as "bt470bg" or "smpte170m" (as color matrix flags, these are equivalent). I haven't seen these in the wild, but you can set the flag with x264's --colormatrix option (-x264opts colormatrix=bt470bg from ffmpeg). This should override the height>=720 rule, but didn't.

Another issue separate from the color matrix stuff: Selecting the NV12 decompression format and then opening a video provokes a crash.

For example, when I do it with this video:
http://upload.wikimedia.org/wikipedia/comm...0b/Hargeisa.ogv

I get this crash report:
http://pastebin.com/YxS6rwyt

I don't know if this is a bug in the plugin or in VirtualDub itself. I was able to open one AVI file after selecting NV12 without provoking a crash, but that's hardly conclusive.
 
     Top
dloneranger
Posted: Dec 15 2013, 12:55 PM


Moderator


Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07



Interesting
What I've actually done is modify the detection rules like this
CODE

//check if ffmpeg can detect it's colorspace and format
bool pos709 = (m_pCodecCtx->colorspace == AVCOL_SPC_BT709);  // ffmpeg reports 709
bool fullrange = m_pCodecCtx->color_range == AVCOL_RANGE_JPEG; // ffmpeg reports 0--255 levels

// if >=720 in options
if (m_bAutoDetect709Fr)
 pos709 = pos709 || (m_pCodecCtx->height >= 720);

switch (m_pCodecCtx->pix_fmt) // ffmpg's reported video format
{
case AV_PIX_FMT_YUV420P:
 if ( pos709 )
  format = nsVDXPixmap::kPixFormat_YUV420_Planar_709;
 else
   format = nsVDXPixmap::kPixFormat_YUV420_Planar; // 601
  if ( fullrange )
  {
    if ( format == nsVDXPixmap::kPixFormat_YUV420_Planar_709 )
      format = nsVDXPixmap::kPixFormat_YUV420ib_Planar_709_FR;
    if ( format == nsVDXPixmap::kPixFormat_YUV420_Planar )
      format = nsVDXPixmap::kPixFormat_YUV420ib_Planar_FR; // 601 fullrange
  }
break;

..... same for AV_PIX_FMT_UYVY422, AV_PIX_FMT_YUYV422
..... everything else left alone eg

case AV_PIX_FMT_BGR24:
case AV_PIX_FMT_RGB24:
format = nsVDXPixmap::kPixFormat_RGB888;
break;


So the only place it actually does any tests or modifications is on the yuv formats
Virtualdub doesn't even have a concept of rgb 601 or 709
I'd imagine most of rgb stuff is something the ffmpeg's doing itself as there's nothing else in the plugin that deals with 601/709
By default all yuv is reported to virtualdub as 601 unless ffmpeg say's it's yuv-709 or (yuv and option >=720 ticked)
I'll change that to only check the height when the colorspace is unknown

Can't do anything about 10bit, as virtualdub doesn't have a 10bit format to use

The crash is inside of virtualdub where it's copying a frame
There was an nv12 bug reported a while ago and fixed
QUOTE
Confirmed NV12 bpp is incorrect -- fixed in 1.10.4 final.

If you're using a previous version try upgrading, if you're using that or newer could you post a bug report for Phaeron to fix?

[edit]
Only check the height option if the colorspace is unknown
https://dl.dropboxusercontent.com/u/1702491...iverTest709.zip

--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3
 
    Top
dloneranger
Posted: Dec 17 2013, 06:33 PM


Moderator


Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07



0.8.0.5 on first post

Options for 709 colorspace detection by ffmpeg or by height (use extended options on opening to set them, disabled by default)
Detection by FFMpeg only works if that information is actually in the video

--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3
 
    Top
raffriff42
Posted: Jan 20 2014, 10:38 PM


Advanced Member


Group: Members
Posts: 384
Member No.: 35081
Joined: 25-June 12



Finally got around to testing version 0.8.0.5 -

Checked two videos, identical (720p, x264vfw) except for "--colormatrix" option:
- advanced options: autodetect 601/709 on, auto >=720 off
- Vdub File Information / Pixel Format always shows "yuv420p (?)" however...
- Null Filter (or any YUV filter) shows format as "YUV420" or "YUV420-709" as appropriate.
Both preview correctly without AliasFormat filter.
Success!

- checked again with StaxRip-generated 720p, x264 videos - still OK.
- correctly detected UTVideo YUV420 BT.601 (UTY0) vs. YUV420 BT.709 (UTH0)
- opens x264vfw & x264 (external) 4:4:4 video correctly as BT.709 (but converts to RGB)
- opens ffmpeg-generated x264 & MPEG-4 appropriately (MPEG-4 is always 601 AFAIK)

Thank you! cool.gif

One problem came up:
crashed on attempting to open Bandicam-generated MJPEG AVI:
https://dl.dropboxusercontent.com/u/1080894...dicam-MJPEG.txt
(also crashes on 0.8.0.3)

...also crashed on Virtualdub-generated MJPEG AVI:
https://dl.dropboxusercontent.com/u/1080894...-vdub-MJPEG.txt

Currently uploading sample files...

EDIT here's a sample, thanks again

EDIT ...removed video

This post has been edited by raffriff42 on Jan 22 2014, 11:08 PM
 
     Top
dloneranger
Posted: Jan 20 2014, 10:55 PM


Moderator


Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07



Hopefully I'll have some time to look at it at the weekend
a quick browse through shows yuv444 decoding isn't in it's source, should be able to add that easily enough
QUOTE
Vdub File Information / Pixel Format always shows "yuv420p (?)" however

That'll be me not filling in the right data at a guess

If the crashes track back to the ffdshow dlls's were stuffed with fixing that at the moment
The latest ffdshow dlls are pretty unstable - there are so many commit/reverts going on that I'm going to wait until a stable one comes out....

--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3
 
    Top
dloneranger
Posted: Jan 21 2014, 03:29 AM


Moderator


Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07



Quick fix for some crashes
https://dl.dropboxusercontent.com/u/1702491...ffdshowtest.zip

FFMPeg returns some logging information, like you see in the commandline version
Turns out that sometimes it gives invalid information that breaks c++ print function in a bad way
So the quick fix just ignores all logging info

I'll get to the rest when possible

Quickfix for testing
https://dl.dropboxusercontent.com/u/1702491...ffdshowtest.zip

--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3
 
    Top
dloneranger
Posted: Jan 21 2014, 03:50 AM


Moderator


Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07



QUOTE
- Vdub File Information / Pixel Format always shows "yuv420p (?)" however...
- Null Filter (or any YUV filter) shows format as "YUV420" or "YUV420-709" as appropriate.


This is from two things
1) The file information dialog shows the format of the file as reported by ffdshow
2) Not all formats are allowed by virtualdub, so there's a negotiation between the two to get something allowable

Eg, for your sample, the format is AV_PIX_FMT_YUVJ420P and it gets negotiated down to rgb24 for virtualdub
There's a section of code that has a lot of if ffmpeg format= x then virtualdub format=y (+some data twiddling)
The main obstacle here is pretty simple, lots and lots of typing in as many extra formats as possible
Well, that and figuring out if/what the equivalent format is in virtualdub
Easy to make mistakes on this....
I 'think' YUVJ420 is 601 full range Y and limited range YV https://wiki.videolan.org/YUV/#I420
(wtf???)

--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3
 
    Top
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:
378 replies since May 10 2011, 10:20 AM Track this topic | Email this topic | Print this topic
Pages: (26) « First ... 8 9 [10] 11 12 ... Last »
<< Back to VirtualDub Filters and Filter Development