Log in

View Full Version : Alising after separate fields


FranceBB
15th May 2019, 21:33
Hi,
I have a rather nasty aliasing issue.
The troupe went out to shoot and I've got completely messed up levels (which I'm gonna adjust in encoding) and some pretty bad aliasing.
They shot in H.264 4:2:0 yv12 planar 8bit FULL HD 50fps progressive.
Since we internally work in XDCAM, I gotta encode it in MPEG-2 50 Mbit/s CBR 8bit 4:2:2 yv16 planar 25i.

Source:


General
Complete name : C:\Users\bucciantinif\Desktop\DJI_0015.MP4
Format : MPEG-4
Format profile : JVT
Codec ID : avc1 (avc1/isom)
File size : 106 MiB
Duration : 22 s 100 ms
Overall bit rate mode : Variable
Overall bit rate : 40.2 Mb/s
Encoded date : UTC 2019-05-14 15:01:42
Tagged date : UTC 2019-05-14 15:01:42
Comment : 0.9.138
©gpt : -174.90
©gyw : +83.20
©grl : +0.00

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 1 Ref Frames
Format settings, CABAC : Yes
Format settings, RefFrames : 1 frame
Format settings, GOP : M=1, N=8
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 22 s 100 ms
Bit rate mode : Variable
Bit rate : 40.0 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 50.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.386
Stream size : 106 MiB (100%)
Title : DJI.AVC
Language : English
Encoded date : UTC 2019-05-14 15:01:42
Tagged date : UTC 2019-05-14 15:01:42
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : mp4a-40-2
Duration : 22 s 80 ms
Bit rate mode : Constant
Bit rate : 64.0 kb/s
Nominal bit rate : 128 kb/s
Channel(s) : 1 channel
Channel positions : Front: C
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 173 KiB (0%)
Title : DJI.AAC
Language : English
Encoded date : UTC 2019-05-14 15:01:42
Tagged date : UTC 2019-05-14 15:01:42


As always, I have just divided in fields the 50fps progressive in order to get 25i, however I get a lot of aliasing as soon as I divide in fields.


video=FFVideoSource("DJI_0015.MP4")
audiook=FFAudioSource("DJI_0015.MP4")
audio=MergeChannels(audiook, audiook, audiook, audiook)
AudioDub(video, audio)

ResampleAudio(48000)
Normalize(0.22)
ConvertAudioTo24bit()
Limiter(min_luma=16, max_luma=235, min_chroma=16, max_chroma=240)

assumeTFF()
separatefields()
selectevery(4,0,3)
weave()
Converttoyv16(matrix="Rec709", interlaced=true)


So I've tried to use a ridiculous amount of antialiasing on the source, but it didn't help much, however as soon as I blurred the hell out of the source, the output has got way less aliasing:


video=FFVideoSource("DJI_0015.MP4")
audiook=FFAudioSource("DJI_0015.MP4")
audio=MergeChannels(audiook, audiook, audiook, audiook)
AudioDub(video, audio)

Blur(1.58)

ResampleAudio(48000)
Normalize(0.22)
ConvertAudioTo24bit()
Limiter(min_luma=16, max_luma=235, min_chroma=16, max_chroma=240)

maa2(mask=1, chroma=true, ss=2.0, aa=280, show=0)

assumeTFF()
separatefields()
selectevery(4,0,3)
weave()
Converttoyv16(matrix="Rec709", interlaced=true)



ffmpeg.exe -hwaccel dxva2 -i "AVS Script.avs" -threads 28 -pix_fmt yuv422p -vcodec mpeg2video -s 1920:1080 -aspect 16:9 -flags +ildct+ilme -r 25 -b:v 50000k -minrate 50000k -maxrate 50000k -bufsize 36408333 -acodec pcm_s24le -ar 48000 -g 12 -bf 2 -profile:v 0 -level:v 2 -color_range 1 -color_primaries 1 -color_trc 1 -colorspace 1 -f mxf "output.mxf"

bmxtranswrap.exe -p -y 10:00:00:00 -t op1a -o "final.mxf" "output.mxf"

PAUSE


Why is that? Is there a way I can divide in fields and avoid to get aliasing like I've got in this example? Whenever I have to encode in interlaced, I generally use that script.

You'll find three files:

1) Source
2) Encode
3) Encode with Antialiasing and Blur

https://we.tl/t-MvZmS3KNPr

wonkey_monkey
15th May 2019, 21:55
The correct thing to do is apply a vertical blur before separating the fields (maybe after converting to YV24, but it probably won't matter):

blur(0, 1) # not sure if this is mathematically the correct value, though

On a CRT, not applying the blur would cause flickering (as on the older VHS transfer of Octopussy, which I remember for some reason) when playing back interlaced video, and of course you get a similar effect when you try to play it back through a deinterlacer. Vertical blurring is the fix.

Cary Knoop
15th May 2019, 21:56
There is already aliasing in the source, it's recorded way too sharp (and the exposure is practically foobar).

FranceBB
17th May 2019, 15:46
The correct thing to do is apply a vertical blur before separating the fields

Got it.

On a CRT, not applying the blur would cause flickering when playing back interlaced video, and of course you get a similar effect when you try to play it back through a deinterlacer. Vertical blurring is the fix.

It makes sense. I did it and it fixed the problem.
Unfortunately we're tied to interlace 'cause we gotta air in interlaced so I don't have much choice.
Alright, thank you. ^_^

frank
22nd May 2019, 14:13
As I can see yor source is already progressive 50fps.
You only have to choose every 2nd frame to get 25 fps.

Edit: ChangeFPS()
or
SelectEven() / SelectOdd()

and you'll get 25 fps without any artifacts.
Then encode.

StainlessS
22nd May 2019, 14:31
But that would entail losing temporal information, guess it depends upon what you want.

For myself, I think I would go with Frank's suggestion. [But I'm not using any CRT]

FranceBB
22nd May 2019, 21:27
As I can see yor source is already progressive 50fps.
You only have to choose every 2nd frame to get 25 fps.

ConvertFPS()
or
SelectEven() / SelectOdd()

and you'll get 25 fps without any artifacts.
Then encode.

No way. Dropping 50fps to 25fps progressive and encoding it as it is would create a 25fps progressive flagged as interlaced stream which would stutter as half the framerate is lost.
Please note that 25i (25 interlaced) is actually as 50fps progressive, not 25fps progressive.


For myself, I think I would go with Frank's suggestion.


That would be unacceptable as it would stutter.
The only things we air as progressive flagged as interlaced 25fps are movies and tv series, but that's because they are originally 23.976fps so we speed them up by 4% and we pitch adjust them.
Any other thing is truly interlaced, so 25i, so 50fps as the TVs you all have at home are progressive and they bob an interlaced signal, thus producing 50fps progressive, which is why whenever you watch news, sports and other events they are so smooth on TV. ;)

In other words, dividing in fields is the way to go and blurring vertically as wonkey_monkey suggested fixed the aliasing problem.

FYI
Just a side note: if you drop fps from 50 to 25 and you encode it as progressive, you would still have to flag it as interlaced 'cause otherwise broadcast playout ports won't accept the stream.
So... what happens when the signal gets to your TV? Simple. Your TV has no idea whether the signal is really interlaced or not, it just blindly trusts the flag, therefore it bobs the stream (which is instead progressive) and what you get is stuttering (like the one you get with movies) AND aliasing. ;)


But I'm not using any CRT


Neither am I, everything is digital now, but you still have to air in interlaced (or at least flag the stream as interlaced) because it's still the standard, just like you do with DVDs.
Luckily H.265 HEVC brought end to interlaced and 4K UHD contents are aired with 50fps progressive, which is the way forward, also 'cause TVs nowadays are all progressive and they bob-deinterlace interlaced signals. ;)

lansing
22nd May 2019, 21:49
Since we internally work in XDCAM, I gotta encode it in MPEG-2 50 Mbit/s CBR 8bit 4:2:2 yv16 planar 25i.


Why is that? I don't understand.

Cary Knoop
22nd May 2019, 22:01
Why is that? I don't understand.
Because broadcasting is still living in the stone age. :)

FranceBB
23rd May 2019, 20:36
Because broadcasting is still living in the stone age. :)

Precisely...

Why is that? I don't understand.

Lansing, our old playout ports only accept IMX files for SD contents and XDCAM files for FULL HD contents.

If you are not familiar with those standards, they are basically:

https://i.imgur.com/yiuv2GI.png

https://i.imgur.com/uEbNSZ8.png


Luckily, the advent of 4K UHD brought a bit of fresh air to the old technical specifications, otherwise H.265 HEVC, 10bit and progressive would have never taken place.
I can't tell you how many issues we're facing to encode new contents in MPEG-2 nowadays, in 2019, while it's not even actively supported anymore...
Having two Xeon CPU 28c/56th, 64 GB of RAM DDR4, an NVIDIA Quadro M4000 and seeing x262.exe/ffmpeg.exe encode in MPEG-2 using only Core0 the uncompressed A/V stream generated by Avisynth 'cause the implementation is old and single-thread, is deeply upsetting...

Motenai Yoda
23rd May 2019, 21:19
As I can see yor source is already progressive 50fps.
You only have to choose every 2nd frame to get 25 fps.

ConvertFPS()
or
SelectEven() / SelectOdd()

and you'll get 25 fps without any artifacts.
Then encode.

Not ConvertFPS() But ChangeFPS()
ConvertFPS() blend, ChangeFPS() drop or duplicate frames

frank
24th May 2019, 10:06
Exactly! My mistake...
You can encode 1080 as 25i! (25 interlaced frames/s or 50 fields/s)
All PAL TV movies are progressive stuff. The TV stations have to encode as 25i for 1080.

But I am viewing german TV in 720p50. Sport life TV is very good. No need for 1080 interlaced HD crap.