Am So., 7. Feb. 2021 um 03:45 Uhr schrieb Mark Filipak (ffmpeg)
<markfili...@bog.us>:
>
> On 02/06/2021 09:37 PM, Carl Eugen Hoyos wrote:
> > Am So., 7. Feb. 2021 um 03:27 Uhr schrieb Mark Filipak (ffmpeg)
> > <markfili...@bog.us>:
> >
> >> "not deinterlaced" == not this:
> >>
> >> pixel[0,0] pixel[0,1] ... pixel[0,in_w-1] pixel[2,0] pixel[2,1] ...
> >> pixel[in_h-2,in_w-1] ...
> >> pixel[1,0] pixel[1,1] ... pixel[1,in_w-1] pixel[3,0] pixel[3,1] ...
> >> pixel[in_h-1,in_w-1]
> >
> > In the terminology of the FFmpeg project (which is the only one
> > relevant on this mailing list), above is not called "deinterlaced".
>
> That's fine. I understand. If it's not called "deinterlaced", then what do I
> call it?
De-interleaved as done by the il filter.
The reason FFmpeg decoders (if not buggy) always output
interleaved ("non de-interleaved") images is foremost (at least
imo) that you cannot connect a CRT to the output of an FFmpeg
decoder and that no driver - gpu - screen combination I have
seen so far could correctly display it.
I also suspect that no encoder would correctly deal with it.
There may be other reasons.
I believe it makes little sense to document that we don't do
something that would be useless, the documentation is already
very long documenting design decisions that are less obvious.
Carl Eugen
PS:
Using above definition, both FFmpeg's hevc and j2k decoders
are buggy.
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
