50i or 60i setting help please

[Matt Davis]

Originally Posted by Colin Elves

I thought it might be something like that. God, AVCHD MTS is such toss isn't it?

I believe that's the correct technical term, yes. :-)

Originally Posted by Colin Elves

I'd have much preferred that Sony just stick the h.264 in a simple QuickTime wrapper, all in nice discreet files - like Canon do. Their implementation is such a ball ache. Bloody Sony

Actually, Canon C100 has just the same problem. In fact you can put an FS700 card in a Canon C100 camera and it will read the shots. Not sure about the MXF implementations over in Canon-land, but the C100 'compatibility' trick is evidence of the 'Bloody' AVCHD standard (rather than Bloody Sony or Bloody Canon :-D )

There was, of course, the JVC trick of shooting XDCAM in QuickTime wrappers - was that what you were thinking of?

[Colin Elves]

Originally Posted by Matt Davis

Not sure about the MXF implementations over in Canon-land, but the C100 'compatibility' trick is evidence of the 'Bloody' AVCHD standard (rather than Bloody Sony or Bloody Canon :-D )

There was, of course, the JVC trick of shooting XDCAM in QuickTime wrappers - was that what you were thinking of?

I don't know what the trick is. I just thought AVCHD was a fancy (read: awful) way of implementing h.264 vido compression - which my Canon DSLR seems to manage fine in simple discreet QuickTime files.

It's a shame if Canon have gone over to AVCHD too - lord knows what they were thinking of when they came up with that standard, as it certainly wasn't pro filmamkers. Must have been the crack talking...

[Alister Chapman]

AVCHD is an industry standard way of encoding using H264 and includes very specific frame sizes and frame rates and codec levels, as well as standard wrappers like mts which also contain metadata about the file. H264 in a quick time wrapper can be anything, any size, any bit rate any level and this can lead to poor quality decoding as the decoder may not be able to determine the correct codec level or which of the many H264 coding enhancements have been used. All the AVC versions of H264 are designed for video camera applications with the ability to use high level features like uncompressed PCM audio and/or Intra frame encoding that are not included in normal H264. AVC Includes AVCHD, AVC Intra and the new XAVC which goes up to 4K at high frame and bit rates not normally part of the H264 specifications.

[Colin Elves]

SEE, see!!! This is why it's rubbish. It's too complicated. I used to like it when you could fix a car with a pair of nylon stockings, now everything needs to be plugged in to a sodding computer.

This stupid database system causes no end of trouble. Why couldn't you just include all the relevant data for codec, frame size etc within the video file itself? Then you wouldn't have the problem where one dodgy video file messes up a whole card. I've had clients call up to say they can't import a card because the folder structure is messed up - so they've had to buy Clipwrap to sort it!

Then, the other day, my FS700 got itself in a right old funk: every time I put it in slow-mo it would just freeze. I couldn't even turn it off without pulling the battery. Drove me mad that did. Eventually managed to work out a combination of settings that wouldn't freeze, but was forced to record the slo mo in 60p rather than 24p like I wanted. Grrr. Stupid computers. Bring back film I say, I could understand all those cogs.

[David Heath]

Originally Posted by Colin Elves

SEE, see!!! This is why it's rubbish. It's too complicated. I used to like it when you could fix a car with a pair of nylon stockings, now everything needs to be plugged in to a sodding computer.

I know exactly how you feel!! :-)

This stupid database system causes no end of trouble. Why couldn't you just include all the relevant data for codec, frame size etc within the video file itself? Then you wouldn't have the problem where one dodgy video file messes up a whole card.

I'd expect codec, frame size etc data to be within the basic file itself, but we get on to the much wider subject of metadata in general. And basically it's a good idea to NOT put a lot of metadata into the video file itself. That means the metadata can be modified without touching the basic video/audio file itself, and also makes metadata searching far faster if that is kept separate from the (relatively very large) video/audio files).

I remember being asked about a system based on a Focus "Firestore" being evaluated, with an eye to easier on set logging. The proposal was for a basic Firestore type hard drive recorder to be wireless fed with logging text from a laptop, the logging data to be incorporated into the video file.

The more I thought about it, the more potential problems came up. What about text typed between shots? Should that be embedded in the preceeding or following file? If the preceeding (which would be more logical) then how could that be implemented? How could the reliability of the text be guaranteed? Compatability of these files within other equipment?

Frankly, it was an example of taking the wrong approach to a problem. Far better to do it the other way round. Form local log files on the PC, and send data from camera to PC (not the other way round) - timecode and possibly whether or not the camera was running.

The only extra hardware then needed was a one-way timecode link, together with software to embed it into the text. Simple (hence cheap) and better than the previously proposed system - the log files remain separate (albeit linked) to the video/audio and small in size, hence easily e-mailed etc separate from the main video/audio.

It would also be quite resilent to loss of the camera/logging link if continuous timecode was being recorded, as long as the receiver would freerun in absence of signal.

Sorry for the digression, but as basic principle it's a good idea to embed some basic metadata in the same file as video/audio, but also a good idea to keep much separate - as long as the two are properly linked!