On 02/09/2016 07:27 PM, Michael Niedermayer wrote:
Signed-off-by: Michael Niedermayer
---
libavcodec/raw.c|1 +
libavformat/nut.c |2 ++
tests/ref/fate/filter-pixfmts-copy |2 +-
tests/ref/fate/filter-pixfmts-crop |2 +-
tests/ref/fat
On 02/09/2016 08:23 PM, Mats Peterson wrote:
Wonderful, Michael.
Mats
But there is no provision for storing the proper palette yet, as far as
I can see. Correct me if I'm wrong.
Mats
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 02/09/2016 08:35 PM, Mats Peterson wrote:
On 02/09/2016 08:23 PM, Mats Peterson wrote:
Wonderful, Michael.
Mats
But there is no provision for storing the proper palette yet, as far as
I can see. Correct me if I'm wrong.
And as far as I know, neither writing AVI or QuickTime
On 02/09/2016 09:01 PM, Michael Niedermayer wrote:
On Tue, Feb 09, 2016 at 08:35:07PM +0100, Mats Peterson wrote:
On 02/09/2016 08:23 PM, Mats Peterson wrote:
Wonderful, Michael.
Mats
But there is no provision for storing the proper palette yet, as far
as I can see. Correct me if I'm
On 02/09/2016 09:03 PM, Mats Peterson wrote:
I'm currently compiling here, so I can't tell yet... Anyway, AVI stores
the palette in the output file, but only when using "-vcodec copy".
QuickTime doesn't store any palette whatsoever. Just a parenthesis.
Yes, Michael,
On 02/09/2016 09:06 PM, Mats Peterson wrote:
On 02/09/2016 09:03 PM, Mats Peterson wrote:
I'm currently compiling here, so I can't tell yet... Anyway, AVI stores
the palette in the output file, but only when using "-vcodec copy".
QuickTime doesn't store any p
On 02/09/2016 09:01 PM, Michael Niedermayer wrote:
ive tried both converting to pal8 nut from yuv420p as well as storing
rawvideo nut pal8 from a actual pal8 source, both worked
Yes, it works fine. My bad. It seems nut is storing the palette at the
end of the packet data rather than using a si
etter way is to use "ffmpeg -i 1bpp.avi -vcodec
copy -vtag B1W0 1bpp.nut". The "-vtag" option is currently needed,
otherwise FFmpeg will use a RGB[15] codec tag for some reason.
I have also updated the 1 bpp FATE test files (once again).
Mats
>From 8352c31123e06ffe88b389305bc43
a RGB[15] codec tag for some reason.
I have also updated the 1 bpp FATE test files (once again).
Mats
>From fa9ae2355de3d7f5c7622a650f6a2a8223b1b13d Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Wed, 10 Feb 2016 02:38:16 +0100
Subject: [PATCH v4] lavc/rawdec: Remove monowhite switching
[15] codec tag for some reason.
I have also updated the 1 bpp FATE test files (once again).
Mats
>From fb5e1ddde3f9ec9a7ad376e169c76a59f51e380a Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Wed, 10 Feb 2016 02:44:58 +0100
Subject: [PATCH v5] lavc/rawdec: Remove monowhite switching
ag for some reason.
I have also updated the 1 bpp FATE test files (once again).
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From dc621b883570f00226a55dcbdeea6e23980a28ad Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Wed, 10 Feb 2016 10:01:02 +0100
Subject: [PATCH v6] lavc/rawdec
On 02/10/2016 10:12 AM, Mats Peterson wrote:
The stride will be calculated incorrectly for the attached 3 x 3 pixel
pal8 nut file, since there is some padding in the packet after the video
data and before the palette. It will be properly rounded down to the
real width of the video data for
On 02/10/2016 11:14 AM, Mats Peterson wrote:
On 02/10/2016 10:12 AM, Mats Peterson wrote:
The stride will be calculated incorrectly for the attached 3 x 3 pixel
pal8 nut file, since there is some padding in the packet after the video
data and before the palette. It will be properly rounded down
On 02/10/2016 12:26 PM, Mats Peterson wrote:
for nut. It would of course be much easier. One will have to divide the
packet size with the height, in the same way as the stride is calculated
, of
For nut, the packet size minus the palette size, of course.
Mats
On 02/10/2016 12:26 PM, Mats Peterson wrote:
When using "-vcodec copy" with pal8 nut as the output, FFmpeg will
happily copy the video to the file without ever considering the stride
of it.
This is an imaginary situation, since I'm not able to enter the 'PAL[8]'
ta
eeded,
otherwise FFmpeg will use a RGB[15] codec tag for some reason.
I have also updated the 1 bpp FATE test files (once again).
Mats
>From 4eb101f9b022240861df1386811a3d71b9e710a7 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Wed, 10 Feb 2016 23:55:41 +0100
Subject: [PATCH v7] lavc/rawdec
here seems to be some weird dithering going
on of the white color, so there will be black pixels here and there in
the monow output. A better way is to use "ffmpeg -i 1bpp.avi -vcodec
copy -vtag B1W0 1bpp.nut". The "-vtag" option is currently needed,
otherwise FFmpeg will use
Sorry for the double posting. Don't bother about this one.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 02/11/2016 12:07 AM, Mats Peterson wrote:
For black & white AVI or QuickTime files, in order to produce a
monochrome nut file, force the pixel format with "-pix_fmt monow" or
"-pix_fmt monob".
Unfortunately, there is a problem with converting from pal8 to monow,
a
On 02/11/2016 01:11 AM, Mats Peterson wrote:
On 02/11/2016 12:07 AM, Mats Peterson wrote:
For black & white AVI or QuickTime files, in order to produce a
monochrome nut file, force the pixel format with "-pix_fmt monow" or
"-pix_fmt monob".
Unfortunately, there is a
On 02/11/2016 02:14 AM, Michael Niedermayer wrote:
On Thu, Feb 11, 2016 at 01:15:38AM +0100, Mats Peterson wrote:
On 02/11/2016 01:11 AM, Mats Peterson wrote:
On 02/11/2016 12:07 AM, Mats Peterson wrote:
For black & white AVI or QuickTime files, in order to produce a
monochrome nut
On 02/11/2016 02:20 AM, Mats Peterson wrote:
have you tried updating your git checkout ?
it might be fixed by: 23261e60014908da7446e9b5bc7401dc30fdecd6
I just pulled the latest. Let's see what happens. It seems you've
changed the *bpp1 files in tests/ref/vsynth for some reason. I
is currently needed, otherwise FFmpeg will
use a RGB[15] codec tag for some reason.
I have also updated the 1 bpp FATE test files (once again).
Mats
>From 999aa8311b0b018accf35b5825af2c027efeb474 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Thu, 11 Feb 2016 03:16:00 +01
On 02/11/2016 02:29 AM, Mats Peterson wrote:
On 02/11/2016 02:20 AM, Mats Peterson wrote:
have you tried updating your git checkout ?
it might be fixed by: 23261e60014908da7446e9b5bc7401dc30fdecd6
I just pulled the latest. Let's see what happens. It seems you've
changed the *bpp
On 02/11/2016 03:20 AM, Mats Peterson wrote:
Updated the FATE test files for the latest checkout.
The stride will be calculated incorrectly for the attached 3 x 3 pixel
pal8 nut file, since there is some padding in the packet after the video
data and before the palette. It will be properly
On 02/11/2016 03:21 AM, Mats Peterson wrote:
On 02/11/2016 02:29 AM, Mats Peterson wrote:
On 02/11/2016 02:20 AM, Mats Peterson wrote:
have you tried updating your git checkout ?
it might be fixed by: 23261e60014908da7446e9b5bc7401dc30fdecd6
I just pulled the latest. Let's see what ha
On 02/11/2016 03:20 AM, Mats Peterson wrote:
Updated the FATE test files for the latest checkout.
The stride will be calculated incorrectly for the attached 3 x 3 pixel
pal8 nut file, since there is some padding in the packet after the video
data and before the palette. It will be properly
On 02/11/2016 03:46 AM, Mats Peterson wrote:
Nice. The patch fails on tests/ref/fate/sub2video, since you JUST
changed it over there. Can you fix that on your side?
Ignore this patch.
Mats
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 02/12/2016 10:53 AM, Paul B Mahol wrote:
On 2/12/16, Mats Peterson wrote:
On 02/11/2016 03:46 AM, Mats Peterson wrote:
Nice. The patch fails on tests/ref/fate/sub2video, since you JUST
changed it over there. Can you fix that on your side?
Ignore this patch.
Why?
Are you being
On 02/12/2016 11:06 AM, Paul B Mahol wrote:
Why?
Are you being sarcastic?
No. Why patch should be ignored?
___
Because I had to fix some additional stuff. I should perhaps say "Ignore
this *version* of the patch"...
Mats
__
ce the pixel format with "-pix_fmt monow" or
"-pix_fmt monob".
Another way is to use "ffmpeg -i 1bpp.avi -vcodec copy -vtag B1W0
1bpp.nut". The "-vtag" option is currently needed, otherwise FFmpeg will
use a RGB[15] codec tag for some reason.
I ha
On 02/12/2016 11:26 AM, Mats Peterson wrote:
Now handles non-standard 8 bpp raw AVI files created with "-vcodec
rawvideo" that contain the palette at the end of each frame, like nut.
8 bpp raw QuickTime files created with "-vcodec rawvideo" won't work
quite right, becau
On 02/12/2016 12:02 PM, Mats Peterson wrote:
On 02/12/2016 11:26 AM, Mats Peterson wrote:
Now handles non-standard 8 bpp raw AVI files created with "-vcodec
rawvideo" that contain the palette at the end of each frame, like nut.
8 bpp raw QuickTime files created with "-vcodec
On 02/12/2016 12:49 PM, Michael Niedermayer wrote:
please split the patch so that each patch is selfcontained and
does not contain independant changes or bugfixes.
see "git rebase -i" and 'git add -p' and "git commit --amend" for
tools to conveniently seperate changes into commits
It is importan
On 02/12/2016 12:53 PM, Mats Peterson wrote:
ahead. I know the debug code is superfluous, though.
But it's handy in order to check packet size / stride, since this circus
is far from over and done with.
Mats
___
ffmpeg-devel mailing list
f
On 02/12/2016 01:00 PM, Michael Niedermayer wrote:
can you fix that ?
it is very important that generated files are correct and compliant
to specs
Well, it's not because of my patch. It was the same before it. And you
have more knowledge than me when it comes to fixing the muxing code. I
hav
On 02/12/2016 01:02 PM, Michael Niedermayer wrote:
On Fri, Feb 12, 2016 at 12:55:59PM +0100, Mats Peterson wrote:
On 02/12/2016 12:53 PM, Mats Peterson wrote:
ahead. I know the debug code is superfluous, though.
But it's handy in order to check packet size / stride, since this
circus i
On 02/12/2016 01:03 PM, Mats Peterson wrote:
Well, it's not because of my patch. It was the same before it. And you
have more knowledge than me when it comes to fixing the muxing code. I
have mostly dealt with the demuxing side so far, since that's where I
feel decently comfortable.
On 02/12/2016 01:09 PM, Mats Peterson wrote:
I admit it sounded like it was because of my patch, but I worded it in a
confusing way, I guess. I meant that since my patch will make 1 bpp raw
AVI files use pal8 internally, to produce a 1 bpp file, you can either
use "-vcodec copy", o
On 02/12/2016 12:49 PM, Michael Niedermayer wrote:
+av_log(avctx, AV_LOG_DEBUG, "PACKET SIZE: %d\n", avpkt->size);
+av_log(avctx, AV_LOG_DEBUG, "STRIDE: %d\n", stride);
this looks like some private debug code, which doesnt belong in this
patch
This is easy enough for you to remove, i
On 02/12/2016 01:09 PM, Mats Peterson wrote:
On 02/12/2016 01:03 PM, Mats Peterson wrote:
Well, it's not because of my patch. It was the same before it. And you
have more knowledge than me when it comes to fixing the muxing code. I
have mostly dealt with the demuxing side so far, since t
On 02/12/2016 01:41 PM, Mats Peterson wrote:
On 02/12/2016 01:09 PM, Mats Peterson wrote:
On 02/12/2016 01:03 PM, Mats Peterson wrote:
Well, it's not because of my patch. It was the same before it. And you
have more knowledge than me when it comes to fixing the muxing code. I
have mostly
On 02/12/2016 01:27 PM, wm4 wrote:
This is easy enough for you to remove, isn't it?
It's even easier for you. (Should be.)
Well, he seems to want to split the patch up anyway, so it shouldn't be
that hard to remove those lines.
Mats
___
ffmpeg-
On 02/13/2016 12:51 AM, Michael Niedermayer wrote:
+if (context->has_pkt_pal) {
+memcpy(context->palette->data,
+ avpkt->data + avpkt->size - AVPALETTE_SIZE, AVPALETTE_SIZE);
This is incorrect, the 8bit palette in nut can have any number of
entries up to 2
On 02/13/2016 05:39 AM, Mats Peterson wrote:
On 02/13/2016 12:51 AM, Michael Niedermayer wrote:
+if (context->has_pkt_pal) {
+memcpy(context->palette->data,
+ avpkt->data + avpkt->size - AVPALETTE_SIZE,
AVPALETTE_SIZE);
This is inco
On 02/13/2016 05:44 AM, Mats Peterson wrote:
again, if you could help fix the bugs (which are not caused by your
patch but which interact with these changes in nasty ways)
that would be great
The rawvideo muxing bugs (incorrect stride for AVI and QuickTime files
produced with "-v
On 02/13/2016 05:44 AM, Mats Peterson wrote:
ill try to split out some trivial parts from this patch and apply
them as seperate commits after some testing though
Alright.
It shouldn't be that hard. Everything works just fine except that
non-AVPALETTE_SIZE thing.
On 02/13/2016 05:48 AM, Mats Peterson wrote:
It shouldn't be that hard. Everything works just fine except that
non-AVPALETTE_SIZE thing.
And how are we supposed to solve that? Knowing how many colors there are
in the palette in the nut packets?
On 02/13/2016 05:39 AM, Mats Peterson wrote:
On 02/13/2016 12:51 AM, Michael Niedermayer wrote:
+if (context->has_pkt_pal) {
+memcpy(context->palette->data,
+ avpkt->data + avpkt->size - AVPALETTE_SIZE,
AVPALETTE_SIZE);
This is inco
On 02/13/2016 05:39 AM, Mats Peterson wrote:
ill try to split out some trivial parts from this patch and apply
them as seperate commits after some testing though
Alright.
You could start with removing the monowhite switching code.
Mats
What it sound like.
Mats
>From 59572f63d94bab07ab392be344c9cde7368fa33a Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Sat, 13 Feb 2016 06:45:02 +0100
Subject: [PATCH] lavc/rawdec: Remove monowhite switching code (and only that)
---
libavcodec/rawdec.c | 19 ---
1 f
On 02/13/2016 06:46 AM, Mats Peterson wrote:
What it sound like.
Mats
Forget this one. I forgot to update the FATE test files.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
What it sounds like. Remove the temporary monowhite switching code for 1
bpp raw AVI.
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 470961cfde11ea31f4b00b2aad4f43caea0a Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Sat, 13 Feb 2016 07:23:19 +0100
Subject: [PATCH] lavc/raw
On 02/13/2016 11:22 AM, Michael Niedermayer wrote:
On Sat, Feb 13, 2016 at 06:01:21AM +0100, Mats Peterson wrote:
On 02/13/2016 05:39 AM, Mats Peterson wrote:
On 02/13/2016 12:51 AM, Michael Niedermayer wrote:
+if (context->has_pkt_pal) {
+memcpy(context->palette
On 02/13/2016 11:28 AM, Mats Peterson wrote:
Once again, how are we supposed to know how many colors the palette
consists of at the end of avpkt->data?
palette size = packet size - width*height
Nope. You have to take the stride in account as well, not just the width
and height, and
On 02/13/2016 11:29 AM, Mats Peterson wrote:
Nope. You have to take the stride in account as well, not just the width
and height, and it varies in nut, depending on whether you use "-vcodec
copy" or "-vcodec rawvideo".
Mats
And you'll have to calculate the stride b
On 02/13/2016 11:39 AM, Paul B Mahol wrote:
On 2/13/16, Mats Peterson wrote:
On 02/13/2016 11:28 AM, Mats Peterson wrote:
Once again, how are we supposed to know how many colors the palette
consists of at the end of avpkt->data?
palette size = packet size - width*height
Nope. You have
On 02/13/2016 11:40 AM, Mats Peterson wrote:
On 02/13/2016 11:39 AM, Paul B Mahol wrote:
On 2/13/16, Mats Peterson wrote:
On 02/13/2016 11:28 AM, Mats Peterson wrote:
Once again, how are we supposed to know how many colors the palette
consists of at the end of avpkt->data?
palette s
On 02/13/2016 11:44 AM, Mats Peterson wrote:
On 02/13/2016 11:40 AM, Mats Peterson wrote:
On 02/13/2016 11:39 AM, Paul B Mahol wrote:
On 2/13/16, Mats Peterson wrote:
On 02/13/2016 11:28 AM, Mats Peterson wrote:
Once again, how are we supposed to know how many colors the palette
consists of
On 02/13/2016 12:31 PM, Michael Niedermayer wrote:
On Sat, Feb 13, 2016 at 11:44:04AM +0100, Mats Peterson wrote:
On 02/13/2016 11:40 AM, Mats Peterson wrote:
On 02/13/2016 11:39 AM, Paul B Mahol wrote:
On 2/13/16, Mats Peterson wrote:
On 02/13/2016 11:28 AM, Mats Peterson wrote:
Once
On 02/13/2016 12:50 PM, Mats Peterson wrote:
On 02/13/2016 12:31 PM, Michael Niedermayer wrote:
On Sat, Feb 13, 2016 at 11:44:04AM +0100, Mats Peterson wrote:
On 02/13/2016 11:40 AM, Mats Peterson wrote:
On 02/13/2016 11:39 AM, Paul B Mahol wrote:
On 2/13/16, Mats Peterson wrote:
On 02/13
On 02/13/2016 12:52 PM, Mats Peterson wrote:
just double checked, this is not the case in written pal8 nut files
nor does the nut spec say anything about that.
Then check an odd-width nut file like the one below. And FFmpeg doesn't
care about specs when using "-vcodec copy".
On 02/13/2016 12:54 PM, Mats Peterson wrote:
On 02/13/2016 12:52 PM, Mats Peterson wrote:
just double checked, this is not the case in written pal8 nut files
nor does the nut spec say anything about that.
Then check an odd-width nut file like the one below. And FFmpeg doesn't
care
On 02/13/2016 12:57 PM, Mats Peterson wrote:
On 02/13/2016 12:54 PM, Mats Peterson wrote:
On 02/13/2016 12:52 PM, Mats Peterson wrote:
just double checked, this is not the case in written pal8 nut files
nor does the nut spec say anything about that.
Then check an odd-width nut file like the
On 02/13/2016 12:58 PM, Mats Peterson wrote:
On 02/13/2016 12:57 PM, Mats Peterson wrote:
On 02/13/2016 12:54 PM, Mats Peterson wrote:
On 02/13/2016 12:52 PM, Mats Peterson wrote:
just double checked, this is not the case in written pal8 nut files
nor does the nut spec say anything about that
On 02/13/2016 01:00 PM, Mats Peterson wrote:
On 02/13/2016 12:58 PM, Mats Peterson wrote:
On 02/13/2016 12:57 PM, Mats Peterson wrote:
On 02/13/2016 12:54 PM, Mats Peterson wrote:
On 02/13/2016 12:52 PM, Mats Peterson wrote:
just double checked, this is not the case in written pal8 nut files
On 02/13/2016 01:03 PM, Mats Peterson wrote:
On 02/13/2016 01:00 PM, Mats Peterson wrote:
On 02/13/2016 12:58 PM, Mats Peterson wrote:
On 02/13/2016 12:57 PM, Mats Peterson wrote:
On 02/13/2016 12:54 PM, Mats Peterson wrote:
On 02/13/2016 12:52 PM, Mats Peterson wrote:
just double checked
On 02/13/2016 01:24 PM, wm4 wrote:
Why are you talking with yourself on the ML? Nobody is going to read
everything you post. You just replied to yourself 7 times!
If you want input from others, you need to properly communicate your
issues. This includes:
- thinking before posting
- summarizing
On 02/13/2016 01:09 PM, Mats Peterson wrote:
On 02/13/2016 01:03 PM, Mats Peterson wrote:
On 02/13/2016 01:00 PM, Mats Peterson wrote:
On 02/13/2016 12:58 PM, Mats Peterson wrote:
On 02/13/2016 12:57 PM, Mats Peterson wrote:
On 02/13/2016 12:54 PM, Mats Peterson wrote:
On 02/13/2016 12:52
On 02/13/2016 01:46 PM, Mats Peterson wrote:
On 02/13/2016 01:09 PM, Mats Peterson wrote:
On 02/13/2016 01:03 PM, Mats Peterson wrote:
On 02/13/2016 01:00 PM, Mats Peterson wrote:
On 02/13/2016 12:58 PM, Mats Peterson wrote:
On 02/13/2016 12:57 PM, Mats Peterson wrote:
On 02/13/2016 12:54
On 02/13/2016 07:25 AM, Mats Peterson wrote:
What it sounds like. Remove the temporary monowhite switching code for 1
bpp raw AVI.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
That is, this
On 02/13/2016 01:49 PM, Mats Peterson wrote:
Sorry, wm4, I got heated up here. I understand your feelings. I will try
to limit the spam-like postings. Michael, given that there is no padding
of the lines for pal8 in nut, I understand that it's possible to
calculate the stride by dividin
I have no problem with the padding *between* the video data and the
palette in nut packets. It's just a matter of rounding up to the nearest
modulo 4 byte to get the start of the palette.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/
On 02/14/2016 05:42 AM, Mats Peterson wrote:
I have no problem with the padding *between* the video data and the
palette in nut packets. It's just a matter of rounding up to the nearest
modulo 4 byte to get the start of the palette.
Mats
It's important that this padding is used co
Old stuff, new shape.
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 28d176395cb1ad7f1e4ee3120c5d0404eb45a93b Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Sun, 14 Feb 2016 06:50:00 +0100
Subject: [PATCH 1/2] lavc/rawdec: Remove temporary switching code for 1 bpp AVI withou
Since we're creating a new frame due to the alignment requirement of 16
bytes, we'll have to retrieve the nut palette from the end of the packet
data.
Mats
>From 9627c56c50f5928e04345e5e62b123f2dbe4109c Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Sun, 14 Feb 2016 07:01:23
On 02/14/2016 07:05 AM, Mats Peterson wrote:
This one is incorrect.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Since we're creating a new frame due to the alignment requirement of 16
bytes, we'll have to retrieve the nut palette from the end of the packet
data.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From c5c3c84be927c8dc04708746aa725b73cf1659b5 Mon Sep 17 00:00:00 20
Small fix.
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From d292ac7030c5e46eb92a1dd13ace1a000c0fb16f Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Sun, 14 Feb 2016 08:11:27 +0100
Subject: [PATCH 2/2 v3] lavc/rawdec: Retrieve nut palette in packets
---
libavcodec/rawdec.c |
On 02/14/2016 07:03 AM, Mats Peterson wrote:
Old stuff, new shape.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Just as a parenthesis, regardless of whether this patch is applied or
not
On 02/14/2016 11:45 AM, Mats Peterson wrote:
On 02/14/2016 07:03 AM, Mats Peterson wrote:
Old stuff, new shape.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Just as a parenthesis
On 02/14/2016 11:45 AM, Mats Peterson wrote:
Just as a parenthesis, regardless of whether this patch is applied or
not, the only way to create a "spec" compliant 1 bpp raw file from a 1
bpp raw AVI or QuickTime file
Make that any type of source file, not only AVI or QuickTime
Since a new frame is created due to the line alignment requirement of 16
bytes, the nut palette has to be retrieved from the packet data.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From d8687d9a6db9630876619e802086c78d82f5c661 Mon Sep 17 00:00:00 2001
From: Mats Peterson
D
On 02/14/2016 04:25 PM, Michael Niedermayer wrote:
This was suggested by wm4 and stefano.
After this patch using align=1 the size used by various functions would not
contain padding, while the palette would be aligned at align>1
This patch makes it required to use align>=4 if the palette is to b
On 02/14/2016 04:25 PM, Michael Niedermayer wrote:
As a side-effect It fixes storing pal8 in nut with odd with&height
It worked fine before this patch (palette starting at a 4-byte boundary).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
htt
On 02/14/2016 04:28 PM, Mats Peterson wrote:
On 02/14/2016 04:25 PM, Michael Niedermayer wrote:
As a side-effect It fixes storing pal8 in nut with odd with&height
It worked fine before this patch (palette starting at a 4-byte boundary).
OK, sorry, I get it.
Mats
--
Mats Peterson
On 02/14/2016 04:30 PM, Mats Peterson wrote:
On 02/14/2016 04:28 PM, Mats Peterson wrote:
On 02/14/2016 04:25 PM, Michael Niedermayer wrote:
As a side-effect It fixes storing pal8 in nut with odd with&height
It worked fine before this patch (palette starting at a 4-byte
boundary).
ly non-standard behaviour for AVI and QuickTime, and it makes the
files unplayable with anything else than FFplay.
Thanks in advance.
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ff
On 02/15/2016 05:38 AM, Mats Peterson wrote:
2. Palette being included in the frames. This is OK for nut, but it's
clearly non-standard behaviour for AVI and QuickTime, and it makes the
files unplayable with anything else than FFplay.
Well, it's perhaps not so much the inclusion of t
On 02/15/2016 05:38 AM, Mats Peterson wrote:
I'm not very confident on the muxing side, therefore I would be grateful
if anyone able to look outside of his own agenda could look into
possible solutions in order to solve the following issues pertaining to
writing AVI and QuickTime files cr
On 02/15/2016 07:00 AM, Mats Peterson wrote:
Files for testing are available at the links below. Get the *bpp_129.*
files. They are odd-width files (129x97 pixels).
https://drive.google.com/open?id=0B3_pEBoLs0faMnU1NUVMdXdsOE0
https://drive.google.com/open?id=0B3_pEBoLs0faWElmM2FnLTZYNlk
The
On 02/15/2016 12:38 PM, Michael Niedermayer wrote:
On Mon, Feb 15, 2016 at 05:38:03AM +0100, Mats Peterson wrote:
I'm not very confident on the muxing side, therefore I would be
grateful if anyone able to look outside of his own agenda could look
into possible solutions in order to solv
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From e62d408f3f6a90806ac64d04f06a522411a41365 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Tue, 16 Feb 2016 11:43:30 +0100
Subject: [PATCH 1/2] lavc/rawdec: Remove temporary monowhite switching code for 1 bpp AVI without a pale
I have removed the 4-byte alignment line.
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 6256d18629e70c24260e4cfb1993411ccebfac73 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Tue, 16 Feb 2016 11:44:50 +0100
Subject: [PATCH 2/2] lavc/rawdec: Retrieve nut palette from pack
Mats Peterson skrev: (16 februari 2016
11:48:28 CET)
>
And once more Michael, give me one sensible reason as to why you want to fix
the long standing muxer issues before applying these patches. That will
seemingly take forever, and it won't make any difference if you apply these
pat
Mats Peterson skrev: (16 februari 2016
14:06:07 CET)
>Mats Peterson skrev: (16 februari
>2016 11:48:28 CET)
>>
>And once more Michael, give me one sensible reason as to why you want
>to fix the long standing muxer issues before applying these patches.
>That will seemingly
Michael Niedermayer skrev: (16 februari 2016 15:03:13
CET)
>On Tue, Feb 16, 2016 at 11:49:31AM +0100, Mats Peterson wrote:
>> I have removed the 4-byte alignment line.
>>
>> --
>> Mats Peterson
>> http://matsp888.no-ip.org/~mats/
>
>> rawdec.c |8
On 02/16/2016 03:04 PM, Mats Peterson wrote:
Michael Niedermayer skrev: (16 februari 2016 15:03:13
CET)
On Tue, Feb 16, 2016 at 11:49:31AM +0100, Mats Peterson wrote:
I have removed the 4-byte alignment line.
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
rawdec.c |8
On 02/16/2016 03:34 PM, Michael Niedermayer wrote:
And what about the monowhite switching code?
Did you forget that one??
no, that patch is left for others to decide, my oppinion is that the
muxer bug must be fixed first to prevent the generation of invalid
files. I wanted to look into it as
On 02/16/2016 03:34 PM, Michael Niedermayer wrote:
no, that patch is left for others to decide, my oppinion is that the
muxer bug must be fixed first to prevent the generation of invalid
files. I wanted to look into it as you dont look into it but i dont
have time now
That's OK regarding not
1 - 100 of 1064 matches
Mail list logo