Log in

View Full Version : DVB-S H264 capture re-encoding to x264


Zag
5th January 2009, 01:34
I have some satellite h264 catpure that I would like to resize, de-interlace and re-encode to x264 to finally end up in a mkv container. I am using megui and I have run the initial .ts capture trough DGAVCdec108 and got the following dga log file.

Stream Type: Transport [188]
Profile: Main
Level: 4
Frame Size: 1440x1080
SAR: 4:3
Display Size: 1920x1080
Frame Rate: 29.970030 fps
Colorimetry: BT.709 [1]
Frame Structure: Fields (TFF)
Frame Type: not yet
Coded Number: 107394
Playback Number: 107394
Frame Repeats: 0
Field Repeats: 0
Bitrate: 3.948
Bitrate (Avg): 5.090
Bitrate (Max): 12.055
Audio Stream: 1123: AC3 3/2 48 384
Elapsed: 0:01:50
Remain: 0:00:00
FPS:
Info: Finished!


I have created an avs script but I am not sure if I am using the correct de-interlace and resizing filters. I am a bit lost on this issue there seems to be so many different way to de-interlace. Here is my script:

LoadPlugin("D:\Program Files\megui\dgavcdec\DGAVCDecode.dll")
loadplugin("D:\Program Files\megui\dgavcdec\Decomb.dll")
AVCSource("d:\capture\capture.dga")
Lanczos4Resize(1280,720)
fielddeinterlace()

what about using yadif? any other filter/plugin that I should be using?

Thanks

Guest
5th January 2009, 01:41
Never resize before deinterlacing.

You have to determine whether your source is interlaced or telecined before you make processing decisions. Which is it?

You have PAFF and may run into issues with DGAVCDec. DGAVCDecNV is much safer for PAFF streams.

Zag
5th January 2009, 01:56
Never resize before deinterlacing.

You have to determine whether your source is interlaced or telecined before you make processing decisions. Which is it?

You have PAFF and may run into issues with DGAVCDec. DGAVCDecNV is much safer for PAFF streams.



I thought DGAVCDecNV used CUDA and therefore required a nvidia card but I'll try it. How would I go about finding out whether it is telecined or interlaced? It's a tv show not a film.

Guest
5th January 2009, 02:02
DGAVCDecNV does indeed require an Nvidia card.

You may be OK with DGAVCDec, though. Let's see.

You need to do some homework before asking simple stuff like how to tell if your video is telecined or interlaced. Otherwise some zealous mod might think about forum rule 1. :)

http://forum.doom9.org/forum-rules.htm

Maybe the first couple questions here can help you with that specific question:

http://neuron2.net/faq.html

Let's assume you have interlaced video based on what you say. Then use the deinterlacer of your choice followed by resizing. FieldDeinterlace() is primitive but will get you going. Again, rule 1 would require you to do some homework because there is a lot of information about deinterlacers readily available. TDeint, LeakKernelDeint, and Yadif are popular choices, however.

Zag
5th January 2009, 02:16
I'll do some homework...Thanks for pointing me in the right direction...

Zag
5th January 2009, 04:12
One last question. I went through the steps to look at the video frame by frame as instructed in you faq. I tried two other known sources (a progressive and an interlaced) and it was very easy to see a a b b c c d d for progressive and a b c d e f for interlaced however the source I am trying to identify is a bit different. It seems progressive a a b b c c etc. but a lot of times the image doubles. In the attached screenshots there are two a and two b but the two b show a double image.

Guest
5th January 2009, 04:32
Those do not look like fields. They look like full frames, which means you did not follow my process for stepping through fields. What is the exact process you went through to make those screenshots?

Zag
5th January 2009, 04:51
I created an avs script and placed the following in it.

AVCSource("d:\capture\capture.dga")
AssumeTFF()
SeparateFields()

I dropped the avs in virtualdub and stepped through the frames. Then I just used snagit to take a couple of screenshot.

I did use DGIndex on the mpeg2 source I had.

Guest
5th January 2009, 04:54
As I said, your snapshots are full frames, which isn't possible if you have separated the fields.

To get to the bottom of it, please post a sample of your *unprocessed* MPEG2 source stream.

Zag
5th January 2009, 04:56
The stream is h264/AVC not mpeg2. Does that make a difference?

Guest
5th January 2009, 05:01
OK, then please post a sample of your *unprocessed* source transport stream.

Your snapshots are 971 x 549!

Zag
5th January 2009, 05:12
Here is a small clip. I used h264ts_cutter_v111 to cut it.

http://www.zshare.net/download/53700369c3a2a8df/

Zag
5th January 2009, 05:26
Sorry, didn't mean to cause more confusion. The screenshots are not true screenshot they are just screen captures using snagit to draw a square around the area to capture and saved as jpg files. Also I just realised that I actually used a different avs script to step through the frames in virtualdub that I had posted. I used the following:

DirectShowSource("d:\capture\capture.ts",fps=29.97,convertfps=true,audio=false)
AssumeTFF()
SeparateFields()

I have tried so many things tonight that I have lost track.

I apologize.

Guest
5th January 2009, 05:46
I don't know how you managed to make a blended screenshot. I didn't see any field blends when I stepped through your sample. Maybe you applied FieldDeinterlace().

Anyway, it's anamorphic 1440x1080 hard telecined 3:2 pulldown. This script seems to work fine on it:

AVCSource("E:\tmp\clip_cut.dga")
telecide(vthresh=30)
decimate()
lanczosresize(1920,1080)

There's some funniness in the middle but it may be just the funny pan they do there. See how it looks on the full movie.

Zag
5th January 2009, 06:19
Thanks for all your help. I went back and looked at all my avs script files I used and none have the FieldDeinterlace(). Must have been the DirectShowSource because I don't see it when using AVCSource. I do however see a lot of pixalation and what looks like wrong field order because of "backstep" frame when using AVCSource. Anyway, I have taken enough of your time. I will run your script overnight and see how things come out. Thanks again...

Guest
5th January 2009, 06:40
I do however see a lot of pixalation The blocking is in the source.

and what looks like wrong field order because of "backstep" frame when using AVCSource. That's not a technical term I am familiar with, nor do I understand why you are attributing it to AVCSource.