On Fri, Mar 15, 2019, 11:34 PM Reto Kromer Ben Hutchinson wrote:
>
> >What is top posting? I'll try to avoid it if I know what it is.
>
> Then please "google" it. Thanks!
>
> https://ffmpeg.org/contact.html#MailingLists
> https://en.wikipedia.org/wiki/Posting_style#Top-posting
>
>
Ben Hutchinson wrote:
>What is top posting? I'll try to avoid it if I know what it is.
Then please "google" it. Thanks!
https://ffmpeg.org/contact.html#MailingLists
https://en.wikipedia.org/wiki/Posting_style#Top-posting
___
ffmpeg-devel mailing list
So what you are saying is that "-pix_fmt yuv420p -color_range 2" should
produce the same output as "-pix_fmt yuvj420p" (both producing YUV video
with full range 0 to 255)? Unfortunately I tried that, and it doesn't work.
I saved the FFMPEG outputs to "-f rawvideo" and then looked at the
individual
What is top posting? I'll try to avoid it if I know what it is.
On Fri, Mar 15, 2019 at 5:21 PM Hendrik Leppkes wrote:
> On Fri, Mar 15, 2019 at 10:13 PM Ben Hutchinson wrote:
> >
> > Also, on another note, why don't we have yuvj410p as a video format? Each
> > chroma-subsampled versionof yuv (
On Fri, Mar 15, 2019 at 10:13 PM Ben Hutchinson wrote:
>
> Also, on another note, why don't we have yuvj410p as a video format? Each
> chroma-subsampled versionof yuv (partial range YUV) format should have an
> equivalent chroma-subsampled version of yuvj (full range yuv). This would
> allow vario
Also, on another note, why don't we have yuvj410p as a video format? Each
chroma-subsampled versionof yuv (partial range YUV) format should have an
equivalent chroma-subsampled version of yuvj (full range yuv). This would
allow various experimental setups to be tested.
On Fri, Mar 15, 2019 at 1:00
Doesn't SDL support YUV444 as a YUV format? Or does it only support YUV420?
Also, thanks for the tip about -vf format=bgra
On Fri, Mar 15, 2019 at 1:00 AM Gyan wrote:
>
>
> On 15-03-2019 12:05 PM, Ben Hutchinson wrote:
> > Note that it does not matter what pixel format the encoder uses (j or
> >
On 15-03-2019 12:05 PM, Ben Hutchinson wrote:
Note that it does not matter what pixel format the encoder uses (j or
non-j). This bug is only present in the decoder, and only when I select the
non-j version of a yuv pixel format. This bug is present in the ffplay
decoder (possibly also in the ff
When I decode rawvideo yuv444p in ffplay that was encoded in ffmpeg (using
the test source called "testsrc"), I notice there is blurring between
adjacent colors (both horizontally and vertically), which would typically
be present in yuv420p. I can avoid this by switching the decoder to use a
pixel
