How to determine TFF or BFF for deinterlacing?

[enim]

Hi there,

I have been surfing this forum for a while and finally here I am to seek help.
Some provided me leisure party family footage for processing and conversion with sample attached here.

General
Complete name : Sample.h264
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 2.17 MiB
Duration : 10s 51ms
Overall bit rate mode : Variable
Overall bit rate : 1 814 Kbps
Writing application : Eureka 10.10

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 10s 51ms
Bit rate mode : Variable
Bit rate : 1 800 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 16:9
Original display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 29.950 fps
Original frame rate : 29.970 fps
Minimum frame rate : 25.000 fps
Maximum frame rate : 29.970 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : MBAFF
Bits/(Pixel*Frame) : 0.174
Stream size : 2.17 MiB (100%)
Writing library : Eureka 10.10 [UTC 2010-10-10]
Color primaries : BT.601 NTSC
Transfer characteristics : BT.601
Matrix coefficients : BT.601

It seems like interlaced while playing in VLC.
How to determine TFF or BFF for deinterlacing?

[aedipuss]

Scan type : MBAFF

http://www.afterdawn.com/glossary/term.cfm/macroblock-adaptive_frame-field_coding

it's neither tff or bff

combined with variable frame rate and you have a mess.

[poisondeathray]

You can treat it as BFF

The way you check is to assume a field order and separate the fields . If it goes fwd/back/fwd/back - it's the wrong field order, then you choose the other

Similarly, if you get the wrong field order when deinterlacing, the motion will be jerky fwd/back/fwd/back

[enim]

from afterdawn link

MBAFF, or Macroblock-Adaptive Frame/Field Coding, is a video encoding feature of MPEG-4 AVC that allows a single frame to be encoded partly progressive and partly interlaced. Maintaining the quality of interlaced video can be a challenge in video encoding because of the larger spaces between horizontal lines in the same field. MBAFF allows an AVC encoder to examine each block in a frame to look for similarities between interlaced fields.

it is possible that a encoded frame is partly interlaced and partly progressive?

Treating as BFF and trying yadif as suggested. but, if a encoded frame is partly interlaced and partly progressive mostly all deinterlace filters gonna mess around whole frame.

More from afterdawn on PicAFF

when using PicAFF encoding an AVC encoder looks for motion to determine whether both fields shold be encoded as a single progressive frame or separate interlaced fields. While not as efficient as the alternative, MBAFF, in terms of file size,

[aedipuss]

here's what you get calling it bff and rendering bff mpeg-2. calling it bff and rendering tff. and calling it tff and rendering tff.

[enim]

nice one!

should I re-encode whole footage as BFF?
coz i dunno think most of the editors will import it correctly.

[jagabo]

it is possible that a encoded frame is partly interlaced and partly progressive?

Yes. Where the encoder encounters comb artifacts it encodes as interlace. Where there are no comb artifacts it encodes as progerssive.

Treating as BFF and trying yadif as suggested. but, if a encoded frame is partly interlaced and partly progressive mostly all deinterlace filters gonna mess around whole frame.

Depends on the deinterlace filter. Smart ones only deinterlace where they see comb artifacts.

Smart bobbed to 60 fps progressive (AR looks wrong to me, should be 4:3?):

[aedipuss]

ouch nasty de-interlace. you lose parts of the objects in motion. like the horse is missing it's entire mouth area and parts of it's legs.

[enim]

as said, it looses details and sharpness.


[Attachment 18055 - Click to enlarge]

[jagabo]

Yes, all deinterlacing is destructive. Some algorithms work better for some material, some for others.

And, by the way, the horse's nose and legs were missing in that field of the original video too.

bob:


And just for kicks, Yadif:

[enim]

Tks, bob seems better for this clip.
and yadif is not too bad either.

And, by the way, the horse's nose and legs were missing in that field of the original video too.

yeeeep!

i will blame the encoder, it followed BAFFMBAFF instead of MBAFF. This is the one gotcha out of many that exist in this universe.

[jagabo]

Tks, bob seems better for this clip.

Bob generally produces the most buzzing edges (of the double frame rate deinterlaceres) and largest loss of resolution. It doesn't look too bad in that frame because there are hardly any near-horizontal lines and edges.

and yadif is not too bad either.

If you zoom in you'll see lots of small dots where it made mistakes around the horse and rider. They aren't too visible at 60 fps though.

[enim]

I am in a beer pub, just had 20 pint of beer and food, still on this.
why it sucks,
Video camera eats up 10% of details,
digital video transfer eats up 10% details,
pre-processing eats up 10%
encoder eats up 20%,
filtering eats up 15%,
compression eats up 20%,
chicken-shit that's what I am left with (only 15% or less).

Full plate of bones instead of chicken drum sticks????
horse without nose, head,leg or tail is much expected.
THIS IS BULLSHIT!

but, i am still up!

I was so fortunate that today in this pub some Digital Video Expert Group party is going on, I met Mr. Gloomy, IEC 11172-1:1993 and shown this, he pointed to Mr. Shiny, IEC 14496-27:2009, where Mr Shiny told we are all about complexity and compression, pump...pump and pump, just forget the quality.

I went on to encoding group, they said, come on-in buddy, we are just like a soup. As I found many with broken arm, leg or lamed without full-featured look, I preferred to stay away.

Finally, ended up with Video Camera Group, what they said is just keep spending more and more coz everyday we are updating our technology (coz we do not know either), but you know The Best is yet to come! or you can wait.

I fed-up, finally went back to a cute bartender, with a sad face I told her one more, please!
With a smile she told me that this is really too much that you can take.

[fvisagie]

[jagabo]

Video camera eats up 10% of details,
digital video transfer eats up 10% details,
pre-processing eats up 10%
encoder eats up 20%,
filtering eats up 15%,
compression eats up 20%,

I don't understand exactly what your process is here. Yes, if your camcorder compresses the video you are stuck with whatever losses you get from that compression. Digital video transfer should result in no losses, all you're doing is copying the file from the camcorder to the computer. If you are capturing analog video you won't lose significant detail with a decent capture device, capturing with a lossless codec. What do you mean by pre-processing? Filtering may or may not be necessary but should not result in significantly lower quality -- the point is to correct problems. Encoding doesn't need to result in large quality losses. Just use sufficient bitrate for your material.

[aedipuss]

the camera is the problem, it's garbage. all follows from there.

[jagabo]

I suspect the file he supplied was not directly from the camera. In which case we have no idea what the camera is capable of.