Re: [FFmpeg-devel] [PATCH] libavformat/dnxhddec added support for raw 444 and dnxhr formats

2016-02-08 Thread Christophe Gisquet 
Hi,

2016-02-08 8:15 GMT+01:00 Christophe Gisquet :
> At this point, I'd say the encoder would better use that prefix.
> That's what the attached patch does (rebased but not tested). You may
> consider building on top of it for that purpose.

Which I haven't attached... So here's one /not/ rebased, but that
should provide the same information, should that interest you.

BR,
-- 
Christophe
From 89e2da58de95af055b16c513de746a0cb64dd33c Mon Sep 17 00:00:00 2001
From: Christophe Gisquet 
Date: Fri, 2 Oct 2015 10:38:22 +0200
Subject: [PATCH 2/7] dnxhd: add and use header version

This makes it somewhat easier to extend and cleaner. The DNxHR
versions are not very well defined for lack of specs.

This also allows writing the correct header for CIDs 1256 to 1260.
---
 libavcodec/dnxhddata.c | 45 ++---
 libavcodec/dnxhddata.h | 13 +
 libavcodec/dnxhddec.c  | 16 +---
 libavcodec/dnxhdenc.c  |  3 +--
 4 files changed, 49 insertions(+), 28 deletions(-)

diff --git a/libavcodec/dnxhddata.c b/libavcodec/dnxhddata.c
index 82fbfdf..a1b452d 100644
--- a/libavcodec/dnxhddata.c
+++ b/libavcodec/dnxhddata.c
@@ -23,6 +23,13 @@
 #include "dnxhddata.h"
 #include "libavutil/common.h"
 
+const uint8_t ff_dnxhd_headers[DNXHD_HEADER_VERSIONS][5] = {
+{ 0x00, 0x00, 0x02, 0x80, 0x01 },
+{ 0x00, 0x00, 0x02, 0x80, 0x02 },
+{ 0x00, 0x00, 0x02, 0x80, 0x03 },
+{ 0x00, 0x00, 0x03, 0x8C, 0x03 },
+};
+
 /* The quantization tables below are in zigzag order! */
 
 /* Used in CID 1235, 1256, 1270 */
@@ -932,7 +939,7 @@ static const uint8_t dnxhd_1250_run[62] = {
 
 const CIDEntry ff_dnxhd_cid_table[] = {
 { 1235, 1920, 1080, 917504, 917504,
-  0, 6, 10, 4,
+  DNXHD_HEADER_INITIAL, 0, 6, 10, 4,
   dnxhd_1235_luma_weight, dnxhd_1235_chroma_weight,
   dnxhd_1235_dc_codes, dnxhd_1235_dc_bits,
   dnxhd_1235_ac_codes, dnxhd_1235_ac_bits, dnxhd_1235_ac_info,
@@ -940,7 +947,7 @@ const CIDEntry ff_dnxhd_cid_table[] = {
   { 175, 185, 365, 440 },
   { { 24000, 1001 }, { 25, 1 }, { 50, 1 }, { 6, 1001 } } },
 { 1237, 1920, 1080, 606208, 606208,
-  0, 4, 8, 3,
+  DNXHD_HEADER_INITIAL, 0, 4, 8, 3,
   dnxhd_1237_luma_weight, dnxhd_1237_chroma_weight,
   dnxhd_1237_dc_codes, dnxhd_1237_dc_bits,
   dnxhd_1237_ac_codes, dnxhd_1237_ac_bits, dnxhd_1237_ac_info,
@@ -948,7 +955,7 @@ const CIDEntry ff_dnxhd_cid_table[] = {
   { 115, 120, 145, 240, 290 },
   { { 24000, 1001 }, { 25, 1 }, { 3, 1001 }, { 50, 1 }, { 6, 1001 } } },
 { 1238, 1920, 1080, 917504, 917504,
-  0, 4, 8, 4,
+  DNXHD_HEADER_INITIAL, 0, 4, 8, 4,
   dnxhd_1238_luma_weight, dnxhd_1238_chroma_weight,
   dnxhd_1237_dc_codes, dnxhd_1237_dc_bits,
   dnxhd_1238_ac_codes, dnxhd_1238_ac_bits, dnxhd_1238_ac_info,
@@ -956,7 +963,7 @@ const CIDEntry ff_dnxhd_cid_table[] = {
   { 175, 185, 220, 365, 440 },
   { { 24000, 1001 }, { 25, 1 }, { 3, 1001 }, { 50, 1 }, { 6, 1001 } } },
 { 1241, 1920, 1080, 917504, 458752,
-  DNXHD_INTERLACED, 6, 10, 4,
+  DNXHD_HEADER_INITIAL, DNXHD_INTERLACED, 6, 10, 4,
   dnxhd_1241_luma_weight, dnxhd_1241_chroma_weight,
   dnxhd_1235_dc_codes, dnxhd_1235_dc_bits,
   dnxhd_1235_ac_codes, dnxhd_1235_ac_bits, dnxhd_1235_ac_info,
@@ -964,7 +971,7 @@ const CIDEntry ff_dnxhd_cid_table[] = {
   { 185, 220 },
   { { 25, 1 }, { 3, 1001 } } },
 { 1242, 1920, 1080, 606208, 303104,
-  DNXHD_INTERLACED, 4, 8, 3,
+  DNXHD_HEADER_INITIAL, DNXHD_INTERLACED, 4, 8, 3,
   dnxhd_1242_luma_weight, dnxhd_1242_chroma_weight,
   dnxhd_1237_dc_codes, dnxhd_1237_dc_bits,
   dnxhd_1237_ac_codes, dnxhd_1237_ac_bits, dnxhd_1237_ac_info,
@@ -972,7 +979,7 @@ const CIDEntry ff_dnxhd_cid_table[] = {
   { 120, 145 },
   { { 25, 1 }, { 3, 1001 } } },
 { 1243, 1920, 1080, 917504, 458752,
-  DNXHD_INTERLACED, 4, 8, 4,
+  DNXHD_HEADER_INITIAL, DNXHD_INTERLACED, 4, 8, 4,
   dnxhd_1243_luma_weight, dnxhd_1243_chroma_weight,
   dnxhd_1237_dc_codes, dnxhd_1237_dc_bits,
   dnxhd_1238_ac_codes, dnxhd_1238_ac_bits, dnxhd_1238_ac_info,
@@ -980,7 +987,7 @@ const CIDEntry ff_dnxhd_cid_table[] = {
   { 185, 220 },
   { { 25, 1 }, { 3, 1001 } } },
 { 1250, 1280,  720, 458752, 458752,
-  0, 6, 10, 4,
+  DNXHD_HEADER_INITIAL, 0, 6, 10, 4,
   dnxhd_1250_luma_weight, dnxhd_1250_chroma_weight,
   dnxhd_1235_dc_codes, dnxhd_1235_dc_bits,
   dnxhd_1250_ac_codes, dnxhd_1250_ac_bits, dnxhd_1250_ac_info,
@@ -988,7 +995,7 @@ const CIDEntry ff_dnxhd_cid_table[] = {
   { 90, 90, 180, 220 },
   { { 24000, 1001 }, { 25, 1 }, { 50, 1 }, { 6, 1001 } } },
 { 1251, 1280,  720, 458752, 458752,
-  0, 4, 8, 4,
+  DNXHD_HEADER_INITIAL, 0, 4, 8, 4,
   dnxhd_1251_luma_weight, dnxhd_1251_chroma_weight,
   dnxhd_1237_dc_codes,

Re: [FFmpeg-devel] [PATCH] libavformat/dnxhddec added support for raw 444 and dnxhr formats

2016-02-08 Thread Mark Reid 
On Mon, Feb 8, 2016 at 1:25 AM, Christophe Gisquet
 wrote:
> Hi,
>
> 2016-02-08 8:15 GMT+01:00 Christophe Gisquet :
>> At this point, I'd say the encoder would better use that prefix.
>> That's what the attached patch does (rebased but not tested). You may
>> consider building on top of it for that purpose.
>
> Which I haven't attached... So here's one /not/ rebased, but that
> should provide the same information, should that interest you.
>
> BR,
> --
> Christophe
>

Thanks! That looks much better, I'll rebase on top of that and send a
new patch, I'll also  add a fate test. I'm guessing its okay to
include "libavcodec/dnxhddata.h" in something thats in libavformat
then? movenc.c uses those prefixes too.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/dnxhddec added support for raw 444 and dnxhr formats

2016-02-08 Thread Christophe Gisquet 
Hi,

2016-02-09 6:27 GMT+01:00 Mark Reid :
[...]
> I'm guessing its okay to
> include "libavcodec/dnxhddata.h" in something thats in libavformat
> then? movenc.c uses those prefixes too.

Argh, nice catch, you can't use the the content of ff_dnxhd_headers
there, which is the point.

I didn't notice the avformat in the path of dnxhddec.

Please ignore my patch, or if you like, just have constructs to allow
iterations.

The only problem would be in the dnxhd libavcodec encoder, which could
write an incorrect header version depending on the CID.

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

Re: [FFmpeg-devel] [PATCH] libavformat/dnxhddec added support for raw 444 and dnxhr formats

2016-02-08 Thread Carl Eugen Hoyos 
Mark Reid  gmail.com> writes:

> I'm guessing its okay to include "libavcodec/dnxhddata.h" 
> in something thats in libavformat then?

Yes, it is ok to include headers from libavcodec in 
libavformat. It may be more complicated with symbols 
though.

Carl Eugen

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

[FFmpeg-devel] [PATCH] libavformat/dnxhddec added support for raw 444 and dnxhr formats

2016-02-07 Thread Mark Reid 
---
 libavcodec/dnxhd_parser.c | 19 ---
 libavformat/dnxhddec.c| 14 +++---
 2 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/libavcodec/dnxhd_parser.c b/libavcodec/dnxhd_parser.c
index fffb98f..83bfda8 100644
--- a/libavcodec/dnxhd_parser.c
+++ b/libavcodec/dnxhd_parser.c
@@ -26,7 +26,10 @@
 
 #include "parser.h"
 
-#define DNXHD_HEADER_PREFIX 0x02800100
+#define DNXHD_HEADER_PREFIX0x02800100
+#define DNXHD_HEADER_PREFIX444 0x02800200
+#define DNXHD_HEADER_PREFIXHR1 0x02800300
+#define DNXHD_HEADER_PREFIXHR2 0x038C0300
 
 typedef struct {
 ParseContext pc;
@@ -34,6 +37,16 @@ typedef struct {
 int cur_field; /* first field is 0, second is 1 */
 } DNXHDParserContext;
 
+static int dnxhd_is_prefix(uint64_t prefix)
+{
+  if (prefix == DNXHD_HEADER_PREFIX||
+  prefix == DNXHD_HEADER_PREFIX444 ||
+  prefix == DNXHD_HEADER_PREFIXHR1 ||
+  prefix == DNXHD_HEADER_PREFIXHR2)
+  return 1;
+  return 0;
+}
+
 static int dnxhd_find_frame_end(DNXHDParserContext *dctx,
 const uint8_t *buf, int buf_size)
 {
@@ -47,7 +60,7 @@ static int dnxhd_find_frame_end(DNXHDParserContext *dctx,
 if (!pic_found) {
 for (i = 0; i < buf_size; i++) {
 state = (state << 8) | buf[i];
-if ((state & 0xff00LL) == DNXHD_HEADER_PREFIX) {
+if (dnxhd_is_prefix(state & 0xff00LL)) {
 i++;
 pic_found = 1;
 interlaced = (state&2)>>1; /* byte following the 5-byte header 
prefix */
@@ -62,7 +75,7 @@ static int dnxhd_find_frame_end(DNXHDParserContext *dctx,
 return 0;
 for (; i < buf_size; i++) {
 state = (state << 8) | buf[i];
-if ((state & 0xff00LL) == DNXHD_HEADER_PREFIX) {
+if (dnxhd_is_prefix(state & 0xff00LL)) {
 if (!interlaced || dctx->cur_field) {
 pc->frame_start_found = 0;
 pc->state64 = -1;
diff --git a/libavformat/dnxhddec.c b/libavformat/dnxhddec.c
index 37e52d5..d26667d 100644
--- a/libavformat/dnxhddec.c
+++ b/libavformat/dnxhddec.c
@@ -26,18 +26,26 @@
 
 static int dnxhd_probe(AVProbeData *p)
 {
-static const uint8_t header[] = {0x00,0x00,0x02,0x80,0x01};
+static const uint8_t header_prefix[]= { 0x00, 0x00, 0x02, 0x80, 0x01 };
+static const uint8_t header_prefix444[] = { 0x00, 0x00, 0x02, 0x80, 0x02 };
+static const uint8_t header_prefixhr1[] = { 0x00, 0x00, 0x02, 0x80, 0x03 };
+static const uint8_t header_prefixhr2[] = { 0x00, 0x00, 0x03, 0x8C, 0x03 };
+
 int w, h, compression_id;
 if (p->buf_size < 0x2c)
 return 0;
-if (memcmp(p->buf, header, 5))
+if (memcmp(p->buf, header_prefix,5) &&
+memcmp(p->buf, header_prefix444, 5) &&
+memcmp(p->buf, header_prefixhr1, 5) &&
+memcmp(p->buf, header_prefixhr2, 5))
 return 0;
 h = AV_RB16(p->buf + 0x18);
 w = AV_RB16(p->buf + 0x1a);
 if (!w || !h)
 return 0;
 compression_id = AV_RB32(p->buf + 0x28);
-if (compression_id < 1235 || compression_id > 1260)
+if ((compression_id < 1235 || compression_id > 1260) &&
+(compression_id < 1270 || compression_id > 1274))
 return 0;
 return AVPROBE_SCORE_MAX;
 }
-- 
2.4.1

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

Re: [FFmpeg-devel] [PATCH] libavformat/dnxhddec added support for raw 444 and dnxhr formats

2016-02-07 Thread Christophe Gisquet 
Hi,

2016-02-08 2:31 GMT+01:00 Mark Reid :

> +static int dnxhd_is_prefix(uint64_t prefix)
> +{
> +  if (prefix == DNXHD_HEADER_PREFIX||
> +  prefix == DNXHD_HEADER_PREFIX444 ||
> +  prefix == DNXHD_HEADER_PREFIXHR1 ||
> +  prefix == DNXHD_HEADER_PREFIXHR2)
> +  return 1;
> +  return 0;
> +}
> +
>  static int dnxhd_find_frame_end(DNXHDParserContext *dctx,
>  const uint8_t *buf, int buf_size)
>  {
> @@ -47,7 +60,7 @@ static int dnxhd_find_frame_end(DNXHDParserContext *dctx,
>  if (!pic_found) {
>  for (i = 0; i < buf_size; i++) {
>  state = (state << 8) | buf[i];
> -if ((state & 0xff00LL) == DNXHD_HEADER_PREFIX) {
> +if (dnxhd_is_prefix(state & 0xff00LL)) {

OK.

>  static int dnxhd_probe(AVProbeData *p)
>  {
> -static const uint8_t header[] = {0x00,0x00,0x02,0x80,0x01};
> +static const uint8_t header_prefix[]= { 0x00, 0x00, 0x02, 0x80, 0x01 
> };
> +static const uint8_t header_prefix444[] = { 0x00, 0x00, 0x02, 0x80, 0x02 
> };
> +static const uint8_t header_prefixhr1[] = { 0x00, 0x00, 0x02, 0x80, 0x03 
> };
> +static const uint8_t header_prefixhr2[] = { 0x00, 0x00, 0x03, 0x8C, 0x03 
> };
> +
>  int w, h, compression_id;
>  if (p->buf_size < 0x2c)
>  return 0;
> -if (memcmp(p->buf, header, 5))
> +if (memcmp(p->buf, header_prefix,5) &&
> +memcmp(p->buf, header_prefix444, 5) &&
> +memcmp(p->buf, header_prefixhr1, 5) &&
> +memcmp(p->buf, header_prefixhr2, 5))

At this point, I'd say the encoder would better use that prefix.
That's what the attached patch does (rebased but not tested). You may
consider building on top of it for that purpose.

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