Hi, > Isn't the simple solution to just not change the encoding profiles? > We opt for multiple encoding processes to run concurrently rather > than supporting multithreading in a single encoding job. We can > stick with that approach.
Can we? I don't know if ffmpeg tries to detect the threading environment automatically like we do. And what about the recently added multithreading decoding (ffmpeg-mt)? Does this compound problems? What revision of ffmpeg is being proposed here? And does a "production system" mean its been tested against gstreamer mpeg2 encoding, or is Osna using hauppage and skipping software encoding completely? There are so many variables with ffmpeg updates that I see a huge assurance effort here and, that that vision is not shared, dismays me a bit. I want a release that I have confidence works more than I want these new features. > With all of this said, we are planning on cutting 1.2 in about a > week. I'm fine waiting until that release branch is cut, so the new > features are released as part of 1.3. I would change my vote to a -0 if it were after 1.2 - I still think the qa effort is being minimalized to our detriment, but if someone else is responsible for release managing that and trying to herd cats to deal with problems then I won't stand in the way. Chris -- Christopher Brooks, BSc, MSc ARIES Laboratory, University of Saskatchewan Web: http://www.cs.usask.ca/~cab938 Phone: 1.306.966.1442 Mail: Advanced Research in Intelligent Educational Systems Laboratory Department of Computer Science University of Saskatchewan 176 Thorvaldson Building 110 Science Place Saskatoon, SK S7N 5C9 _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
