[FFmpeg-devel] [PATCH 01/11] avformat/rtpdec_rfc4175: use rawvideo for uyvy422

[lance.lmwang at gmail.com]

On Wed, Nov 24, 2021 at 04:54:01AM +0100, Lynne wrote:
> 23 Nov 2021, 23:33 by lance.lmwang at gmail.com:
> 
> > On Fri, Nov 12, 2021 at 06:22:06PM +0800, lance.lmwang at gmail.com wrote:
> >
> >> From: Limin Wang <lance.lmwang at gmail.com>
> >>
> >> Signed-off-by: Limin Wang <lance.lmwang at gmail.com>
> >> ---
> >>  libavformat/rtpdec_rfc4175.c | 4 +++-
> >>  1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/libavformat/rtpdec_rfc4175.c b/libavformat/rtpdec_rfc4175.c
> >> index f50cad7..f13736b 100644
> >> --- a/libavformat/rtpdec_rfc4175.c
> >> +++ b/libavformat/rtpdec_rfc4175.c
> >> @@ -55,9 +55,11 @@ static int rfc4175_parse_format(AVStream *stream, PayloadContext *data)
> >>  if (data->depth == 8) {
> >>  data->pgroup = 4;
> >>  pixfmt = AV_PIX_FMT_UYVY422;
> >> +            stream->codecpar->codec_id = AV_CODEC_ID_RAWVIDEO;
> >>  } else if (data->depth == 10) {
> >>  data->pgroup = 5;
> >>  pixfmt = AV_PIX_FMT_YUV422P10;
> >> +            stream->codecpar->codec_id = AV_CODEC_ID_BITPACKED;
> >>  } else {
> >>  return AVERROR_INVALIDDATA;
> >>  }
> >> @@ -268,7 +270,7 @@ static int rfc4175_handle_packet(AVFormatContext *ctx, PayloadContext *data,
> >>  const RTPDynamicProtocolHandler ff_rfc4175_rtp_handler = {
> >>  .enc_name           = "raw",
> >>  .codec_type         = AVMEDIA_TYPE_VIDEO,
> >> -    .codec_id           = AV_CODEC_ID_BITPACKED,
> >> +    .codec_id           = AV_CODEC_ID_NONE,
> >>  .priv_data_size     = sizeof(PayloadContext),
> >>  .parse_sdp_a_line   = rfc4175_parse_sdp_line,
> >>  .parse_packet       = rfc4175_handle_packet,
> >> --
> >>
> >
> > Plan to push the patchset in two days. 
> >
> 
> This patchset was NAK'd because it breaks the API.
> And I'm giving it another NAK.
> 
> The entire point of bitpacked is to serve as a generic codec
> for bitpacked content, based on the input pixel format, whether
> it'd be 10 bit or 12 or 14 bit, or even 9 bit. Absolutely no reason
> to remove it. s210 is not an official name either.
> So no, do not introduce an s210 encoder, or a decoder, or a
> new pixel format, or even a new codec ID, extend what we
> already have.

thanks for your comments, if you prefer to use bitpacked codec, I'll
update the patchset to use it still. Consdiering for the API, I'll
not remove the code even uyvy422 will not use bitpacked anymore.

But to support rtp output, I'll add bitpacked encoder, do you think it's OK?

> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".

-- 
Thanks,
Limin Wang