interlaced SD&HD PAL&NTSC 4:2:0 mpeg2/dv/h264 content has chroma upsample error on decklink consumer 422 +workaround

[walterav1984]

Problem: During the playback of Red and or Blue high saturated colors and or contrast within interlaced motion area's in SD PAL mpeg2/h264/dv video content which uses yuv interlaced 4:2:0 chroma sampling, there is visible artifacts/distortion like jaggy edges especially moving Red/Orange color contrast on blacks during playback on a SDL/Decklink consumer connected to CRT SD monitor. This might is also the case for NTSC & HD content, but I don't have interlaced HD broadcast CRT monitor to check (HDMI LCD).

melt -profile dv_pal sdinterlaced420mpeg2dvh264examplevideofile -consumer decklink #plays incorrect with chroma artifacts

Analyses: From video file to decklink output the following has to take place, detect field order of file and if necessary change it to field order of SDI decklink output. Followed by the detection of chroma sampling level 4:2:0 and upscale it to decklink native 4:2:2 (possible a lot more routines happen and maybe in different order). The interlacing and field order is detected correctly for (mpeg2dvd upper field & DV lower field), because motion with less saturation/contrast is playback correct and smooth. But the problem is chroma upscaling probably happens "progressive" instead of "interlaced". Its indeed C.U.E. (chroma upsampling error) because it is mostly visible in the motion affected areas of footage, on contrary (ICP) interlaced chroma problem is mostly visible in static areas of the footage, see here for explanation:

http://web.archive.org/web/20060719025947/http://www.hometheaterhifi.com/volume_8_2/dvd-benchmark-special-report-chroma-bug-4-2001.html https://trac.ffmpeg.org/ticket/4168

FIX/Workaround? As of my understanding "melt" is build around ffmpeg, the following ffmpeg filter libswscale which is also part of melt can fix this in ffmpeg with "-vf scale=interl=1" and choosing a 422 or 4:4:4 output video codec . Investigation by ddennedy / max-verem shows that this interlaced aware code in the melt scaler equivalent is missing.

Workaround PRECONVERT footage: ffmpeg -f mpeg -i bug.vob -vf scale=interl=1 -c:v prores test.mov melt -profile dv_pal test.mov -consumer decklink #plays correct on CRT monitor no chroma errors

Workaround LIVE/REALTIME streams: ffmpeg -re -i pipe:0 -vf scale=interl=1 -vcodec rawvideo -pix_fmt uyvy422 -acodec copy -f avi - | melt -profile dv_pal pipe:0 -consumer decklink As a example source to ffmpeg pipe:0 I used "dvsink-command" which gets a DV 4:2:0 PAL video stream from "dvswitch" video mixer on the network. I do have to call this above mentioned workaround command in a seperate bashscript to "dvswitch-command -h ipadress -p port ffmpeg420i422.sh" otherwise execvp or getopt errors from dvsink-command when parsing the arguments off the command line.

Concluding&Fix: FFmpeg needs to be told/forced with "-vf scale=interl=1" and choosing a 422 or higher pixelformat/videocodec to fix correct upscaling of interlaced chroma 4:2:0 to 4:2:2. For m(e)lt there is a workaround for now until interlaced aware chroma scaling code is ported and a working patch is available @max-verem commit 934744c branch :max-verem:sliced_pixfmt3 https://github.com/mltframework/mlt/pull/191/commits/934744c0fdf07da2322ebeaf5193bbfde967bb79

Software: OS ubuntu: 16.04.1 amd64 kernel 4.4.0.xxx M(e)LT version: ubuntu repository 6.0.0 & Shotcut 17.01 binaries 6.5.0 BMD Desktop Video Driver: 10.8.4 and 10.6.2/10.7.0

Hardware: Intensity Pro 4K, analog SD component to SONY PVM20ME4 crt monitor Decklink SDI 4K, SDI SD to Barco crt monitor

Example Video: intro-clean.m2v "dvd copy tff example" intro-clean.m2v.zip

clean.dv "original lff example" https://github.com/walterav1984/dvpause/blob/master/videos/clean.dv

[max-verem]

But my last concern is NTSC needed sometimes "reverse" filter to be played back correctly without chroma upsampling error. So melt is sometimes not able to detect interlacing or use field order correctly for NTSC that might be the different bug.

if you see wrong field order in NTSC mode during playback of ntsc clip that mean problem could be in consumer_decklink.c because it shift non-progressive frame for all output mode, because of internally IIRC it is lower-field-first. That correct for all except NTSC... i will prepare a fix soon...

This flow will only work if PAL or NTSC clips are lowerfield first DV files.

DV is lower-field-first for PAL and NTSC...

ntsc422correct411dv.dv #ntsc example plays !!!incorrect!!! on firewire but correct using melt (which needed + frame->interlaced_frame = 1 so something is not totally correct...)

that mean: it is wrongly converted previously + bug with fields order for NTSC (wrong field order + unneeded line shift give positive output)

[walterav1984]

Indeed negative*negative=positive, you are right I'm probably fighting a bug that was not in mlt 6.0.0 from ubuntu repo which can play DV ntsc 411 lowerupperfield perfect to decklink ntsc consumer, but with this newer 6.5.x version I have to make DV ntsc 411 upperfield (shift field order) to playback correct on decklink consumer. Or have to reverse playback.

Strange thing is DV pal 420 lowerfield plays correct with your patch #182 code, but upperfield rawvideo yuv420p pal stutters, but mpeg2 upperfield 4:2:0 plays fine(very contradicting...). The same for uyvy422 NTSC upperfield which playback fine with BlackMagic Mediabridge but stutters in melt unless I make it lowerfield.

[max-verem]

Lets continue... here is patch:

diff --git a/src/modules/decklink/consumer_decklink.cpp b/src/modules/decklink/consumer_decklink.cpp
index 0d01e91..cc8a6ea 100644
--- a/src/modules/decklink/consumer_decklink.cpp
+++ b/src/modules/decklink/consumer_decklink.cpp
@@ -575,7 +575,7 @@ protected:
                                        ssize_t size = stride * height;

                                        // convert lower field first to top field first
-                                       if ( !progressive )
+                                       if ( !progressive && bmdUpperFieldFirst == m_displayMode->GetFieldDominance() )
                                        {
                                                arg[1] += stride;
                                                size -= stride;

that should fix line shift for NTSC

If it fix reference NTSC video playback on NTSC output, then find a samples that plays correctly on other devices but not with MLT.

[walterav1984]

Fix #182 + frame->interlaced_frame = 1; + if ( !progressive && bmdUpperFieldFirst == m_displayMode->GetFieldDominance() ) makes all test footage from DV(lff), MPEG2(tff), rawvideo yuv420p(lff=pal?tff=ntsc), uyvy422tff behave consistent/correct on each CRT Monitor output method:

"MLT+decklink(fix #182 + 2 additions" Original MPEG2 tff PAL intro-clean.m2v plays correct without chroma upsample errors or field stutter. Later added clean.dv lff PAL plays correct without chroma upsample error or field stutter, also a correct cleanntscb.dv lff 4:1:1 NTSC plays correct. Rawvideo PAL / NTSC uyvy422 created for BMD mediaexpress also play correct. Lowerfield first rawvideo yuv420p also playback correctly thanks to your code.

"BlackMagicDesign media express" Only rawvideo uyvy422 (tff PAL & NTSC) footage that plays correctly in this program also playback correctly in melt. This is used as a reference pathway to check playback of correct NTSC & PAL footage, without melt or other picture affecting routines.

"DV-in camcorder to S-video out" Both clean.dv (lff PAL) and the NTSC version cleanntscb.dv (lff) play correctly using the program "test-dv" from libiec61883 examples to DV-in of multi format SONY camcorder and playback well on S-video connected CRT monitor. Both files playback correct using the DV path, but also playback correct in melt. ffmpeg -r 29.97 -i clean.dv -filter:v "scale=interl=1,crop=in_w:480:0:48,fieldorder=bff,setdar=4:3" -acodec copy -target ntsc-dv cleanntscb.dv This pathway is used as a reference platform for playback of correct DV lower field 4:1:1 NTSC & 4:2:0 PAL footage.

Also grassvalley NTSC test clips(DV25-50 MPEG IMX) are tested correctly including motion. http://www.gvgdevelopers.com/concrete/products/k2/test_clips/

To summarize allmost all seems fixed!

Except...

Rawvideo yuv420p PAL / NTSC only playback lff first is this by design or my bad ffmpeg conversion? Incorrect play means wrong field order stutter and softening image means half wrong field stutter... ffmpeg -i clean.dv -c:v rawvideo -pix_fmt yuv420p -f avi clean420to420yuvpal2.avi #plays correct adding -vf fieldorder=tff #plays incorrect, also using bff is still softening the image.

ffmpeg -r 29.97 -i clean.dv -vf crop=in_w:480:0:48,scale=interl=1,setdar=4:3 -c:v rawvideo -pix_fmt yuv420p -acodec copy -f avi clean420to420yuvntsc.avi #plays correct adding -vf fieldorder=tff #plays incorrect, also using bff is still softening the image.

[walterav1984]

BTW no HD interlaced no SD/HD progressive 4:2:0 footage has been tested, is this needed or not affected by @max-verem his code as final thought?

Interlaced 4:2:0 HD 1080i50 is also affected by @max-verem his code. I cannot judge exactly but melt -profile atsc_1080i_50 h264broadcast.ts -consumer decklink and using the decklink HD > SD internal downconverter to CRT monitor gives far better anti-aliasing type edges than without @max-verem his code.

Native HD interlaced 4:2:0 playback on a HDMI monitor does n't look little different it is less saturated and it fixes orange artifacts like in SD footage. I used a kitchen cooking television show and as soon as a orange carrot got sliced in peaces @max-verem his code fixed the chroma upsample error artifacts. PS I'm comparing against ubuntu repo 6.0.0 melt version.

[walterav1984]

Since C.U.E. looks visually fixed, I found HD footage that shows exaggerated I.C.P. after C.U.E. is applied. This applies to static (non motion) heavy saturated color area's in the footage, these parts show increased lines/macroblocking since the C.U.E. was applied. I will add screenshots later if I found some copyright free examples.

[max-verem]

I.C.P. problem could arise because of i omitted setting src_v_chr_pos values for vertical chroma interpolation...

anyway, here is some progress, but a lot of other issues discovered:

• NTSC field order
• melt 6.5.0 hangs on certain .mp4 video file (https://github.com/mltframework/mlt/issues/166)

i will try to provide two new branch for testing...

[max-verem]

Please try newer version of interlaced 4:2:0 processing (https://github.com/max-verem/mlt/tree/yuv420_20160206):

git clone -b yuv420_20160206 https://github.com/max-verem/mlt.git

his version should fix I.C.P. issue.

original vf_scale.c DO NOT properly set vertical chroma position for fields in interlaced picture. issue and solution been sent to ffmpeg-devel http://ffmpeg.org/pipermail/ffmpeg-devel/2017-February/206749.html

this branch has relation only to 4:2:0 problem but not to interlacing fix and rawvideo export either. so no need to notify about wrong interlaced field order on SDI or NDI outputs...

[max-verem]

For field order testing for NTSC mode, please check https://github.com/max-verem/mlt/commits/interlaced_output_20170206

[walterav1984]

Fixed C.U.E & I.C.P :+1: for HD 1080i50 4:2:0 footage using commit 4ae2366 from: git clone -b yuv420_20160206 https://github.com/max-verem/mlt.git

Playback still freezes using this example video after ~100 frames on Decklink consumer (SDL consumer is not freezing). I have sent you this exact same example video to test.

[walterav1984]

About NTSC, I tested a49c4ad from "interlaced_output_20170206" it behaves similar and correct as earlier #182 + 2patches, except one issue relating to yuv420p footage which looks better on #182 + frame->interlaced_frame = 1; + if ( !progressive && bmdUpperFieldFirst == m_displayMode->GetFieldDominance() ) mentioned 7 posts earlier.

The footage in concern is made with ffmpeg in following way: ffmpeg -r 29.97 -i clean.dv -vf crop=in_w:480:0:48,scale=interl=1,setdar=4:3 -c:v rawvideo -pix_fmt yuv420p -acodec copy -f avi clean420to420yuvntsc.avi Looks "best" with #182 + 2 patches, with a49c4ad it looks bad like C.U.E is here again.

ffmpeg -r 29.97 -i clean.dv -vf crop=in_w:480:0:48,scale=interl=1,fieldorder=bff,setdar=4:3 -c:v rawvideo -pix_fmt yuv420p -acodec copy -f avi clean420to420yuvntscb.avi Looks "softer" compared to former video without -vf fieldorder= but plays with #182 + patches and looks similar soft in a49c4ad.

ffmpeg -r 29.97 -i clean.dv -vf crop=in_w:480:0:48,scale=interl=1,fieldorder=tff,setdar=4:3 -c:v rawvideo -pix_fmt yuv420p -acodec copy -f avi clean420to420yuvntsct.avi Looks bad stutters in #182+ 2 patches, looks similar bad and stutters in a49c4ad.

[max-verem]

Playback still freezes using this example video after ~100 frames on Decklink consumer (SDL consumer is not freezing). I have sent you this exact same example video to test.

that is decklink related issue - too high delay for getting frame... i will try to find workaround. but:

melt -debug -profile dv_pal /mnt/mlt/klokhuis-NPO-3-HD.ts -consumer decklink:3 preroll=12 realtime=-4

works without hang

[max-verem]

BTW, using this approach for converting 4:2:0 rises some warning:

YUV color matrix differs for YUV->YUV, using intermediate RGB to convert

i suspect it will eat a lot of cpu time to gain high quality, so after getting global slices, i will try to enable parallel slicing processing...

[max-verem]

The footage in concern is made with ffmpeg in following way: ffmpeg -r 29.97 -i clean.dv -vf crop=in_w:480:0:48,scale=interl=1,setdar=4:3 -c:v rawvideo -pix_fmt yuv420p -acodec copy -f avi clean420to420yuvntsc.avi Looks "best" with #182 + 2 patches, with a49c4ad it looks bad like C.U.E is here again.

resulting file clean420to420yuvntsc.avi will contains a progressive frame. that cause all misbehavior

use:

ffmpeg -i clean420to420yuvntsc.avi -vf showinfo -f null -y foo

to check if output is interlaced and how interlaced...

[max-verem]

there is some performance tests.

HD source (1080i50)

melt -profile atsc_1080i_50 HD.ts -consumer null

timings. new(64) mean newer method with 64 pixel wide slice

                          4CPU
original:   11311 us
new(64):    31620 us   10019 us
new(128):   21399 us    7049 us
new(256):   16932 us    5363 us
new(512):   14607 us    4484 us
new(1920):  12041 us    6078 us

SD source (720x576@25)

melt -profile dv_pal BNC124626.mov -consumer null

results:

                          4CPU
original:   2569 us
new(64):    7047 us    2231 us
new(128):   3605 us    1569 us
new(256):   3583 us    1362 us
new(512):   3187 us    1405 us
new(720):   2859 us    1822 us

as seen some performance gain happens.

[walterav1984]

YUV color matrix differs for YUV->YUV, using intermediate RGB to convert

Does this RGB processing only apply to realtime downconversion of HD 4:2:0 footage > SD decklink consumer or also from SD 4:2:0 footage > SD decklink consumer? CasparCG also uses RGB444 8bit colorspace, I though melt only uses RGB depending on the filters/processing, otherwise yuv as long as posible.

But since the RGB routine came across, I might as well test CasparCG tonight using the following AMCP command which does the same ffmpeg upsampling realtime on inputs.

play 1-1 chromaerrorfootage FILTER scale=interl=1,format=pix_fmts=uyvy422

This "timings.new(64-1920)" code is probably in your new "major_fixes_20170208_est". I still have to test this new code tonight it looks alot faster with correct multithreading.

Using ffmpeg to do the realtime chroma upsampling and piping to melt takes 4000 frames to reach 25FPS on a I3-4170 (8gb ram), with only 130% cpu usage of 400% (dualcpu + ht), ffmpeg uses 80% melt 40%.

[ddennedy]

YUV color matrix differs for YUV->YUV, using intermediate RGB to convert

MLT asked libswscale for a YUV pixel format conversion or scaling operation where the source and destination YUV colorspaces differ. For example, Rec 709 to 601. Libswscale is reporting that it is going to accomplish this by converting to RGB and then back, perhaps because that is the only way it can do that today (or this version).

[walterav1984]

For example, Rec 709 to 601

Probably means that its only for the HD (rec 709) to SD (rec 601) decklink downconversion, but SD footage stays YUV as long as not any other colorspace translations has to be done for the SD output?

[walterav1984]

Quick comparison of CasparCG HD footage > SD decklink consumer shows around 250% of 400% CPU usage on E5472 Quadcore, when using ffmpeg 4:2:0>4:2:2 upsampling. Without upsampling CPU usage is about 180%. Good thing about CasparCG is that it re-interlaces the footage so motion looks smoother, very bad thing is that it has very low quality scaling and introduces alot of aliasing edges on non straight lines. Also SD footage on SD consumer looks more pixelated in high saturated area's.

You haven't asked for it yet, but I tried to compile the new "major_fixes_20170208" & "major_fixes_20170208_est" branches but the give compile error about ".step" not available.

producer_avformat.c:1319:53: error: ‘AVComponentDescriptor {aka const struct AVComponentDescriptor}’ has no member named ‘step’ : ( ( i ) ? 0 : slice_x * ctx->src_desc->comp[0].step ); ^ producer_avformat.c:1323:53: error: ‘AVComponentDescriptor {aka const struct AVComponentDescriptor}’ has no member named ‘step’ : ( ( i ) ? 0 : slice_x * ctx->dst_desc->comp[0].step )

In the previous testing of the HD interlaced 4:2:0 upsampling I mainly tested on a HDMI HD monitor, that looked good since both C.U.E. and finally I.C.P. were fixed but realtime HD to SD downconversion was just unimaginable. And yet we have another test-case with... new artifacts/errors ;-).

You might have noticed yourself but downconversion of HD 1080i footage on a SD decklink consumer introduces another new kind of artifact: The first error I noticed was some kind of dithering (camera gain noise)&macro blocking in darker smooth/even colored areas like the girls dark blue&gray dress or her face. The original HD footage with decklink consumer and profile atsc_1080i_50 also looks worse on the dark blue&grey dress.

Lack of re-interlacing, some filmic 25p motion look instead of smooth motion?

BTW adding real_time=-4 instead of realtime=-4 keeps the video playing, albeit non realtime but atleast it won't freeze anymore.

[max-verem]

@walterav1984 could you try this branch https://github.com/max-verem/mlt/tree/major_fixes_20170208_est and run bash script for playback testing:

#!/bin/bash

export MLT_AVFORMAT_SLICED_PIXFMT=1
export MLT_AVFORMAT_THREADS=4

melt -profile atsc_1080i_50 /usr/local/src/2017-02-07/klokhuis-NPO-3-HD.ts -consumer decklink:0 sliced_swab=1

that branch unifies slicing processing making it available for all source format, so 4:2:2 source would also converted throw this mechanizm

[max-verem]

producer_avformat.c:1319:53: error: ‘AVComponentDescriptor {aka const struct AVComponentDescriptor}’ has no member named ‘step’ : ( ( i ) ? 0 : slice_x ctx->src_desc->comp[0].step ); ^ producer_avformat.c:1323:53: error: ‘AVComponentDescriptor {aka const struct AVComponentDescriptor}’ has no member named ‘step’ : ( ( i ) ? 0 : slice_x ctx->dst_desc->comp[0].step )

it present: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/pixdesc.h;h=a8ad588913cf199b437b9c9e876759a60a75c954;hb=HEAD#l41

i am using git head for testing... you'll have to build ffmpeg from source...

which version of FFMPEG you are using?

[walterav1984]

FFmpeg version 2.8.10 from the ubuntu 16.04 repo, do you happen to have a build script that automatically links the melt compile to self compiled ffmpeg version?

[max-verem]

try to replace:

ctx->src_desc->comp[0].step

with

(ctx->src_desc->comp[0].step_minus1 + 1)

[walterav1984]

Compiling the "major_fixes_20170208_est" branch with (ctx->src_desc->comp[0].step_minus1 + 1) for older ffmpeg makes the CPU I3-2100 run melt smooth both on "dv_pal_wide" and "atsc_1080i_50" with no frame drops using both HD 1080i50 h264 transport stream as content on decklink output :+1: .

CPU usage was around 30% of 400% with SD footage on SD consumer and was around 200% of 400% using HD> HD and 220% when downconverting to SD.

Sharpness and aliasing are far better looking than CasparCG, I do have to test colour and motion.

[walterav1984]

Older CPU Xeon E5472 is also capable of realtime playback without freezing anymore on both native "atsc_1080i_50" and "dv_pal_wide" using the same 1080i_50 h264 transport stream sample footage we share.

so 4:2:2 source would also converted throw this mechanizm

I don't have any 1080i 4:2:2 example videos to test at least not until a week, but this slicing on 4:2:2 footage will improve CPU utilization and increase FPS/realtime capabilities or will it also affect chroma upsampling?

Should we test some native progressive footage 1080p50 4:2:0 h264 as well, which won't play realtime (only first 2 seconds) with "atsc_1080p_50" (320% of 400% cpu usage) but does when using "atsc_1080i_50" / "dv_pal_wide"(180% of 400% cpu). It shows however in debug log a alternating detection of its progressive=0/1 state see logs.

(log is from dv_pal_wide profile)

`producer_get_image:1593: top_field_first=0, progressive=0, consumer_deinterlace=1, consumer_tff=0, meta.top_field_first=0, meta.swap_fields=0 producer_get_image:1947: DUR(convert_image)=8226 us producer_get_image:2027: DUR(producer_get_image)=16208 us producer_get_image:2036: top_field_first=0, progressive=1, consumer_deinterlace=1, consumer_tff=0, meta.top_field_first=0, meta.swap_fields=0 mlt_consumer.c:1558: ENTER62 mlt_consumer.c:676: ENTER mlt_consumer_get_frame:724: CONSUMER {progressive=0, top_field_first=0}

producer_get_image:1593: top_field_first=0, progressive=0, consumer_deinterlace=1, consumer_tff=0, meta.top_field_first=0, meta.swap_fields=0 producer_get_image:1947: DUR(convert_image)=6918 us producer_get_image:2027: DUR(producer_get_image)=12968 us producer_get_image:2036: top_field_first=0, progressive=1, consumer_deinterlace=1, consumer_tff=0, meta.top_field_first=0, meta.swap_fields=0 mlt_consumer.c:1558: ENTER63 mlt_consumer.c:676: ENTER mlt_consumer_get_frame:724: CONSUMER {progressive=0, top_field_first=0}

producer_get_image:1593: top_field_first=0, progressive=0, consumer_deinterlace=1, consumer_tff=0, meta.top_field_first=0, meta.swap_fields=0 producer_get_image:1947: DUR(convert_image)=9554 us producer_get_image:2027: DUR(producer_get_image)=17394 us producer_get_image:2036: top_field_first=0, progressive=1, consumer_deinterlace=1, consumer_tff=0, meta.top_field_first=0, meta.swap_fields=0 mlt_consumer.c:1558: ENTER64 mlt_consumer.c:676: ENTER mlt_consumer_get_frame:724: CONSUMER {progressive=0, top_field_first=0}`

(log is from atsc_1080i_50 profile).

` producer_get_image:1593: top_field_first=0, progressive=0, consumer_deinterlace=0, consumer_tff=0, meta.top_field_first=0, meta.swap_fields=0 producer_get_image:1947: DUR(convert_image)=21260 us producer_get_image:2027: DUR(producer_get_image)=28403 us producer_get_image:2036: top_field_first=0, progressive=1, consumer_deinterlace=0, consumer_tff=0, meta.top_field_first=0, meta.swap_fields=0 mlt_consumer.c:1558: ENTER mlt_consumer.c:676: ENTER mlt_consumer_get_frame:724: CONSUMER {progressive=0, top_field_first=0}

producer_get_image:1593: top_field_first=0, progressive=0, consumer_deinterlace=0, consumer_tff=0, meta.top_field_first=0, meta.swap_fields=0 producer_get_image:1947: DUR(convert_image)=19462 us producer_get_image:2027: DUR(producer_get_image)=32456 us producer_get_image:2036: top_field_first=0, progressive=1, consumer_deinterlace=0, consumer_tff=0, meta.top_field_first=0, meta.swap_fields=0 mlt_consumer.c:1558: ENTER mlt_consumer.c:676: ENTER mlt_consumer_get_frame:724: CONSUMER {progressive=0, top_field_first=0}

producer_get_image:1593: top_field_first=0, progressive=0, consumer_deinterlace=0, consumer_tff=0, meta.top_field_first=0, meta.swap_fields=0 producer_get_image:1947: DUR(convert_image)=19761 us producer_get_image:2027: DUR(producer_get_image)=28224 us producer_get_image:2036: top_field_first=0, progressive=1, consumer_deinterlace=0, consumer_tff=0, meta.top_field_first=0, meta.swap_fields=0 mlt_consumer.c:1558: ENTER mlt_consumer.c:676: ENTER mlt_consumer_get_frame:724: CONSUMER {progressive=0, top_field_first=0}

producer_get_image:1593: top_field_first=0, progressive=0, consumer_deinterlace=0, consumer_tff=0, meta.top_field_first=0, meta.swap_fields=0 producer_get_image:1947: DUR(convert_image)=17370 us producer_get_image:2027: DUR(producer_get_image)=26318 us producer_get_image:2036: top_field_first=0, progressive=1, consumer_deinterlace=0, consumer_tff=0, meta.top_field_first=0, meta.swap_fields=0 mlt_consumer.c:1558: ENTER mlt_consumer.c:676: ENTER mlt_consumer_get_frame:724: CONSUMER {progressive=0, top_field_first=0}

producer_get_image:1593: top_field_first=0, progressive=0, consumer_deinterlace=0, consumer_tff=0, meta.top_field_first=0, meta.swap_fields=0 producer_get_image:1947: DUR(convert_image)=23019 us producer_get_image:2027: DUR(producer_get_image)=29122 us producer_get_image:2036: top_field_first=0, progressive=1, consumer_deinterlace=0, consumer_tff=0, meta.top_field_first=0, meta.swap_fields=0 mlt_consumer.c:1558: ENTER mlt_consumer.c:676: ENTER mlt_consumer_get_frame:724: CONSUMER {progressive=0, top_field_first=0}

producer_get_image:1593: top_field_first=0, progressive=0, consumer_deinterlace=0, consumer_tff=0, meta.top_field_first=0, meta.swap_fields=0 producer_get_image:1947: DUR(convert_image)=20099 us Current Position: 200 producer_get_image:2027: DUR(producer_get_image)=26515 us producer_get_image:2036: top_field_first=0, progressive=1, consumer_deinterlace=0, consumer_tff=0, meta.top_field_first=0, meta.swap_fields=0 mlt_consumer.c:1558: ENTER mlt_consumer.c:676: ENTER mlt_consumer_get_frame:724: CONSUMER {progressive=0, top_field_first=0}

producer_get_image:1593: top_field_first=0, progressive=0, consumer_deinterlace=0, consumer_tff=0, meta.top_field_first=0, meta.swap_fields=0 [consumer decklink] renderVideo:641: ScheduleVideoFrame failed, hr=80000009 producer_get_image:1947: DUR(convert_image)=18854 us producer_get_image:2027: DUR(producer_get_image)=26601 us producer_get_image:2036: top_field_first=0, progressive=1, consumer_deinterlace=0, consumer_tff=0, meta.top_field_first=0, meta.swap_fields=0 `

[walterav1984]

Interlaced Chroma Upsampling Error and NTSC field order reversing tested and fixed in mlt master commit b01523a.