For those settings (glitchy interface wouldn't let me radio button multipass) set to allow streaming (under the streaming tab), a 7:39 iMovie project took 40 minutes on a 1.5 GHz AlPB 1.2 GB RAM.
It did something funky with the audio, though. The movie is 7:39, and same for the audio track, but it didn't combine them properly, and the audio didn't play at all. The video wasn't deinterlaced or something either, and had these horizontal lines throughout. Previewing the iMovie is pretty much impossible it's so choppy.
Looks like High Def is in there, but still lots to work on, it seems.
Thats awesome wow, thanks. We are looking into MPEG 4 AVC streaming servers that have to convert raw source t o512/1mbit AVC streams. Some source may even be 4-8 mbit mpeg2 transcoding.
Looks like you have aboatload of options!!
You should report to Quicktime team all the problems you have. I know some people there and they are working like mad on AVC in Quicktime and any input is welcome.
Read it before and that didn't give me a lot of information except that it is a framework that helps developers with creating and managing database backends for their applications.
Here's a question though: Can the data that is stored in a application's CoreData database be indexed by SpotLight?
Can the data that is stored in a application's CoreData database be indexed by SpotLight?
Based on information from Working with Spolight I don't see how that would work since Spotlight and its importers are file oriented. What types of Core Data objects would Spotlight index and what would be the results of queries, assuming an importer could be written for it? Maybe you'll locate database files more efficiently with Spotlight but it won't help make any useful interpretation of the content.
Read it before and that didn't give me a lot of information except that it is a framework that helps developers with creating and managing database backends for their applications.
Here's a question though: Can the data that is stored in a application's CoreData database be indexed by SpotLight?
Yes, but from what I can gather I presume you'll have to write a metadata importer for that kind of database.
CoreData is essentially an Apple-provided API for working with databases, be they XML or SQL or anything yet to come. You write one program and it should with a nearly zero effort work with any back-end supported by Apple. SQL support is not too shabby, to start with.
Read it before and that didn't give me a lot of information except that it is a framework that helps developers with creating and managing database backends for their applications.
That is what I thought at first.
It looks like the database part of Core Data is the least interesting part. What is cool about Core Data is most likely not going to be visible to end users directly. A developer using Core Data will be able to just describe the data in his application that needs to be saved and let CD take care of the details. In many ways it is very similar to the tradeoff developers made when moving to the original Mac and it's Toolbox.
Before the Mac, everyone wrote their UIs from scratch. The positive side of that was you had the flexibility to do what you wanted as a developer in building a custom UI tailored to your particular application. The negative was that there was a tremendous duplication of effort by developers reinventing / re-implementing all the low level details over and over again.
The winning tradeoff developers made when they moved to the Mac was in sacrificing some freedom to gain a significant amount of functionality for free from Apple. Core Data is the next step in that process of consolidating the common elements of applications into ready to use packages that allow developers to focus their efforts on the unique features of the application.
I've seen people complain about how OS X applications are constantly requiring the latest OS version which forces users to pay for upgrades they don't feel the need for. From a developers perspective things like Core Data, and Bindings in 10.3, enable you to rip out large sections of your code and replace it with something simpler and most likely with more features. Users running older OS versions require the developer to maintain the new small and simple code and all the old messy code. It's just to tempting to just rip out all the old code and require users to have the latest version.
Users running older OS versions require the developer to maintain the new small and simple code and all the old messy code. It's just too tempting to just rip out all the old code and require users to have the latest version.
Not only tempting. We should not forget that supporting 2 versions of one product based on 2 different APIs/technologies/platforms is likely to be substantially more costly. On the other hand, almost nobody runs 10.0 these days, even though many of us complained about backward compatibility when 10.1 was released. This is progress, and it doesn't care if we like it or not.
Comments
Originally posted by MasonMcD
http://www.masonmcd.net/export.png
http://www.masonmcd.net/exportimage.png
http://www.masonmcd.net/properties.png
For those settings (glitchy interface wouldn't let me radio button multipass) set to allow streaming (under the streaming tab), a 7:39 iMovie project took 40 minutes on a 1.5 GHz AlPB 1.2 GB RAM.
It did something funky with the audio, though. The movie is 7:39, and same for the audio track, but it didn't combine them properly, and the audio didn't play at all. The video wasn't deinterlaced or something either, and had these horizontal lines throughout. Previewing the iMovie is pretty much impossible it's so choppy.
Looks like High Def is in there, but still lots to work on, it seems.
Thats awesome wow, thanks. We are looking into MPEG 4 AVC streaming servers that have to convert raw source t o512/1mbit AVC streams. Some source may even be 4-8 mbit mpeg2 transcoding.
Looks like you have aboatload of options!!
You should report to Quicktime team all the problems you have. I know some people there and they are working like mad on AVC in Quicktime and any input is welcome.
Thanks again
Originally posted by MPMoriarty
I am confused about a lot of the details on CoreData. Could you go into any details about what advantages it offers?
Mac OS X v10.4 Tiger: Developer Overview
Originally posted by sjk
Mac OS X v10.4 Tiger: Developer Overview
Read it before and that didn't give me a lot of information except that it is a framework that helps developers with creating and managing database backends for their applications.
Here's a question though: Can the data that is stored in a application's CoreData database be indexed by SpotLight?
Originally posted by MPMoriarty
Can the data that is stored in a application's CoreData database be indexed by SpotLight?
Based on information from Working with Spolight I don't see how that would work since Spotlight and its importers are file oriented. What types of Core Data objects would Spotlight index and what would be the results of queries, assuming an importer could be written for it? Maybe you'll locate database files more efficiently with Spotlight but it won't help make any useful interpretation of the content.
Originally posted by MPMoriarty
Read it before and that didn't give me a lot of information except that it is a framework that helps developers with creating and managing database backends for their applications.
Here's a question though: Can the data that is stored in a application's CoreData database be indexed by SpotLight?
Yes, but from what I can gather I presume you'll have to write a metadata importer for that kind of database.
CoreData is essentially an Apple-provided API for working with databases, be they XML or SQL or anything yet to come. You write one program and it should with a nearly zero effort work with any back-end supported by Apple. SQL support is not too shabby, to start with.
Originally posted by MPMoriarty
Read it before and that didn't give me a lot of information except that it is a framework that helps developers with creating and managing database backends for their applications.
That is what I thought at first.
It looks like the database part of Core Data is the least interesting part. What is cool about Core Data is most likely not going to be visible to end users directly. A developer using Core Data will be able to just describe the data in his application that needs to be saved and let CD take care of the details. In many ways it is very similar to the tradeoff developers made when moving to the original Mac and it's Toolbox.
Before the Mac, everyone wrote their UIs from scratch. The positive side of that was you had the flexibility to do what you wanted as a developer in building a custom UI tailored to your particular application. The negative was that there was a tremendous duplication of effort by developers reinventing / re-implementing all the low level details over and over again.
The winning tradeoff developers made when they moved to the Mac was in sacrificing some freedom to gain a significant amount of functionality for free from Apple. Core Data is the next step in that process of consolidating the common elements of applications into ready to use packages that allow developers to focus their efforts on the unique features of the application.
I've seen people complain about how OS X applications are constantly requiring the latest OS version which forces users to pay for upgrades they don't feel the need for. From a developers perspective things like Core Data, and Bindings in 10.3, enable you to rip out large sections of your code and replace it with something simpler and most likely with more features. Users running older OS versions require the developer to maintain the new small and simple code and all the old messy code. It's just to tempting to just rip out all the old code and require users to have the latest version.
Originally posted by Tuttle
Users running older OS versions require the developer to maintain the new small and simple code and all the old messy code. It's just too tempting to just rip out all the old code and require users to have the latest version.
Not only tempting. We should not forget that supporting 2 versions of one product based on 2 different APIs/technologies/platforms is likely to be substantially more costly. On the other hand, almost nobody runs 10.0 these days, even though many of us complained about backward compatibility when 10.1 was released. This is progress, and it doesn't care if we like it or not.