interlaced mode in consumer camcorders

[ybarra]

Again, it all comes down to bandwidth and interlace does NOT hurt compression if you're viewing it in the correct context:

Let's take a 480i60 source for instance. Your mpeg-2 or h.264 is trying to compress 60 fields of half vertical resolution. That's more visual information than 480p30. Deinterlacing 480i60 in a sense averages the fields into 30 full frames throwing away some of the visual information by smoothing it, so yes, 480p30 will compress more than 480i60 simply because you've lost some of the visual information. I understand that mathematically it's the same amount of pixels, but 60 fields captures more movement than 30 frames, therefore it's technically more visual information the more movement between a full frame.

The same applies to 1080i60. 1080i60 has more visual information than 1080p30. Broadcast is usually around 18-20mbps mpeg2 (at least around here) to cram that information into. Most camcorders are using 24mbps mpeg4. You're going to get a whole lot of artifacts trying to cram 1080p60 into 28mbps (AVCHD 2.0) in real time because you're adding way more visual information. 1080i60 was the best compromise for capturing motion and still getting it into a reasonable bandwidth.

IMHO, it's silly to complain about camcorders not being all native progressive because you're looking at a past technology limitation (bandwidth). It's the functional equivalent of complaining that all cameras should have a 4K mode. I imagine as the technology progresses and we get the higher bandwidths for 4K and 8K you'll see 1080p60 as a standard. Otherwise, in today's bit rates 1080p60 will just equal a bad case of the blockies. Don't believe me? Check out Sony's NEX-FS100. That camera clocks in at 10-20x the price of a consumer camcorder and includes the 1080p60 holy-grail. Problem is that a lot of pros will tell you they won't shoot it. It's because the AVCHD 2.0 specs only allow for a top of 28mbps. When you compare 1080p24 or 1080i60 @ 24mbps with 1080p60 (double the data) in 28mbps, the quality is just awful.

[glenpinn]

hi, my panasonic HDC-SDT750 cams film in 1080p/50, i convert them to 1080p/50 and 720p/50 MP4 using handbrake @ RF20 and audio is either auto passthru or AAC passthru depending what i need.

on my computers or laptops the resulting 1080p/720p and the original m2ts files play perfectly using various software media players like VLC, MPC-hc & WMP, i get no shimmering from any of them.

as soon as i dump them all onto a portable usb hard drive and play them directly thru the usb port on any HD (1366x768) or full HD tv the 720p/50 MP4 plays perfectly just as it does on the computers, but the 1080p/50 MP4 and m2ts files will not play properly, they have this "shimmering" effect during playback, and is more noticeable when the camera is panning.

i have also tried them on all sorts of different model hdd media players such as WD Live, PCH & my own Dune HD-TV 301 player and i get the same shimmering with the 1080p/50 files.

i am pretty happy watching the 720p/50 mp4 files, the quaality is pretty dam awesome, but it would be nice to be able to play the 1080p/50 files without the shimmer in them.

cheers

[pandy]

pandy,

There are no real eyeballs in that first paper - it's all PSNR with certain deinterlacers.

In the second paper, the bitrate isn't mentioned.

Hmmm - it was fast search in Google, also it is very difficult to find any other than PSNR metrics for older ie before 1995 case studies (i mean times when MPEG-2 was born), however i fully understand why interlace exist, what is good and bad with interlace and also i assume that interlace must be more difficult to compress ie tend to produce higher bitrate than progressive video (function is not smooth but disrupted and all math related to this problem) - i think that this can be relatively easy to prove with help of some p50/60 source without deinterlacing ie produce half rate progressive p25/30 vs i25/30. And still i think that interlace is good (for limited bandwidth) because it provide data compression directly correlated with our vision perception ie human eye is less sensitive to details for moving (especially fast) objects and for static part we see much more details and this more or less is similar to way how interlace works - exchange motion fluidity for resolution for moving objects and opposite to static and quasi static.

"Everyone says" interlacing will hurt compression. With H.264, depending on the encoder and the deinterlacer, you can demonstrate that this is true sometimes. There are plenty of EBU papers showing that.

However, at real world broadcast bitrates, you'd be struggling to deliver 50p using MPEG-2 and have something watchable with complex content. TBH it's not always watchable with 50i either.

MPEG-2 just isn't smart enough to rendering interlacing a redundant piece of compression technology.

Cheers,
David.

Oh - for example France 1 (AFAIR TF1) create nice MPEG-2 stream where encoder analyze amount of motion and switch to progressive always where it is better from quality/bitrate point of view - nice example of encoding where i assume both ways are analyzed (interlace and progressive) then if progressive is better (of course there is question about metrics used to take decision) however obviously from some reason (and i assume not to hurt quality) progressive is preferred for video with static and quasi static content.

[2Bdecided]

The dynamic switching of some broadcasts (we have it in the UK too, on the HD channels) is from 50i to 25p, not 50p. It is used during still scenes, or (most usefully) on content that is really 25p, like films. The broadcast chain up to the encoder has no way of differentiating between 50i and 25p - both are 25 frames per second on an SDI interface, so you need a smart encoder to detect and switch for best results.


Tests, stating with an uncompressed progressive source, and comparing 50i and 50p, have already been done many times. The winner depends on the codec, the bitrate, and the content. It is simply not true that 50p always wins!

When I did my own tests years back, I found that 25p beats 50i in encoding quality by a large margin with MPEG-2, but of course it stutters. 50p loses badly.

Cheers,
David.

[pandy]

The dynamic switching of some broadcasts (we have it in the UK too, on the HD channels) is from 50i to 25p, not 50p. It is used during still scenes, or (most usefully) on content that is really 25p, like films. The broadcast chain up to the encoder has no way of differentiating between 50i and 25p - both are 25 frames per second on an SDI interface, so you need a smart encoder to detect and switch for best results.


Tests, stating with an uncompressed progressive source, and comparing 50i and 50p, have already been done many times. The winner depends on the codec, the bitrate, and the content. It is simply not true that 50p always wins!

When I did my own tests years back, I found that 25p beats 50i in encoding quality by a large margin with MPEG-2, but of course it stutters. 50p loses badly.

Cheers,
David.

Oh, my point was related only to comparison p25 vs i25 (SDTV compatible). Forcing MPEG-2 MP@ML with 15Mbps limitation to compress p50/i50 can be demanding task (i assume longer GOP is required than recommended by EBU i.e. I frame in less than 500ms period).

[_Al_]

as for H.264,
I only tested 60i vs.60p, where 60p was created out of 60i by QTGMC,30p was created by dropping avery other frame, which might not be optimal I admit. I did not look for some uncompressed 60i and 60p same sources.
I found, using x264 and CRF and 60p that you need more bitrate, than for 30p (15-20%) , but less then 60i.

I correct myself, last sentence, using word "bitrate", it got different meaning, what I meant to say - using CRF, 60p got bigger then 30p (15-20%) but was smaller then 60i.