Does AVCSource properly decode pf24 footage?

[davexnet]

Hi all,
I couldn't find a definitive answer, so I thought I'd come straight here.
I'm talking about footage similar to the MTS sample (from the Canon HG10) provided on this page.
http://people.csail.mit.edu/dalleyg/collaboration/avchd/readme.html
Here's the sample: http://people.csail.mit.edu/dalleyg/collaboration/avchd/hg10-24pf.MTS

I provide the project (honor pulldown flags), TFM().Tdecimate()
but I get combing in some frames.

On the otherhand directshowsource().TFM().Tdecimate()
(using FFdshow 1.3.4500) *appears* to provide non-combed frames.

Thanks for any info.

[Guest]

Works fine for me, at least for your sample.

Possibly you are missing AssumeTFF() before the IVTC.

loadplugin("H:\Don\Programming\C++\DGAVCDec\DGAVCDecode\Release\DGAVCDecode.dll")
AVCSource("hg10-24pf.dga")
assumetff()
telecide(post=0)
decimate()

If you still have issues with that sample, please give your exact script and state which frame is still combed.

[davexnet]

HI Donald,
I got similar results with your script, since mine was pretty much the same - very basic:
LoadPlugin("F:\Documents and Settings\Dave Xnet\My Documents\Downloads\dgavcdec109\DGAVCDecode.dll")
AVCSource("F:\Documents and Settings\Dave Xnet\Desktop\movies _temp\hg10-24pf.dga") #,deblock=true)

#AVCSource("hg10-24pf.dga")
assumetff()
#tfm().tdecimate()
telecide(post=0)
decimate()
either telecide/decimate or tfm/tdecimate seemed to produce the same results. Look at frames 78,90,498,570 -
there are probably others, but these showed up when I was moving around the timeline. Not so easy to see,
not much movement, but you can see some combing on the legs of the people walking.

Switching to directshow with this,
directshowsource("f:\Documents and Settings\Dave Xnet\My Documents\Downloads\hg10-24pf.MTS",audio=no)
tfm().Tdecimate()
at first glance appears OK, as I eluded to above. Frame 78 (AVCSource) appears to match up with frame 81 in the dshow example,
based on the car position that is moving to the left.

[Guest]

I've examined this in detail now and it is clear that you are not seeing match failures due to the IVTC because the moving car is not affected, i.e., it is matched correctly on the frame where the leg is mangled, and because the mangling is clearly not simple combing. So you are seeing DGAVCDec failing to decode PAFF correctly here, as is well known.

You'll have to use a different source filter for PAFF. Naturally, I would suggest DGDecNV, which I have tested on your sample and found to be correct for these streams.

BTW, I have a version of DGAVCDec using an updated version of libav that doesn't show these particular artifacts. I won't release it, however, because that version of libav introduces other problems and I don't see a net gain. If DirectShowSource() is finding a good decoder as you suggest, then obviously that is a solution for you, no?

[davexnet]

Yes, of course. What is PAFF? Is it the way progressive fields are interlaced as shown by
"Figure 3: PF24 Decoding -- Common Realities vs. Correct" at http://people.csail.mit.edu/dalleyg/collaboration/avchd/readme.html
I'm referring to the first column, "Canon's Pulldown" ?

[poisondeathray]

Yes, of course. What is PAFF? Is it the way progressive fields are interlaced as shown by
"Figure 3: PF24 Decoding -- Common Realities vs. Correct" at http://people.csail.mit.edu/dalleyg/collaboration/avchd/readme.html
I'm referring to the first column, "Canon's Pulldown" ?



PAFF is "Picture Adaptive Field Frame" . It's a method of encoding as opposed to MBAFF encoding (macroblock adaptive field frame). You can think of it as encoding "interlaced" . When used in camcorders it's never adaptive, it's always coded as fields, not progressive frames

Canon's PF24 is analgous to "hard telecine" or "hard pulldown". Ie. it's 24p content encoded interlaced in a 59.94 fields per second stream . As opposed to "soft pulldown", where the same 24p content is encoded progressive, but pulldown flags output a 59.94 fields/s signal

Some consumer Canon models offer a true 24pN (native progressive) mode now

[Guest]

Thanks, poisondeathray. Nothing needs to be added to what you said.

[davexnet]

Thanks gentleman. I must ask, what did the owners of these cameras use to retrieve the 24 progressive frames per second out of the 30i footage?
Did canon offer a utility?

The writer of the article suggests it never should have been done this way, and that it's left over from
limitations in the Tech. from when tape was still being used.

Regarding this clip
http://people.csail.mit.edu/dalleyg/collaboration/avchd/hg10-pf24-clip2.mts

and a simple script like this so you can see the fields:
directshowsource("f:\Documents and Settings\Dave Xnet\My Documents\Downloads\hg10-pf24-clip2.mts",audio=no)
SeparateFields()

You see the back and forth motion as you would expect, due to the way the fields are stored,
but I'm surprised the cars are as blurry as they are. They're not traveling that fast.
Was the depth of field wrong, or perhaps the shutter speed too low?

[poisondeathray]

Thanks gentleman. I must ask, what did the owners of these cameras use to retrieve the 24 progressive frames per second out of the 30i footage?
Did canon offer a utility?


Many people used avisynth ; and some NLE's could IVTC it . Canon did not offer a utility that I know of.

"24p" was (and still is) considered a "pro" or "semi pro" area, so support wasn't that great on consumer camcorders whose typical buyers would be shooting home videos, not filmic theatrical content



The writer of the article suggests it never should have been done this way, and that it's left over from
limitations in the Tech. from when tape was still being used.


Yes; and as mentioned above true 24pN modes are offered now in some consumer camcorders (not just Canon)




Regarding this clip
http://people.csail.mit.edu/dalleyg/collaboration/avchd/hg10-pf24-clip2.mts

and a simple script like this so you can see the fields:
directshowsource("f:\Documents and Settings\Dave Xnet\My Documents\Downloads\hg10-pf24-clip2.mts",audio=no)
SeparateFields()

You see the back and forth motion as you would expect, due to the way the fields are stored,
but I'm surprised the cars are as blurry as they are. They're not traveling that fast.
Was the depth of field wrong, or perhaps the shutter speed too low?


HD is always TFF. You have to assume a field order when you separatefields() , otherwise avisynth assumes BFF by default (so you get the jerky fwd/back)

AssumeTFF()
SeparateFields()

RE: Motion blur - it looks about right for 24p .

But there is an overall blurriness/softness to the picture that is a result of a combination of things and might be partially contributing. The HG10 is an old 1st or 2nd generation AVCHD camcorder. The AVCHD compression back then was a lot worse (very soft and mushy), sensors were a lot worse.

[davexnet]

I had completely forgotten about the field order; somewhere in the back of my mind,
I reconciled the back and forth as a side effect of the field repetitions. Of course,
as soon as you look again at figure 3 in the article, you see the bad assumption.
Thanks for pointing it out!

Is assumeTFF() required before TFM().Tdecimate() or Telecide().Decimate(),
or do those functions figure it out themselves?

[Guest]

Is assumeTFF() required before TFM().Tdecimate() or Telecide().Decimate(),
or do those functions figure it out themselves? It all depends on whether the source filter reports the field order correctly to Avisynth. Filters typically believe what Avisynth tells them. The current version of DGDecNV for example correctly reports it so there is no need for an assume call. If there is any doubt it is safest to determine the field order by inspection and ensure that it is set correctly using an assume call.

[WorBry]

.... So you are seeing DGAVCDec failing to decode PAFF correctly here, as is well known.

You'll have to use a different source filter for PAFF. Naturally, I would suggest DGDecNV, which I have tested on your sample and found to be correct for these streams.

BTW, I have a version of DGAVCDec using an updated version of libav that doesn't show these particular artifacts. I won't release it, however, because that version of libav introduces other problems and I don't see a net gain. If DirectShowSource() is finding a good decoder as you suggest, then obviously that is a solution for you, no?

Having just purchased a Canon HF M400 AVCHD camcoder, which like the HG10 records 30PF and 24PF as progressive segmented frames (PsF) in a 60i wrapper, I'm facing the same considerations - and only now recall this being an issue several years back when I was considering upgrading to an AVCHD camcorder.

Unfortunately, DGDecNV is not an option as I do not have an NVidia graphics card - NVidia and I have permanently fallen-out after their infamous graphics chip defect trashed my laptop.

What appears to work well (so far) is to demux the mts stream, remux to mkv and load into AVISynth with ffms2. One quirk of libavcodec however is that it reports the field rate of interlace flagged streams as framerate and so (at default) ffms2 outputs at double frame-rate. So, it is necessary to set the fps numerator and denominator parameters appropriately i.e. fpsnum=30000, fpsden=1001 for 29.970 as explained in the ffms2 User Manual, under 'Known Issues'

https://ffmpegsource.googlecode.com/svn/trunk/doc/ffms2-avisynth.html

So, a bit tedious, but it seems to work OK - no artifacts as far as I can tell.

I do wonder though if there is any utility that can change the mts stream interlace flags to progressive, in a manner similar to Restream for MPEG2 sources?

[Guest]

Unfortunately, DGDecNV is not an option as I do not have an NVidia graphics card Not a problem, as I have made a version that does not require Nvidia. Look for the thread about DGDecIM in the DVD2AVI/DGIndex forum.

[WorBry]

Unfortunately, my CPU is an AMD :(

[Guest]

I believe the SW engine will work on any processor. If you'd like to try it I will be happy to send you a free license.

[WorBry]

Yes, thanks, I'd like to try it.

[Guest]

PM sent.