Quoting Marton Balint (2024-10-23 15:19:27)
>
>
> On Tue, 22 Oct 2024, Anton Khirnov wrote:
>
> > Quoting Marton Balint (2024-10-22 20:35:52)
> >>
> >>
> >> On Tue, 22 Oct 2024, Anton Khirnov wrote:
> >>
> >>> Quoting Martin Schitter (2024-10-21 21:57:18)
> +static int pass_through(AVCodecC
On 23.10.24 15:19, Marton Balint wrote:
On Tue, 22 Oct 2024, Anton Khirnov wrote:
Quoting Marton Balint (2024-10-22 20:35:52)
I don't really want the MXF demuxer/muxer to do DNXUC parsing
What parsing is there to do? You just compare against the codec tag.
As far as I know, the codec tag
On Tue, 22 Oct 2024, Anton Khirnov wrote:
Quoting Marton Balint (2024-10-22 20:35:52)
On Tue, 22 Oct 2024, Anton Khirnov wrote:
Quoting Martin Schitter (2024-10-21 21:57:18)
+static int pass_through(AVCodecContext *avctx, AVFrame *frame, const AVPacket
*avpkt)
+{
+/* there is no ne
On 23.10.24 09:12, Diederick C. Niehorster wrote:
+ This decoder for DNxUncompressed video data is mostly based on
+ reverse engineering of output generated by DaVinci Resolve 19
+ but was later also checked against the SMPTE RDD 50 specification.
+
+ Not all DNxUncompressed pixel format varia
On Wed, Oct 23, 2024 at 8:44 AM James Almer wrote:
>
> On 10/21/2024 4:57 PM, Martin Schitter wrote:
> > ---
> > libavcodec/Makefile| 1 +
> > libavcodec/allcodecs.c | 1 +
> > libavcodec/dnxucdec.c | 338 +
> > 3 files changed, 340 insertions(
On 22.10.24 20:35, Marton Balint wrote:
On Tue, 22 Oct 2024, Anton Khirnov wrote:
I said this twice before already - every single format that uses
pass_through() should instead be exported by the demuxer as
AV_CODEC_ID_RAWVIDEO, because that's what it is.
I don't really want the MXF demuxer/
Quoting Marton Balint (2024-10-22 20:35:52)
>
>
> On Tue, 22 Oct 2024, Anton Khirnov wrote:
>
> > Quoting Martin Schitter (2024-10-21 21:57:18)
> >> +static int pass_through(AVCodecContext *avctx, AVFrame *frame, const
> >> AVPacket *avpkt)
> >> +{
> >> +/* there is no need to copy as the d
On Tue, 22 Oct 2024, Anton Khirnov wrote:
Quoting Martin Schitter (2024-10-21 21:57:18)
+static int pass_through(AVCodecContext *avctx, AVFrame *frame, const AVPacket
*avpkt)
+{
+/* there is no need to copy as the data already match
+ * a known pixel format */
+
+frame->buf[0] =
Quoting Martin Schitter (2024-10-21 21:57:18)
> +static int pass_through(AVCodecContext *avctx, AVFrame *frame, const
> AVPacket *avpkt)
> +{
> +/* there is no need to copy as the data already match
> + * a known pixel format */
> +
> +frame->buf[0] = av_buffer_ref(avpkt->buf);
I said
Quoting martin schitter (2024-10-22 01:40:07)
>
>
> On 21.10.24 22:44, James Almer wrote:
> >
> > That's not good...
> >
> > [...]
>
> Whenever and however I change it, there will allways be somebody who
> doesn't like it. !:(
>
> This time I spend a lot of time to modify the code as close a
On 22.10.24 04:37, James Almer wrote:
On 10/21/2024 8:51 PM, James Almer wrote:
On 10/21/2024 10:02 PM, martin schitter wrote:
I didn't participate in earlier rounds, but at least my opinion is
that we shouldn't add new pixel formats if they are only used for a
single codec and have no RIFF
On 10/21/2024 8:51 PM, James Almer wrote:
On 10/21/2024 10:02 PM, martin schitter wrote:
I know -- it's trivial to choose this way, but there has to be some
common agreement or docu, how it should be done, otherwise we run
circles.
I didn't participate in earlier rounds, but at least my opini
On 10/21/2024 10:02 PM, martin schitter wrote:
On 22.10.24 00:31, James Almer wrote:
On 10/21/2024 8:40 PM, martin schitter wrote:
On 21.10.24 22:44, James Almer wrote:
That's not good...
[...]
Whenever and however I change it, there will allways be somebody who
doesn't like it. !:(
My
On 22.10.24 00:31, James Almer wrote:
On 10/21/2024 8:40 PM, martin schitter wrote:
On 21.10.24 22:44, James Almer wrote:
That's not good...
[...]
Whenever and however I change it, there will allways be somebody who
doesn't like it. !:(
My point is, it's not a good idea to commit code th
On 10/21/2024 8:40 PM, martin schitter wrote:
On 21.10.24 22:44, James Almer wrote:
That's not good...
[...]
Whenever and however I change it, there will allways be somebody who
doesn't like it. !:(
My point is, it's not a good idea to commit code that's not tested.
Assuming that's wha
On 21.10.24 23:50, James Almer wrote:
On 10/21/2024 5:44 PM, James Almer wrote:
On 10/21/2024 4:57 PM, Martin Schitter wrote:
+ break;
+ case MKTAG('y','2','1','0'):
+ ret = fmt_frame(avctx, frame, avpkt,
AV_PIX_FMT_YUV422P10LE, 20, unpack_y210);
Y210 has no pi
On 10/21/2024 5:44 PM, James Almer wrote:
On 10/21/2024 4:57 PM, Martin Schitter wrote:
+ break;
+ case MKTAG('y','2','1','0'):
+ ret = fmt_frame(avctx, frame, avpkt,
AV_PIX_FMT_YUV422P10LE, 20, unpack_y210);
Y210 has no pixel format, and it's packed, not planar,
On 21.10.24 22:44, James Almer wrote:
That's not good...
[...]
Whenever and however I change it, there will allways be somebody who
doesn't like it. !:(
This time I spend a lot of time to modify the code as close as possible
to requests asked by one previous reviewer, who insisted, that
On 10/21/2024 4:57 PM, Martin Schitter wrote:
---
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/dnxucdec.c | 338 +
3 files changed, 340 insertions(+)
create mode 100644 libavcodec/dnxucdec.c
diff --git a/libavcodec/Mak
19 matches
Mail list logo
