date:20181012

[FFmpeg-devel] [PATCH] avformat/utils: Never store negative values in last_IP_duration

2018-10-12 Thread Michael Niedermayer

Fixes: integer overflow compute_pkt_fields()
Fixes: compute_pkt_usan

Reported-by: Thomas Guilbert 
Signed-off-by: Michael Niedermayer 
---
 libavformat/utils.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index fa3699daef..93e588ee1e 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1352,7 +1352,7 @@ static void compute_pkt_fields(AVFormatContext *s, 
AVStream *st,
 
 /* This is tricky: the dts must be incremented by the duration
  * of the frame we are displaying, i.e. the last I- or P-frame. */
-if (st->last_IP_duration == 0)
+if (st->last_IP_duration == 0 && (uint64_t)pkt->duration <= 
INT32_MAX)
 st->last_IP_duration = pkt->duration;
 if (pkt->dts != AV_NOPTS_VALUE)
 st->cur_dts = pkt->dts + st->last_IP_duration;
@@ -1364,7 +1364,8 @@ static void compute_pkt_fields(AVFormatContext *s, 
AVStream *st,
 next_pts != AV_NOPTS_VALUE)
 pkt->pts = next_dts;
 
-st->last_IP_duration = pkt->duration;
+if ((uint64_t)pkt->duration <= INT32_MAX)
+st->last_IP_duration = pkt->duration;
 st->last_IP_pts  = pkt->pts;
 /* Cannot compute PTS if not present (we can compute it only
  * by knowing the future. */
-- 
2.19.1

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

Re: [FFmpeg-devel] ffv1enc: question about "Cannot allocate worst case packet size, the encoding could fail"

2018-10-12 Thread Michael Niedermayer

On Fri, Oct 12, 2018 at 04:23:43PM +0200, Jerome Martinez wrote:
> On 12/10/2018 15:30, Jan Ekström wrote:
> >And while it seems like we're focusing on the arbitrary limit in
> >av_malloc (which is an issue of its own), I do note that for this
> >specific case this "worst case packed frame size" allocation heuristic
> >might have to be modified? Or at least explained if possible, so that
> >things can be improved in a proper way.
> 
> 
> Thank you for the feedback.
> I was focused on ff_alloc_packet2() which accepts 64-bit integers, and I did
> not check what is behind (limited to INT_MAX too).
> I understand now that this is a global limit, not tied to FFV1 encoder (but
> when this limit is removed from mem.h, there will be a review of ode which
> test this limit before calling ff_alloc_packet2()...).
> 
> As you said in the other answer, it was unrealistic to hit such limit in
> 2005, but now... 2 GB by packet is still huge (the input frame is "only" 128
> MB), but the multiplier used in FFV1 encoder makes the limit hit for "basic"
> 4K frames. 8K frames are approaching...
> A bit complex for me to remove this 2 GB  limit for sure everywhere :(, so I
> try to find another solution.

you can increase the 2gb limit to whatever you like with
av_max_alloc() / -max_alloc
That will likely result in bugs appearing which you will need to fix
also there may be other places hardcoding some limits that would need to be
reviewed and updated 

If people feel the 2gb limit is an issue then we could attempt to disable it in
the fuzzer and see what happens. (after some local testing first ...)


> 
> 
> >
> >For historical context, this limit has been inside ffv1enc as follows,
> >number 1 being the current version:
> >1. avctx->width*avctx->height*37LL*4 ("added support for
> >AV_PIX_FMT_GBRP16" - ce2217b25eccda9f5c14022bd69792e71b417b73)
> >2. avctx->width*avctx->height*35LL*4 ("avcodec/ffv1enc: fix size used
> >for ff_alloc_packet2()" - 904a2864bdafe19d18db95ca54dfb36d72957a16)
> >3. avctx->width*avctx->height*((8*2+1+1)*4)/8 ("ffv1enc: switch to
> >encode2()." - 278d88689ba89c78f6c2667cf98025835567d78d)
> >4. ??? Limit was probably somewhere elsewhere or didn't exist before this
> 
> I see it but still don't catch the reason (and I am very curious to find an
> input frame able to e.g. make an output  frame 2x bigger than the input
> frame).
> Eager to have some background about it (Michael?).

the limit is a result of the v3 version. Its a upper bound of the worst
case. 
With sufficient work you can probably find a much more complex expression
that would bound the size for large resolutions to a smaller value.
You will have to consider the range coder states and how they would
evolve during encoding in the worst case. Their evolution is bound to
tend towards less bad in a large frame so there the expression for the
max size will become more complex than a w*h*constant

and you better arent scared of "math proofs" because this pretty much
needs one. That is to decrease the max size you need to properly proof
that that a new bound is large enough.
The current bound should be reasonable easy to proof but the more tight
the bound is the more work it will be

also you can allocate a smaller buffer and reallocate before it becomes too
small. Multithreaded encoding will make this more complex though.

These problems are avoided in v4, this is what should be used really

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott



signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH V2 1/2] lavf/vc1test: fix vc1test can't probe some RCV file.

2018-10-12 Thread myp...@gmail.com

On Sat, Oct 13, 2018 at 12:55 AM myp...@gmail.com  wrote:
>
> On Fri, Oct 12, 2018 at 10:35 PM Carl Eugen Hoyos 
wrote:
> >
> > 2018-10-12 15:41 GMT+02:00, Jun Zhao :
> > > case 1:
> > > use the hexdump -C SMM0005.rcv get:
> > >  size  skip (size - 4)
> > >   ||
> > >   VV
> > >   18 00 00 c5 05 00 00 00  4d f1 0a 11 00 e0 01 00
> > > 0010  00 d0 02 00 00 0c 00 00  00 88 13 00 00 c0 65 52
> > >  ^
> > >|
> > >size + 16
> > > case 2:
> > > same the command for SMM0015.rcv get:
> > > size
> > >   |
> > >   V
> > >   19 00 00 c5 04 00 00 00  41 f3 80 01 40 02 00 00
> > > 0010  d0 02 00 00 0c 00 00 00  00 00 00 10 00 00 00 00
> > >   ^
> > > |
> > >  size + 16
> > >
> > > There are different the RCV file format for VC-1, vc1test
> > > just handle the case 2 now, this fix will support the case 1.
> >
> > Both with and without your patch, I get identical output from
> > FFmpeg's decoder for both SSM0015.rcv and SMM0005.rcv.
> > What exactly is your patch supposed to change?
> >
> > $ md5sum SMM0005.rcv
> > abd0fa5ec90d44f7b4865c6930d65ff2  SMM0005.rcv
> > $ md5sum SSM0015.rcv
> > 21a0281f83b7f2e99a048b180dd3347f  SSM0015.rcv
>
> In my test clips, I get md5 like this
> $ md5sum SMM0005.rcv
> 39eb225dbfafacea3e3737deba789530  SMM0005.rcv
> $ md5sum SMM0015.rcv
> 78e45e50079e143e69f69d677c37ac3b  SMM0015.rcv
RCV format have a different version, you can google the rcv1 rcv2 for VC-1.
(e,g:
http://www.ti.com/lit/ml/sprs363a/sprs363a.pdf), I think we use a different
RCV format for test clips SMM0005.rcv
> >
> >
> > The following does not change:
> >
> > $ ffmpeg -i SMM0005.rcv -f crc -
> > ffmpeg version N-92147-gf85fa10 Copyright (c) 2000-2018 the FFmpeg
developers
> >   built with gcc 6.4.0 (GCC)
> >   configuration: --enable-gpl --enable-gnutls --enable-libxml2
> >   libavutil  56. 19.101 / 56. 19.101
> >   libavcodec 58. 32.100 / 58. 32.100
> >   libavformat58. 18.104 / 58. 18.104
> >   libavdevice58.  4.105 / 58.  4.105
> >   libavfilter 7. 33.100 /  7. 33.100
> >   libswscale  5.  2.100 /  5.  2.100
> >   libswresample   3.  2.100 /  3.  2.100
> >   libpostproc55.  2.100 / 55.  2.100
> > Input #0, vc1test, from 'SMM0005.rcv':
> >   Duration: 00:00:01.00, bitrate: 7472 kb/s
> > Stream #0:0: Video: wmv3 (Main), yuv420p, 720x480, 24 fps, 24 tbr,
> > 24 tbn, 24 tbc
> > Stream mapping:
> >   Stream #0:0 -> #0:0 (wmv3 (native) -> rawvideo (native))
> > Press [q] to stop, [?] for help
> > Output #0, crc, to 'pipe:':
> >   Metadata:
> > encoder : Lavf58.18.104
> > Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p,
> > 720x480, q=2-31, 99532 kb/s, 24 fps, 24 tbn, 24 tbc
> > Metadata:
> >   encoder : Lavc58.32.100 rawvideo
> > SMM0005.rcv: Input/output error
> > Last message repeated 1 times
> > CRC=0xe3b2671c
> > frame=   24 fps=0.0 q=-0.0 Lsize=   0kB time=00:00:01.00 bitrate=
> >  0.1kbits/s speed=14.8x
> > video:12150kB audio:0kB subtitle:0kB other streams:0kB global
> > headers:0kB muxing overhead: unknown
> >
> > What exactly is your patch supposed to improve?
> >
> > Thank you, Carl Eugen
> >
> > (05 looks different here.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] avcodec: Implement Archimedes VIDC encoder/decoder

2018-10-12 Thread Cameron Cawley

Signed-off-by: Cameron Cawley 
---
 doc/general.texi  |  2 ++
 libavcodec/Makefile   |  2 ++
 libavcodec/allcodecs.c|  2 ++
 libavcodec/avcodec.h  |  1 +
 libavcodec/codec_desc.c   |  7 +++
 libavcodec/pcm.c  | 15 +++
 libavcodec/pcm_tablegen.c |  2 ++
 libavcodec/pcm_tablegen.h | 27 +++
 libavcodec/utils.c|  1 +
 libavformat/Makefile  |  2 ++
 libavformat/allformats.c  |  2 ++
 libavformat/pcmdec.c  |  3 +++
 libavformat/pcmenc.c  |  3 +++
 13 files changed, 69 insertions(+)

diff --git a/doc/general.texi b/doc/general.texi
index 05f7bcd9fc..e3874430a4 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -545,6 +545,7 @@ library:
 @item raw VC-1  @tab X @tab X
 @item raw PCM A-law @tab X @tab X
 @item raw PCM mu-law@tab X @tab X
+@item raw PCM Archimedes VIDC   @tab X @tab X
 @item raw PCM signed 8 bit  @tab X @tab X
 @item raw PCM signed 16 bit big-endian  @tab X @tab X
 @item raw PCM signed 16 bit little-endian  @tab X @tab X
@@ -1146,6 +1147,7 @@ following image formats are supported:
 @tab encoding supported through external library libopus
 @item PCM A-law  @tab  X  @tab  X
 @item PCM mu-law @tab  X  @tab  X
+@item PCM Archimedes VIDC@tab  X  @tab  X
 @item PCM signed 8-bit planar  @tab  X  @tab  X
 @item PCM signed 16-bit big-endian planar  @tab  X  @tab  X
 @item PCM signed 16-bit little-endian planar  @tab  X  @tab  X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index ce766aa466..b12d9ffccd 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -794,6 +794,8 @@ OBJS-$(CONFIG_PCM_U32BE_DECODER)  += pcm.o
 OBJS-$(CONFIG_PCM_U32BE_ENCODER)  += pcm.o
 OBJS-$(CONFIG_PCM_U32LE_DECODER)  += pcm.o
 OBJS-$(CONFIG_PCM_U32LE_ENCODER)  += pcm.o
+OBJS-$(CONFIG_PCM_VIDC_DECODER)   += pcm.o
+OBJS-$(CONFIG_PCM_VIDC_ENCODER)   += pcm.o
 OBJS-$(CONFIG_PCM_ZORK_DECODER)   += pcm.o
 
 OBJS-$(CONFIG_ADPCM_4XM_DECODER)  += adpcm.o adpcm_data.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index c0b4d56d0d..1b8144a2b7 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -552,6 +552,8 @@ extern AVCodec ff_pcm_u32be_encoder;
 extern AVCodec ff_pcm_u32be_decoder;
 extern AVCodec ff_pcm_u32le_encoder;
 extern AVCodec ff_pcm_u32le_decoder;
+extern AVCodec ff_pcm_vidc_encoder;
+extern AVCodec ff_pcm_vidc_decoder;
 extern AVCodec ff_pcm_zork_decoder;
 
 /* DPCM codecs */
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 705a3ce4f3..7ffef768dc 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -491,6 +491,7 @@ enum AVCodecID {
 AV_CODEC_ID_PCM_S64BE,
 AV_CODEC_ID_PCM_F16LE,
 AV_CODEC_ID_PCM_F24LE,
+AV_CODEC_ID_PCM_VIDC,
 
 /* various ADPCM codecs */
 AV_CODEC_ID_ADPCM_IMA_QT = 0x11000,
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 67a30542d1..1a159f7e13 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1936,6 +1936,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("PCM 24.0 floating point 
little-endian"),
 .props = AV_CODEC_PROP_LOSSLESS,
 },
+{
+.id= AV_CODEC_ID_PCM_VIDC,
+.type  = AVMEDIA_TYPE_AUDIO,
+.name  = "pcm_vidc",
+.long_name = NULL_IF_CONFIG_SMALL("PCM Archimedes VIDC"),
+.props = AV_CODEC_PROP_LOSSY,
+},
 
 /* various ADPCM codecs */
 {
diff --git a/libavcodec/pcm.c b/libavcodec/pcm.c
index 8c326c6829..ffcbccc77d 100644
--- a/libavcodec/pcm.c
+++ b/libavcodec/pcm.c
@@ -42,6 +42,9 @@ static av_cold int pcm_encode_init(AVCodecContext *avctx)
 case AV_CODEC_ID_PCM_MULAW:
 pcm_ulaw_tableinit();
 break;
+case AV_CODEC_ID_PCM_VIDC:
+pcm_vidc_tableinit();
+break;
 default:
 break;
 }
@@ -216,6 +219,12 @@ static int pcm_encode_frame(AVCodecContext *avctx, 
AVPacket *avpkt,
 *dst++ = linear_to_ulaw[(v + 32768) >> 2];
 }
 break;
+case AV_CODEC_ID_PCM_VIDC:
+for (; n > 0; n--) {
+v  = *samples++;
+*dst++ = linear_to_vidc[(v + 32768) >> 2];
+}
+break;
 default:
 return -1;
 }
@@ -249,6 +258,10 @@ static av_cold int pcm_decode_init(AVCodecContext *avctx)
 for (i = 0; i < 256; i++)
 s->table[i] = ulaw2linear(i);
 break;
+case AV_CODEC_ID_PCM_VIDC:
+for (i = 0; i < 256; i++)
+s->table[i] = vidc2linear(i);
+break;
 case AV_CODEC_ID_PCM_F16LE:
 case AV_CODEC_ID_PCM_F24LE:
 s->scale = 1. / (1 << (avctx->bits_per_coded_sample - 1));
@@ -485,6 +498,7 @@ static int pcm_decode_frame(AVCodecContext *avctx, void 
*data,
 break;
 case AV_CODEC_ID_PCM_ALAW:
 case AV_CODEC_ID_PCM_MULAW:
+

[FFmpeg-devel] [PATCH 2/2] avformat/rpl: Support files containing 8 bit PCM or VIDC audio

2018-10-12 Thread Cameron Cawley

Signed-off-by: Cameron Cawley 
---
 libavformat/rpl.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/libavformat/rpl.c b/libavformat/rpl.c
index d373600478..6b45b35c30 100644
--- a/libavformat/rpl.c
+++ b/libavformat/rpl.c
@@ -119,6 +119,8 @@ static int rpl_read_header(AVFormatContext *s)
 AVStream *vst = NULL, *ast = NULL;
 int total_audio_size;
 int error = 0;
+const char *endptr;
+char audio_type[RPL_LINE_LENGTH];
 
 uint32_t i;
 
@@ -188,7 +190,9 @@ static int rpl_read_header(AVFormatContext *s)
 ast->codecpar->codec_tag   = audio_format;
 ast->codecpar->sample_rate = read_line_and_int(pb, );  // 
audio bitrate
 ast->codecpar->channels= read_line_and_int(pb, );  // 
number of audio channels
-ast->codecpar->bits_per_coded_sample = read_line_and_int(pb, );  
// audio bits per sample
+error |= read_line(pb, line, sizeof(line));
+ast->codecpar->bits_per_coded_sample = read_int(line, , 
);  // audio bits per sample
+strcpy(audio_type, endptr);
 // At least one sample uses 0 for ADPCM, which is really 4 bits
 // per sample.
 if (ast->codecpar->bits_per_coded_sample == 0)
@@ -205,6 +209,17 @@ static int rpl_read_header(AVFormatContext *s)
 // 16-bit audio is always signed
 ast->codecpar->codec_id = AV_CODEC_ID_PCM_S16LE;
 break;
+} else if (ast->codecpar->bits_per_coded_sample == 8) {
+if(strstr(audio_type, "unsigned") != NULL) {
+ast->codecpar->codec_id = AV_CODEC_ID_PCM_U8;
+break;
+} else if(strstr(audio_type, "linear") != NULL) {
+ast->codecpar->codec_id = AV_CODEC_ID_PCM_S8;
+break;
+} else {
+ast->codecpar->codec_id = AV_CODEC_ID_PCM_VIDC;
+break;
+}
 }
 // There are some other formats listed as legal per the spec;
 // samples needed.
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH 10/12] lavf/mxfdec: demux s436m as eia608 subtitle track

2018-10-12 Thread Baptiste Coudurier

On Wed, Jul 4, 2018 at 1:50 PM Marton Balint  wrote:

>
>
> On Wed, 4 Jul 2018, Baptiste Coudurier wrote:
>
> > ---
> > libavformat/mxfdec.c | 102 +++
> > 1 file changed, 102 insertions(+)
> >
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index 3f443bbbc9..54e4be7934 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -52,6 +52,7 @@
> > #include "libavutil/intreadwrite.h"
> > #include "libavutil/parseutils.h"
> > #include "libavutil/timecode.h"
> > +#include "libavutil/opt.h"
> > #include "avformat.h"
> > #include "internal.h"
> > #include "mxf.h"
> > @@ -263,6 +264,7 @@ typedef struct MXFIndexTable {
> > } MXFIndexTable;
> >
> > typedef struct MXFContext {
> > +const AVClass *class; /**< Class for private options. */
> > MXFPartition *partitions;
> > unsigned partitions_count;
> > MXFOP op;
> > @@ -287,6 +289,8 @@ typedef struct MXFContext {
> > int64_t current_edit_unit;
> > int nb_index_tables;
> > MXFIndexTable *index_tables;
> > +int edit_units_per_packet;  ///< how many edit units to read at
> a time (PCM, OPAtom)
>
> This seems unused, probably remained after a merge. (edit_units_per_packet
> is now an MXFTrack property).
>
> > +int eia608_extract;
> > } MXFContext;
> >
> > /* NOTE: klv_offset is not set (-1) for local keys */
> > @@ -449,6 +453,78 @@ static int find_body_sid_by_offset(MXFContext *mxf,
> int64_t offset)
> > return mxf->partitions[a].body_sid;
> > }
> >
> > +static int mxf_get_eia608_packet(AVFormatContext *s, AVStream *st,
> AVPacket *pkt, int64_t length)
> > +{
> > +int count = avio_rb16(s->pb);
> > +int i, ret;
> > +
> > +for (i = 0; i < count; i++) {
> > +if (length < 6) {
> > +av_log(s, AV_LOG_ERROR, "error reading s436m packet
> %"PRId64"\n", length);
> > +return AVERROR_INVALIDDATA;
> > +}
> > +int line_num = avio_rb16(s->pb);
> > +int wrapping_type = avio_r8(s->pb);
> > +int sample_coding = avio_r8(s->pb);
> > +int sample_count = avio_rb16(s->pb);
> > +av_log(s, AV_LOG_DEBUG, "len %"PRId64" line %d wrap type %d
> coding %d count %d\n",
> > +   length, line_num, wrapping_type, sample_coding,
> sample_count);
> > +length -= 6 + 8 + sample_count;
> > +if (line_num != 9 && line_num != 11)
> > +break;
> > +if (sample_coding == 7 || sample_coding == 8 || sample_coding
> == 9) {
> > +av_log(s, AV_LOG_ERROR, "unsupported s436m 10 bit sample
> coding\n");
> > +return 0;
> > +}
> > +if (length < 0)
> > +return AVERROR_INVALIDDATA;
> > +
> > +int array_count = avio_rb32(s->pb);
> > +int array_elem_size = avio_rb32(s->pb);
> > +av_log(s, AV_LOG_DEBUG, "array count %d elem size %d\n",
> array_count, array_elem_size);
> > +int did = avio_r8(s->pb);
> > +int sdid = avio_r8(s->pb);
> > +int data_count = avio_r8(s->pb);
> > +av_log(s, AV_LOG_DEBUG, "did %x sdid %x count %d\n", did, sdid,
> data_count);
> > +if (did != 0x61)
> > +break;
> > +int cdp_id = avio_rb16(s->pb);
> > +int cdp_data_count = avio_r8(s->pb);
> > +int cdp_framing_rate = avio_r8(s->pb) >> 4;
> > +int cdp_flags = avio_r8(s->pb);
> > +int cdp_counter = avio_rb16(s->pb);
> > +int cdp_data_section = avio_r8(s->pb);
> > +if (cdp_data_section != 0x72) {
> > +av_log(s, AV_LOG_ERROR, "wrong cdp data section %x\n",
> cdp_data_section);
> > +return AVERROR_INVALIDDATA;
> > +}
> > +int flags = avio_r8(s->pb);
> > +int cc_count = flags & 0x1f;
> > +av_log(s, AV_LOG_DEBUG, "cdp id %x dcount %d frame rate %d cdp
> flags %x flags %x "
> > +   "cc count %d counter %d section %x\n", cdp_id,
> cdp_data_count, cdp_framing_rate,
> > +   cdp_flags, flags, cc_count, cdp_counter,
> cdp_data_section);
> > +ret = av_get_packet(s->pb, pkt, cc_count * 3);
> > +if (ret < 0)
> > +return ret;
> > +if (cdp_data_count - 9 - 4 <  cc_count * 3) {
> > +av_log(s, AV_LOG_ERROR, "wrong cdp size %d cc count %d\n",
> data_count, cc_count);
> > +return AVERROR_INVALIDDATA;
> > +}
> > +avio_skip(s->pb, data_count - 9 - 4 - cc_count * 3);
> > +int cdp_footer_section = avio_r8(s->pb);
> > +if (cdp_footer_section != 0x74) {
> > +av_log(s, AV_LOG_ERROR, "wrong cdp footer section %x\n",
> cdp_footer_section);
> > +return AVERROR_INVALIDDATA;
> > +}
> > +int cdp_counter2 = avio_rb16(s->pb);
> > +int cdp_checksum = avio_r8(s->pb);
> > +av_log(s, AV_LOG_DEBUG, "cdp counter %d checksum %x\n",
> cdp_counter2, cdp_checksum);
> > +break;
> > +}
> > +
> > +return 0;
> > +}
> > +
> > /* XXX:

Re: [FFmpeg-devel] [PATCH v2] lavf/mxfenc: support creating s436m data tracks

2018-10-12 Thread Baptiste Coudurier

On Mon, Sep 24, 2018 at 1:55 PM Baptiste Coudurier <
baptiste.coudur...@gmail.com> wrote:

> On Thu, Jul 19, 2018 at 2:32 PM Michael Niedermayer 
> wrote:
>
>> On Wed, Jul 04, 2018 at 03:06:54PM -0700, Baptiste Coudurier wrote:
>> > ---
>> >  libavformat/mxf.c|  1 +
>> >  libavformat/mxfdec.c |  2 ++
>> >  libavformat/mxfenc.c | 41 +
>> >  libavformat/utils.c  |  6 +-
>> >  4 files changed, 45 insertions(+), 5 deletions(-)
>> [...]
>> > diff --git a/libavformat/utils.c b/libavformat/utils.c
>> > index c9cdd2b470..36a32ad9c2 100644
>> > --- a/libavformat/utils.c
>> > +++ b/libavformat/utils.c
>> > @@ -1003,6 +1003,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
>> >  *pnum = frame_size;
>> >  *pden = sample_rate;
>> >  break;
>> > +case AVMEDIA_TYPE_DATA:
>> > +*pnum = st->time_base.num;
>> > +*pden = st->time_base.den;
>> > +break;
>> >  default:
>> >  break;
>> >  }
>> > @@ -1405,7 +1409,7 @@ static void compute_pkt_fields(AVFormatContext
>> *s, AVStream *st,
>> >  presentation_delayed, delay, av_ts2str(pkt->pts),
>> av_ts2str(pkt->dts), av_ts2str(st->cur_dts));
>> >
>> >  /* update flags */
>> > -if (is_intra_only(st->codecpar->codec_id))
>> > +if (st->codecpar->codec_type == AVMEDIA_TYPE_DATA ||
>> is_intra_only(st->codecpar->codec_id))
>> >  pkt->flags |= AV_PKT_FLAG_KEY;
>> >  #if FF_API_CONVERGENCE_DURATION
>> >  FF_DISABLE_DEPRECATION_WARNINGS
>>
>> This should be a seperate patch.
>> Also i think forcing duration=1 is not correct for all AVMEDIA_TYPE_DATA
>> for example there are ID3 and fonts. These would i guess if they have a
>> timebase set apply to more than 1 "unit"
>>
>
> I applied the separate patch.
> Will apply this patch shortly, addressing Marton comment.
>
> Thanks!
>

Applied.

-- 
Baptiste Coudurier
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 04/12] avformat/mxfenc: update body partition with footer offset

2018-10-12 Thread Baptiste Coudurier

On Thu, Jul 19, 2018 at 8:40 AM Baptiste Coudurier <
baptiste.coudur...@gmail.com> wrote:

> On Wed, Jul 4, 2018 at 11:35 AM, Baptiste Coudurier <
> baptiste.coudur...@gmail.com> wrote:
>
>> ---
>>  libavformat/mxfenc.c| 9 +++--
>>  tests/ref/lavf/mxf  | 6 +++---
>>  tests/ref/lavf/mxf_d10  | 2 +-
>>  tests/ref/lavf/mxf_dv25 | 2 +-
>>  tests/ref/lavf/mxf_dvcpro50 | 2 +-
>>  tests/ref/lavf/mxf_opatom   | 2 +-
>>  tests/ref/lavf/mxf_opatom_audio | 2 +-
>>  7 files changed, 15 insertions(+), 10 deletions(-)
>
>
> Will apply.
>

Applied.

-- 
Baptiste Coudurier
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 03/12] avformat/mxfenc: add mpeg-2 specific metadata, fix compatibility with sony content browser

2018-10-12 Thread Baptiste Coudurier

On Thu, Jul 19, 2018 at 8:42 AM Baptiste Coudurier <
baptiste.coudur...@gmail.com> wrote:

> On Wed, Jul 4, 2018 at 11:35 AM, Baptiste Coudurier <
> baptiste.coudur...@gmail.com> wrote:
>
>> ---
>>  libavformat/mxfenc.c| 46 ++---
>>  tests/ref/lavf/mxf  |  6 ++---
>>  tests/ref/lavf/mxf_d10  |  2 +-
>>  tests/ref/lavf/mxf_dv25 |  2 +-
>>  tests/ref/lavf/mxf_dvcpro50 |  2 +-
>>  tests/ref/lavf/mxf_opatom   |  2 +-
>>  tests/ref/lavf/mxf_opatom_audio |  2 +-
>>  7 files changed, 50 insertions(+), 12 deletions(-)
>>
>
> Will apply.
>

Applied.

-- 
Baptiste Coudurier
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 05/12] avformat/mxfenc: correctly set content package rate in system element

2018-10-12 Thread Baptiste Coudurier

On Thu, Jul 19, 2018 at 8:37 AM Baptiste Coudurier <
baptiste.coudur...@gmail.com> wrote:

> On Wed, Jul 4, 2018 at 11:35 AM, Baptiste Coudurier <
> baptiste.coudur...@gmail.com> wrote:
>
>> ---
>>  libavformat/mxf.c| 17 +
>>  libavformat/mxf.h|  2 ++
>>  libavformat/mxfenc.c |  4 +++-
>>  tests/ref/lavf/mxf   |  2 +-
>>  4 files changed, 23 insertions(+), 2 deletions(-)
>>
>
> Will apply.
>

Applied

-- 
Baptiste Coudurier
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 02/12] avformat/mxfenc: write index delta entry array needed by sony vegas pro 11

2018-10-12 Thread Baptiste Coudurier

On Thu, Jul 12, 2018 at 12:44 PM Baptiste Coudurier <
baptiste.coudur...@gmail.com> wrote:

> Hey Thomas,
>
> On Thu, Jul 12, 2018 at 12:29 PM, Tomas Härdin  wrote:
>
>> Is this the latest/correct patch series for these things? I saw some
>> other patches conflicted with Marton's work
>>
>
> Yes, the conflicts were on the demuxer side
>

Will apply.

-- 
Baptiste Coudurier
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavc/qsvenc_jpeg: add async_depth support

2018-10-12 Thread Eoff, Ullysses A

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> Zhong Li
> Sent: Thursday, October 11, 2018 2:30 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Li, Zhong 
> Subject: [FFmpeg-devel] [PATCH 1/2] lavc/qsvenc_jpeg: add async_depth support
> 
> Currently qsv (m)jpeg encoding is broken.
> Regression introducing by the commit(id: c1bcd3): fix async support,
> which requires the minimum async_depth to be 1, instead previous zero.
> But the default async_depth of qsv (m)jpeg encoding is still initialized
> (mostly) as zero.
> 
> This patch also abviously improves qsv (m)jpeg encoding performance
> due to the default async_depth is changed to 4.
> 
> Signed-off-by: Zhong Li 
> ---
>  libavcodec/qsvenc_jpeg.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavcodec/qsvenc_jpeg.c b/libavcodec/qsvenc_jpeg.c
> index c18fe91..01c10125 100644
> --- a/libavcodec/qsvenc_jpeg.c
> +++ b/libavcodec/qsvenc_jpeg.c
> @@ -64,6 +64,7 @@ static av_cold int qsv_enc_close(AVCodecContext *avctx)
>  #define OFFSET(x) offsetof(QSVMJPEGEncContext, x)
>  #define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
>  static const AVOption options[] = {
> +{ "async_depth", "Maximum processing parallelism", 
> OFFSET(qsv.async_depth), AV_OPT_TYPE_INT, { .i64 =
> ASYNC_DEPTH_DEFAULT }, 1, INT_MAX, VE },
>  { NULL },
>  };
> 
> --
> 2.7.4
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This fixes it for me.  Please merge.


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

Re: [FFmpeg-devel] [PATCH V2 1/2] lavf/vc1test: fix vc1test can't probe some RCV file.

2018-10-12 Thread myp...@gmail.com

On Fri, Oct 12, 2018 at 10:35 PM Carl Eugen Hoyos  wrote:
>
> 2018-10-12 15:41 GMT+02:00, Jun Zhao :
> > case 1:
> > use the hexdump -C SMM0005.rcv get:
> >  size  skip (size - 4)
> >   ||
> >   VV
> >   18 00 00 c5 05 00 00 00  4d f1 0a 11 00 e0 01 00
> > 0010  00 d0 02 00 00 0c 00 00  00 88 13 00 00 c0 65 52
> >  ^
> >|
> >size + 16
> > case 2:
> > same the command for SMM0015.rcv get:
> > size
> >   |
> >   V
> >   19 00 00 c5 04 00 00 00  41 f3 80 01 40 02 00 00
> > 0010  d0 02 00 00 0c 00 00 00  00 00 00 10 00 00 00 00
> >   ^
> > |
> >  size + 16
> >
> > There are different the RCV file format for VC-1, vc1test
> > just handle the case 2 now, this fix will support the case 1.
>
> Both with and without your patch, I get identical output from
> FFmpeg's decoder for both SSM0015.rcv and SMM0005.rcv.
> What exactly is your patch supposed to change?
>
> $ md5sum SMM0005.rcv
> abd0fa5ec90d44f7b4865c6930d65ff2  SMM0005.rcv
> $ md5sum SSM0015.rcv
> 21a0281f83b7f2e99a048b180dd3347f  SSM0015.rcv

In my test clips, I get md5 like this
$ md5sum SMM0005.rcv
39eb225dbfafacea3e3737deba789530  SMM0005.rcv
$ md5sum SMM0015.rcv
78e45e50079e143e69f69d677c37ac3b  SMM0015.rcv
>
>
> The following does not change:
>
> $ ffmpeg -i SMM0005.rcv -f crc -
> ffmpeg version N-92147-gf85fa10 Copyright (c) 2000-2018 the FFmpeg developers
>   built with gcc 6.4.0 (GCC)
>   configuration: --enable-gpl --enable-gnutls --enable-libxml2
>   libavutil  56. 19.101 / 56. 19.101
>   libavcodec 58. 32.100 / 58. 32.100
>   libavformat58. 18.104 / 58. 18.104
>   libavdevice58.  4.105 / 58.  4.105
>   libavfilter 7. 33.100 /  7. 33.100
>   libswscale  5.  2.100 /  5.  2.100
>   libswresample   3.  2.100 /  3.  2.100
>   libpostproc55.  2.100 / 55.  2.100
> Input #0, vc1test, from 'SMM0005.rcv':
>   Duration: 00:00:01.00, bitrate: 7472 kb/s
> Stream #0:0: Video: wmv3 (Main), yuv420p, 720x480, 24 fps, 24 tbr,
> 24 tbn, 24 tbc
> Stream mapping:
>   Stream #0:0 -> #0:0 (wmv3 (native) -> rawvideo (native))
> Press [q] to stop, [?] for help
> Output #0, crc, to 'pipe:':
>   Metadata:
> encoder : Lavf58.18.104
> Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p,
> 720x480, q=2-31, 99532 kb/s, 24 fps, 24 tbn, 24 tbc
> Metadata:
>   encoder : Lavc58.32.100 rawvideo
> SMM0005.rcv: Input/output error
> Last message repeated 1 times
> CRC=0xe3b2671c
> frame=   24 fps=0.0 q=-0.0 Lsize=   0kB time=00:00:01.00 bitrate=
>  0.1kbits/s speed=14.8x
> video:12150kB audio:0kB subtitle:0kB other streams:0kB global
> headers:0kB muxing overhead: unknown
>
> What exactly is your patch supposed to improve?
>
> Thank you, Carl Eugen
>
> (05 looks different here.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] ffv1enc: question about "Cannot allocate worst case packet size, the encoding could fail"

2018-10-12 Thread Carl Eugen Hoyos

2018-10-12 11:59 GMT+02:00, Jerome Martinez :
> On 12/10/2018 11:15, Carl Eugen Hoyos wrote:
>> 2018-10-11 14:01 GMT+02:00, Jerome Martinez :
>>
>>> - why is having a number > INT_MAX an issue? modern machines
>>> are 64-bit and have 8+ GB of RAM
>> So where is the issue?
>
> The issue is that vanilla FFmpeg shows a warning in the scenario I
> indicate (a 128 MB frame, far less than 2 GB), without obvious reason of
> this warning (the multiplier used and the underlying limitation to 2 GB,
> lower than the available RAM, are hard coded without comments about the
> reason).

At a very general level, I believe a warning that very large resolutions
can have a negative effect seems not absurd.
I believe it was already argued that pathological input frames can lead
to multiplied output size.

>> If above is true for you, can can simply remove the check locally, no?
>
> My goal is that **others** don't have this warning when they use a
> vanilla version of FFmpeg.

You seem to be 100% sure that the warning is bad, I am not convinced.

> Before sending a patch for removing the limitation I don't understand
> (or lowering a number I don't understand), I ask if there is a reason
> for it (I guess that if this code is here, there is a reason and I
> imagined that FFmpeg developers could kindly explain the reason), isn't
> it the right thing to do? Do you prefer that I send directly a patch?
>
>> (I hope you agree that what you write is not generally true.)
>
> I don't catch what you want to indicate: do you mean that the only way
> in FFmpeg to be compatible with all machines is to set an hard coded
> limit to 2 GB?
> I don't catch the goal, as you can have machines with 1 GB so this test
> would be useless on them (it will not prevent other parts of the code to
> have to do checks about RAM allocations) as well for machines having lot
> of RAM (they can handle big frames).

I wanted to explain that not every system FFmpeg runs on is a 64 bit
system, I know very well that FFmpeg will have issues on memory-
limited systems, iirc, it hits dnxhd on real-world systems.
(The default user memory limits hit you on AIX afaiu although
system memory is >100G.)

> As I understand, the following test:
>  if ((ret = ff_alloc_packet2(avctx, pkt, maxsize, 0)) < 0)
>  return ret;
>
> permits to check that FFmpeg has enough RAM for storing the max encoded
> frame size, whatever is the size of the RAM (1 GB or 8 GB), so I don't
> understand the reason maxsize is limited to 2 GB before the call to
> ff_alloc_packet2.

> I kindly request more details about how hard coding 2 GB in the code
> helps, for both machines having 1 GB & machines having 8 GB. Looks like
> I am personally not smart enough for understanding that alone.

I believe there are at least two reasons:
One is that on 32bit systems, you cannot allocate larger blocks, the
second reason is that dos is considered a security issue and allocating
more that 2G for one frame seems like a dos approach.

One solution may be to have a configure option that raises the
allocation limit on 64 bit systems or to raise it for every 64bit
system.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] ffv1enc: question about "Cannot allocate worst case packet size, the encoding could fail"

2018-10-12 Thread Paul B Mahol

On 10/12/18, Jerome Martinez  wrote:
> On 12/10/2018 15:30, Jan Ekstroem wrote:
>> And while it seems like we're focusing on the arbitrary limit in
>> av_malloc (which is an issue of its own), I do note that for this
>> specific case this "worst case packed frame size" allocation heuristic
>> might have to be modified? Or at least explained if possible, so that
>> things can be improved in a proper way.
>
>
> Thank you for the feedback.
> I was focused on ff_alloc_packet2() which accepts 64-bit integers, and I
> did not check what is behind (limited to INT_MAX too).
> I understand now that this is a global limit, not tied to FFV1 encoder
> (but when this limit is removed from mem.h, there will be a review of
> ode which test this limit before calling ff_alloc_packet2()...).
>
> As you said in the other answer, it was unrealistic to hit such limit in
> 2005, but now... 2 GB by packet is still huge (the input frame is "only"
> 128 MB), but the multiplier used in FFV1 encoder makes the limit hit for
> "basic" 4K frames. 8K frames are approaching...
> A bit complex for me to remove this 2 GB  limit for sure everywhere :(,
> so I try to find another solution.
>
>
>>
>> For historical context, this limit has been inside ffv1enc as follows,
>> number 1 being the current version:
>> 1. avctx->width*avctx->height*37LL*4 ("added support for
>> AV_PIX_FMT_GBRP16" - ce2217b25eccda9f5c14022bd69792e71b417b73)
>> 2. avctx->width*avctx->height*35LL*4 ("avcodec/ffv1enc: fix size used
>> for ff_alloc_packet2()" - 904a2864bdafe19d18db95ca54dfb36d72957a16)
>> 3. avctx->width*avctx->height*((8*2+1+1)*4)/8 ("ffv1enc: switch to
>> encode2()." - 278d88689ba89c78f6c2667cf98025835567d78d)
>> 4. ??? Limit was probably somewhere elsewhere or didn't exist before this
>
> I see it but still don't catch the reason (and I am very curious to find
> an input frame able to e.g. make an output  frame 2x bigger than the
> input frame).
> Eager to have some background about it (Michael?).
>
> I guess there is a good reason for the "37LL*4" which is huge (note: I
> am afraid I did not update this limit when I implemented
> AV_PIX_FMT_GBRAP16, which is 4/3x bigger), so now trying to find a way
> to warn the user but not with 1 message per frame.
>
> If I can not (easily) remove this limitation, would limiting the message
> to 1 iteration for a whole stream be an acceptable patch?
> If so I'll send such patch.

I'm looking in adoption of v4 (and improve it) version sooner than never.

Ignoring issue all together may cause crash for specially crafted
input files, even
when such scenario is highly unlikely.

The limit of 2GB or whatever small value should ultimately be removed
at some point.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH V2 1/2] lavf/vc1test: fix vc1test can't probe some RCV file.

2018-10-12 Thread Carl Eugen Hoyos

2018-10-12 15:41 GMT+02:00, Jun Zhao :
> case 1:
> use the hexdump -C SMM0005.rcv get:
>  size  skip (size - 4)
>   ||
>   VV
>   18 00 00 c5 05 00 00 00  4d f1 0a 11 00 e0 01 00
> 0010  00 d0 02 00 00 0c 00 00  00 88 13 00 00 c0 65 52
>  ^
>|
>size + 16
> case 2:
> same the command for SMM0015.rcv get:
> size
>   |
>   V
>   19 00 00 c5 04 00 00 00  41 f3 80 01 40 02 00 00
> 0010  d0 02 00 00 0c 00 00 00  00 00 00 10 00 00 00 00
>   ^
> |
>  size + 16
>
> There are different the RCV file format for VC-1, vc1test
> just handle the case 2 now, this fix will support the case 1.

Both with and without your patch, I get identical output from
FFmpeg's decoder for both SSM0015.rcv and SMM0005.rcv.
What exactly is your patch supposed to change?

$ md5sum SMM0005.rcv
abd0fa5ec90d44f7b4865c6930d65ff2  SMM0005.rcv
$ md5sum SSM0015.rcv
21a0281f83b7f2e99a048b180dd3347f  SSM0015.rcv

The following does not change:

$ ffmpeg -i SMM0005.rcv -f crc -
ffmpeg version N-92147-gf85fa10 Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 6.4.0 (GCC)
  configuration: --enable-gpl --enable-gnutls --enable-libxml2
  libavutil  56. 19.101 / 56. 19.101
  libavcodec 58. 32.100 / 58. 32.100
  libavformat58. 18.104 / 58. 18.104
  libavdevice58.  4.105 / 58.  4.105
  libavfilter 7. 33.100 /  7. 33.100
  libswscale  5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
  libpostproc55.  2.100 / 55.  2.100
Input #0, vc1test, from 'SMM0005.rcv':
  Duration: 00:00:01.00, bitrate: 7472 kb/s
Stream #0:0: Video: wmv3 (Main), yuv420p, 720x480, 24 fps, 24 tbr,
24 tbn, 24 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (wmv3 (native) -> rawvideo (native))
Press [q] to stop, [?] for help
Output #0, crc, to 'pipe:':
  Metadata:
encoder : Lavf58.18.104
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p,
720x480, q=2-31, 99532 kb/s, 24 fps, 24 tbn, 24 tbc
Metadata:
  encoder : Lavc58.32.100 rawvideo
SMM0005.rcv: Input/output error
Last message repeated 1 times
CRC=0xe3b2671c
frame=   24 fps=0.0 q=-0.0 Lsize=   0kB time=00:00:01.00 bitrate=
 0.1kbits/s speed=14.8x
video:12150kB audio:0kB subtitle:0kB other streams:0kB global
headers:0kB muxing overhead: unknown

What exactly is your patch supposed to improve?

Thank you, Carl Eugen

(05 looks different here.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] ffv1enc: question about "Cannot allocate worst case packet size, the encoding could fail"

2018-10-12 Thread Jerome Martinez


On 12/10/2018 15:30, Jan Ekström wrote:

And while it seems like we're focusing on the arbitrary limit in
av_malloc (which is an issue of its own), I do note that for this
specific case this "worst case packed frame size" allocation heuristic
might have to be modified? Or at least explained if possible, so that
things can be improved in a proper way.



Thank you for the feedback.
I was focused on ff_alloc_packet2() which accepts 64-bit integers, and I 
did not check what is behind (limited to INT_MAX too).
I understand now that this is a global limit, not tied to FFV1 encoder 
(but when this limit is removed from mem.h, there will be a review of 
ode which test this limit before calling ff_alloc_packet2()...).


As you said in the other answer, it was unrealistic to hit such limit in 
2005, but now... 2 GB by packet is still huge (the input frame is "only" 
128 MB), but the multiplier used in FFV1 encoder makes the limit hit for 
"basic" 4K frames. 8K frames are approaching...
A bit complex for me to remove this 2 GB  limit for sure everywhere :(, 
so I try to find another solution.





For historical context, this limit has been inside ffv1enc as follows,
number 1 being the current version:
1. avctx->width*avctx->height*37LL*4 ("added support for
AV_PIX_FMT_GBRP16" - ce2217b25eccda9f5c14022bd69792e71b417b73)
2. avctx->width*avctx->height*35LL*4 ("avcodec/ffv1enc: fix size used
for ff_alloc_packet2()" - 904a2864bdafe19d18db95ca54dfb36d72957a16)
3. avctx->width*avctx->height*((8*2+1+1)*4)/8 ("ffv1enc: switch to
encode2()." - 278d88689ba89c78f6c2667cf98025835567d78d)
4. ??? Limit was probably somewhere elsewhere or didn't exist before this


I see it but still don't catch the reason (and I am very curious to find 
an input frame able to e.g. make an output  frame 2x bigger than the 
input frame).

Eager to have some background about it (Michael?).

I guess there is a good reason for the "37LL*4" which is huge (note: I 
am afraid I did not update this limit when I implemented 
AV_PIX_FMT_GBRAP16, which is 4/3x bigger), so now trying to find a way 
to warn the user but not with 1 message per frame.


If I can not (easily) remove this limitation, would limiting the message 
to 1 iteration for a whole stream be an acceptable patch?

If so I'll send such patch.

Jérôme


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

[FFmpeg-devel] [PATCH V2 2/2] lavf/vc1test: add rcv to vc1test demuxer extensions

2018-10-12 Thread Jun Zhao

rcv is commonly used as extension for vc1 test stream files.

Signed-off-by: Jun Zhao 
---
 libavformat/vc1test.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/libavformat/vc1test.c b/libavformat/vc1test.c
index 82e155a..a252bf0 100644
--- a/libavformat/vc1test.c
+++ b/libavformat/vc1test.c
@@ -121,5 +121,6 @@ AVInputFormat ff_vc1t_demuxer = {
 .read_probe = vc1t_probe,
 .read_header= vc1t_read_header,
 .read_packet= vc1t_read_packet,
+.extensions = "rcv",
 .flags  = AVFMT_GENERIC_INDEX,
 };
-- 
1.7.1

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

[FFmpeg-devel] [PATCH v3] fate: add api-h264-slice test

2018-10-12 Thread joshdk

From: Josh de Kock 

This test ensures that you are able to send N number of slice NALUs in slice 
threaded mode to be decoded simultaneously
---

 Ignore the previous patch, had some dead code in it. This now
 works in MinGW as well.

 tests/api/Makefile  |   1 +
 tests/api/api-h264-slice-test.c | 207 +
 tests/fate/api.mak  |   4 +
 tests/ref/fate/api-h264-slice   | 309 
 4 files changed, 521 insertions(+)
 create mode 100644 tests/api/api-h264-slice-test.c
 create mode 100644 tests/ref/fate/api-h264-slice

diff --git a/tests/api/Makefile b/tests/api/Makefile
index 759dd9d243..b5c4ccae23 100644
--- a/tests/api/Makefile
+++ b/tests/api/Makefile
@@ -1,5 +1,6 @@
 APITESTPROGS-$(call ENCDEC, FLAC, FLAC) += api-flac
 APITESTPROGS-$(call DEMDEC, H264, H264) += api-h264
+APITESTPROGS-$(call DEMDEC, H264, H264) += api-h264-slice
 APITESTPROGS-yes += api-seek
 APITESTPROGS-yes += api-codec-param
 APITESTPROGS-$(call DEMDEC, H263, H263) += api-band
diff --git a/tests/api/api-h264-slice-test.c b/tests/api/api-h264-slice-test.c
new file mode 100644
index 00..aefcdc3928
--- /dev/null
+++ b/tests/api/api-h264-slice-test.c
@@ -0,0 +1,207 @@
+/*
+ * Copyright (c) 2001 Fabrice Bellard
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#define MAX_SLICES 8
+
+// ./fate 2 ./crew_cif out.y4m
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+static int header = 0;
+
+static void decode(AVCodecContext *dec_ctx, AVFrame *frame,
+   AVPacket *pkt)
+{
+static uint64_t frame_cnt = 0;
+int ret;
+
+ret = avcodec_send_packet(dec_ctx, pkt);
+if (ret < 0) {
+fprintf(stderr, "Error sending a packet for decoding: %s\n", 
av_err2str(ret));
+exit(1);
+}
+
+while (ret >= 0) {
+const AVPixFmtDescriptor *desc;
+char *sum;
+struct AVHashContext *hash;
+
+ret = avcodec_receive_frame(dec_ctx, frame);
+if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF) {
+return;
+} else if (ret < 0) {
+fprintf(stderr, "Error during decoding: %s\n", av_err2str(ret));
+exit(1);
+}
+
+if (!header) {
+printf(
+"#format: frame checksums\n"
+"#version: 2\n"
+"#hash: MD5\n"
+"#tb 0: 1/30\n"
+"#media_type 0: video\n"
+"#codec_id 0: rawvideo\n"
+"#dimensions 0: 352x288\n"
+"#sar 0: 128/117\n"
+"#stream#, dts,pts, duration, size, hash\n");
+header = 1;
+}
+desc = av_pix_fmt_desc_get(dec_ctx->pix_fmt);
+av_hash_alloc(, "md5");
+av_hash_init(hash);
+sum = av_mallocz(av_hash_get_size(hash) * 2 + 1);
+
+for (int i = 0; i < frame->height; i++)
+av_hash_update(hash, >data[0][i * frame->linesize[0]], 
frame->width);
+for (int i = 0; i < frame->height >> desc->log2_chroma_h; i++)
+av_hash_update(hash, >data[1][i * frame->linesize[1]], 
frame->width >> desc->log2_chroma_w);
+for (int i = 0; i < frame->height >> desc->log2_chroma_h; i++)
+av_hash_update(hash, >data[2][i * frame->linesize[2]], 
frame->width >> desc->log2_chroma_w);
+
+av_hash_final_hex(hash, sum, av_hash_get_size(hash) * 2 + 1);
+printf("0, %10"PRId64", %10"PRId64",1, %8d, %s\n",
+frame_cnt, frame_cnt,
+(frame->width * frame->height + 2 * (frame->height >> 
desc->log2_chroma_h) * (frame->width >> desc->log2_chroma_w)), sum); 
+frame_cnt += 1;
+av_free(hash);
+av_free(sum);
+}
+}
+
+int main(int argc, char **argv)
+{
+const AVCodec *codec;
+AVCodecContext *c = NULL;
+AVFrame *frame;
+unsigned int threads;
+AVPacket *pkt;
+FILE *fd;
+char

[FFmpeg-devel] [PATCH V2 1/2] lavf/vc1test: fix vc1test can't probe some RCV file.

2018-10-12 Thread Jun Zhao

case 1:
use the hexdump -C SMM0005.rcv get:
 size  skip (size - 4)
  ||
  VV
  18 00 00 c5 05 00 00 00  4d f1 0a 11 00 e0 01 00
0010  00 d0 02 00 00 0c 00 00  00 88 13 00 00 c0 65 52
 ^
 |
 size + 16
case 2:
same the command for SMM0015.rcv get:
size
  |
  V
  19 00 00 c5 04 00 00 00  41 f3 80 01 40 02 00 00
0010  d0 02 00 00 0c 00 00 00  00 00 00 10 00 00 00 00
  ^
  |
   size + 16

There are different the RCV file format for VC-1, vc1test
just handle the case 2 now, this fix will support the case 1.
(Both of test clips come from: RP 228:2008 - SMPTE
Recommended Practice - VC-1 Decoder and Bitstream Conformance).

Signed-off-by: Jun Zhao 
Signed-off-by: Yan, FengX 
---
 libavformat/vc1test.c |   11 +--
 1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/libavformat/vc1test.c b/libavformat/vc1test.c
index a801f4b..82e155a 100644
--- a/libavformat/vc1test.c
+++ b/libavformat/vc1test.c
@@ -34,9 +34,13 @@
 
 static int vc1t_probe(AVProbeData *p)
 {
+int size;
+
 if (p->buf_size < 24)
 return 0;
-if (p->buf[3] != 0xC5 || AV_RL32(>buf[4]) != 4 || AV_RL32(>buf[20]) 
!= 0xC)
+
+size = AV_RL32(>buf[4]);
+if (p->buf[3] != 0xC5 || AV_RL32(>buf[size+16]) != 0xC)
 return 0;
 
 return AVPROBE_SCORE_EXTENSION;
@@ -48,9 +52,10 @@ static int vc1t_read_header(AVFormatContext *s)
 AVStream *st;
 int frames;
 uint32_t fps;
+int size;
 
 frames = avio_rl24(pb);
-if(avio_r8(pb) != 0xC5 || avio_rl32(pb) != 4)
+if (avio_r8(pb) != 0xC5 || ((size = avio_rl32(pb)) < 4))
 return AVERROR_INVALIDDATA;
 
 /* init video codec */
@@ -63,6 +68,8 @@ static int vc1t_read_header(AVFormatContext *s)
 
 if (ff_get_extradata(s, st->codecpar, pb, VC1_EXTRADATA_SIZE) < 0)
 return AVERROR(ENOMEM);
+
+avio_skip(pb, size - 4);
 st->codecpar->height = avio_rl32(pb);
 st->codecpar->width = avio_rl32(pb);
 if(avio_rl32(pb) != 0xC)
-- 
1.7.1

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

[FFmpeg-devel] [PATCH v2 4/4] fate: add h264 timecode test

2018-10-12 Thread joshdk

From: Josh de Kock 

---
 tests/fate/h264.mak  |   2 +
 tests/ref/fate/h264-timecode | 305 +++
 2 files changed, 307 insertions(+)
 create mode 100644 tests/ref/fate/h264-timecode

diff --git a/tests/fate/h264.mak b/tests/fate/h264.mak
index 1839b9b44e..f14b46c6e0 100644
--- a/tests/fate/h264.mak
+++ b/tests/fate/h264.mak
@@ -196,6 +196,7 @@ FATE_H264  := $(FATE_H264:%=fate-h264-conformance-%)
\
   fate-h264-3386\
   fate-h264-missing-frame   \
   fate-h264-ref-pic-mod-overflow\
+  fate-h264-timecode
 
 FATE_H264-$(call DEMDEC, H264, H264) += $(FATE_H264)
 FATE_H264-$(call DEMDEC,  MOV, H264) += fate-h264-crop-to-container
@@ -440,6 +441,7 @@ fate-h264-twofields-packet:   CMD = 
framecrc -i $(TARGET_SAM
 fate-h264-unescaped-extradata:CMD = framecrc -i 
$(TARGET_SAMPLES)/h264/unescaped_extradata.mp4 -an -frames 10
 fate-h264-3386:   CMD = framecrc -i 
$(TARGET_SAMPLES)/h264/bbc2.sample.h264
 fate-h264-missing-frame:  CMD = framecrc -i 
$(TARGET_SAMPLES)/h264/nondeterministic_cut.h264
+fate-h264-timecode:   CMD = framecrc -i 
$(TARGET_SAMPLES)/h264/crew_cif_timecode-2.h264
 
 fate-h264-reinit-%:   CMD = framecrc -i 
$(TARGET_SAMPLES)/h264/$(@:fate-h264-%=%).h264 -vf 
format=yuv444p10le,scale=w=352:h=288
 
diff --git a/tests/ref/fate/h264-timecode b/tests/ref/fate/h264-timecode
new file mode 100644
index 00..b78f700c6d
--- /dev/null
+++ b/tests/ref/fate/h264-timecode
@@ -0,0 +1,305 @@
+#tb 0: 1/30
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 352x288
+#sar 0: 128/117
+0,  0,  0,1,   152064, 0x70684c80
+0,  1,  1,1,   152064, 0xb5c8b300
+0,  2,  2,1,   152064, 0x5777ac60
+0,  3,  3,1,   152064, 0xb27646a5
+0,  4,  4,1,   152064, 0x20bd98ec
+0,  5,  5,1,   152064, 0xcf5ac1b0
+0,  6,  6,1,   152064, 0x85a42952
+0,  7,  7,1,   152064, 0xc25aa530
+0,  8,  8,1,   152064, 0x97b14be9
+0,  9,  9,1,   152064, 0xf67ec91a
+0, 10, 10,1,   152064, 0x3890d6a3
+0, 11, 11,1,   152064, 0xc52c8467
+0, 12, 12,1,   152064, 0x30a7af36
+0, 13, 13,1,   152064, 0x27528a98
+0, 14, 14,1,   152064, 0x245c08c5
+0, 15, 15,1,   152064, 0x7e0220f3
+0, 16, 16,1,   152064, 0x4b254c89
+0, 17, 17,1,   152064, 0x1586e3e5
+0, 18, 18,1,   152064, 0x594dfc58
+0, 19, 19,1,   152064, 0x85ba9c8e
+0, 20, 20,1,   152064, 0x1e235100
+0, 21, 21,1,   152064, 0xa02c6a72
+0, 22, 22,1,   152064, 0xd1166fb6
+0, 23, 23,1,   152064, 0xcc9b1546
+0, 24, 24,1,   152064, 0x55e35a35
+0, 25, 25,1,   152064, 0xea63e2ae
+0, 26, 26,1,   152064, 0x936a1802
+0, 27, 27,1,   152064, 0x354a749c
+0, 28, 28,1,   152064, 0x5cd0f246
+0, 29, 29,1,   152064, 0x0376e69b
+0, 30, 30,1,   152064, 0x5af5fb61
+0, 31, 31,1,   152064, 0x9a053ab8
+0, 32, 32,1,   152064, 0x57cbbfcc
+0, 33, 33,1,   152064, 0x81f19e93
+0, 34, 34,1,   152064, 0x0812953d
+0, 35, 35,1,   152064, 0x0ae2a166
+0, 36, 36,1,   152064, 0x193125b8
+0, 37, 37,1,   152064, 0xab7eca7b
+0, 38, 38,1,   152064, 0x91ff1870
+0, 39, 39,1,   152064, 0x8f522dde
+0, 40, 40,1,   152064, 0x98faab46
+0, 41, 41,1,   152064, 0xa2119231
+0, 42, 42,1,   152064, 0xfe591321
+0, 43, 43,1,   152064, 0x6c8a1bf5
+0, 44, 44,1,   152064, 0x857c925c
+0, 45, 45,1,   152064, 0xe81a77f2
+0, 46, 46,1,   152064, 0x08234e83
+0, 47, 47,1,   152064, 0x76cb39f6
+0, 48, 48,1,   152064, 0x26168d25
+0, 49, 49,1,   152064, 0x4dd3b273
+0, 50, 50,1,   152064, 0xd6e8398e
+0, 51, 51,1,   152064, 0x55986a57
+0, 52, 52,1,   152064,

[FFmpeg-devel] [PATCH v4 2/4] h264/pic_timing: support multiple timecodes

2018-10-12 Thread joshdk

From: Josh de Kock 

---
 There are no cosmetic changes which are not functional here.

 libavcodec/h264_sei.c   | 21 ---
 libavcodec/h264_sei.h   | 28 +--
 libavcodec/h264_slice.c | 59 +++--
 3 files changed, 65 insertions(+), 43 deletions(-)

diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index 275224eabe..d4eb9c0dab 100644
--- a/libavcodec/h264_sei.c
+++ b/libavcodec/h264_sei.c
@@ -84,8 +84,10 @@ static int decode_picture_timing(H264SEIPictureTiming *h, 
GetBitContext *gb,
 return AVERROR_INVALIDDATA;
 
 num_clock_ts = sei_num_clock_ts_table[h->pic_struct];
+h->timecode_cnt = 0;
 for (i = 0; i < num_clock_ts; i++) {
 if (get_bits(gb, 1)) {  /* 
clock_timestamp_flag */
+H264SEITimeCode *tc = >timecode[h->timecode_cnt++];
 unsigned int full_timestamp_flag;
 unsigned int counting_type, cnt_dropped_flag;
 h->ct_type |= 1 << get_bits(gb, 2);
@@ -95,20 +97,21 @@ static int decode_picture_timing(H264SEIPictureTiming *h, 
GetBitContext *gb,
 skip_bits(gb, 1);   /* discontinuity_flag 
*/
 cnt_dropped_flag = get_bits(gb, 1);  /* cnt_dropped_flag */
 if (cnt_dropped_flag && counting_type > 1 && counting_type < 7)
-h->tc_dropframe = 1;
-h->tc_frames = get_bits(gb, 8); /* n_frames */
+tc->dropframe = 1;
+tc->frame = get_bits(gb, 8); /* n_frames */
 if (full_timestamp_flag) {
-h->fulltc_received = 1;
-h->tc_seconds = get_bits(gb, 6); /* seconds_value 0..59 */
-h->tc_minutes = get_bits(gb, 6); /* minutes_value 0..59 */
-h->tc_hours = get_bits(gb, 5);   /* hours_value 0..23 */
+tc->full = 1;
+tc->seconds = get_bits(gb, 6); /* seconds_value 0..59 */
+tc->minutes = get_bits(gb, 6); /* minutes_value 0..59 */
+tc->hours = get_bits(gb, 5);   /* hours_value 0..23 */
 } else {
+tc->seconds = tc->minutes = tc->hours = tc->full = 0;
 if (get_bits(gb, 1)) { /* seconds_flag */
-h->tc_seconds = get_bits(gb, 6);
+tc->seconds = get_bits(gb, 6);
 if (get_bits(gb, 1)) { /* minutes_flag */
-h->tc_minutes = get_bits(gb, 6);
+tc->minutes = get_bits(gb, 6);
 if (get_bits(gb, 1))   /* hours_flag */
-h->tc_minutes = get_bits(gb, 5);
+tc->hours = get_bits(gb, 5);
 }
 }
 }
diff --git a/libavcodec/h264_sei.h b/libavcodec/h264_sei.h
index 3b8806be0a..a75c3aa175 100644
--- a/libavcodec/h264_sei.h
+++ b/libavcodec/h264_sei.h
@@ -67,6 +67,17 @@ typedef enum {
 H264_SEI_FPA_TYPE_2D  = 6,
 } H264_SEI_FpaType;
 
+typedef struct H264SEITimeCode {
+/* When not continuously receiving full timecodes, we have to reference
+   the previous timecode received */
+int full;
+int frame;
+int seconds;
+int minutes;
+int hours;
+int dropframe;
+} H264SEITimeCode;
+
 typedef struct H264SEIPictureTiming {
 int present;
 H264_SEI_PicStructType pic_struct;
@@ -88,14 +99,15 @@ typedef struct H264SEIPictureTiming {
  */
 int cpb_removal_delay;
 
-/* When not continuously receiving full timecodes, we have to reference
-   the previous timecode received */
-int fulltc_received;
-int tc_frames;
-int tc_seconds;
-int tc_minutes;
-int tc_hours;
-int tc_dropframe;
+/**
+ * Maximum three timecodes in a pic_timing SEI.
+ */
+H264SEITimeCode timecode[3];
+
+/**
+ * Number of timecode in use
+ */
+int timecode_cnt;
 } H264SEIPictureTiming;
 
 typedef struct H264SEIAFD {
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index f5415ba595..2e158745a0 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1287,42 +1287,49 @@ static int h264_export_frame_props(H264Context *h)
 h->avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
 }
 
-if (h->sei.picture_timing.fulltc_received) {
+if (h->sei.picture_timing.timecode_cnt > 0) {
 uint32_t tc = 0;
-uint32_t frames;
+uint32_t *tc_sd;
 
 AVFrameSideData *tcside = av_frame_new_side_data(cur->f,
  
AV_FRAME_DATA_S12M_TIMECODE,
- sizeof(uint32_t));
+ sizeof(uint32_t)*4);

[FFmpeg-devel] [PATCH v2 1/4] lavc/h264: create AVFrame side data from H.264 timecodes

2018-10-12 Thread joshdk

From: Devin Heitmueller 

Create SMPTE ST 12-1 timecodes based on H.264 SEI picture timing
info.

For framerates > 30 FPS, the field flag is used in conjunction with
pairs of frames which contain the same frame timestamp in S12M.
Ensure the field is properly set per the spec.
---
 libavcodec/h264_sei.c   | 37 -
 libavcodec/h264_sei.h   |  9 +
 libavcodec/h264_slice.c | 38 ++
 libavutil/frame.c   |  1 +
 libavutil/frame.h   |  8 
 5 files changed, 76 insertions(+), 17 deletions(-)

diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index 43593d34d2..275224eabe 100644
--- a/libavcodec/h264_sei.c
+++ b/libavcodec/h264_sei.c
@@ -84,32 +84,35 @@ static int decode_picture_timing(H264SEIPictureTiming *h, 
GetBitContext *gb,
 return AVERROR_INVALIDDATA;
 
 num_clock_ts = sei_num_clock_ts_table[h->pic_struct];
-
 for (i = 0; i < num_clock_ts; i++) {
-if (get_bits(gb, 1)) {/* clock_timestamp_flag */
+if (get_bits(gb, 1)) {  /* 
clock_timestamp_flag */
 unsigned int full_timestamp_flag;
-
+unsigned int counting_type, cnt_dropped_flag;
 h->ct_type |= 1 << get_bits(gb, 2);
-skip_bits(gb, 1); /* nuit_field_based_flag */
-skip_bits(gb, 5); /* counting_type */
+skip_bits(gb, 1);   /* 
nuit_field_based_flag */
+counting_type = get_bits(gb, 5);/* counting_type */
 full_timestamp_flag = get_bits(gb, 1);
-skip_bits(gb, 1); /* discontinuity_flag */
-skip_bits(gb, 1); /* cnt_dropped_flag */
-skip_bits(gb, 8); /* n_frames */
+skip_bits(gb, 1);   /* discontinuity_flag 
*/
+cnt_dropped_flag = get_bits(gb, 1);  /* cnt_dropped_flag */
+if (cnt_dropped_flag && counting_type > 1 && counting_type < 7)
+h->tc_dropframe = 1;
+h->tc_frames = get_bits(gb, 8); /* n_frames */
 if (full_timestamp_flag) {
-skip_bits(gb, 6); /* seconds_value 0..59 */
-skip_bits(gb, 6); /* minutes_value 0..59 */
-skip_bits(gb, 5); /* hours_value 0..23 */
+h->fulltc_received = 1;
+h->tc_seconds = get_bits(gb, 6); /* seconds_value 0..59 */
+h->tc_minutes = get_bits(gb, 6); /* minutes_value 0..59 */
+h->tc_hours = get_bits(gb, 5);   /* hours_value 0..23 */
 } else {
-if (get_bits(gb, 1)) {/* seconds_flag */
-skip_bits(gb, 6); /* seconds_value range 0..59 
*/
-if (get_bits(gb, 1)) {/* minutes_flag */
-skip_bits(gb, 6); /* minutes_value 0..59 */
-if (get_bits(gb, 1))  /* hours_flag */
-skip_bits(gb, 5); /* hours_value 0..23 */
+if (get_bits(gb, 1)) { /* seconds_flag */
+h->tc_seconds = get_bits(gb, 6);
+if (get_bits(gb, 1)) { /* minutes_flag */
+h->tc_minutes = get_bits(gb, 6);
+if (get_bits(gb, 1))   /* hours_flag */
+h->tc_minutes = get_bits(gb, 5);
 }
 }
 }
+
 if (sps->time_offset_length > 0)
 skip_bits(gb,
   sps->time_offset_length); /* time_offset */
diff --git a/libavcodec/h264_sei.h b/libavcodec/h264_sei.h
index 5b7c8ef9d8..3b8806be0a 100644
--- a/libavcodec/h264_sei.h
+++ b/libavcodec/h264_sei.h
@@ -87,6 +87,15 @@ typedef struct H264SEIPictureTiming {
  * cpb_removal_delay in picture timing SEI message, see H.264 C.1.2
  */
 int cpb_removal_delay;
+
+/* When not continuously receiving full timecodes, we have to reference
+   the previous timecode received */
+int fulltc_received;
+int tc_frames;
+int tc_seconds;
+int tc_minutes;
+int tc_hours;
+int tc_dropframe;
 } H264SEIPictureTiming;
 
 typedef struct H264SEIAFD {
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index d09cee4b13..f5415ba595 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1287,6 +1287,44 @@ static int h264_export_frame_props(H264Context *h)
 h->avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
 }
 
+if (h->sei.picture_timing.fulltc_received) {
+uint32_t tc = 0;
+uint32_t frames;
+
+AVFrameSideData *tcside

Re: [FFmpeg-devel] ffv1enc: question about "Cannot allocate worst case packet size, the encoding could fail"

2018-10-12 Thread Jan Ekström

On Thu, Oct 11, 2018 at 4:04 PM Jerome Martinez  wrote:
>
> In this case, the ratio (148 times the size of input) is proportional to
> the input frame size, and the test is on a fixed value (MAX_INT).
> I get now the reason to reserve more than the size of the input frame.
> I don't get the relationship between your explanation and these hard
> coded values (148 times the size of input and MAX_INT limit).
>
> Why 148x (37x4) and not 147 or 149?
> Why a warning and maxsize forced to MAX_INT if maxsize > MAX_INT? Is it
> an internal constraint of FFmpeg which would be not able to store
> encoded frames bigger than MAX_INT?
>
> Can any of that be changed e.g. warning only once for avoiding "spam" of
> such warning which hides other warnings during encoding?
>
> Jérôme
>

And while it seems like we're focusing on the arbitrary limit in
av_malloc (which is an issue of its own), I do note that for this
specific case this "worst case packed frame size" allocation heuristic
might have to be modified? Or at least explained if possible, so that
things can be improved in a proper way.

For historical context, this limit has been inside ffv1enc as follows,
number 1 being the current version:
1. avctx->width*avctx->height*37LL*4 ("added support for
AV_PIX_FMT_GBRP16" - ce2217b25eccda9f5c14022bd69792e71b417b73)
2. avctx->width*avctx->height*35LL*4 ("avcodec/ffv1enc: fix size used
for ff_alloc_packet2()" - 904a2864bdafe19d18db95ca54dfb36d72957a16)
3. avctx->width*avctx->height*((8*2+1+1)*4)/8 ("ffv1enc: switch to
encode2()." - 278d88689ba89c78f6c2667cf98025835567d78d)
4. ??? Limit was probably somewhere elsewhere or didn't exist before this

Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] fate: add api-h264-slice test

2018-10-12 Thread joshdk

From: Josh de Kock 

This test ensures that you are able to send N number of slice NALUs in slice 
threaded mode to be decoded simultaneously
---
 tests/api/Makefile  |   1 +
 tests/api/api-h264-slice-test.c | 213 ++
 tests/fate/api.mak  |   4 +
 tests/ref/fate/api-h264-slice   | 309 
 4 files changed, 527 insertions(+)
 create mode 100644 tests/api/api-h264-slice-test.c
 create mode 100644 tests/ref/fate/api-h264-slice

diff --git a/tests/api/Makefile b/tests/api/Makefile
index 759dd9d243..b5c4ccae23 100644
--- a/tests/api/Makefile
+++ b/tests/api/Makefile
@@ -1,5 +1,6 @@
 APITESTPROGS-$(call ENCDEC, FLAC, FLAC) += api-flac
 APITESTPROGS-$(call DEMDEC, H264, H264) += api-h264
+APITESTPROGS-$(call DEMDEC, H264, H264) += api-h264-slice
 APITESTPROGS-yes += api-seek
 APITESTPROGS-yes += api-codec-param
 APITESTPROGS-$(call DEMDEC, H263, H263) += api-band
diff --git a/tests/api/api-h264-slice-test.c b/tests/api/api-h264-slice-test.c
new file mode 100644
index 00..49c4153338
--- /dev/null
+++ b/tests/api/api-h264-slice-test.c
@@ -0,0 +1,213 @@
+/*
+ * Copyright (c) 2001 Fabrice Bellard
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#define MAX_SLICES 8
+
+// ./fate 2 ./crew_cif out.y4m
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+static int header = 0;
+static FILE *ofd;
+
+static void decode(AVCodecContext *dec_ctx, AVFrame *frame,
+   AVPacket *pkt)
+{
+static uint64_t frame_cnt = 0;
+int ret;
+
+ret = avcodec_send_packet(dec_ctx, pkt);
+if (ret < 0) {
+fprintf(stderr, "Error sending a packet for decoding: %s\n", 
av_err2str(ret));
+exit(1);
+}
+
+while (ret >= 0) {
+const AVPixFmtDescriptor *desc;
+char *sum;
+struct AVHashContext *hash;
+
+ret = avcodec_receive_frame(dec_ctx, frame);
+if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF) {
+return;
+} else if (ret < 0) {
+fprintf(stderr, "Error during decoding: %s\n", av_err2str(ret));
+exit(1);
+}
+
+if (!header) {
+printf(
+"#format: frame checksums\n"
+"#version: 2\n"
+"#hash: MD5\n"
+"#tb 0: 1/30\n"
+"#media_type 0: video\n"
+"#codec_id 0: rawvideo\n"
+"#dimensions 0: 352x288\n"
+"#sar 0: 128/117\n"
+"#stream#, dts,pts, duration, size, hash\n");
+header = 1;
+}
+desc = av_pix_fmt_desc_get(dec_ctx->pix_fmt);
+av_hash_alloc(, "md5");
+av_hash_init(hash);
+sum = av_mallocz(av_hash_get_size(hash) * 2 + 1);
+
+for (int i = 0; i < frame->height; i++)
+av_hash_update(hash, >data[0][i * frame->linesize[0]], 
frame->width);
+for (int i = 0; i < frame->height >> desc->log2_chroma_h; i++)
+av_hash_update(hash, >data[1][i * frame->linesize[1]], 
frame->width >> desc->log2_chroma_w);
+for (int i = 0; i < frame->height >> desc->log2_chroma_h; i++)
+av_hash_update(hash, >data[2][i * frame->linesize[2]], 
frame->width >> desc->log2_chroma_w);
+
+av_hash_final_hex(hash, sum, av_hash_get_size(hash) * 2 + 1);
+printf("0, %10"PRId64", %10"PRId64",1, %8d, %s\n",
+frame_cnt, frame_cnt,
+(frame->width * frame->height + 2 * (frame->height >> 
desc->log2_chroma_h) * (frame->width >> desc->log2_chroma_w)), sum); 
+frame_cnt += 1;
+av_free(hash);
+av_free(sum);
+}
+}
+
+int main(int argc, char **argv)
+{
+const AVCodec *codec;
+AVCodecContext *c = NULL;
+AVFrame *frame;
+unsigned int threads;
+AVPacket *pkt;
+FILE *fd;
+char nal[MAX_SLICES * UINT16_MAX + AV_INPUT_BUFFER_PADDING_SIZE];
+int

Re: [FFmpeg-devel] [PATCH] lavf/vc1test: fix vc1test can't probe some RCV file.

2018-10-12 Thread myp...@gmail.com

On Fri, Oct 12, 2018 at 5:19 PM Carl Eugen Hoyos  wrote:

> 2018-10-12 4:37 GMT+02:00, Jun Zhao :
> > case 1:
> > use the hexdump -C SMM0005.rcv get:
> >  size  skip (size - 4)
> >   ||
> >   VV
> >   18 00 00 c5 05 00 00 00  4d f1 0a 11 00 e0 01 00
> > 0010  00 d0 02 00 00 0c 00 00  00 88 13 00 00 c0 65 52
> >  ^
> >|
> >size + 16
> > case 2:
> > same the command for SMM0015.rcv get:
> > size
> >   |
> >   V
> >   19 00 00 c5 04 00 00 00  41 f3 80 01 40 02 00 00
> > 0010  d0 02 00 00 0c 00 00 00  00 00 00 10 00 00 00 00
> >   ^
> > |
> >  size + 16
> >
> > There are different the RCV file format for VC-1, vc1test
> > just handle the case 2 now, this fix will support the case 1.
> > (Both of test clips come from: RP 228:2008 - SMPTE
> > Recommended Practice - VC-1 Decoder and Bitstream Conformance).
> >
> > Signed-off-by: Jun Zhao 
> > Signed-off-by: Yan, FengX 
> > ---
> >  libavformat/vc1test.c |   13 +++--
> >  1 files changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavformat/vc1test.c b/libavformat/vc1test.c
> > index a801f4b..38eb1a4 100644
> > --- a/libavformat/vc1test.c
> > +++ b/libavformat/vc1test.c
> > @@ -34,9 +34,13 @@
> >
> >  static int vc1t_probe(AVProbeData *p)
> >  {
> > +int size;
> > +
> >  if (p->buf_size < 24)
> >  return 0;
> > -if (p->buf[3] != 0xC5 || AV_RL32(>buf[4]) != 4 ||
> > AV_RL32(>buf[20]) != 0xC)
> > +
> > +size = AV_RL32(>buf[4]);
> > +if (p->buf[3] != 0xC5 || AV_RL32(>buf[size+16]) != 0xC)
> >  return 0;
> >
> >  return AVPROBE_SCORE_EXTENSION;
> > @@ -48,10 +52,12 @@ static int vc1t_read_header(AVFormatContext *s)
> >  AVStream *st;
> >  int frames;
> >  uint32_t fps;
> > +int size;
> >
> >  frames = avio_rl24(pb);
> > -if(avio_r8(pb) != 0xC5 || avio_rl32(pb) != 4)
>
> (Maybe it is enough to only change the "!= 4" here?)
>
> Maybe   avio_rl32(pb) >= 4 ?

> > +if (avio_r8(pb) != 0xC5)
> >  return AVERROR_INVALIDDATA;
>
> > +size = avio_rl32(pb);
> >
> >  /* init video codec */
> >  st = avformat_new_stream(s, NULL);
> > @@ -63,6 +69,8 @@ static int vc1t_read_header(AVFormatContext *s)
> >
> >  if (ff_get_extradata(s, st->codecpar, pb, VC1_EXTRADATA_SIZE) < 0)
> >  return AVERROR(ENOMEM);
> > +
> > +avio_skip(pb, size - 4);
>
> I may miss something but this looks as if you pass an unchecked
> value to avio_skip.
>
> Will add a check before the avio_skip.


> >  st->codecpar->height = avio_rl32(pb);
> >  st->codecpar->width = avio_rl32(pb);
> >  if(avio_rl32(pb) != 0xC)
>
> > @@ -114,5 +122,6 @@ AVInputFormat ff_vc1t_demuxer = {
> >  .read_probe = vc1t_probe,
> >  .read_header= vc1t_read_header,
> >  .read_packet= vc1t_read_packet,
> > + .extensions= "rcv",
>
> This is an unrelated change that should not be part of this patch.
>
Will split to the other patch for this change.

>
> Carl Eugen
> ___
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat: add SER demuxer

2018-10-12 Thread Paul B Mahol

Fixes #6821.

Signed-off-by: Paul B Mahol 
---
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/serdec.c | 138 +++
 3 files changed, 140 insertions(+)
 create mode 100644 libavformat/serdec.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index e0222535c1..e99e9150d5 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -467,6 +467,7 @@ OBJS-$(CONFIG_SDX_DEMUXER)   += sdxdec.o
 OBJS-$(CONFIG_SEGAFILM_DEMUXER)  += segafilm.o
 OBJS-$(CONFIG_SEGAFILM_MUXER)+= segafilmenc.o
 OBJS-$(CONFIG_SEGMENT_MUXER) += segment.o
+OBJS-$(CONFIG_SER_DEMUXER)   += serdec.o
 OBJS-$(CONFIG_SHORTEN_DEMUXER)   += shortendec.o rawdec.o
 OBJS-$(CONFIG_SIFF_DEMUXER)  += siff.o
 OBJS-$(CONFIG_SINGLEJPEG_MUXER)  += rawenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 5c32ee6dff..9e41718685 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -367,6 +367,7 @@ extern AVInputFormat  ff_segafilm_demuxer;
 extern AVOutputFormat ff_segafilm_muxer;
 extern AVOutputFormat ff_segment_muxer;
 extern AVOutputFormat ff_stream_segment_muxer;
+extern AVInputFormat  ff_ser_demuxer;
 extern AVInputFormat  ff_shorten_demuxer;
 extern AVInputFormat  ff_siff_demuxer;
 extern AVOutputFormat ff_singlejpeg_muxer;
diff --git a/libavformat/serdec.c b/libavformat/serdec.c
new file mode 100644
index 00..b14bb42d28
--- /dev/null
+++ b/libavformat/serdec.c
@@ -0,0 +1,138 @@
+/*
+ * SER video demuxer
+ * Copyright (c) 2018 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/imgutils.h"
+#include "libavutil/parseutils.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/opt.h"
+#include "internal.h"
+#include "avformat.h"
+
+#define SER_MAGIC "LUCAM-RECORDER"
+
+typedef struct SERDemuxerContext {
+const AVClass *class;
+int width, height;
+AVRational framerate;
+} SERDemuxerContext;
+
+static int ser_probe(AVProbeData *pd)
+{
+if (memcmp(pd->buf, SER_MAGIC, 14) == 0)
+return AVPROBE_SCORE_MAX;
+else
+return 0;
+}
+
+static int ser_read_header(AVFormatContext *s)
+{
+SERDemuxerContext *ser = s->priv_data;
+enum AVPixelFormat pix_fmt;
+int depth, color_id, endian;
+int packet_size;
+AVStream *st;
+
+st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+
+avio_skip(s->pb, 14);
+avio_skip(s->pb, 4);
+color_id = avio_rl32(s->pb);
+endian = avio_rl32(s->pb);
+ser->width = avio_rl32(s->pb);
+ser->height = avio_rl32(s->pb);
+depth = avio_rl32(s->pb);
+st->nb_frames = st->duration = avio_rl32(s->pb);
+avio_skip(s->pb, 120);
+avio_skip(s->pb, 8);
+avio_skip(s->pb, 8);
+
+switch (color_id) {
+case   0: pix_fmt = depth <= 8 ? AV_PIX_FMT_GRAY8   : endian ? 
AV_PIX_FMT_GRAY16LE   : AV_PIX_FMT_GRAY16BE;   break;
+case   8: pix_fmt = depth <= 8 ? AV_PIX_FMT_BAYER_RGGB8 : endian ? 
AV_PIX_FMT_BAYER_RGGB16LE : AV_PIX_FMT_BAYER_RGGB16BE; break;
+case   9: pix_fmt = depth <= 8 ? AV_PIX_FMT_BAYER_GRBG8 : endian ? 
AV_PIX_FMT_BAYER_GRBG16LE : AV_PIX_FMT_BAYER_GRBG16BE; break;
+case  10: pix_fmt = depth <= 8 ? AV_PIX_FMT_BAYER_GBRG8 : endian ? 
AV_PIX_FMT_BAYER_GBRG16LE : AV_PIX_FMT_BAYER_GBRG16BE; break;
+case  11: pix_fmt = depth <= 8 ? AV_PIX_FMT_BAYER_BGGR8 : endian ? 
AV_PIX_FMT_BAYER_BGGR16LE : AV_PIX_FMT_BAYER_BGGR16BE; break;
+case 100: pix_fmt = depth <= 8 ? AV_PIX_FMT_RGB24   : endian ? 
AV_PIX_FMT_RGB48LE: AV_PIX_FMT_RGB48BE;break;
+case 101: pix_fmt = depth <= 8 ? AV_PIX_FMT_BGR24   : endian ? 
AV_PIX_FMT_BGR48LE: AV_PIX_FMT_BGR48BE;break;
+default:
+return AVERROR_PATCHWELCOME;
+}
+
+st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
+st->codecpar->codec_id = s->iformat->raw_codec_id;
+
+avpriv_set_pts_info(st, 64, ser->framerate.den, ser->framerate.num);
+
+st->codecpar->width  = ser->width;
+st->codecpar->height = ser->height;
+st->codecpar->format = pix_fmt;
+packet_size = av_image_get_buffer_size(st->codecpar->format, ser->width,

[FFmpeg-devel] [PATCH] avformat: add SER demuxer

2018-10-12 Thread Paul B Mahol

Fixes #6821.

Signed-off-by: Paul B Mahol 
---
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/serdec.c | 138 +++
 3 files changed, 140 insertions(+)
 create mode 100644 libavformat/serdec.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index e0222535c1..e99e9150d5 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -467,6 +467,7 @@ OBJS-$(CONFIG_SDX_DEMUXER)   += sdxdec.o
 OBJS-$(CONFIG_SEGAFILM_DEMUXER)  += segafilm.o
 OBJS-$(CONFIG_SEGAFILM_MUXER)+= segafilmenc.o
 OBJS-$(CONFIG_SEGMENT_MUXER) += segment.o
+OBJS-$(CONFIG_SER_DEMUXER)   += serdec.o
 OBJS-$(CONFIG_SHORTEN_DEMUXER)   += shortendec.o rawdec.o
 OBJS-$(CONFIG_SIFF_DEMUXER)  += siff.o
 OBJS-$(CONFIG_SINGLEJPEG_MUXER)  += rawenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 5c32ee6dff..9e41718685 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -367,6 +367,7 @@ extern AVInputFormat  ff_segafilm_demuxer;
 extern AVOutputFormat ff_segafilm_muxer;
 extern AVOutputFormat ff_segment_muxer;
 extern AVOutputFormat ff_stream_segment_muxer;
+extern AVInputFormat  ff_ser_demuxer;
 extern AVInputFormat  ff_shorten_demuxer;
 extern AVInputFormat  ff_siff_demuxer;
 extern AVOutputFormat ff_singlejpeg_muxer;
diff --git a/libavformat/serdec.c b/libavformat/serdec.c
new file mode 100644
index 00..1deda4935c
--- /dev/null
+++ b/libavformat/serdec.c
@@ -0,0 +1,138 @@
+/*
+ * SER video demuxer
+ * Copyright (c) 2018 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/imgutils.h"
+#include "libavutil/parseutils.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/opt.h"
+#include "internal.h"
+#include "avformat.h"
+
+#define SER_MAGIC "LUCAM-RECORDER"
+
+typedef struct SERDemuxerContext {
+const AVClass *class;
+int width, height;
+AVRational framerate;
+} SERDemuxerContext;
+
+static int ser_probe(AVProbeData *pd)
+{
+if (memcmp(pd->buf, SER_MAGIC, 14) == 0)
+return AVPROBE_SCORE_MAX;
+else
+return 0;
+}
+
+static int ser_read_header(AVFormatContext *s)
+{
+SERDemuxerContext *ser = s->priv_data;
+enum AVPixelFormat pix_fmt;
+int depth, color_id, endian;
+int packet_size;
+AVStream *st;
+
+st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+
+avio_skip(s->pb, 14);
+avio_skip(s->pb, 4);
+color_id = avio_rl32(s->pb);
+endian = avio_rl32(s->pb);
+ser->width = avio_rl32(s->pb);
+ser->height = avio_rl32(s->pb);
+depth = avio_rl32(s->pb);
+st->nb_frames = st->duration = avio_rl32(s->pb);
+avio_skip(s->pb, 120);
+avio_skip(s->pb, 8);
+avio_skip(s->pb, 8);
+
+switch (color_id) {
+case   0: pix_fmt = AV_PIX_FMT_MONOBLACK; break;
+case   8: pix_fmt = depth == 8 ? AV_PIX_FMT_BAYER_RGGB8 : endian ? 
AV_PIX_FMT_BAYER_RGGB16LE : AV_PIX_FMT_BAYER_RGGB16BE; break;
+case   9: pix_fmt = depth == 8 ? AV_PIX_FMT_BAYER_GRBG8 : endian ? 
AV_PIX_FMT_BAYER_GRBG16LE : AV_PIX_FMT_BAYER_GRBG16BE; break;
+case  10: pix_fmt = depth == 8 ? AV_PIX_FMT_BAYER_GBRG8 : endian ? 
AV_PIX_FMT_BAYER_GBRG16LE : AV_PIX_FMT_BAYER_GBRG16BE; break;
+case  11: pix_fmt = depth == 8 ? AV_PIX_FMT_BAYER_BGGR8 : endian ? 
AV_PIX_FMT_BAYER_BGGR16LE : AV_PIX_FMT_BAYER_BGGR16BE; break;
+case 100: pix_fmt = depth == 8 ? AV_PIX_FMT_RGB24   : endian ? 
AV_PIX_FMT_RGB48LE: AV_PIX_FMT_RGB48BE;break;
+case 101: pix_fmt = depth == 8 ? AV_PIX_FMT_BGR24   : endian ? 
AV_PIX_FMT_BGR48LE: AV_PIX_FMT_BGR48BE;break;
+default:
+return AVERROR_PATCHWELCOME;
+}
+
+st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
+st->codecpar->codec_id = s->iformat->raw_codec_id;
+
+avpriv_set_pts_info(st, 64, ser->framerate.den, ser->framerate.num);
+
+st->codecpar->width  = ser->width;
+st->codecpar->height = ser->height;
+st->codecpar->format = pix_fmt;
+packet_size = av_image_get_buffer_size(st->codecpar->format, ser->width, 
ser->height, 1);
+if (packet_size < 0)
+return packet_size;
+

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc_hevc: correction for QSV HEVC default plugin selection on Windows

2018-10-12 Thread Maxym Dmytrychenko

On Tue, Oct 9, 2018 at 3:50 AM Landgraph  wrote:

> 1. Old logic meaned: everywhere, except Windows, ffmpeg has to use HW
> acceleration, but on Windows ffmpeg has to use (unavailable) software
> encode by default
> 2. Software encode is available only if you provide corresponding
> software MediaSDK library, which isn't provided with ffmpeg. More
> information could be found in
>
> https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/samples/readme-encode_linux.pdf
> 3. HW encode is available on Windows in the driver by default
> ---
>   libavcodec/qsvenc_hevc.c | 4 
>   1 file changed, 4 deletions(-)
>
> diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
> index 4339b316a3..e7ca27d49f 100644
> --- a/libavcodec/qsvenc_hevc.c
> +++ b/libavcodec/qsvenc_hevc.c
> @@ -217,11 +217,7 @@ static av_cold int qsv_enc_close(AVCodecContext
> *avctx)
>   return ff_qsv_enc_close(avctx, >qsv);
>   }
>
> -#if defined(_WIN32)
> -#define LOAD_PLUGIN_DEFAULT LOAD_PLUGIN_HEVC_SW
> -#else
>   #define LOAD_PLUGIN_DEFAULT LOAD_PLUGIN_HEVC_HW
> -#endif
>
>   #define OFFSET(x) offsetof(QSVHEVCEncContext, x)
>   #define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
> --
> 2.14.1.windows.1
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


it is good switch for HW configuration per default, agree.
LGTM

regards
Maxym
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] ffv1enc: question about "Cannot allocate worst case packet size, the encoding could fail"

2018-10-12 Thread Jerome Martinez


On 12/10/2018 11:15, Carl Eugen Hoyos wrote:

2018-10-11 14:01 GMT+02:00, Jerome Martinez :


- why is having a number > INT_MAX an issue? modern machines
are 64-bit and have 8+ GB of RAM

So where is the issue?



The issue is that vanilla FFmpeg shows a warning in the scenario I 
indicate (a 128 MB frame, far less than 2 GB), without obvious reason of 
this warning (the multiplier used and the underlying limitation to 2 GB, 
lower than the available RAM, are hard coded without comments about the 
reason).




If above is true for you, can can simply remove the check locally, no?


My goal is that **others** don't have this warning when they use a 
vanilla version of FFmpeg.
Before sending a patch for removing the limitation I don't understand 
(or lowering a number I don't understand), I ask if there is a reason 
for it (I guess that if this code is here, there is a reason and I 
imagined that FFmpeg developers could kindly explain the reason), isn't 
it the right thing to do? Do you prefer that I send directly a patch?



(I hope you agree that what you write is not generally true.)


I don't catch what you want to indicate: do you mean that the only way 
in FFmpeg to be compatible with all machines is to set an hard coded 
limit to 2 GB?
I don't catch the goal, as you can have machines with 1 GB so this test 
would be useless on them (it will not prevent other parts of the code to 
have to do checks about RAM allocations) as well for machines having lot 
of RAM (they can handle big frames).


As I understand, the following test:
    if ((ret = ff_alloc_packet2(avctx, pkt, maxsize, 0)) < 0)
    return ret;

permits to check that FFmpeg has enough RAM for storing the max encoded 
frame size, whatever is the size of the RAM (1 GB or 8 GB), so I don't 
understand the reason maxsize is limited to 2 GB before the call to 
ff_alloc_packet2.


I kindly request more details about how hard coding 2 GB in the code 
helps, for both machines having 1 GB & machines having 8 GB. Looks like 
I am personally not smart enough for understanding that alone.


Jérôme


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

Re: [FFmpeg-devel] [PATCH] lavf/vc1test: fix vc1test can't probe some RCV file.

2018-10-12 Thread Carl Eugen Hoyos

2018-10-12 4:37 GMT+02:00, Jun Zhao :
> case 1:
> use the hexdump -C SMM0005.rcv get:
>  size  skip (size - 4)
>   ||
>   VV
>   18 00 00 c5 05 00 00 00  4d f1 0a 11 00 e0 01 00
> 0010  00 d0 02 00 00 0c 00 00  00 88 13 00 00 c0 65 52
>  ^
>|
>size + 16
> case 2:
> same the command for SMM0015.rcv get:
> size
>   |
>   V
>   19 00 00 c5 04 00 00 00  41 f3 80 01 40 02 00 00
> 0010  d0 02 00 00 0c 00 00 00  00 00 00 10 00 00 00 00
>   ^
> |
>  size + 16
>
> There are different the RCV file format for VC-1, vc1test
> just handle the case 2 now, this fix will support the case 1.
> (Both of test clips come from: RP 228:2008 - SMPTE
> Recommended Practice - VC-1 Decoder and Bitstream Conformance).
>
> Signed-off-by: Jun Zhao 
> Signed-off-by: Yan, FengX 
> ---
>  libavformat/vc1test.c |   13 +++--
>  1 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/vc1test.c b/libavformat/vc1test.c
> index a801f4b..38eb1a4 100644
> --- a/libavformat/vc1test.c
> +++ b/libavformat/vc1test.c
> @@ -34,9 +34,13 @@
>
>  static int vc1t_probe(AVProbeData *p)
>  {
> +int size;
> +
>  if (p->buf_size < 24)
>  return 0;
> -if (p->buf[3] != 0xC5 || AV_RL32(>buf[4]) != 4 ||
> AV_RL32(>buf[20]) != 0xC)
> +
> +size = AV_RL32(>buf[4]);
> +if (p->buf[3] != 0xC5 || AV_RL32(>buf[size+16]) != 0xC)
>  return 0;
>
>  return AVPROBE_SCORE_EXTENSION;
> @@ -48,10 +52,12 @@ static int vc1t_read_header(AVFormatContext *s)
>  AVStream *st;
>  int frames;
>  uint32_t fps;
> +int size;
>
>  frames = avio_rl24(pb);
> -if(avio_r8(pb) != 0xC5 || avio_rl32(pb) != 4)

(Maybe it is enough to only change the "!= 4" here?)

> +if (avio_r8(pb) != 0xC5)
>  return AVERROR_INVALIDDATA;

> +size = avio_rl32(pb);
>
>  /* init video codec */
>  st = avformat_new_stream(s, NULL);
> @@ -63,6 +69,8 @@ static int vc1t_read_header(AVFormatContext *s)
>
>  if (ff_get_extradata(s, st->codecpar, pb, VC1_EXTRADATA_SIZE) < 0)
>  return AVERROR(ENOMEM);
> +
> +avio_skip(pb, size - 4);

I may miss something but this looks as if you pass an unchecked
value to avio_skip.

>  st->codecpar->height = avio_rl32(pb);
>  st->codecpar->width = avio_rl32(pb);
>  if(avio_rl32(pb) != 0xC)

> @@ -114,5 +122,6 @@ AVInputFormat ff_vc1t_demuxer = {
>  .read_probe = vc1t_probe,
>  .read_header= vc1t_read_header,
>  .read_packet= vc1t_read_packet,
> + .extensions= "rcv",

This is an unrelated change that should not be part of this patch.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] h264/pic_timing: support multiple timecodes

2018-10-12 Thread Carl Eugen Hoyos

2018-10-11 15:04 GMT+02:00, Joshua de Kock :
> On 9 October 2018 at 21:03, Carl Eugen Hoyos  wrote:
>> 2018-10-09 15:32 GMT+02:00, jos...@ob-encoder.com :
>>> From: Josh de Kock 
>>
>>> [...]
>>
>> If the first patch gets committed as-is, please split this one
>> in a functional and a cosmetic patch, above is unreviewable.
>>
>> Thank you, Carl Eugen
>
> I assume you mean split vf_showinfo out,

No.

> I had intended to do that but clearly I forgot so will do that.

> And why is it unreviewable?

It mixed white-space-only changes with functional changes
so that the original and the new lines get separated and make
the patch much more difficult to read than necessary.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] ffv1enc: question about "Cannot allocate worst case packet size, the encoding could fail"

2018-10-12 Thread Carl Eugen Hoyos

2018-10-11 14:01 GMT+02:00, Jerome Martinez :

> - why is having a number > INT_MAX an issue? modern machines
> are 64-bit and have 8+ GB of RAM

So where is the issue?
If above is true for you, can can simply remove the check locally, no?
(I hope you agree that what you write is not generally true.)

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avcodec/libopenh264enc.c

2018-10-12 Thread Valery Kot

I sent a (hopefully valid) patch along with a proper commit message.
It resulted in a new thread, sorry.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/libopenh264enc.c: Handle sample_aspect_ratio in libopenh264 encoder

2018-10-12 Thread Valery Kot

When using libx264 (GPL) encoder, sample aspect ratio gets stored on
both container and frame levels. For libopenh264 (LGPL) encoder,
aspect ratio on codec/frame level currently is ignored, which results
in weird display aspect ratio for non-square pixels on some players.

Proposed patch fixes that, if FFmpeg being build against libopenh264
1.7 or newer.
From 2d22329e01b892576b856806c93d484c304f11d8 Mon Sep 17 00:00:00 2001
From: vkot 
Date: Fri, 12 Oct 2018 09:02:59 +0200
Subject: [PATCH] Handle sample_aspect_ratio in libopenh264 encoder

---
 libavcodec/libopenh264enc.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 83c3f0ce20..c630dff33c 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -164,6 +164,32 @@ FF_ENABLE_DEPRECATION_WARNINGS
 param.sSpatialLayers[0].iSpatialBitrate = param.iTargetBitrate;
 param.sSpatialLayers[0].iMaxSpatialBitrate  = param.iMaxBitrate;
 
+#if OPENH264_VER_AT_LEAST(1, 7)
+if(avctx->sample_aspect_ratio.num == 0 || avctx->sample_aspect_ratio.den 
== 0)
+param.sSpatialLayers[0].bAspectRatioPresent = false;
+else {
+param.sSpatialLayers[0].bAspectRatioPresent = true;
+if  (!av_cmp_q(av_make_q( 1,  1), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_1x1;
+else if (!av_cmp_q(av_make_q(12, 11), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_12x11;
+else if (!av_cmp_q(av_make_q(10, 11), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_10x11;
+else if (!av_cmp_q(av_make_q(16, 11), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_16x11;
+else if (!av_cmp_q(av_make_q(40, 33), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_40x33;
+else if (!av_cmp_q(av_make_q(24, 11), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_24x11;
+else if (!av_cmp_q(av_make_q(20, 11), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_20x11;
+else if (!av_cmp_q(av_make_q(32, 11), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_32x11;
+else if (!av_cmp_q(av_make_q(80, 33), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_80x33;
+else if (!av_cmp_q(av_make_q(18, 11), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_18x11;
+else if (!av_cmp_q(av_make_q(15, 11), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_15x11;
+else if (!av_cmp_q(av_make_q(64, 33), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_64x33;
+else if (!av_cmp_q(av_make_q(160,99), avctx->sample_aspect_ratio))  
param.sSpatialLayers[0].eAspectRatio = ASP_160x99;
+else {
+param.sSpatialLayers[0].eAspectRatio = ASP_EXT_SAR;
+param.sSpatialLayers[0].sAspectRatioExtWidth = 
avctx->sample_aspect_ratio.num;
+param.sSpatialLayers[0].sAspectRatioExtHeight = 
avctx->sample_aspect_ratio.den;
+}
+}
+#endif
+
 if ((avctx->slices > 1) && (s->max_nal_size)) {
 av_log(avctx, AV_LOG_ERROR,
"Invalid combination -slices %d and -max_nal_size %d.\n",
-- 
2.15.1.windows.2

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

[FFmpeg-devel] [PATCH] avformat/utils: Never store negative values in last_IP_duration

Re: [FFmpeg-devel] ffv1enc: question about "Cannot allocate worst case packet size, the encoding could fail"

Re: [FFmpeg-devel] [PATCH V2 1/2] lavf/vc1test: fix vc1test can't probe some RCV file.

[FFmpeg-devel] [PATCH 1/2] avcodec: Implement Archimedes VIDC encoder/decoder

[FFmpeg-devel] [PATCH 2/2] avformat/rpl: Support files containing 8 bit PCM or VIDC audio

Re: [FFmpeg-devel] [PATCH 10/12] lavf/mxfdec: demux s436m as eia608 subtitle track

Re: [FFmpeg-devel] [PATCH v2] lavf/mxfenc: support creating s436m data tracks

Re: [FFmpeg-devel] [PATCH 04/12] avformat/mxfenc: update body partition with footer offset

Re: [FFmpeg-devel] [PATCH 03/12] avformat/mxfenc: add mpeg-2 specific metadata, fix compatibility with sony content browser

Re: [FFmpeg-devel] [PATCH 05/12] avformat/mxfenc: correctly set content package rate in system element

Re: [FFmpeg-devel] [PATCH 02/12] avformat/mxfenc: write index delta entry array needed by sony vegas pro 11

Re: [FFmpeg-devel] [PATCH 1/2] lavc/qsvenc_jpeg: add async_depth support

Re: [FFmpeg-devel] [PATCH V2 1/2] lavf/vc1test: fix vc1test can't probe some RCV file.

Re: [FFmpeg-devel] ffv1enc: question about "Cannot allocate worst case packet size, the encoding could fail"

Re: [FFmpeg-devel] ffv1enc: question about "Cannot allocate worst case packet size, the encoding could fail"

Re: [FFmpeg-devel] [PATCH V2 1/2] lavf/vc1test: fix vc1test can't probe some RCV file.

Re: [FFmpeg-devel] ffv1enc: question about "Cannot allocate worst case packet size, the encoding could fail"

[FFmpeg-devel] [PATCH V2 2/2] lavf/vc1test: add rcv to vc1test demuxer extensions

[FFmpeg-devel] [PATCH v3] fate: add api-h264-slice test

[FFmpeg-devel] [PATCH V2 1/2] lavf/vc1test: fix vc1test can't probe some RCV file.

[FFmpeg-devel] [PATCH v2 4/4] fate: add h264 timecode test

[FFmpeg-devel] [PATCH v4 2/4] h264/pic_timing: support multiple timecodes

[FFmpeg-devel] [PATCH v2 1/4] lavc/h264: create AVFrame side data from H.264 timecodes

Re: [FFmpeg-devel] ffv1enc: question about "Cannot allocate worst case packet size, the encoding could fail"

[FFmpeg-devel] [PATCH] fate: add api-h264-slice test

Re: [FFmpeg-devel] [PATCH] lavf/vc1test: fix vc1test can't probe some RCV file.

[FFmpeg-devel] [PATCH] avformat: add SER demuxer

[FFmpeg-devel] [PATCH] avformat: add SER demuxer

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc_hevc: correction for QSV HEVC default plugin selection on Windows

Re: [FFmpeg-devel] ffv1enc: question about "Cannot allocate worst case packet size, the encoding could fail"

Re: [FFmpeg-devel] [PATCH] lavf/vc1test: fix vc1test can't probe some RCV file.

Re: [FFmpeg-devel] [PATCH 3/3] h264/pic_timing: support multiple timecodes

Re: [FFmpeg-devel] ffv1enc: question about "Cannot allocate worst case packet size, the encoding could fail"

Re: [FFmpeg-devel] avcodec/libopenh264enc.c

[FFmpeg-devel] [PATCH] avcodec/libopenh264enc.c: Handle sample_aspect_ratio in libopenh264 encoder

35 matches

Site Navigation

Mail list logo

Footer information