Re: [FFmpeg-devel] [PATCH] avfilter/vf_subtitles: Respect YCbCr Matrix header

2024-10-15 Thread Ridley Combs via ffmpeg-devel 


> On Oct 13, 2024, at 05:45, arch1t3cht  wrote:
> 
> As specified in libass's ass_types.h, the colors or ASS_Images
> should be converted to YCbCr using the matrix/range specified in
> the track's YCbCrMatrix field (unless that field is set to YCBCR_NONE,
> and defaulting to TV.601 if the header is missing).
> 
> This does not affect any subtitles generated or transcoded by ffmpeg,
> since these contain a 'YCbCrMatrix: None' header.
> 
> Signed-off-by: arch1t3cht 
> ---
> libavfilter/vf_subtitles.c | 38 +-
> 1 file changed, 37 insertions(+), 1 deletion(-)
> 
> diff --git a/libavfilter/vf_subtitles.c b/libavfilter/vf_subtitles.c
> index de1cfa7d9e..ed1d12ca76 100644
> --- a/libavfilter/vf_subtitles.c
> +++ b/libavfilter/vf_subtitles.c
> @@ -88,6 +88,40 @@ static const int ass_libavfilter_log_level_map[] = {
> [7] = AV_LOG_DEBUG, /* MSGL_DBG2 */
> };
> 
> +static enum AVColorSpace ass_get_color_space(ASS_YCbCrMatrix ass_matrix, 
> enum AVColorSpace inlink_space) {
> +switch (ass_matrix) {
> +case YCBCR_NONE:return inlink_space;
> +case YCBCR_SMPTE240M_TV:
> +case YCBCR_SMPTE240M_PC:return AVCOL_SPC_SMPTE240M;
> +case YCBCR_FCC_TV:
> +case YCBCR_FCC_PC:  return AVCOL_SPC_FCC;
> +case YCBCR_BT709_TV:
> +case YCBCR_BT709_PC:return AVCOL_SPC_BT709;
> +case YCBCR_BT601_TV:
> +case YCBCR_BT601_PC:
> +case YCBCR_DEFAULT:
> +case YCBCR_UNKNOWN:
> +default:return AVCOL_SPC_SMPTE170M;
> +}
> +}
> +
> +static enum AVColorRange ass_get_color_range(ASS_YCbCrMatrix ass_matrix, 
> enum AVColorRange inlink_range) {
> +switch (ass_matrix) {
> +case YCBCR_NONE:return inlink_range;
> +case YCBCR_SMPTE240M_PC:
> +case YCBCR_FCC_PC:
> +case YCBCR_BT709_PC:
> +case YCBCR_BT601_PC:return AVCOL_RANGE_JPEG;
> +case YCBCR_SMPTE240M_TV:
> +case YCBCR_FCC_TV:
> +case YCBCR_BT709_TV:
> +case YCBCR_BT601_TV:
> +case YCBCR_DEFAULT:
> +case YCBCR_UNKNOWN:
> +default:return AVCOL_RANGE_MPEG;
> +}
> +}
> +
> static void ass_log(int ass_level, const char *fmt, va_list args, void *ctx)
> {
> const int ass_level_clip = av_clip(ass_level, 0,
> @@ -147,7 +181,9 @@ static int config_input(AVFilterLink *inlink)
> {
> AssContext *ass = inlink->dst->priv;
> 
> -ff_draw_init2(&ass->draw, inlink->format, inlink->colorspace, 
> inlink->color_range,
> +ff_draw_init2(&ass->draw, inlink->format,
> +  ass_get_color_space(ass->track->YCbCrMatrix, 
> inlink->colorspace),
> +  ass_get_color_range(ass->track->YCbCrMatrix, 
> inlink->color_range),
>   ass->alpha ? FF_DRAW_PROCESS_ALPHA : 0);
> 
> ass_set_frame_size  (ass->renderer, inlink->w, inlink->h);
> -- 
> 2.47.0
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

LGTM; will push on Friday if nobody objects.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/assenc: normalize line endings to \n

2024-02-13 Thread Ridley Combs via ffmpeg-devel 


> On Feb 13, 2024, at 04:33, Martin Storsjö  wrote:
> 
> On Tue, 13 Feb 2024, Ridley Combs via ffmpeg-devel wrote:
> 
>>> On Feb 13, 2024, at 01:28, Anton Khirnov  wrote:
>>> Quoting Martin Storsjö (2024-02-12 12:31:29)
>>>> On Mon, 12 Feb 2024, Hendrik Leppkes wrote:
>>>>> On Mon, Feb 12, 2024 at 11:22 AM Martin Storsjö  wrote:
>>>>>>> diff --git a/.gitattributes b/.gitattributes
>>>>>>> index 5a19b963b6..a900528e47 100644
>>>>>>> --- a/.gitattributes
>>>>>>> +++ b/.gitattributes
>>>>>>> @@ -1,2 +1 @@
>>>>>>> *.pnm -diff -text
>>>>>>> -tests/ref/fate/sub-scc eol=crlf
>>>>>> This change seems to have had a tricky effect on the
>>>>>> tests/ref/fate/sub-scc file. Previously, when checked out, users got the
>>>>>> file with CRLF newlines. When updating to this git commit, or past it,
>>>>>> that file remains untouched, with CRLF still present, and the
>>>>>> fate-sub-scc test fails. If one does "rm tests/ref/fate/sub-scc; git
>>>>>> checkout tests/ref/fate/sub-scc", then the file does get restored with LR
>>>>>> newlines, and the test passes.
>>>>>> It's easy to do this change manually in the source checkout of a fate
>>>>>> runner, but I'm not sure how easily we get all fate instances fixed that
>>>>>> way - currently this test is failing in most of them.
>>>>> Can this be fixed by restoring the .gitattribute entry but with eol=lf?
>>>>> Not sure if Git would reset the file then.
>>>> No, that doesn't seem to make any difference. Not sure if there are any 
>>>> other straightforward/elegant fixes, short of renaming the file, which I 
>>>> guess would require renaming the test itself.
>>> I'm fine with renaming the test, unless anyone has a better fix.
>> 
>> We could probably tweak the fate runner script to make sure this gets fixed 
>> up; can anyone try this patch on one of the affected machines? 
>> https://gist.github.com/rcombs/c2ad470bf36c5cbd3fc33e699330eb15
> 
> That doesn't seem to make any difference.
> 
> Also, updating fate.sh doesn't necessarily propagate automatically to runners 
> - in order to run fate, one needs to run fate.sh before it even clones/checks 
> out the directory where it fetches the latest source. So unless one later has 
> changed one's setup, to invoke a fate.sh from the checkout, most fate runners 
> just use whatever copy of fate.sh they had when it was set up.
> 
>> Alternately, we could set -text on all fate ref files, or explicitly set 
>> eol=of for them, to ensure their line endings never get rewritten like this 
>> regardless of git config. I think either of these solutions would fix this 
>> in fate, but only after the fix commit gets checked out *followed by* at 
>> least one other commit.
> 
> Neither of those seem to make any difference either.
> 
> It's quite easy to test for one self:
> 
> $ git checkout -b experiment
> $ 
> $ 
> 
> $ git checkout 7bf1b9b3576~ # Reset original state, for testing
> $ rm tests/ref/fate/sub-scc; git checkout tests/ref/fate/sub-scc
> $ vi tests/ref/fate/sub-scc # inspect that the file originally has CRLF
> $ git checkout experiment~ # check out the commit setting attributes
> $ git checkout experiment # check out the next commit, with the new 
> attributes set
> $ vi tests/ref/fate/sub-scc # observe that the file still has CRLF
> 
> $ git checkout --detach
> $ git -c core.autocrlf=false reset --hard 7bf1b9b3576
> $ vi tests/ref/fate/sub-scc # observe that the file still has CRLF

It looks like checkout has different behavior from reset, and fate uses a hard 
reset.
To test, I committed the change adding tests/ref/** -text, unix2dos'd 
tests/ref/fate/sub-scc, then ran git -c core.autocrlf=true reset --quiet 
--hard; this dos2unix'd the file as expected when run with a working tree 
containing the .gitattributes change (but not otherwise).

> 
> 
> It seems to me (I haven't trid to dig into manuals) that the attribute gets 
> stuck in whatever form it was when the file was first created in the workdir. 
> E.g. doing a "git checkout d1df72a702~" (the commit before the file was 
> originally added) followed by "git checkout 7bf1b9b3576" does fix it. This is 
> at least observed with git 2.25.1. Not sure if this is intended behaviour or 
> a bug from git's side.

Git doesn't have any "memory" of the CRLFiness of a file beyond the content of 
the file itself (whether in the working tree or in committed blobs). It just 
doesn't necessarily replace every file in checkout invocations when they differ 
only in line endings. Windows was a mistake.

> 
> // Martin

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/assenc: normalize line endings to \n

2024-02-13 Thread Ridley Combs via ffmpeg-devel 


> On Feb 13, 2024, at 01:28, Anton Khirnov  wrote:
> 
> Quoting Martin Storsjö (2024-02-12 12:31:29)
>> On Mon, 12 Feb 2024, Hendrik Leppkes wrote:
>> 
>>> On Mon, Feb 12, 2024 at 11:22 AM Martin Storsjö  wrote:
> 
> diff --git a/.gitattributes b/.gitattributes
> index 5a19b963b6..a900528e47 100644
> --- a/.gitattributes
> +++ b/.gitattributes
> @@ -1,2 +1 @@
> *.pnm -diff -text
> -tests/ref/fate/sub-scc eol=crlf
 
 This change seems to have had a tricky effect on the
 tests/ref/fate/sub-scc file. Previously, when checked out, users got the
 file with CRLF newlines. When updating to this git commit, or past it,
 that file remains untouched, with CRLF still present, and the
 fate-sub-scc test fails. If one does "rm tests/ref/fate/sub-scc; git
 checkout tests/ref/fate/sub-scc", then the file does get restored with LR
 newlines, and the test passes.
 
 It's easy to do this change manually in the source checkout of a fate
 runner, but I'm not sure how easily we get all fate instances fixed that
 way - currently this test is failing in most of them.
 
>>> 
>>> Can this be fixed by restoring the .gitattribute entry but with eol=lf?
>>> Not sure if Git would reset the file then.
>> 
>> No, that doesn't seem to make any difference. Not sure if there are any 
>> other straightforward/elegant fixes, short of renaming the file, which I 
>> guess would require renaming the test itself.
> 
> I'm fine with renaming the test, unless anyone has a better fix.

We could probably tweak the fate runner script to make sure this gets fixed up; 
can anyone try this patch on one of the affected machines? 
https://gist.github.com/rcombs/c2ad470bf36c5cbd3fc33e699330eb15

Alternately, we could set -text on all fate ref files, or explicitly set eol=of 
for them, to ensure their line endings never get rewritten like this regardless 
of git config. I think either of these solutions would fix this in fate, but 
only after the fix commit gets checked out *followed by* at least one other 
commit.

> 
> -- 
> Anton Khirnov
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org 
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org  with 
> subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v1 2/5] avformat: add muxer support for H266/VVC

2024-01-18 Thread Ridley Combs via ffmpeg-devel 


> On Jan 4, 2024, at 16:31, James Almer  wrote:
> 
> On 11/3/2023 6:57 AM, Thomas Siedel wrote:
>> Add muxer for vvcc byte stream format.
>> Add AV_CODEC_ID_VVC to ff_mp4_obj_type.
>> Add AV_CODEC_ID_VVC to ISO Media codec (VvcConfigurationBox vvi1,
>> vvc1 defined in ISO/IEC 14496-15:2021).
>> Add VvcConfigurationBox vvcC which extends FullBox type in
>> ISO/IEC 14496-15:2021.
>> Add ff_vvc_muxer to RAW muxers.
>> Signed-off-by: Thomas Siedel 
>> ---
>>  libavformat/Makefile|   6 +-
>>  libavformat/isom.c  |   1 +
>>  libavformat/isom_tags.c |   3 +
>>  libavformat/mov.c   |   6 +
>>  libavformat/movenc.c|  41 +-
>>  libavformat/vvc.c   | 998 
>>  libavformat/vvc.h   |  99 
>>  7 files changed, 1150 insertions(+), 4 deletions(-)
>>  create mode 100644 libavformat/vvc.c
>>  create mode 100644 libavformat/vvc.h
>> diff --git a/libavformat/Makefile b/libavformat/Makefile
>> index 329055ccfd..595f6bdf08 100644
>> --- a/libavformat/Makefile
>> +++ b/libavformat/Makefile
>> @@ -341,7 +341,7 @@ OBJS-$(CONFIG_MATROSKA_DEMUXER)  += 
>> matroskadec.o matroska.o  \
>>  oggparsevorbis.o 
>> vorbiscomment.o \
>>  qtpalette.o replaygain.o 
>> dovi_isom.o
>>  OBJS-$(CONFIG_MATROSKA_MUXER)+= matroskaenc.o matroska.o \
>> -av1.o avc.o hevc.o \
>> +av1.o avc.o hevc.o vvc.o\
>>  flacenc_header.o avlanguage.o \
>>  vorbiscomment.o wv.o dovi_isom.o
>>  OBJS-$(CONFIG_MCA_DEMUXER)   += mca.o
>> @@ -363,7 +363,7 @@ OBJS-$(CONFIG_MODS_DEMUXER)  += mods.o
>>  OBJS-$(CONFIG_MOFLEX_DEMUXER)+= moflex.o
>>  OBJS-$(CONFIG_MOV_DEMUXER)   += mov.o mov_chan.o mov_esds.o \
>>  qtpalette.o replaygain.o 
>> dovi_isom.o
>> -OBJS-$(CONFIG_MOV_MUXER) += movenc.o av1.o avc.o hevc.o 
>> vpcc.o \
>> +OBJS-$(CONFIG_MOV_MUXER) += movenc.o av1.o avc.o hevc.o 
>> vvc.o vpcc.o \
>>  movenchint.o mov_chan.o rtp.o \
>>  movenccenc.o movenc_ttml.o 
>> rawutils.o \
>>  dovi_isom.o evc.o
>> @@ -516,7 +516,7 @@ OBJS-$(CONFIG_RTP_MUXER) += rtp.o
>>  \
>>  rtpenc_vp8.o  \
>>  rtpenc_vp9.o\
>>  rtpenc_xiph.o \
>> -avc.o hevc.o
>> +avc.o hevc.o vvc.o
>>  OBJS-$(CONFIG_RTSP_DEMUXER)  += rtsp.o rtspdec.o httpauth.o \
>>  urldecode.o
>>  OBJS-$(CONFIG_RTSP_MUXER)+= rtsp.o rtspenc.o httpauth.o \
>> diff --git a/libavformat/isom.c b/libavformat/isom.c
>> index 6d019881e5..9fbccd4437 100644
>> --- a/libavformat/isom.c
>> +++ b/libavformat/isom.c
>> @@ -36,6 +36,7 @@ const AVCodecTag ff_mp4_obj_type[] = {
>>  { AV_CODEC_ID_MPEG4   , 0x20 },
>>  { AV_CODEC_ID_H264, 0x21 },
>>  { AV_CODEC_ID_HEVC, 0x23 },
>> +{ AV_CODEC_ID_VVC , 0x33 },
>>  { AV_CODEC_ID_AAC , 0x40 },
>>  { AV_CODEC_ID_MP4ALS  , 0x40 }, /* 14496-3 ALS */
>>  { AV_CODEC_ID_MPEG2VIDEO  , 0x61 }, /* MPEG-2 Main */
>> diff --git a/libavformat/isom_tags.c b/libavformat/isom_tags.c
>> index a575b7c160..705811e950 100644
>> --- a/libavformat/isom_tags.c
>> +++ b/libavformat/isom_tags.c
>> @@ -123,6 +123,9 @@ const AVCodecTag ff_codec_movvideo_tags[] = {
>>  { AV_CODEC_ID_HEVC, MKTAG('d', 'v', 'h', 'e') }, /* HEVC-based Dolby 
>> Vision derived from hev1 */
>>   /* dvh1 is handled 
>> within mov.c */
>>  +{ AV_CODEC_ID_VVC, MKTAG('v', 'v', 'i', '1') },  /* VVC/H.266 which 
>> indicates parameter sets may be in ES */
>> +{ AV_CODEC_ID_VVC, MKTAG('v', 'v', 'c', '1') },  /* VVC/H.266 which 
>> indicates parameter shall not be in ES */
>> +
>>  { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '1') }, /* AVC-1/H.264 */
>>  { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '2') },
>>  { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '3') },
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index e8efccf6eb..11b43ac135 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -2117,6 +2117,11 @@ static int mov_read_glbl(MOVContext *c, AVIOContext 
>> *pb, MOVAtom atom)
>>  if ((uint64_t)atom.size > (1<<30))
>>  return AVERROR_INVALIDDATA;
>>  +if (atom.type == MKTAG('v','v','c','C')) {
>> +avio_rb32(pb);
> 
> avio_skip(pb, 4);
> 
>> +

Re: [FFmpeg-devel] [ANNOUNCE] upcoming GA vote

2023-10-25 Thread Ridley Combs via ffmpeg-devel 
Received.

> On Oct 25, 2023, at 07:22, Rémi Denis-Courmont  wrote:
> 
> Hi,
> 
> I am not on the GA, but there are probably people with my locale on the GA. 
> And it seems that the voting system hits a Perl syntax error if your browser 
> locale is set to French.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avdevice/v4l2: Switch to wrapped AVFrames and implement strides

2023-09-29 Thread Ridley Combs via ffmpeg-devel 



> On Sep 29, 2023, at 00:52, Asahi Lina via ffmpeg-devel 
>  wrote:
> 
> V4L2 provides a line stride to the client for hardware that has
> alignment requirements. rawvideo cannot represent this, so switch to
> wrapped_avframe for raw video formats and calculate the plane strides
> manually.
> 
> This is slightly messy because the existing helper APIs expect
> dimensions and an alignment value, while v4l2 provides the stride of
> plane 0 and the subsequent plane strides are implied, so we need to
> open-code the logic to calculate the plane strides.
> 
> This makes vertical video work properly on Apple Macs with "1080p"
> cameras, which are actually square and can support resolutions like
> 1080x1920, which require stride padding to a multiple of 64 bytes.
> 
> In principle, this could be extended to support the V4L2 multiplanar
> API, though there seem to be practically no capture (not M2M) drivers
> that support this, so it's not terribly useful right now.
> 
> Signed-off-by: Asahi Lina 
> ---
> libavdevice/v4l2-common.c |  68 +++
> libavdevice/v4l2.c| 138 +++---
> 2 files changed, 151 insertions(+), 55 deletions(-)
> 
> diff --git a/libavdevice/v4l2-common.c b/libavdevice/v4l2-common.c
> index b5b4448a3154..944ffe3d87e1 100644
> --- a/libavdevice/v4l2-common.c
> +++ b/libavdevice/v4l2-common.c
> @@ -19,53 +19,53 @@
> #include "v4l2-common.h"
> 
> const struct fmt_map ff_fmt_conversion_table[] = {
> -//ff_fmt  codec_id  v4l2_fmt
> -{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV420  },
> -{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YVU420  },
> -{ AV_PIX_FMT_YUV422P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV422P },
> -{ AV_PIX_FMT_YUYV422, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUYV},
> -{ AV_PIX_FMT_UYVY422, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_UYVY},
> -{ AV_PIX_FMT_YUV411P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV411P },
> -{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YUV410  },
> -{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_YVU410  },
> -{ AV_PIX_FMT_RGB555LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB555  },
> -{ AV_PIX_FMT_RGB555BE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB555X },
> -{ AV_PIX_FMT_RGB565LE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB565  },
> -{ AV_PIX_FMT_RGB565BE,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB565X },
> -{ AV_PIX_FMT_BGR24,   AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_BGR24   },
> -{ AV_PIX_FMT_RGB24,   AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB24   },
> +//ff_fmt  codec_id v4l2_fmt
> +{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_YUV420  
> },
> +{ AV_PIX_FMT_YUV420P, AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_YVU420  
> },
> +{ AV_PIX_FMT_YUV422P, AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_YUV422P 
> },
> +{ AV_PIX_FMT_YUYV422, AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_YUYV
> },
> +{ AV_PIX_FMT_UYVY422, AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_UYVY
> },
> +{ AV_PIX_FMT_YUV411P, AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_YUV411P 
> },
> +{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_YUV410  
> },
> +{ AV_PIX_FMT_YUV410P, AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_YVU410  
> },
> +{ AV_PIX_FMT_RGB555LE,AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_RGB555  
> },
> +{ AV_PIX_FMT_RGB555BE,AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_RGB555X 
> },
> +{ AV_PIX_FMT_RGB565LE,AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_RGB565  
> },
> +{ AV_PIX_FMT_RGB565BE,AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_RGB565X 
> },
> +{ AV_PIX_FMT_BGR24,   AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_BGR24   
> },
> +{ AV_PIX_FMT_RGB24,   AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_RGB24   
> },
> #ifdef V4L2_PIX_FMT_XBGR32
> -{ AV_PIX_FMT_BGR0,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_XBGR32  },
> -{ AV_PIX_FMT_0RGB,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_XRGB32  },
> -{ AV_PIX_FMT_BGRA,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_ABGR32  },
> -{ AV_PIX_FMT_ARGB,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_ARGB32  },
> +{ AV_PIX_FMT_BGR0,AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_XBGR32  
> },
> +{ AV_PIX_FMT_0RGB,AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_XRGB32  
> },
> +{ AV_PIX_FMT_BGRA,AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_ABGR32  
> },
> +{ AV_PIX_FMT_ARGB,AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_ARGB32  
> },
> #endif
> -{ AV_PIX_FMT_BGR0,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_BGR32   },
> -{ AV_PIX_FMT_0RGB,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_RGB32   },
> -{ AV_PIX_FMT_GRAY8,   AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_GREY},
> +{ AV_PIX_FMT_BGR0,AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_BGR32   
> },
> +{ AV_PIX_FMT_0RGB,AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX_FMT_RGB32   
> },
> +{ AV_PIX_FMT_GRAY8,   AV_CODEC_ID_WRAPPED_AVFRAME, V4L2_PIX