Adjust Scenalyzer setting at the programming level

[SF01]

Is it possible to change the source code of scenalyzer?
I have exported a frame as jpg and it incorrectly saved it as 768x576 image with the Correct Aspect Ratio (square pixels) turned on, the problem is that 768 is't square pixels, as anyone familiar with ITU-R BT.470 and 601 knows.

[DB83]

If they are non-square then what are they ?


The DV stream is transferred as 720*576 (non-square). When the 4:3 DAR kicks in the image correctly displays as 768*576

[Alwyn]

Yes, my video editors also export still images from 720x576 4:3 video as 768x576.

They also export 720X576 16:9 as 1024x576.

[SF01]

So you two do not know ITU-R BT.470 and 601.
https://bjohas.de/wiki/Tutorials/Video/Pixel_Aspect_Ratio
The 4:3 video is encoded in the middle 702x576 patr of the image, the remaining 18 samples are Nominal analogue blanking that are not part of the image. The middle 702x576 portion needs to ne expanded to the proper aspect ratio, not the whole 720 part.
Vegas does it properly. VLC does not, it does even worse for NTSC, it converts 720x480 into 720x540 something that should never be done.

It wouldn't be a problem, if it first cropped to 702 and then expanded to 768, or 1024m but it doesn't do that. Which is why I have this filter:

"crop=702:576:9:0,scale=768:576,setsar=1"

in ffmpeg when converting analog to mp4 and this:

"scale=788:576,setsar=1"

when converting DV to mp4 to maintain actual aspect ratio.

[Alwyn]

Oh Kay....

[DB83]

Well Sc-Live is not an editor. If the slightly squashed image (and it is slight) troubles you then just use Vegas.


There are been countless topics on here since many dvds are created the same way.


Some time ago there was a topic with a link that showed the effect of 702(or704)*576 against 720*576 for DV in respect of AR.

[SF01]

It's not an editor indeed, it has the basic funcitonalyty thankfully.
Yes, a problem with many new DVDs. The last proepr DVD I've seen was Iron Maiden Death on the Road. The problem is with HDTVs, they don't know how to properly handle SD signal, hence the manufacturers stopped using BT.601 compliant video to fill full screen of modern TV, instead of it displaying digital blanking.
DVD can only have 704 samples, ebcause MPEG-2 only accepts multiples of 4, but mp4 can.
As for DV, it uses all available 720 sample,s but still follows the same principle in terms of sample aspect ratio. Shoot a circle, expand it to both 768 and 788 pixel width and only one has the perfect circle on it, the one compliant with BT.601.

[Skiller]

I second that.
With DV, no matter if natively shot on a digital camcorder that occupies all 720 pixels with active image*, or if originally shot in analog with ~702 active pixels, one can be pretty sure – I'd almost say certain – that ITU-R BT compliant scaling is the right choice for DV.

(* I actually tested that back in the day with my MiniDV camcorders.)

It's DVDs of the past 10 or so years and digital SD broadcasts where there is uncertainty (and new TVs of course). It's all over place in my experience and more often than not the scaling used is the so called "generic" one (flat out 16:9 or 4:3 no matter the other parameters).

[SF01]

I second that.
With DV, no matter if natively shot on a digital camcorder that occupies all 720 pixels with active image*, or if originally shot in analog with ~702 active pixels, one can be pretty sure – I'd almost say certain – that ITU-R BT compliant scaling is the right choice for DV.

(* I actually tested that back in the day with my MiniDV camcorders.)

It's DVDs of the past 10 or so years and digital SD broadcasts where there is uncertainty (and new TVs of course). It's all over place in my experience and more often than not the scaling used is the so called "generic" one (flat out 16:9 or 4:3 no matter the other parameters).

Yes and yet VLC still fails to recognize that, one would hope that Scenalyzer that is is a specialised software for DV would handle it properly, but apparently not...

Very unfortunate, this is why I no longer buy DVDs of new stuff that comes out, though some still comes out only on DVD, I have seen some concerts, not only they have complete disregard for ITU, many labels will release NTSC only, even if the source is PAL and the primary market is Europe, simply, becuase it's cheaper to have one master and one pressing order... Even for Blu-Rays and the artifacts are clearly visible, Ear Music even uses interlacing when converting 25 to 29,970i, as evident on Celebrating Jon Lord Blu-Ray, absolotely a nightmare to watch, I could understand snd probably not notice, if full frames were duplicated, but the combing is all over the place and back conversion does not work completely. I'd much rather preffer VHS.

[Skiller]

Ear Music even uses interlacing when converting 25 to 29,970i, as evident on Celebrating Jon Lord Blu-Ray, absolotely a nightmare to watch, I could understand snd probably not notice, if full frames were duplicated

It sacrifices some spatial quality for much better temporal quality. Have you ever watched a video that was converted from 25p to 29.97p? I think that is borderline unwatchable.
The combing shouldn't be visible when watched on a TV at all, so I don't see the issue there. If I was in charge of that conversion I absolutely would have gone interlaced as well (25 fps to 59.94 fields via duplication).

[dellsam34]

So you two do not know ITU-R BT.470 and 601.
https://bjohas.de/wiki/Tutorials/Video/Pixel_Aspect_Ratio
The 4:3 video is encoded in the middle 702x576 patr of the image, the remaining 18 samples are Nominal analogue blanking that are not part of the image. The middle 702x576 portion needs to ne expanded to the proper aspect ratio, not the whole 720 part.
Vegas does it properly. VLC does not, it does even worse for NTSC, it converts 720x480 into 720x540 something that should never be done.

Firstable when you try to prove someone wrong you better provide a working link, Secondable Sclive is not wrong, DV is 720x576 not 704x576, So when you use it to capture DV it doesn't care what your original source is, it processes DV in its native resolution:

Common resolutions and the corresponding sample aspect ratios (a.k.a PAR, pixels aspect ratio):

NTSC:
720x480 (DV/DVD, Full frame) -> SAR=8/9
704x480 (Analog Capture and some DVD's, SD Crop) -> SAR=10/11
640x480 (Square pixel, SD Resize) -> SAR=1

PAL/SECAM:
720x576 (DV/DVD, Full frame) -> SAR=16/15
704x576 (Analog Capture, SD Crop) -> SAR=12/11
768x576 (Square pixel, SD Resize) -> SAR=1

[SF01]

Ear Music even uses interlacing when converting 25 to 29,970i, as evident on Celebrating Jon Lord Blu-Ray, absolotely a nightmare to watch, I could understand snd probably not notice, if full frames were duplicated

It sacrifices some spatial quality for much better temporal quality. Have you ever watched a video that was converted from 25p to 29.97p? I think that is borderline unwatchable.
The combing shouldn't be visible when watched on a TV at all, so I don't see the issue there. If I was in charge of that conversion I absolutely would have gone interlaced as well (25 fps to 59.94 fields via duplication).

I am watching on both TV and laptop, just watch Celebrating Jon Lord, or From Here to Infinite by Dep Purple, combing everywhere. Also, the much better temporal resolution is basically a soap opera effect, whiel the spatial resolution is where the "much better" is more appropriate for PAL.
This is what they are doing, converting 25p footage to 59,940 fields and the fields look basically like in three-two pull down, the combing comes and goes like a sinusoid, good frames, then interlaced mess. If I was in charge, it would have been properly released as 25p. It's even worse with Nightiwish, after they butchered one Blu-Ray by slowing down 25p to 24p and it's noticable in audio, they resampled all subsequent Blu-Ray releases from 25p to 24p introducing ghosting in a simmilar recurring pattern. By the way, they used real 24,000, not 23,976.

So you two do not know ITU-R BT.470 and 601.
https://bjohas.de/wiki/Tutorials/Video/Pixel_Aspect_Ratio
The 4:3 video is encoded in the middle 702x576 patr of the image, the remaining 18 samples are Nominal analogue blanking that are not part of the image. The middle 702x576 portion needs to ne expanded to the proper aspect ratio, not the whole 720 part.
Vegas does it properly. VLC does not, it does even worse for NTSC, it converts 720x480 into 720x540 something that should never be done.

Firstable when you try to prove someone wrong you better provide a working link

Those bloody dying links I keep in bookmarks.
This one works:
https://web.archive.org/web/20191026141308/https://bjohas.de/wiki/Tutorials/Video/Pixel_Aspect_Ratio

Secondable Sclive is not wrong, DV is 720x576 not 704x576, So when you use it to capture DV it doesn't care what your original source is, it processes DV in its native resolution:

Common resolutions and the corresponding sample aspect ratios (a.k.a PAR, pixels aspect ratio):

NTSC:
720x480 (DV/DVD, Full frame) -> SAR=8/9
704x480 (Analog Capture, SD Crop) -> SAR=10/11
640x480 (Square pixel, SD Resize) -> SAR=1

PAL/SECAM:
720x576 (DV/DVD, Full frame) -> SAR=16/15
704x576 (Analog Capture, SD Crop) -> SAR=12/11
768x576 (Square pixel, SD Resize) -> SAR=1

https://www.youtube.com/watch?v=2sRS1dwCotw

First of all, it's calles Sample Aspect Ratio, you even used the SAR acronym.
Second of all, you are now officially in the club of people who have no bloody idea what ITU-R BT.470 and 601 are.
And do you know why it's called Sample? Because BT.470 specifies the analog scan line, which for PAL is 52 µs, the BT.601 in turn specifies the SD digital video with horizontal size of 720 samples with sampling rate of 13,5MHz. For this part I am going to use mathematics: 52 µs · 13 MHz =, ladies and gentleman, 702 samples. Fifty Two Microseconds sampled 13,5 million times a second gives us exactly 702 samples. These 702 samples contain the active image of both sigitized analog video and broadcasted digital video, also the video encoded on DVD, according to specification. The remaining 18 pixels are nominal analogue blanking (a recommended read). This is how analog video was broadcasted and manufactured on tapes, this is how digital SD ideo was broadcasted and released on DVDs.

Now for DV, the native resolution is indeed 720 samples, but it doesn'r change anything, every DV equipment is hardwired to uphold both BT.470 and 601 and it samples at 13,5 MHz back and forth. And it just happens to use full 720 samples available to record video, which in no way, shape, or form means i deviates from ITU-R standards, it just contains more video than your typical 4:3, or 16:9 video.

Asfor the SARs you mentioned, 10/11 for 704x480 is correct, because for NTSC the active image is exactly 704 pixels. Square pixels value are also obviously correct, but the image needs to be first properly expanded, or shrunk to square pixels according to correct SAR, which you can find in the archived link (by the way, the first thing you do, when a link is not working, you check it in the archive, pointing out to someone that their link isn't working is neither an argument, nor invalidation of the argument).

Again, I will reffer reffer you to my experiment of shooting a drawn circle in DV, which was already proven by Skiller. The SAR for SD is always 1,094 for 4:3 PAL (SAR=768/702=128/117), 1,459 (SAR=1024/702=512/351) for 16:9 PAL, 0,0901 for 4:3 NTSC (SAR=640/704=10/11) and 1,212 for 16:9 NTSC (SAR=480·16/9/704=40/33), by the way, good luck rendering square pixel widescreen NTSC (spoiler alert, you can't, it's not a real number, just like their frame rate). Just because DV uses digital blanking samples for more video, doesn't mean the SAR changes, because it doesn't, why would they use two different sampling rates for converting analog and recording digital video, it wouldn't make any sense and would be more expensive to manufacture.

Now back, to the "it processes DV in its native resolution", yes, according to ITU, so for analog it will make 720 sampels by sampling the scan line at 13,5 MHz, but the video is only in 52 microseconds resulting in 702 samples, but DV is 720 samples, because it samples 53,333 microseconds, because of being compatible with BT.601 that clearly specifies it (both ITU documends are a required reading at this point, if I could have, then you can too, maybe then you will understand), hence the phenomenon called digital blanking, which results from sampling of the nominal analogue blanking at the sides of the active image area.

Also useful are these BBC test patterns, which clearly are for full frame D1:
https://web.archive.org/web/20051126010756/http://www.bbc.co.uk/commissioning/tvbrandi...turesize.shtml
You will find the 16:9 test image to be 1050x576 and I'm pretty sure I've explained why it's 1050, not 1024.

[dellsam34]

First of all, it's calles Sample Aspect Ratio

Common resolutions and the corresponding sample aspect ratios (a.k.a PAR, pixels aspect ratio):

NTSC:
720x480 (DV/DVD, Full frame) -> SAR=8/9
704x480 (Analog Capture and some DVD's, SD Crop) -> SAR=10/11
640x480 (Square pixel, SD Resize) -> SAR=1

PAL/SECAM:
720x576 (DV/DVD, Full frame) -> SAR=16/15
704x576 (Analog Capture, SD Crop) -> SAR=12/11
768x576 (Square pixel, SD Resize) -> SAR=1

Oh boy

[SF01]

Oh well, you got me there, touché.

[Skiller]

combing everywhere.

Assuming the deinterlacing during playback is done properly, it's likely due to a bad conversion with some mistakes done to the footage. If everything works out as it should, there would be no combing during playback. Ever.

If I was in charge, it would have been properly released as 25p.

No question about it. Best option.

Also, the much better temporal resolution is basically a soap opera effect, whiel the spatial resolution is where the "much better" is more appropriate for PAL.

You did not get my point there. This illustration is not about frame interpolation – which would artificially create the soap opera effect – this is about having to make a DVD or Blu-ray with 60 Hz output from a 25p source using just plain simple frame duplication (as dumb as that goal may be). Frame or field duplication does not change the look of motion. At best, you don't even notice it while watching.

25 fps fit way worse in 29.97 than in 59.94. The problem with the former is it makes the motion quite jerky. Yes, all the original frames are there, nothing is lost, but the motion now has a distinct and quite obvious pattern to it. Going with 59.94 of course does this as well (after all 25 fps is never going to fit perfectly for any kind of 60 Hz output), but the pattern is much better spread out.
That's the sole reason I argue the interlaced conversion is the lesser evil in such case, assuming it's done right.

[SF01]

combing everywhere.

Assuming the deinterlacing during playback is done properly, it's likely due to a bad conversion with some mistakes done to the footage. If everything works out as it should, there would be no combing during playback. Ever.

If I was in charge, it would have been properly released as 25p.

No question about it. Best option.

Also, the much better temporal resolution is basically a soap opera effect, whiel the spatial resolution is where the "much better" is more appropriate for PAL.

You did not get my point there. This illustration is not about frame interpolation – which would artificially create the soap opera effect – this is about having to make a DVD or Blu-ray with 60 Hz output from a 25p source using just plain simple frame duplication. Frame or field duplication does not change the look of motion. At best, you don't even notice it while watching.

25 fps fit way worse in 29.97 than in 59.94. The problem with the former is it makes the motion quite jerky. Yes, all the original frames are there, nothing is lost, but the motion now has a distinct and quite obvious pattern to it. Going with 59.94 of course does as this well (after all 25 fps is never going to fit perfectly for any kind of 60 Hz output), but the pattern is much better spread out.
That's the sole reason I argue the interlaced conversion is the lesser evil in such case, assuming it's done right.

Bad conversion.

I got the point, I just get triggered by PAL vs NTSC. Frame duplication, yes, converting 25p to fields and then duplicating fields = combing in all DP BDs I have and I have a lot... Except Montrux 2006, this one is in 23,976... So I'm not sure which is worse.

[DB83]

Now that link you posted above looks pretty similar (if not the exact but then original) one I remembered from a year or more back.


Ok. I'll concede from the purist POV that cropped to 702 and then resized is the correct way to do this but that table also confirms my original argument that 768*576 really is square pixels (if considering the whole frame). But there is also clear inconsistency in the adoption with video editors whom you would think would do it 'right'.


Yet I do recall one topic that attempted to illustrate the difference and TBH I could not detect the difference with a perfect circle in either method. And when you are following real-time video if the difference is minimal then you are basically using a sledge-hammer to crack a nut. It's a similar argument with PAL speed-up. Some detect the sound variation whereas many (since I guess they are used to it - or like me are half-deaf - and have no experience with the original) will not.


None of which in the 14 or so replies actually answers your original Q.

[SF01]

768x576 is square pixels, when you have 4:3 image and it was cropped to 702 first, or cropped to 768 after.
Vegas and Premiere do it properly, I haven't tested Da Vinci.

The speed differance might be better than duplicating one frame every second, I should do tests for VHS.

[Skiller]

Frame duplication, yes, converting 25p to fields and then duplicating fields = combing in all DP BDs I have and I have a lot... Except Montrux 2006, this one is in 23,976... So I'm not sure which is worse.

Hmm, not sure we are talking about the same thing. To do what I was talking about you take 25p, frame duplicate to 59.94p (yes, p) then drop every other scanline (in an alternating fashion) to be left with 59.94 fields to be weaved into 29.97 interlaced frames.
Because if you were to duplicate the literal fields of 25p that would give a semi-broken interlacing in the result.

[SF01]

Frame duplication, yes, converting 25p to fields and then duplicating fields = combing in all DP BDs I have and I have a lot... Except Montrux 2006, this one is in 23,976... So I'm not sure which is worse.

Hmm, not sure we are talking about the same thing. To do what I was talking about you take 25p, frame duplicate to 59.94p (yes, p) then drop every other scanline (in an alternating fashion) to be left with 59.94 fields to be weaved into 29.97 interlaced frames.
Because if you were to duplicate the literal fields of 25p that would give a semi-broken interlacing in the result.

Could be, the end result I see is alternating pattern of full frames, then the desynchronization between fields increases, then decreases to ful frames again and the cycle repeats, I don't know if this is done by duplicating frames to 59,940p then dropping fields, or by converting to 25PsF and then duplicating fields to achieve 29,970i. The result is basically like the frames of tele-cine pull down.

[poisondeathray]

I don't think Scenalyzer is open source


The method Skiller mentioned is the "right" way for audio oriented 25p content on NTSC DVD - because it can be perfectly inverse telecined to back to the original 25p content. Moreover, the audio is the original, no speedup/slowdown/pitch shifting - so for concerts it's the right thing to do.

Some TV's have 3:2:3:2:2 pulldown detection built in - and perform IVTC on the fly, this returns the 25p back perfectly. But then it's whether or no your TV supports variable refresh rates. If it's 60Hz only, then you still don't have perfectly smooth motion (25 cannot be evenly divisible into 60 as integer result)

But if your TV does not have 3:2:3:2:2 pulldown support, then it gets deinterlaced instead. If it gets deinteralced - you might see deinterlacing artifacts, but you should never see "combing" eitherway as Skiller mentioned

[SF01]

I don't think Scenalyzer is open source


The method Skiller mentioned is the "right" way for audio oriented 25p content on NTSC DVD - because it can be perfectly inverse telecined to back to the original 25p content. Moreover, the audio is the original, no speedup/slowdown/pitch shifting - so for concerts it's the right thing to do.

Some TV's have 3:2:3:2:2 pulldown detection built in - and perform IVTC on the fly, this returns the 25p back perfectly. But then it's whether or no your TV supports variable refresh rates. If it's 60Hz only, then you still don't have perfectly smooth motion (25 cannot be evenly divisible into 60 as integer result)

But if your TV does not have 3:2:3:2:2 pulldown support, then it gets deinterlaced instead. If it gets deinteralced - you might see deinterlacing artifacts, but you should never see "combing" eitherway as Skiller mentioned

Interesting. Any idea to reverse the 25p to 29,970i process with software? ffmpeg command string? SHould be easier than deghost blended frames...

[dellsam34]

Yet I do recall one topic that attempted to illustrate the difference and TBH I could not detect the difference with a perfect circle in either method. And when you are following real-time video if the difference is minimal then you are basically using a sledge-hammer to crack a nut. It's a similar argument with PAL speed-up. Some detect the sound variation whereas many (since I guess they are used to it - or like me are half-deaf - and have no experience with the original) will not.


None of which in the 14 or so replies actually answers your original Q.

He derailed his own thread by throwing insults left and right, The difference in aspect ratio is not really that noticeable to the masses, but it is there, I've done a demonstration before to illustrate it.
https://forum.videohelp.com/threads/397337-Calculation-of-Color-Rate-NTSC/page2#post2584522

[poisondeathray]

Interesting. Any idea to reverse the 25p to 29,970i process with software? ffmpeg command string? SHould be easier than deghost blended frames...

Are you sure it was a clean conversion in the first place , similar to what Skiller described? Because there is no blending or ghosting on those DVD's. If you're seeing blending, ghosting (and it's not from your player blend deinterlacing) , then you have something else or maybe you have undergone multiple conversions

Avisynth IVTC for 25p content in 29.97i DVD , back to original 25p content . This is essentially what the TV chips do on the fly that have 3:2:3:2:2 pulldown detection

Mpeg2Source()
TFM()
TDecimate(cycle=6,cycler=1)

[SF01]

Interesting. Any idea to reverse the 25p to 29,970i process with software? ffmpeg command string? SHould be easier than deghost blended frames...

Are you sure it was a clean conversion in the first place , similar to what Skiller described? Because there is no blending or ghosting on those DVD's. If you're seeing blending, ghosting (and it's not from your player blend deinterlacing) , then you have something else or maybe you have undergone multiple conversions

Avisynth IVTC for 25p content in 29.97i DVD , back to original 25p content . This is essentially what the TV chips do on the fly that have 3:2:3:2:2 pulldown detection

Mpeg2Source()
TFM()
TDecimate(cycle=6,cycler=1)

Deep Purple Blu-Rays use interlacing and are conversions form 25p to 29,970i, the blending with ghosting I mentioned are Nightwish Blu-Rays...
Is there a need to specify baseline full frame and baseline interlaced frame? So that all fields would be properly processed, instead of interlacing it even more?

Yet I do recall one topic that attempted to illustrate the difference and TBH I could not detect the difference with a perfect circle in either method. And when you are following real-time video if the difference is minimal then you are basically using a sledge-hammer to crack a nut. It's a similar argument with PAL speed-up. Some detect the sound variation whereas many (since I guess they are used to it - or like me are half-deaf - and have no experience with the original) will not.


None of which in the 14 or so replies actually answers your original Q.

He derailed his own thread by throwing insults left and right, The difference in aspect ratio is not really that noticeable to the masses, but it is there, I've done a demonstration before to illustrate it.
https://forum.videohelp.com/threads/397337-Calculation-of-Color-Rate-NTSC/page2#post2584522

Was I throwing insults? Apologies, I sometimes have unwanted episodes... As for the video test, It is immidiately noticable when played back on 18" monitor swithing aspect ratios in VLC.

[poisondeathray]

Is there a need to specify baseline full frame and baseline interlaced frame? So that all fields would be properly processed, instead of interlacing it even more?

I don't understand your question

Fieldmatching takes all the fields into account for processing. But sometimes fields don't quite align , or there is residual combing, or ophan field (maybe bad post production edits). Post processing comb detection is usually used, and only those frames where combing after matching is detected will get deinterlaced

ffmpeg equivalent would be

-vf fieldmatch=combmatch=full,decimate=cycle=6

You have to be careful with ffmpeg, because if your timestamps are not perfect, the results can be inconsistent with wrong matches. Personally I would use avisynth or vapoursynth with DGIndex or DGIndexNV . Very consistent, frame accurate

[SF01]

Is there a need to specify baseline full frame and baseline interlaced frame? So that all fields would be properly processed, instead of interlacing it even more?

I don't understand your question

Fieldmatching takes all the fields into account for processing. But sometimes fields don't quite align , or there is residual combing, or ophan field (maybe bad post production edits). Post processing comb detection is usually used, and only those frames where combing after matching is detected will get deinterlaced

ffmpeg equivalent would be

-vf fieldmatch=combmatch=full,decimate=cycle=6

You have to be careful with ffmpeg, because if your timestamps are not perfect, the results can be inconsistent with wrong matches. Personally I would use avisynth or vapoursynth with DGIndex or DGIndexNV . Very consistent, frame accurate

This is exactly what I meant, if the software would be able to identify the sequence correctly, if it didn't start from the first frame.