Posts by Poo2

    They have some wierd theory behind the delay and apparently it is intentional, even though FFMPEG's standard AAC doesn't do it, neither does Adobe's AAC or any other video-editing suite with AAC support for that matter.

    It isn't an issue with FFMPEG, its by design inside FDK... the delay can be noticed in very highly sychronized fast action video by those who actually create the video... for example my better half says she can't tell the difference.

    But where it really becomes apparent is when you re-import the mp4 with FDKAAC stream into Premiere and you will see the delay in the sample view.

    Unless someone seriously into dissecting code was to fork FDKAAC and engineered their own changes in, I'm afraid it would be wise to just stick with alternative options, for now I just stick with raw 24 bit pcm and let the transcoding server deal with the distribution formats.


    Just want to add for newcomers to AAC... The standard AAC built into FFMPEG is actually BETTER than FDK-AAC at higher than 128kb bitrates. FDKAAC comes into its own below 128k and in part at 128k. But Nero is still the best IMO at all bitrates, but I don't think Vouk will ever add functionality to allow us to use the neroaacencode.exe binary?...

    Sadly FDK still has that 'delay' at the beginning. I created a build myself with some tweaks to the header of output files, that reduced the delay by half, but still a delay remains nonetheless.

    (attachment is nested as this is only for techies)

    Firstly, hope all had a great christmas. :)

    I made the transition across to DaVinci from Adobe, though I shall still be using Adobe Photoshop, but in as far as video editing and compositing, my workflow now comprises of DaVinci and Nuke. Saving up to purchase a DaVinci Resolve Advanced Controller too.

    Heres hoping Voukoder will be available for DaVinci soon... :love:

    I've never seen the graph plot in windows move from zero... but if one has an Intel CPU with HD graphics enabled, then Intel QSV is used to decode video...

    is this all by design? or is my system badly configured?

    my research thus far has found people on the adobe forums claiming adobe do not use the hardware decoding functionality on discreet cards, but apparently adobe do use some features of intel graphics for decoding, so this concurs with my own experiences.

    It would be nice if Adobe actually just admitted once in a while what they actually DO support and what they DONT support, rather than never officially reply to their users.

    From CISC to RISC to ZISC
    By Sheldon Liebman (1998)

    The evolution of computing technology has produced some very interesting devices. However long the list, it’s a good bet that a ZISC chip should be on it. ZISC stands for Zero Instruction Set Computer and it’s a technology that was jointly developed by IBM in Paris and by Guy Paillet, Chairman of Sunnyvale, CA-based Silicon Recognition, Inc.

    Although it may sound like to contradiction to refer to a computer as having zero instructions, that is actually a pretty good description of this technology. The first generation of ZISC chip contains 36 independent cells that can be thought of as neurons or parallel processors. Each of these cells is designed to compare an input vector of up to 64 Bytes with a similar vector stored in the cell’s memory.

    If the input vector matches the vector in the cell’s memory, it fires. Otherwise, it doesn’t. As a parallel architecture, the ZISC chip tells all 36 cells to compare their memory to the input vector at the same time. As output, the chip effectively provides the number of the cell that had a match or indicates that no matches occurred.

    Silicon Recognition has developed a technology around the ZISC chips called Parallel Associative Learning Memory, or PALM. PALM Technology combines a control system, typically an FPGA and DRAM memory, with one or more ZISC chips to create a standalone, hardwired recognition system.

    In a traditional serial environment devoted to pattern matching, a computer program basically loads a pattern into memory, then fetches a stored pattern from each location in a large array. After fetching the pattern, it does a comparison, then fetches the data from the next location and continues the process. As the number of patterns you need to check grows, the speed of the process decreases. With a very fast computer, tens or hundreds of patterns may be able to be checked in a real-time environment, but eventually, a limit is reached.

    This is because you need to look at what’s in every array location to see if there is a match. With ZISC chips and PALM technology, the system provides the location of the match without having to look at what’s in that location. Instead of looking at the problem as "What’s in array location 12 and does it match?" the problem becomes "location 12 matches." By eliminating the step of loading and comparing the pattern for each location, the speed of the system increases dramatically.

    If you only need to compare an input pattern to 36 potential matches, it’s tough to see how ZISC computing provides a real advantage over traditional computing. However, the real power of ZISC is in its scalability. A ZISC network can be expanded by adding more ZISC devices without suffering a decrease in recognition speed. According to Silicon Recognition, there is no theoretical limitation on the number of cells that can be in a network. The company regularly discusses networks with 10,000 or more cells.

    One way to think about this is to imagine a large sports arena with seating for 10,000 people. If you make an announcement over the public address system, every person in the stadium hears it at virtually the same time and can process the announcement in a truly parallel fashion. In a serial version, the announcer may move from seat to seat and speak with one person at a time. Let’s say the goal is to determine if "Sheldon Liebman is in the house." With parallel processing, I can immediately stand up and shout "Section A, Row 12, Seat 3." In the serial version, the process is much slower.

    Thus far, we’ve illustrated the process of finding an exact match to an input vector, but ZISC chips can also be used to find fuzzy matches. Instead of asking if there’s an exact match, you can ask for the closest match. Then, cells that are above a certain threshold fire simultaneously and the controller in the chip looks at which one returns the closest value. For example, location 12 may have a 63/64 match and location 14 has 62/64. In this case, the system returns that location 12 is the "best" match. At that point, higher level software can determine if the match is "appropriate" through automatic or manual methods.

    This leads us into the area of training a ZISC-based system to perform pattern recognition. As an example, let’s assume that we are trying to categorize apples on a conveyor belt as Red, Green or Yellow. We might start to picking 100 different Red apples and presenting them to the system. If they match an existing pattern, they are classified as Red. If they don’t, we instruct the system to add this pattern to a new cell. Next we do the same with 100 Green apples and 100 Yellow apples. Now, the first 100 locations define Red, the second 100 Define Green and the third 100 define Yellow. Based on which location is returned as a match, we can begin to classify our apples. However, it’s reasonable to assume that eventually, we’ll get an apple that confuses the system. When this occurs, we can add the pattern for this apple to a new cell and instruct the system as to whether that new cell refers to Red, Yellow or Green. You can also instruct by counterexample. If the system mistakes a Green apple for a Red one, you can "correct" it and add the pattern to a new cell. Eventually, the system will "learn" the different to a very high degree of accuracy. If you have 1000 sample apples, for example, you may want to use the first 300 to train the system and the next 700 to test it.

    The characteristics of the ZISC chip make it useful in two very specific situations. The first is as a recognition engine plugged into a traditional computer. Silicon Recognition actually offers PCI, ISA and VME cards that fit this description. In this environment, the ZISC chips are used to offload the recognition function from a general-purpose computer.

    The second application is where you need to tie recognition to a particular function that isn’t being controlled by a full-size computer. ZISC chips use very little power and can be put into very portable environments. For this type of application, Silicon Recognition offers 84-pin SIMs (Single Inline Modules) that contain either 3 or 6 ZISC chips with up to 216 processors.

    The company provided a real world example of this type of application in the agriculture industry. A computerized system was developed to spray weeds that grow intermixed with crops. A system was developed that places a camera on a moving appliance that covers twelve rows of crops at a time and has 12 spray nozzles attached, one for each row. Moving at approximately two miles per hour, the camera captures data and the ZISC chips determine if the spray head is over ground, crop or weed. If it’s over weeds, the spray head is activated. In this type of environment, a full size computer just can’t be used.

    There are a number of other applications that are particularly well suited to ZISC. Face recognition is one example. If your pattern is recognized, access can be granted to software or to a specific location. If this technology was incorporated into a video camera at your front door, your house could actually unlock automatically and the front door open as you approached.

    Real-time monitoring is another area well suited to ZISC chips. In France, a system is being used to count the number of people that go through a particular area each day. Since the system can continue to learn, it knows the difference between a head and a backpack, for example.

    At Lawrence Livermore Labs, ZISC is being used to inspect the optics of large laser systems. Each time the laser is fired, the optics are checked for cracks and other defects. Depending on what is found, the system decides if it is safe to fire the laser again. In applications like this, secondary processing is used once a "match" is made through ZISC. Perhaps the defect will allow the laser to be fired once more, or twice. That response depends on the location of the match.

    As technology advances, ZISC chips are expected to hold more cells and work even faster for less money. The current generation ZISC36 chip was developed using 1 micron technology at IBM. Work is being done to improve the density of the chips and Silicon Recognition is hopeful that up to 200 cells may be able to exist in a future version. Today’s ZISC chip operates at 20 MHz and can determine a match among 10,000 patterns in less than 3 microseconds. The next generation may operate at up to 100 MHz for a significant speed increase. Current Silicon Recognition products start at approximately $1000 for a board with a single ZISC chip. The company hopes to halve that number by the end of this year.

    From CISC to RISC and now to ZISC.

    Zero has never been such a significant number.

    What they said. Oh and also don't forget to see if some silly background services churn away during encoder performance tests. Best practice is to switch off all the non-essential services and also to check in task-manager for any hiding apps too. Also depending on the antivirus you use, some tend to disable AV too during encoding performance tests or at the very least add exceptions, and some even go as far as taking the computer offline (networking) during the test.

    GPU is faster at some types of computations and the CPU is most definitely leagues faster at some other types of computation, so it is quite difficult to say which is better. In the ideal world it would be nice if QSV and NVENC worked together to bring even greater benefits to the table.

    Consumer pricing has escalated a great deal indeed. But I do believe that Intel still delivers bang-for-buck. Threadripper might be great for AMD specific tuned apps and bitcoin mining etc, but I wouldn't personally recommend the Ryzen over the equivalent Intel. Now if Ryzen beefed up their game in the single-core 'umph' department, then I would definitely consider the AMD platform myself.

    To be fair, if your computer does what you need, and ok it may take a few more minutes than the fastest glitteringly dazzling cpu/ram/mobo, then hey, just go and take the dog for a walk or attack one of your personal chores outside of computing. Personally I always advise get bigger faster SSD and more ram and a good enough GPU for what you need. Everything else can wait till you really see a massive difference in performance accelerating your productivity to the next level.

    Just my two pence. ;)

    red-tape and all is a nightmare, what you could consider in the spirit of open-source is simply throw up a little 'text-entry' box where the end-user is responsible for whatever goes in the vendor id ;) - that way VK is playing fair, though an EU regulation may appear in the near future which 'farts in the general direction of freedom' lol


    In those 'shaky' movements, if they are part and parcel of the scene and not something you want to lose, with X265 I would enable tune for grain, and also increase the scenecut threshold to say 80 at the very least and merange to 64 with a subme of at least 7. I believe Vokoder gives you access to these options. But please do note that encoding time and output file size will both increase considerably.

    If you want to smooth out the video and not desire those 'shaky' scenes, then as Vouk suggested, Premiere offers warp-stabilisation (google it for instructions). Or you can also consider using proDAD's Mercalli plugin (my personal favourite as it permits you to be a little bit more selective of how you want to stabilise etc).

    Warp Stabilizer:

    Mercalli (plugin):

    Or just use a circle with a dot you can move around inside it? like a virtual joypad thumbstick.

    Could have 4 points of interest then... the circumference of circle being the point of diminishing returns....

    But I have no idea what the 4th point would be, 10bit/hdr parameter enhancements? scenecut threshold, deblocking etc... hmmm...

    I recall a similar concept being used in an encoder donkeys years ago, I think it was an xvid type.

    It kind of replicates what x264 and x265 already do via their builtin presets ie 'fast, slow, medium' etc... and its then just a case of turning the quality factor up or down or choosing a specific bitrate to get closer to a predictable file-size, the builtin x26x presets already turn things on and off according to encoder developer designed preset configuration.

    But... if one was to take Poo's concept and say make it universal across all lossy formats with internally punched parameter variables relevant to each video format then according to mutation of triangle one could say it is probably going to be the most simplest interface for encoding newbies if there ever was one.

    Personally I think the x26x's do a pretty good job with just preset and quality. Indeed if there were a gazillion parameters to tweak behind the scenes then the above concept could prove useful but someone would need to spend a long while testing countless sources and configurations to determine every parameter combination to achieve some level of sense, it is why the x26x's gave us presets in the first place, and this simplification is as friendly as we can get without having a graphical interface.