Smooth Video Playback
This seems to come up a bit on the forum but I haven’t been able to find anything that I can make work.
I have a very simple patch. Just crossfading between two jit.qt. movie objects with dials for controlling playback speed. No effects or slabs. The clips are 640 x 480. I’ve tried PJPEG at 75% and Apple Pro-Res. The codec doesn’t seem to matter. The clips still stutter during playback. I’m really hoping for smooth playback as almost all my clips are text animations (rolls, crawls, etc) and the stutter is super noticeable. The clips play real smooth in a standard QT player but once I try to play them in Max they stutter. Any tips to optimize my video playback great appreciated.
I’m on a Mac Book Pro, 2.66 Intel Core i7, 8gig Ram, External fast firewire 800 hard-drive, Max/MSP/Jitter 5.1.6
----------begin_max5_patcher---------- 4223.3oc6cs0aiaiE94L+JHLFfBraRpHEotzGVLscmtsOzoEcl18ghECTrXR TGYIWY4LIsn+2WRdnrkRrnnikYTa5fL1V2O7ima7bNj52ewIytn7V9pYnOC8 ynSN42ewImn1kbGmn29jYKRtcddxJ0oMqf+wxK9kYmBGpleasZ24kIoWjTbU yAJVuHqHmWqtHrdmWVVTuJ623p8QN2a64Vtt99mLrq56VxAxal51i9e5CuLo d90YEW89J97Z3Lv9dLwME4Gp9JvS9IQ74lKJKUQrhFvY3YsHphjEpmxrOuJK Iel7.+wKdg7iSOLXoFcA5hCGSHFwjSs.an9QJnIfn9hZBZBGYrYAe0pjq3O. bVUWtbmXCYWXC9bVLCGEteLMFAkfH.TBwpuT7K3ncCJA9tATlmySpdZQEF.G g.qRfQTg97RLJDGp.EbvvhQALmfMo77j6DDAyydtlwW2qFXHQpuBhMBLAO2X ZTbKDlMLMgOSz8FF.1pAVEy5dwXumKJeCIQsgEpYXg87RPhEAnBw2BAIxyHs uZfgDSsP66yLOeYwd1q80Q5Y7COhbKCLFIhRuajGHIcNqe8KrQFMtXcccYgQ dhQanfDpROJQ0oCdxJ+bmMS5Hx1+aKRVh7DO+Pj24Dj+46r4xbRGM30AV0ei 8BMw3yFYKIoxqaD5nuLuLoda6rfySy4yKyKqfSPzbBoL7oxePt+uvsZqFPHg 2EJ1inlO2I.s0m0q577I33.uH4iMlhwgApe4whhHcIfK5dYwhSkFpn1.I419 WpKaD01fO+ISaCgprEgAkNCntYjc8Uv6HZCF4BqqxVMOIW8fD8I6sOdDy7sm ZUPqHfjIfTLiAshE4F6SUI0bzKwOodB2v6PhUgifxL4JLK9u5Ftor3slxLKH QC9Sqca+HRS27Plsog+UzrMsIp0gVX0lF87ypMEha.lXiQ6+1l89yA5G4CdE EZgll3milroAXvhMdXK1XOxyGS1ZVGB7kYK1XOG4KCwyy6oaz1fBbpGX1NzD hPcSz79kr5yuJ+7axR4kKySJ3HoHUcRA5UIqqKWjTmMWXJ7UJoLgdMeeewmx +dUcURwpKKqVHZhq30H7QL9NBx78BZoJ6VoLo4H7D.g8BBKHkXTfj5lLVshm ivGNa2fg+xbl77A4Q3qPi3h+HqJWzNtfWcDYPxJrSacCH34Or1ZJ9X54rrIj Uz0QnXOguHf+OMNBEv7hi55HxQ0maM.EXiO2jd7nZqabQRGpXm1poYvipnsW 1C90i0ip5xqtJmOFtwJ4vr.3vvHyfDkK+bmHm+HpbYYEeIuHEc6kIo7iXE2X 11FFbChEpz9BkRQeBVjQN1NyKWrfKU.bOj4KNbzvyTHIHPoQ.iAg3arIG3ll 7mebaxB+zflL0hlripQF7SnGcXv4VMKv.QzzQ3wSHZP8rGMH+E0CCglPOvK+ .KBgK1MpE9Okn2UZO3XbzfFUIBsceHghTy5Gntos+sY2tOLFO91NTXOLcnRL l1cByMs82IGiVVcVYA5cYK3NAEn.2u5qXib+jH2fBKV4hFtNNGPwKoS2ZeMb 2O7pwJRYWKQ0ttsGJCV5o67Ws81+wqQk.IESCsLiZU72X9S.BYKVunc+1NP6 dFJRf3epf69ve8XGJhEgybdRgn0KvC9DuqaOxno1bHipjHnFGXfOdWcdmO9c emto+o4oH18HNjrj4e3oMcoMNgnyirwDG46lhiSFsCjGpmZiyeTbRavffsAX fPaXFXHdNAX9GRV7idr5uWZ3LIpBdv.IznWrYj8bcUdV5.lv1..d3wN1E.OQ LTAPTHv7g8zv2HsTVkI71HQ5ck5gOhdrrrRL3NDWn1eIGUWhfvXgtbcd9p4U bdAZYdxcWzRMCDKw0E0sYaNJAAHF7uUmSZX7MxBobm40I1YYwn+veYiPTKyG J1dg8BUDKUwhU+q6EC1QOuEpQMyXTXNkXNW+tQyzRzquslWUjji91xhr5xpm r3KRhAcRXHe+DioY0z3JZ+L3UZLQCJhKHKmeCuZUiL8o58ukRzkZ.jjIOPwA oUbdkNijWN+C7zVxQmLKke49bOJWxK1d9d.KYqO5dlYEREFsUF094lrNu986 tuo6wuLYNu2Kdmv3IytpJKsrPRDctR4tadbhdOH4ur1zs5LJRVtiKttrL+hj paxVkcQNuS+ffMNQ3YXRMuNCnGh2lqKawxpLPC3l8wKRD2iqEZMKyy6bqfib yNNRJ+lr47OlkVecGGPu2DjsEeSGArN62nB+tRaeYd17OH01un7FgV+q4Hod sOlUjV9QjfuVvN7IqP5skFEDmAoHEklsRZMn88bWVC5Ut0fra+VF5UPErKnC 6ELVM+1Lr8Lyaen35WVtVXfsZVygUpzfeb5iD86nla2YQYY4pYiJd09h5WmW +58.6.wjsoUocHUef2ItDN6FA5t34KwnWR5EIIOcHIjYNc4nDzOR5OQXLaW6 .iDPRLAjOnVB50gEX5nASu9GVdOOvkkIBd9uFazzHaY6rFO.Pp8jFODPxlJh 33fHOw.58wDOT7ljvMMD1AvDCUDpt5EMIsGLwLCshWOoLCowSF0NyPgSD3rR zT4FD3wit5SqTcpsEggo2KTwHlfyHmBmsSlfYHamQl9wClO5.Tae9EFPGrd9 VOnwr3A6PZc7GStEbkngZPBhOKqRGY+d8GTJYObxvSahLXnNFr2Tw5HfoN0Y CKQSBDwgffgLJhwSGvbcQ8zCIYL6FKAlLQrGJCnfNbAqPuRU21KJSGAKj6Y7 SOR8GgZKoCZPE6zQ2YJnOu6ZNn9MqHoluBUdI5NAEnBryhNwb8oNvNZW.aRR BavH6PmJX7+k+IUbTYQ9cHgOAbAaeMOU7SUDzpKWdVN+xZYjeTUJSuvsuSga H5v5Re.CKXaThA3lMQzwbC+1kUnWlgQ+ysI6cRELMXIQA6MrZhfoBK7mmJTP bk.OQKytkmuRF+2jaJyRQIE2gDW15KRpVcdu7tTWx6pC9KjUUrmt9OL.yNc3 hp1durkG8373uIWH2KiH8kDKs8Uf2PdzwDLfFhUBo6m5Khdowy1Va79zZ2lE IISdOIjQQUxiuaXXkfyZdS2mdLcntzWpvPgzrrNmZ+7l3ucuy65rzztovBJg ozkkB9BM4Y4351WpNxRpN7OkTs+jhpCsjpClTTMyRplNonZpkTsbLpSHx12V xdZwiPrkrimTjM1V8HXxzhtCrjtmXjs0b2dSK51Z16ok8lcnaabo6.e4TzhP naWOB5rgdoSWcVgLqiM8d2N8rrcNwz9HIarEjczHR15cJnecQwlbCO88P0A8 9j55prKVWCtD2ot11U4ccrpIrgp4LSkSVd4EI45hyay4L6EaQgQZVR1pTZeI 9Ia00ocQM9vrp1Iipi7bl1cSLde8DhG2ZdQ0y7hOJXjWzMHgO0q5F5VOrjGZ d1uDE5jh58C761In3sOfBcfI00C+ZXPhDCA4zXkOGE8mU4.bfdBBBLArlO2Y qLdTWd2uqX9SnVtlFdPq4hTep4hwNaBCzTHsMq2QxVOJf5IjR8PuJkur95KV e4k7JrCV3psP7fg0KhwFmZowDmAfqu6l6HIUWcwzXgeJRmM1X110Bv9WH1bz KVAdM5Ia8XHDPBRy60FiK.a9NgsQkOhdllWrwz9Sy+GRobHXywGF0SnwoVLl 5LQqes97Ek2jwQuJIMYYsXTFu5lxb4Bw15hrecMWtCUJ2UYuWJHdjlGXiofo NsP5LG22LFyMq6cM0YYEOI8oZNMEAu9szKUBlWxjvi75GzZYJCatkxU5ukkK WmmTyumiOVCHB.8xraAkdY42vqpqJKxlm7Ye56pxdqv.6qugW7oy1I70L2ey p4Kzi8clGA8te3aN6su6yeC5699W+lyD2lyj2GzWkImOZeeU4Ov+MoThj+6T 4GdTzOkT7qqyVc8YeA+xxJN5KkSwGza3eD4Qr4NDfda1pUbN5a4UeHq.QdO1 lKKB8kB4PICUBGY0CJJwhK4rk+xR9UctPrG5GyqUS.JzOvqVWXEAhInWWjd2 hrxBaNaJ5GPud9GJQBjXUChXGTfCDsqhUqWrPEDDathHzWmHKBwuRzgI3arB +Hdvw3FN2AW3I5p3Rd7MAdwjACHwlAf4TyinCG9b0YLFnym09soPuumUdF3K FyCB+QruEK8qOOcESCQ9PMXa1UL++1SrCPpTupoSzqTU83IVzyFGwzS8dJr3 FZ1Qr3+r6G12kltOtggQeSQZlv95WK5fry2Fez69Izaut7ixEMfZgp3MdSYy UyPu4tEKulWmUuNc+tzPkuGkU05qxlqIVbMRTpqOIXwcPzpkkI52UkLOmu5r 29l27UY2dFbOd6+t646i9Bdx7qsyEIlvkphqD+YyIGh9wBgiT1cmiQkEbzkp imH3wbt2QLnX+zuCcGx6nQNTUR00Wtb0UqyFok6sG+xLDr7Iiia8pm1umP85 6+2qEb1uVvAKnf5oJq4U0J5rovp9l6xu.DWksq2nFfF1HZ.+WWvElXPaYiOV KfUC+l3.B7qJ73AFeyN56v24vHdUxpwZk2z2pW.lhugG5vnEFVkuzND1GbE5 x2EEUB2A4UayKivd90kHxwVmtUYhA.M8qSRLyLSlkNPqt1tExL.h2udTzP4C Kb4NkITekNSmZf5gEfx8K9DbnZ4aVOnLQCtYidzBZMwZAsFsej5ARQQ1PR2C iO5zTjMvTnaooPano.2RSAVPSggSOZBum73f.ne7lYCVyVGJwZAs51tzvvif 1rCklvsqzuwQqEMPofkBk6h7sVTyViAwND.RoSO.DydjHHT9bMH3gaiJvFVv .2JVDXiVk.laoIlMzD08zzPbZA9tklnSNmdtGBLIHIhM1MwL2STCp3paAre7 IJazvG3VSjAd1PSX2SSC044XUA1Xa1sbSLaF+y9J1gILvGUlx3bbSLPau03a 3lYi6r2q8NbSw2OPMMYfWpMMsL0lGJ8FdDnWmPSQON1AcwesARorCGCsQjh4 VqFL1Q.COTZxFmPXgSPZxau40BUu4wzqP89vqou6sYndKekxmvCeXWLa7nh4 VCfLxDjlrw4Ee257ByFmWXtc.e1nBg5VUHTq7TvaRRT6ICkerJ1BDHGizPuM acnjazwfbOThxFa9z3IHMErucqXYGYLLuKgpgpyFvbThFn7VQtwg1Jrx6D2B r1nYweeM55iUdzQaVYa82t4gRu1XXk5ViXTaLrRc6PKoVYX0wBwdSuXQaiOm tsmS0oLXLKCcOMMX7b7ld3DaO66BhgEACX8VDi0F9CoGrhKqfP1dZoOfR5Pt z3QkbGLTmtUVUV4ICRSg6ot+PX3g52Qw521ac1xGljxxsX5sFiFxfZchbO3R FYZRtbOJQWf+jQ2rgK3D7crdaabty2w5ssx6N2NTVepszD1czjMdvQbr8Ma7 fi3X9IOaCWiC66rYHztcDzjviPhcvXHtCAdpZZMJV+BCr8VLHIJrPklV1HjD EhURFtc7VDqFaiioIajLHtkMDGcLJETnbynPMUS2twgRr1XRG6VSU3fiPxPO TZhYUHCcKMYiIcraMUgsxtfaG.C1l5GwswjAaG+ji4wwdSPhxKZ7qRJclEF+ 5979IMXjROSStOBUKVIM4EIjLBzqstL4NOKspzYODlPwF+wK9+3jKuDG -----------end_max5_patcher-----------
Might be that your pro-res is not the correct codec(there are different types). try with the 422, lq or proxy, see if any of those work properly.
Thanks. I did try all the different pro-res codecs and pjpeg as well. Doesn’t make any difference. I wonder if it has something to do with the fps playback not being completely locked to the actual frame rate of the clip. Fluctuates around 29 and change and 30 and change. I’m stumped as I don’t know how to get the metro to play the qt movie back at exactly 30 fps.
I would recommend leaving them in UYVY until the image is on the GPU, and using the slab-based conversion. Also, the XFade can be replaced with a slab as well. This will provide the most efficient processing. Here is a retrofitted version of your patch that should give you a little performance boost.
----------begin_max5_patcher---------- 4335.3oc6cs0baaiE9YmeEXzjY5L6Z6RbiW5C6jzroa6CMsSha2G5zwCkHrM SnHUHobram9eeAH.kHsDIAonfo81LNRhR7xAe3bGG.7mu3jYyStikMC7MfeC bxI+4KN4jhuR7EmnN9jYK8uaQjeVwoMKl8kj4eb1oxeJmcWdwW+wv7yuN57r H+4f7zvrb+XvqtJLhAVr3702e68nzqm6e9GuKq7RW4mu3lv3quLksHWRAtT5 4VmBnPKwaHncwa7C.+t5hhWuLLNhkWPKH0WFFTPBbx5Lmx69UIw4w9KYE+xq SC8ils8VjrN+g2C4Wke+JljTDMnKuN5RQCbcJa1ofYy1PEhadV3eTbpPDmHU snTVFKN2OOLItVqBWoUU9B32EWze8hWHd4zCC7iR7Cl6GecKPKDaUfsXmh2r sZGZg6Bsv9Bsvlf1BRsQvb7fkbvbv7VvDB1s.RrQEuQ5Mj3.GM1MY22Q.aVx xx7ulsC3jkmrpErw1UhMNvh2JXWft8PRzFOZ7KMfGvyodTnqyHBJKhX9osgJ TIb3H4Xr6OpPlvnx.EibfNEngTc8.DiroSewnFvl.Vj+87VK0pa.B4V7lsWu spYa+rS2qix3NcvLMNOa085XKMUK4TFftWHz5YnxWGjaUXgL.Xg97S6K0UBG H7PEjPOu09p.HjGYnZee944K0y5.09Z8zU6K1o03jPEJecsjRUmS6oRF5QW0 6vPi4qyyShaqkiHE5WQE7DRObEupMOAkLLogwis+OV5uBXwaIN7HrQ.74s2Q K8.AVzeCsbZWHftmFLcZ1UGT442RKGJSHgia4qs2SGyXAQrEIQIox6C+pcHT XQ1LPO7SvJ2tpP1VOYut1sBA8rsbE2AOBD5XW7IKpqKp98RS77pnD+7sf575 OLO9Cf3TPt1B5s5mfCL0LMosAdd6xbE1ifRkNCQciyzjGj2AversyEJk3jH. s+Ijh51cSWjJxE9QE+BueueVljLQsaZ5H3GbpeNC7RnFrMHuhzQPn81UXp2S v.DZ0vMg5s0t0.DjH1OQsaicQkc+CxrMw4ojYaRYlqcFpUah6SRq1DYRAfnG Ai1+sM6ZxaXo2SNCUSi2STS1DanzhMbfVrgVn+e0jshqAIea.VrgVtOAMYir rrZeTIKjhHVRy1N8FVHSzXvZeXxuMLfkrJxOlscvx8WmmrzOObA2T3qJj.35 0vXL+UweuJO0ON6pjzkWJFl4bPabaTaYxtjIEjf5unJgLpijNugkFdW6ih93 gxYrnVgGarTXT9liUuSIH1azS+03hKqWNmkpABXgGnpbx3Mz2gw4Gk7+0omy JPvdvdNiZvwnsdV4J7KhJcLh6sDbPNFUGYD+bXbce5Ju4U7tylZ44V+w8.Op b2Rk67og5QUdx0WGw5Fygxn0jift3U8AcbOUqKXuFynUVkxVwhC.q7S8WB74 zff+sYSbPoWSTG4.Vgo8VVCMQywyhjkKYaa7aPnus0TWfjkPgLbFDt+nQuCT 2532jecqb.VpAtjLzlL9QrI2XPRs6YGT5oqpedHY1DOM45aBOZGMHVGHZfln 941kmFb8eVRW7sGZddm9tZzjZg+SB3hjV0FJAGrb3FICP0.YTTMb.g90Ta+G CuqcFCU88RUIRwq+sc5TssegHVsPQc.CtHbIqcTfHEOJdyq+hGH2oJJrLq0F tJUHx5aBY2+Ft2icCutxON0Ftb8xpOn86.jSk1Ms+h7XqwMIZ2H5vpGYfiHK tmt2OUMfhAnesDsaHjDa9+JRx6teZngjTOslU6j1T397yu7Kgma0ssLJofaU UuD8puaisrE9w76OGnXUO0IWOZeRnp45SaJzL+EeRGWQTC4rS+y6C5oWADJR V.vBPszAYjYAoKjAuGkwiWAgYprD9ODZ.fZfJJOTjC6Qu3WPiWoC9fQGarXZ xhBCzy+cOYQCQj4n2oOFpQczVSCKm1TU+5MMOqsJk2mXzH5whXFbkAXbEsqX f7DfLcVfqVGEksHkwhAqh7uedE0LxTwIRATENf8.idRmbUCasLJHQcWp+Xm4 8HlCf9Oo+RNONIcoejXF+AdU0bkwk5ZcjKjSAPJoRQ61KYNxf0DUwrETNK8b KRrZQdUUepUikZOmAGes7q.u8tbVZreD3GShCySZOzKOoBMnrjBP8ejbMQQT TsAvRUXhBT3mMmO6VVZVcsFmLaayTUpDxgByRpECUIWyBWUhRV7IVPEwkSlE vtpO2ijUr3smes43oZhdV8LCiqNKQe3y0ecT9k6GFp+6W4uf03Eu2tiSlccZ XPRrfHpckhut7wwYMjiLMsJcWbFw9q1yEmmjDM2O81vrv4QrZ8Cb1Xetu194 r7PI8fr1bcgKWkFJUZt46Xw976wMbEsIQQ0tUxe4187KAraCWv9RXP9M0bo+ ASr4J7M0Dvp88sZintz1ahBW7IgAhkI2xMTbCCHTE9kv3fju.3xGb1guJCnN VXGgeFn3.PPXlv.R0649Lfznbqz7gJGZxPGwUYwZRzso4x6tRvuIYM2Zb5r5 2vcspznkkSJUoI+voCD8qolqgAfIIaVG3kpDS8JTvImQqUy5p13EZ33U06Xy 59N1vY8jVWGOeID7RjlHob.6TkuhcaHIZ+HI9oNR1BiY0xNnQ+ajiBnbV3ua Y.oMNRFNNhZCG2obDdDwy+ktnoxcZ3fQS5QhqTN1yO9h3PaWKfEGgPV.uMia WiB6R7DJKxTUgNNHoc6mwR6klgxX4ZhmRt0CvLjyyX3LkSUrNE3U1gfxoBrr HRFDT5djzeZVcmUG+gNzQpl7zzAiXd8Aw1a1p6.KGbVq0erHZILyAm5ZSIZT Dj.+0jzfL85xsTVGsGbeNzZ3hI3NESNch3.rDS0zYCjLI.11C1nHD9bNZhEU pGt1QRJ8.ik.hdFaOTjPAU5Bx.upnjuWlDvzjK0QYYb3FHgiTjZ8LopOxcHs kzmKtgIU+FF6myx.IWAtmiDEI1YYsbt1+D6n7PrbLVnCOyNjIepcZCi+uruJ kARhitGvsey3r84r.9GKxfVdxpyhXWkKx7SQw0zHbi6.tk4yUUIFP4x.GAMD 3l9TNSZ2xtaUJ3kgPv+b63C2UJfjqfJPqCP0xS9vBaiE90AbEDWywSvpv6XQ Yh7+5eaRX.vO9d.+xVO2OM67F4cIcneWUtTREFVp5QYH8BNSdV2h1fV16vaF 1hGL3E6fFVMfFtiUJdJ4MD24YiHXHex5IjhgZiGMwc3oWueWs1sihjfIugAj ongH988CCYb1wEk3cYXI.Xs1T.2RgvtrZP09sMQ4Cp21uILHn9XXIqJrfUI7 dRE8oYfcChrszfr8lVjMTSxV3x3Pnaarnb3QHx14.ZsCTKYsEmkCU63t6c6D cjamGK5FqKcaMsnaaMoazzhrc0EtmVzs1b2SKsOZybaOoHahtjMbRQ1TMIax jhpczjpmVrH5pGA+jjpclTTsmlTMcDoZ0WxIeU8r5eKK3RY0AcoeddZ3704R WhqVWaGZYd0xO0UElccTxb+HU81s4dT6NuCEs2v+jnvHMwJqT8ssuDqTsnF2 cTV6duiXhNMq6bN0iUykdXkIRUelR8t1OxSodQgyfb5tEJWkD6ZZ2rmtVWmI 950w9wkOwtuSPA4IydYGSYCq8.J8tFdIcLuu18MiJG.sUynPICBs7U8ED7Lk fPiqL72Guni09QUiztxbXpWp47fO4VwjJKj1xoXf3IArIVbUAVfWEvVkey70 WcEKsayCTnZQNt+y2TOzzVIRi7TrbPqaOEdRIkxc7k9uzjgeRwQUjo8VmySN RcpXYRnbv8dMlDRFaUqk+erUp1hT2myOeYxsgLvq7C7WkCffWcaRjX0Iacb3 mWyDeQwn6VLtzh83q9NonbKKA.4XZnF1ydMqnnOgWlxJqfvTlePa6JZx8mJ0 JDfa+mzwvI5Ra6ZwfgUR.hk+tUIqVG4mWaFQKd3ahxpMQV4.eXKUeMfolMr2 9Hh0QlUiMMtqBuSpnNL5VVZdZRb3B+u4quHM7Cbycu8VV7WWR.g4rkJzXlEB bw6+gy9vEu9cfe5me66NieAmItBv2EJlGX+bZx6Y+gPFVPHmJdwh.9U+3OuN L6ly9V1UIoLvaDSsFv6XeAXgz4NXC9PXVFiA9QV5mBiAnKg5bYtf2v0RHX28 Y.sdPt9ZbIms5iqXWW6BgVfeIJuXhGAdOKccrVDHDAdabv8KCSh04rIf2Cd6 hOk.3HQVIhnGT.s4sq3r0KWVj7ActBWv26KJ9uui2gw4PzB+PVxei0x4Nlwv MJa.jzCdCfz9QYCfzfdqQsjg46gG5Jl5yLm0T.BVVfyCvYM7e6qlF9poDMUK C4H0h1Te7Uy84uqZpYuNQtf+M.W07d96oFUVyRpcVzA4oFZZ5o1OEDreG0ff eHNHjaP764rO548CFbwuB9vMIeQLc9y4FJ13ukNWME7t6Wt5FVdX95f9coNE dmjjlqtJctFO90Hvi5ds.42AdqVT.m+Tp+hHV1Ye3cu66Bu6L483C+65mOF7 sL+E2nmSTTtSWwWy+SmS1A7Kwh8jYstydfjXF3phe2mKAL19OITWe0prqWG1 51uqrdfqrYMi6SlLwXSrb7LZKcZ6aASwZ6TcG6z+EZKxeuHoMl4VWlalsqdm 8s6f9HODSedIiqtFrUtnw1nSQPG18egmAajco2izNLJfk5m0MC.TtHXY2+Ew Z73kdkZ6Xj72kjtofKUftob2A4ghuITWtEyaR.nNQP0trHj1+McSrqoF.h8f ZEmX8h3UBhOrTLTP4tExUsJcpoR8qVYirawWr+BuXmNVcooG73ZnVmr5GMAg NVhRU0VthG6p13YqcDkrYQgmpN5.aJ1GgVxARRZCtPiQRO.AZflHFElfTMnI yJW3pAEYaVPRm9MpYIIKjFDUw91TenJhT6ARsSF5g1bzASu5zs1SpUQeDY8m H12gJO5PoVnNhpPC2kqkrpoIJTMUnZLkRN9jDVGXxvpYI5PSlUOKzdBxN4nA 6DzvZ+0QykGpm9ogcKTVIC0ir8fC0oRcTbgPl0QWcre9.OzO5zjNlOQlklzR ukY65v5vNgQF0MZrVcclMZCrN52E4nwj3DUWZxf3jN1bvl0NHVGaNXr4oITW zTOcWVLg8Ea8SNpr.r4fwfXsFYh0DcpN8T+tiibqyRsQNnJ+gpGgk0Ds3Hp5 nCsg3oiGQl0aVrmFc3zdZoxlnB1TtvgAIdaNzDPHsmB31d3ZjqGZTI2NS.hk 46w6BBsMqdasL4ZVJRKGcMazvDc7VhXXbRGOcIl04ahVdK02rwig1EQ1Utxg h2d3gRu53IkYCdmnUN2s6aN9fBHySN+Jk0AVsCjyEIhcQHzhCLRqvvBwtZkr WyFaHw6XPTk4bVV1Ek4iFOBBLdGiDlefDkNJcHFljzIjepYCajB0MMDFjlzw vJ0rFwn3IHMoieZz9ZXEQkwho1SqvxM16Gbni5HbQntNGtND8ZKl0MXpN5Pn FVGhVNmXVuSnNGAbhyGV32gZ5CxY0r2bnQnWy5GB08HPSa.MYlT1.otVGNF5 cDFhqRBDSKTx3UVgrUOhHKwF2xgjdDJwFKcxRoQ4Fr0wSAayZswVGOErMqmB 15LF4OrjCLBQ0onggG9Wa73WjHGJIQldjDUmjwgMOM0obmYSSssNdgXaXNbc rpaa1nqJFFD3HakjXi1X5aTMD5.mdUQoVHn6.Avwt31bbNB0yxgVymZUKR8E Akto4sYg1u7HSPrNFtnY0oS00r5Ub0pjOMLNoSDAdl0mUuImGFdviQIu4TnP SMk4kBmEGTiX4G7Wu3+wFmkVp -----------end_max5_patcher-----------
Thanks Ben! That helped a bit. However the playback of the clips still stutters and is most noticeable on text roll/crawl animations. Do you think I’ll gain some performance by stopping and clearing the qt movie that is not active in the mixer? Or do you think it is better to just let the clip play until I load another one? Is it just not possible to play QT movies at 640 x 480 smoothly in Jitter?
It could be that the data rate is too large..even in photojpeg..this sounds like more of a disk speed issue than a processing problem..I’ve definitely played two 640×480′s simultaneously while doing a million other processes and never had a noticeable stutter.
Open your clips in quicktime and go to ‘window’ and select movie inspector..it should tell you your data rate for that clip…if its much over 20mb/s its probably overkill and could be bottle-necking your disk..pro res codecs would definitely be a high data rate codec
the problem is the ji.qt.movie object.
it always stutters !
independent from codec or hardware ..
it would be really great, if someone could write
an external which solve this issue.
the quicktime play engine from openframeworks could
be a good start. (there is no stuttering)
for cycling it seem to be ok as it is …..
its a pity …
Yes, the clips are over 20mb/s. But I don’t understand how that is a disc issue if they play fine in the Apple QT player or with the VLC player. But I will try a codec that is less than 20 mb/s to see if that solves the problem. However, I’m also afraid they won’t look good anymore if I do that.
They play fine one a time or both at the same time in QT? I have the exact same machine you have (8gb ram), play things off of a 7200rpm FW800 drive, two at a time and I sit pretty steadily at 30fps..and I’m sometimes running 10 slab effects and jumping around within the videos.
My photojpegs are around 17mb/s in terms of data rate..although fw800 claims 800mbits/s as it’s throughput, it is much lower than you think according to this article: http://en.wikipedia.org/wiki/List_of_device_bit_rates
FW800 can at best get around 98mb/s, so if you’re running two videos that add up to be more than that..chances are you’ll have some stuttering…dropping the quality just a bit to 50% or so really won’t look too bad
I tried photojpeg at around 17mb/s and the playback stutter is just as bad as with the prores clips (maybe even worse). Weird. And I’m not even playing two clips at the same time. After a 2 second xfade I stop and clear the non-active qt player. It seems to me to have something specifically to do with Jitter and/or perhaps my patch (with edits from Andrew Benson) still isn’t as optimized as it could be. There has been some mention that softVNS plays video better than the jit.qt.player but I really can’t afford it at the moment.
Thanks again for your help!!
Is Overdrive on? At what point in the playback does stuttering occur? Is something else happening at the same time (like reading a new movie in, for example)? Sometimes a small stall will occur at the loop-point of a video as the hard-drive has to seek to the beginning of the file. This can be alleviated to some extent by using "loadram" messages to load the beginning and end of the clip into RAM.
I’m not sure what Overdrive is except in audio circuits so I’m not sure If I am using it or not. It just happens throughout the length of the clip. The clips are fairly long, anywhere from 1 to 3 minutes each. But I do not have any effects other than the cross fade and I am not looping anything. With the xfade each clip comes on really smooth. I haven’t had much problem there. The stutter really comes and goes but more often than not it is there. It is just especially noticeable on the text roll animations. Do you think the problem is the clip length?
Overdrive is an option in the ‘options’ menu..it ensures timing related things run as accurately as possible, but its usually more important for audio related tasks I think…but I’m sure andrew knows best.
It’s definitely not the clip length. I use 10-12minute 640×480 clips with no problem.
How about starting over completely from scratch..just to make sure its not another element in your patch. Do those video files ‘stutter’ when you try them in say..the qt.movie help file with no other patches open, or the jit.xfade help file?
What kind of fps are you getting? Is it a sudden fps drop that looks like a ‘stutter’? I might need a little more info on what the stutter looks like…im just really confused since we have the exact same setup and I don’t have that problem..what about upgrading to 5.1.7?
the ‘quicktime play engine’ is just a wrapper around the quicktime framework.
Thanks for sticking with me on this!
I tried your suggestions, opening a file in the jit.qt.movie help file with no other patches open, and I can see the stutter. It’s really only noticeable on my text roll animations. The fps I’m getting is right around 33 plus some variable amount after the decimal point. I’m wondering if it is the variable frame rate causing the stutter on the text rolls. They were animated to play smoothly at 29.97 (SMPTE time code speed). So I wonder if the non-standard fps is the problem. Is there anyway in Jitter to force a .mov file to play at 29.97? Or will it do this automatically at the default Rate of 1.? Just confused about the fps in Jitter. If the clip is playing at 33.2534 fps does that mean that it is playing faster than 29.97? Will the clip actually be shorter in terms of how much time it takes to play?
Maybe I’m just over thinking all of this and not in the smartest way. The jit.qt.movie object is simple to use in some ways but takes so many messages and has so many attributes that I find it hard to fully understand it.
It is sort of confusing, agreed! jit.qt.movie does not "guarantee’ a frame rate: the speed it reads the file from disc is independent from the speed it outputs frames. The speed jit.qt.movie outputs frames is NOT related to the frame rate of the video file: it is only the result of how many bangs per second it receives.
If you set the metro that bangs the jit.wt.movie to "100" you will get around 10 frames per second output. This is true if your video FILE has a frame rate of 29.97, or 24, or 15…or even if your file is a still image, like a .jpg, instead of a .mov.
Frames per second of the file is NOT EQUAL to the frames per second that jit.qt.movie outputs. It is entirely independent.
Each bang received is a request to output a frame. If it has a new frame available, it will out put it. If it doesn’t, it will output the same frame again. (This is the reason you may see an output frame rate that is higher than the frame rate of your file — you mention seeing 33.25 from a 29.97 file.)
If you want to "guarantee" an output rate, your best bet is to type "@unique 1" on the jit.qt.movie, and set the metro faster that your intended output frame rate (say, 20ms for 29.97fps). This insures that no duplicates will be output, and that there will almost definitely be a request for every new available frame from disc.
In MSP, it’s possible to guarantee timing: when MSP is ON, audio signals flow down the yellow-and-black patch cords at 44.1k samples per second, GUARANTEED. In Jitter, there are no guarantees. Video is heavy work, and there is no way to insure that other Max activities (effects, etc) won’t bog down the processor, or that system activities won’t cause the disc to spin etc.
all i want to say is, that the use of
the quicktime framework in jitter is not good.
you can make some simple tests on a mac:
open some fotojpeg movies (640×480, 30fps or bigger)inside
the quicktimeplayer and start them all.
on a modern machine all the movies will play fluently.
play the same movies with openframeworks (and mix them)
they will all play fluently
try the same with max/jitter using all tricks
(vades patch, opengl ….)
it will always stutter !
so it seems to be a problem of the jit.qt.movie object.
perhaps it is a bit outdated or overloaded with functions….
perhaps it would be a good idea to let the object as it is
and deliver a new one, which has not so many functions but
has its focus on playing movies fluently.
i think many jitter people would love to use this object.
for us it is a core functionality to play movies :-)
the c code to realize the object is opensource.
It is actually c++(you have similar wrappers in other toolkits like Cinder), but i do agree that the qt objects in jitter can be slightly inefficient when playing high resolution files. I am not sure if the stuttering is only related with the object itself or with the update of the Max graphic interface or something else. When compiled, Jitter objects need to be exposed to the patcher, maybe a bottleneck there?.
I agree with the previous two posts: C74 should make it a priority to test and improve performance of jit.qt.movie. It is not what it should be.
I understand that there are complex interactions between objects in Max/Jitter, threading issues, etc. But like they say, the first step to getting better is admitting there’s a problem. ;-)
With Syphon would it be possible to route a fluently-playing movie from Open Frameworks (for instance) into Jitter for processing?
thats a really smart idea !
so we could make a proof of concept for C74.
is it possible to "stream" multiple textures via Syphon ?
then we could make a kind of moviebank program in Open Frameworks, which
delivers smooth texture streams.
or we have to create one Open Frameworks application for each quicktime.
(with a settings.xml)
its a pity, that i am totally busy till april.
but i will definitly check this out !
just in case did you activate highquality ? jit.qt.movie @highquality 1
@Kurt FWIW, we’ve admitted this limitation for all the reasons you point out in various forum threads over the years. It’s not an easy solution for us to revisit the way QT interacts with Max without doing things like separating it into a separate process which introduces *many* other issues. However, we are investigating improvements for Max 6.
@jeanette_h + efe, for reasons, such as Kurt outlines, it’s not exactly a fair comparison with open frameworks, or cinder, where you are building a custom lightweight application. When you make something in these apps, you are not at the same time building a scheduler, low priority queue, a complete editing and patcher environment with competing with user events, and high priority events in the same way.
Sure, if one simply uses QT to play a movie to a window through CoreVideo, you get smooth playback. However, when you decouple the data from QT itself as jitter does it makes some of the timestamp synchronization and other issues with smoothness more difficult to preserve. Also note that CoreVideo (necessary for the time-stamping and synchronization to get smooth playback) and QTKit isn’t present on windows, that we maintain a cross platform code base and are integrating it into a complex, existing thread ecosystem of a large scale general purpose application. These make it a much more significant problem, and we balance this problem with other development priorities. Max/MSP/Jitter is not a dedicated video program, and cannot be fairly compared as such. It is a dynamic visual programming environment which has video capabilities as one of it’s many competing features.
I would say that a third party app which streams data from an out of process player is a great idea. I think it would be useful to a great number of people. Already, you can do this with QuartzComposer and jit.gl.syphon.
In the meantime, we’ll also investigate various improvements (note that in those threads the "next major version of Jitter" is actually Max 6).
Thank you for your feedback and understanding.
Just thought I’d chip in to say 2 things. First is while I don’t have access to ProRes, I find that the best codec to use is Apple Intermediate Codec. Although I’m sure this is irrelevant to the issue after reading the thread.
Secondly, whilst this talk of using qc/ofx and syphon to make a smooth stream sounds a great idea, I consistantly keep thinking it would be great to have a max object that was based upon mplayer. The main benefit of this would be the increased format support on Windows, but I always found that for single threaded CPU based decoding (my opinion has changed a bit since all this GPU based VDADecoder stuff came into quicktime), it is by far the fastest decoder.
Would there be a way of making an object that played mplayer directly to a named jitter texture (lets say ignoring if it’s being banged or not), that then could simply be read by using a jit.gl.texture object? Would that kind of thing fix the problem?
Just some random ideas I’ve been having that I thought I might share! Sorry if it’s a little off topic.
Quicktime codecs such as Pro Res and AIC (and many others) are multithreaded for the decompression sessions behind the scenes. So while Jitter may use one (or a few?) threads, Quicktime is managing its own decompression threads for the selected movie. This is not to say Quicktime is great (getting intimate with it makes me understand how amazingly not great it is as a *modern* sensible API), but I think part of the issue right now is just how Max/ Jitter work (push vs pull rendering for one), the timestaping issue JKC mentions, etc.
DigitalFX, even if you sent a texture directly to GL, or output a jit_gl_texture from an output port on this jit.mplayer object, you will still need to drive the main GL context rendering and have the scheduler, etc issues that are inherit to Max.
Yup that makes sense! But then that also means the idea of using ofx/QC and syphon would be no different right?
on the contrary, i am completely aware of the pros and cons of using jitter as a creative tool. Looking forward for Max6.
Joshua, thanks++ for the info and comments! Max 5 is a thing of beauty — looking forward to the even greater beauties of Max 6.
Please check your stats before posting
Firewire 800 is just short of 800 Mbit/s Which works out to 98 MB/s – thats MegaBytes Not MegaBits = big difference Original Firewire was ~ 100 Mbit/
DigitalFX, no, because the scheduler timing would not hinder the secondary background application that is doing the decoding, and timestamps are dealt with in this secondary playback app, ensuring that the texture is properly up to date (Core Video and Quicktime visual contexts also handle buffering the textures to ensure things are there as fast as possible). As long as you can reasonably get 60Hz for display, it should be ok.
I think, what actually would be amazingly helpful for jitter (and this is something I had pondered for a while), is something along the lines of a "DisplayLink" driven metro.
Core Video display link is a separate sort of timer and callback that is driven by the refresh rate of your display, and calls your rendering functions so they finish *just in time* for the screen refresh to draw. No faster, so its light on the CPU. It keeps a running average of how long your rendering takes, and then times the rendering function to happen before the display updates, then sleeps the appropriate amount of time.
Being able to drive a metro or qmetro like that so its 60Hz (qmetro 16.666666666667) but somehow smart enough to bang to sync with the display might make a decent amount of difference?
No idea if something like that is feasible, or maybe if Jitter already does it unknowingly, but it could not hurt? (or.. could it?)
Very curious about Max 6 :)
While we’re talking about this (on multiple threads), I thought I’d share another quick and dirty example that touches on many of the things that Vade’s examples demonstrate (for reference, his excellent patches are here http://abstrakt.vade.info/?p=147 ). The main additions relate to using a single, fast qmetro (of 1ms rather than 16ms). They also include some monitors to see where the timing is off, and provide some scheduler recommendations (see schedulerlab subpatch).
Anyway, in the meantime, these patches show how you can get pretty decent playback, before you start adding a bunch of UI objects and other issues that will cause timing issues. In such a case, it is recommended that you run your engine in a separate instance of the application and communicate to your performance patch over the network.
I was using James’ example movie file for testing:
Here are some recommendations from the patch:
1. use a *single* 1 ms qmetro to drive all of your jit.qt.movie objects.
2. make sure you use "@unique 1" for all jit.qt.movie objects (@adapt 1 and @colormode uyvy recommended)
3. disable overdrive if you are only doing jitter work. high priority scheduler work typically interfere’s with jitter. You may also want to set a small scheduler slop value in this case.
4. generate as *few* low/high priority events as possible–i.e. don’t use a lot of metronomes or line objects if you can avoid it.
5. use as few dynamically updating UI elements as possible
6. if possible, separate your video playback mechanism from your performance patch. communicate over the network with your playback engine running in two separate instances of the applciation (run your playback engine in the runtime version)
7. if you are using other jit.gl.* objects for mixing or otherwise, drive your render drawing and swapping from a single master movie’s output or following slab chain, rather than a separate metronome
And for this thread’s pertinence, here’s an adapted version of the originally posted patch (including Andrew Benson’s GPU optimizations)
----------begin_max5_patcher---------- 4439.3oc6cs0aiiik94T+J3Fz.CvtUxHdURyCKpt6s5clG5pGzUMy9vfEETr XRTWxRtjjSkzCl+6KIOT1RNR1zwRxJ.acw159ge7vy4vyEp+4at3xaxeTVdI 5Og9GnKt3e9lKtvrK8Ntvt8EWtL5wEoQklS6xE4KWJypt7svwpjOVY1exxU4 EUQYU+an0kRT08RT95pUqqP42hdJecAZY9CIRzsIopiTfJSitAs39njLTUNp 7aQqfypPlEKKRxtCsHOyb2sOozjL4h70YlGG2tyjXyCO+le6JQP8Ydq5ByhV JMG56KRhRadjxje2bDh20d1cmsdYRVprxzBw1ctpPVpZnQUI4YetPtnBPIJV ecHtOQ+km8Cz+61akpYWeupe.qhpVbupM079vBzWqfv0eQvlsvDr9doun+0a di9i2NrcKQnREYn5AtMprB80kxphbM9GWj7frQ2TYmnN84nN1aXQcmwu.lAv vgMfOe9KD89sjpqucU4cqSt74MQJ83ZhX707PNNv281IwtWXWUOsRBMxKu7s p+ug4pCXfG5aXiBLriBC+H8kBCYxuoZvOiGpBci5uxhHECTZW.j+nCPr9.na hxtSCR0eanxCiZAdvfOyW9XCOj2vhZZdp6RuFjmgpJRJUCCQuSMZ79bDoKXL 37wmUCetfZ9TXnGmMhvlQ8vFPynzXwhqW+zCOQJt6lnq+sGK6.BOVFQR2BiH GG3oH4OeW5m0Mg0EGl4KvGzfTK4WLFvXZdTLzo9bQ1CCH0MGFdubX6CVvTXz HMzaqnrWLrrTVVFcm7Y3RYU9pNvDwPJimbbHydQEeOpATBLbITCnnU1Mnfxh TYTQWnBalhJBA.GAFkeTwIgJ6SqWWfBeLG+PbRQ2d4XnFSAnTiVM5nHjNVlF 8j5tx85BfDioT3Wt.lZfwCLUJbL.ldYZ7m6LMfMP9CASyQJ6EerygX5D9BF7 Pg4ZLwBewX9bEVXzlvBaRk9Rl2CjDd.nPCNWRewySou0.iW3YP5q2bmogO9R e2NK8FHC26rvsbfIBvLRZCMfhRoM+DDuby5pp7rtZ4arscbmUCQXDVxLcsfS C0eNjr8+9xnUHO0ixG4cMAQutql6.Y0JeX6nAqNrZV87OIF+3FMkls7slid2 h7z7B3gqPJbnvKP691PFF6KL+xiGDPTzRaW51A+gTFmJac+77Ybrwavjc+Et WOD2KxcqZF7UaguaZS6gJ5k4adDB8yn4uZ9v1CpiA+O3GT+4fJsA2ISn+LTZ CQ.Fv.BcNQwMpdMEQ0US+Dctm1UXKhRMGS08O.Zm.Fr25jmYXF4VVjhONdlo HpRh9NbWXW3L0P3ZdGpmwCDL9nLAgNUbyDyugRLeCZXcJyHo2l4OI5soPbUn zyqZaVv7SsMyGrVkPFSs1++Jsag4fmHvzIWmMKb9IngFBQK25PuQRkM1i75U mMyGBqDWbVTYi8Blo5rs7ND3qQRkMwyqKeyv3ywYaCxwYXPgm+X3MOaPceHI VluJMJStMztQqqxWFUkrPoJ7clgKJYgTJU8o9euqpHJq717hkeVmONUnt31X ryh+czw8UQ5EIOdvX9J.CIDbvY.Duwv8WkxzNgGZ3YIr3NkSABHMnHvW9mHt rd4Mxt7kNCeVXPRxbSXcMH.YwzIJrteKmI8XS0VSeBzlTwAapTFZsiQP51mI cvZZSi87ZXIkf6EF3h0XuDS02wjpfsj9y90ALoxB5ACgE9U42cWprKLmNDyV QyG4PSACy+BBGt9ygT3xpB4JYVLZUTQzRTzRSNA97FLw+rjcI6WEGFLFhGD1 vH5W7.r9R0xenK3PLlvg29bMgkM.l3.gNJM4uuqlL8b0jwPqj5GN.M4dmjTm V1woyPK6vfMtVVfSbZR8gGchFj4HZv4CGZzqkF74skFJQgbvBT7.XpQehE9u yQeJuKQCrQOCW2qHQnsSg.KxFGQh+bxicxXP3m21NjfObqKSBGk19mzyUKQW vDnOkrrK6gHAmWTfDBy007U33v8urqLSlDdda3V2c.96fHFmoYQcHaBTMijk qW1jfGUencuteo8bF709K9sc9qcmtygExt6DRDp+X7w6y+0gBLKABylsSheZ xm50slTGzPsHJSQdp1orI.2rq65AtySQ602abSMhiaOZO9Sc.6Ss5a4Bi3W6 77GX+9rJZwW5pilLWCaZsQH13I6OJE.QRlD4g5LG4HCTVOQG3h4ZCv.gPcb. l+c8f2tbSHAe93W1IvY6ajDkrMepdwXSYZRb2losYPyllo2VAR4EI0kD5NZd FMOW.MZLjxNLv679CrEK5RcsDIUxpWI0UCJ3NKzsqSSKWTHkYnUoQOcSCwLs JKTRGw+I7b4D.H+R400nlWcFUNQ0nV90Y4EKiR0EnF5cMcVlZXWWNHzAQQMT Fgg5MNv31UiWWs+podnSbP5PUma1xEjay02vQIWnWgd+iUxhrnTzOmmkTk2Y pzGLCcJIHASPsE9MYK5z7hjEVLwBJJBUwm8frnrsLnKtb6s1VUqLnL57f46K 1dm0F3jlu3Kx3FClt3xX4sGy8HekLa6460rZ3aUR7vYlj0rd5284FsNs5yc2 Cz932FsP16E2YG6EWdWQRbdllHZck5cW+3TcGPff4MoayYjEspiKtJOO8lnh GRJStIU1pePwFGorSNpRVkrzVy6attjkqJR.ola1mLKRcOtWIoMOMs0sBNxC cbjX4CIKjeKIt59VliuyB5PC9lVCvZs+8pjn8nseLMYwWzZHVl+.rFOnEE9s jr37ugTizTrC+gRjcashD0YPxhQwIkZMHMumcoAouJU84Cc+w70JUwE6d7NX e5aPb+pU5W0heCelASOitQb1E0hzfe71WH52RLWOQfIu7xtwKxzhWMOR+B+1 i63.8BFIeAAsy6fABNa6051342gQeGoGjjNFHIYjQRZyrPULcLlMy6fmYeyz Bjj8AjOKgD50xEv3Q6jw3iBm4dvy+ydQS9LhsrYPoO.PZsBGO4Cwwh.Ojm5I S7PgaBb2yJOrWUC1AvDC4.JFxZqobzdsZnRYUO3o+qJ0PV7DXUGI0P6ANKTj rr2A7ASKTtWwmNI5zpKBSfTYJbbfylAfXWHKbffrNcd8KELew9r18HQbBdt9 .hug9RJ+7LzvLIA0m4Ew8Y2K1aZGlPO3vjivJCOqNRwjqcDvzdk8fwulzKVu ZTAKdPhQQq39Ay0Y8oPDSd8gjb94YxDZGJXcWPI5clb9dYdb+ZHwG0T0NRWo NKrPA5O7spRGGMp6yoOe5dIH9MIKpRVtY87T6Xmks74p6N1gMu7ri0FvPPrA vzO3t1YeX7+i7OTHQ4YoOgT51kJ19JYLRu1nduNhLqtJUdak1yOlrqoW3l1C bymWvM3VYh0TQvC3LxzIi4A4iqJPeWBF8erM.wOCzDuF8lFDrEaTvlTwDeeb rdU6k6gVk7nLsT6+2nGxShQQYOgTW15ahJJutWdWVOcC9yJdWq2eE1UrBHBW rAFlMzYerkslRXqFk2X6HG5lfjrSnR.Uq.uglPub.ACfd6CMBub3EOACkn3S o0tMJRZl7dBHi4gqOd2vPoh+dQcujcpsn1jQrRQgVsrMlZ+iMtIbmy69j331 gvBRnq3U4pteK44HO7wR0ANR09uJoZ5rhp8cjpEyJpl6HUylUTMyQpVOO5YD YSckrmW7HDWI6vYEYicUNBlLunagiz8Lircl61adQ2NydOuz2zgrsgktETcc ZQHrsKNAs1.hQKbVae8OL7sSOGamyLoOZxF6.YGLfjscmJ52lHsQOHi+LjcP eNpppH4l0UfIwsxqs9yfqCkgX2kleSTpMe41bO1b4cl3XCc1l8lsnv.UYkMR +1NWiU7mgqld7lI03tAScnJp9.wTTT8PSgCMBaESIF9ErCRWqtaA9y2UrCKt vIiWAs7E4ScAJCTV75cbugYrwZ84e4.HAKwlrSqNN5ebP3TLNvlFTBAT5fa9 bXWZ3eJaQ2R4BwyvZI2BIP7B3i1RlTchzVWhA51HRv7zKGbn2EKWUc+Mqu8V YQm.24ckR2ggG90UipXbdcCHqPcU8W3Y3Z0P.7VkiZeauLJbTFOs2YQOgYi4 pL4gjrV++CIHJ.CfCT759zw5sO0WqtFdUE9tn3nUUJ6me2C4o5kmr0YIecsT uCSbjMwkV+Jox4phhO2WmxruapXVg81HgxFmkRnBYTbWbih4W05D362XgCH3 zr5YsNXXc0vcvpO8xk2p7UqSipZUa1GCfjTIWZm.2kdDzm90+xUe7Se+GP+x e88e3pOUjb0G0Za9oDcQU8WKx+U4uqGPn4cdq9COF5uGk800Ik2e0OHuMuPh 9Qccpf9f7aHOhK2AA5iIkkRI5mkEeIICQ9L1kKK.8ipgbZdmHIxoGTPjCWxU q9sUx6ZcgXOzeKsxTEOneUVrNyIBDSPuOK9okp4V6xYyP+J58K9RNRgDk0Hh aPAVnZWYkqWtzLSdWth.zeNRmIc+jpC6AYgS3GwCNlbOmaOqQtzsuFUuM4QP gbRp5AWUjmkrH5O8GU2R8c78OHy9iW5hNhMOI8w23Ah8ov.VrSf2Ml3wYtJm z6qPwqg2Wg7A88U3wZsFaN5jC6KiufygwZzWC1pUCQvhrzqQa0Bl6lpYGVZW YvI1ku2o0Tsv4mkZ1pNmAK+eikkZjyfkZXzeIKNQod4Oq5Lby7GJ5S+czGuO +a5hiuRI1ciAWtb0bzGdZ4p6kUIUqiOtK02XdRdQk8pb4ZBUWi19f1lsfU2A UqVmNj+RQzhTY4Ue7Ce3mRd7J3d7w+q1mOE8CxnE26lUTbkUWY2o9mKmrO5u koeWv6zcNDkmoeY2qOdjheZDMf5WhiGG6m3Xdi28rmr8S8tpgwNyKy9uhVhv fWTbvryoijako7IYMK1aaKYbVNz+5RoZnR2qH5hy2RcjCuM.MKNgPDD51Xay k2NyBAfZ2.DagqmmDPsR4p9RssV4.xyiHb2QC9YcdNSSLWoI7zQSBGnofiCl DglTZ.VER49a2ZJnUL+EQrA95uB72t0oRr5LUjd.hkwlTFPlmKLf9S6fBeWn ofomlHCLMIHrqwJkfJYrHAHBTudsysaMDjL9PjLcRgwPrCcsgjiilvALSpPA 0rqB4p23TI1gWN3IRQAtPR6fwiNME3BLMsRPBbQBRvzppOvEUU99yOZBerR0 LC.EjMqCJ0achDqu+HH63DoIgKzjXZYzDtzoJ3SKM4hs2B1zSSGR+nXZ0OJX yNcN6f.yBRh3hXKLe5IJ7AIJuoknbwdKwDKyzkobHvSOMcPakmTRhGNBSsES 7MkM.Ex+rP6aGjVaw.GvXm3qYqSso3hIh6zdObSgxwMbpPcKaH7p.2eDn2Ig lBdYrC001cMjN.y9j6hUH7oUDMmOBX3oRStnwm6OCoIuilWCd+SYeGZSgkty c1LztEyH7Ijb57gtX9BeZ01vIyPZxEKEnSqkBbWrTfOsytxEQHroUDByIKE7 lkD0QxPw7LNkmTWIN7MacpjavXPtmJQ4hNeV3LjlDGa2pvnZ.yfZGBrFo0VA vFAF6UBNcuIwbx9joEZcJ.kGqZWJ0XSGCdQagI7sadpzqKpVYSqZLlKpVYS6 L4XNoZchGF6BIMsQXKzE2w4O8zzAcUg27Cm3GYemuW.DkaXMTiXUyp2bJfP9 QpWUv8aRtXAaPI2C5Euo0Q0TWjoQlXtPOWmtvDl3JtXB2zZAGwottoUEIwI0 QSLM4B6DYZ66vAiQtJXiGJjpahsabpDqKI6AdZmpLdLRNqSklbwvG7zZkA1I AWSqNGrKQyZZMYc2.5MO3mvdyPhxKX3iYq00KLAoQNbZ15joVxX3+pZmCAuW YqcbTf+oSutLCyosC2kt6IV1uKiUmVwrN43JuI0hUgqjzDZIl+HPSXLLXTPL l8DBKU2s2hCgc1l.r7AHryTWFoRNElP0F+q27+YQVLFF -----------end_max5_patcher-----------
And as far as codecs go, some quick anecdotal info that may be of interest: I just ran some tests of this clock animation converted to 1080/30p in the following codecs, and tested with the jit.qt.movie-smoothtest patches:
Apple Intermediate Codec
Apple ProRes 422
Apple ProRes 422 (LT)
Apple ProRes 422 (HQ)
Apple ProRes 444 with Alpha
The ProRes codec variants clearly offered the most stable timing with the lowest bandwidth (LT) to the highest bandwidth (4444) respectively. Photo JPEG and AIC didn’t perform that well and H.264 was even worse. So for those of you doing HD work, I would highly recommend using the ProRes codecs if possible. With these simple patches I was able to get smooth playback with two 1080/30p sources on a latest generation MacBookPro.
There is still a stall at the loop points when using these HD versions, which wasn’t present with the SD version. This is not avoidable by using loadram, either, though slightly improved. However, QT Player exhibits the same issues trying to loop an HD movie, FWIW.
Anyway, posting here in case of use to anyone in their attempts to get optimal HD playback.
@Joshua, could you please make a sticky out of the two posts above?
I second that jonathanb.
This is an incredibly useful and informative thread.
also a very important setting for better movie playback on multiple gpus is:
cut 1 pixel of the left side of your jit.window (using the rect message)
i have 30% better framerates playing movies on my system.
mac pro 4,1, mac os 10.6.4
this is a bug, which exists till snow leopard came out.
since 1,5 years ther is no bugfix from cycling74 :-(
hopefully it will be fixed at max6.
This has been a great thread!
I thought I’d throw in my $0.02 wrt codecs and smooth video playback. I too have found apple prores to be quiet good for HD playback. But here are some interesting (?) observations (all of which are kind of expected, but sharing nonetheless):
1. Baseline: patch loads, takes ~7% of the CPU (as is usually the case). no video processing yet.
2. turn on rendering (but no files loaded into jit.qt.movie yet): no change in CPU
3. load one 720p movie (apple ProRes 4444), CPU jumps to 26%. autostart = 0, no bang reaching the jit.qt.movie object.
4. send a "start" message, CPU to 50%. Still no bang reaching jit.qt.movie. Shark reports that 44% of Max’s resources is in dealing with the apple ProRes codec.
5. start the image chain (i.e. allow the bang to pass thru the jit.qt.movie), 67%.
6. load the movie into RAM, CPU = 90%
(consistently throughout I’m getting 60fps, which is great, and smooth playback)
Now for my particular project, I’m actually loading 4 HD streams & compositing into 3840 x 720 window (three tiled background movies, one foreground with an alpha channel that moves across the entire window).
7. 4 HD movies reading from the hard drive, ~135%. Still 60fps. Shark reports that 85% of max’s resources is dealing with decoding pro res.
8. If I load everything into RAM, my disk activity drops to 0, but CPU is around 200%. Still 60fps.
9. Repeat step 7 with photo jpeg (med) HD files (ignoring the fact that I can’t have an alpha channel on the foreground image), CPU @ 70%, 60fps. However vs. ProRes, photo jpeg adds quite a few artifacts that show up quite easily in the content I’m using.
One thing I did notice was that you have to send a "stop" message to jit.qt.movie objects even when you stop the bangs to the jit.qt.movie objects if your goal is to recoup some CPU cycles for other tasks (otherwise stays above 100%, mostly for pro res decoding).
I also notice I get a lot of crashes after loading the HD files into RAM. I suspect it’s Max running out of memory, however the usual "memoryheap" issues don’t show up in the crash log. Using an SSD drive takes care of the need to load into RAM.
Anyway, may or may not be useful…just thought I’d share.
BTW: this is on a recent MBP, 10.6.5, Max 5.1.7.
Quicktime movies task when not being banged (the file is still being read, and decoded if you told it to play, etc), so even if you stop the metro, you need to give an explicit stop method to jit.qt.movie, less you want disk access and CPU to be used in the background with no real visible indication.
Good to know! I don’t think I would have ever noticed it had I not switched to a more CPU-intesive codec!
I learned that pretty quickly on older machines it was hard not to notice even on 320×240 back in the day, when we played visuals uphill (both ways). You youngen’s with your 12 cores and gigahertz…. complaining about the lack of smooth playback.
But honestly, I don’t recall if that was ever mentioned in the documentation. It certainly is … not intuitive compared to other matrix based objects that only process when banged. Something good to know, especially if you juggle between generative and playback, ensuring you get the full CPU and thus FPS when not actively using your jit.qt.movies.
Similarly related to that vade, do you know the answer to this post I made a few months ago? http://cycling74.com/forums/topic.php?id=27810
Thanks for posting the patch with optimizations. However, for some reason I can’t seem to get your patch to output video. Am I doing something wrong or is their a bug in the patch?
If I change the attribute in the jit.gl.videoplane object from @automatic 0 to @automatic 1 than the patch works. Is there a benefit to setting that attribute to @automatic 0? And if so what is the benefit and how can I get the patch to output video to the jit.window with the setting at @automatic 0?
Your fix for this was appropriate. Oversight on my part. Sorry for the confusion.
The patch (including Andrew Benson’s GPU optimizations) still produces an error for me, even after making the @automatic 1 changes recommended by avlodge.
When I click the center button which triggers the fade to the second video instance, once it reaches 100 and completes the fade the video stops playing, unless I send a bang from the left-most button, which isn’t clear to me b/c I believe this controls rate for the first video instance.
am I missing something here ?
is it because the rendering context changes to something other than ‘tristan’ when you press the middle button which initiates the crossfade ?
Ah! I was being thrown-off by the @unique 1 attribute, which waits for a bang before it sends out new frames. What I don’t understand in this patch [the originally posted patch (including Andrew Benson's GPU optimizations)] is why is it when the crossfade bar is used independently of the button, it works smoothly, but when the button is used, only the video instance on the right (B) gets stuck and fails to update?
If, from this (stuck) position, we click on the middle button again to take us back to the first jit.qt.movie instance on the left (A), it starts to play and works as it should. Must be some kind of bug that I’m not catching?
Maybe I think for Max 6 it will be very interesting to use VLC in the place of Quicktime here a link : http://www.videolan.org/
another project seems to be very interesting vlmc: http://trac.videolan.org/vlmc/
Nota you can make lot of sound on Max, but you only read them with Vlc not with Itunes or Qt. it a same for movies
Hello jitter professionals,
I am also trying to play back videos smoothly without
I tryed all the patches from Joshua posted here with the clock_spin.mov.
(which is smal one)
I also used different codecs an played with the
scheduler and queue settings of max.
All the changes had no effect. The movie does not play fluently.
The problem seems to be somewhere else.
At the quicktime player, there is no problem playing the clip.
Does someone has an additional hint for me ?
@Joshua: Does the next version of max fix this issue ?
My system is a:
MacBookPro8,2, Intel Core i7, 4 cores with 2,2 GHz
Running: Mac OS X 10.6.8
should be fast enough to play this movie :-)
I have seen the one japanese artist can use HD1920 and output with HD projectors, his work and everthing so smooth no stutter,i think… maybe he combine all clips that he want to use in one file and he message the range of time that he want to use ( load for1time and use many clips many times ) this is my idea im not sure,his name is Ryoichi Kurokawa and the good example for how can he use HD is "RHEO"
Just wondering if there were any improvements relating to quicktime playback in Max 6?
Anything new we should know about?
if you are on a mac, 10.6 or later, there’s this:
It would be great, if we would have a better method to play out our quicktime files.
The jit.qt.movie object seems to be a bit old fashioned, we are waiting since years for an update ….
Its definitly a dealbreaker, that we can not play a single HD movie smoothly with jitter.
Yes, i tryed vades patches, all codes and all tips in this forum ….
btw, jit.BC.QTKit does not work well.
Sad to say I’m having problems with jit.BC.QTKit as well and not sure I’d be able to get in there and sort it out with my meagre coding skills.
I should’ve said, I was trying to use this in Max for Live, possibly a bit ambitious.
Seemed to work fine in Max, not that I gave it any serious testing.
this is a great thread! thankyou to all involved…