Page 2 of 62 FirstFirst 1234561252 ... LastLast
Results 11 to 20 of 620
  1. Collapse Details
    #11
    Senior Member Ian-T's Avatar
    Join Date
    May 2007
    Location
    Back home in FLA
    Posts
    3,428
    Default
    Ralph B, I think this is a good sign. I'm not sure why some folks can't see this as a good solution (even if it turns out not to be 4:2:2). The benefit is...if you don't want AVCHD...you now have a choice. I saw some HDMI footage early on and I thought it looked a tad sharper than the AVCHD. I could be wrong but that was my first impression. It might not be worth it to some but it would be worth it to those why already have a HDMI capture solution. I say...if this works correctly...then it's worth it to get one of those capture solutions....especially knowing that better cameras come out all of the time and you could always upgrade to the next best thing...and STILL have you capture device.


    Reply With Quote
     

  2. Collapse Details
    #12
    Senior Member Ian-T's Avatar
    Join Date
    May 2007
    Location
    Back home in FLA
    Posts
    3,428
    Default
    By the way...do you have some raw footage for us to look at?


    Reply With Quote
     

  3. Collapse Details
    #13
    Senior Member
    Join Date
    Apr 2009
    Location
    Mannheim / Germany
    Posts
    809
    Default
    Quote Originally Posted by Ian-T View Post
    By the way...do you have some raw footage for us to look at?
    +1


    Reply With Quote
     

  4. Collapse Details
    #14
    Default
    Ralph, how does the script know where the spurious duplicate fields are? I mean, I would assume they're distributed evenly throughout, but -- how does it know where the first one is? It could be at any position, depending on when the user presses "record"...

    If someone wants to play with this, here's a file recorded from the GH2 onto the NanoFlash, shooting a consistent moving object at an identical speed, so it should be easy to detect any duplicated fields...
    http://www.mediafire.com/?ib3arayi6cw1ic3


    Reply With Quote
     

  5. Collapse Details
    #15
    Senior Member
    Join Date
    Dec 2010
    Location
    Los Angeles
    Posts
    528
    Default
    Quote Originally Posted by Sandbox View Post
    It wasn't deemed useless because of the lack of consistency for removing pulldown. It was deemed useless because the color gets trashed coming out of the HDMI pipe, somehow. The AVISynth solution is elegant, but doesn't solve why one would want uncompressed video that looks like this http://www.dvxuser.com/V6/showthread...t-front/page27
    While being "uncompressed" a close look at the HDMI image makes you realize you're not getting 4:2:2 resolution. Which kinda defeats the purpose of recording the image "uncompressed" to start with.
    At least that's where that conversation died.
    Thanks for the input. I've updated the script. Check out the first post.


    Reply With Quote
     

  6. Collapse Details
    #16
    Senior Member
    Join Date
    Dec 2010
    Location
    Los Angeles
    Posts
    528
    Default
    Quote Originally Posted by Barry_Green View Post
    Ralph, how does the script know where the spurious duplicate fields are? I mean, I would assume they're distributed evenly throughout, but -- how does it know where the first one is? It could be at any position, depending on when the user presses "record"...
    The magic key is the TFM function, Barry. It has the ability to sift through combed frames and extract progressive pictures wherever they happen to be. It was written by Tritical, who is one of the Avisynth gurus. TFM deletes nothing. So, you're left with a stream of progessive fames with a lot of duplicates scattered throughout. Now the task is to get rid of the duplicates, and that's what fdecimate does. Then we set the frame rate to 23.976 and viola, we're home.

    Of course, the script is only as good as the underlying functions, and it's entirely conceivable that a certain piece of footage might trip them up. But, so far they've performed fine.

    We do need people putting the script to the test to see how robust it really is.
    Last edited by Ralph B; 03-16-2011 at 02:09 PM.


    Reply With Quote
     

  7. Collapse Details
    #17
    Senior Member
    Join Date
    Aug 2009
    Location
    Utah
    Posts
    1,704
    Default
    This news (HDMI out) ...makes this news even more interesting....

    ATMOS WEBSITE....FIRST BATCH ON IT'S WAY!!!!!

    http://www.atomos.com/

    You figured this out....at the perfect time.


    Reply With Quote
     

  8. Collapse Details
    #18
    Senior Member PappasArts's Avatar
    Join Date
    Oct 2004
    Location
    LANYUK
    Posts
    2,345
    Default
    Awesome! The HDMI is way better than the AVCHD comparisons on the first thread. It's very obvious in the subtleties. Great work Ralph...

    Pappas
    http://www.pbase.com/Arrfilms
    http://www.PappasArts.com

    The talent of an artist is never measured on how real they can create something, its on how much life they can give it


    Reply With Quote
     

  9. Collapse Details
    #19
    Senior Member
    Join Date
    Sep 2009
    Posts
    1,105
    Default
    @Ralphi B - Nice workaround with the ConvertToYV12() !

    If I can make some suggestions:

    1) I would use AssumeFPS(24000,1001) instead of AssumeFPS(23.976) . Gradual desync will occur with the latter on longer clips, because of the approximation

    2) DirectShowSource() isn't necessarily frame accurate, and relies on system installed codecs/filters - this can cause inconsistencies. This may be problematic for some people, especially if you are doing non linear seeks or using temporal filters. If you have an AVI wrapped file I would recommend using AVISource(). If you have a MOV wrapped file (maybe from a AJA capture), I would use FFMpegSource or QTInput()

    TIVTC includes the function TDecimate() which is fairly similar to FDecimate(). Is there a reason why you prefer FDecimate() ?



    Quote Originally Posted by Barry_Green View Post
    Ralph, how does the script know where the spurious duplicate fields are? I mean, I would assume they're distributed evenly throughout, but -- how does it know where the first one is? It could be at any position, depending on when the user presses "record"...

    If someone wants to play with this, here's a file recorded from the GH2 onto the NanoFlash, shooting a consistent moving object at an identical speed, so it should be easy to detect any duplicated fields...
    http://www.mediafire.com/?ib3arayi6cw1ic3


    If you're using this for nanoflash footage, you can read out of mxf container with ffmpegsource2
    http://code.google.com/p/ffmpegsource/

    Another alternative is to use DGIndex and MPEG2Source() , but this requires unwrapping the .m2v elementary video from the .mxf container.

    RalphieB's default settings won't work on your clip, because there is field switching in your sample and longer strings of duplicates , so both TFM and TDecimate must use different parameters

    FFVideoSource("01293001.MXF",seekmode=0)
    AssumeTFF()
    TFM(order=1,mode=7,slow=2)
    TDecimate(mode=1)
    AssumeFPS(24000,1001)
    ConvertToYV12() #If you want to convert to 4:2:0

    (I've scaled this down by 2x, as it's just for demonstration purposes for the cadence of Barry's clip. It's MJPEG in AVI, if anyone needs a free decoder , install FFDSHOW. The VFW decoder configuration needs to have MJPEG enabled. You can examine frame by frame in virtualdub for example)
    http://www.mediafire.com/?2cl8m8agohp63lu

    (In theory, those parameters should work for other GH2 HDMI clips as well, but more testing of course is better)
    Last edited by PDR; 02-03-2011 at 07:53 PM.


    Reply With Quote
     

  10. Collapse Details
    #20
    Senior Member
    Join Date
    Dec 2010
    Location
    Los Angeles
    Posts
    528
    Default
    Quote Originally Posted by PDR View Post

    TIVTC includes the function TDecimate() which is fairly similar to FDecimate(). Is there a reason why you prefer FDecimate() ?
    I did indeed try Tdecimate, but some duplicate frames slipped through it, which fdecimate was able to catch. So, in my experience, I would say fdecimate is superior.

    Thanks for your tips. This is what we need - more people working on the problem.


    Reply With Quote
     

Page 2 of 62 FirstFirst 1234561252 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •