PAL to NTSC using pulldown excessive judder

[Skiller]

Mistateo, I was talking about the maximum bitrate (not average, which is what defines the file size). There is no need to limit it to 8000 when the spec allows for >9000. A higher max rate yields more dynamic bitrate allocation and better quality in scenes with fast motion.

DVD uses mode 1/2048 error correction, so there is plenty of overhead to correct for errors before they show. There is no need to use closed GOPs for better error resilience. If the disc does not play without errors, it's a coaster anyways in my opinion and needs to be reburned.
Closed GOPs are good to have if you ever want to edit the video, as mentioned by jagabo, or is required by spec for multiangle titlesets (special application).


Resizing straight between 720x480 and 720x576 without any cropping is (accidentally) correct in terms of aspect ratio, although it does not account for different active scanline lengths of the two systems. But this can be neglected as it does not have any real world effect, especially not when played on a modern TV.

This also led me to the debate on 704x480 vs 720x480. Since I own no CRT TVs, I think 720x480 should be fine.

Does not matter what kind of TV setup you have – 704 is correct in all cases while 720 is not always. (<— That right there is the conclusion of pages and pages of discussions).

[mistateo]

Speaking of resizing from 576 to 480, since neither 720x480 or 720x576 are 4/3 ratios, I am guessing there is no crop involved in the resize, and that the height/width ratios for the tv pixels are different between PAL and NTSC.

Yes. The PAR (Pixel Aspect Ratio) for 4:3 PAL DVD is 16:15, while for 4:3 NTSC DVD it is 8:9.
Cropping does not change the Pixel Aspect Ratio, while resizing does.

Plenty of new topics for me to go research. This seems to confirm my suspicion of non-square pixels in TVs. Though a quick google search would have told me also, I'll learn someday. This also led me to the debate on 704x480 vs 720x480. Since I own no CRT TVs, I think 720x480 should be fine.

The non-square pixels are part of the DVD format. Non-square pixels of digital video and the various aspect ratios and "frame resolutions" are a subject of its own, and you risk to open a can of worms when you dive deeper into the subject.
When you find confusing numbers, definitions, standards and tools it is always helpful to remember the basic concepts of cropping and resizing
But what you have done so far for your PAL DVD to NTSC DVD conversion is correct.

I think I understand the basics now. The storage aspect ratio for NTSC is 720x480 (3:2), but when factoring in the NTSC pixel aspect ratio (8:9) it displays (pretending the pixels are square) like 720 x 540 (4:3, display aspect ratio). PAL storage aspect ratio being 720x576 (5:4), with pixel aspect ratio (16:15) it displays (pretending pixels are square) as 720x540 (4:3). Based on this, since my SOURCE is 720x576 and I am cropping BEFORE resizing I would assume my crop factor should be a ratio of 5:4 so that the cropped image aspect ratio is the same before the resize is applied. Cropping after resize appears to limit me to even numbers, and then borders added back in, resulting in a smaller output image (pretending borders are not part of the image).

[mistateo]

Mistateo, I was talking about the maximum bitrate (not average, which is what defines the file size). There is no need to limit it to 8000 when the spec allows for >9000. A higher max rate yields more dynamic bitrate allocation and better quality in scenes with fast motion.

DVD uses mode 1/2048 error correction, so there is plenty of overhead to correct for errors before they show. There is no need to use closed GOPs for better error resilience. If the disc does not play without errors, it's a coaster anyways in my opinion and needs to be reburned.
Closed GOPs are good to have if you ever want to edit the video, as mentioned by jagabo, or is required by spec for multiangle titlesets (special application).


Resizing straight between 720x480 and 720x576 without any cropping is (accidentally) correct in terms of aspect ratio, although it does not account for different active scanline lengths of the two systems. But this can be neglected as it does not have any real world effect, especially not when played on a modern TV.

This also led me to the debate on 704x480 vs 720x480. Since I own no CRT TVs, I think 720x480 should be fine.

Does not matter what kind of TV setup you have – 704 is correct in all cases while 720 is not always. (<— That right there is the conclusion of pages and pages of discussions).

Ah, now I see what you mean about maximum bitrate. If you have 2 ac3 audio tracks at 256kbps, and two subtitle streams, since only one of those can be selected at a time, does that mean that in theory the max bitrate could be: (10.08Mbps - 256kbps - subtitle max kbps) would it be (10.08Mbps - 512kbps - subtitle1 max kbps - subtitle2 max kbps)?

Regarding the 704 vs 720 debate, it seems like the summary would be "704 always displays correctly, a round ball will be round, no matter if using hdmi or composite, upscaled or native resolution, with the only tradeoff being an imperceivable loss of horizontal resolution at 704". Does that sound about right?

[jagabo]

Ah, now I see what you mean about maximum bitrate. If you have 2 ac3 audio tracks at 256kbps, and two subtitle streams, since only one of those can be selected at a time, does that mean that in theory the max bitrate could be: (10.08Mbps - 256kbps - subtitle max kbps) would it be (10.08Mbps - 512kbps - subtitle1 max kbps - subtitle2 max kbps)?

The latter. The max bitrate for all assets and overhead is 10.08 Mb/s. Whether they are played/used or not.

[ConsumerDV]

Regarding the 704 vs 720 debate, it seems like the summary would be "704 always displays correctly, a round ball will be round, no matter if using hdmi or composite, upscaled or native resolution, with the only tradeoff being an imperceivable loss of horizontal resolution at 704". Does that sound about right?

• if you get 704
  • then it is 4:3 (or 16:9).
• But if you get 720
  • it either is 4:3 (or 16:9)
  • or only 704 portion of it is 4:3 (or 16:9), and 16 pixels are tacked on. This option is the same as if you get 704 to begin with, but the extra 16 pixels can be black or can contain image.

[jagabo]

The DVD spec refers to the MPEG2 spec regarding aspect ratios. MPEG2 encoding doesn't flag the sampling aspect ratio, only the display aspect ratio. And it says that the full frame comprises the specified aspect ratio (in the absence of a sequence_display_extension that indicates otherwise). The rec.601 spec for digitizing analog video results in a 720x480 (720x576 for PAL) frame with a 704x480 (702x576 for PAL) portion of that frame comprising the 4:3 image. So the full 720x480 is slightly wider than 4:3. From what I've seen, most commercial DVDs made from analog source ignore this discrepancy and just use the full 720x480 frame and call it 4:3. All the upscaling players I've looked at upscale the full frame to a 4:3 size and pad the left and right borders fill out the 16:9 size (for example 720x480 resized to 1440x1080, padded to 1920x1080). So to get the correct aspect ratio you need to use a 704x480 frame, or resize the 704 portion to 720 before encoding. Of course, the reality is that you'll never notice the ~2% difference unless you get out a ruler and measure the picture on the TV screen.

Generally, small resizes should be avoided as they can create moire artifacts with very sharp material. Try resizing the video in this post:

https://forum.videohelp.com/threads/399396-Reason-to-resize-SD-video-to-720x540#post2600093

Analog caps aren't very sharp so you may not have problems.

[Skiller]

Good summary, jagabo.

For a PAL to NTSC conversion I would resize straight from 720x576 to 720x480 without any cropping before resizing, and then crop to 704 afterwards and encode (yes, even if it means a tiny bit of image is cut off). Resizing on the horizontal axis by just a few pixels to get rid of padding is not a good idea, I agree.

[Cornucopia]

I'm going to throw a wrench into your thinking, @mistateo. There is no such thing as Storage Aspect Ratio.
There is just Display (Frame) AR, Pixel (Sample) AR, and H rez & V rez. The sooner you get that clear, the easier all these calulations will be. 720x480 and 720x576 are both - when not widescreen - AT or VERY CLOSE to 4:3. Because natively from digitizing, if they follow the Rec601 spec, they never have square pixels (samples). You likely will want your end product to be square, because it fits better with most modern computer setups, but that requires proper resizing.

If going from one non-square format to another (e.g. PAL <--> NTSC), I agree with Skiller & jagabo's assessments.

Scott

[Sharc]

You likely will want your end product to be square, because it fits better with most modern computer setups, but that requires proper resizing

According to the OP's first post his final product shall be an authored NTSC DVD which he can play on his NTSC DVD player, as I understood it.

[mistateo]

You likely will want your end product to be square, because it fits better with most modern computer setups, but that requires proper resizing

According to the OP's first post his final product shall be an authored NTSC DVD which he can play on his NTSC DVD player, as I understood it.

This is correct.

[mistateo]

Okay, I am doing the encoding for all content for both discs. Straight resize from 720x576 to 720x480, followed by cropping 16 pixels horizontally for an output size of 704x480. Just confirming one last time that this is what the general consensus was. No 16 pixels of borders to bring it back to 720, just 704x480.

[ConsumerDV]

Consensus, are you kidding You don't have to crop 16 pixels. Both 720 and 704 pixels across are valid both for "NTSC" and for "PAL". Pixel aspect ratio will not change whether you crop or not.

[jagabo]

Consensus, are you kidding You don't have to crop 16 pixels. Both 720 and 704 pixels across are valid both for "NTSC" and for "PAL". Pixel aspect ratio will not change whether you crop or not.

The pixel aspect ratio does change in this case. Because an upscaling DVD player will upscale both frames to the same output size -- 1440x1080 in the case of 1080p.

This particular video has picture content out to within 4 pixels of the left and right edges. Keeping the full 720x480 frame will get you a little more (~1%) picture.

[mistateo]

Consensus, are you kidding You don't have to crop 16 pixels. Both 720 and 704 pixels across are valid both for "NTSC" and for "PAL". Pixel aspect ratio will not change whether you crop or not.

The pixel aspect ratio does change in this case. Because an upscaling DVD player will upscale both frames to the same output size -- 1440x1080 in the case of 1080p.

This particular video has picture content out to within 4 pixels of the left and right edges. Keeping the full 720x480 frame will get you a little more (~1%) picture.

Somehow I must be failing to understand this whole thing... I was under the impression (without understanding why) that to have the correct aspect ratio in all situations, it needed to be 704 and not 720. By the grace of Microsoft, my computer decided to restart for updates in the middle of my encoding. If keeping the full 720 frame ALSO displays correctly, I would rather not lose the extra pixels. I actually DO notice a quality degradation when I was cropping the padding before resizing, so I won't be doing that anymore. But yeah, if I am only losing a few pixels on each side and gaining nothing in return, I would rather keep the 720 wide frame and call it a day.

[ConsumerDV]

Consensus, are you kidding You don't have to crop 16 pixels. Both 720 and 704 pixels across are valid both for "NTSC" and for "PAL". Pixel aspect ratio will not change whether you crop or not.

The pixel aspect ratio does change in this case. Because an upscaling DVD player will upscale both frames to the same output size -- 1440x1080 in the case of 1080p.

Are you saying that a DVD player will treat both 704xYYY and 720xYYY as 4:3? (Your message above started with 720x576 but then switched to 704x480, so I lost track). In this case would not cropping the original 720 to 704 make the image wider when played on TV?

[jagabo]

Are you saying that a DVD player will treat both 704xYYY and 720xYYY as 4:3?

Yes. The MPEG 2 spec uses 4 bits to indicate the aspect ratio. Of the 16 possible values only 4 are defined: 4:3, 16:9, 2.2:1, and square pixel. Of those 4 only 2 are valid for DVD: 4:3 and 16:9. The spec clearly says the aspect ratio refers to the full frame unless overridden by a "sequence_display_extension" (an optional header). I've never seen one used to indicate the AR is a 704 portion of a 720 frame. All the upscaling DVD/BD player's I've checked (admittedly only a handful) upscale the full frame, whether it be 720 or 704, to a 4:3 size then pad with pillarbox bars.

[Luke M]

Are you saying that a DVD player will treat both 704xYYY and 720xYYY as 4:3?

Yes. The MPEG 2 spec uses 4 bits to indicate the aspect ratio. Of the 16 possible values only 4 are defined: 4:3, 16:9, 2.2:1, and square pixel. Of those 4 only 2 are valid for DVD: 4:3 and 16:9. The spec clearly says the aspect ratio refers to the full frame unless overridden by a "sequence_display_extension" (an optional header). I've never seen one used to indicate the AR is a 704 portion of a 720 frame. All the upscaling DVD/BD player's I've checked (admittedly only a handful) upscale the full frame, whether it be 720 or 704, to a 4:3 size then pad with pillarbox bars.

But surely this was not the case with the original analog output DVD players? I imagine they all treated 720 and 704 the same from a pixel clock point of view. Also why would the spec bother to include both 704 and 720, if not to accomodate existing standards? The literalist reading of the spec lacks a rationale.

Regardless of that, if it's the practice of Hollywood DVD authoring to treat 720x480 as (exactly) 4:3 or 16:9, then the upscaling DVD players are doing the right thing.

[ConsumerDV]

Of course, I started reading ISO/IEC 13818-2 after asking on the forum OTOH, if I did not ask, I would not know what to search for. The doc says the following:

aspect_ratio_information -- This is a four-bit integer defined in the Table 6-3.

aspect_ratio_information either specifies that the “sample aspect ratio” (SAR) of the reconstructed frame is 1.0 (square samples) or alternatively it gives the “display aspect ratio” (DAR).

If sequence_display_extension() is not present then it is intended that the entire reconstructed frame is intended to be mapped to the entire active region of the display. The sample aspect ratio may be calculated as follows:

SAR = DAR * horizontal_size/vertical_ size

NOTE - In this case horizontal_size and vertical_size are constrained by the SAR of the source and the DAR selected.

If sequence_display_extension() is present then the sample aspect ratio may be calculated as follows:

SAR = DAR * display_ horizontal_ size/display_vertical _ size

Usage of display_ horizontal_ size and display_vertical _ size is explained further:

display_horizontal_size and display_vertical_size together define a rectangle which may be considered as the “intended display’s” active region. If this rectangle is smaller than the encoded frame size then the display process may be expected to display only a portion of the encoded frame. Conversely if the display rectangle is larger than the encoded frame size then the display process may be expected to display the reconstructed frames on a portion of the display device rather than on the whole display device.

display_horizontal_size shall be in the same units as horizontal_size (samples of the encoded frames).

display_vertical_size shall be in the same units as vertical_size (lines of the encoded frames).

display_horizontal_size and display_vertical_size do not affect the decoding process but may be used by the display process that is not standardised in this specification.

These properties allow for soft pan-and-scan, I wonder whether any studio has ever used this feature:

The picture display extension allows the position of the display rectangle whose size is specified in sequence_display_extension() to be moved on a picture-by-picture basis. One application for this is the implementation of pan-scan.

TL;DR: Jagabo is right. Without extra display size info the decoder should take the whole frame and use one of the four defined aspect ratios.

[ConsumerDV]

Found an old thread that has all of this and much, much more

[Sharc]

Somehow I must be failing to understand this whole thing...

No wonder.... re-read post #30. Now the box of the pandora is open

... I would rather keep the 720 wide frame and call it a day.

Yes, IMHO close the pandora box and resize 720x576 to 720x480 and be done with it (especially in view that no one knows how the PAL "original" has been cropped and resized. Only the circle test would reveal this).
More important than the ~2% ambiguity is that your frames are progressive before the vertical resizing from 576 to 480 is applied. You did this correctly with QTGMC+SRestore for your example.

[Sharc]

Of course, I started reading ISO/IEC 13818-2 ......

Keep in mind that DVD is a standard (aka "DVD books") of its own. It relies on many other standards and can be seen as a subset of these, plus additions for the authoring, file structure, medium etc. The DVD video specs are not even publicly available but must be licensed for about 5'000.- USD AFAIK.

[jagabo]

I was under the impression (without understanding why) that to have the correct aspect ratio in all situations, it needed to be 704 and not 720.

No. The full frame, whether it be 704x480 or 720x480 will scaled to 4:3 by the DVD player. The problem is that ITU complaint standard definition analog video capture devices deliver a 720x480 frame with the 4:3 picture within a 704x480 portion of that frame. The full 720x480 frame is usually written to DVD without any correction for this discrepancy. Of course, not all 4:3 DVDs come from SD analog video tape. Some are properly made following the DVD/MPEG2 spec.

The issue is similar for PAL where the ITU spec delivers a 720x576 frame with the 4:3 image in a 702x576 portion.

If you are a real stickler for having a perfect aspect ratio you need to examine each video and decide for yourself how to handle it. The best way is to find something of known aspect ratio and measure it. A big circular or square logo for example. Something spherical.


[Attachment 65437 - Click to enlarge]

Of course, rarely can you find something so unambiguous.

[jagabo]

But surely this was not the case with the original analog output DVD players? I imagine they all treated 720 and 704 the same from a pixel clock point of view.

Yes, many years ago when I looked at the composte/s-video analog output of a few DVD players with an oscilloscope the pixel clock was the same. The extra pixels of a 720x480 DVD were outside the designated 4:3 area.

Regardless of that, if it's the practice of Hollywood DVD authoring to treat 720x480 as (exactly) 4:3 or 16:9, then the upscaling DVD players are doing the right thing.

DVDs made from analog video tapes usually ignore the discrepancy. DVDs made directly from film or digital HD video usually follow the DVD/MPEG 2 spec.

[Skiller]

But surely this was not the case with the original analog output DVD players? I imagine they all treated 720 and 704 the same from a pixel clock point of view.

Yes, many years ago when I looked at the composte/s-video analog output of a few DVD players with an oscilloscope the pixel clock was the same. The extra pixels of a 720x480 DVD were outside the designated 4:3 area.

The analog outputs of DVD-players are the reverse operation of digitizing. Like capture devices, it works with a base clock of 13.5 MHz (or multiples of it). Therefore this behavior is the only possible outcome and perfectly correct (for ITU compliant proportions). ...Which is incorrectly upscaled via HDMI if encoded in a 720 frame.

Hence the conclusion that a 704 encoded frame leaves no room for ambiguity.

I was under the impression (without understanding why) that to have the correct aspect ratio in all situations, it needed to be 704 and not 720.

No. The full frame, whether it be 704x480 or 720x480 will scaled to 4:3 by the DVD player.

"In all situations" (not just looking at upscaling via HDMI), the answer is a clear yes.



With a source like this, a 30+ years old TV show that almost certainly was on analog broadcast tape at some point, in 4:3 on a DVD with not all of the 720 pixels filled, I would very strongly assume it is ITU compliant. Therefore my recommendation to crop to 704 to get rid of said ambiguity just for the sake of it. But indeed, without checking what would be a perfect circle, nobody can be absolutely sure and encoding at 720 is alright nevertheless.


Edit: I did some tests a few years back with sequence_display_extension signaling a width of 704 and a 720x576 encoded frame size. None of the players I tested reacted to it in any way when upscaling.

[jagabo]

I started reading ISO/IEC 13818-2...

Yes, that's what I've been paraphrasing from.

(sequence_display_extension) These properties allow for soft pan-and-scan, I wonder whether any studio has ever used this feature:

The only way I've seen it used is with 16:9 VOB files that are marked as 4:3 DAR but the sequence_display_extension indicates that DAR is from a 540x480 (540x576) portion of the frame. So the full 720 pixel width of the frame is 16:9. When set to output 4:3 the DVD player would use that 540x480 to create a full screen 4:3 video. I don't know if it always "center cropped" or if the crop panned around (the tool I was using didn't say). When set to output 16:9 it would put out a full screen 16:9 video.

I've never seen one indicating a 704 portion of the frame was the 4:3 video.

The only other values I've ever seen there is 720x480 or 720x576 -- the same as the frame size.

[mistateo]

Okay, despite what my senses and others were telling me, I went further down the rabbit hole and kept looking. From the Wikipedia article on Pixel Aspect Ratio, I checked the citations and read from a couple of those. It all started to make sense to me once I read this page: https://encodingwissen.de/hintergrund/videobild/anamorph/itu-r-bt601/ (after I used google translate to english). My understanding was further supplemented with this page: https://web.archive.org/web/20140816103129/http://lipas.uwasa.fi/~f76998/video/conversion/

Now I know why the "active picture" size is the way it is, why analog signal was overscanned on CRT TVs (convenient place to keep other "metadata" off screen and clean up those half scan lines on top/bottom and the black borders on the sides), etc. It was also interesting to read the nuts and bolts of the analog to digital conversion process, exactly why 13.5 MHz is the sampling frequency what the pixel width/height numbers end up after the conversion. This does make me wonder why the electron beam (CRT obviously) fires across the scan line diagonally and then moves back to the other side horizontally. I would think if it scanned horizontally and moved to the next line diagonally they could have eliminated the "half lines". I'm GUESSING the reason is because the distance of the diagonal scan line is longer than it would be horizontally, and the time it takes to scan diagonally (opposed to horizontally) somehow matched up better to carrier frequencies for the analog signal?

Now I understand the flaws, realize nothing is perfect (like building with wood) and now I see why enthusiasts follow one methodology, and the home video producers just don't care. First and foremost, I may as well turn in my A/V card and surrender my TV. When I was testing the roundness of a circle on my TV, I wondered why part of the image was missing. I had previously foolishly selected "16x9" as the TV mode instead of "fit to screen" (2010 Samsung c6300). 16x9 SEEMED like the right answer to someone who doesn't know any better, but it was essentially zooming in on the whole screen, clipping the top/bottom and sides. Changing to "fit to screen" gave me the proper view. So now I find out I have been watching other "HD" content in this weird zoomed faux resolution simply because Samsung wanted to save me from myself...

When looking at the unaltered source in Virtualdub, I would see the "half scan line" on the BOTTOM of the image, but the top line was full width, not half black filled like the bottom. So the top seems to have been cropped/re-padded already. In any case, to summarize, my source is what it is, round looks round, and after straight resize from 720x576 to 720x480 round still looks round on my (digital) TV, whether cropping to 704 or keeping the original 720. Since my source video is wider than 704 in the ACTIVE picture (looks to be about 711 wide, with the right edge looking softer than the left, which seems to be no coincidence after reading the material in those pages), and the roundness of a dragonball (not very scientific, I know) is the same height/width to the millimeter with a ruler and my old eyes I just don't see the benefit to cropping to 704 and losing a few pixels on each side in my specific situation. If this just means that it will introduce a practically imperceivable margin of error in the display aspect ratio when connected via analog video cable (instead of HDMI) I think I can live with that, and I apologize if I piss off any video enthusiasts in the process.

Once again I want to express my sincere gratitude to everyone who chimed in on this post. You all are awesome.

[ConsumerDV]

This does make me wonder why the electron beam (CRT obviously) fires across the scan line diagonally and then moves back to the other side horizontally. I would think if it scanned horizontally and moved to the next line diagonally they could have eliminated the "half lines".

EDIT: I have removed my conjectures Here is the reason: "the horizontal lines slope downwards in the direction of scanning because the vertical deflecting current simultaneously produces a vertical scanning motion, which is very slow compared with horizontal scanning." Duh! Old-school analog system, cannot jump from one line to another with sufficient precision.

When looking at the unaltered source in Virtualdub, I would see the "half scan line" on the BOTTOM of the image, but the top line was full width, not half black filled like the bottom. So the top seems to have been cropped/re-padded already.

This is a very good page that explains where half lines and the designation of "upper" and "lower" fields come from.

[jagabo]

The motion of the electron beam in a CRT is produced by two deflection circuits. One moves the beam quickly from left to right, the other slowly from top to bottom. Both of these motions is constant so the electron beam is always moving down slowly even as it moves left to right for each scan line. This creates a slightly diagonal scan line across the screen. There's no point in wasting time moving the electron beam back to the left after each scan line, and back to the top after scanning the entire field, so each is done as quickly as possible. So both the waveforms are a sawtooth:

https://en.wikipedia.org/wiki/Sawtooth_wave

A sawtooth like this is easily created in analog systems where you apply a voltage to a capacitor which slowly charges up, then it can be be quickly discharge by shorting the circuit:

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

[jagabo]

When I was testing the roundness of a circle on my TV, I wondered why part of the image was missing. I had previously foolishly selected "16x9" as the TV mode instead of "fit to screen" (2010 Samsung c6300).

Yes, the 16:9 setting was simulating overscan to hide any possible junk at the edges of the frame. People would think there's something wrong with their TV if they saw that junk. This junk used to be pretty common (for example, without overscan, one might see closed captions at the top of the screen, or head switching noise at the bottom) but broadcasters have mostly eliminated it now.

When looking at the unaltered source in Virtualdub, I would see the "half scan line" on the BOTTOM of the image, but the top line was full width, not half black filled like the bottom. So the top seems to have been cropped/re-padded already.

The active picture is 485 scan lines: half a scan line at the top, 484 full scanlines, then half a scan line at the bottom. This is captured as 486 lines because it's easy to address a full digital array with an X and a Y coordinate.

https://www.educba.com/2-d-arrays-in-c/

Most systems now only capture 480 lines as that is most of the active area and is a nice mod 32 number for computers to work with.

[ConsumerDV]

There's no point in wasting time moving the electron beam back to the left after each scan line, and back to the top after scanning the entire field, so each is done as quickly as possible.

Um, it does move back to the left after each scan line, and back to the top after scanning the entire field, doesn't it?