Latest post Sat, Jan 14 2012 3:36 AM by FredTex. 25 replies.
Page 1 of 2 (26 items) 1 2 Next >
Sort Posts: Previous Next
  • Mon, Jul 14 2008 1:07 PM

    DNxHD compression via ffmpeg

    So as to prevent a previous thread not only being hijacked, but forced to eventually land with grissly results... I've started this new thread to objectively discuss and explore DNxHD encoding via 3rd-party software, namely: ffmpeg.

    For those not 'in the know', ffmpeg is a command-line tool for compressing/transcoding/converting video and audio files... (you get the gist). ffmpeg functions not only under Windows, but can also be found on Linux and Mac operating systems.

    Recently I noticed that the ffmpeg builds included DNxHD encoding support. (The implementation may have been made many months ago, but hey, I can only report what I find when I actually find it Wink)

    Personally I use Avanti-GUI as a front-end to ffmpeg regularly, and find it's quite a nice combination for many day-to-day tasks. There are too many neat things to mention about the combination of the two to post here, so let's stick purely with DNxHD.

    Firstly, Here's the version of ffmpeg I've been using (Windows Build 13778):

    To confirm that DNxHD is an available encode option (if you're curious), extract the package and open a command prompt in the extracted folder where ffmpeg.exe resides and type:

    ffmpeg.exe -formats

    Then scroll up and you'll see DNxHD as "VC3/DNxHD"

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

    Okay, enough talk, some test results:

    Source: 1920x1080p H.264 Trailer 2:27 running time @ 23.976fps (No audio for this test)
    System: 2GB RAM Athlon X2 4200+ (operating at 2x 2.4GHz) WinXP + no excess programs/processes running.

    Quicktime or MPEG Streamclip format:
    DNxHD 1080p 23.976 @ 175Mb/s 8-bit Millions+ & 709-colourspace

    Encode time: 10m:15s

    ffmpeg-13778 via Avanti format:
    DNxHD 1080p 23.976 @ 175Mb/s 8-bit (unknown colour count and colourspace)

    Encode time: 4m:45s

    Based on my experience using Blender (another free tool), I found that letting ffmpeg assign CPU core affinity to only 2-threads on my system, actually hampered the speed. As a result of this, I always run both Blender and ffmpeg with 8 CPU threads assigned. For ffmpeg I add the following switch:

    -threads 8

    Clearly the ffmpeg version transcodes the source material at a significantly quicker rate. Over twice as fast... on Windows (I'll test my 64-bit Ubuntu system later).

     

    Test Notes:

    Neither method produced a DNxHD file which accurately represented the original colours of the source clip. (Not even using Quicktime and Avid's DNxHD codec set to RGB produced an accurate result). I suspect it's the age-old Quicktime gamma issue with H.264 material.

    To eliminate Quicktime as the decoding front-end, I did a 2nd test using an uncompressed 24-Bit RGB AVI generated from Virtualdub which featured the following RGB-accurate colours:

    Test Black: R=0, G=0, B=0
    Test Gray: R=64, G=64, B=64
    Test White: R=255, G=255, B=255

    In this second test the Quicktime/Avid DNxHD file showed accurate colour levels in both RGB and 709 export modes. By that, I mean the RGB & 709 exports BOTH had the exact same colour results. Black was 0 and white was 255 and the test gray remained accurate.

    The ffmpeg version however showed colour abnormalities. Black became 16, but white did not become 235... instead it became R=241,G=235,B=242. And the test gray became R=73,G=70,B=73.

     

    Caveats/Bugs/Finds:

    There doesn't seem to be an option to specify the colourspace for conversion (as yet), though google revealed some whispers about a summer-of-code project here or there to implement such a thing.

    The DNxHD implementation in ffmpeg at present is limited to 8-bit modes only, no 10-bit 'X' modes (as yet). Once again, there seemed to be some google summer-of-code suggestions about permitting 10-bit modes within ffmpeg.

    Since ffmpeg is command line, you have to remember (or have a list to hand) as to what bitrates fit which resolution (60Mbs for 23.976fps 1280x720p, 175MBs for 23.976fps 1920x1080p etc...)

    This last caveat isn't really a big deal as I discovered last night. If I set the bitrate in Avanti-GUI to 220000Kb/s (220Mb/s) I noticed that ffmpeg seemed to automatically 'cap' the encoding bitrate to the highest permitted based upon resolution.

    What this meant was that whilst I passed the 220Mb/s bitrate on to ffmpeg with a 1080p 25fps test it capped the bitrate to the highest 185Mb/s. Likewise, when I fed ffmpeg a 1080p 23.976fps file, it capped the bitrate to 175Mb/s. When I then sent it another file to be converted to 720p 59.94fps it automatically transcoded to 220Mb/s.

     

    Conclusions:

    FFmpeg appears to be seriously quick, and produces files which are the same filesize as Avid's own codec versions. FFmpeg also produced image quality which (to my eye) was every bit as defined... with the one main issue being that there is some weird colourspace 'stuff' going on. It's like FFmpeg is 'almost' turning every source file into 709, but not quite getting there.

    If quality isn't an issue, it seems you can leave the typical bitrate level at the highest (220000Kb/s 220Mb/s) and never worry about it again as it tailors the bitrate to the appropriate resolution.

    From my early tests I'd have to say that if ffmpeg manage to resolve the colourspace issues (which in all honesty are only very slightly out so it could be a typo in their source code) and then implement 10-bit processing... ffmpeg would be my default choice for encoding raw footage to a final DNxHD file.

    Ideally this would work very well with uncompressed image sequences straight from Avid. Much like the workflow associated with high-quality CGI/3D renders. Images > ffmpeg > DNxHD in what seems to be half the time.

    What I really like about ffmpeg so far, is that it does make really good use of multiple cores. I suspect that if you threw a video clip at a quad-core system running ffmpeg, it'd absolutely scream.

     

    To Do List:

    1.) I intend to take some footage and once again encode/transcode/convert using both Avid's Quicktime DNxHD codec and the ffmpeg version. Colourspace problems aside, I hope to do a frame-by-frame difference comparison to see if there's any detail loss through the alternative ffmpeg version.

    2.) I intend to test some interlaced footage (as ffmpeg requires an additional switch to process interlaced material).

    3.) I hope to take advantage of some HDV material I have to see how ffmpeg handles Thin-Raster DNxHD encoding.

     

    It is just the early days with ffmpeg's implementation of ffmpeg. Should they sort a few issues out, I suspect I won't be using Avid's own codec and Quicktime unless I ever really have to.

    MSI Neo-2 Platinum Nforce3 Ultra (Bios Rev 1.0D) Athlon64 X2 4200+ (Overclocked to 2 x 2.4GHz) AMD Cool'N'Quiet CPU Throttling 2GB Corsair PC3200... [view my complete system specs]

    "When the waters are at their calmest, that's when folk most want to skim their pebbles." - Me

    "Be water my friend." - Bruce Lee

    Filed under: , ,
  • Fri, Oct 10 2008 12:53 AM In reply to

    Re: DNxHD compression via ffmpeg

    Okay, I figured some updating was necessary given that FFmpeg has undergone various updates/revisions/rewrites.

    I'll focus not on the sheer increase in encoding speed this time, but look at Colour Space issues since they were a big deal when I last tested FFmpeg DNxHD encoding.

    What I used:

    FFmpeg Build 15394 and Avanti 0.2.9
    MPEG Streamclip 1.2b2 + Avid LE Codecs 1.10
    Avid Xpress Pro 5.8.4 Academic

    This 24-Bit RGB 1280x720 uncompressed progressive bitmap image:

    The Bitmap RGB-accurate colours are:

    Black: 0,0,0
    Gray: 127,127,127
    White: 255,255,255
    Red: 255,255,255
    Green: 255,255,255
    Blue: 255,255,255

    ==========================

    Settings

    Streamclip:

    Bitmap exported from Streamclip as Quicktime movie, 100% quality, 23.976fps, no audio.
    Used Avid DNxHD codec settings: RGB colour setting, 720p 23.976 8-bit 60Mb/s codec.

    Settings - Avanti + FFmpeg:

    Bitmap exported from Avanti as Quicktime movie, 23.976fps, no audio, bitrate=60000(kbps), aspect 16:9.

    Settings - Avid Xpress Pro 5.8.4:

    Bitmap imported into a 720p 23.976 project using 601/709 image/frame size and colour space set to RGB colour levels. (To convert appropriately upon import).

    ==========================

    Methodology:

    The FFmpeg and Streamclip DNxHD files were both imported using 601/709 for frame size and 601/709 for colour space in order to "Fast Import" without additional colour conversion. Thus putting the externally created DNxHD material straight up against the Avid natively compressed DNxHD version.

    ==========================

    Results:

    RGB colour values were sampled using Xpress Pro's inbuilt colour correction tool with 3x3 averaging enabled.

    Streamclip version:

    Black: 16,16,16
    Gray: 124,124,124
    White: 234,234,234
    Red: 251,36,13
    Green: 0,201,10
    Blue: 12,28,241

    FFmpeg version:

    Black: 16,16,16
    Gray: 125,125,125
    White: 235,235,235
    Red: 253,37,12
    Green: 0,201,11
    Blue: 13,29,244

    Official Avid-generated version:

    Black: 16,16,16
    Gray: 125,125,125
    White: 235,235,235
    Red: 235,16,16
    Green: 16,235,17
    Blue: 17,16,235

    ==========================

    Conclusions/Thoughts/Observations:

    It's really good to see that the recent FFmpeg build sorts out the disparities when converting RGB. The early tests showed dips in the green values compared to their red and blue conterparts. FFmpeg this time around manages to preserve accurate values for black at 16, white at 235 and a correct mid-gray value of 125 - entirely in line with Avid's own import process.

    Interesting to see that if you use MPEG Streamclip through the Avid LE codecs, the gray and white values are not as accurate as Avid or FFmpeg's versions.

    Also of note is how close the MPEG Streamclip and FFmpeg values are for the Red/Green/Blue bands. This is a much better result than with previous tests.

    What is REALLY interesting is whatever the Avid import process is doing. The black/gray/white values remain consistent with a 601/709 conversion, and match the FFmpeg attempt. But the Red/Green/Blue bands show significantly more saturation.

    I suspect that this is something gamma related as it doesn't appear to be affecting the lowest and highest black/white values, or even the gray value inbetween.

     

    All in all, it's a good turnout for FFmpeg this time. Looks like a lot has been fixed, but it leaves me asking why the Streamclip version, encoded through the Avid LE Codecs doesn't show the same Red/Green/Blue band values as the native Avid import?

    MSI Neo-2 Platinum Nforce3 Ultra (Bios Rev 1.0D) Athlon64 X2 4200+ (Overclocked to 2 x 2.4GHz) AMD Cool'N'Quiet CPU Throttling 2GB Corsair PC3200... [view my complete system specs]

    "When the waters are at their calmest, that's when folk most want to skim their pebbles." - Me

    "Be water my friend." - Bruce Lee

  • Fri, Oct 10 2008 1:10 AM In reply to

    Re: DNxHD compression via ffmpeg

    Aaaah, there's a console command which appears to affect the results:

    CONVERTCOLORSPACE

    When I type that in, the console reports:

    "HD sources will not be converted to 601 for desktop display"

    ...and the results for both the Streamclip and FFmpeg versions suddenly "pop" into life and start reflecting almost exactly the Avid import version values! (Though it has the effect of then making the Avid version go in the opposite direction, desaturating it.)

    When I type it again, the console reports:

    "HD sources will be converted to 601 for desktop display"

    ...and the Streamclip/FFmpeg versions resort back to their desaturated values.

     

    Problem for me is that this process evidently affects how you can colour sample an imported file, and since the files don't change, it means I have no idea what is the "real" value for any given file. Even the Avid one makes less sense if its values can be altered with a console command.

    Since this command can in some way show Streamclip/FFmpeg versions at the same safe levels and saturation I have to conclude that both Streamclip and FFmpeg do indeed encode DNxHD very well, but perhaps there's some sort of Colour space flag not being set in either?

    It's certainly not a matter of choosing RGB instead of 601/709 at the Avid import stage because that would crush already-converted 601/709 values even more and I'd expect to see blacks in the 32,32,32 range.

    Strange indeed. Shame because if it's just a colour flag issue I hope it's easily sorted soon because FFmpeg is such a damn quick conversion tool! Yes

    MSI Neo-2 Platinum Nforce3 Ultra (Bios Rev 1.0D) Athlon64 X2 4200+ (Overclocked to 2 x 2.4GHz) AMD Cool'N'Quiet CPU Throttling 2GB Corsair PC3200... [view my complete system specs]

    "When the waters are at their calmest, that's when folk most want to skim their pebbles." - Me

    "Be water my friend." - Bruce Lee

  • Fri, Oct 10 2008 4:54 AM In reply to

    • jwrl
    • Top 25 Contributor
    • Joined on Thu, Oct 13 2005
    • Melbourne, Australia
    • Posts 8,450
    • Points 98,435

    Re: DNxHD compression via ffmpeg

    Quite intriguing, Steve.  And thanks for posting the detailed results and methodology.

    Have you experimented with using the DNxHD codecs in Blender?  It would be intriguing to see if a QT export of your reference frame using the Blender compositing engine gave the same results.  I'd try this myself, but I'm at home at the moment and won't be back on deck until sometime next week.

    MC 7.0.4 - Asus P6T Deluxe V2 mobo - Intel i7 920 2.66GHz - Windows 7 Ult64 SP1 - nVidia Quadro FX 1800 - 16 Gbyte low latency DDR3 RAM - Internal 8 Tb... [view my complete system specs]
  • Fri, Oct 10 2008 5:44 AM In reply to

    Re: DNxHD compression via ffmpeg

    Good stuff Steve.

     

    I am not surprised of the performance with QT. It has been noted that QT is not threaded well. Keep us posted about the color space issue.

    MC 2022, W11, ASUS z690m, Intel 13900K, Gigabyte 3080Ti Waterforce, 128GB RAM, Samsung 980 Pro M2 SSD, BM Mini monitor & Dell UP2718Q. MBP 2019, Big... [view my complete system specs]
  • Fri, Oct 10 2008 11:07 AM In reply to

    Re: DNxHD compression via ffmpeg

    jwrl:
    Have you experimented with using the DNxHD codecs in Blender?  It would be intriguing to see if a QT export of your reference frame using the Blender compositing engine gave the same results.

    I awoke this morning and immediately thought of trying an export from another 3rd-party app. Blender came to mind because it can directly access the QT backend too (under Windows).

     

    Here's the result:

    Blender 2.48 RC-1 with QT 7.3 (QT, DNxHD, 720p/23.976 RGB Levels in export dialog):

     

    Black: 16,16,16
    Gray: 125,125,125
    White: 235,235,235
    Red: 235,16,16
    Green: 16,235,17
    Blue: 17,16,235

    These values are EXACTLY the same as the Avid version!

    This implies that there is something wrong with how Streamclip is processing the QT options within the Avid Codecs. Regardless of setting the colour levels to 709/RGB the same file is exported each time with desaturated tones.

    It's interesting that in Streamclip, the codec selection box gets cut off for some strange reason.

    It IS good to see that a 24-bit BMP from Blender, albeit exported through the Quicktime backend, generates a 100% accurate DNxHD file ready for "Fast Import".

    I really think what's happening is that Streamclip and FFmpeg are not treating DNxHD material in 709 colour space at all.

    MSI Neo-2 Platinum Nforce3 Ultra (Bios Rev 1.0D) Athlon64 X2 4200+ (Overclocked to 2 x 2.4GHz) AMD Cool'N'Quiet CPU Throttling 2GB Corsair PC3200... [view my complete system specs]

    "When the waters are at their calmest, that's when folk most want to skim their pebbles." - Me

    "Be water my friend." - Bruce Lee

  • Fri, Oct 17 2008 1:03 PM In reply to

    • macjaeger
    • Top 500 Contributor
    • Joined on Mon, Jun 16 2008
    • Coburg, Germany
    • Posts 241
    • Points 2,905

    Re: DNxHD compression via ffmpeg

    Thank your for writing this, otherwise i'd never known that ffmpeg can compress to DNxHD! Why? I've been using ffmpeg directshow codec, but it doesn't list DNxHD as available compressor (at least not in its GUI). Yet actually i can't find this compressor in avanti either, though the ffmpeg.exe lists it (using -formats commandline option, as you explained).

    Maybe i'm missing a step or two here... Could you please explain in simple steps how to, say, transcode a given xvid-compressed avi-wrapped video to DNxHD using avanti and ffmpeg? I'd really appreciate that, and i'm sure a lot of others would too. Especially since ffmpeg + avisynth will make a good (and free) toolset to convert avchd to dnxhd.

    MC 3.0 (soft) on 2.4Ghz Intel Core2Quad, 4GB, Win7, 3 Screens hooked to Nvidia GTX260 & 9500GT, 1 TB striping RAID [view my complete system specs]

    not a pro, just a teacher...

  • Fri, Oct 17 2008 1:19 PM In reply to

    Re: DNxHD compression via ffmpeg

    Okay, here's a short Avanti/FFmpeg list of what to do. (Make sure you have the 15394 FFmpeg build and Avanti 0.2.9 and that the ffmpeg.exe is sitting in Avanti's ffmpeg folder.)

    1.) Open Avanti and then the Codec Database Manager.
    2.) In the manager, press CTRL+INSERT to add a new codec entry (which appears above the one you're already got highlighted).
    3.) Highlight the "Ext" entry box for the newly-created entry. Press ENTER and type mov
    4.) Highlight the "FFmpeg Codecs" 
    entry box to the right, press ENTER and type dnxhd
    5.) 
    Highlight the "Codec Label" entry box to the right, press ENTER and give it a name like "Avid DNxHD"
    6.) Return now back to Avanti's main front end with the White arrow in a Blue circle.
    7.) Under Video Destination Settings, find the Codec area and type your label "Avid DNxHD" in there to activate the codec within the database.

    The rest from here on is down to your knowledge of the DNxHD formats. Adjust the frame size approprately (1280x720,1920x1080 etc... but NO thin-raster varieties). Make sure the frame rate is accurate, so use proper 23.976, 24, 25, 59.94 etc... (If you are encoding to an interlaced DNxHD file 50i/59.94i etc.. then you will need to add the following option to the USER VIDEOS area half-way down the main screen: -flags +ildct )

    In the bitrate area, leave them all empty except the first box Bitrate (kbit/s). Enter a value in here that is in kilobits. So for a 60Mb/s DNxHD file, put 60000. For 115Mb/s put 115000 and so on.

    See how you get on with it but do be warned that neither Streamclip nor FFmpeg appear to be exporting to DNxHD in 709 colourspace. Sure, the blacks/grays and whites will be DNxHD accurate, but the colour range/gamut/gamma/matrix won't be.

    It still bugs me that Streamclip using the proper Quicktime exporter is also ignoring the correct colourspace matrix.

    MSI Neo-2 Platinum Nforce3 Ultra (Bios Rev 1.0D) Athlon64 X2 4200+ (Overclocked to 2 x 2.4GHz) AMD Cool'N'Quiet CPU Throttling 2GB Corsair PC3200... [view my complete system specs]

    "When the waters are at their calmest, that's when folk most want to skim their pebbles." - Me

    "Be water my friend." - Bruce Lee

  • Fri, Oct 17 2008 1:42 PM In reply to

    • macjaeger
    • Top 500 Contributor
    • Joined on Mon, Jun 16 2008
    • Coburg, Germany
    • Posts 241
    • Points 2,905

    Re: DNxHD compression via ffmpeg

    Ah, now that i was able to register the dnxhd codec in Avanti, the rest seems obvious. Thank you very much! I must say that Avanti is not very intuitiv to setup, but rather powerfull once you get to understand it.

    MC 3.0 (soft) on 2.4Ghz Intel Core2Quad, 4GB, Win7, 3 Screens hooked to Nvidia GTX260 & 9500GT, 1 TB striping RAID [view my complete system specs]

    not a pro, just a teacher...

  • Fri, Oct 17 2008 1:47 PM In reply to

    Re: DNxHD compression via ffmpeg

    macjaeger:

    Ah, now that i was able to register the dnxhd codec in Avanti, the rest seems obvious. Thank you very much! I must say that Avanti is not very intuitiv to setup, but rather powerfull once you get to understand it.

    Yeah, it's a little strange to begin with but once you get your head around most of it, it's an extremely powerful tool to have in the toolbox. (I really like it's crop/scale/pad tool. Requires a little math sometimes, but what in the video world occasionally doesn't?)

    I've even edited my Avanti startup INI file to contain all the usual stuff I regularly use. (Custom frame rates, frame sizes, aspect ratios, sound formats etc... just tidying it all up in tandem with the Database... but that's all a bit tricky to explain in here... Wink)

    See how you get on, but I wouldn't really be using FFmpeg (or streamclip now for that matter) when it comes to DNxHD conversion. Not until one or the other sorts this disparity with the colour levels.

    Feel free to test stuff out with the RGB bitmap I've been using.

    MSI Neo-2 Platinum Nforce3 Ultra (Bios Rev 1.0D) Athlon64 X2 4200+ (Overclocked to 2 x 2.4GHz) AMD Cool'N'Quiet CPU Throttling 2GB Corsair PC3200... [view my complete system specs]

    "When the waters are at their calmest, that's when folk most want to skim their pebbles." - Me

    "Be water my friend." - Bruce Lee

  • Fri, Oct 17 2008 1:51 PM In reply to

    • macjaeger
    • Top 500 Contributor
    • Joined on Mon, Jun 16 2008
    • Coburg, Germany
    • Posts 241
    • Points 2,905

    Re: DNxHD compression via ffmpeg

    Just two more questions:

    What parameters should i use to create a DNxHD video that will "fast import" as DNxHD 120? (All my attempts import fine, but MC always does "normal" import, which - in my understanding - means recompression, and that's exactly what i want to avoid...)

    And what sort of audio compression would match the DNxHD 120 setup?

    MC 3.0 (soft) on 2.4Ghz Intel Core2Quad, 4GB, Win7, 3 Screens hooked to Nvidia GTX260 & 9500GT, 1 TB striping RAID [view my complete system specs]

    not a pro, just a teacher...

  • Fri, Oct 17 2008 2:02 PM In reply to

    • macjaeger
    • Top 500 Contributor
    • Joined on Mon, Jun 16 2008
    • Coburg, Germany
    • Posts 241
    • Points 2,905

    Re: DNxHD compression via ffmpeg

    malefunktion:
    See how you get on, but I wouldn't really be using FFmpeg (or streamclip now for that matter) when it comes to DNxHD conversion. Not until one or the other sorts this disparity with the colour levels.

    I'm still hunting for a fast and smooth way to import AVCHD files without multiple recompression cycles, as several of my students have sony camcorders using this strange format. Luckily correct colors are not a top priority, most of our cutting is just for training purposes, so ffmepgs misbehaviour isn't too much of an issue for us... still i'm going to do my own experiments once i covered the basics of avanti / ffmpeg :-)

    The combination of Avanti / AviSynth / ffmpeg has the potential to open MC to the widest possible range of source material, which is essential in my line of work.

    MC 3.0 (soft) on 2.4Ghz Intel Core2Quad, 4GB, Win7, 3 Screens hooked to Nvidia GTX260 & 9500GT, 1 TB striping RAID [view my complete system specs]

    not a pro, just a teacher...

  • Fri, Oct 17 2008 2:03 PM In reply to

    Re: DNxHD compression via ffmpeg

    Okay, so I'll assume you've successfully compressed a DNxHD 120 file then? Did you check it out in the Quicktime player just to be sure? (Always a good idea with 3rd Party stuff prior to the Avid stage).

    What version is that DNxHD 120 file? 1080p25? 1080i50?

    To "Fast Import", ensure your Avid import settings match. So for Video resolution, set it to DNxHD 120.

    Under Options, set the frame size to 601/709, and set the colour space box to 601/709 as well. If it's interlaced... you'll have to set it to lower-field (Even lines).

    That should do the trick. The "Fast Import" route often trips up down to Avid import settings rather than the source file. (At least that's been my experience working with Avid-compliant video formats).

    MSI Neo-2 Platinum Nforce3 Ultra (Bios Rev 1.0D) Athlon64 X2 4200+ (Overclocked to 2 x 2.4GHz) AMD Cool'N'Quiet CPU Throttling 2GB Corsair PC3200... [view my complete system specs]

    "When the waters are at their calmest, that's when folk most want to skim their pebbles." - Me

    "Be water my friend." - Bruce Lee

  • Fri, Oct 17 2008 2:23 PM In reply to

    • macjaeger
    • Top 500 Contributor
    • Joined on Mon, Jun 16 2008
    • Coburg, Germany
    • Posts 241
    • Points 2,905

    Re: DNxHD compression via ffmpeg

    Yes, I was able to create a DNxHD 120 file, playing fine in qt, and importing fine in avid - just not fast. The source was a HDV file (1080i 25fps), for export i used 1920x1080, 25fps, 120 000 kbit/s. Yet still i can't fast import it as DNxHD 120, using 601/709 in both frame size and colour space and having tried all three interlace settings. The project type is set to 1080i/50, standard raster type (also tried hdv instead, made no difference). Am I missing something obvious?

    MC 3.0 (soft) on 2.4Ghz Intel Core2Quad, 4GB, Win7, 3 Screens hooked to Nvidia GTX260 & 9500GT, 1 TB striping RAID [view my complete system specs]

    not a pro, just a teacher...

  • Fri, Oct 17 2008 2:30 PM In reply to

    Re: DNxHD compression via ffmpeg

    macjaeger:

    Yes, I was able to create a DNxHD 120 file, playing fine in qt, and importing fine in avid - just not fast. The source was a HDV file (1080i 25fps), for export i used 1920x1080, 25fps, 120 000 kbit/s. Yet still i can't fast import it as DNxHD 120, using 601/709 in both frame size and colour space and having tried all three interlace settings. The project type is set to 1080i/50, standard raster type (also tried hdv instead, made no difference). Am I missing something obvious?

    Okay, I just did a test too. Exported 1920x1080, 25fps, DNxHD 120, 16:9 aspect (important!), interlaced (-flags +ildct)

    Went to Avid, set it all to 601/709, lower-field (Even)... and it "Fast Imported" here (into a 1080i50 project).

    I think it may be related to the 16:9 aspect flag. Also, 1080i50 HDV is thin-raster 1440x1080, so unless your Avanti/FFmpeg setup isn't rescaling to 1920x1080 then I'm a bit confuzzled. Confused

    Make sure the interlaced settings are on and the aspect is set to 16:9.

    Oh, and for the audio side of things. You'll be wanting to use WAV 16le (little-endian) (might just be called wav in the default Avanti setup as I renamed mine), 2-channels and 48Khz sampling rate. You can ignore bitrate for this format as FFmpeg knows and uses the default rate appropriate to the WAV standard (1536Kb/s for 16-bit Stereo 48Khz material).

    MSI Neo-2 Platinum Nforce3 Ultra (Bios Rev 1.0D) Athlon64 X2 4200+ (Overclocked to 2 x 2.4GHz) AMD Cool'N'Quiet CPU Throttling 2GB Corsair PC3200... [view my complete system specs]

    "When the waters are at their calmest, that's when folk most want to skim their pebbles." - Me

    "Be water my friend." - Bruce Lee

Page 1 of 2 (26 items) 1 2 Next >

© Copyright 2011 Avid Technology, Inc.  Terms of Use |  Privacy Policy |  Site Map |  Find a Reseller