Re: [FFmpeg-devel] [PATCH] avformat/dump: Fix context/level for payload dump

[Michael Niedermayer]

On Sat, Mar 05, 2016 at 09:10:00AM -0800, Mark Harris wrote:
> Use the context and level specified to av_pkt_dump_log2(),
> instead of panic level (0), for dumping packet payload.
> ---
>  libavformat/dump.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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

[FFmpeg-devel] [PATCH 2/2] version.sh: Add next release to the version

[Timothy Gu]

Also make consistent the fallback versions.

This patch uses a RELEASE-based approach rather than a tag-based one.
There are several reasons for this. First, the -dev tags never convey
more information than RELEASE. Second, RELEASE can provide a version
even without Git.

The new script is designed to be fairly robust, tested under a plethora
of conditions.
---
 RELEASE|  2 +-
 version.sh | 50 +++---
 2 files changed, 32 insertions(+), 20 deletions(-)

diff --git a/RELEASE b/RELEASE
index b889d20..f25eb1f 100644
--- a/RELEASE
+++ b/RELEASE
@@ -1 +1 @@
-3.0.git
+n3.1-master
diff --git a/version.sh b/version.sh
index c46aec5..e92c811 100755
--- a/version.sh
+++ b/version.sh
@@ -4,42 +4,54 @@
 
 export GIT_DIR="$1/.git"
 
-# check for git short hash
+# Check version using git describe.
 if ! test "$revision"; then
-if (cd "$1" && grep git RELEASE 2> /dev/null >/dev/null) ; then
+if (cd "$1" && grep -q master RELEASE); then
+# If we are not in a release branch, use the N-based
+# revision.
 revision=$(git describe --tags --match N 2> /dev/null)
 else
-revision=$(git describe --tags --always 2> /dev/null)
+# Check if there is a tag on this commit.
+test "$version" || version=$(git describe --tags --exact-match 2> 
/dev/null)
+
+# If not, use git describe to find delta from latest tag
+# as the revision.
+revision=$(git describe --tags 2> /dev/null | cut -d- -f2-)
 fi
 fi
 
 # Shallow Git clones (--depth) do not have the N tag:
-# use 'git--MM-DD-hhh'.
-test "$revision" || revision=$(
-  git log -1 --pretty=format:"git-%cd-%h" --date=short 2> /dev/null)
+# use 'ghhh'.
+if ! test "$revision"; then
+revision=$(git log -1 --pretty=format:"%h" 2> /dev/null)
+test "$revision" && revision=g$revision
+fi
 
 # Snapshots from gitweb are in a directory called ffmpeg-hhh or
 # ffmpeg-HEAD-hhh.
 if [ -z "$revision" ]; then
-  srcdir=$(cd "$1" && pwd)
-  case "$srcdir" in
-*/ffmpeg-[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f])
-  git_hash="${srcdir##*-}";;
-*/ffmpeg-HEAD-[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f])
-  git_hash="${srcdir##*-}";;
-  esac
+srcdir=$(cd "$1" && pwd)
+case "$srcdir" in
+*/ffmpeg-[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f])
+revision="g${srcdir##*-}";;
+*/ffmpeg-HEAD-[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f])
+revision="g${srcdir##*-}";;
+esac
 fi
 
-# no revision number found
-test "$revision" || revision=$(cd "$1" && cat RELEASE 2> /dev/null)
+# If we have a revision prepend it with a hyphen.
+test "$revision" && revision="-$revision"
+
+# Prepend RELEASE.
+revision=$(cat "$1/RELEASE" | cut -d- -f1)-dev$revision
 
-# Append the Git hash if we have one
-test "$revision" && test "$git_hash" && revision="$revision-$git_hash"
+# Check if this is a release through the VERSION file
+test "$version" || version=$(cd "$1" && cat VERSION 2> /dev/null)
 
-# releases extract the version number from the VERSION file
-version=$(cd "$1" && cat VERSION 2> /dev/null)
+# If not a release, use the revision.
 test "$version" || version=$revision
 
+# Append any extra version string.
 test -n "$3" && version=$version-$3
 
 if [ -z "$2" ]; then
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 0/2] New versioning (was: version.sh: Always use latest tag for generated version number)

[Timothy Gu]

This patch set implements the versioning algorithm I recently proposed.
The first patch addresses an already existing problem with version.sh.
The second is the one actually implementing the change.

To Michael and all release makers: after this patchset when making a
release in a release branch, please do ALL of the following in the
following order.

1. cp RELEASE VERSION
2. git add VERSION
3. Update doc/Doxyfile and Changelog
4. git commit -a -m "Update for $(cat VERSION)"
5. git tag -a -m "Release $(cat VERSION)"
6. Edit RELEASE to make it contain next version
7. git rm VERSION
8. git commit -a -m "Next release is $(cat RELEASE)"

The differences to before is that, first, rather than updating RELEASE
right before a release, it must be updated after the release is made;
second, VERSION must be checked in at the tag, and removed immediately
after the release is made.

When a release branch is cut, do the following

1. Remove "-master" in RELEASE
2. git commit -a -m "Next release is $(cat RELEASE)"

Timothy Gu (2):
  version.sh: Fix Git directory
  version.sh: Add next release to the version

 RELEASE|  2 +-
 version.sh | 54 ++
 2 files changed, 35 insertions(+), 21 deletions(-)

--
1.9.1

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

[FFmpeg-devel] [PATCH 1/2] version.sh: Fix Git directory

[Timothy Gu]

This is necessary for cases where the FFmpeg directory does not have Git
metadata but the parent directories do. See e.g.
https://github.com/mxe/mxe/issues/1219.
---
 version.sh | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/version.sh b/version.sh
index a9d7e39..c46aec5 100755
--- a/version.sh
+++ b/version.sh
@@ -2,18 +2,20 @@
 
 # Usage: version.sh   
 
+export GIT_DIR="$1/.git"
+
 # check for git short hash
 if ! test "$revision"; then
 if (cd "$1" && grep git RELEASE 2> /dev/null >/dev/null) ; then
-revision=$(cd "$1" && git describe --tags --match N 2> /dev/null)
+revision=$(git describe --tags --match N 2> /dev/null)
 else
-revision=$(cd "$1" && git describe --tags --always 2> /dev/null)
+revision=$(git describe --tags --always 2> /dev/null)
 fi
 fi
 
 # Shallow Git clones (--depth) do not have the N tag:
 # use 'git--MM-DD-hhh'.
-test "$revision" || revision=$(cd "$1" &&
+test "$revision" || revision=$(
   git log -1 --pretty=format:"git-%cd-%h" --date=short 2> /dev/null)
 
 # Snapshots from gitweb are in a directory called ffmpeg-hhh or
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH] lavf/avienc: Store palette at keyframes

[Mats Peterson]

Mats Peterson  skrev: (5 mars 2016 23:31:40 
CET)
>On 03/05/2016 11:23 PM, Mats Peterson wrote:
>> On 03/05/2016 11:20 PM, Mats Peterson wrote:
>>> On 03/05/2016 11:00 PM, Mats Peterson wrote:
 Here is an experimental and much simpler solution that stores the
>last
 used palette at keyframes regardless. Maybe too simple, Michael, I
>don't
 know.

>>>
>>> This simplicity leads to storing an xxpc chunk with the same palette
>at
>>> every keyframe when there is only one palette in the original file.
>>> Perhaps not acceptable.
>>>
>>
>> It's at least better than storing an xxpc chunk for every frame.
>>
>> Mats
>>
>
>Ouch. Every packet in toon.avi contains a keyframe...
>
>Mats
>
>___
>ffmpeg-devel mailing list
>ffmpeg-devel@ffmpeg.org
>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This thing about storing xxpc palette switching chunks at every keyframe is 
rather much overkill, and more of academic interest than anything else in my 
book. Take that toon.avi file for example, every frame in it is a keyframe, yet 
it only contains two xxpc chunks. And Reimar, you would be hard pressed to find 
a 2gb 8 bpp file with xxpc chunks. This only concerns older and relatively 
short clips really. But if you want to implement something on top of what's 
already done, Michael, by all means, go ahead. Just as long as it will work 
with both stream copy, raw and non-raw video.

Mats
-- 
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] [RFC] proof-of-concept minimal inflate.

[Reimar Döffinger]

FFmpeg currently lacks a fallback inflate algorithm
when zlib is not available.
We have a lot of infrastructure for it already available
though, like VLC code reading (though only in libavcodec,
not libavutil).
This is a hackish quick-and-dirty version.
It certainly is not optimized, and I would want it to
be mostly small/simple, not necessarily fast anyway
as it would at most be a fallback.
Is there interest in me cleaning up the code and
integrating it as fallback, or are you all happy
with zlib and I should drop it?
I at least like that readability-wise this code
is miles and miles ahead of zlib...
---
 libavcodec/inflate.c | 192 +++
 1 file changed, 192 insertions(+)
 create mode 100644 libavcodec/inflate.c

diff --git a/libavcodec/inflate.c b/libavcodec/inflate.c
new file mode 100644
index 000..0340d7c
--- /dev/null
+++ b/libavcodec/inflate.c
@@ -0,0 +1,192 @@
+#define BITSTREAM_READER_LE
+
+#include "get_bits.h"
+#include "libavutil/internal.h"
+static uint16_t reverse(uint16_t x, int n)
+{
+return (ff_reverse[x & 0xFF] << 8 | ff_reverse[x >> 8]) >> (16 - n);
+}
+
+static int bits2codes(uint16_t *codes, const uint8_t *bits, int count)
+{
+int len_counts[16] = {0};
+int code_starts[16] = {0};
+int i;
+for (i = 0; i < count; i++) {
+av_assert0(bits[i] < 16);
+len_counts[bits[i]]++;
+}
+for (i = 2; i < 16; i++)
+code_starts[i] = (code_starts[i - 1] + len_counts[i - 1]) << 1;
+for (i = 0; i < count; i++) {
+int n = bits[i];
+if (!n) continue;
+codes[i] = code_starts[n]++;
+codes[i] = reverse(codes[i], n);
+}
+for (i = 0; i < 16; i++) if (code_starts[i] > (1 << i)) return 
AVERROR_INVALIDDATA;
+return 0;
+}
+
+static void get_static_huff(VLC *v, VLC *dv)
+{
+uint8_t main_bits[288 + 32];
+uint16_t main_codes[288 + 32];
+memset(main_bits, 8, 144);
+memset(main_bits + 144, 9, 256 - 144);
+memset(main_bits + 256, 7, 280 - 256);
+memset(main_bits + 280, 0, 288 - 280);
+memset(main_bits + 288, 5, 32);
+
+bits2codes(main_codes, main_bits, 288);
+ff_free_vlc(v);
+init_vlc(v, 9, 288, main_bits, 1, 1, main_codes, 2, 2, INIT_VLC_LE);
+bits2codes(main_codes + 288, main_bits + 288, 32);
+ff_free_vlc(dv);
+init_vlc(dv, 9, 32, main_bits + 288, 1, 1, main_codes + 288, 2, 2, 
INIT_VLC_LE);
+}
+
+static int build_dyn_huff(GetBitContext *gb, VLC *v, VLC *dv)
+{
+VLC tmpv;
+int i, max;
+uint8_t main_bits[288 + 32] = {0};
+uint16_t main_codes[288 + 32];
+uint8_t clen_bits[19] = {0};
+uint16_t clen_codes[19];
+int hlit = get_bits(gb, 5) + 257;
+int hdist = get_bits(gb, 5) + 1;
+int hclen = get_bits(gb, 4) + 4;
+for (i = 0; i < hclen; i++)
+{
+static const uint8_t map[19] = {
+16, 17, 18, 0, 8, 7, 9, 6, 10, 5,
+11, 4, 12, 3, 13, 2, 14, 1, 15};
+clen_bits[map[i]] = get_bits(gb, 3);
+}
+bits2codes(clen_codes, clen_bits, 19);
+init_vlc(, 7, 19, clen_bits, 1, 1, clen_codes, 2, 2, INIT_VLC_LE);
+i = 0;
+max = hlit + hdist;
+do {
+int code = get_vlc2(gb, tmpv.table, 7, 1);
+if (code < 0 || code > 18) return AVERROR_INVALIDDATA;
+if (code < 16) {
+main_bits[i++] = code;
+} else if (code == 16) {
+int cnt = get_bits(gb, 2) + 3;
+if (cnt > max - i) return AVERROR_INVALIDDATA;
+if (i == 0) return AVERROR_INVALIDDATA;
+memset(main_bits + i, main_bits[i - 1], cnt);
+i += cnt;
+} else {
+int cnt = code == 17 ? get_bits(gb, 3) + 3 : get_bits(gb, 7) + 11;
+i += cnt;
+}
+} while (i < max);
+ff_free_vlc();
+bits2codes(main_codes, main_bits, hlit);
+ff_free_vlc(v);
+init_vlc(v, 9, hlit, main_bits, 1, 1, main_codes, 2, 2, INIT_VLC_LE);
+bits2codes(main_codes + hlit, main_bits + hlit, hdist);
+ff_free_vlc(dv);
+init_vlc(dv, 9, hdist, main_bits + hlit, 1, 1, main_codes + hlit, 2, 2, 
INIT_VLC_LE);
+}
+
+static int inflate_block(GetBitContext *gb, const VLC *v, const VLC *dv, 
uint8_t *out, uint8_t *out_end)
+{
+uint8_t *start = out;
+int code;
+do {
+code = get_vlc2(gb, v->table, 9, 2);
+if (code < 0 || code > 285 || get_bits_left(gb) < 0) return 
AVERROR_INVALIDDATA;
+if (code < 256) {
+if (out >= out_end) return -1;
+*out++ = code;
+} else if (code > 256) {
+// Note: Overall length 258 has two encodings.
+// We also accept the pointless inefficient one.
+static const uint8_t len_tab[] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 10, 
12, 14, 16, 20, 24, 28, 32, 40, 48, 56, 64, 80, 96, 112, 128, 160, 192, 224, 
255};
+static const uint16_t dist_tab[] = {1, 2, 3, 4, 5, 7, 9, 13, 17, 
25, 33, 49, 65, 97, 129, 193, 257, 385, 513, 769, 1025, 1537, 2049, 3073, 4097, 
6145, 

Re: [FFmpeg-devel] [PATCH] lavf/avienc: Store palette at keyframes

[Mats Peterson]

On 03/05/2016 11:23 PM, Mats Peterson wrote:

On 03/05/2016 11:20 PM, Mats Peterson wrote:

On 03/05/2016 11:00 PM, Mats Peterson wrote:

Here is an experimental and much simpler solution that stores the last
used palette at keyframes regardless. Maybe too simple, Michael, I don't
know.



This simplicity leads to storing an xxpc chunk with the same palette at
every keyframe when there is only one palette in the original file.
Perhaps not acceptable.



It's at least better than storing an xxpc chunk for every frame.

Mats



Ouch. Every packet in toon.avi contains a keyframe...

Mats

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

Re: [FFmpeg-devel] [PATCH] lavf/avienc: Store palette at keyframes

[Mats Peterson]

On 03/05/2016 11:20 PM, Mats Peterson wrote:

On 03/05/2016 11:00 PM, Mats Peterson wrote:

Here is an experimental and much simpler solution that stores the last
used palette at keyframes regardless. Maybe too simple, Michael, I don't
know.



This simplicity leads to storing an xxpc chunk with the same palette at
every keyframe when there is only one palette in the original file.
Perhaps not acceptable.



It's at least better than storing an xxpc chunk for every frame.

Mats

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

[FFmpeg-devel] [PATCH] lavf/avienc: Store palette at keyframes

[Mats Peterson]

Here is an experimental and much simpler solution that stores the last 
used palette at keyframes regardless. Maybe too simple, Michael, I don't 
know.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From f244806bf67595bf42d3449dccd3defd4433119d Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Sat, 5 Mar 2016 22:59:09 +0100
Subject: [PATCH] lavf/avienc: Store palette at keyframes

---
 libavformat/avienc.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index 0cfffb7..e80d2d8 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -696,7 +696,7 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 int ret2 = ff_get_packet_palette(s, opkt, ret, avist->palette);
 if (ret2 < 0)
 return ret2;
-if (ret2) {
+if (ret2 || (pkt->flags & AV_PKT_FLAG_KEY)) {
 int pal_size = 1 << enc->bits_per_coded_sample;
 int pc_tag, i;
 
@@ -713,7 +713,8 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 memcpy(avist->old_palette, avist->palette, pal_size * 4);
 avist->pal_offset = 0;
 }
-if (memcmp(avist->palette, avist->old_palette, pal_size * 4)) {
+if (memcmp(avist->palette, avist->old_palette, pal_size * 4) ||
+(pkt->flags & AV_PKT_FLAG_KEY)) {
 avi_stream2fourcc(tag, stream_index, enc->codec_type);
 tag[2] = 'p'; tag[3] = 'c';
 pc_tag = ff_start_tag(pb, tag);
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH v10] VideoToolbox H.264 Encoder

[Mark Harris]

> iam not sure zthis is still an issue as the last build is a few days
> ago so maybe this is alread fixed but, theres a build failure on:
> http://fatebeta.ffmpeg.org/log/x86_64-darwin-gcc-4.8/20160303011009/compile

This was fixed by ecba35bbe305c022d59da2d7bf066e3325693c26.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/avienc: store palette at keyframes if it differs from the global one

[Mats Peterson]

On 03/05/2016 10:26 PM, Mats Peterson wrote:

On 03/05/2016 10:13 PM, Mats Peterson wrote:

On 03/05/2016 10:12 PM, Mats Peterson wrote:


Doesn't seem to work quite as expected, Michael.
Try ffmpeg -i toon.avi -vcodec copy out.avi.
The destination file will still contain only two xxpc chunks.

Mats



Well, it works with -vcodec rawvideo, but not -vcodec copy.

Mats



On stream copy, the palette won't come with every packet like it does
for e.g. "-vcodec rawvideo". So you'll need to add the keyframe xxpc
chunks outside of the "if (ret2)" block in some way.

Mats



Not only stream copy by the way, but any non-raw codec.

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/avienc: store palette at keyframes if it differs from the global one

[Mats Peterson]

On 03/05/2016 10:13 PM, Mats Peterson wrote:

On 03/05/2016 10:12 PM, Mats Peterson wrote:


Doesn't seem to work quite as expected, Michael.
Try ffmpeg -i toon.avi -vcodec copy out.avi.
The destination file will still contain only two xxpc chunks.

Mats



Well, it works with -vcodec rawvideo, but not -vcodec copy.

Mats



On stream copy, the palette won't come with every packet like it does 
for e.g. "-vcodec rawvideo". So you'll need to add the keyframe xxpc 
chunks outside of the "if (ret2)" block in some way.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v10] VideoToolbox H.264 Encoder

[Michael Niedermayer]

On Wed, Mar 02, 2016 at 08:11:40PM +0800, Rick Kern wrote:
> Autodetected by default. Encode using -codec:v h264_videotoolbox.
> 
> Signed-off-by: Rick Kern 
> ---
>  MAINTAINERS  |1 +
>  configure|   26 +-
>  libavcodec/Makefile  |1 +
>  libavcodec/allcodecs.c   |1 +
>  libavcodec/videotoolboxenc.c | 1339 
> ++
>  5 files changed, 1361 insertions(+), 7 deletions(-)
>  create mode 100644 libavcodec/videotoolboxenc.c

iam not sure zthis is still an issue as the last build is a few days
ago so maybe this is alread fixed but, theres a build failure on:
http://fatebeta.ffmpeg.org/log/x86_64-darwin-gcc-4.8/20160303011009/compile


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


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

Re: [FFmpeg-devel] [PATCH] avformat/avienc: store palette at keyframes if it differs from the global one

[Mats Peterson]

On 03/05/2016 10:12 PM, Mats Peterson wrote:


Doesn't seem to work quite as expected, Michael.
Try ffmpeg -i toon.avi -vcodec copy out.avi.
The destination file will still contain only two xxpc chunks.

Mats



Well, it works with -vcodec rawvideo, but not -vcodec copy.

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/avienc: store palette at keyframes if it differs from the global one

[Mats Peterson]

On 03/05/2016 08:44 PM, Michael Niedermayer wrote:

---
  libavformat/avienc.c |9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index 0cfffb7..8804ece 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -84,6 +84,7 @@ typedef struct AVIStream {

  uint32_t palette[AVPALETTE_COUNT];
  uint32_t old_palette[AVPALETTE_COUNT];
+uint32_t global_palette[AVPALETTE_COUNT];
  int64_t pal_offset;
  } AVIStream;

@@ -711,9 +712,15 @@ static int avi_write_packet(AVFormatContext *s, AVPacket 
*pkt)
  }
  avio_seek(pb, cur_offset, SEEK_SET);
  memcpy(avist->old_palette, avist->palette, pal_size * 4);
+memcpy(avist->global_palette, avist->palette, pal_size * 
4);
  avist->pal_offset = 0;
  }
-if (memcmp(avist->palette, avist->old_palette, pal_size * 4)) {
+if (memcmp(avist->palette, avist->old_palette, pal_size * 4) ||
+(memcmp(avist->palette, avist->global_palette, pal_size * 
4) ||
+ avist->strh_flags_offset == 0 ||
+ !pb->seekable
+) && (pkt->flags & AV_PKT_FLAG_KEY)
+) {
  avi_stream2fourcc(tag, stream_index, enc->codec_type);
  tag[2] = 'p'; tag[3] = 'c';
  pc_tag = ff_start_tag(pb, tag);





Doesn't seem to work quite as expected, Michael.
Try ffmpeg -i toon.avi -vcodec copy out.avi.
The destination file will still contain only two xxpc chunks.

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v5 1/4 v7] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/05/2016 06:14 PM, Michael Niedermayer wrote:

On Sat, Mar 05, 2016 at 05:54:05PM +0100, Reimar Döffinger wrote:

On Sat, Mar 05, 2016 at 02:32:56PM +0100, Mats Peterson wrote:

On 03/05/2016 02:24 PM, Mats Peterson wrote:


The original toon.avi doesn't contain xxpc chunks at keyframes either,
if that can be of any comfort. It only contains two xxpc chunks, at
that. If you're able to invent something nice regarding palette changes
on keyframes, please go ahead. But please add what's available in the
meantime.

Mats



In my book it should be up to the demuxer/decoder to keep track of previous
palettes. You said yourself that no xxpc chunks should be included if they
are identical to the first palette.


Define "previous".
What you suggests means that for a 1 GB video, if you want to see the
only the last frame the demuxer would _always_ have to parse the whole 1GB
just to make sure it has the last palette.
Thus the desire to always have a complete palette included for
"keyframes", which exist exactly so you can start playing
without parsing the whole file first.
Obviously patches don't have to solve every problem from the start,
but then again half the time to revise them faster than anyone can check
them...



Btw. sorry, maybe Michael manages, but I at least won't be able to
even read, much less properly follow all your emails if you
write that many.


same problem here
ive applied the latest now, as i think its less work to build on top
of that and fix what remains ...




That's my idea. Thanks, Michael.

Mats

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

Re: [FFmpeg-devel] [PATCH v5 1/4 v7] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/05/2016 05:54 PM, Reimar Döffinger wrote:

On Sat, Mar 05, 2016 at 02:32:56PM +0100, Mats Peterson wrote:

On 03/05/2016 02:24 PM, Mats Peterson wrote:


The original toon.avi doesn't contain xxpc chunks at keyframes either,
if that can be of any comfort. It only contains two xxpc chunks, at
that. If you're able to invent something nice regarding palette changes
on keyframes, please go ahead. But please add what's available in the
meantime.

Mats



In my book it should be up to the demuxer/decoder to keep track of previous
palettes. You said yourself that no xxpc chunks should be included if they
are identical to the first palette.


Define "previous".
What you suggests means that for a 1 GB video, if you want to see the
only the last frame the demuxer would _always_ have to parse the whole 1GB
just to make sure it has the last palette.
Thus the desire to always have a complete palette included for
"keyframes", which exist exactly so you can start playing
without parsing the whole file first.
Obviously patches don't have to solve every problem from the start,
but then again half the time to revise them faster than anyone can check
them...
Btw. sorry, maybe Michael manages, but I at least won't be able to
even read, much less properly follow all your emails if you
write that many.
So either you have to slow down or wait a bit longer for us
to manage to (find the right version of) and apply patches...

Regards,
Reimar
___


Well, Reimar, I do agree on this after all. That statement about letting 
the demuxer handle it was rather incorrect. A fit of bad patience, if 
you will. But the fact is that the original toon.avi file there only 
contains two xxpc chunks, so it hardly follows the "xxpc chunk on 
keyframe" rule.


Mats

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

[FFmpeg-devel] [PATCH v2] avfilter/vf_bwdif: add x86 SIMD

[Thomas Mundt]

This new patch adds x86 SIMD support up to 12 bit.
Please comment.

Signed-off-by: Thomas Mundt 
---
 libavfilter/bwdif.h |  72 +++
 libavfilter/vf_bwdif.c  |  69 +++
 libavfilter/x86/Makefile|   2 +
 libavfilter/x86/vf_bwdif.asm| 266 
 libavfilter/x86/vf_bwdif_init.c |  78 
 5 files changed, 432 insertions(+), 55 deletions(-)
 create mode 100644 libavfilter/bwdif.h
 create mode 100644 libavfilter/x86/vf_bwdif.asm
 create mode 100644 libavfilter/x86/vf_bwdif_init.c

diff --git a/libavfilter/bwdif.h b/libavfilter/bwdif.h
new file mode 100644
index 000..8b42c76
--- /dev/null
+++ b/libavfilter/bwdif.h
@@ -0,0 +1,72 @@
+/*
+ * 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
+ */
+
+#ifndef AVFILTER_BWDIF_H
+#define AVFILTER_BWDIF_H
+
+#include "libavutil/pixdesc.h"
+#include "avfilter.h"
+
+enum BWDIFMode {
+BWDIF_MODE_SEND_FRAME = 0, ///< send 1 frame for each frame
+BWDIF_MODE_SEND_FIELD = 1, ///< send 1 frame for each field
+};
+
+enum BWDIFParity {
+BWDIF_PARITY_TFF  =  0, ///< top field first
+BWDIF_PARITY_BFF  =  1, ///< bottom field first
+BWDIF_PARITY_AUTO = -1, ///< auto detection
+};
+
+enum BWDIFDeint {
+BWDIF_DEINT_ALL= 0, ///< deinterlace all frames
+BWDIF_DEINT_INTERLACED = 1, ///< only deinterlace frames marked as 
interlaced
+};
+
+typedef struct BWDIFContext {
+const AVClass *class;
+
+int mode;   ///< BWDIFMode
+int parity; ///< BWDIFParity
+int deint;  ///< BWDIFDeint
+
+int frame_pending;
+
+AVFrame *cur;
+AVFrame *next;
+AVFrame *prev;
+AVFrame *out;
+
+void (*filter_intra)(void *dst1, void *cur1, int w, int prefs, int mrefs,
+ int prefs3, int mrefs3, int parity, int clip_max);
+void (*filter_line)(void *dst, void *prev, void *cur, void *next,
+int w, int prefs, int mrefs, int prefs2, int mrefs2,
+int prefs3, int mrefs3, int prefs4, int mrefs4,
+int parity, int clip_max);
+void (*filter_edge)(void *dst, void *prev, void *cur, void *next,
+int w, int prefs, int mrefs, int prefs2, int mrefs2,
+int parity, int clip_max, int spat);
+
+const AVPixFmtDescriptor *csp;
+int inter_field;
+int eof;
+} BWDIFContext;
+
+void ff_bwdif_init_x86(BWDIFContext *bwdif);
+
+#endif /* AVFILTER_BWDIF_H */
diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
index 7985054..d402aa4 100644
--- a/libavfilter/vf_bwdif.c
+++ b/libavfilter/vf_bwdif.c
@@ -37,6 +37,7 @@
 #include "formats.h"
 #include "internal.h"
 #include "video.h"
+#include "bwdif.h"
 
 /*
  * Filter coefficients coef_lf and coef_hf taken from BBC PH-2071 (Weston 3 
Field Deinterlacer).
@@ -48,51 +49,6 @@ static const uint16_t coef_lf[2] = { 4309, 213 };
 static const uint16_t coef_hf[3] = { 5570, 3801, 1016 };
 static const uint16_t coef_sp[2] = { 5077, 981 };
 
-enum BWDIFMode {
-BWDIF_MODE_SEND_FRAME = 0, ///< send 1 frame for each frame
-BWDIF_MODE_SEND_FIELD = 1, ///< send 1 frame for each field
-};
-
-enum BWDIFParity {
-BWDIF_PARITY_TFF  =  0, ///< top field first
-BWDIF_PARITY_BFF  =  1, ///< bottom field first
-BWDIF_PARITY_AUTO = -1, ///< auto detection
-};
-
-enum BWDIFDeint {
-BWDIF_DEINT_ALL= 0, ///< deinterlace all frames
-BWDIF_DEINT_INTERLACED = 1, ///< only deinterlace frames marked as 
interlaced
-};
-
-typedef struct BWDIFContext {
-const AVClass *class;
-
-int mode;   ///< BWDIFMode
-int parity; ///< BWDIFParity
-int deint;  ///< BWDIFDeint
-
-int frame_pending;
-
-AVFrame *cur;
-AVFrame *next;
-AVFrame *prev;
-AVFrame *out;
-
-void (*filter_intra)(void *dst1, void *cur1, int w, int prefs, int mrefs,
- int prefs3, int mrefs3, int parity, int clip_max);
-void (*filter_line)(void *dst, void *prev, void *cur, void *next,
-int w, int prefs, int mrefs, int prefs2, int mrefs2,
-int prefs3, int mrefs3, int prefs4, int mrefs4,
-int parity, int 

Re: [FFmpeg-devel] [PATCH]lavf/img2dec: xbm autodetection

[Michael Niedermayer]

On Sat, Mar 05, 2016 at 07:29:01PM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Not sure how useful this patch is.
> 
> Please comment, Carl Eugen

>  Makefile |1 +
>  allformats.c |1 +
>  img2dec.c|8 
>  3 files changed, 10 insertions(+)
> 0debba60a1363edb619fa5ec358815b92ac480e8  patchxbm.diff
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index dc931d9..8981e08 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -227,6 +227,7 @@ OBJS-$(CONFIG_IMAGE_SGI_PIPE_DEMUXER) += img2dec.o 
> img2.o
>  OBJS-$(CONFIG_IMAGE_SUNRAST_PIPE_DEMUXER) += img2dec.o img2.o
>  OBJS-$(CONFIG_IMAGE_TIFF_PIPE_DEMUXER)+= img2dec.o img2.o
>  OBJS-$(CONFIG_IMAGE_WEBP_PIPE_DEMUXER)+= img2dec.o img2.o
> +OBJS-$(CONFIG_IMAGE_XBM_PIPE_DEMUXER) += img2dec.o img2.o
>  OBJS-$(CONFIG_INGENIENT_DEMUXER) += ingenientdec.o rawdec.o
>  OBJS-$(CONFIG_IPMOVIE_DEMUXER)   += ipmovie.o
>  OBJS-$(CONFIG_IRCAM_DEMUXER) += ircamdec.o ircam.o pcm.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 94f258d..0f992d8 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -359,6 +359,7 @@ void av_register_all(void)
>  REGISTER_DEMUXER (IMAGE_SUNRAST_PIPE,image_sunrast_pipe);
>  REGISTER_DEMUXER (IMAGE_TIFF_PIPE,   image_tiff_pipe);
>  REGISTER_DEMUXER (IMAGE_WEBP_PIPE,   image_webp_pipe);
> +REGISTER_DEMUXER (IMAGE_XBM_PIPE,image_xbm_pipe);
>  
>  /* external libraries */
>  REGISTER_MUXER   (CHROMAPRINT,  chromaprint);
> diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> index 019793f..24e8940 100644
> --- a/libavformat/img2dec.c
> +++ b/libavformat/img2dec.c
> @@ -860,6 +860,13 @@ static int webp_probe(AVProbeData *p)
>  return 0;
>  }
>  
> +static int xbm_probe(AVProbeData *p)
> +{
> +if (memcmp(p->buf, "#define image_width ", 20))
> +return 0;
> +return AVPROBE_SCORE_MAX - 1;
> +}

are whitespaces always that way and is that alwas the first line ?
if so then the patch LGTM

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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

[FFmpeg-devel] [PATCH] avformat/avienc: store palette at keyframes if it differs from the global one

[Michael Niedermayer]

---
 libavformat/avienc.c |9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index 0cfffb7..8804ece 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -84,6 +84,7 @@ typedef struct AVIStream {
 
 uint32_t palette[AVPALETTE_COUNT];
 uint32_t old_palette[AVPALETTE_COUNT];
+uint32_t global_palette[AVPALETTE_COUNT];
 int64_t pal_offset;
 } AVIStream;
 
@@ -711,9 +712,15 @@ static int avi_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 }
 avio_seek(pb, cur_offset, SEEK_SET);
 memcpy(avist->old_palette, avist->palette, pal_size * 4);
+memcpy(avist->global_palette, avist->palette, pal_size * 
4);
 avist->pal_offset = 0;
 }
-if (memcmp(avist->palette, avist->old_palette, pal_size * 4)) {
+if (memcmp(avist->palette, avist->old_palette, pal_size * 4) ||
+(memcmp(avist->palette, avist->global_palette, pal_size * 
4) ||
+ avist->strh_flags_offset == 0 ||
+ !pb->seekable
+) && (pkt->flags & AV_PKT_FLAG_KEY)
+) {
 avi_stream2fourcc(tag, stream_index, enc->codec_type);
 tag[2] = 'p'; tag[3] = 'c';
 pc_tag = ff_start_tag(pb, tag);
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH]lavf/img2dec: Use jpeg constants in jpeg_probe()

[Michael Niedermayer]

On Sat, Mar 05, 2016 at 07:26:36PM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> I believe attached patch makes the jpeg probe function more readable.
> 
> Please comment, Carl Eugen

>  img2dec.c |   73 
> +++---
>  1 file changed, 37 insertions(+), 36 deletions(-)
> 82bb95da87139860c2e09731e375420e2733392e  patchjpegconstants.diff
> diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH] avcodec: try to document timebase and framerate a bit more

[Reimar Döffinger]

On Sat, Mar 05, 2016 at 06:56:30PM +0100, Michael Niedermayer wrote:
> On Sat, Mar 05, 2016 at 06:01:11PM +0100, Reimar Döffinger wrote:
> > On Sat, Mar 05, 2016 at 01:41:32PM +0100, Michael Niedermayer wrote:
> > > + * Note, for variable framerate material this has undefined meaning 
> > > currently
> > > + * and is not set to the actual framerate nor {0,1} but can be set to
> > > + * 1/timebase (FIXME) the code in some parts assumes framerate == 
> > > 1/timebase
> > > + * which is generally not true but these parts need to be fixed 
> > > before framerate
> > > + * can be fixed.
> > 
> > This is too complex, maybe it can be split in multiple sentences.
> > Suggestion (but I took a lot of liberty and it might not say what you
> > meant!):
> > 
> > Note: meaning is not yet defined for variable frame rate content.
> > Ideally it should be set to either the current frame rate or {0,1}
> > for that case.
> > However for this some code assuming framerate == 1/timebase needs to
> > be fixed first - until then this field may incorrectly be set
> > to 1/timebase.
> 
> there are 2 cases
> 1. encoding where the users sets it
> 2. deoding where lavc sets it
> 
> my comment was about decoding "issues"/"bugs"

I understood that, but I admit my description did not capture that,
so maybe clearer with adding "when decoding" and "libavcodec sets"

> > Note: when decoding meaning is not yet defined for variable frame
> > rate content.
> > Ideally libavcodec should set it to either the current frame rate or {0,1}
> > for that case.
> > However for this some code assuming framerate == 1/timebase needs to
> > be fixed first - until then libavcodec may incorrectly set this field
> > to 1/timebase.

But as said it's just a suggestion. Even your original one is better
than nothing. I just thought it quite tough to read.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [libav-devel] [PATCH] avcodec/cfhd: Fixes cfhd_odd.mov which has a resolution of 496x241

[Vittorio Giovara]

On Sat, Mar 5, 2016 at 1:06 PM, Kieran Kunhya  wrote:
> In this case container width/height is better however.
> Thanks to koda for the sample
> ---
>  libavcodec/cfhd.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
> index e37bef0..98f16d3 100644
> --- a/libavcodec/cfhd.c
> +++ b/libavcodec/cfhd.c
> @@ -467,6 +467,9 @@ static int cfhd_decode(AVCodecContext *avctx, void *data, 
> int *got_frame,
>  coeff_data += lowpass_width;
>  }
>
> +/* Align to mod-4 position to continue reading tags */
> +bytestream2_seek(, bytestream2_tell() & 3, SEEK_CUR);
> +
>  /* Copy last line of coefficients if odd height */
>  if (lowpass_height & 1) {
>  memcpy(_data[lowpass_height * lowpass_width],
> --

Confirmed to work with the sample. Here is an addendum to avoid
displaying garbage (untested with other samples)

commit 658fdd157f12633006533bc67ffb3b0d44a198df
Author: Vittorio Giovara 
Date:   Sat Mar 5 13:32:54 2016 -0500

cfhd: Crop visible height

diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index e37bef0..4d2e933 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -420,6 +420,8 @@ static int cfhd_decode(AVCodecContext *avctx, void
*data, int *got_frame,
 break;
 }
 planes = av_pix_fmt_count_planes(s->coded_format);
+} else if (tag == -85) {
+avctx->height = data;
 } else
 av_log(avctx, AV_LOG_DEBUG,  "Unknown tag %i data %x\n",
tag, data);


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

[FFmpeg-devel] [PATCH]lavf/img2dec: xbm autodetection

[Carl Eugen Hoyos]

Hi!

Not sure how useful this patch is.

Please comment, Carl Eugen
diff --git a/libavformat/Makefile b/libavformat/Makefile
index dc931d9..8981e08 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -227,6 +227,7 @@ OBJS-$(CONFIG_IMAGE_SGI_PIPE_DEMUXER) += img2dec.o img2.o
 OBJS-$(CONFIG_IMAGE_SUNRAST_PIPE_DEMUXER) += img2dec.o img2.o
 OBJS-$(CONFIG_IMAGE_TIFF_PIPE_DEMUXER)+= img2dec.o img2.o
 OBJS-$(CONFIG_IMAGE_WEBP_PIPE_DEMUXER)+= img2dec.o img2.o
+OBJS-$(CONFIG_IMAGE_XBM_PIPE_DEMUXER) += img2dec.o img2.o
 OBJS-$(CONFIG_INGENIENT_DEMUXER) += ingenientdec.o rawdec.o
 OBJS-$(CONFIG_IPMOVIE_DEMUXER)   += ipmovie.o
 OBJS-$(CONFIG_IRCAM_DEMUXER) += ircamdec.o ircam.o pcm.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 94f258d..0f992d8 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -359,6 +359,7 @@ void av_register_all(void)
 REGISTER_DEMUXER (IMAGE_SUNRAST_PIPE,image_sunrast_pipe);
 REGISTER_DEMUXER (IMAGE_TIFF_PIPE,   image_tiff_pipe);
 REGISTER_DEMUXER (IMAGE_WEBP_PIPE,   image_webp_pipe);
+REGISTER_DEMUXER (IMAGE_XBM_PIPE,image_xbm_pipe);
 
 /* external libraries */
 REGISTER_MUXER   (CHROMAPRINT,  chromaprint);
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index 019793f..24e8940 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -860,6 +860,13 @@ static int webp_probe(AVProbeData *p)
 return 0;
 }
 
+static int xbm_probe(AVProbeData *p)
+{
+if (memcmp(p->buf, "#define image_width ", 20))
+return 0;
+return AVPROBE_SCORE_MAX - 1;
+}
+
 #define IMAGEAUTO_DEMUXER(imgname, codecid)\
 static const AVClass imgname ## _class = {\
 .class_name = AV_STRINGIFY(imgname) " demuxer",\
@@ -894,3 +901,4 @@ IMAGEAUTO_DEMUXER(sgi, AV_CODEC_ID_SGI)
 IMAGEAUTO_DEMUXER(sunrast, AV_CODEC_ID_SUNRAST)
 IMAGEAUTO_DEMUXER(tiff,AV_CODEC_ID_TIFF)
 IMAGEAUTO_DEMUXER(webp,AV_CODEC_ID_WEBP)
+IMAGEAUTO_DEMUXER(xbm, AV_CODEC_ID_XBM)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavf/img2dec: Use jpeg constants in jpeg_probe()

[Carl Eugen Hoyos]

Hi!

I believe attached patch makes the jpeg probe function more readable.

Please comment, Carl Eugendiff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index 019793f..fe0e346 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -33,6 +33,7 @@
 #include "avio_internal.h"
 #include "internal.h"
 #include "img2.h"
+#include "libavcodec/mjpeg.h"
 
 #if HAVE_GLOB
 /* Locally define as 0 (bitwise-OR no-op) any missing glob options that
@@ -687,7 +688,7 @@ static int j2k_probe(AVProbeData *p)
 static int jpeg_probe(AVProbeData *p)
 {
 const uint8_t *b = p->buf;
-int i, state = 0xD8;
+int i, state = SOI;
 
 if (AV_RB16(b) != 0xFFD8 ||
 AV_RB32(b) == 0xFFD8FFF7)
@@ -700,57 +701,57 @@ static int jpeg_probe(AVProbeData *p)
 continue;
 c = b[i + 1];
 switch (c) {
-case 0xD8:
+case SOI:
 return 0;
-case 0xC0:
-case 0xC1:
-case 0xC2:
-case 0xC3:
-case 0xC5:
-case 0xC6:
-case 0xC7:
+case SOF0:
+case SOF1:
+case SOF2:
+case SOF3:
+case SOF5:
+case SOF6:
+case SOF7:
 i += AV_RB16([i + 2]) + 1;
-if (state != 0xD8)
+if (state != SOI)
 return 0;
-state = 0xC0;
+state = SOF0;
 break;
-case 0xDA:
+case SOS:
 i += AV_RB16([i + 2]) + 1;
-if (state != 0xC0 && state != 0xDA)
+if (state != SOF0 && state != SOS)
 return 0;
-state = 0xDA;
+state = SOS;
 break;
-case 0xD9:
-if (state != 0xDA)
+case EOI:
+if (state != SOS)
 return 0;
-state = 0xD9;
+state = EOI;
 break;
-case 0xE0:
-case 0xE1:
-case 0xE2:
-case 0xE3:
-case 0xE4:
-case 0xE5:
-case 0xE6:
-case 0xE7:
-case 0xE8:
-case 0xE9:
-case 0xEA:
-case 0xEB:
-case 0xEC:
-case 0xED:
-case 0xEE:
-case 0xEF:
+case APP0:
+case APP1:
+case APP2:
+case APP3:
+case APP4:
+case APP5:
+case APP6:
+case APP7:
+case APP8:
+case APP9:
+case APP10:
+case APP11:
+case APP12:
+case APP13:
+case APP14:
+case APP15:
 i += AV_RB16([i + 2]) + 1;
 break;
 default:
-if (  (c >= 0x02 && c <= 0xBF)
-|| c == 0xC8)
+if (  (c > TEM && c < SOF0)
+|| c == JPG)
 return 0;
 }
 }
 
-if (state == 0xD9)
+if (state == EOI)
 return AVPROBE_SCORE_EXTENSION + 1;
 return AVPROBE_SCORE_EXTENSION / 8;
 }
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavfi/extractplanes: Fix in_pixfmts

[Carl Eugen Hoyos]

Hi!

I see the following issue here with extractplanes:
If the input file has a 16bit little endian pix_fmt not supported by 
extractplanes (gbra12le), the filter system has to choose a compatible 
pix_fmt supported by the filter and chooses rgba64be here.
The extractplanes filter returns gray16le as output pix_fmt because the 
original pix_fmt was le but produces visually broken output because the 
actual filter input is be.
Attached patch works around this issue by always providing compatible 
input and output formats.

I am happy if this can be fixed differently.

Please comment, Carl Eugendiff --git a/libavfilter/vf_extractplanes.c b/libavfilter/vf_extractplanes.c
index 099c00f..3203057 100644
--- a/libavfilter/vf_extractplanes.c
+++ b/libavfilter/vf_extractplanes.c
@@ -62,7 +62,7 @@ AVFILTER_DEFINE_CLASS(extractplanes);
 
 static int query_formats(AVFilterContext *ctx)
 {
-static const enum AVPixelFormat in_pixfmts[] = {
+static const enum AVPixelFormat in_pixfmts_le[] = {
 AV_PIX_FMT_YUV410P,
 AV_PIX_FMT_YUV411P,
 AV_PIX_FMT_YUV440P,
@@ -73,30 +73,47 @@ static int query_formats(AVFilterContext *ctx)
 AV_PIX_FMT_YUVJ411P,
 AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUVA444P,
 AV_PIX_FMT_YUV420P16LE, AV_PIX_FMT_YUVA420P16LE,
-AV_PIX_FMT_YUV420P16BE, AV_PIX_FMT_YUVA420P16BE,
 AV_PIX_FMT_YUV422P16LE, AV_PIX_FMT_YUVA422P16LE,
-AV_PIX_FMT_YUV422P16BE, AV_PIX_FMT_YUVA422P16BE,
 AV_PIX_FMT_YUV444P16LE, AV_PIX_FMT_YUVA444P16LE,
-AV_PIX_FMT_YUV444P16BE, AV_PIX_FMT_YUVA444P16BE,
 AV_PIX_FMT_GRAY8, AV_PIX_FMT_GRAY8A,
-AV_PIX_FMT_YA16LE, AV_PIX_FMT_YA16BE,
-AV_PIX_FMT_GRAY16LE, AV_PIX_FMT_GRAY16BE,
+AV_PIX_FMT_YA16LE, AV_PIX_FMT_GRAY16LE,
 AV_PIX_FMT_RGB24, AV_PIX_FMT_BGR24,
 AV_PIX_FMT_RGBA, AV_PIX_FMT_BGRA,
 AV_PIX_FMT_ARGB, AV_PIX_FMT_ABGR,
 AV_PIX_FMT_RGB48LE, AV_PIX_FMT_BGR48LE,
-AV_PIX_FMT_RGB48BE, AV_PIX_FMT_BGR48BE,
 AV_PIX_FMT_RGBA64LE, AV_PIX_FMT_BGRA64LE,
+AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRAP,
+AV_PIX_FMT_GBRP16LE, AV_PIX_FMT_GBRAP16LE,
+AV_PIX_FMT_NONE,
+};
+static const enum AVPixelFormat in_pixfmts_be[] = {
+AV_PIX_FMT_YUV410P,
+AV_PIX_FMT_YUV411P,
+AV_PIX_FMT_YUV440P,
+AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUVA420P,
+AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUVA422P,
+AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P,
+AV_PIX_FMT_YUVJ440P, AV_PIX_FMT_YUVJ444P,
+AV_PIX_FMT_YUVJ411P,
+AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUVA444P,
+AV_PIX_FMT_YUV420P16BE, AV_PIX_FMT_YUVA420P16BE,
+AV_PIX_FMT_YUV422P16BE, AV_PIX_FMT_YUVA422P16BE,
+AV_PIX_FMT_YUV444P16BE, AV_PIX_FMT_YUVA444P16BE,
+AV_PIX_FMT_GRAY8, AV_PIX_FMT_GRAY8A,
+AV_PIX_FMT_YA16BE, AV_PIX_FMT_GRAY16BE,
+AV_PIX_FMT_RGB24, AV_PIX_FMT_BGR24,
+AV_PIX_FMT_RGBA, AV_PIX_FMT_BGRA,
+AV_PIX_FMT_ARGB, AV_PIX_FMT_ABGR,
+AV_PIX_FMT_RGB48BE, AV_PIX_FMT_BGR48BE,
 AV_PIX_FMT_RGBA64BE, AV_PIX_FMT_BGRA64BE,
 AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRAP,
-AV_PIX_FMT_GBRP16LE, AV_PIX_FMT_GBRP16BE,
-AV_PIX_FMT_GBRAP16LE, AV_PIX_FMT_GBRAP16BE,
+AV_PIX_FMT_GBRP16BE, AV_PIX_FMT_GBRAP16BE,
 AV_PIX_FMT_NONE,
 };
 static const enum AVPixelFormat out8_pixfmts[] = { AV_PIX_FMT_GRAY8, AV_PIX_FMT_NONE };
 static const enum AVPixelFormat out16le_pixfmts[] = { AV_PIX_FMT_GRAY16LE, AV_PIX_FMT_NONE };
 static const enum AVPixelFormat out16be_pixfmts[] = { AV_PIX_FMT_GRAY16BE, AV_PIX_FMT_NONE };
-const enum AVPixelFormat *out_pixfmts;
+const enum AVPixelFormat *out_pixfmts, *in_pixfmts;
 const AVPixFmtDescriptor *desc;
 AVFilterFormats *avff;
 int i, ret, depth = 0, be = 0;
@@ -106,14 +123,19 @@ static int query_formats(AVFilterContext *ctx)
 return AVERROR(EAGAIN);
 }
 
-if (!ctx->inputs[0]->out_formats)
-if ((ret = ff_formats_ref(ff_make_format_list(in_pixfmts), >inputs[0]->out_formats)) < 0)
-return ret;
-
 avff = ctx->inputs[0]->in_formats;
 desc = av_pix_fmt_desc_get(avff->formats[0]);
 depth = desc->comp[0].depth;
 be = desc->flags & AV_PIX_FMT_FLAG_BE;
+if (be) {
+in_pixfmts = in_pixfmts_be;
+} else {
+in_pixfmts = in_pixfmts_le;
+}
+if (!ctx->inputs[0]->out_formats)
+if ((ret = ff_formats_ref(ff_make_format_list(in_pixfmts), >inputs[0]->out_formats)) < 0)
+return ret;
+
 for (i = 1; i < avff->nb_formats; i++) {
 desc = av_pix_fmt_desc_get(avff->formats[i]);
 if (depth != desc->comp[0].depth ||
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/cfhd: Fixes cfhd_odd.mov which has a resolution of 496x241

[Kieran Kunhya]

In this case container width/height is better however.
Thanks to koda for the sample
---
 libavcodec/cfhd.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index e37bef0..98f16d3 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -467,6 +467,9 @@ static int cfhd_decode(AVCodecContext *avctx, void *data, 
int *got_frame,
 coeff_data += lowpass_width;
 }
 
+/* Align to mod-4 position to continue reading tags */
+bytestream2_seek(, bytestream2_tell() & 3, SEEK_CUR);
+
 /* Copy last line of coefficients if odd height */
 if (lowpass_height & 1) {
 memcpy(_data[lowpass_height * lowpass_width],
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH] avcodec: try to document timebase and framerate a bit more

[Michael Niedermayer]

On Sat, Mar 05, 2016 at 06:01:11PM +0100, Reimar Döffinger wrote:
> On Sat, Mar 05, 2016 at 01:41:32PM +0100, Michael Niedermayer wrote:
> > + * Note, for variable framerate material this has undefined meaning 
> > currently
> > + * and is not set to the actual framerate nor {0,1} but can be set to
> > + * 1/timebase (FIXME) the code in some parts assumes framerate == 
> > 1/timebase
> > + * which is generally not true but these parts need to be fixed before 
> > framerate
> > + * can be fixed.
> 
> This is too complex, maybe it can be split in multiple sentences.
> Suggestion (but I took a lot of liberty and it might not say what you
> meant!):
> 
> Note: meaning is not yet defined for variable frame rate content.
> Ideally it should be set to either the current frame rate or {0,1}
> for that case.
> However for this some code assuming framerate == 1/timebase needs to
> be fixed first - until then this field may incorrectly be set
> to 1/timebase.

there are 2 cases
1. encoding where the users sets it
2. deoding where lavc sets it

my comment was about decoding "issues"/"bugs"
i think user apps should always set it correctly when encoding
"git grep framerate libavcodec/*enc*c" looks like its basically unused
for encoders.

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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

[FFmpeg-devel] [PATCH] avformat/avienc: Remove unneeded seekable tests

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavformat/avienc.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index 0cfffb7..357dd34 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -306,8 +306,7 @@ static int avi_write_header(AVFormatContext *s)
 avio_wl32(pb, enc->codec_tag);
 else
 avio_wl32(pb, 1);
-if (enc->codec_type == AVMEDIA_TYPE_VIDEO && pb->seekable)
-avist->strh_flags_offset = avio_tell(pb);
+avist->strh_flags_offset = avio_tell(pb);
 avio_wl32(pb, 0); /* flags */
 avio_wl16(pb, 0); /* priority */
 avio_wl16(pb, 0); /* language */
@@ -369,8 +368,7 @@ static int avi_write_header(AVFormatContext *s)
 && enc->pix_fmt == AV_PIX_FMT_RGB555LE
 && enc->bits_per_coded_sample == 15)
 enc->bits_per_coded_sample = 16;
-if (pb->seekable)
-avist->pal_offset = avio_tell(pb) + 40;
+avist->pal_offset = avio_tell(pb) + 40;
 ff_put_bmp_header(pb, enc, ff_codec_bmp_tags, 0, 0);
 pix_fmt = avpriv_find_pix_fmt(avpriv_pix_fmt_bps_avi,
   enc->bits_per_coded_sample);
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH v5 3/4] lavf/riffenc: Handle palette for non-raw codecs

[Michael Niedermayer]

On Thu, Mar 03, 2016 at 12:35:36AM +0100, Mats Peterson wrote:
> 
> -- 
> Mats Peterson
> http://matsp888.no-ip.org/~mats/

>  riffenc.c |   20 +++-
>  1 file changed, 11 insertions(+), 9 deletions(-)
> 70ca679c14ab31934806895eea5f10f633aeb778  
> 0003-lavf-riffenc-Handle-palette-for-non-raw-codecs.patch
> From 602db1c464b7a432b4f4b471cbeed401cd220e4c Mon Sep 17 00:00:00 2001
> From: Mats Peterson 
> Date: Thu, 3 Mar 2016 00:28:23 +0100
> Subject: [PATCH v5 3/4] lavf/riffenc: Handle palette for non-raw codecs

applied (the variant i got privatly as it was frm a later date)

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


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

Re: [FFmpeg-devel] [PATCH v5 1/4 v7] lavf/avienc: Add support for palette side data

[Michael Niedermayer]

On Sat, Mar 05, 2016 at 12:21:14PM +0100, Mats Peterson wrote:
> I've noticed that avienc.c is close to useless for use with stdout.
> It only checks pb->seekable in a few places, and for example the
> ff_end_tag() function uses avio_seek(), but that one is used in
> several places where there is no check for a seekable stream.
> 
> Anyway, this version adds the AVISF_VIDEO_PALCHANGES flag properly
> to the 'strh' chunk, per the Microsoft documentation.
> 
> Mats
> 
> -- 
> Mats Peterson
> http://matsp888.no-ip.org/~mats/

>  avienc.c |   91 
> ++-
>  1 file changed, 62 insertions(+), 29 deletions(-)
> f6d7eec2a9d7be9cbb0326cd68bc6303217ac8ed  
> 0001-lavf-avienc-Add-support-for-palette-side-data.patch
> From cc97d81425598317014a8e744dd2c8a2062c4496 Mon Sep 17 00:00:00 2001
> From: Mats Peterson 
> Date: Sat, 5 Mar 2016 12:16:57 +0100
> Subject: [PATCH v5 1/4 v7] lavf/avienc: Add support for palette side data
> 
> ---
>  libavformat/avienc.c |   91 
> ++
>  1 file changed, 62 insertions(+), 29 deletions(-)

applied (more exactly the one you sent privately but i think they
where the same)

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


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

[FFmpeg-devel] [PATCH] avformat/dump: Fix context/level for payload dump

[Mark Harris]

Use the context and level specified to av_pkt_dump_log2(),
instead of panic level (0), for dumping packet payload.
---
 libavformat/dump.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/dump.c b/libavformat/dump.c
index 9e7c12b..86bb82d 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -101,7 +101,7 @@ static void pkt_dump_internal(void *avcl, FILE *f, int 
level, const AVPacket *pk
 HEXDUMP_PRINT("\n");
 HEXDUMP_PRINT("  size=%d\n", pkt->size);
 if (dump_payload)
-av_hex_dump(f, pkt->data, pkt->size);
+hex_dump_internal(avcl, f, level, pkt->data, pkt->size);
 }
 
 void av_pkt_dump2(FILE *f, const AVPacket *pkt, int dump_payload, const 
AVStream *st)
-- 
2.7.2

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

Re: [FFmpeg-devel] [PATCH] avcodec: try to document timebase and framerate a bit more

[Reimar Döffinger]

On Sat, Mar 05, 2016 at 01:41:32PM +0100, Michael Niedermayer wrote:
> + * Note, for variable framerate material this has undefined meaning 
> currently
> + * and is not set to the actual framerate nor {0,1} but can be set to
> + * 1/timebase (FIXME) the code in some parts assumes framerate == 
> 1/timebase
> + * which is generally not true but these parts need to be fixed before 
> framerate
> + * can be fixed.

This is too complex, maybe it can be split in multiple sentences.
Suggestion (but I took a lot of liberty and it might not say what you
meant!):

Note: meaning is not yet defined for variable frame rate content.
Ideally it should be set to either the current frame rate or {0,1}
for that case.
However for this some code assuming framerate == 1/timebase needs to
be fixed first - until then this field may incorrectly be set
to 1/timebase.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v5 1/4 v7] lavf/avienc: Add support for palette side data

[Reimar Döffinger]

On Sat, Mar 05, 2016 at 02:32:56PM +0100, Mats Peterson wrote:
> On 03/05/2016 02:24 PM, Mats Peterson wrote:
> >
> >The original toon.avi doesn't contain xxpc chunks at keyframes either,
> >if that can be of any comfort. It only contains two xxpc chunks, at
> >that. If you're able to invent something nice regarding palette changes
> >on keyframes, please go ahead. But please add what's available in the
> >meantime.
> >
> >Mats
> >
> 
> In my book it should be up to the demuxer/decoder to keep track of previous
> palettes. You said yourself that no xxpc chunks should be included if they
> are identical to the first palette.

Define "previous".
What you suggests means that for a 1 GB video, if you want to see the
only the last frame the demuxer would _always_ have to parse the whole 1GB
just to make sure it has the last palette.
Thus the desire to always have a complete palette included for
"keyframes", which exist exactly so you can start playing
without parsing the whole file first.
Obviously patches don't have to solve every problem from the start,
but then again half the time to revise them faster than anyone can check
them...
Btw. sorry, maybe Michael manages, but I at least won't be able to
even read, much less properly follow all your emails if you
write that many.
So either you have to slow down or wait a bit longer for us
to manage to (find the right version of) and apply patches...

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

Re: [FFmpeg-devel] [PATCH v5 1/4 v7] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/05/2016 02:24 PM, Mats Peterson wrote:

On 03/05/2016 12:21 PM, Mats Peterson wrote:

I've noticed that avienc.c is close to useless for use with stdout. It
only checks pb->seekable in a few places, and for example the
ff_end_tag() function uses avio_seek(), but that one is used in several
places where there is no check for a seekable stream.

Anyway, this version adds the AVISF_VIDEO_PALCHANGES flag properly to
the 'strh' chunk, per the Microsoft documentation.

Mats





The original toon.avi doesn't contain xxpc chunks at keyframes either,
if that can be of any comfort. It only contains two xxpc chunks, at
that. If you're able to invent something nice regarding palette changes
on keyframes, please go ahead. But please add what's available in the
meantime.

Mats



In my book it should be up to the demuxer/decoder to keep track of 
previous palettes. You said yourself that no xxpc chunks should be 
included if they are identical to the first palette.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec: try to document timebase and framerate a bit more

[Michael Niedermayer]

Hi

see the 2 attached patches
ISP still has probems with git send email here

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
From a8b2a1a51c8f570f496d53e3295d5ebf330d9fcc Mon Sep 17 00:00:00 2001
From: Michael Niedermayer 
Date: Sat, 5 Mar 2016 13:29:16 +0100
Subject: [PATCH 1/2] avcodec: try to document timebase a bit more

Signed-off-by: Michael Niedermayer 
---
 libavcodec/avcodec.h |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 5dc4b73..981ceb7 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1669,7 +1669,15 @@ typedef struct AVCodecContext {
  * timebase should be 1/framerate and timestamp increments should be
  * identically 1.
  * This often, but not always is the inverse of the frame rate or field rate
- * for video.
+ * for video. 1/time_base is not the average frame rate if the frame rate is not
+ * constant.
+ *
+ * Like containers, elementary streams also can store timestamps, 1/time_base
+ * is the unit in which these timestamps are specified.
+ * As example of such codec time base see ISO/IEC 14496-2:2001(E)
+ * vop_time_increment_resolution and fixed_vop_rate
+ * (fixed_vop_rate == 0 implies that it is different from the framerate)
+ *
  * - encoding: MUST be set by user.
  * - decoding: the use of this field for decoding is deprecated.
  * Use framerate instead.
-- 
1.7.9.5

From 97f37e16d295546bb877f2948773fdee728c95fe Mon Sep 17 00:00:00 2001
From: Michael Niedermayer 
Date: Sat, 5 Mar 2016 13:37:44 +0100
Subject: [PATCH 2/2] avcodec/avcodec: try to document some issues with
 framerate

Signed-off-by: Michael Niedermayer 
---
 libavcodec/avcodec.h |7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 981ceb7..4973925 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3226,6 +3226,13 @@ typedef struct AVCodecContext {
 int initial_padding;
 
 /**
+ *
+ * Note, for variable framerate material this has undefined meaning currently
+ * and is not set to the actual framerate nor {0,1} but can be set to
+ * 1/timebase (FIXME) the code in some parts assumes framerate == 1/timebase
+ * which is generally not true but these parts need to be fixed before framerate
+ * can be fixed.
+ *
  * - decoding: For codecs that store a framerate value in the compressed
  * bitstream, the decoder may export it here. { 0, 1} when
  * unknown.
-- 
1.7.9.5



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

Re: [FFmpeg-devel] [PATCH v5 1/4 v7] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/05/2016 01:18 PM, Mats Peterson wrote:

On 03/05/2016 01:10 PM, Mats Peterson wrote:

On 03/05/2016 12:21 PM, Mats Peterson wrote:

I've noticed that avienc.c is close to useless for use with stdout. It
only checks pb->seekable in a few places, and for example the
ff_end_tag() function uses avio_seek(), but that one is used in several
places where there is no check for a seekable stream.

Anyway, this version adds the AVISF_VIDEO_PALCHANGES flag properly to
the 'strh' chunk, per the Microsoft documentation.

Mats




I understand what you mean with "non-keyframes", Michael. I currently do
not have any nice solution to offer, but perhaps you could add what I've
done so far anyway? It's at least better thant what was before, with no
support whatsoever for palette side data.

Mats



Is there a way to check if a packet is a "key frame packet" or whatever?

Mats



AV_PKT_FLAG_KEY. Thanks to myself.

Mats

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

Re: [FFmpeg-devel] [PATCH v5 1/4 v7] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/05/2016 01:10 PM, Mats Peterson wrote:

On 03/05/2016 12:21 PM, Mats Peterson wrote:

I've noticed that avienc.c is close to useless for use with stdout. It
only checks pb->seekable in a few places, and for example the
ff_end_tag() function uses avio_seek(), but that one is used in several
places where there is no check for a seekable stream.

Anyway, this version adds the AVISF_VIDEO_PALCHANGES flag properly to
the 'strh' chunk, per the Microsoft documentation.

Mats




I understand what you mean with "non-keyframes", Michael. I currently do
not have any nice solution to offer, but perhaps you could add what I've
done so far anyway? It's at least better thant what was before, with no
support whatsoever for palette side data.

Mats



Is there a way to check if a packet is a "key frame packet" or whatever?

Mats

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

Re: [FFmpeg-devel] [PATCH v5 1/4 v7] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/05/2016 12:21 PM, Mats Peterson wrote:

I've noticed that avienc.c is close to useless for use with stdout. It
only checks pb->seekable in a few places, and for example the
ff_end_tag() function uses avio_seek(), but that one is used in several
places where there is no check for a seekable stream.

Anyway, this version adds the AVISF_VIDEO_PALCHANGES flag properly to
the 'strh' chunk, per the Microsoft documentation.

Mats




I understand what you mean with "non-keyframes", Michael. I currently do 
not have any nice solution to offer, but perhaps you could add what I've 
done so far anyway? It's at least better thant what was before, with no 
support whatsoever for palette side data.


Mats

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

Re: [FFmpeg-devel] [PATCH v5 1/4 v7] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/05/2016 12:41 PM, Mats Peterson wrote:

On 03/05/2016 12:21 PM, Mats Peterson wrote:

I've noticed that avienc.c is close to useless for use with stdout. It
only checks pb->seekable in a few places, and for example the
ff_end_tag() function uses avio_seek(), but that one is used in several
places where there is no check for a seekable stream.




Interestingly enough, it works pretty well when using stdout. I must
have missed something regarding the meaning of pb->seekable...



It works thanks to the xxpc chunks, that is.

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v5 1/4 v7] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/05/2016 12:21 PM, Mats Peterson wrote:

I've noticed that avienc.c is close to useless for use with stdout. It
only checks pb->seekable in a few places, and for example the
ff_end_tag() function uses avio_seek(), but that one is used in several
places where there is no check for a seekable stream.




Interestingly enough, it works pretty well when using stdout. I must 
have missed something regarding the meaning of pb->seekable...


Mats

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

Re: [FFmpeg-devel] [PATCH v5 1/4 v7] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/05/2016 12:21 PM, Mats Peterson wrote:

I've noticed that avienc.c is close to useless for use with stdout. It
only checks pb->seekable in a few places, and for example the
ff_end_tag() function uses avio_seek(), but that one is used in several
places where there is no check for a seekable stream.

Anyway, this version adds the AVISF_VIDEO_PALCHANGES flag properly to
the 'strh' chunk, per the Microsoft documentation.

Mats




Once again, here's a good file with xxpc chunks that you can try. It is 
encoded with Microsoft Video 1 (CRAM).


https://samples.ffmpeg.org/avi/palette_change/toon.avi

Mats

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

[FFmpeg-devel] [PATCH v5 1/4 v7] lavf/avienc: Add support for palette side data

[Mats Peterson]

I've noticed that avienc.c is close to useless for use with stdout. It 
only checks pb->seekable in a few places, and for example the 
ff_end_tag() function uses avio_seek(), but that one is used in several 
places where there is no check for a seekable stream.


Anyway, this version adds the AVISF_VIDEO_PALCHANGES flag properly to 
the 'strh' chunk, per the Microsoft documentation.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From cc97d81425598317014a8e744dd2c8a2062c4496 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Sat, 5 Mar 2016 12:16:57 +0100
Subject: [PATCH v5 1/4 v7] lavf/avienc: Add support for palette side data

---
 libavformat/avienc.c |   91 ++
 1 file changed, 62 insertions(+), 29 deletions(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ca505f4..9bf755e 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -49,6 +49,8 @@ typedef struct AVIIentry {
 
 #define AVI_INDEX_CLUSTER_SIZE 16384
 
+#define AVISF_VIDEO_PALCHANGES 0x0001
+
 typedef struct AVIIndex {
 int64_t indx_start;
 int64_t audio_strm_offset;
@@ -74,12 +76,15 @@ typedef struct AVIStream {
 int max_size;
 int sample_requested;
 
-int64_t pal_offset;
-int hdr_pal_done;
-
 int64_t last_dts;
 
 AVIIndex indexes;
+
+int64_t strh_flags_offset;
+
+uint32_t palette[AVPALETTE_COUNT];
+uint32_t old_palette[AVPALETTE_COUNT];
+int64_t pal_offset;
 } AVIStream;
 
 static int avi_write_packet_internal(AVFormatContext *s, AVPacket *pkt);
@@ -301,6 +306,8 @@ static int avi_write_header(AVFormatContext *s)
 avio_wl32(pb, enc->codec_tag);
 else
 avio_wl32(pb, 1);
+if (enc->codec_type == AVMEDIA_TYPE_VIDEO && pb->seekable)
+avist->strh_flags_offset = avio_tell(pb);
 avio_wl32(pb, 0); /* flags */
 avio_wl16(pb, 0); /* priority */
 avio_wl16(pb, 0); /* language */
@@ -362,7 +369,8 @@ static int avi_write_header(AVFormatContext *s)
 && enc->pix_fmt == AV_PIX_FMT_RGB555LE
 && enc->bits_per_coded_sample == 15)
 enc->bits_per_coded_sample = 16;
-avist->pal_offset = avio_tell(pb) + 40;
+if (pb->seekable)
+avist->pal_offset = avio_tell(pb) + 40;
 ff_put_bmp_header(pb, enc, ff_codec_bmp_tags, 0, 0);
 pix_fmt = avpriv_find_pix_fmt(avpriv_pix_fmt_bps_avi,
   enc->bits_per_coded_sample);
@@ -652,11 +660,11 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 {
 unsigned char tag[5];
 const int stream_index = pkt->stream_index;
-const uint8_t *data= pkt->data;
-int size   = pkt->size;
 AVIOContext *pb = s->pb;
 AVCodecContext *enc = s->streams[stream_index]->codec;
 AVIStream *avist= s->streams[stream_index]->priv_data;
+AVPacket *opkt = pkt;
+enum AVPixelFormat pix_fmt = enc->pix_fmt;
 int ret;
 
 if (enc->codec_id == AV_CODEC_ID_H264 && enc->codec_tag == MKTAG('H','2','6','4') && pkt->size) {
@@ -668,39 +676,64 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 if ((ret = write_skip_frames(s, stream_index, pkt->dts)) < 0)
 return ret;
 
-if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) {
-int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16;
-int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
-
-ret = ff_reshuffle_raw_rgb(s, , enc, expected_stride);
-if (ret < 0)
-return ret;
-if (ret) {
-if (ret == CONTAINS_PAL) {
-int pc_tag, i;
+if (!pkt->size)
+return avi_write_packet_internal(s, pkt); /* Passthrough */
+
+if (enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) {
+int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16;
+int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
+ret = ff_reshuffle_raw_rgb(s, , enc, expected_stride);
+if (ret < 0)
+return ret;
+} else
+ret = 0;
+if (pix_fmt == AV_PIX_FMT_NONE && enc->bits_per_coded_sample == 1)
+pix_fmt = AV_PIX_FMT_MONOWHITE;
+if (pix_fmt == AV_PIX_FMT_PAL8 ||
+pix_fmt == AV_PIX_FMT_MONOWHITE ||
+pix_fmt == AV_PIX_FMT_MONOBLACK) {
+int ret2 = ff_get_packet_palette(s, opkt, ret, avist->palette);
+if (ret2 < 0)
+return ret2;
+if (ret2) {
 int pal_size = 1 << enc->bits_per_coded_sample;
-if (!avist->hdr_pal_done) {
+int pc_tag, i;
+if (pb->seekable && avist->pal_offset) {
  

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Hendrik Leppkes]

On Sat, Mar 5, 2016 at 11:26 AM, Carl Eugen Hoyos  wrote:
> Timothy Gu  gmail.com> writes:
>
>> The versioning scheme is supposed to make people's life easier.
>
> The patch would make my life more difficult .
>

If you can't even explain why, then I wouldn't expect many people to listen.
The latest proposal includes the exact same information as before,
plus one more piece of information.

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

Re: [FFmpeg-devel] [PATCH] Use matroska TrackNumber for populating AVStream::id

[Michael Niedermayer]

On Fri, Mar 04, 2016 at 04:19:18PM -0800, Sergey Volk wrote:
> Ok, something like this for now, then?

your original patch contained a nice commit message, this one
doesnt


> I'm new to ffmpeg development. When is the next version bump going to happen?

you can make changes at the next bump by using #if FF_API...
see libavfilter/version.h


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Carl Eugen Hoyos]

Timothy Gu  gmail.com> writes:

> The versioning scheme is supposed to make people's life easier.

The patch would make my life more difficult .

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH v5 1/4 v5] lavf/avienc: Add support for palette side data

[Michael Niedermayer]

On Sat, Mar 05, 2016 at 04:48:21AM +0100, Mats Peterson wrote:
> On 03/05/2016 04:43 AM, Mats Peterson wrote:
> >
> >
> >
> >___
> >ffmpeg-devel mailing list
> >ffmpeg-devel@ffmpeg.org
> >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> 
> This one only adds an xxpc chunk if it's not identical to the
> previosly used palette. Good enough?

for non keyframes yes

for keyframes, its trickier
keyframes can be reched either from the previous frame or via seeking
from anywhere else

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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

Re: [FFmpeg-devel] [PATCH v5 1/4 v6] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/05/2016 09:08 AM, Mats Peterson wrote:

On 03/05/2016 07:33 AM, Mats Peterson wrote:

Only copy/compare enough bytes for the bit depth in question.



Here's another good file with xxpc chunks that you can try. It is
encoded with Microsoft Video 1 (CRAM).

https://samples.ffmpeg.org/avi/palette_change/toon.avi

Mats



Hold your horses with this one. I have another version coming that sets 
the AVISF_VIDEO_PALCHANGES flag properly in the 'strh' chunk.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Regression maybe

[JULIAN GARDNER]

Ive now got the bisect down to the problem appearing between 75753 and 75759 
but when i build the versions inbetween i get avconv build and not ffmpeg
This is how the bisect went78890 BAD72615 GOOD75753 GOOD77321 BAD..75759 
BADAVCONV built
joolz

 Joolz 

On Friday, 4 March 2016, 0:17, Hendrik Leppkes  wrote:
 
 

 On Thu, Mar 3, 2016 at 11:23 PM, JULIAN GARDNER  wrote:
> But regressions are development problems, things like "how do i scale a 
> video" is for users.
> Im going tobe bisecting and fixing code if needed, so surely this is 
> development!
>  Joolz

Then open an issue on trac, thats what an issue tracker is for. Once
someone comes up with a potential fix, we can discuss it here.

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


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

Re: [FFmpeg-devel] [PATCH v5 1/4 v6] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/05/2016 07:33 AM, Mats Peterson wrote:

Only copy/compare enough bytes for the bit depth in question.



Here's another good file with xxpc chunks that you can try. It is 
encoded with Microsoft Video 1 (CRAM).


https://samples.ffmpeg.org/avi/palette_change/toon.avi

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel