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 > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 4th April 2011, 12:16   #41  |  Link
Chikuzen
typo lover
 
Chikuzen's Avatar
 
Join Date: May 2009
Posts: 597
ok, It seems that I succeeded in modifying avs2pipe for support other csps (require avisynth2.6.0α2)

avs2pipe260-0.0.2
*Added support YUV444(YV24) / YUV422(YUY2/YV16) / YUV411 / Y8 colorspace Y4M output.

thanks to doobry and kemuri-_9 !
__________________
my repositories
Chikuzen is offline   Reply With Quote
Old 4th April 2011, 12:52   #42  |  Link
ganymede
Registered User
 
Join Date: Aug 2010
Location: Paris
Posts: 52
Quote:
Originally Posted by Chikuzen View Post
(require avisynth2.6.0α2)
It works for me (using wine on linux) with avisynth2.6.0α2, but not SEt's 2.6 MT. With 2.6 MT, output is empty (no data). Nice step forward, though.
ganymede is offline   Reply With Quote
Old 4th April 2011, 14:05   #43  |  Link
doobry
Totally Clueless
 
doobry's Avatar
 
Join Date: Nov 2010
Location: Edinburgh, UK
Posts: 31
Quote:
Originally Posted by Chikuzen View Post
ok, It seems that I succeeded in modifying avs2pipe for support other csps (require avisynth2.6.0α2)

avs2pipe260-0.0.2
*Added support YUV444(YV24) / YUV422(YUY2/YV16) / YUV411 / Y8 colorspace Y4M output.

thanks to doobry and kemuri-_9 !
Yey that is fan fricking tastic, I totally missed the link from kemuri-_9 to that darned header I couldn't find, and now the work is basically done for me

Will try to roll the changes into my "master" version, can hopefully stick in a macro to enable support if requested, and slap your name in the comments.

@Chikuzen, where did you get the avisynth.lib link library? is it the one that i included in the original zip (2.5.8) or one from avisynth2.6.0α2? as I think SEt's 2.6 MT build did not include the link library, and I cannot find his source release for it...

Last edited by doobry; 4th April 2011 at 15:54.
doobry is offline   Reply With Quote
Old 4th April 2011, 16:23   #44  |  Link
Chikuzen
typo lover
 
Chikuzen's Avatar
 
Join Date: May 2009
Posts: 597
Quote:
Originally Posted by doobry View Post
@Chikuzen, where did you get the avisynth.lib link library? is it the one that i included in the original zip (2.5.8) or one from avisynth2.6.0α2? as I think SEt's 2.6 MT build did not include the link library, and I cannot find his source release for it...
I got it from official 2.6.0α2 binary(extracted installer with 7zip).

I don't know where 2.6MT source code is because I lost the interest in MT after SEt disappears .
__________________
my repositories
Chikuzen is offline   Reply With Quote
Old 4th April 2011, 17:44   #45  |  Link
doobry
Totally Clueless
 
doobry's Avatar
 
Join Date: Nov 2010
Location: Edinburgh, UK
Posts: 31
Well my version now in theory supports the new colorspaces, thanks to the header from kemuri-_9, so there are now 4 binaries, gcc and vs compiled against 2.5.8 and 2.6a2, just need something to test them with.

As for 2.6MT support, I am not going to bother, the latest source link I could find was just above a post detailing a bunch of bugs, so it seems I cannot get a link library for the MT version, and as something weird is clearly happening with it I'm not going to waste my time without the proper sources and libs.

Also coming in version 0.0.3, Blu-Ray encoding suggestions for x264, it looks at your avs script and picks the correct settings from http://sites.google.com/site/x264bluray/ to pass to x264... kinda pointless for most people but it lets me define everything in the avs file as I use batch files to encode.
doobry is offline   Reply With Quote
Old 4th April 2011, 19:15   #46  |  Link
doobry
Totally Clueless
 
doobry's Avatar
 
Join Date: Nov 2010
Location: Edinburgh, UK
Posts: 31
New Version 0.0.3

http://doobrymedia.com/avs2pipe-0.0.3.zip

Changed the command line usage to remove "--" from the command arguments, as there can be only one command and if I add "options" later this will keep things neater.

Usage: avs2pipe [audio|video|info|x264] input.avs
audio - output wav extensible format audio to stdout.
video - output yuv4mpeg2 format video to stdout.
info - output information about aviscript clip.
x264bd - suggest x264 arguments for blu-ray disc encoding.

Added Blu-Ray x264 command generator based on specs from http://sites.google.com/site/x264bluray/

Added Support for new Colorspaces in AviSynth 2.6 with code written by Chikuzen

I messed around a little with how the colorspaces are handled to make it a bit neater for the macro to switch between 2.5 / 2.6 support, so their could be bugs as its not tested fully.

I do know that the 2.6 versions will prob hang under 2.5 and the 2.5 versions will hang under 2.6 if you try to use new features, but thats expected.
doobry is offline   Reply With Quote
Old 4th April 2011, 22:26   #47  |  Link
ganymede
Registered User
 
Join Date: Aug 2010
Location: Paris
Posts: 52
I just tested avs2pipe26_gcc.exe with SEt's 2.6 MT under linux/wine... and it works ! Don't ask me why it does , but it's a good news for me.
Thank you guys for your work

Last edited by ganymede; 4th April 2011 at 22:28.
ganymede is offline   Reply With Quote
Old 5th April 2011, 10:11   #48  |  Link
doobry
Totally Clueless
 
doobry's Avatar
 
Join Date: Nov 2010
Location: Edinburgh, UK
Posts: 31
Speaking of weirdness... why does outputting both an I420 and YV12 colorspace result in exactly the same data... shouldn't AVS_CS_I420 be y-u-v planar, while AVS_CS_YV12 is y-v-u planar? As I'd coppied the method from avs2yuv I hadn't really spent too much time looking colorspace details, but thanks to Chikuzen I had to fire up google and look, and from what I found in theory the code should not have worked from day one as the u and v planes should have been swapped (its called YUV4MPEG2 and not YVU4MPEG2 afterall).

The avs2pipe code takes each plane and writes then out in the order that avisynth presents them... litterally a planes 1-3 for loop (well 0-2), given this shouldn't streams marked as AVS_CS_I420 give different output to AVS_CS_YV12? It would not be hard to swap the planes if needed, and it should be, but it seems that it "just works (tm)" when it really shouldn't.

So anyone with a bit more AviSynth knowledge know whats going on? Does AviSynth store all planar colorspaces in the same order in memory (y-u-v) and just set the pixel_type for reference of where its reordered data came from?

PS. The current download version (0.0.3) automatically adds a ConvertToYV12 filter to anything it doesn't understand, which includes AVS_CS_I420, obviously I've turned that off for AVS_CS_I420 on my current test version and told it to handle it exactly the same as AVS_CS_YV12.

Last edited by doobry; 5th April 2011 at 10:20.
doobry is offline   Reply With Quote
Old 5th April 2011, 10:40   #49  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,384
Quote:
Originally Posted by doobry View Post
The avs2pipe code takes each plane and writes then out in the order that avisynth presents them... litterally a planes 1-3 for loop (well 0-2), given this shouldn't streams marked as AVS_CS_I420 give different output to AVS_CS_YV12? It would not be hard to swap the planes if needed, and it should be, but it seems that it "just works (tm)" when it really shouldn't.

So anyone with a bit more AviSynth knowledge know whats going on? Does AviSynth store all planar colorspaces in the same order in memory (y-u-v) and just set the pixel_type for reference of where its reordered data came from?
The planes (Y, U, V) are always numbered the same, independently of the order they are stored in memory, so if you always ask for them (via GetReadPtr()) in a given order, that's the order you will get.

However, I'm confused by your saying planes 0-2, since Y, U, V are numbered 1, 2 and 4.
Code:
enum {
   PLANAR_Y=1<<0,
   PLANAR_U=1<<1,
   PLANAR_V=1<<2,
   ...
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 5th April 2011, 11:01   #50  |  Link
doobry
Totally Clueless
 
doobry's Avatar
 
Join Date: Nov 2010
Location: Edinburgh, UK
Posts: 31
I'm a giant idiot... ofc they are requested by name (or at least a named constant), ffs, I have an array at the top to map the 0-2 from the for loop to the constants AVS_PLANAR_Y, AVS_PLANAR_U, AVS_PLANAR_V... so that the loop is simpler.

So basically AviSynth isn't braindead, and if you request AVS_PLANAR_U it gives you U no matter what the formats storage order may be...

This is what happens when you convert someone else's method, to ms's ancient c that requires all variables declared at the beginning of the functions body, then don't look at it for 6 months.

@Gavino thanks for the well aimed cluebat. PS GScript and GRunT look pretty fantastic, would you have any issues with me adding auto loading of scripts via GImport? I can see two easy ways, a) Just load all scripts via GImport if the function / dll is present, or b) trying to load it if the passed file is *.gscript (or similar). Do you have a preference?

I.E. You would be able to do avs2pipe video myscript.gscript and have it autoload the plugin and GImport the script...

Last edited by doobry; 5th April 2011 at 11:33.
doobry is offline   Reply With Quote
Old 5th April 2011, 12:32   #51  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,384
Quote:
Originally Posted by doobry View Post
would you have any issues with me adding auto loading of scripts via GImport? I can see two easy ways, a) Just load all scripts via GImport if the function / dll is present, or b) trying to load it if the passed file is *.gscript (or similar). Do you have a preference?

I.E. You would be able to do avs2pipe video myscript.gscript and have it autoload the plugin and GImport the script...
Sounds like a cool idea either way. I don't have a strong preference, but if going for option b, how about .avsg as the extension (based on existing use of .avsi)?
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 5th April 2011, 12:38   #52  |  Link
doobry
Totally Clueless
 
doobry's Avatar
 
Join Date: Nov 2010
Location: Edinburgh, UK
Posts: 31
using an avsg extension would be my preference, as it means that scripts with GScript features would be harder to mistake for "normal" avs scripts, either linked on forums or "found" years after they were written.
doobry is offline   Reply With Quote
Old 5th April 2011, 14:01   #53  |  Link
doobry
Totally Clueless
 
doobry's Avatar
 
Join Date: Nov 2010
Location: Edinburgh, UK
Posts: 31
Quote:
Originally Posted by tebasuna51 View Post
avs2pipe [info]: writing 20 seconds of 0 Hz, 48000 channel audio.
I went through and changed a bunch of the standard fprintf placeholders to the super special Microsoft versions in the last release (0.0.3), are you still having this problem as I cannot reproduce it?

If its still there what flavor (vs or gcc etc) and type of input are you using?
doobry is offline   Reply With Quote
Old 5th April 2011, 15:56   #54  |  Link
tebasuna51
Moderator
 
tebasuna51's Avatar
 
Join Date: Feb 2005
Location: Spain
Posts: 5,660
Quote:
Originally Posted by doobry View Post
I went through and changed a bunch of the standard fprintf placeholders to the super special Microsoft versions in the last release (0.0.3), are you still having this problem as I cannot reproduce it?
Is ok now, thanks.
__________________
BeHappy, AviSynth audio transcoder, in Doom9 forums. NicAudio, BassAudio, audio decoders.
tebasuna51 is offline   Reply With Quote
Old 6th April 2011, 01:20   #55  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,171
@doobry,

In terms of plane order, generally you cannot assume a particular order in memory. In all places except env->NewVideoFrame(vi), CS_YV12 and CS_I420 are considered identical. This distinction is to allow source filters to import YV12 and I420 video data directly into a PVideoFrame without needing to blit the individual planes.
IanB is offline   Reply With Quote
Old 6th April 2011, 13:31   #56  |  Link
doobry
Totally Clueless
 
doobry's Avatar
 
Join Date: Nov 2010
Location: Edinburgh, UK
Posts: 31
Quote:
Originally Posted by IanB View Post
In terms of plane order, generally you cannot assume a particular order in memory. In all places except env->NewVideoFrame(vi), CS_YV12 and CS_I420 are considered identical. This distinction is to allow source filters to import YV12 and I420 video data directly into a PVideoFrame without needing to blit the individual planes.
Given this does reading via avs_get_read_ptr_p(frame, planes[p]) etc, always return the correct pointer to Y, U, V plane when using the AVS_PLANAR_Y, AVS_PLANAR_U, AVS_PLANAR_V constants? Assuming that another filter has not messed something up?

i.e. Is avs2pipe doing it right? The only testing I can do easily is using FFMpegSource which marks the stream I420, and DGIndex which marks the same source as YV12... Both given identical output with avs2pipe, using the same YUV4MPEG2 generation method, so it works for me, but I just want to make sure its not a fluke.
doobry is offline   Reply With Quote
Old 6th April 2011, 14:18   #57  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,384
Quote:
Originally Posted by doobry View Post
Given this does reading via avs_get_read_ptr_p(frame, planes[p]) etc, always return the correct pointer to Y, U, V plane when using the AVS_PLANAR_Y, AVS_PLANAR_U, AVS_PLANAR_V constants? Assuming that another filter has not messed something up?
Yes, because GetReadPtr (or avs_get_read_ptr_p in the C API) uses the appropriate offset (offsetU, offsetV) from the frame header (previously stored by NewVideoFrame(vi)).
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 7th April 2011, 01:37   #58  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,171
Quote:
Originally Posted by doobry View Post
Given this does reading via avs_get_read_ptr_p(frame, planes[p]) etc, always return the correct pointer to Y, U, V plane when using the AVS_PLANAR_Y, AVS_PLANAR_U, AVS_PLANAR_V constants? Assuming that another filter has not messed something up?

i.e. Is avs2pipe doing it right? The only testing I can do easily is using FFMpegSource which marks the stream I420, and DGIndex which marks the same source as YV12... Both given identical output with avs2pipe, using the same YUV4MPEG2 generation method, so it works for me, but I just want to make sure its not a fluke.
For testing SwapUV() with a planar just flips the pointers in the header (zero cost), so you can make sure you code is plane order agnostic.
IanB is offline   Reply With Quote
Old 7th April 2011, 13:20   #59  |  Link
doobry
Totally Clueless
 
doobry's Avatar
 
Join Date: Nov 2010
Location: Edinburgh, UK
Posts: 31
Thanks to IanB and Gavino causing me to look though the color space handling code, I've rewritten it for the "next" version. It now uses an internal buffer to organize each frame, before writing it to stdout with a single call to fwrite. Before it called fprintf for the FRAME header, and then fwrite for each row of data...

This has given me a huge speed boost, ~1.3 seconds to write 1000 frames to null, vs ~2.1 seconds using the old method, however I noticed that it will no longer output to the windows console, not a problem as you should never want to do that, but it did make me wonder if there is a limit to how much you can write to a pipe with a single fwrite... it still works fine via x264 or piping to a file, but I want to be sure.

So before I upload this and remove the link to the working version, does anyone want to have a test, or have any views on this... I will provide a download link via PM to a test version, but I'm not posting it here as I've noticed scrapers are linking to my downloads, which I don't really mind but I don't want some random site posting a possibly broken version without the info saying it might be busted.

Obviously this "huge" speed increase will be pretty insignificant vs the slowdown caused by say piping the output to x264 but it all helps.
doobry is offline   Reply With Quote
Old 7th April 2011, 17:27   #60  |  Link
Chikuzen
typo lover
 
Chikuzen's Avatar
 
Join Date: May 2009
Posts: 597
@doobry
It seems that x264 team schedules to change some encode options.
https://github.com/DarkShikari/x264-...3c468060efe1e4

I think that you might discontinue "x264bd" because it will be outdated soon.
__________________
my repositories
Chikuzen is offline   Reply With Quote
Reply

Tags
avs2pipe

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 20:44.


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