Rodney

It'll take a bit of imagination to consider the potential but the following video tutorial by Greg Smith demonstrates some useful workflow in OpenToonz. It can help to think of images rendered in A:M in the place of the hill he draws and the ball he animates. Of specific interest is the path he draws that is then used to direct the animation. This same basic workflow can be accomplished in A:M but it can help to prototype that workflow elsewhere and then tailor the workflow to fit more perfectly in A:M. xhttps://www.youtube.com/watch?v=eIIMh2PVc2A This should also demonstrate how a program such as OpenToonz can be quickly used to storyboard and plan projects that will be modeled, textured, animated and lit in A:M.

Times are certainly a-changing... It's worth noting that by at least one account, not long ago Toonz would set you back about $30,000 per seat. (or rented seats on a monthly basis for about $600 each as of Toonz 5.0 timeframe) Now here we are in 2016 with OpenToonz available for free. OpenToonz now has nightly builds for Windows and Mac as well as access to source (not sure about Linux). This can be useful if staring at something that doesn't appear to be working but has been tagged for fixing. It may have been fixed but is just awaiting the next official release. Someone with a talent for programming can also examine the source to shed more light on outstanding issues. For those with the time and interest, I recommend the current nightly build over the initial v1 release and the subsequent v1.01 update as it replaces a lot of code that was set aside by Studio Ghibli, which formed the majority of the initial release of OpenToonz. The reason for this is that Ghibli worked mainly from paper with a team of animators, inkers/painters that each had customized 'rooms' to work in that didn't distract them from their task at hand. The elements not needed were still in the code but hidden. Now the initial set of those features has been replaced. So creating and storing customized rooms can easily be accomplished from within the OpenToonz interface. Don't like the general layout or workflow... change it. If previously installed you'll need to uninstall OpenToonz first before installing the nightly build. Installing over the top of previous setup will likely not work. There have been three releases to date (if you count the nightly builds as one): https://github.com/opentoonz/opentoonz/releases

This is something I'd like to delve into at some point but I currently don't have enough data to present. The realities of filmmaking are increasingly making it difficult for everything to pour out of a renderer fully formed. This relates to some of the recent changes at Disney where the Hyperion renderer was built from scratch in short order which was then used in 'Big Hero Six', 'Zootopia', etc. rather than Renderman, etc. What this makes me wonder about even more is how the dynamics work between PIXAR and DISNEY... not to mention other production houses (Dreamworks, Weta, etc.) who are in competition (or riding the coat tails of) the Disney juggernaut. Specifically with Disney/PIXAR though is the question about Research and Development and how elements of one inform those of the other. And with Disney's purchase of Lucas Films a ton of technology and experience has rolled in house that wasn't accessible before. And... we haven't even seen the next wave of films that propose to advance filmmaking more such as the next four Avatar movies... and how they've taken root with Disney too (in a way taking on the place of Lucas Film's Star Tours attraction after all that moved under the Disney umbrella). I don't know enough at this point to know what I don't know. PIXAR is certainly trying to project that they are fully invested in Game A. I've seen relatively little behind the scenes evidence released to suggest the contrary. I do think they shifted some significant focus near the release of 'Wall-e' and this was accented by their (rather odd IMO) decision to include live action characters in that movie. Their need to connect the audience with reality appears to have compelled them into Game B territory in order to make the common-humanity-gone-to-excess throughline of the story work. This sounds to me like you are attempting to be in Game B environment but with a Game A approach. Game B by it's very nature needs to be modular, scalable... open. Game A is, by comparison, modular, scaleable and (mostly) closed. What's the difference? I'd say mostly of inputs and outputs. The example of this in A:M would be that of textures. Textures certainly can be created in A:M and in fact they could all be created in A:M but that might be costly so A:M allows importing of external images for that purpose. Here then is a logical entry point in a Game A scenario. Textures of all kinds can be photographed, drawn, painted, created in almost any form for use as images in A:M's native environment. As is often the case... garbage in/garbage out... it's important to consider what foreign matter is being introduced into the ecosystem. The same can be said doubly (triply?) for meshes made in other programs as A:M is not optimized for use as a Game B platform. A slight caveat should be inserted at this point because A:M does work well with other programs but only as well as the differences between these programs inputs and outputs are understood. This is the same with every program. I like both Game A and Game B approaches. The one I tend to prefer is that which is currently (or optimally) working.

Whoa. Grandma needs to settle down and consider who is watching her! That's a very nice shot Simon. I like. There is always some finessing that can be done. Little things that might please an audience...even if only subconsciously... upon subsequent viewings. My thought would be to get some added emphasis on the bike to suggest weight. This might include any/all of the following: - A noticeable drop of the bike while the wheels either don't move or squash and stretch. I'm not sure if the bike is rigged for that. - A sharper movement at the very end where the bike drops would be nice and perhaps suggest the squash/stretch/impact even if it isn't there. In other words, the ride into the scene is nice and smooth.... as is the movement across the screen... as is the final landing... as is the stop. A little texture in the movement would aid in suggesting the reality and weight and forces at work. In reviewing the shot I can see some slight indication of this momentum shift but perhaps it could be exaggerated. Which leads me to... - Some anticipation and follow through on the part of Granny would be nice. For instance, Granny could be up just a bit more on the pegs of the bike (straighter) as she rides into the scene but then her knees bend down as she sits and lands. This movement would also assist in selling the element of weight that squash and stretch is often used for. I realize that this might require drawing Granny again... very not good... so the standing vs sitting as she rides in may not be an option. - Either some slight movement up/down or right/left to suggest Granny is controlling/resisting the bike's movement. Aside: What you are doing here relates to why I got into 3D in the first place. I knew it was going to be difficult if not impossible to draw things like motorcyles over and over again from altering views and 3D modeling and animation could most definitely do that. Bottom line: The point of the shot appears to be clear. Grandma has arrived at her destination. Well done!

The current forum banner (over the Latest Info forum) is a single frame from a 500 frame sequence rendered straight out of A:M with one exception; it was resized (to a lower resolution) in an image utility called Irfanview. Where I have the option I prefer to use images rendered directly out of A:M; this is something of a 'purist' view. I would relate this to what most would assume is the approach of PIXAR which is to forego any compositing, post production etc.; what comes directly out of the renderer is what will be used. This is the A game of animation. The ideal environment in which to produce. The B game is what most of us tend to use if for no other reason than practicality. I'll call it the new-Disney approach. It might better be called the Hollywood approach or Summer Blockbuster... everyone is doing it. And we enjoy this power of tweaking and adjusting, cropping and recoloring, recombining and generally re-purposing our resources. This is what I tend to use other programs for; initial setup (if needed) and finalizing for presentation. The attached is a rendering out of the newly open sourced program OpenToonz. Technically, it could be called a re-rendering. All of the imagery is still that which was rendered directly out of A:M but only five frames are used from the 500 frame sequence. The closed egg being exposed for the entire duration of the animation (almost as if it was a background) with the other four images superimposed. There are a few settings that didn't get adjusted correctly; the width of the camera's view is slightly too wide. I re-rendered in OpenToonz with a slightly smaller camera view to get all of the banner into view. The timing is not optimized; frames were exposed where I thought they might work and for as long as I thought necessary to be viewed. No optimizations or post processing to smooth or ease in/out. No multiplane camera moves. No recoloring. No film grain. No bells. No whistles. Just the retiming of five images rendered out of Animation:Master in OpenToonz via it's exposure sheet. Certainly, this could have played out in another fashion; the various elements of font, egg, duck, and ground could have been rendered out separately and composited together. This can be a very useful approach if you know particular elements of a scene will change or need to be re-purposed. Perhaps the show might play again but this time with some other character/animal emerging from the egg. Perhaps the logo might change or fade in/out... and on and on and on. I am always in a constant state of conflict between A and B; rendering everything directly out of A:M versus tweaking everything in post. It's not one of those conflicts like warfare though. It's an effort to render better imagery and perhaps even learn. It's like animation itself; working from Pose A to Pose B seeking the perfect breakdown position that will yield the absolute best performance in support of our stories. out000 shrink 4.mov

I don't really need one of these but I WANT ONE. xhttps://www.youtube.com/watch?v=9Pl7xM6atCQ I don't see an anticipated price yet. Sold only through resellers a this point. 96TB of capacity on the desktop up to 2600MB/s speeds RAID 5/6 Specifically designed for use with data from 4/5/6K cameras. For those with the need you can sign up to win a free one here: http://textseagate.com/nab/signup/

One example of a Pose that you would typically want ON by default is a Pose the contains the constraints that make the rig work. Ha! Now we've gone full circle. Yes, exactly. That was the source of great confusion with The Setup Machine all those many years ago which was my introduction to the underlying problem in the first place. I could not understand why folks would want to continually answer newbie questions about why a TSM rig wasn't working with the same answer over and over again, "Turn on the rig's constraint to turn the rig on first." Say what???

This is one of the reasons I was looking at containers like Brendan Bolles's MOX. If I understand correctly, it (and other similar containers) can store sequential images (compressed or not) in a variety of formats and with various codecs. It seems like an ideal approach but I don't have a deep technical understanding... my understanding is on the surface only. MOX/NOX is currently at the point where the Dirac codec is being optimized for use and that leads to considerable compression/quality ratios. A downside of MOX might be that it currently appears to require a plugin versus native processing in a given application. If MOX code is shared widely though perhaps code could be executed internally without plugins. MOX is also more of a production container... I don't know what potential that presents for distribution, presentation or live streaming. That doesn't appear to be its purpose. One thing may be certain, companies will look to see if there is an opportunity to make a profit from the end of Quicktime on Windows. Where there is potential for profit there will be movement. Development on MOX has slowed of late primarily because it has achieved the goals set out in it's Indigogo funderaiser. Perhaps the removal of Quicktime for Windows might encourage new activity with the format. A few months ago a poster from Swordfish posted this comment on the MOX discussion group related to Dirac compression with MOX: Although, it looks bad when every site related to the Dirac codec is missing/disconnected.

Yes, indeed! Although I perceive two 'problems' so I'd parse that as 'one of the problems' rather than 'the problem'. Thanks much for the insightful look and documentation of what is going on. This is an important element of the bigger picture (beyond the issue at hand but moving into a future state of even better understanding for average users and workflows) so I want to 'note to self' for that purpose here. I think it's important (although hardly so from a practical purpose in production) to move beyond things like 'T Poses' where models arrive in states that are 'unnatural'. Getting a model into what one might consider a 'golden pose' or even set of poses that help define 'character' (I think) is important. This may be especially true for shared resources, although I should caveat this with the statement that I don't think the originator of the resource is in any way constrained to get that resource into that optimal state/pose. Their primary focus is the initial design and potential (the modeling if you will) that allows for optimal animation. I'm stepping a bit far afield of the topic to further this idea a little more. Take a character such as Keekat for instance or several of the other characters that come standard with A:M and that are featured in initial tutorials. Keekat has one pose slider called 'Dynamic Pose' that demonstrates basic articulation of the model and (presumably) is designed to suggest character and performance. woo boy howdee... now that's what we are talkin' 'bout. Moving beyond the model... moving beyond the potential... moving into the realm of animating character performance (or at least one extreme pose on the way to that end). This makes me wonder... What downsides might there be to saving a character such as Keekat out with his dynamic pose turned on... thereby storing that pose so that it's automatically activated upon opening in an Action or Chor. The pro response might be to suggest that it is easier to start from the T pose rather than from a more or less random pose that may or may not be anywhere in the ballpark of what the shot/scene at hand calls for. I'm not convinced. I *think* we are looking more for a state where the character is 'alive'. The character 'learns'. The character presents better options to the animator/director to choose from from those that (currently) define its character. Put another way... Why would we want to preset a pose with any given setting in the first place? Why define a percentage pose from -100 to 100... 0 to 5... whatever? Why set a pose to on? When would it be better set to off? I submit that it's because there is an anticipated purpose... a framing of potential outcomes... a 'set' of environmental variables to aid and direct us in our future work.

I"m starting to get a list of things to run through Live Answer Time on Saturday. It's not that it doesn't save. One part of this is that the result of that state doesn't appear (in the Modeling Window (i.e. while it does appear in a Relationship, Action or Chor window). This is to be expected because Models aren't dynamic and Mark clued me in that this may be more of a workflow issue. I might be occasionally expecting to see a result in a Model window when it's not designed to be there in the first place. What I need to do on my end is put together a couple use cases that basically state (This works this way. This works that way. This way isn't working as I had anticipated... or isn't working optimally. Etc.) That would also cut down on any ramp up time during Live Answer just defining the issue and getting everyone on the same page. As interested in smoothing this one out as I am though I've got several other questions of more interest to me personally I'd like to pose during Live Answer and they might be of the variety where the question is introduced at one Live Answer Session so that it can be addressed in a future session. Actually, the following might be the 'concise' set up and question regarding the issue because it is something that is observable and repeatable: Robert said: In a Percentage pose we can Right Click and select 'Settings' to assign default values but... In an On/Off pose the 'Settings' option is not available. This may be the cause of my confusion because after using that option to set default values in a percentage pose I try to do the same in the On/Off pose but can't... in the same way. The logical reason for this is of course because there are (presumed to be) only two states the on/off pose can have (although there are actually three state); on, off and not set. But at any rate, the workflows of percentage poses and on/off poses are different enough that depending whether the Model is saved and where it is viewed the pose may appear not to have worked. Nancy provided an initial piece of the issue that I originally skimmed over (that of Saving) and that is an essential element to storing the persistent state. Therefore the step can't be overlooked in the workflow either. Gerald provided another piece of the puzzle by demonstrating a known workflow that doesn't apply universally; the Setting option is not present in an On/Off pose while it is easily accessed (and obvious!) in poses with percentages. I've found it fascinating that the word 'confusion' has surfaced on several fronts because those with experience are well established in workflows (that workflows that work that is) whereas on my end I've mostly just been bumping up against trying to repeat the exact same steps where those steps cannot be re-stepped. The approach/workflow is different.

I just returned from seeing the new movie and... This is an impressive movie on many levels. What perhaps surprises me most is that I didn't think I would enjoy it as much as the original animated version that is such a classic. No spoilers here except to say the film remained faithful is significant ways to the animated film. I was surprised by that too. Two other things that was a bit wary of going in but turned out to be just fine and well executed: - The film intentionally exaggerates scale on and they work that element like it's almost a character itself. As such it enhances the experience in significant ways and enlarges our view of the jungle especially from Mowgli's point of view. - While the film did have 'learning point' they were pretty seamlessly woven into the fabric and flow of story which is something few films succeed at accomplishing. Disney has hit on a very interesting approach of late that is well worth looking into. The last movie that I thought pulled that off well was 'Zootopia' which could have gotten bogged down and preachy but managed to avoid that. And make sure you stay for the end credits... those were as impressive as the film itself.

Doh! I just had one of those painful reminders that we should save often and save with incremented filenames/numbers. I had spend entirely too much time modeling a character when I thought to save the model. All is well. Then I began to adjust the color of groups in the model. Everything working fine. I'm really starting to like the progess of the model. Then I accidentally enlarged a group and it took over another section of the mesh, giving it the wrong color. A quick undo didn't work as anticipated and then I deleted the entire mesh except for the eyes.... Gah! No problem... I can fix that. Then... My fat fingers and dull mind accidentally Control Saved the model... OVER THE TOP OF THE PREVIOUSLY SAVED MODEL! GAHHHHHHHH! Very not cool. I should have saved again with a number appended to the filename. Then I'd still have my original. Perhaps I should remodel this thing while the topology is still fresh in my mind.

Not seeing the results in the Model definitely throws me for a loop every time. This may just be a matter of getting use to a particular workflow but I just tried a new pose (for a different test) and thought to also use it as a test to see how the default pose would work. I set everything up, saved the model and opened a new (empty) project to import the Model into. Upon opening the Model I see the results in the Model Window as if I hadn't set up the pose, although the Pose itself shows that it is set to On so 'should' be showing. To complicate matters, no Pose slider is showing in the Pose window... I must go to User Properties to see the pose slider. (That should have been a clue) Then I remember to open the Model in an Action and BAM! Sure enough the pose is on and displayed accordingly. Almost there but not quite. More staring at this is required...

Good thinking and an even better theory. My initial test didn't work but subsequent tests did. I'm checking again to find out what I changed in the process of testing. Choosing 'Constant' shouldn't matter though as that is the default so whether on or off constant is selected (unless manually set to time based... haven't even thought to try that... yet more variables/options). One odd thing I did note is that after saving as you suggest when the model is opened the pose isn't set to the last saved constant... in the Model... but as soon as the Model is opened in an Action the pose turns on (or off) in accordance with the setting saved prior.... in other words, correctly. This is in accordance with your memory of how it works. If this is always the case, which it appears to be, this may be a 90% solution. The only downside being that the desired default is not 'activated' in the Model until an Action or (presumably) Chor Action is invoked. This is a bit odd so I'm trying to lock my understanding of what is going on down and I'll bump this result up against prior tests and desired outcomes to determine what gaps remain unresolved or if I've inadvertently reframed my original target. There are some variables I still need to account for. Sorry for all the text but I'm documenting what I'm doing so I can repeat the process. Here's what I'm seeing at present: (Aligned with what you've suggested) I've created a simple 3 CP spline Model. Set an on/off pose where on turns the spline into a smile and off turns it into a frown. Set the pose to on and save the Model as 'smile.mdl'. Set the pose to off and save the Model as 'frown.mdl'. Open a new project (this is to make sure we are starting from ground zero with no pose data left in memory or a chance to inadvertently be in the wrong window) Import smile.mdl Import frown.md Note that -in the Models- the pose sliders correctly display 'On' (for smile.mdl) and 'Off' (for frown.mdl). The disconnect here is that looking at the screen wouldn't tell you this because the three CPs are in their original position in a straight line neither smiling or frowning. Again, this in in the Model view. Open a Chor (the same thing can be done via Action) Drag/Drop both models into the Chor Note that each model activates appropriately in the Chor (or Action) with Smile.mdl smiling and Frown.mdl frowning. A few additional notes Within the Chor the poses are now set at Use Cache Value instead of Constant. This is fine as the poses have appeared as desired. Setting to Constant merely locks those down. I find myself wondering if viewing the pose in the Model might not be a refresh issue but it appears to be the way it is designed to work (i.e showing the default pose of the model without regard to any pose settings. In the case of a character's T Pose the assumption being that in the Model we'd see the T pose but as soon as opened in an Action or Chor the Model would change to the default pose stored in the pose slider(s). Thanks Mark! You've given me another important angle to investigate. Now I have to investigate with an eye toward making sure I formulated the right use case/need in my post above. There I stated: From what I can tell this is be resolved *after* the Model is opened in an Action or Chor. While in the Model mode the poses appear to be correctly stored and just awaiting activation. (Stored potential.... I like it!) I need to better understand how this relates to Drag/Drop poses as optimally (and originally) intended to work. I should be able to rule out a specific need for (default) poses to appear (i.e. be active) in the Model view. At the moment, other than for aesthetics and perhaps to prevent confusion of the 'hey, I thought I posed this model-variety', I can't think of any specific case where that would be required. Aside: And if there is such a need, why are the poses in the Model not initially seen/active. Obviously, I also need to test on more complex models.

Still have to test the percentage on/off switches further as I'm getting inbetweening where previously I hadn't seen any and thought I'd be getting all or nothing results. A workaround there would be to specify smaller increments which while it won't remove inbetweening will make it negligible. Example: Default=.1 Minimum=0 Maximum=.1 ... On the plus side this actually aids in the pose to pose approach to animation in that we get the extremes easily and then refine the inbetweens intentionally (and if desired even mathematically).

Robert, Results from my quick test suggest.... that wont quite resolve the issue. For a second I thought it might. But we may yet turn this weakness into a strength. Taking a look at the percentage on/off option... In a world where all poses are percentage poses an on/off pose can be created by setting 0 as minimum and 1 as maximum. An important setting is the percentage however. That needs to be changed to 0 because if left at 100 my understanding is that will result in percent increments between 0 and 1. (which could be useful also) Setting the percentage option to 0 though results in an either 0 or 1 result which is exactly what we want. As of this moment, if a solution to the on/off defaulting doesn't present itself it looks to me like an all percentage pose approach may be optimal because on/off is a subset of a percentage between 0 and 1 anyway.** The on/off pose would then be used for generic poses that are assigned as 'not set' by default (i.e. a switch that is optimal for awaiting user input of the yes/no variety). **And all this time I had no idea A:M allowed us to create poses that leverage fuzzy logic.

Thanks! That's close Robert. I don't think it's a fix but certainly a work around. What we'd have to test would be saving the model out and then reopening and see if the newly assigned default is maintained in the process. Unfortunately, I don't think it addresses the main issue. The underlying need is to have any number of on/off poses set in the Model so that when they are opened/reopened in A:M the defaults appear as set and will revert to that default as necessary. This would be similar to that of setting the defaults in a percentage pose. And that presents another workaround. We can forego the standard On/Off pose entirely and set up a percentage pose that consists of boolean response; 0 and 1.... -1 and 0... whatever, as long as only two states are allowed. This would create the desired on/off pose whose default could be saved and reloaded. I briefly used that workaround once before. I'll look again at your video and double check to see if it doesn't provide a fuller solution than I see on first viewing. Easy enough to test. I'm curious if saving the Model out via the Chor saves the 'new' default in the Model or if it reverts back to original or not set.

We'll have to seek expert advice but as I understand it this isn't about the movie files... but about the Quicktime program itself. The program code contains the vulnerability not the files it produces. Hence the call to uninstall the program. Of course we can assume that a likely means of gaining access would be through files (movies) the programs opens but any executed code devised for that purpose would do. Perhaps it's time to get that A:M code for video editing out of mothballs. As this is likely a reference that won't resonate I'll offer this image of a feature none of us present (to my knowledge) have ever used. Disclaimer: I know that A:M can't have the code that it takes teams of programmers to maintain in video editors. I just ocassionally consider things that might have been. The timeline filmsstrip is only one of many features that had to be set aside for the greater good of all users (and greater priorities) back in the v10/v11 timeframe. Another would be the little 3D preview image that we could see and manipulate before opening a model back in that same timeframe.

This is something like a ten year old thing so I'm hopeful that a solution will float to the top. It can obviously take me awhile to get around to addressing issues but I eventually do. I vaguely recall using a text editor to test setting of the default but I don't remember the outcome of that. This was sometime around when percentage poses gained the abilty to go into larger ranges than 1 to 100 and allowed negative percentages.

That would be great *if* the Settings option was always there. Unfortunately, it doesn't always appear in all Poses (and hasn't in all cases as long as I can recall). It appears that this is primarily a difference between the On/Off pose versus the percentage pose. In the Percentage Pose the Settings option appears while in the On/Off pose it doesn't (always). This has been a long standing thing and I've never brought it up in the forum before as I've never locked down the rules of engagement (i.e. the optimum workflow). Try this and see if the Setting option shows up upon Right Click. - Create New Model (empty or otherwise) - Right Click and create a new On/Off Pose - Now Right Click and look for the Settings option to set the defaults Most of the time (although I won't swear that it's always) the Setting option isn't there to select. In a percentage pose it appears to always be there (I still need to confirm) Perhaps this is an omission that no one ever reported? I have a faint memory of the settings option appearing intially when creating a Pose but then disappearing later. I also have a dim recollection of asking Raf Anzovin why the Setup Machine didn't create rigs that were turned on by default. I never got a satisfactory reply to that query. Most folks said... just turn the thing on. I viewed it more from a newbie standpoint of deflecting questons of why the rig didn't work when what really needed to happen to activate the rig was turn on a pose. Could it be that an issue with setting the default to On was an issue even back then? Some of my thinking that the Settings option appeared/disappeared may just be the result of me going from an On/Off pose to a percentage pose and not realizing I had altered the variables. Added: As it appears to be more accurate I've edited the topic to specify setting defaults for On/Of poses.

I've done this before and know that there is a specific place we have to look to set this but I forget. Perhaps someone can get me back on track. I have a faint recollection that this is best set immediately upon creation of the pose slider as well. The most basic example is the On/Off pose where the pose is set to On by default (which without setting is 'Not Set' by default) In the case of a percentage pose the example might be to set the default as 0 on a scale of -100 to 100. As I have to occasionally revisit this It'd be good to get this cemented in my mind. Thanks in advance! Edit: I may have answered my question already but I'm hoping my answer is wrong. I see that we can easily set the default and other settings of a pose in an Action. I thought we could set the default in the Model itself.

As of February of this year Apple and Microsoft published an interesting document emphasizing the need to move forward and do so sooner rather than later. For those with an interest I've converted that document to PDF and attached it here. A few take-aways: The document describes some of the issues Apple is facing with splintered implementations to the MPEG standard From the papers introduction: This does beg a few questions. What is the current volume of data delivered over the internet and what are conservative and extreme projections of growth in the future? (easy enough to google) What is the equivalent of html for video (my term here.... hvml: hyper video markup language?). Future formats need to allow for such connectivity with images as html does with text. In short, how does the technology merge the two together to where there is no discernible difference between woids and picchas? Current realities don't appear to address this. What is the transmission capacity of the internet? (easy enough to google) How this will change in the future remains to be seen but (presumably) must be engineered. It might be time to dust off Martin's old notes on distribution of content on the internet. The document proposes some likely formats/standards: and proposes some constraints: All this quickly gets a bit too technical for the majority of us that just want to render and share our movies. Added: Some of the proposed formats/codecs such as AV1 designed to resolve issues of interest are projected to -begin- to come online in the 2017 timeframe. Apples move with Quicktime may be a strategic part of their effort to have the mass move more fully toward support of that timeline (and beyond). From streamingmedia.com: So, they believe that codec-wise VP9/10 and AV1 (or is it AV2 by then?) are on the rise. VP9/VP10 is a video coding format developed by Google that is open and royalty free. The AV1 codec is a product of the Alliance for Open Media (which formed in Sep 2015) w16144 Requirements for CMAF.pdf

I don't have an answer to that but for those wanting to get an overview of some of the complexity involved here's a relatively simple overview of formats, containers, and codecs that frame the question from the folks over at Videomaker: Link to article/video: http://www.videomaker.com/article/c10/15362-video-formats-explained One of the defining elements of choosing formats, containers and codecs is whether the video (and often audio) is in the area of production or distribution. Generally speaking, if in production, quality is of utmost importance (and a lossless codec... or no compression at all) will be preferred while if in distribution then a targeted audience will dictate what features to aim for. I wish my answer to the question raised could be 'HTML5 video' but to my understanding HTML5 is more firmly aligned in the distribution category. It feels a bit wrong to say it but I'll go out on a limb and suggest that HTML5 is primarily a distribution format. What this implies is that it isn't ideal as a production format. The key to better understanding what we need is to think in terms of loss of data. From the article they offer the following infomation/advice: What this means with regard to A:M is that the best format is going to be the one you originally render from in A:M. But... danger Will Robinson... this leads us to consider what the best 'video' format is for A:M and the answer to that precedes the creation of the (video) imagery itself.... the raw data formed of splines and patches BEFORE they are rendered. The formatting of splines and patches ensures infinite resolution that is likely to remain optimal. Consideration then must be placed on the formats ingested into A:M that are not of a scalable and similarly lossless resolution. So, the answer to the question of what format exists that can reliably scrub back and forth frame-by-frame, without regard to compression while keeping in sync with audio is the native format of our favorite program; Animation:Master. All derivatives from that original formatting are distributed interpretations (published renderings) of that data. Does this lead to any recommendations? I think so. A suggestion would be to optimize workflow within A:M to the point where rendering is a secondary consideration, although of relative high importance.** The degree of importance for distribution (and the targeting of specific formats, containers and codecs) then can be framed in terms of where, when and the degree of quality required for the absolute best presentation affordable within the current budget of time and money. **This is another way of saying, "keep the production phase of a project inside A:M for as long as it is reasonably possible." Added: Apple's answer to this issue is telling. It suggests they recognize a need to move on.

I haven't read very deeply here so take that into account... According to the write=up the vulnerability would be triggered by code from visiting a website (or launching a program). While they don't tend to state specific methods (to prevent people who don't know from getting curious and attempting the exploit) the user wouldn't have to watch or download a video. It would be enough for the code to know where Quicktime is installed and how to gain access through the files store/installed there to exploit the vulnerablility. Bad videos aren't necessary for the exploit to work. Those mostly just cause boredom.

My 'quicktime' update kicks in fairly often but it's almost always for iTunes. It rarely has anything related to Quicktime so I generally hit 'cancel'. When I just hit the option to update Quicktime the software said Apple Software updates were available but the update that appeared was only for iTunes. I'd have to double check but at a guess I'd say the last security update for Quicktime came out back in December/January. Here's the write up from US-CERT: https://www.us-cert.gov/ncas/alerts/TA16-105A One of thehe specific vulnerabilities open in quicktime is said to be the zero day program although, as with many such advisories, there is often no confirmed case of a use of said vulnerability observed in the wild. Note that these reports are generally for government entities to include networks where if such vulnerabities are left open that constitutes undue risk. In my estimation on most personal computers used by an individual where the program is needed the same would constitute an acceptable risk. Added: (The following is information regarding Apple's last security update for Quicktime)