---
fftools/ffmpeg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 01f04103cf..fe067007ea 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2107,7 +2107,7 @@ static void check_decode_result(InputStream *ist, int
*got_output, i
---
fftools/ffmpeg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 01f04103cf..aaeabe512b 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2107,7 +2107,7 @@ static void check_decode_result(InputStream *ist, int
*got_output, i
Good point, thanks for the review, I updated the patch to display the
incremented frame number as suggested.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or emai
---
fftools/ffmpeg.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 01f04103cf..43bd47ded4 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2108,8 +2108,10 @@ static void check_decode_result(InputStream *ist, int
*got_outpu
---
libavformat/mxf.h| 1 +
libavformat/mxfdec.c | 20 +++-
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/libavformat/mxf.h b/libavformat/mxf.h
index fc587f19f0..3fb3c6d74d 100644
--- a/libavformat/mxf.h
+++ b/libavformat/mxf.h
@@ -49,6 +49,7 @@ enum MXFMetada
---
libavformat/mxf.h| 1 +
libavformat/mxfdec.c | 32 +++-
2 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/libavformat/mxf.h b/libavformat/mxf.h
index fc587f19f0..3fb3c6d74d 100644
--- a/libavformat/mxf.h
+++ b/libavformat/mxf.h
@@ -49,6 +49,7 @@ e
> The rgb48ToUV and rgb48ToY funcs in input.c use the formula I'm using.
rgb64ToUV and rgb64ToY use it too, might be an opportunity to reduce code
duplication.
I ran into this while working on related precision issues (color range
conversion being precise only for 8bits) and just used the same fo
Le lun. 14 sept. 2020 à 10:40, Tomas Härdin a écrit :
> sön 2020-09-13 klockan 23:42 +0100 skrev Rémi Achard:
> >
> > @@ -855,15 +857,19 @@ static int mxf_read_cryptographic_context(void
> *arg, AVIOContext *pb, int tag, i
> >
> > static int mxf_read_strong_ref_
e
outside mxf_read_strong_ref_array back to mxf_read_generic_descriptor or
this involve more structural changes ?
Le lun. 14 sept. 2020 à 11:37, Tomas Härdin a écrit :
> mån 2020-09-14 klockan 10:48 +0100 skrev Rémi Achard:
> > > Why this added hunk? Appending strong refs like
Hi,
As you are probably aware, the libopenjpeg decoder is not able to interpret
cinema jp2k mxf correctly, the pixel format being assigned as rgb48 instead
of xyz12 as it should. Note that ffmpeg native jp2k decoder parse the RSIZ
descriptor from the jp2k bitstream and is able to correctly assign
m a different Descriptor structure
than the one used for eg. width and height parameters
* Currently the pixel_format is only passed on for RAWVIDEO codec, so
it would require doing that for JP2K and potentially others as well
Le dim. 30 août 2020 à 18:22, Rémi Achard a écrit :
> Hi,
>
> * 3D SMPTE MXF
Typo, this is 2D SMPTE MXF, there are 3D versions in that same repo
however, but it probably don't matter much here.
Le mar. 1 sept. 2020 à 11:06, Rémi Achard a écrit :
> > Do you have a sample that does not work with the native decoder?
>
> According to
ntinue to work on trying to fix mxfdec.c anyway, thanks.
Le mar. 1 sept. 2020 à 18:18, Carl Eugen Hoyos a
écrit :
> Am Di., 1. Sept. 2020 um 12:14 Uhr schrieb Rémi Achard <
> remiach...@gmail.com>:
> >
> > > Do you have a sample that does not work with the native de
> Sure, here are some comparisons I just made, please note the huge
difference in speed between current master and n4.0 that I picked as a
representative of the state of the decoder back then.
Also worth noting that the n4.0 decoder was not even able to transcode the
full sequence properly and out
ize= 70102kB time=00:00:01.97
bitrate=290149.4kbits/s speed=0.182x
jpeg2000 (n4.0)
frame= 50 fps=3.0 q=-0.0 Lsize= 36176kB time=00:00:01.02
bitrate=290281.1kbits/s dup=0 drop=46 speed=0.0605x
Le mar. 1 sept. 2020 à 18:39, Carl Eugen Hoyos a
écrit :
> Am Di., 1. Sept. 2020 um 19:32 Uhr schrie
{ {
0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x3B,0x00
}, mxf_read_track, sizeof(MXFTrack), Track }, /* Generic Track */
{ {
0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x14,0x00
}, mxf_read_timecode_component, sizeof(MXFTimecodeCompon
b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x3B,0x00
}, mxf_read_track, sizeof(MXFTrack), Track }, /* Generic Track */
{ {
0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x14,0x00
}, mxf_read_timecode_component, sizeof(MXFTimecodeComponent),
TimecodeComponent },
Le mar.
17 matches
Mail list logo
