Hey Ross, I had shot you an email earlier this morning with regards to an issue with being unable to correctly open a file saved in memory as a JPEG. Well we soon figured out that fTo gets only the image data and the JPEG header is sent separately and that is what had caused the problem. Originally I was providing the entire JPEG array to fTo and this caused streaming issues.
Now we have run into another issue! We are using our own library to create the JPEG in memory on the Server. This library has it's own method for setting the compression ratio(0-99) and we set that compression ratio on the fly. What we are seeing is that the JPEG image displayed at the client side is much more lossy-(ier) than it should be for the value of the compression ratio. We have written the JPEG from memory to a file on the Server side and it does not have nearly the amount of compression that arrives at the client. I have a feeling this is partly in regards to the fLastQfactor on the server. I tried providing the same value to fLastQfactor as the compression ratio when we create the jpeg in memory and it did not seem to help. Only when the compression is set to about 95~99 is when we see an image that isn't severely compressed. How is the fLastQfactor related to how the client side receives and decompresses the JPEG? We again are using our own custom library to decode and display the JPEG on the client side, yet how we set fLastQfactor on the server is affecting the compression ratio that is recognized on the client side. We assumed that since we are encoding and decoding the jpeg with our own library that all of the information as far as compressing/decompressing the images would come from our library rather than any code from the server or client. Our desire here is simply to have the client recognize the same amount of comression as is set on the server. Essentially whatever we compressed to memory on the server is what we want to display on the client side. Do we need to derive our own create Qfactor table on the server? Hope to hear from you at your earliest convenience. Any help in this regard Would be seriously appreciated. Thanks, Nikhil. _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
