Tambourine said:
FLV is a format and h264 is a codec. FLV video format in cases uses the h264 codec to compress info in video files, on some other cases it uses other kinds of codecs.
To clarify my earlier statement.
The current codec in use is the sorenson h.263 one, also known as 'flv'.
This is the one that's been used for a long time, and not the h.264 codec used briefly during the trials for both 640*480 and some 320*240 content.
Tambourine said:
Blurry frames are caused by the camera's sensor not the compression, its caused when the model moves faster than the time it takes for the sensor to create the image, so the pixels are moved and repeated which causes the blurriness. The video stutter cause by too compress images is not fixable but it is preventable, you'll just need not to move so much, which is dumb but well real. This stutter issue is actually one of the biggest concerns about video technology because it doesnt have a solution yet, and it one of the biggest downsides of digital video as an evolving format.
This is somewhat true - and somewhat misleading.
There is blur which is caused by the camera shutter - yes.
However, the other cause of both blur and jerkiness is due to the fact that the video codec is trying to convert the stream of incoming frames into a sequence of bits which go out through the models internet in a smooth stream.
The problem arises when a large change occurs in the picture, or changes happen at too fast a rate - the image breaks down not due to motion blur, but doe to the codec not having enough bits to encode all the changes in the image.
This causes texture in fast-moving areas to dissapear, blockiness, and other artifacts.
There is no problem with stutter with properly setup digital video codecs.
It only occurs if there is not enough CPU to compress the image properly - if there is some problem with the video hardware or drivers causing it to miss frames, or if the codec is misconfigured.
With proper digital video, the codec takes one frame, analyses it, spits out some bits as to how it changed from the last frame, and repeats. (with keyframes every so often to cope with major changes, or file corruption).
One frame in = one frame out - there isn't any room for jerkiness.
With random models cameras and random CPU, it's a bit more complex.
Is the camera and its driver properly delivering frames to the codec, is the bandwidth too large for the upload capabilities of the models line, is the CPU adequate to encode each frame on-time, so it doesn't run out of the limited sound buffer, and be desynced from it, causing it to skip frames?
...
How much of this is under MFCs control is somewhat questionable.
It may well be lots better if they could get with - say - manycams - and produce a simple uploader for video, which diddn't rely on anything to do with flash.
As to changes - MFC can do some configuration of the flash stream from the model - they have to be to be able to set the profile of the models stream. Changes in this configuration might include min/max framerates, and other parameters, which may make some models cameras seem better, and others worse than they were before.
maybe this is an mfc conspiracy to get hid of all the huge distracting/moving tagging/banners.
need new forum section ? pchelp?
