[FFmpeg-user] sntsc

[Andrew Randrianasulu]

пн, 8 янв. 2024 г., 09:13 Mark Filipak <markfilipak.imdb at gmail.com>:

> On 1/8/24 00:26, Andrew Randrianasulu wrote:
> > пн, 8 янв. 2024 г., 05:14 Mark Filipak <markfilipak.imdb at 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.
>
> > https://lurkertech.com/lg/video-systems/#480i
>
> 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 at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
>