H.263 avi encoding - possible?

I have a need to create a h.263 encoded AVI video file... (For a video IVR platform). I purchased Quicktime Pro, hoping it would be able to create these files for me, but it's not as obvious as I hoped.
I see I can create an h.263 encoded .mov file, but I need this to be in a .avi container. When I select .avi file, I only get 5 or 6 different encoders I can use, and h.263 isn't one of them.
The g3 format or whatever has h.263 support, but again that's not .avi ..
I looked at ffmpegx too, but again - not too obvious.
Can anyone help??? Thanks
24" iMac Mac OS X (10.4.9)

It's 2007 and even Microsoft dumped the AVI container years ago.
Ask them first why they need AVI and then explain your export options.
They seem to be locked into the early 90's.

Similar Messages

Create Disc - Burn a Blu-Ray (or any disc) without re-encoding possible?

In short, I burned my first Blu-Ray recently using the compressor template job action. I noticed it used an app called Create Disc, but I also noticed that I have to re-encode my file every time I want to burn a new disc (after quitting compressor).
Is there anyway to burn a disc without re-encoding? I don't have Toast 10, but I do have a blu-ray burner in my Mac Pro. While we're at it, has anyone found an opensource app that can playback blu-ray discs?

Hi,
if you already have your h264 and ac3 encode files, you can try running Create disk and follow what Brian suggested to you in the other post.
What I suggested you is the way you can organize your data to burn multiple copies with your Blu ray burner.
But this is done going through the entire process in compressor, where you select your HDD as destination device so that you will end up having an IMG file to be burnt with Disk Utility (multiple times).
If by content saved to your HDD you refer only to those 2 files (h264 and ac3), then copying them to your BD won't work, as you need to author the disk properly, and that's what Create disk does when it either creates a BD directly or an image file.
Creating a Blu Ray is similar to creating a DVD: there is a specific format authored that you can't just copy files in there if you want to play that media using a DVD/Blu ray player.
Regards,
Armando.

Is ANSI ENCODING possible using file/j2see adapter

Hi all,
I am doing a file to file bypass scenario .My client has demanded that the output file should be in ANSI format.I checked the <b>file.encoding</b> option in sap-help but ANSI is not available can u suggest that what encoding type i must use.
I am thinking of using ISO-8859-1.
Regards
Saurabh

ANSI characters not present in ISO-8859-1
http://www.alanwood.net/demos/charsetdiffs.html#a
http://www.alanwood.net/demos/ansi.html
This link may help...
https://www.sdn.sap.com/irj/sdn?rid=/webcontent/uuid/40943d04-0b01-0010-fbae-c023e996d1b6 [original link is broken]

Is AVI Assembling possible with Final Cut Pro?

Hi everyone,
Please forgive my ignorance...I'm a complete newbee regarding Final Cut Pro's capabilities. I'm trying to find software that can assemble multiple AVI, OGM and MKV Video files. I'd like to be able to cut each video file into chapters and edit a menu as to fill a DVD disc to the max of 4.7 GB and then burn it all on a DVD disc...PS: I have used iDVD 1/2 successfully as it does the trick but it has a 2hr video limit. I'm trying to fill up the DVD disc to 4.7GB of video to watch on a standalone DVD player. Suggestions anyone?
Rio.
2x2.66GHz Dual-Core Intel Xeon Mac Pro Mac OS X (10.4.8) 1GB RAM
2x2.66GHz Dual-Core Intel Xeon Mac Pro Mac OS X (10.4.8) 1GB RAM

You are confusing time and size in consideration of DVD content. They are connected in a complicated way. You may want to spend some time with your DVDSP manual to get your head around the concept of Bitrate.
That being said, AVI can be read/imported into FCP using Flip4mac's WMV studio plug-in. The other two, OMG and MKV are far from standard formats. If DVDSP can convert them to MPEG2 you are good to go. If it can not, you need to find a translator that can convert them to a more mainstream (aka Quicktime) format.
Good luck.
x

Share/export without any re-encoding, possible?

let's say you create a new MPEG4 iMovie project, and drag some DV files of a consisent size and quality into it; they get encoded to mpeg4 during the import. Now say you want to export your movie-- shouldn't there be a setting to simply "copy" the frames rather than re-encode everything? Not only does it take forever and it's redundant, but you loose quality doing so.
I know if you want to resize the clip, or do anything to it, it would HAVE to re-encode it-- but shouldn't there be an option to just use the clips "raw"? Of course, the clips would have be completely consistent, which would be the case if they were DV off of the same camera...
Thanks!

??? me confused...
I still don't understand your workflow, sorry:
iMovie is a consumer video edit app meant to work with firewire connected miniDV/D8 camcorders
no word about "convert it into a playback format first, then create a project in a third codec... " etc...
iM≥5 allows projects in mainly TWO codecs: DV (as on miniDV tapes, bit-identical tape=>Mac, no loss of quality), and mpeg4 (mainly for iSight recordings, low quality, as from some still-cams aible to do "movin' images"..) iM is a consumer app, made for simplicity & convenience, no all-purpose app. stay within concept of app => no fuzz (here...).
2nd)
mpeg4... a file with a mp4 suffix can contain MANY different codecs: plain mpeg4, but also h264.. or divx... or... iM allows in its Expert Settings to choose, WHICH mp4 should be created...
mpeg4 ≠ mpeg4 !!
ALL that codecs are NOT intended as processing files, they are PLAYBACK codecs..
so, it is absolutly useless + lossy (=losing pic quality), to handle any h264 coded material; if you have dv, stay dv.
and: h264 needs an awful lot of encoding power => tiiiiiiiime. if you choose "mpeg4" as project format, and choose h264 as export format, that needs computation, lots of computations.. and creates apparently from mp4 to mp4, as said above
finally:
all that "compressing" does NOT save any diskspace; these processes need an awful lot of diskspace to generate the files... video needs harddrive space - no workaround.

Exporting in the best AVI format possible. help

So I need to export my project in AVI format. Ive already done it once and it looks really bad, quality seems to be low even if I put it on best. Everything was turned up. Dont really know what im doing wrong. The footage was shot in HD 10-bit NTSC 720x486 4:3
Can anyone walk me threw what they do when they want to export at the best AVI quality??

JustADude21 wrote:
The client wants AVI format. I told them QT is better and more used. They also want a mpeg format.
Dimensions: 720x486
You can ask what clients want and you can explain why you can't do it for them but it's impolitic to tell them they don't know what they want. There is nothing better about QT nor is it used more. AVI persists in spite of the fact it has been dead for more than 15 years.
MPEG? 1, 2, 3, or 4? You must find out.
Your video dimensions indicate standard definition DV. The AVI export out of FCP or Compressor is lovely on my systems which suggests you may be viewing it improperly.
bogiesan

Flash Media Encoder .f4v file larger than .avi after conversion

This is my first time using Flash Media Encoder.
I converted a 168 MB .AVI video to .F4V and the resultant file is 302 MB.
Is this normal?
What could I have done wrong?

I'm not familiar with CamStudio's compression settings, but it sounds to me like the bitrate of the AVI is lower than your target bitrate for the new encoding. If that's the case, it makes sense that the new file is larger.
It would be better to start out with a high quality AVI if possible. Remember that you're compressing again when you transcode the file, so in order to maintain the quality of the source, you have no choice but to encode at a very high bitrate. If you start out with a high quality source, you can reduce the bitrate when encoding the flv/f4v

How do i encode a HUGE movie to fit on a website?

I have a film shot by my client that is 58Mb (about 720px wide) , and I need to resize it and encode it so that it is downloadable in several formats (wmv, avi, mov) on the client's website. I will probably also have an embedded version, but that depends how the user testing goes.
What settings in QT 7.5 should I use to get good quality but as small as possible files? What is considered a user friendly size, under 5Mb?
If it helps, the movie is an interview, so speech can be 22KHz, and there is little or no fast action.

The movie is about 4:45 minutes long. I have 13 of them as well, all roughly the same length.
If that is 4 minutes and 45 seconds, it sounds like they are already the equivalent of an H.264/AAC iPod encode. While you can transcode them to any of the afore mentioned file formats using a combined video + audio data rate in the 1600-1700 Kbps range, further dropping the data rate without decreasing the display size would likely impact poorly on the quality. If you plan to keep the display size and some loss in visual and audio quality is to be allowed you might try dropping the video data rate to about 1000 Kbps and encode the audio as mono at 32 Kbps/32.0 KHz or 64 Kbps/44.1 or 48.0 KHz.
Encoding to WMV 9 would require the Flip4Mac "Studio" encode/decode package ($49). Visual Hub ($23+) will do an older WMV encode and an AVI encode (don't know what audio/video codecs are used here). Since AVI is basically a generic file container that Microsoft stopped supporting officially about a decade ago, many codec combinations are possible and your source would depend on which one/ones you wished to specifically use and is somewhat dependent on both platform and operating system. As to MOV files, this is the QT generic file container and any compression combination (including WMV and AVI files) can be stored in the MOV container using the QT Pro or MPEG Streamclip "Save As..." File menu option.

Help: encoder not recognizing audio in mpg

i have to convery a number of mpgs into flvs using flash's
video encoder. the mpgs have audio, however when i bring them into
the encoder, click on settings, and then click on the audio tab,
it's all grayed out like it's not recognizing it has audio.
anybody encounter this problem as well?
thanks!

Hi liscola,
I'm having similar issues with Flash's video encoder although
I have an MPEG file with audio that I'm converting to an FLV. I've
been using the 'Flash 8 - High Quality' setting. It starts encoding
the file but then give me the following error;
2008-04-18 13:13:34 : ENCODING FAILED
- Source file: SourceFile.mpg
- Output file: ConvertedFile.flv
- Video codec: On2 VP6
- Alpha channel encoded: no
- Deinterlace: no
- Frame rate: 0 fps
- Key frame interval: 0 frames
- Video data rate: 700 kbps
- Width: 0 pixels
- Height: 0 pixels
- Audio codec: MPEG Layer III (MP3)
- Audio data rate: 128 kbps (stereo)
- FLV duration: 00:00:00
- Encoding time: 00:02:01
====================================================================
An internal application error occurred.
====================================================================
I have looked into this and there are other posts indicating
that the encoder possibly can't format MPEGS with sound thats over
44kbps. Other people have suggested to convert the MPEG to AVI and
then to FLV but when I tried that is just reduced the quality of
the video.
If there's anyone that can help with this issue I'd really
appreciate it.
Thanks Simon

HD DVD encoding and playback problem

Hello,
we are running into a problem with some HD dvd authoring lately. We are using 1920x1080 23.98fps film based source material and encode it for HD DVD use with compressor. Like it says in the documentation we are using the hd dvd presets and just adjust the output to 720P for an H.264 encode. Apparently since the last upgrade to DVD studio 4.2 it is now possible to encode progressive h.264 with a framerate of 23.98 fps. Well as i said we encode the footage with compressor, import it into DVDSP 4.2 and include it into our project. Everything works fine until we put it into our DVD player (Toshiba HD-A20). The menus and everything works and looks great, but when we are playing the 720P 23.98fps H.264 clips we get a way too fast playing clip, basically as if it is trying to play it at 29.97 fps. Does anyone else run into that problem? First we thought it is the player, but then we tried playing the disc in our Macpro and the same problem. 1920x1080 works great with Mpeg2 29,97fps compression, even though, because we have film based 23.98fps source material it seems to stutter slightly. I wonder if we need to include 2:3 pulldown in order for the player to remove it properly. Any help would be great.
Thanks,
Gorilla

Harm,
Sorry for not responing for a few days, but I runned the benchmark you'll send me. The main results (dee details attached file):
53,6, secs Total Benchmark Time
6,4, secs AVI Encoding Time
14,2, secs MPEG Elapsed Time
33, secs Rendering Time
Since the potential problem is my hard disk, inaddition, I runned HDtune (hopefully it will help pinpionting the problem):
disk1: avarage transfer rate: 94MB/s, acces time 13.8ms, burst rate 185MB/s
disk2: avarage transfer rate: 85MB/s, acces time 14ms, burst rate 157MB/s
disk3: avarage transfer rate: 73MB/s, acces time 13.9ms, burst rate 183MB/s
Analyzing these results, could the current hard disk configuration cause the problem I have, or is my system to slow anyway to edit AVCHD material?
If the hard disk configuration is the problem, could it be solved by applying your suggestion by removing all partitions? Since, I'm not looking forward of removing all partions(re-installing windows (dual boot win7 and vista), shifting a huge amount of data, etc), but if it would help I will do it.
Thanks inadvance,
Jeffrey

Client wants .mov or .avi viewable and editable on a p.c. Ugh!

Sorted out the media drive issue at least. The files are very large ntsc/dv exports.
.avi ntsc/dv codec isn't working, nor the original .mov exports.
I would have thought ntsc/dv would be a pretty standard codec on the latest build of Quicktime for Windows, but apparently not. The client isn't very media savvy. Should we advise him to try downloading any particular codec component packs?
Or do we need a conversion app? QT on mac seems to limit .avi encoding to none, ntsc/dv, animation, and cinepak.
Anybody had any success doing this?

Hi Joey,
DV usually works on both systems...
You need to deliver at the highest res possible since your client
needs to edit this material and the original source would be best.
However, before you start with big exports or conversion try one or two tests
with Uncompressed and Animation.
Yeah you might end up with huge files but what matter first is that
your client can play your delivered material at its best.
If she only needed to preview this you could suggest to download the ProRes decoder for PC.
So in short export a tiny portion of your material in Animation and Uncompressed (I'd stay away from exporting AVIs if possible)and see what she says
Luca

What every developer should know about character encoding

This was originally posted (with better formatting) at Moderator edit: link removed/what-every-developer-should-know-about-character-encoding.html. I'm posting because lots of people trip over this.
If you write code that touches a text file, you probably need this.
Lets start off with two key items
1.Unicode does not solve this issue for us (yet).
2.Every text file is encoded. There is no such thing as an unencoded file or a "general" encoding.
And lets add a codacil to this – most Americans can get by without having to take this in to account – most of the time. Because the characters for the first 127 bytes in the vast majority of encoding schemes map to the same set of characters (more accurately called glyphs). And because we only use A-Z without any other characters, accents, etc. – we're good to go. But the second you use those same assumptions in an HTML or XML file that has characters outside the first 127 – then the trouble starts.
The computer industry started with diskspace and memory at a premium. Anyone who suggested using 2 bytes for each character instead of one would have been laughed at. In fact we're lucky that the byte worked best as 8 bits or we might have had fewer than 256 bits for each character. There of course were numerous charactersets (or codepages) developed early on. But we ended up with most everyone using a standard set of codepages where the first 127 bytes were identical on all and the second were unique to each set. There were sets for America/Western Europe, Central Europe, Russia, etc.
And then for Asia, because 256 characters were not enough, some of the range 128 – 255 had what was called DBCS (double byte character sets). For each value of a first byte (in these higher ranges), the second byte then identified one of 256 characters. This gave a total of 128 * 256 additional characters. It was a hack, but it kept memory use to a minimum. Chinese, Japanese, and Korean each have their own DBCS codepage.
And for awhile this worked well. Operating systems, applications, etc. mostly were set to use a specified code page. But then the internet came along. A website in America using an XML file from Greece to display data to a user browsing in Russia, where each is entering data based on their country – that broke the paradigm.
Fast forward to today. The two file formats where we can explain this the best, and where everyone trips over it, is HTML and XML. Every HTML and XML file can optionally have the character encoding set in it's header metadata. If it's not set, then most programs assume it is UTF-8, but that is not a standard and not universally followed. If the encoding is not specified and the program reading the file guess wrong – the file will be misread.
Point 1 – Never treat specifying the encoding as optional when writing a file. Always write it to the file. Always. Even if you are willing to swear that the file will never have characters out of the range 1 – 127.
Now lets' look at UTF-8 because as the standard and the way it works, it gets people into a lot of trouble. UTF-8 was popular for two reasons. First it matched the standard codepages for the first 127 characters and so most existing HTML and XML would match it. Second, it was designed to use as few bytes as possible which mattered a lot back when it was designed and many people were still using dial-up modems.
UTF-8 borrowed from the DBCS designs from the Asian codepages. The first 128 bytes are all single byte representations of characters. Then for the next most common set, it uses a block in the second 128 bytes to be a double byte sequence giving us more characters. But wait, there's more. For the less common there's a first byte which leads to a sersies of second bytes. Those then each lead to a third byte and those three bytes define the character. This goes up to 6 byte sequences. Using the MBCS (multi-byte character set) you can write the equivilent of every unicode character. And assuming what you are writing is not a list of seldom used Chinese characters, do it in fewer bytes.
But here is what everyone trips over – they have an HTML or XML file, it works fine, and they open it up in a text editor. They then add a character that in their text editor, using the codepage for their region, insert a character like ß and save the file. Of course it must be correct – their text editor shows it correctly. But feed it to any program that reads according to the encoding and that is now the first character fo a 2 byte sequence. You either get a different character or if the second byte is not a legal value for that first byte – an error.
Point 2 – Always create HTML and XML in a program that writes it out correctly using the encode. If you must create with a text editor, then view the final file in a browser.
Now, what about when the code you are writing will read or write a file? We are not talking binary/data files where you write it out in your own format, but files that are considered text files. Java, .NET, etc all have character encoders. The purpose of these encoders is to translate between a sequence of bytes (the file) and the characters they represent. Lets take what is actually a very difficlut example – your source code, be it C#, Java, etc. These are still by and large "plain old text files" with no encoding hints. So how do programs handle them? Many assume they use the local code page. Many others assume that all characters will be in the range 0 – 127 and will choke on anything else.
Here's a key point about these text files – every program is still using an encoding. It may not be setting it in code, but by definition an encoding is being used.
Point 3 – Always set the encoding when you read and write text files. Not just for HTML & XML, but even for files like source code. It's fine if you set it to use the default codepage, but set the encoding.
Point 4 – Use the most complete encoder possible. You can write your own XML as a text file encoded for UTF-8. But if you write it using an XML encoder, then it will include the encoding in the meta data and you can't get it wrong. (it also adds the endian preamble to the file.)
Ok, you're reading & writing files correctly but what about inside your code. What there? This is where it's easy – unicode. That's what those encoders created in the Java & .NET runtime are designed to do. You read in and get unicode. You write unicode and get an encoded file. That's why the char type is 16 bits and is a unique core type that is for characters. This you probably have right because languages today don't give you much choice in the matter.
Point 5 – (For developers on languages that have been around awhile) – Always use unicode internally. In C++ this is called wide chars (or something similar). Don't get clever to save a couple of bytes, memory is cheap and you have more important things to do.
Wrapping it up
I think there are two key items to keep in mind here. First, make sure you are taking the encoding in to account on text files. Second, this is actually all very easy and straightforward. People rarely screw up how to use an encoding, it's when they ignore the issue that they get in to trouble.
Edited by: Darryl Burke -- link removed

DavidThi808 wrote:
This was originally posted (with better formatting) at Moderator edit: link removed/what-every-developer-should-know-about-character-encoding.html. I'm posting because lots of people trip over this.
If you write code that touches a text file, you probably need this.
Lets start off with two key items
1.Unicode does not solve this issue for us (yet).
2.Every text file is encoded. There is no such thing as an unencoded file or a "general" encoding.
And lets add a codacil to this – most Americans can get by without having to take this in to account – most of the time. Because the characters for the first 127 bytes in the vast majority of encoding schemes map to the same set of characters (more accurately called glyphs). And because we only use A-Z without any other characters, accents, etc. – we're good to go. But the second you use those same assumptions in an HTML or XML file that has characters outside the first 127 – then the trouble starts. Pretty sure most Americans do not use character sets that only have a range of 0-127. I don't think I have every used a desktop OS that did. I might have used some big iron boxes before that but at that time I wasn't even aware that character sets existed.
They might only use that range but that is a different issue, especially since that range is exactly the same as the UTF8 character set anyways.
>
The computer industry started with diskspace and memory at a premium. Anyone who suggested using 2 bytes for each character instead of one would have been laughed at. In fact we're lucky that the byte worked best as 8 bits or we might have had fewer than 256 bits for each character. There of course were numerous charactersets (or codepages) developed early on. But we ended up with most everyone using a standard set of codepages where the first 127 bytes were identical on all and the second were unique to each set. There were sets for America/Western Europe, Central Europe, Russia, etc.
And then for Asia, because 256 characters were not enough, some of the range 128 – 255 had what was called DBCS (double byte character sets). For each value of a first byte (in these higher ranges), the second byte then identified one of 256 characters. This gave a total of 128 * 256 additional characters. It was a hack, but it kept memory use to a minimum. Chinese, Japanese, and Korean each have their own DBCS codepage.
And for awhile this worked well. Operating systems, applications, etc. mostly were set to use a specified code page. But then the internet came along. A website in America using an XML file from Greece to display data to a user browsing in Russia, where each is entering data based on their country – that broke the paradigm.
The above is only true for small volume sets. If I am targeting a processing rate of 2000 txns/sec with a requirement to hold data active for seven years then a column with a size of 8 bytes is significantly different than one with 16 bytes.
Fast forward to today. The two file formats where we can explain this the best, and where everyone trips over it, is HTML and XML. Every HTML and XML file can optionally have the character encoding set in it's header metadata. If it's not set, then most programs assume it is UTF-8, but that is not a standard and not universally followed. If the encoding is not specified and the program reading the file guess wrong – the file will be misread.
The above is out of place. It would be best to address this as part of Point 1.
Point 1 – Never treat specifying the encoding as optional when writing a file. Always write it to the file. Always. Even if you are willing to swear that the file will never have characters out of the range 1 – 127.
Now lets' look at UTF-8 because as the standard and the way it works, it gets people into a lot of trouble. UTF-8 was popular for two reasons. First it matched the standard codepages for the first 127 characters and so most existing HTML and XML would match it. Second, it was designed to use as few bytes as possible which mattered a lot back when it was designed and many people were still using dial-up modems.
UTF-8 borrowed from the DBCS designs from the Asian codepages. The first 128 bytes are all single byte representations of characters. Then for the next most common set, it uses a block in the second 128 bytes to be a double byte sequence giving us more characters. But wait, there's more. For the less common there's a first byte which leads to a sersies of second bytes. Those then each lead to a third byte and those three bytes define the character. This goes up to 6 byte sequences. Using the MBCS (multi-byte character set) you can write the equivilent of every unicode character. And assuming what you are writing is not a list of seldom used Chinese characters, do it in fewer bytes.
The first part of that paragraph is odd. The first 128 characters of unicode, all unicode, is based on ASCII. The representational format of UTF8 is required to implement unicode, thus it must represent those characters. It uses the idiom supported by variable width encodings to do that.
But here is what everyone trips over – they have an HTML or XML file, it works fine, and they open it up in a text editor. They then add a character that in their text editor, using the codepage for their region, insert a character like ß and save the file. Of course it must be correct – their text editor shows it correctly. But feed it to any program that reads according to the encoding and that is now the first character fo a 2 byte sequence. You either get a different character or if the second byte is not a legal value for that first byte – an error.
Not sure what you are saying here. If a file is supposed to be in one encoding and you insert invalid characters into it then it invalid. End of story. It has nothing to do with html/xml.
Point 2 – Always create HTML and XML in a program that writes it out correctly using the encode. If you must create with a text editor, then view the final file in a browser.
The browser still needs to support the encoding.
Now, what about when the code you are writing will read or write a file? We are not talking binary/data files where you write it out in your own format, but files that are considered text files. Java, .NET, etc all have character encoders. The purpose of these encoders is to translate between a sequence of bytes (the file) and the characters they represent. Lets take what is actually a very difficlut example – your source code, be it C#, Java, etc. These are still by and large "plain old text files" with no encoding hints. So how do programs handle them? Many assume they use the local code page. Many others assume that all characters will be in the range 0 – 127 and will choke on anything else.
I know java files have a default encoding - the specification defines it. And I am certain C# does as well.
Point 3 – Always set the encoding when you read and write text files. Not just for HTML & XML, but even for files like source code. It's fine if you set it to use the default codepage, but set the encoding.
It is important to define it. Whether you set it is another matter.
Point 4 – Use the most complete encoder possible. You can write your own XML as a text file encoded for UTF-8. But if you write it using an XML encoder, then it will include the encoding in the meta data and you can't get it wrong. (it also adds the endian preamble to the file.)
Ok, you're reading & writing files correctly but what about inside your code. What there? This is where it's easy – unicode. That's what those encoders created in the Java & .NET runtime are designed to do. You read in and get unicode. You write unicode and get an encoded file. That's why the char type is 16 bits and is a unique core type that is for characters. This you probably have right because languages today don't give you much choice in the matter.
Unicode character escapes are replaced prior to actual code compilation. Thus it is possible to create strings in java with escaped unicode characters which will fail to compile.
Point 5 – (For developers on languages that have been around awhile) – Always use unicode internally. In C++ this is called wide chars (or something similar). Don't get clever to save a couple of bytes, memory is cheap and you have more important things to do.
No. A developer should understand the problem domain represented by the requirements and the business and create solutions that appropriate to that. Thus there is absolutely no point for someone that is creating an inventory system for a stand alone store to craft a solution that supports multiple languages.
And another example is with high volume systems moving/storing bytes is relevant. As such one must carefully consider each text element as to whether it is customer consumable or internally consumable. Saving bytes in such cases will impact the total load of the system. In such systems incremental savings impact operating costs and marketing advantage with speed.

HOW SPECIFY FILE.ENCODING=ANSI FORMAT IN J2SE ADAPTER.

Hi All,
we are using j2se plain adapter, we need the outputdata in ANSI FORMAT.
Default file.encoding=UTF-8
how to achive this.
thanks in advance.
Regards,
Mohamed Asif KP

File adapter would behave in a similar fashion on J2ee. Providing u the link to ongoing discussion
is ANSI ENCODING possible using file/j2see adapter
Regards,
Prateek

Audio, no video with .avi file

We have cameras on our buses in which we can save the video to a PC as an .avi video file. (hardware only works on a PC). So now I have a .avi file that we would like to view on our Macs. No matter what program I try, the movie has sound, but no video.
+According to MediaInfoMac,+
+Video Codecs Used: WaveCodec+
+Audio Codecs Used: PCM+
+File Format: AVI+
+Encoded with: MEncoder 1.0pre5-3.3.5+
+Encoding Library: MPlayer+
+another program mentioned ADV1+
I have
* tried both Leopard and Snow Leopard machines
* Quicktime Pro
* Perian (made sure the DiVx was unistalled, repaired permission, restarted etc)
* tried the latest VLN
I don't mind purchasing a program, but I want to make sure it will work. This is an important program to us and we need it to work.
Has anyone run across this type of file?

There is no Mac codec for that video format. Use MPEG Streamclip to convert it to MPEG-4 on the PC.
(51506)

Encoding and playback problem HD files

Hi all,
Currently, I'm using a new HD camcorder and have no problem with importing and playing these files is premiere cs4 pro. However, when I'm using six video track at the same time I experience some playback problems. After rendering, the video's play, but not smooth, they skip frames and playing a few frames back. In other words, it seems that the video playback stutters. The problem still excists when I encode the project to any file (mpeg2-blu ray, avi, etc). When using two video tracks (with two HD video) this problem is not present, even when these video's are in slowmotion. Installing the new update (4.2) did not solve the problem.
Specs of my system:
Quad core Q6600 @3.0GHz (overclocked)
8gb RAM
>200gb free disk space
windows 7, 64-bit
Does anyone have some suggestions to solve this problem? Thanks in advance.
Regards,
Jeffrey

Harm,
Sorry for not responing for a few days, but I runned the benchmark you'll send me. The main results (dee details attached file):
53,6, secs Total Benchmark Time
6,4, secs AVI Encoding Time
14,2, secs MPEG Elapsed Time
33, secs Rendering Time
Since the potential problem is my hard disk, inaddition, I runned HDtune (hopefully it will help pinpionting the problem):
disk1: avarage transfer rate: 94MB/s, acces time 13.8ms, burst rate 185MB/s
disk2: avarage transfer rate: 85MB/s, acces time 14ms, burst rate 157MB/s
disk3: avarage transfer rate: 73MB/s, acces time 13.9ms, burst rate 183MB/s
Analyzing these results, could the current hard disk configuration cause the problem I have, or is my system to slow anyway to edit AVCHD material?
If the hard disk configuration is the problem, could it be solved by applying your suggestion by removing all partitions? Since, I'm not looking forward of removing all partions(re-installing windows (dual boot win7 and vista), shifting a huge amount of data, etc), but if it would help I will do it.
Thanks inadvance,
Jeffrey

H.263 avi encoding - possible?

Similar Messages

Maybe you are looking for