This page: https://ffmpeg.org/ffmpeg-utils.html 'says' this: "The following abbreviations are recognized: "‘sntsc’ " 640x480" What is it? I'm not aware that any such thing exists. --Mark.
On Fri, Dec 22, 2023 at 2:38 PM Mark Filipak <markfilipak.imdb@gmail.com> wrote:
This page: https://ffmpeg.org/ffmpeg-utils.html 'says' this:
"The following abbreviations are recognized: "‘sntsc’ " 640x480"
What is it? I'm not aware that any such thing exists.
It's NTSC with square pixels (as opposed to the more common pixel aspect ratio of 10:11 found with 720x480). Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmueller@ltnglobal.com
Hi Devin, On 12/22/23 15:14, Devin Heitmueller wrote:
On Fri, Dec 22, 2023 at 2:38 PM Mark Filipak <markfilipak.imdb@gmail.com> wrote:
This page: https://ffmpeg.org/ffmpeg-utils.html 'says' this:
"The following abbreviations are recognized: "‘sntsc’ " 640x480"
What is it? I'm not aware that any such thing exists.
It's NTSC with square pixels...
How do you go from 720x480 to 640x480 without throwing away 80 pixels per line? Normally, 720x480 decodes to 720x540.
(as opposed to the more common pixel aspect ratio of 10:11 found with 720x480).
Devin
Umm... 10:11? What is that?
On Fri, Dec 22, 2023 at 3:57 PM Mark Filipak <markfilipak.imdb@gmail.com> wrote:
Hi Devin,
On 12/22/23 15:14, Devin Heitmueller wrote:
On Fri, Dec 22, 2023 at 2:38 PM Mark Filipak <markfilipak.imdb@gmail.com> wrote:
This page: https://ffmpeg.org/ffmpeg-utils.html 'says' this:
"The following abbreviations are recognized: "‘sntsc’ " 640x480"
What is it? I'm not aware that any such thing exists.
It's NTSC with square pixels...
How do you go from 720x480 to 640x480 without throwing away 80 pixels per line? Normally, 720x480 decodes to 720x540.
I would encourage you to do some reading up on "pixel aspect ratio" and "non-square pixels" Briefly, the number of lines is fixed, since they correspond to the scanlines put out to the CRT raster. However the width of the video is determined on how often the analog waveform was sampled. The display aspect ratio is 4:3, and if you have square pixels that would mean you have a resolution of 640x480. However it was common to capture 720 samples per line to improve image quality, and as a result the actual pixels are rectangular (i.e. slightly taller than they are wide). If you don't treat the pixels as non-square, you end up with a display aspect ratio which is greater than 4:3, and the image looks horizontally stretched.
(as opposed to the more common pixel aspect ratio of 10:11 found with 720x480).
Devin
Umm... 10:11? What is that?
See above. The pixel isn't square. It's actually a rectangle which is 10% taller than it is wide. Even worse, you can have 720x480 video with a display aspect ratio of 16:9 (i.e. standard definition widescreen). In this case the pixel aspect ratio is going to be 40:33. Yeah, this is all a huge PITA. I'm very happy that with HD resolutions they just decided to make all pixels square. Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmueller@ltnglobal.com
On 12/22/23 16:09, Devin Heitmueller wrote:
On Fri, Dec 22, 2023 at 3:57 PM Mark Filipak <markfilipak.imdb@gmail.com> wrote:
On 12/22/23 15:14, Devin Heitmueller wrote:
On Fri, Dec 22, 2023 at 2:38 PM Mark Filipak <markfilipak.imdb@gmail.com> wrote:
This page: https://ffmpeg.org/ffmpeg-utils.html 'says' this:
"The following abbreviations are recognized: "‘sntsc’ " 640x480"
What is it? I'm not aware that any such thing exists.
It's NTSC with square pixels...
How do you go from 720x480 to 640x480 without throwing away 80 pixels per line? Normally, 720x480 decodes to 720x540. -snip-
Even worse, you can have 720x480 video with a display aspect ratio of 16:9 (i.e. standard definition widescreen). In this case the pixel aspect ratio is going to be 40:33.
Huh? "720x480 video with a display aspect ratio of 16:9" is what's on most 'NTSC' DVDs. The PAR is 32/27.
On Mon, Dec 25, 2023 at 4:04 AM Mark Filipak <markfilipak.imdb@gmail.com> wrote:
On Fri, Dec 22, 2023 at 3:57 PM Mark Filipak <markfilipak.imdb@gmail.com> wrote:
On 12/22/23 15:14, Devin Heitmueller wrote:
On Fri, Dec 22, 2023 at 2:38 PM Mark Filipak < markfilipak.imdb@gmail.com> wrote:
This page: https://ffmpeg.org/ffmpeg-utils.html 'says' this:
"The following abbreviations are recognized: "‘sntsc’ " 640x480"
What is it? I'm not aware that any such thing exists.
It's NTSC with square pixels...
How do you go from 720x480 to 640x480 without throwing away 80 pixels
On 12/22/23 16:09, Devin Heitmueller wrote: per line?
Normally, 720x480 decodes to 720x540. -snip-
Even worse, you can have 720x480 video with a display aspect ratio of 16:9 (i.e. standard definition widescreen). In this case the pixel aspect ratio is going to be 40:33.
Huh? "720x480 video with a display aspect ratio of 16:9" is what's on most 'NTSC' DVDs. The PAR is 32/27.
Is that what you calculated the PAR to be? Or is that what "ffmpeg -i" says when run against the VOB? DVDs in general are a pretty poor reference as to what constitutes "correct", given there are so many different authoring tools that were used and many of them were poor quality. That said, I haven't reviewed the underlying DVD specs, so perhaps they put in there some sort of clause where widescreen encodings should be 720x480 with explicitly no overscan region. Devin -- [image: Img] Devin Heitmueller, Senior Software Engineer *LTN Global Communications* *o*: +1 (301) 363-1001 *w*: https://ltnglobal.com *e*: devin.heitmueller@ltnglobal.com [image: LTN Facebook icon] <https://www.facebook.com/LTNGlobal>[image: LTN X icon] <https://twitter.com/LTNGlobal>[image: LTN LinkedIn icon] <https://www.linkedin.com/company/ltnglobal/>
On 12/26/23 09:30, Devin Heitmueller wrote:
On Mon, Dec 25, 2023 at 4:04 AM Mark Filipak <markfilipak.imdb@gmail.com> wrote:
On Fri, Dec 22, 2023 at 3:57 PM Mark Filipak <markfilipak.imdb@gmail.com> wrote:
On 12/22/23 15:14, Devin Heitmueller wrote:
On Fri, Dec 22, 2023 at 2:38 PM Mark Filipak < markfilipak.imdb@gmail.com> wrote:
This page: https://ffmpeg.org/ffmpeg-utils.html 'says' this:
"The following abbreviations are recognized: "‘sntsc’ " 640x480"
What is it? I'm not aware that any such thing exists.
It's NTSC with square pixels...
How do you go from 720x480 to 640x480 without throwing away 80 pixels
On 12/22/23 16:09, Devin Heitmueller wrote: per line?
Normally, 720x480 decodes to 720x540. -snip-
Even worse, you can have 720x480 video with a display aspect ratio of 16:9 (i.e. standard definition widescreen). In this case the pixel aspect ratio is going to be 40:33.
Huh? "720x480 video with a display aspect ratio of 16:9" is what's on most 'NTSC' DVDs. The PAR is 32/27.
Oops. Sorry. SAR for 16:9 DVD is 32/27. PAR is 3/2. You brought up 40/33. That's a PAR? A PAR for what? And my original question: What is "sntsc"? ‘ntsc’ 720x480 ‘pal’ 720x576 ‘sntsc’ 640x480 ‘spal’ 768x576 What ffmpeg is calling 'ntsc' & 'pal' are from film scanners targeting pseudo-NTSC DVDs and pseudo-PAL DVDs. What ffmpeg is calling 'sntsc' & 'spal' don't have any relationship to NTSC and PAL, neither film nor broadcast, or to DVDs. Why ffmpeg has put the letters 'ntsc' and 'pal' into 640x480 and 768x576 is a total mystery to me and continues the confusion many people have. I'm sorry I brought it up. It was the marketing people who labeled DVDs as 'NTSC' or 'PAL'. FFmpeg is just propagating that myth. I simply ran across 'sntsc' and asked myself, "What is that?"
Hi Mark, On Tue, Dec 26, 2023 at 2:58 PM Mark Filipak <markfilipak.imdb@gmail.com> wrote:
Oops. Sorry. SAR for 16:9 DVD is 32/27. PAR is 3/2.
You brought up 40/33. That's a PAR? A PAR for what?
In this context SAR (Sample Aspect Ratio) and PAR (Pixel Aspect Ratio) are equivalent. Unfortunately the use of the term "SAR" is ambiguous as people sometimes mean "Storage Aspect Ratio" or "Screen Aspect Ratio". Using PAR avoids that ambiguity. I would encourage you to review the following page, which has an entire section on non-square pixels, as well as common values for NTSC (which talks about the 10:11 and 40:33 commonly found with encoded NTSC video): https://en.wikipedia.org/wiki/Pixel_aspect_ratio#Pixel_aspect_ratios_of_comm...
And my original question: What is "sntsc"?
‘ntsc’ 720x480 ‘pal’ 720x576 ‘sntsc’ 640x480 ‘spal’ 768x576
While I wouldn't have gone with the nomenclature that ffmpeg uses, it would appear the intent was for "ntsc" to be 720x480 with a DAR of 4:3 (therefore the PAR is 11:10), and "sntsc" to be 640x480 with a DAR of 4:3 (therefore the PAR is 1:1).
What ffmpeg is calling 'ntsc' & 'pal' are from film scanners targeting pseudo-NTSC DVDs and pseudo-PAL DVDs.
What ffmpeg is calling 'sntsc' & 'spal' don't have any relationship to NTSC and PAL, neither film nor broadcast, or to DVDs.
Why ffmpeg has put the letters 'ntsc' and 'pal' into 640x480 and 768x576 is a total mystery to me and continues the confusion many people have.
I'm sorry I brought it up. It was the marketing people who labeled DVDs as 'NTSC' or 'PAL'. FFmpeg is just propagating that myth. I simply ran across 'sntsc' and asked myself, "What is that?"
Frankly, I think the shortcuts were well-intentioned, but not very well thought out. If you know what you are doing I would discourage you from trying to use them and simply specify the real resolution and framerate using the fps filter and/or the scale filter as needed. Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmueller@ltnglobal.com
On 12/26/23 15:30, Devin Heitmueller wrote:
Hi Mark,
On Tue, Dec 26, 2023 at 2:58 PM Mark Filipak <markfilipak.imdb@gmail.com> wrote:
Oops. Sorry. SAR for 16:9 DVD is 32/27. PAR is 3/2.
You brought up 40/33. That's a PAR? A PAR for what?
In this context SAR (Sample Aspect Ratio) and PAR (Pixel Aspect Ratio) are equivalent.
On what planet are SAR & PAR equivalent?
Unfortunately the use of the term "SAR" is ambiguous as people sometimes mean "Storage Aspect Ratio" or "Screen Aspect Ratio". Using PAR avoids that ambiguity.
Yes, people misuse terms, mainly because the terms are not defined. The H.262 definitions have no relevance in the real world. "3.114 sample aspect ratio (SAR): This specifies the relative distance between samples. It is defined (for the purposes of ITU-T Rec. H.262 | ISO/IEC 13818-2), as the vertical displacement of the lines of luminance samples in a frame divided by the horizontal displacement of the luminance samples. Thus, its units are (metres per line) ÷ (metres per sample)." That definition applies solely to flying-spot scanners -- note that it is vertical (line-to-line) spacing divided by horizontal (pixel-to-pixel) spacing. To everyone else, H/W is upside down. H.262 then goes on to define a DAR that's upside down: "3.44 display aspect ratio: The ratio height/width (in spatial measurement units such as centimeters) of the intended display." H.262 avoids "PAR" and "pixel aspect" altogether. There's not a mention. That was intentional. So, to the ITU (and presumably to MPEG), PAR doesn't exist. Some call it 'pixel aspect' and some call it 'picture aspect'. Curiously, the ITU (and presumably to MPEG) define a 'picture', thusly: "3.97 picture: Source, coded or reconstructed image data. A source or reconstructed picture consists of three rectangular matrices of 8-bit numbers representing the luminance and two chrominance signals. A 'coded picture' is defined in 3.21 of ITU-T Rec. H.262 | ISO/IEC 13818-2. For progressive video, a picture is identical to a frame, while for interlaced video, a picture can refer to a frame, or the top field or the bottom field of the frame depending on the context." So, to the ITU (and presumably to MPEG) data is a picture. Good grief...
I would encourage you to review the following page, which has an entire section on non-square pixels, as well as common values for NTSC (which talks about the 10:11 and 40:33 commonly found with encoded NTSC video):
704x480 is illegal for DVD. It either gets padded out to 720x480, or cropped to 704x469, then scaled to 720x480, or some combination of the two methods. But 704x420 is not legal for DVDs -- there's no such aspect choice in PES headers.
https://en.wikipedia.org/wiki/Pixel_aspect_ratio#Pixel_aspect_ratios_of_comm...
Oh, no! Mister Billipedia! Hahahaha... (where people who are as ill informed as you are, get to pontificate)
And my original question: What is "sntsc"?
‘ntsc’ 720x480 ‘pal’ 720x576 ‘sntsc’ 640x480 ‘spal’ 768x576
While I wouldn't have gone with the nomenclature that ffmpeg uses, it would appear the intent was for "ntsc" to be 720x480 with a DAR of 4:3 (therefore the PAR is 11:10), and "sntsc" to be 640x480 with a DAR of 4:3 (therefore the PAR is 1:1).
What ffmpeg is calling 'ntsc' & 'pal' are from film scanners targeting pseudo-NTSC DVDs and pseudo-PAL DVDs.
What ffmpeg is calling 'sntsc' & 'spal' don't have any relationship to NTSC and PAL, neither film nor broadcast, or to DVDs.
Why ffmpeg has put the letters 'ntsc' and 'pal' into 640x480 and 768x576 is a total mystery to me and continues the confusion many people have.
I'm sorry I brought it up. It was the marketing people who labeled DVDs as 'NTSC' or 'PAL'. FFmpeg is just propagating that myth. I simply ran across 'sntsc' and asked myself, "What is that?"
Frankly, I think the shortcuts were well-intentioned, but not very well thought out. If you know what you are doing I would discourage you from trying to use them and simply specify the real resolution and framerate using the fps filter and/or the scale filter as needed.
Indeed. '-s 1920x1080' etc. ...It's more readable. :-) (And note, it's W/H, the inverse of how the ITU (and presumably MPEG) defines things.) I'm done. ...Gee, I thought it was such a simple question: "What's 'sntsc'?"
On Tue 26 Dec 2023 at 22:53, Mark Filipak <markfilipak.imdb@gmail.com> wrote:
On 12/26/23 15:30, Devin Heitmueller wrote:
Hi Mark,
On Tue, Dec 26, 2023 at 2:58 PM Mark Filipak <markfilipak.imdb@gmail.com> wrote:
Oops. Sorry. SAR for 16:9 DVD is 32/27. PAR is 3/2.
You brought up 40/33. That's a PAR? A PAR for what?
In this context SAR (Sample Aspect Ratio) and PAR (Pixel Aspect Ratio) are equivalent.
On what planet are SAR & PAR equivalent?
Unfortunately the use of the term "SAR" is ambiguous as people sometimes mean "Storage Aspect Ratio" or "Screen Aspect Ratio". Using PAR avoids that ambiguity.
Yes, people misuse terms, mainly because the terms are not defined. The H.262 definitions have no relevance in the real world.
"3.114 sample aspect ratio (SAR): This specifies the relative distance between samples. It is defined (for the purposes of ITU-T Rec. H.262 | ISO/IEC 13818-2), as the vertical displacement of the lines of luminance samples in a frame divided by the horizontal displacement of the luminance samples. Thus, its units are (metres per line) ÷ (metres per sample)."
That definition applies solely to flying-spot scanners -- note that it is vertical (line-to-line) spacing divided by horizontal (pixel-to-pixel) spacing. To everyone else, H/W is upside down. H.262 then goes on to define a DAR that's upside down:
"3.44 display aspect ratio: The ratio height/width (in spatial measurement units such as centimeters) of the intended display."
H.262 avoids "PAR" and "pixel aspect" altogether. There's not a mention. That was intentional. So, to the ITU (and presumably to MPEG), PAR doesn't exist. Some call it 'pixel aspect' and some call it 'picture aspect'. Curiously, the ITU (and presumably to MPEG) define a 'picture', thusly:
"3.97 picture: Source, coded or reconstructed image data. A source or reconstructed picture consists of three rectangular matrices of 8-bit numbers representing the luminance and two chrominance signals. A 'coded picture' is defined in 3.21 of ITU-T Rec. H.262 | ISO/IEC 13818-2. For progressive video, a picture is identical to a frame, while for interlaced video, a picture can refer to a frame, or the top field or the bottom field of the frame depending on the context."
So, to the ITU (and presumably to MPEG) data is a picture. Good grief...
I would encourage you to review the following page, which has an entire section on non-square pixels, as well as common values for NTSC (which talks about the 10:11 and 40:33 commonly found with encoded NTSC video):
704x480 is illegal for DVD. It either gets padded out to 720x480, or cropped to 704x469, then scaled to 720x480, or some combination of the two methods. But 704x420 is not legal for DVDs -- there's no such aspect choice in PES headers.
https://en.wikipedia.org/wiki/Pixel_aspect_ratio#Pixel_aspect_ratios_of_comm...
Oh, no! Mister Billipedia! Hahahaha... (where people who are as ill informed as you are, get to pontificate)
I think you must have misread the tone of Devin’s email, and I would hardly call him ill informed. His post was constructive and your language will only derail threads like this. Please read the code of conduct https://ffmpeg.org/community.html#Code-of-Conduct-1 Best, Kieran
On 12/27/23 01:58, Kieran O Leary wrote:
On Tue 26 Dec 2023 at 22:53, Mark Filipak <markfilipak.imdb@gmail.com>
Oh, no! Mister Billipedia! Hahahaha... (where people who are as ill informed as you are, get to pontificate)
I think you must have misread the tone of Devin’s email, and I would hardly call him ill informed. His post was constructive and your language will only derail threads like this.
Oh, I did not mean it like that. I meant the general 'you' as in 'you, the reader', as in 'people who are as ill informed as _they_ are'. I sincerely didn't mean Devon. But you are entirely justified in your objection. You read it differently, but your reading is reasonable and reasoned, I must admit. I sincerely apologize. I meant no harm. I certainly didn't mean to denigrate Devon. I only meant to denigrate Wikipedia. Peace and love. Please forgive my overly hasty post. I am appropriately chastened. In the future, I will try harder to express my true meanings. So sorry -- Mark.
Hi Mark On Wed 27 Dec 2023 at 08:53, Mark Filipak <markfilipak.trash@gmail.com> wrote:
On 12/27/23 01:58, Kieran O Leary wrote:
On Tue 26 Dec 2023 at 22:53, Mark Filipak <markfilipak.imdb@gmail.com>
Oh, no! Mister Billipedia! Hahahaha... (where people who are as ill informed as you are, get to pontificate)
I think you must have misread the tone of Devin’s email, and I would hardly call him ill informed. His post was constructive and your language will only derail threads like this.
Oh, I did not mean it like that. I meant the general 'you' as in 'you, the reader', as in 'people who are as ill informed as _they_ are'. I sincerely didn't mean Devon.
I re-read your post and I did indeed misread it. I understand what you mean now! Thanks for clarifying, Kieran.
чт, 28 дек. 2023 г., 08:54 Kieran O Leary <kieran.o.leary@gmail.com>:
Hi Mark
On Wed 27 Dec 2023 at 08:53, Mark Filipak <markfilipak.trash@gmail.com> wrote:
On 12/27/23 01:58, Kieran O Leary wrote:
On Tue 26 Dec 2023 at 22:53, Mark Filipak <markfilipak.imdb@gmail.com>
Oh, no! Mister Billipedia! Hahahaha... (where people who are as ill informed as you are, get to pontificate)
Well, we (cinelerra-gg users/hackers/maintainers) run into aspect ratio issues too , and I tried to demistify it for myself ... only to run into much more complex explanation at https://lurkertech.com/lg/pixelaspect/ Thing is, I was confused by lack of st->sample_aspect_ratio for HDV sources, but av_guess_sample_aspect_ratio() guessed SAR correctly anyway. So in our "info" window I added two sar/dar pairs conditionally - one guessed and one detected (as in libavformat/dump.c). if (st->sample_aspect_ratio.num && av_cmp_q(st->sample_aspect_ratio, st->codecpar->sample_aspect_ratio))
I think you must have misread the tone of Devin’s email, and I would
hardly
call him ill informed. His post was constructive and your language will only derail threads like this.
Oh, I did not mean it like that. I meant the general 'you' as in 'you,
the
reader', as in 'people who are as ill informed as _they_ are'. I sincerely didn't mean Devon.
I re-read your post and I did indeed misread it. I understand what you mean now! Thanks for clarifying,
Kieran. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
On 1/7/24 17:34, Andrew Randrianasulu wrote:
Well, we (cinelerra-gg users/hackers/maintainers) run into aspect ratio issues too , and I tried to demistify it for myself ... only to run into much more complex explanation at
I'm sorry, I couldn't get past the first sentence: "Pixels in the graphics world are square." They probably meant "dots" (aka "pels"). But I've read enough squirrely things in my time to know squirrely when I read it. My experience is that things that start squirrely get squirrelier. Some video folks who are stuck in analog TV write about 704x480 and 704x576 and 10:11 SAR and 59:54 SAR, and they talk about overscan. It's all nonsense. DVDs are not TV and never was. So, folks with analog TVs didn't see 720x480 because some of it got into the horizontal blanking. So what? There were no such SARs as 10:11 & 59:54. "59:54" isn't right even if 704 existed. Some of those people who write those squirrely things, and more, write them into standards. It's all still nonsense. What is it that you want to know?
пн, 8 янв. 2024 г., 05:14 Mark Filipak <markfilipak.imdb@gmail.com>:
On 1/7/24 17:34, Andrew Randrianasulu wrote:
Well, we (cinelerra-gg users/hackers/maintainers) run into aspect ratio issues too , and I tried to demistify it for myself ... only to run into much more complex explanation at
I'm sorry, I couldn't get past the first sentence: "Pixels in the graphics world are square." They probably meant "dots" (aka "pels"). But I've read enough squirrely things in my time to know squirrely when I read it. My experience is that things that start squirrely get squirrelier.
Some video folks who are stuck in analog TV write about 704x480 and 704x576 and 10:11 SAR and 59:54 SAR, and they talk about overscan. It's all nonsense. DVDs are not TV and never was.
I guess early on they were meant to be displayed on TVs among other things .... So, folks with
analog TVs didn't see 720x480 because some of it got into the horizontal blanking. So what? There were no such SARs as 10:11 & 59:54. "59:54" isn't right even if 704 existed.
Some of those people who write those squirrely things, and more, write them into standards. It's all still nonsense. What is it that you want to know?
I think I like to try and see bigger picture behind acronyms. At least this page explains how some 640*480 files might be born (it should be 486, but some lines are cut). https://lurkertech.com/lg/video-systems/#480i This is all interesting and not really theoretical to me because at least one our user still have a lot of HDV and DV material and he hopes to get correct encoding results in those cases too!
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
On 1/8/24 00:26, Andrew Randrianasulu wrote:
пн, 8 янв. 2024 г., 05:14 Mark Filipak <markfilipak.imdb@gmail.com>:
What is it that you want to know?
I think I like to try and see bigger picture behind acronyms.
What acronyms?
At least this page explains how some 640*480 files might be born (it should be 486, but some lines are cut).
Nonsense. If you're referring to DVD, there's no such thing as 640x480. There's 720x480. It decodes to 720x540.
Total Lines Per Frame 525. Nobody has those TVs anymore.
This is all interesting and not really theoretical to me because at least one our user still have a lot of HDV and DV material and he hopes to get correct encoding results in those cases too!
Sorry, I can't help there. I don't know what HDV & DV are. Is your friend trying to make a standards compliant DVD or BD? No? Then the correct encoding results are whatever can do the capture or the remux or the transcoding. I assume HDV & DV are analog, otherwise, why are you fussing about 704 & 525? If HDV & DV are digital, then 704 & 252 don't apply. All that analog capture stuff is moot. Get everything you can and then use ffmpeg to crop to whatever the image is. As long as the capture hardware is running at 60/1.001 fields per second, the field-to-field images should be stable and you'll be fine. If the videos are hand held camcorder, then the images will not be stable, but there are stabilizers you can use. Just get the images, then worry about presentation.
пн, 8 янв. 2024 г., 09:13 Mark Filipak <markfilipak.imdb@gmail.com>:
On 1/8/24 00:26, Andrew Randrianasulu wrote:
пн, 8 янв. 2024 г., 05:14 Mark Filipak <markfilipak.imdb@gmail.com>:
What is it that you want to know?
I think I like to try and see bigger picture behind acronyms.
What acronyms?
SAR, DAR, PAR .....
At least this page explains how some 640*480 files might be born (it should be 486, but some lines are cut).
I just found some intersection between topic of this thread (sntsc - square pixels NTSC) and oroblem we facing. Thanks for bring it up.
Nonsense. If you're referring to DVD, there's no such thing as 640x480. There's 720x480. It decodes to 720x540.
Total Lines Per Frame 525. Nobody has those TVs anymore.
This is all interesting and not really theoretical to me because at least one our user still have a lot of HDV and DV material and he hopes to get correct encoding results in those cases too!
Sorry, I can't help there. I don't know what HDV & DV are.
DV in this context digital video as recorded by early camcoders. HDV is from early mpeg2 tape-based cameras. Is your friend trying to make a standards
compliant DVD or BD? No? Then the correct encoding results are whatever can do the capture or the remux or the transcoding.
I assume HDV & DV are analog, otherwise, why are you fussing about 704 & 525? If HDV & DV are digital, then 704 & 252 don't apply.
All that analog capture stuff is moot. Get everything you can and then use ffmpeg to crop to whatever the image is. As long as the capture hardware is running at 60/1.001 fields per second, the field-to-field images should be stable and you'll be fine. If the videos are hand held camcorder, then the images will not be stable, but there are stabilizers you can use. Just get the images, then worry about presentation.
Well, here lies the problem for us! Ffmpeg (command line utility) encodes those files straight away, so for example VLC displays them correctly. But our software (cinelerra-gg) so far was not setting st->sample_aspect_ratio so say webm encodes were by default with wrong Display aspect ratio in both VLC and GNOME filemanager previews. I hope now (after my patches under testing) we set sample aspect ratio in both places (codecpar and st) so hopefully libav* based players will display them correctly out of the box.
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
On 1/8/24 01:46, Andrew Randrianasulu wrote:
Well, here lies the problem for us!
Ffmpeg (command line utility) encodes those files straight away, so for example VLC displays them correctly. But our software (cinelerra-gg) so far was not setting st->sample_aspect_ratio so say webm encodes were by default with wrong Display aspect ratio in both VLC and GNOME filemanager previews.
You can set DAR in ffmpeg to whatever you want.
I hope now (after my patches under testing) we set sample aspect ratio in both places (codecpar and st) so hopefully libav* based players will display them correctly out of the box. Well, I don't know your tools, but MPEG-TSs actually has no SAR setting. It has no PAR setting, either, but you can set PAR by setting horizontal_size_value & vertical_size_value. I don't know how to set them without ffmpeg reacting by actually scaling the samples. That's not what you will want. You want to correct the aspect without scaling. I don't know how to do that.
Perhaps someone else can advise you. I'd sure like to know how to change MPEG tags. -- Mark.
On 1/8/24 01:46, Andrew Randrianasulu wrote:
пн, 8 янв. 2024 г., 09:13 Mark Filipak <markfilipak.imdb@gmail.com>:
On 1/8/24 00:26, Andrew Randrianasulu wrote:
пн, 8 янв. 2024 г., 05:14 Mark Filipak <markfilipak.imdb@gmail.com>:
What is it that you want to know?
I think I like to try and see bigger picture behind acronyms.
What acronyms?
SAR, DAR, PAR .....
DAR is a physical aspect (i.e., a W/H). It is the dots-by-lines aspect of the view. Note that I don't use the word "display" because that makes many people think of a whole screen. I use the word "view", instead, as in "lines per view", not "lines per display". PAR is a physical aspect (i.e., a W/H). It is the pixels-by-rows aspect of the 'picture' matrix. Note that I use the word 'picture', an alias, because data matrices are not really pictures. But MPEG and the rest of the world call them "pictures" so I call them 'pictures'. SAR is not a physical aspect, it's an aspect transform. It transforms pixels-by-rows to dots-by-lines. SAR = DAR/PAR means view(W/H)/'picture'(W/H). For example, (1024/576)/(720/576). Details. "DAR" means "display aspect ratio" and you probably know all about that. It's dpl/lpv, i.e., (dots per line)/(lines per view). DAR dpl/lpv 1024/576 = 16/9 for 16:9 'PAL', 768/576 = 4/3 for 4:3 'PAL', 853/480 = 16/9 for 16:9 'NTSC', 720/540 = 4/3 for 4:3 'NTSC'. "PAR' means "picture aspect ratio". It's ppr/rpp, i.e., (pixels per row)/(rows per 'picture'). PAR ppr/rpp 720/576 = 5/4 for 16:9 'PAL', 720/576 = 5/4 for 4:3 'PAL', 720/480 = 3/2 for 16:9 'NTSC', 720/480 = 3/2 for 4:3 'NTSC'. "SAR" means "sample aspect ratio". That term is from the days of flying spot film scanners. Modern SAR is actually not an aspect at all. It's a transform. SAR transforms pixels-by-rows into dots-by-lines [note1]. It's dpp/lpr, i.e., (dots per pixel)/(lines per row). 'SAR' dpp/lpr (dpl/ppr)/(lpv/rpp) [note2] (1024/720)/(576/576) = 1024/720 = 64/45 for 16:9 'PAL' -- 64 dots per 45 pixels, (768/720)/(576/576) = 768/720 = 16/15 for 4:3 'PAL' -- 16 dots per 15 pixels, (853/720)/(480/480) = 853/720 = 32/27 for 16:9 'NTSC' -- 32 dots per 27 pixels, (720/720)/(540/480) = 1/(540/480) = 1/(9/8) for 4:3 'NTSC' -- 9 lines per 8 rows [note3]. [note1] Though modern SAR is actually a transform -- a 'picture'-to-view transform (PVT) -- the "SAR" acronym has become so entrenched in the art that it would be impossible to get people to change to "PVT". I try to get around the issue by calling SAR-as-transform, 'SAR' (meaning it's an alias, not a real aspect ratio). [note2] The following is not a 'stupid math trick', it is real. 'SAR' = dpp/lpr = (dpl/ppr)/(lpv/rpp) = (dpl/lpv)/(ppr/rpp) = DAR/PAR. For example, 'SAR' = dpp/lpr = (1024/720)/(576/576) = (1024/576)/(720/576) = (16/9)/(5/4) = DAR/PAR. [note3] Why is 4:3 'NTSC' so different? Well, there's two ways to look at it: 1, for 4:3 'NTSC', 'SAR' is less than one while for the others, 'SAR' is greater than one, and 2, turning 4:3 'NTSC' into 640x480 would lose resolution whereas 720x540 preserves resolution. The difference is moot because TVs don't use 'SAR' anyway. What they do is look at the size of their screen (e.g., 1920x1080), look at DAR in the PES header (e.g. 4/3), compute the size of the view based on that DAR (e.g. 1440x1080), and scale directly (e.g., turn 4-by-4 pixel blocks into 8-by-9 dot blocks). That makes 'SAR' a kind of fiction (which it is in a way). If you're unhappy with 'SAR', then just forget it. Know DAR and PAR though. Know them well. -- Mark.
вт, 9 янв. 2024 г., 11:35 Mark Filipak <markfilipak.imdb@gmail.com>:
On 1/8/24 01:46, Andrew Randrianasulu wrote:
пн, 8 янв. 2024 г., 09:13 Mark Filipak <markfilipak.imdb@gmail.com>:
On 1/8/24 00:26, Andrew Randrianasulu wrote:
пн, 8 янв. 2024 г., 05:14 Mark Filipak <markfilipak.imdb@gmail.com>:
What is it that you want to know?
I think I like to try and see bigger picture behind acronyms.
What acronyms?
SAR, DAR, PAR .....
DAR is a physical aspect (i.e., a W/H). It is the dots-by-lines aspect of the view. Note that I don't use the word "display" because that makes many people think of a whole screen. I use the word "view", instead, as in "lines per view", not "lines per display".
PAR is a physical aspect (i.e., a W/H). It is the pixels-by-rows aspect of the 'picture' matrix. Note that I use the word 'picture', an alias, because data matrices are not really pictures. But MPEG and the rest of the world call them "pictures" so I call them 'pictures'.
SAR is not a physical aspect, it's an aspect transform. It transforms pixels-by-rows to dots-by-lines. SAR = DAR/PAR means view(W/H)/'picture'(W/H). For example, (1024/576)/(720/576).
Details.
"DAR" means "display aspect ratio" and you probably know all about that. It's dpl/lpv, i.e., (dots per line)/(lines per view). DAR dpl/lpv 1024/576 = 16/9 for 16:9 'PAL', 768/576 = 4/3 for 4:3 'PAL', 853/480 = 16/9 for 16:9 'NTSC', 720/540 = 4/3 for 4:3 'NTSC'.
"PAR' means "picture aspect ratio". It's ppr/rpp, i.e., (pixels per row)/(rows per 'picture'). PAR ppr/rpp 720/576 = 5/4 for 16:9 'PAL', 720/576 = 5/4 for 4:3 'PAL', 720/480 = 3/2 for 16:9 'NTSC', 720/480 = 3/2 for 4:3 'NTSC'.
"SAR" means "sample aspect ratio". That term is from the days of flying spot film scanners. Modern SAR is actually not an aspect at all. It's a transform. SAR transforms pixels-by-rows into dots-by-lines [note1]. It's dpp/lpr, i.e., (dots per pixel)/(lines per row). 'SAR' dpp/lpr (dpl/ppr)/(lpv/rpp) [note2] (1024/720)/(576/576) = 1024/720 = 64/45 for 16:9 'PAL' -- 64 dots per 45 pixels, (768/720)/(576/576) = 768/720 = 16/15 for 4:3 'PAL' -- 16 dots per 15 pixels, (853/720)/(480/480) = 853/720 = 32/27 for 16:9 'NTSC' -- 32 dots per 27 pixels, (720/720)/(540/480) = 1/(540/480) = 1/(9/8) for 4:3 'NTSC' -- 9 lines per 8 rows [note3].
[note1] Though modern SAR is actually a transform -- a 'picture'-to-view transform (PVT) -- the "SAR" acronym has become so entrenched in the art that it would be impossible to get people to change to "PVT". I try to get around the issue by calling SAR-as-transform, 'SAR' (meaning it's an alias, not a real aspect ratio).
[note2] The following is not a 'stupid math trick', it is real. 'SAR' = dpp/lpr = (dpl/ppr)/(lpv/rpp) = (dpl/lpv)/(ppr/rpp) = DAR/PAR. For example, 'SAR' = dpp/lpr = (1024/720)/(576/576) = (1024/576)/(720/576) = (16/9)/(5/4) = DAR/PAR.
[note3] Why is 4:3 'NTSC' so different? Well, there's two ways to look at it: 1, for 4:3 'NTSC', 'SAR' is less than one while for the others, 'SAR' is greater than one, and 2, turning 4:3 'NTSC' into 640x480 would lose resolution whereas 720x540 preserves resolution. The difference is moot because TVs don't use 'SAR' anyway. What they do is look at the size of their screen (e.g., 1920x1080), look at DAR in the PES header (e.g. 4/3), compute the size of the view based on that DAR (e.g. 1440x1080), and scale directly (e.g., turn 4-by-4 pixel blocks into 8-by-9 dot blocks). That makes 'SAR' a kind of fiction (which it is in a way).
If you're unhappy with 'SAR', then just forget it. Know DAR and PAR though. Know them well.
it hard to forgot if libav* internals want it ;) And I want to fix this little bug of ours when we not setting it (and thus DAR indirectly) on encoding in some cases .... https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=summary our git, just in case. (I posted link before but at least on mobile (Android) gmail client switching between mails is slow task in itself) our current ah wondering about and around aspects: https://lists.cinelerra-gg.org/pipermail/cin/2024-January/thread.html cinelerra had interesting history down to very early 2000s, so some "aspects" (pun intended) of it are not very obvious from variable names used (just aspect_ratio for example)
-- Mark.
This is important to me. I sent it yesterday, but from the wrong account, so it didn't get to ffmpeg-user. If you somehow got 2 of them, please accept my apology. On 12/27/23 01:58, Kieran O Leary wrote:
On Tue 26 Dec 2023 at 22:53, Mark Filipak <markfilipak.imdb@gmail.com>
Oh, no! Mister Billipedia! Hahahaha... (where people who are as ill informed as you are, get to pontificate)
I think you must have misread the tone of Devin’s email, and I would hardly call him ill informed. His post was constructive and your language will only derail threads like this.
Oh, I did not mean it like that. I meant the general 'you' as in 'you, the reader', as in 'people who are as ill informed as _they_ are'. I sincerely didn't mean Devon. But you are entirely justified in your objection. You read it differently, but your reading is reasonable and reasoned, I must admit. I sincerely apologize. I meant no harm. I certainly didn't mean to denigrate Devon. I only meant to denigrate Wikipedia. Peace and love. Please forgive my overly hasty post. I am appropriately chastened. In the future, I will try harder to express my true meanings. So sorry -- Mark. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
This is important to me. I sent it yesterday, but from the wrong account, so it wasn't accepted by ffmpeg-user. If you somehow got 2 of them, please accept my apology. (Between TBird's quirks and Gmail's quirks, email is driving me nuts.) On 12/27/23 01:58, Kieran O Leary wrote:
On Tue 26 Dec 2023 at 22:53, Mark Filipak <markfilipak.imdb@gmail.com> wrote:
Oh, no! Mister Billipedia! Hahahaha... (where people who are as ill informed as you are, get to pontificate)
I think you must have misread the tone of Devin’s email, and I would hardly call him ill informed. His post was constructive and your language will only derail threads like this.
Oh, I did not mean it like that. I meant the general 'you' as in 'you, the reader', as in 'people who are as ill informed as _they_ are'. I sincerely didn't mean Devon. But you are entirely justified in your objection. You read it differently, but your reading is reasonable and reasoned, I must admit. I sincerely apologize. I meant no harm. I certainly didn't mean to denigrate Devon. I only meant to denigrate Wikipedia. Peace and love. Please forgive my overly hasty post. I am appropriately chastened. In the future, I will try harder to express my true meanings. So sorry -- Mark.
On 12/25/2023 1:04 AM, Mark Filipak wrote:
Huh? "720x480 video with a display aspect ratio of 16:9" is what's on most 'NTSC' DVDs.
Huh? The vast majority of DVDs I've handled were 4:3 then maybe letterboxed to only show some wide-screen size (like 2.33:1). Only more recent content was shot at 16:9, but AFAIK it's still coming of the disk as 720x480 or 704x480 (don't forget that one). Remember that almost everything involved with color NTSC is a kludge, and digital encoding of it is a kludge built on a kludge. Do not expect too much logic. z!
Hi On Tue 26 Dec 2023 at 17:25, Carl Zwanzig <cpz@tuunq.com> wrote:
On 12/25/2023 1:04 AM, Mark Filipak wrote:
Huh? "720x480 video with a display aspect ratio of 16:9" is what's on
most
'NTSC' DVDs.
Huh? The vast majority of DVDs I've handled were 4:3 then maybe letterboxed to only show some wide-screen size (like 2.33:1).
This is the opposite of my experience where widescreen DVDs were encoded anamorphically and were de-squeezed to the correct DAR. Very few were 4:3 with burnt in letterboxes. Best, Kieran
On 12/26/23 14:37, Kieran O Leary wrote:
Hi
On Tue 26 Dec 2023 at 17:25, Carl Zwanzig <cpz@tuunq.com> wrote:
On 12/25/2023 1:04 AM, Mark Filipak wrote:
Huh? "720x480 video with a display aspect ratio of 16:9" is what's on
most
'NTSC' DVDs.
Huh? The vast majority of DVDs I've handled were 4:3 then maybe letterboxed to only show some wide-screen size (like 2.33:1).
This is the opposite of my experience where widescreen DVDs were encoded anamorphically and were de-squeezed to the correct DAR. Very few were 4:3 with burnt in letterboxes.
Best,
Kieran
The pre-2000/2001 DVDs labeled "Wide Screen" were letterboxed 4:3 DVDs that are also pillarboxed on 16:9 screens. I still have a couple of them. DVDs are not optically anamorphic in the sense that CinemaScope is anamorphic. They were simply sampled with the highest resolution available to flying-spot scanners of the era. I don't think the word "anamorphic" applies because 720x480 (or 720x576) are not pictures, they're data arrays populated by pixels (data). -- Mark.
On 26 Dec 2023, at 21:13, Mark Filipak <markfilipak.imdb@gmail.com> wrote:
How about stopping trolling if you know it all? The ‘imdb’ in your mail address makes you an even bigger jerk. Bouke
On 12/26/23 16:03, Bouke / edit 'B wrote:
On 26 Dec 2023, at 21:13, Mark Filipak <markfilipak.imdb@gmail.com> wrote:
How about stopping trolling if you know it all?
The ‘imdb’ in your mail address makes you an even bigger jerk.
It was a left over account from when imdb ended its forum. It means nothing. For a long time I used spoofed 'From:' addresses but neither Gmail or my ISP allows that any longer. I'd use my real email address but ffmpeg.org publishes email addresses in the archive. I'm sorry you think I'm trolling. I've been here for maybe 10 years and normally post maybe a half-dozen posts per year. Is that trolling?
Hi Devin, On 12/22/23 15:14, Devin Heitmueller wrote:
On Fri, Dec 22, 2023 at 2:38 PM Mark Filipak <markfilipak.imdb@gmail.com> wrote:
This page: https://ffmpeg.org/ffmpeg-utils.html 'says' this:
"The following abbreviations are recognized: "‘sntsc’ " 640x480"
What is it? I'm not aware that any such thing exists.
It's NTSC with square pixels...
How do you go from 720x480 to 640x480 without throwing away 80 pixels per line? Normally, 720x480 decodes to 720x540. Correction: Actually, 720x480 decodes to 720x480. It SAR-scales to 720x540 for display. My apologies.
(as opposed to the more common pixel aspect ratio of 10:11 found with 720x480).
Devin
Umm... 10:11? What is that?
participants (7)
-
Andrew Randrianasulu -
Bouke / edit 'B -
Carl Zwanzig -
Devin Heitmueller -
Kieran O Leary -
Mark Filipak -
Mark Filipak