VideoHelp Forum
+ Reply to Thread
Results 1 to 14 of 14
Thread
  1. Member
    Join Date
    Aug 2018
    Location
    USA
    Search Comp PM
    Is there a 64-bit version of ef_barrel.vdf?

    Running into memory allocation errors in the 32-bit version of VDub2 prompted this question. The error happens when trying to save an MP4 from a 12MP image sequence.

    Edit:
    The only way I don't hit the error in the 32-bit version is by setting the 264 codec to 'Ultrafast' and limiting the amount of filters used.
    Last edited by MFZ; 31st Aug 2018 at 11:37. Reason: added information
    Quote Quote  
  2. I think it's only 32bit , but the sources are available, so theoretically someone could compile it for 64bit
    http://emiliano.deepabyss.org/

    Another option is defish_mt x64 in avisynth , or other applications that have lens distortion filters (e.g. natron)

    But what other filters are being used ? There might be equivalents in avisynth or other programs
    Quote Quote  
  3. Member
    Join Date
    Aug 2018
    Location
    USA
    Search Comp PM
    Originally Posted by poisondeathray View Post
    I think it's only 32bit , but the sources are available, so theoretically someone could compile it for 64bit
    http://emiliano.deepabyss.org/

    Another option is defish_mt x64 in avisynth , or other applications that have lens distortion filters (e.g. natron)

    But what other filters are being used ? There might be equivalents in avisynth or other programs
    Hm.. crop, 6-axis color correction, and temporal smoother..

    Would I link AviSynth into VirtualDub2? Or..
    Quote Quote  
  4. Originally Posted by MFZ View Post
    Hm.. crop, 6-axis color correction, and temporal smoother..

    Would I link AviSynth into VirtualDub2? Or..

    Those other ones are native filters and can be found in the x64 vdub2 version

    But you can crop in avisynth too, and there are various temporal smoothing filters available as well (ttempsmooth would probably be the closes to vdub's temporal smoother)

    vdub2 has avisynth support , you can open an avs script directly as if it were a video
    Quote Quote  
  5. Member
    Join Date
    Aug 2018
    Location
    USA
    Search Comp PM
    Originally Posted by poisondeathray View Post
    Originally Posted by MFZ View Post
    Hm.. crop, 6-axis color correction, and temporal smoother..

    Would I link AviSynth into VirtualDub2? Or..

    Those other ones are native filters and can be found in the x64 vdub2 version

    But you can crop in avisynth too, and there are various temporal smoothing filters available as well (ttempsmooth would probably be the closes to vdub's temporal smoother)

    vdub2 has avisynth support , you can open an avs script directly as if it were a video
    Thanks for the info. I'll keep it in mind.

    I got it to do what I wanted though by checking 'Zero Latency' in the x264 codec configuration.. but why would that use less memory?
    Last edited by MFZ; 31st Aug 2018 at 17:43.
    Quote Quote  
  6. Member
    Join Date
    Aug 2018
    Location
    USA
    Search Comp PM
    I just verified that this command line switch: --tune zerolatency, is what makes the encoder use less memory. I'm still curious as to why though..
    Quote Quote  
  7. Originally Posted by MFZ View Post
    I just verified that this command line switch: --tune zerolatency, is what makes the encoder use less memory. I'm still curious as to why though..
    zero latency means --bframes 0 --force-cfr --no-mbtree --sync-lookahead 0 --sliced-threads --rc-lookahead 0

    It uses less memory because of no lookahead, no mbtree, no bframes . This usually means lower compression efficiency, lower quality .
    Quote Quote  
  8. Another workaround you might be able to use is frameserve from the 32bit vdub to another 64bit application, even another vdub2 x64 instance. That should workaround the memory issues
    Quote Quote  
  9. Member
    Join Date
    Aug 2018
    Location
    USA
    Search Comp PM
    Originally Posted by poisondeathray View Post
    Originally Posted by MFZ View Post
    I just verified that this command line switch: --tune zerolatency, is what makes the encoder use less memory. I'm still curious as to why though..
    zero latency means --bframes 0 --force-cfr --no-mbtree --sync-lookahead 0 --sliced-threads --rc-lookahead 0

    It uses less memory because of no lookahead, no mbtree, no bframes . This usually means lower compression efficiency, lower quality .
    This info is highly useful!
    Quote Quote  
  10. Member
    Join Date
    Aug 2018
    Location
    USA
    Search Comp PM
    Originally Posted by poisondeathray View Post
    Another workaround you might be able to use is frameserve from the 32bit vdub to another 64bit application, even another vdub2 x64 instance. That should workaround the memory issues
    I'm gettin' AVI Import Filter Error 80040154. I installed AviSynth.. It works if I open the vdf file with the 32-bit version of VDub, but that's pointless, LOL..
    Quote Quote  
  11. It works here 32bit vdub2 to 64bit vdub2 . The vdub frameserver doesn't use avisynth

    Did you run the auxsetup ? You might have to merge the frameserver64.reg version
    Quote Quote  
  12. Member
    Join Date
    Aug 2018
    Location
    USA
    Search Comp PM
    Originally Posted by poisondeathray View Post
    It works here 32bit vdub2 to 64bit vdub2 . The vdub frameserver doesn't use avisynth

    Did you run the auxsetup ? You might have to merge the frameserver64.reg version
    It works. I didn't have all the auxsetup files in the main directory. They came in a directory called extra.

    I'm assuming the slower rendering FPS is to be expected?

    Thanks for coachin' me thru this by the way!
    Last edited by MFZ; 31st Aug 2018 at 19:18.
    Quote Quote  
  13. Yes it's expected to be slow. Lots of overhead . If you can use separate drives for source / destination that would help

    At least it doesn't crash , and a working workaround - until you can get someone to compile an x64 version of ef_barrel.vdf for you

    Or another workaround would be to split the processes up by applying the filters to a lossless intermediate first, then encode the intermediate later, but you would need lots of HDD temp space

    I bet the defish_mt method would much faster; definitely a more tidy workflow
    Quote Quote  
  14. Member
    Join Date
    Aug 2018
    Location
    USA
    Search Comp PM
    Originally Posted by poisondeathray View Post
    Yes it's expected to be slow. Lots of overhead . If you can use separate drives for source / destination that would help

    At least it doesn't crash , and a working workaround - until you can get someone to compile an x64 version of ef_barrel.vdf for you
    I see.. Yea, it's a workaround.


    Originally Posted by poisondeathray View Post
    Or another workaround would be to split the processes up by applying the filters to a lossless intermediate first, then encode the intermediate later, but you would need lots of HDD temp space
    I may try that outta curiosity.


    Originally Posted by poisondeathray View Post
    I bet the defish_mt method would much faster; definitely a more tidy workflow
    Without a doubt, LOL..



    So, to recap.. One actual workaround for using 32-bit filters in a 64-bit environment is to frameserve from VDub 32-bit to VDub 64-bit.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!