Re: [FFmpeg-devel] [PATCH v9] lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette

[Michael Niedermayer]

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->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 256, this assumes its fixed 256
> >>
> >
> >I had absolutely no idea, Michael. I'm doing my best ;) It would be much
> >easier and more consequent if it used AVPALETTE_SIZE, though.
> >
> 
> 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

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

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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

Re: [FFmpeg-devel] [PATCH v9] lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette

[Mats Peterson]

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->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 256, this assumes its fixed 256



I had absolutely no idea, Michael. I'm doing my best ;) It would be much
easier and more consequent if it used AVPALETTE_SIZE, though.



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 it varies in nut, depending on whether you use "-vcodec 
copy" or "-vcodec rawvideo".


Mats

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

Re: [FFmpeg-devel] [PATCH v9] lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette

[Mats Peterson]

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 it varies in nut, depending on whether you use "-vcodec
copy" or "-vcodec rawvideo".

Mats



And you'll have to calculate the stride by subtracting the palette size 
from the packet size, then divide by the height.


Mats

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

Re: [FFmpeg-devel] [PATCH v9] lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette

[Paul B Mahol]

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 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 by subtracting the palette size
> from the packet size, then divide by the height.

Nope, pixels outside of width x height are ignored.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v9] lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette

[Mats Peterson]

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 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 by subtracting the palette size
from the packet size, then divide by the height.


Nope, pixels outside of width x height are ignored.
___


I need the stride for the alignment to 16 bytes. It's not done for fun.

Mats

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

Re: [FFmpeg-devel] [PATCH v9] lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette

[Mats Peterson]

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 size = packet size - width*height



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 by subtracting the palette size
from the packet size, then divide by the height.


Nope, pixels outside of width x height are ignored.
___


I need the stride for the alignment to 16 bytes. It's not done for fun.

Mats



And pixels outside of the width are still in the packet, that's what's 
called the stride.


Mats

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

Re: [FFmpeg-devel] [PATCH v9] lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette

[Mats Peterson]

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 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 it varies in nut, depending on whether you use
"-vcodec
copy" or "-vcodec rawvideo".

Mats



And you'll have to calculate the stride by subtracting the palette size
from the packet size, then divide by the height.


Nope, pixels outside of width x height are ignored.
___


I need the stride for the alignment to 16 bytes. It's not done for fun.

Mats



And pixels outside of the width are still in the packet, that's what's
called the stride.

Mats




Not pixels, but bytes.

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

Re: [FFmpeg-devel] [PATCH v9] lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette

[Mats Peterson]

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 about specs when using "-vcodec copy". The stride will be the one
of the original data, whether it's 2, 4 or some other amount of bytes.



The stride will be *aligned* to 2, 4 or some other amount of bytes.

Mats



Try "ffmpeg -i 8bpp_129.avi -vcodec rawvideo 8bpp_129.nut" with the file 
below. It will have a stride aligned to 4 bytes like the original AVI 
file, and per the Microsoft specification, since it doesn't "-vcodec 
copy" won't touch the video data.


https://drive.google.com/open?id=0B3_pEBoLs0faekxWUTdkVGNTTlk
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v9] lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette

[Mats Peterson]

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 one below. And FFmpeg doesn't
care about specs when using "-vcodec copy". The stride will be the one
of the original data, whether it's 2, 4 or some other amount of bytes.



The stride will be *aligned* to 2, 4 or some other amount of bytes.

Mats



Try "ffmpeg -i 8bpp_129.avi -vcodec rawvideo 8bpp_129.nut" with the file
below. It will have a stride aligned to 4 bytes like the original AVI
file, and per the Microsoft specification, since it doesn't "-vcodec
copy" won't touch the video data.

https://drive.google.com/open?id=0B3_pEBoLs0faekxWUTdkVGNTTlk
___


I mean "ffmpeg -i 8bpp_129.avi -vcodec copy 8bpp_129.nut" of course.

Mats

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

Re: [FFmpeg-devel] [PATCH v9] lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette

[Mats Peterson]

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.



Then check an odd-width nut file like the one below. And FFmpeg
doesn't
care about specs when using "-vcodec copy". The stride will be the one
of the original data, whether it's 2, 4 or some other amount of bytes.



The stride will be *aligned* to 2, 4 or some other amount of bytes.

Mats



Try "ffmpeg -i 8bpp_129.avi -vcodec rawvideo 8bpp_129.nut" with the file
below. It will have a stride aligned to 4 bytes like the original AVI
file, and per the Microsoft specification, since it doesn't "-vcodec
copy" won't touch the video data.

https://drive.google.com/open?id=0B3_pEBoLs0faekxWUTdkVGNTTlk
___


I mean "ffmpeg -i 8bpp_129.avi -vcodec copy 8bpp_129.nut" of course.

Mats



The stride will be 132 bytes, divisible by 4, rather than 129 bytes.

Mats

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

Re: [FFmpeg-devel] [PATCH v9] lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette

[Mats Peterson]

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
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". The stride will be the
one
of the original data, whether it's 2, 4 or some other amount of
bytes.



The stride will be *aligned* to 2, 4 or some other amount of bytes.

Mats



Try "ffmpeg -i 8bpp_129.avi -vcodec rawvideo 8bpp_129.nut" with the file
below. It will have a stride aligned to 4 bytes like the original AVI
file, and per the Microsoft specification, since it doesn't "-vcodec
copy" won't touch the video data.

https://drive.google.com/open?id=0B3_pEBoLs0faekxWUTdkVGNTTlk
___


I mean "ffmpeg -i 8bpp_129.avi -vcodec copy 8bpp_129.nut" of course.

Mats



The stride will be 132 bytes, divisible by 4, rather than 129 bytes.

Mats



Now the problem is that it won't show any video, since the incorrect 
codec tag RGB[15] will be written to the nut file, and it's not possible 
to use "-vtag" to set tha PAL[8] codec tag, but if you use "-v debug" 
you will see that the stride is 132 bytes.


Mats

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

Re: [FFmpeg-devel] [PATCH v9] lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette

[Mats Peterson]

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, 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". The stride will be the
one
of the original data, whether it's 2, 4 or some other amount of
bytes.



The stride will be *aligned* to 2, 4 or some other amount of bytes.

Mats



Try "ffmpeg -i 8bpp_129.avi -vcodec rawvideo 8bpp_129.nut" with the
file
below. It will have a stride aligned to 4 bytes like the original AVI
file, and per the Microsoft specification, since it doesn't "-vcodec
copy" won't touch the video data.

https://drive.google.com/open?id=0B3_pEBoLs0faekxWUTdkVGNTTlk
___


I mean "ffmpeg -i 8bpp_129.avi -vcodec copy 8bpp_129.nut" of course.

Mats



The stride will be 132 bytes, divisible by 4, rather than 129 bytes.

Mats



Now the problem is that it won't show any video, since the incorrect
codec tag RGB[15] will be written to the nut file, and it's not possible
to use "-vtag" to set tha PAL[8] codec tag, but if you use "-v debug"
you will see that the stride is 132 bytes.

Mats

___


What's more, no palette will be included in the frames, since "-vcodec 
copy" once again doesn't touch the original AVI data. So it's pretty 
useless to use "-vcodec copy" for pal8.


Mats

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

Re: [FFmpeg-devel] [PATCH v9] lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette

[wm4]

On Sat, 13 Feb 2016 13:09:48 +0100
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 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". The stride will be the
> >>> one
> >>> of the original data, whether it's 2, 4 or some other amount of
> >>> bytes.
> >>>  
> >
> > The stride will be *aligned* to 2, 4 or some other amount of bytes.
> >
> > Mats
> >  
> 
>  Try "ffmpeg -i 8bpp_129.avi -vcodec rawvideo 8bpp_129.nut" with the
>  file
>  below. It will have a stride aligned to 4 bytes like the original AVI
>  file, and per the Microsoft specification, since it doesn't "-vcodec
>  copy" won't touch the video data.
> 
>  https://drive.google.com/open?id=0B3_pEBoLs0faekxWUTdkVGNTTlk
>  ___  
> >>>
> >>> I mean "ffmpeg -i 8bpp_129.avi -vcodec copy 8bpp_129.nut" of course.
> >>>
> >>> Mats
> >>>  
> >>
> >> The stride will be 132 bytes, divisible by 4, rather than 129 bytes.
> >>
> >> Mats
> >>  
> >
> > Now the problem is that it won't show any video, since the incorrect
> > codec tag RGB[15] will be written to the nut file, and it's not possible
> > to use "-vtag" to set tha PAL[8] codec tag, but if you use "-v debug"
> > you will see that the stride is 132 bytes.
> >
> > Mats
> >
> > ___  
> 
> What's more, no palette will be included in the frames, since "-vcodec 
> copy" once again doesn't touch the original AVI data. So it's pretty 
> useless to use "-vcodec copy" for pal8.

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 the issues in a CONCISE and short way
- not confusing yourself and others with hundreds of follow-ups
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v9] lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette

[Mats Peterson]

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 the issues in a CONCISE and short way
- not confusing yourself and others with hundreds of follow-ups
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel




I wasn't talking to you.

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

Re: [FFmpeg-devel] [PATCH v9] lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette

[Mats Peterson]

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 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". The stride will be the
one
of the original data, whether it's 2, 4 or some other amount of
bytes.



The stride will be *aligned* to 2, 4 or some other amount of bytes.

Mats



Try "ffmpeg -i 8bpp_129.avi -vcodec rawvideo 8bpp_129.nut" with the
file
below. It will have a stride aligned to 4 bytes like the original AVI
file, and per the Microsoft specification, since it doesn't "-vcodec
copy" won't touch the video data.

https://drive.google.com/open?id=0B3_pEBoLs0faekxWUTdkVGNTTlk
___


I mean "ffmpeg -i 8bpp_129.avi -vcodec copy 8bpp_129.nut" of course.

Mats



The stride will be 132 bytes, divisible by 4, rather than 129 bytes.

Mats



Now the problem is that it won't show any video, since the incorrect
codec tag RGB[15] will be written to the nut file, and it's not possible
to use "-vtag" to set tha PAL[8] codec tag, but if you use "-v debug"
you will see that the stride is 132 bytes.

Mats

___


What's more, no palette will be included in the frames, since "-vcodec
copy" once again doesn't touch the original AVI data. So it's pretty
useless to use "-vcodec copy" for pal8.

Mats



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 dividing the packet size by (width * height). 
It's only when using "-vcodec copy" that the stride will be different, 
and then no palette will be included as well. I'll arrange something here.


Mats

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

Re: [FFmpeg-devel] [PATCH v9] lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette

[Mats Peterson]

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 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 about specs when using "-vcodec copy". The stride will be the
one
of the original data, whether it's 2, 4 or some other amount of
bytes.



The stride will be *aligned* to 2, 4 or some other amount of bytes.

Mats



Try "ffmpeg -i 8bpp_129.avi -vcodec rawvideo 8bpp_129.nut" with the
file
below. It will have a stride aligned to 4 bytes like the original AVI
file, and per the Microsoft specification, since it doesn't "-vcodec
copy" won't touch the video data.

https://drive.google.com/open?id=0B3_pEBoLs0faekxWUTdkVGNTTlk
___


I mean "ffmpeg -i 8bpp_129.avi -vcodec copy 8bpp_129.nut" of course.

Mats



The stride will be 132 bytes, divisible by 4, rather than 129 bytes.

Mats



Now the problem is that it won't show any video, since the incorrect
codec tag RGB[15] will be written to the nut file, and it's not possible
to use "-vtag" to set tha PAL[8] codec tag, but if you use "-v debug"
you will see that the stride is 132 bytes.

Mats

___


What's more, no palette will be included in the frames, since "-vcodec
copy" once again doesn't touch the original AVI data. So it's pretty
useless to use "-vcodec copy" for pal8.

Mats



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 dividing the packet size by (width * height).
It's only when using "-vcodec copy" that the stride will be different,
and then no palette will be included as well. I'll arrange something here.



Will you please apply my "remove the monoswitch code only" patch first?

Mats

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

Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Remove temporary monowhite switching code for 1 bpp raw AVI

[Mats Peterson]

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 one. Please apply it before I'll continue.

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 v9] lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette

[Mats Peterson]

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 dividing the packet size by (width * height).
It's only when using "-vcodec copy" that the stride will be different,
and then no palette will be included as well. I'll arrange something
here.





I mean of course that it's possible to calculate the palette size by 
subtracting width * height from the packet size.


Mats

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

Re: [FFmpeg-devel] [PATCH] avutil/avstring: add a "ALL" entry and the possibility to negate matches to av_match_name()

[Stefano Sabatini]

On date Thursday 2016-02-11 20:49:05 +0100, Michael Niedermayer encoded:
> This will extend the whitelist features to allow blacklisting individual 
> protocols and to
> explicitly force everything to be enabled.
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavutil/avstring.c |   15 ++-
>  libavutil/avstring.h |5 +
>  2 files changed, 15 insertions(+), 5 deletions(-)

Nit: bump micro

> 
> diff --git a/libavutil/avstring.c b/libavutil/avstring.c
> index 57fe74d..85fb3e9 100644
> --- a/libavutil/avstring.c
> +++ b/libavutil/avstring.c
> @@ -326,13 +326,18 @@ int av_match_name(const char *name, const char *names)
>  return 0;
>  
>  namelen = strlen(name);
> -while ((p = strchr(names, ','))) {
> +while (*names) {
> +int negate = '-' == *names;
> +p = strchr(names, ',');
> +if (!p)
> +p = names + strlen(names);
> +names += negate;
>  len = FFMAX(p - names, namelen);
> -if (!av_strncasecmp(name, names, len))
> -return 1;
> -names = p + 1;
> +if (!av_strncasecmp(name, names, len) || !strncmp("ALL", names, 
> FFMAX(3, p - names)))
> +return !negate;

So we have:

av_match_name("foo", "foo")  => 1
av_match_name("foo", "ALL")  => 1
av_match_name("foo", "-foo") => 0
av_match_name("foo", "ALL,-foo") => 1
av_match_name("foo", "-foo,ALL") => 0

Is this correct?

> +names = p + (*p == ',');
>  }
> -return !av_strcasecmp(name, names);
> +return 0;
>  }

>  int av_utf8_decode(int32_t *codep, const uint8_t **bufp, const uint8_t 
> *buf_end,
> diff --git a/libavutil/avstring.h b/libavutil/avstring.h
> index a46d012..ea08d4f 100644
> --- a/libavutil/avstring.h
> +++ b/libavutil/avstring.h
> @@ -284,6 +284,11 @@ const char *av_dirname(char *path);
>  
>  /**
>   * Match instances of a name in a comma-separated list of names.

> + * List entries are checked from 0 to the end of the names list,

from 0 => from the start

> + * the first match ends further proessing. If a entry prefixed with '-'
> + * matches than 0 is returned. the "ALL" list entry is considered to
> + * match all names.

With typo-check on and my suggestion, this becomes:

 * the first match ends further processing. If an entry prefixed with '-'
 * matches, then 0 is returned. The "ALL" list entry is considered to
 * match all names.

LGTM otherwise, thanks.
-- 
FFmpeg = Fabulous & Fostering Mega Power Elegant Gem
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] avutil/imgutils: only align the palette in av_image_copy_to_buffer() if there is enough space

[Michael Niedermayer]

This allows disabling the alignment by using a compact buffer

Signed-off-by: Michael Niedermayer 
---
 libavutil/imgutils.c |5 +
 libavutil/version.h  |2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
index 5c28703..adf6fdd 100644
--- a/libavutil/imgutils.c
+++ b/libavutil/imgutils.c
@@ -385,6 +385,7 @@ int av_image_copy_to_buffer(uint8_t *dst, int dst_size,
 int i, j, nb_planes = 0, linesize[4];
 int size = av_image_get_buffer_size(pix_fmt, width, height, align);
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
+uint8_t *orig_dst = dst;
 
 if (size > dst_size || size < 0 || !desc)
 return AVERROR(EINVAL);
@@ -409,6 +410,10 @@ int av_image_copy_to_buffer(uint8_t *dst, int dst_size,
 
 if (desc->flags & AV_PIX_FMT_FLAG_PAL) {
 uint32_t *d32 = (uint32_t *)(((size_t)dst + 3) & ~3);
+
+if (dst_size - 1024 < (uint8_t*)d32 - orig_dst)
+d32 = (uint32_t *)dst;
+
 for (i = 0; i<256; i++)
 AV_WL32(d32 + i, AV_RN32(src_data[1] + 4*i));
 }
diff --git a/libavutil/version.h b/libavutil/version.h
index 5352f26..f99624c 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -65,7 +65,7 @@
 
 #define LIBAVUTIL_VERSION_MAJOR  55
 #define LIBAVUTIL_VERSION_MINOR  17
-#define LIBAVUTIL_VERSION_MICRO 100
+#define LIBAVUTIL_VERSION_MICRO 101
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
LIBAVUTIL_VERSION_MINOR, \
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH 1/2] avutil/imgutils: do not ignore align parameter for pseudo-pal in av_image_get_buffer_size()

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavutil/imgutils.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
index 3320664..5c28703 100644
--- a/libavutil/imgutils.c
+++ b/libavutil/imgutils.c
@@ -370,7 +370,7 @@ int av_image_get_buffer_size(enum AVPixelFormat pix_fmt,
 
 // do not include palette for these pseudo-paletted formats
 if (desc->flags & AV_PIX_FMT_FLAG_PSEUDOPAL)
-return width * height;
+return FFALIGN(width, align) * height;
 
 return av_image_fill_arrays(data, linesize, NULL, pix_fmt,
 width, height, align);
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH] doc/protocols: document protocol_whitelist

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 doc/protocols.texi |   19 +++
 1 file changed, 19 insertions(+)

diff --git a/doc/protocols.texi b/doc/protocols.texi
index 05c4bdb..41b43d4 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1,3 +1,22 @@
+@chapter Protocol Options
+@c man begin PROTOCOL OPTIONS
+
+The libavformat library provides some generic global options, which
+can be set on all the protocols. In addition each protocol may support
+so-called private options, which are specific for that component.
+
+The list of supported options follows:
+
+@table @option
+@item protocol_whitelist @var{list} (@emph{input})
+"," separated List of allowed protocols. "ALL" matches all protocols. protocols
+prefixed by "-" are disabled. The default is that initially all protocols are
+allowed but protocols used by a protocol are restricted to a per protocol
+subset.
+@end table
+
+@c man end PROTOCOL OPTIONS
+
 @chapter Protocols
 @c man begin PROTOCOLS
 
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH] fate/source: Do not use GNU extensions in sed

[Timothy Gu]

On Sat, Feb 13, 2016 at 02:35:22AM +0100, Michael Niedermayer wrote:
> On Fri, Feb 12, 2016 at 05:07:20PM -0800, Timothy Gu wrote:
> > ---
> > 
> > Tested on FreeBSD 10.2.
> 
> patch should be ok

Pushed, thanks.

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

[FFmpeg-devel] [PATCH] libavdevice/dshow.c: Correct CoGetMalloc check

[FearThe1337]

Fixes a typo in a return code conditional check.


0001-libavdevice-dshow.c-Correct-CoGetMalloc-check.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avutil/imgutils: only align the palette in av_image_copy_to_buffer() if there is enough space

[Stefano Sabatini]

On date Saturday 2016-02-13 15:32:58 +0100, Michael Niedermayer encoded:
> This allows disabling the alignment by using a compact buffer
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavutil/imgutils.c |5 +
>  libavutil/version.h  |2 +-
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
> index 5c28703..adf6fdd 100644
> --- a/libavutil/imgutils.c
> +++ b/libavutil/imgutils.c
> @@ -385,6 +385,7 @@ int av_image_copy_to_buffer(uint8_t *dst, int dst_size,
>  int i, j, nb_planes = 0, linesize[4];
>  int size = av_image_get_buffer_size(pix_fmt, width, height, align);
>  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
> +uint8_t *orig_dst = dst;
>  
>  if (size > dst_size || size < 0 || !desc)
>  return AVERROR(EINVAL);
> @@ -409,6 +410,10 @@ int av_image_copy_to_buffer(uint8_t *dst, int dst_size,
>  

>  if (desc->flags & AV_PIX_FMT_FLAG_PAL) {
>  uint32_t *d32 = (uint32_t *)(((size_t)dst + 3) & ~3);
> +
> +if (dst_size - 1024 < (uint8_t*)d32 - orig_dst)
> +d32 = (uint32_t *)dst;
> +

Do you have a specific use case for this?

[...]

LGTM. 
-- 
FFmpeg = Foolish and Forgiving Merciless Pure Evil Gnome
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/protocols: document protocol_whitelist

[Stefano Sabatini]

On date Saturday 2016-02-13 17:01:59 +0100, Michael Niedermayer encoded:
> Signed-off-by: Michael Niedermayer 
> ---
>  doc/protocols.texi |   19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/doc/protocols.texi b/doc/protocols.texi
> index 05c4bdb..41b43d4 100644
> --- a/doc/protocols.texi
> +++ b/doc/protocols.texi
> @@ -1,3 +1,22 @@
> +@chapter Protocol Options
> +@c man begin PROTOCOL OPTIONS
> +
> +The libavformat library provides some generic global options, which
> +can be set on all the protocols. In addition each protocol may support
> +so-called private options, which are specific for that component.
> +
> +The list of supported options follows:
> +
> +@table @option
> +@item protocol_whitelist @var{list} (@emph{input})
> +"," separated List of allowed protocols. "ALL" matches all protocols. 
> protocols

Nit:
Set a ","-separated list of allowed protocols. "ALL" matches all protocols. 
Protocols


> +prefixed by "-" are disabled.

> The default is that initially all protocols are

This "initially" is confusing.

> +allowed but protocols used by a protocol are restricted to a per protocol
> +subset.

What about:

All protocols are allowed by default but protocols used by a another
protocol (nested protocols) are restricted to a per protocol subset.

?
...

May be conceptually wrong though since I didn't follow the whitelist
protocol discussion.
-- 
FFmpeg = Furious & Fanciful Mastodontic Powered Enlightened Glue
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avutil/imgutils: only align the palette in av_image_copy_to_buffer() if there is enough space

[Michael Niedermayer]

On Sat, Feb 13, 2016 at 05:53:17PM +0100, Stefano Sabatini wrote:
> On date Saturday 2016-02-13 15:32:58 +0100, Michael Niedermayer encoded:
> > This allows disabling the alignment by using a compact buffer
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavutil/imgutils.c |5 +
> >  libavutil/version.h  |2 +-
> >  2 files changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
> > index 5c28703..adf6fdd 100644
> > --- a/libavutil/imgutils.c
> > +++ b/libavutil/imgutils.c
> > @@ -385,6 +385,7 @@ int av_image_copy_to_buffer(uint8_t *dst, int dst_size,
> >  int i, j, nb_planes = 0, linesize[4];
> >  int size = av_image_get_buffer_size(pix_fmt, width, height, align);
> >  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
> > +uint8_t *orig_dst = dst;
> >  
> >  if (size > dst_size || size < 0 || !desc)
> >  return AVERROR(EINVAL);
> > @@ -409,6 +410,10 @@ int av_image_copy_to_buffer(uint8_t *dst, int dst_size,
> >  
> 
> >  if (desc->flags & AV_PIX_FMT_FLAG_PAL) {
> >  uint32_t *d32 = (uint32_t *)(((size_t)dst + 3) & ~3);
> > +
> > +if (dst_size - 1024 < (uint8_t*)d32 - orig_dst)
> > +d32 = (uint32_t *)dst;
> > +
> 
> Do you have a specific use case for this?

the nut spec currently says that for pal8 theres
width*height + palette
if both width and height are odd the padding results in a mismatch
to that

This commit alone doesnt fix it but it allows to use
av_image_copy_to_buffer() to create that layout

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

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

Re: [FFmpeg-devel] [RFC][WIP][PATCH] avfilter: add luascript filter

[Stefano Sabatini]

On date Thursday 2016-02-04 19:40:18 +0100, Paul B Mahol encoded:
> On 2/2/16, Paul B Mahol  wrote:
> > Hi,
> >
> > patch attached.
> >
> 
> Much more useful version attached.
> 
> Simple demo demonstrating functionality currently missing in lavfi:

I toyed with this idea three years ago, and I'll show you my (crappy)
POC patch which assumes a different design (resuming: I wanted to
implement a lua function to filter the media buffer, and possibly add
other hooks to call during configuration).

Sample lua script file:

frame = 0

function init()
 print "hello world!"
 print(l_sin(239))
end

function filter_frame()
 print(string.format('frame number %d', frame))
 frame = frame + 1
end

I gave up because I realized that with that approach I also needed to
script most FFmpeg functions, that is I needed to script FFmpeg as a
whole, which hugely extended the scope of the task.

> 
> lavfi.log(0, "Lavfi script example", lavfi.script_name, lavfi.frame_count(0));
> if (lavfi.frame_count(0) >= 50) then
> lavfi.filter({"aa"}, "vflip", nil, {"a"})
> lavfi.filter({"bb"}, "hflip", nil, {"b"})
> else
> lavfi.filter({"aa"}, "negate", nil, {"a"})
> lavfi.filter({"bb"}, "vflip",  nil, {"b"})
> end
> 
> lavfi.filter({"a", "b"}, "hstack", "2", {"out0"});

Can you shortly give a description of how this code interface with lua?
(alternatively write docs, assuming you plan to land a committable version)

> From a84f155924b2235162d690664c97b55477d0a4c2 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol 
> Date: Tue, 2 Feb 2016 10:09:50 +0100
> Subject: [PATCH] avfilter: add luascript filter
> 
> Signed-off-by: Paul B Mahol 
> ---
>  configure   |   4 +
>  libavfilter/Makefile|   1 +
>  libavfilter/allfilters.c|   1 +
>  libavfilter/src_luascript.c | 793 
> 
>  4 files changed, 799 insertions(+)
>  create mode 100644 libavfilter/src_luascript.c

[...]
-- 
FFmpeg = Free and Frightening Maxi Portentous Evangelical Glue
>From eedbafe05e4947b0030399597c4aeb4d898b390c Mon Sep 17 00:00:00 2001
From: Stefano Sabatini 
Date: Sat, 1 Jun 2013 16:43:31 +0200
Subject: [PATCH] lavfi: add lua filter

---
 configure|   4 +
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_lua.c | 261 +++
 4 files changed, 267 insertions(+)
 create mode 100644 libavfilter/vf_lua.c

diff --git a/configure b/configure
index 93970a1..35f3d79 100755
--- a/configure
+++ b/configure
@@ -205,6 +205,7 @@ External library support:
   --enable-libgsm  enable GSM de/encoding via libgsm [no]
   --enable-libiec61883 enable iec61883 via libiec61883 [no]
   --enable-libilbc enable iLBC de/encoding via libilbc [no]
+  --enable-liblua  enable Lua scripting [no]
   --enable-libmodplug  enable ModPlug via libmodplug [no]
   --enable-libmp3lame  enable MP3 encoding via libmp3lame [no]
   --enable-libnut  enable NUT (de)muxing via libnut,
@@ -1169,6 +1170,7 @@ EXTERNAL_LIBRARY_LIST="
 libgsm
 libiec61883
 libilbc
+liblua
 libmodplug
 libmp3lame
 libnut
@@ -2154,6 +2156,7 @@ histeq_filter_deps="gpl"
 hqdn3d_filter_deps="gpl"
 hue_filter_deps="gpl"
 interlace_filter_deps="gpl"
+lua_filter_deps="liblua"
 kerndeint_filter_deps="gpl"
 mcdeint_filter_deps="avcodec gpl"
 movie_filter_deps="avcodec avformat"
@@ -4116,6 +4119,7 @@ enabled libgsm && { for gsm_hdr in "gsm.h" "gsm/gsm.h"; do
 check_lib "${gsm_hdr}" gsm_create -lgsm && break;
 done || die "ERROR: libgsm not found"; }
 enabled libilbc&& require  libilbc ilbc.h WebRtcIlbcfix_InitDecode -lilbc
+enabled liblua && require_pkg_config lua5.1 lua.h lua_newstate
 enabled libmodplug && require  libmodplug libmodplug/modplug.h ModPlug_Load -lmodplug
 enabled libmp3lame && require  "libmp3lame >= 3.98.3" lame/lame.h lame_set_VBR_quality -lmp3lame
 enabled libnut && require  libnut libnut.h nut_demuxer_init -lnut
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 2d2ea45..fdb5ce8 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -148,6 +148,7 @@ OBJS-$(CONFIG_IL_FILTER) += vf_il.o
 OBJS-$(CONFIG_INTERLACE_FILTER)  += vf_interlace.o
 OBJS-$(CONFIG_INTERLEAVE_FILTER) += f_interleave.o
 OBJS-$(CONFIG_KERNDEINT_FILTER)  += vf_kerndeint.o
+OBJS-$(CONFIG_LUA_FILTER)+= vf_lua.o
 OBJS-$(CONFIG_LUT3D_FILTER)  += vf_lut3d.o
 OBJS-$(CONFIG_LUT_FILTER)+= vf_lut.o
 OBJS-$(CONFIG_LUTRGB_FILTER) += vf_lut.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index f9d9391..10a1fb0 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -144,6 +144,7 @@ void 

Re: [FFmpeg-devel] [PATCH] lavc/lavf: transmit stream_id information for mpegts KLV data packets

[Stefano Sabatini]

On date Monday 2016-02-08 19:18:26 +0100, Stefano Sabatini encoded:
> On date Friday 2016-02-05 01:15:47 +0100, Marton Balint encoded:
> > 
> > On Thu, 4 Feb 2016, Stefano Sabatini wrote:
> > 
> > >On date Wednesday 2016-02-03 10:18:34 +0100, Stefano Sabatini encoded:
> > >[...]
> > >>Note: since my purpose is to allow remuxing KLV data, I can change
> > >>this to enable stream_id side-data only with data streams (so that no
> > >>reference must be changed).
> > >>
> > >>Since I have no strong opinion on this I'd change in case someone has
> > >>a preference.
> > 
> > I have no strong preference either. Unless it is a noticable
> > performance hit, I think it is fine to add the stream id to all
> > packets.
> > 
> > The mpegts demuxer part seems fine, one thing I may change is that
> > in new_pes_packet, you allocate the side data in the beginning of
> > the function after assigning pes->buffer to the packet buffer.
> > 
> > Probably it would be better if you could allocate the side data in
> > the end of the function, after setting pes->buffer to NULL so the
> > allocated buffer will not belong to both the pes->buf and pkt->buf,
> > therefore in case of ENOMEM at least we will have a chance of
> > freeing it properly.
> 
> Sure, good catch, patch updated.
> 
> No more comments, or is it fine to push?
> -- 
> FFmpeg = Funny and Frenzy Marvellous Puristic Epic God

> From 1dbf24a767c4909b254af7c679f91a5fd7fe81fb Mon Sep 17 00:00:00 2001
> From: Stefano Sabatini 
> Date: Wed, 18 Nov 2015 19:23:03 +0100
> Subject: [PATCH] lavc/lavf: transmit stream_id information for mpegts KLV data
>  packets
> 
> This allows to copy information related to the stream ID from the demuxer
> to the muxer, thus allowing for example to retain information related to
> synchronous and asynchronous KLV data packets. This information is used
> in the muxer when remuxing to distinguish the two kind of packets (if the
> information is lacking, data packets are considered sychronous).
> 
> The fate reference changes are due to the use of
> av_packet_merge_side_data(), which increases the size of the output
> packet size, since side data is merged into the packet data.
> ---
>  doc/APIchanges|   3 +
>  libavcodec/avcodec.h  |   6 ++
>  libavcodec/avpacket.c |   1 +
>  libavcodec/version.h  |   4 +-
>  libavformat/mpegts.c  |  31 +--
>  libavformat/mpegtsenc.c   |  26 --
>  tests/ref/fate/concat-demuxer-simple2-lavf-ts | 128 
> +-
>  tests/ref/seek/lavf-ts|  54 +--
>  8 files changed, 148 insertions(+), 105 deletions(-)

Someone else wants to have a look, or should I push as is?

[...]
-- 
FFmpeg = Fierce and Fiendish Meaningful Practical Educated Governor
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mux: do not fail in case of non monotonically increasing DTS values for data packets

[Stefano Sabatini]

On date Friday 2015-05-01 19:10:17 +0200, Stefano Sabatini encoded:
> On date Thursday 2015-04-30 16:24:08 +0200, Michael Niedermayer encoded:
> > On Thu, Apr 30, 2015 at 02:20:52PM +0200, Stefano Sabatini wrote:
> > > Disable monotonicity test for data packets. Data packets are not supposed
> > > to be decoded by FFmpeg, and this checks cause conversion failure with
> > > some files with non strictly monotonous timestamps.
> > > ---
> > >  libavformat/mux.c | 5 +++--
> > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > most muxers will not work with packets which arent ordered no matter
> > what type the packets are
> 
> Fine, I will drop the patch. The application level can take care of
> that if needed (by sorting the misordered packets).

I have an use case with data packets that have the same PTS (which
makes sense in that specific case). Since I want to fix this issue,
and dropping the check inconditionally may not be acceptable, I
propose the following variants:

* I add an option to drop strict monotonicity checks on data packets

* I enable a format level capability which disables the strict
  monotonicity requirement for data packets depending on the format

What do you find acceptable?
-- 
FFmpeg = Faithless Fantastic Most Prodigious Explosive Generator
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avutil/imgutils: av_image_get_buffer_size(): do not insert padding between stride*height and palette

[Michael Niedermayer]

This fixes the layout that is stored in pal8 nut with odd width*height

Signed-off-by: Michael Niedermayer 
---
 libavcodec/avpicture.c |2 ++
 libavutil/imgutils.c   |4 
 2 files changed, 6 insertions(+)

diff --git a/libavcodec/avpicture.c b/libavcodec/avpicture.c
index 56435f4..cac9287 100644
--- a/libavcodec/avpicture.c
+++ b/libavcodec/avpicture.c
@@ -51,6 +51,8 @@ int avpicture_layout(const AVPicture* src, enum AVPixelFormat 
pix_fmt, int width
 
 int avpicture_get_size(enum AVPixelFormat pix_fmt, int width, int height)
 {
+if (pix_fmt == AV_PIX_FMT_PAL8)
+return FFALIGN(width*height, 4) + 1024;
 return av_image_get_buffer_size(pix_fmt, width, height, 1);
 }
 
diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
index adf6fdd..976bd23 100644
--- a/libavutil/imgutils.c
+++ b/libavutil/imgutils.c
@@ -372,6 +372,10 @@ int av_image_get_buffer_size(enum AVPixelFormat pix_fmt,
 if (desc->flags & AV_PIX_FMT_FLAG_PSEUDOPAL)
 return FFALIGN(width, align) * height;
 
+// For paletted images we do not align the palette as in AVFrames
+if (desc->flags & AV_PIX_FMT_FLAG_PAL)
+return FFALIGN(width, align) * height + 1024;
+
 return av_image_fill_arrays(data, linesize, NULL, pix_fmt,
 width, height, align);
 }
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH 2/2] avutil/imgutils: only align the palette in av_image_copy_to_buffer() if there is enough space

[Michael Niedermayer]

On Sat, Feb 13, 2016 at 05:53:17PM +0100, Stefano Sabatini wrote:
> On date Saturday 2016-02-13 15:32:58 +0100, Michael Niedermayer encoded:
> > This allows disabling the alignment by using a compact buffer
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavutil/imgutils.c |5 +
> >  libavutil/version.h  |2 +-
> >  2 files changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
> > index 5c28703..adf6fdd 100644
> > --- a/libavutil/imgutils.c
> > +++ b/libavutil/imgutils.c
> > @@ -385,6 +385,7 @@ int av_image_copy_to_buffer(uint8_t *dst, int dst_size,
> >  int i, j, nb_planes = 0, linesize[4];
> >  int size = av_image_get_buffer_size(pix_fmt, width, height, align);
> >  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
> > +uint8_t *orig_dst = dst;
> >  
> >  if (size > dst_size || size < 0 || !desc)
> >  return AVERROR(EINVAL);
> > @@ -409,6 +410,10 @@ int av_image_copy_to_buffer(uint8_t *dst, int dst_size,
> >  
> 
> >  if (desc->flags & AV_PIX_FMT_FLAG_PAL) {
> >  uint32_t *d32 = (uint32_t *)(((size_t)dst + 3) & ~3);
> > +
> > +if (dst_size - 1024 < (uint8_t*)d32 - orig_dst)
> > +d32 = (uint32_t *)dst;
> > +
> 
> Do you have a specific use case for this?
> 
> [...]
> 

> LGTM. 

applied

thanks

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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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: only warn about hwaccel with frame threads

[Michael Niedermayer]

On Thu, Feb 11, 2016 at 11:59:31PM +0100, Michael Niedermayer wrote:
> On Mon, Feb 08, 2016 at 04:35:05PM -0500, Ronald S. Bultje wrote:
> > Hi,
> > 
> > On Tue, Jan 26, 2016 at 5:23 PM, Andreas Cadhalpun <
> > andreas.cadhal...@googlemail.com> wrote:
> > 
> > > On 25.01.2016 00:53, Hendrik Leppkes wrote:
> > > > On Sat, Jan 23, 2016 at 3:52 PM, Andreas Cadhalpun
> > > >  wrote:
> > > >> On 23.01.2016 15:10, Hendrik Leppkes wrote:
> > > >>> On Sat, Jan 23, 2016 at 2:45 PM, Ronald S. Bultje 
> > > wrote:
> > >  Both of you keep shouting from one side of the room to the other
> > > without
> > >  trying to actually converge to a point that might somehow be mutually
> > >  acceptable. I'm getting very grumbly here.
> > > 
> > > >>>
> > > >>> I'm not trying to be unreasonable here, all I'm asking for at this
> > > >>> point is to make sure the new vp9 hwaccel doesn't break spectacularly
> > > >>> when MT is turned on before its allowed back.
> > > >>
> > > >> OK, that would be fine with me.
> > > >>
> > > >> Do you agree that the attached patch is sufficient for this?
> > > >>
> > > >
> > > > YUV420P will not remain the only format available for hwaccel, I
> > > > already have some work pending to allow Profile2/10-bit as well, so
> > > > the check should be further out.
> > >
> > > OK. Though if Ronald manages to (hopefully soon) find a solution for
> > > automatically throttling the hwaccel threads to 1, this check will be
> > > removed again anyway.
> > >
> > > > It would also log every time the function executes, no matter if
> > > > hwaccel is requested or not, unfortunately I don't see a way to fix
> > > > that nicely since the decoder doesn't know if the user is going to
> > > > activate hwaccel.
> > >
> > > Indeed. But since that is anyway logged in setup_hwaccel there
> > > is not really much need for another warning here. I've thus reduced
> > > the log level to verbose. Attached is an updated patch.
> > 
> > 
> > See attached for what I had in mind, and along with this you can then
> > remove the current blocking code in libavcodec/utils.c which you're
> > complaining about.
> > 
> > So, this _sometimes_ works for dxva2/vp9, but it still fails sometimes.
> > Hendrik thinks it's related to dxva2 generic buffer handling, not
> > vp9-related anymore, and in line with that, it's indeed true that
> > h264/dxva2 hwaccel+threading fails also. vdpau hwaccel+mt works, but has no
> > vp9 so we can't confirm if vp9 is fine here. I haven't found anyone with
> > vaapi vp9 yet...
> > 
> > Hendrik is not against applying this, but the question is whether it's
> > helpful, because if you remove the libavcodec/utils.c block, mt+hwaccel for
> > dxva2 will fail again (easily reproduced with make THREADS=4 HWACCEL=dxva2
> > fate-h264/vp9 -k). Hendrik suggested possibly putting locks around the
> > dxva2 picture pool, but that's stupid. Also, this whole setup still doesn't
> > allow much room for adaptive fallback and delayed hw decoding (i.e. having
> > multiple buffers in the hw queue), since the hw is disabled without flush
> > as soon as we switch between hw and fallback...
> >
> > Ronald
> 
> >  vp9.c |   60 +++-
> >  1 file changed, 35 insertions(+), 25 deletions(-)
> > 84b2a1d29ea965ee24ef82b0de63c0f6b91e9af6  
> > 0001-vp9-only-call-ff_get_format-on-stream-format-changes.patch
> > From ec0a1e148d60a203a5bb82a8e9d7d3b97c5503dd Mon Sep 17 00:00:00 2001
> > From: "Ronald S. Bultje" 
> > Date: Mon, 8 Feb 2016 16:29:09 -0500
> > Subject: [PATCH] vp9: only call ff_get_format on stream format changes.
> > 
> > In practice, this means we don't call it N times for N-threaded decoding.
> 
> iam in favor of this patch
> multiple calls to ff_get_format() has lead to complaints in the past
> from developers of multiple applications IIRC
> 
> Also we should get some solution
> into git for FFmpeg 3.0 for the hwaccel-mt case.

applied after IRC approval by author

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes


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

Re: [FFmpeg-devel] [RFC][WIP][PATCH] avfilter: add luascript filter

[Paul B Mahol]

On 2/13/16, Stefano Sabatini  wrote:
> On date Thursday 2016-02-04 19:40:18 +0100, Paul B Mahol encoded:
>> On 2/2/16, Paul B Mahol  wrote:
>> > Hi,
>> >
>> > patch attached.
>> >
>>
>> Much more useful version attached.
>>
>> Simple demo demonstrating functionality currently missing in lavfi:
>
> I toyed with this idea three years ago, and I'll show you my (crappy)
> POC patch which assumes a different design (resuming: I wanted to
> implement a lua function to filter the media buffer, and possibly add
> other hooks to call during configuration).
>
> Sample lua script file:
>
> frame = 0
>
> function init()
>  print "hello world!"
>  print(l_sin(239))
> end
>
> function filter_frame()
>  print(string.format('frame number %d', frame))
>  frame = frame + 1
> end
>
> I gave up because I realized that with that approach I also needed to
> script most FFmpeg functions, that is I needed to script FFmpeg as a
> whole, which hugely extended the scope of the task.
>
>>
>> lavfi.log(0, "Lavfi script example", lavfi.script_name,
>> lavfi.frame_count(0));
>> if (lavfi.frame_count(0) >= 50) then
>> lavfi.filter({"aa"}, "vflip", nil, {"a"})
>> lavfi.filter({"bb"}, "hflip", nil, {"b"})
>> else
>> lavfi.filter({"aa"}, "negate", nil, {"a"})
>> lavfi.filter({"bb"}, "vflip",  nil, {"b"})
>> end
>>
>> lavfi.filter({"a", "b"}, "hstack", "2", {"out0"});
>
> Can you shortly give a description of how this code interface with lua?
> (alternatively write docs, assuming you plan to land a committable version)

It just recreates different filtergraph depending on what lua executes,
pretty dumb really.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads

[Michael Niedermayer]

On Sat, Jan 23, 2016 at 11:42:54AM +0100, Hendrik Leppkes wrote:
> On Sat, Jan 23, 2016 at 10:12 AM, Andreas Cadhalpun
>  wrote:
> > VLC uses hwaccel with frame threads and it works fine, but returning
> > an error here made it fail.
> >
> > This regression was introduced in commit 31741ae.
> >
> 
> I'm still opposed to this, and so is everyone else that commented on the 
> issue.
> Also, the vp9 hwaccel will most definitely misbehave with MT, so this
> one needs to be re-factored before MT is allowed at the very least.

vp9 has been fixed

from IRC:

 BBB, can the vp9 & hwaccel-mt patches be applied or is there a 
reason to wait ?
 no reason to wait, can be applied
 sorry, I haven’t kept track very closely of that patch
 I can apply if you want, but it’s probably faster if you merge for me
 I believe with that patch, we can revert the previous patch that 
prevented mt+hwaccel, as andreas requested
 it will still not work for dxva2, but that’s unrelated to vp9 since it 
fails for h264 also
 i can apply the patchs, i just dont want to step on anyones toes, 
the vp9 one seems clear but which is the 2nd one, the one from anreas that 
changes it to a warning or revert 31741ae ?

just want to make double sure i dont step on anyones toes, thus asking
on the ML here too before applying the patch

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

It is what and why we do it that matters, not just one of them.


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

Re: [FFmpeg-devel] [PATCH] avutil/imgutils: av_image_get_buffer_size(): do not insert padding between stride*height and palette

[wm4]

On Sat, 13 Feb 2016 19:38:01 +0100
Michael Niedermayer  wrote:

> This fixes the layout that is stored in pal8 nut with odd width*height
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/avpicture.c |2 ++
>  libavutil/imgutils.c   |4 
>  2 files changed, 6 insertions(+)
> 
> diff --git a/libavcodec/avpicture.c b/libavcodec/avpicture.c
> index 56435f4..cac9287 100644
> --- a/libavcodec/avpicture.c
> +++ b/libavcodec/avpicture.c
> @@ -51,6 +51,8 @@ int avpicture_layout(const AVPicture* src, enum 
> AVPixelFormat pix_fmt, int width
>  
>  int avpicture_get_size(enum AVPixelFormat pix_fmt, int width, int height)
>  {
> +if (pix_fmt == AV_PIX_FMT_PAL8)
> +return FFALIGN(width*height, 4) + 1024;
>  return av_image_get_buffer_size(pix_fmt, width, height, 1);
>  }
>  
> diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
> index adf6fdd..976bd23 100644
> --- a/libavutil/imgutils.c
> +++ b/libavutil/imgutils.c
> @@ -372,6 +372,10 @@ int av_image_get_buffer_size(enum AVPixelFormat pix_fmt,
>  if (desc->flags & AV_PIX_FMT_FLAG_PSEUDOPAL)
>  return FFALIGN(width, align) * height;
>  
> +// For paletted images we do not align the palette as in AVFrames
> +if (desc->flags & AV_PIX_FMT_FLAG_PAL)
> +return FFALIGN(width, align) * height + 1024;
> +
>  return av_image_fill_arrays(data, linesize, NULL, pix_fmt,
>  width, height, align);
>  }

It seems wrong to litter the code with specific checks for an obscure
pixel format, and change behavior, just to make these function's
behavior line up with what NUT needs?

It's also possible that this is actually what the API user wants; there
are many implications.

Also, is this consistent with av_image_fill_arrays etc.?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/lavf: transmit stream_id information for mpegts KLV data packets

[Marton Balint]

On Sat, 13 Feb 2016, Stefano Sabatini wrote:


Subject: [PATCH] lavc/lavf: transmit stream_id information for mpegts KLV data
 packets



[...]


Someone else wants to have a look, or should I push as is?


I had a look at the mpegtsenc part as well:


--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c


[...]


@@ -1451,6 +1456,15 @@ static int mpegts_write_packet_internal(AVFormatContext 
*s, AVPacket *pkt)
 const int64_t delay = av_rescale(s->max_delay, 9, AV_TIME_BASE) * 2;
 int64_t dts = pkt->dts, pts = pkt->pts;
 int opus_samples = 0;
+int side_data_size;
+char *side_data = NULL;
+int stream_id = 0;


Why don't you use -1 as undefined? Theoretically stream_id can be zero 
as well, can't it?


Otherwise it is LGTM. I think you waited long enough, feel free to push.

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

[FFmpeg-devel] [PATCH v2 2/2] lavc/ccaption_dec: implement special and extended character sets

[Aman Gupta]

From: Aman Gupta 

character sets implemented as defined in 
https://en.wikipedia.org/wiki/EIA-608#Characters
---
 libavcodec/ccaption_dec.c | 152 +-
 1 file changed, 149 insertions(+), 3 deletions(-)

diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
index 5fb2ec6..fc361b2 100644
--- a/libavcodec/ccaption_dec.c
+++ b/libavcodec/ccaption_dec.c
@@ -63,6 +63,116 @@ enum cc_font {
 CCFONT_UNDERLINED_ITALICS,
 };
 
+enum cc_charset {
+CCSET_BASIC_AMERICAN,
+CCSET_SPECIAL_AMERICAN,
+CCSET_EXTENDED_SPANISH_FRENCH_MISC,
+CCSET_EXTENDED_PORTUGUESE_GERMAN_DANISH,
+};
+
+static const char *charset_overrides[4][128] =
+{
+[CCSET_BASIC_AMERICAN] = {
+[0x27] = "’",
+[0x2a] = "á",
+[0x5c] = "é",
+[0x5e] = "í",
+[0x5f] = "ó",
+[0x60] = "ú",
+[0x7b] = "ç",
+[0x7c] = "÷",
+[0x7d] = "Ñ",
+[0x7e] = "ñ",
+[0x7f] = "\u2588"
+},
+[CCSET_SPECIAL_AMERICAN] = {
+[0x30] = "®",
+[0x31] = "°",
+[0x32] = "½",
+[0x33] = "¿",
+[0x34] = "™",
+[0x35] = "¢",
+[0x36] = "£",
+[0x37] = "♪",
+[0x38] = "à",
+[0x39] = "\u00A0",
+[0x3a] = "è",
+[0x3b] = "â",
+[0x3c] = "ê",
+[0x3d] = "î",
+[0x3e] = "ô",
+[0x3f] = "û",
+},
+[CCSET_EXTENDED_SPANISH_FRENCH_MISC] = {
+[0x20] = "Á",
+[0x21] = "É",
+[0x22] = "Ó",
+[0x23] = "Ú",
+[0x24] = "Ü",
+[0x25] = "ü",
+[0x26] = "´",
+[0x27] = "¡",
+[0x28] = "*",
+[0x29] = "‘",
+[0x2a] = "-",
+[0x2b] = "©",
+[0x2c] = "℠",
+[0x2d] = "·",
+[0x2e] = "“",
+[0x2f] = "”",
+[0x30] = "À",
+[0x31] = "Â",
+[0x32] = "Ç",
+[0x33] = "È",
+[0x34] = "Ê",
+[0x35] = "Ë",
+[0x36] = "ë",
+[0x37] = "Î",
+[0x38] = "Ï",
+[0x39] = "ï",
+[0x3a] = "Ô",
+[0x3b] = "Ù",
+[0x3c] = "ù",
+[0x3d] = "Û",
+[0x3e] = "«",
+[0x3f] = "»",
+},
+[CCSET_EXTENDED_PORTUGUESE_GERMAN_DANISH] = {
+[0x20] = "Ã",
+[0x21] = "ã",
+[0x22] = "Í",
+[0x23] = "Ì",
+[0x24] = "ì",
+[0x25] = "Ò",
+[0x26] = "ò",
+[0x27] = "Õ",
+[0x28] = "õ",
+[0x29] = "{",
+[0x2a] = "}",
+[0x2b] = "\\",
+[0x2c] = "^",
+[0x2d] = "_",
+[0x2e] = "|",
+[0x2f] = "~",
+[0x30] = "Ä",
+[0x31] = "ä",
+[0x32] = "Ö",
+[0x33] = "ö",
+[0x34] = "ß",
+[0x35] = "¥",
+[0x36] = "¤",
+[0x37] = "¦",
+[0x38] = "Å",
+[0x39] = "å",
+[0x3a] = "Ø",
+[0x3b] = "ø",
+[0x3c] = "┌",
+[0x3d] = "┐",
+[0x3e] = "└",
+[0x3f] = "┘",
+},
+};
+
 static const unsigned char pac2_attribs[32][3] = // Color, font, ident
 {
 { CCCOL_WHITE,   CCFONT_REGULAR,0 },  // 0x40 || 0x60
@@ -103,6 +213,7 @@ static const unsigned char pac2_attribs[32][3] = // Color, 
font, ident
 struct Screen {
 /* +1 is used to compensate null character of string */
 uint8_t characters[SCREEN_ROWS][SCREEN_COLUMNS+1];
+uint8_t charsets[SCREEN_ROWS][SCREEN_COLUMNS+1];
 uint8_t colors[SCREEN_ROWS][SCREEN_COLUMNS+1];
 uint8_t fonts[SCREEN_ROWS][SCREEN_COLUMNS+1];
 /*
@@ -123,6 +234,7 @@ typedef struct CCaptionSubContext {
 uint8_t cursor_column;
 uint8_t cursor_color;
 uint8_t cursor_font;
+uint8_t cursor_charset;
 AVBPrint buffer;
 int buffer_changed;
 int rollup;
@@ -189,6 +301,7 @@ static void flush_decoder(AVCodecContext *avctx)
 ctx->cursor_column = 0;
 ctx->cursor_font = 0;
 ctx->cursor_color = 0;
+ctx->cursor_charset = 0;
 ctx->active_screen = 0;
 ctx->last_real_time = 0;
 ctx->screen_touched = 0;
@@ -204,10 +317,13 @@ static int write_char(CCaptionSubContext *ctx, struct 
Screen *screen, char ch)
 uint8_t col = ctx->cursor_column;
 char *row = screen->characters[ctx->cursor_row];
 char *font = screen->fonts[ctx->cursor_row];
+char *charset = screen->charsets[ctx->cursor_row];
 
 if (col < SCREEN_COLUMNS) {
 row[col] = ch;
 font[col] = ctx->cursor_font;
+charset[col] = ctx->cursor_charset;
+ctx->cursor_charset = CCSET_BASIC_AMERICAN;
 if (ch) ctx->cursor_column++;
 return 0;
 }
@@ -306,6 +422,7 @@ static void roll_up(CCaptionSubContext *ctx)
 memcpy(screen->characters[i_row], screen->characters[i_row+1], 
SCREEN_COLUMNS);
 memcpy(screen->colors[i_row], screen->colors[i_row+1], SCREEN_COLUMNS);
 memcpy(screen->fonts[i_row], screen->fonts[i_row+1], SCREEN_COLUMNS);
+memcpy(screen->charsets[i_row], 

[FFmpeg-devel] [PATCH v2 1/2] lavc/ccaption_dec: do not ignore repeated character commands

[Aman Gupta]

From: Aman Gupta 

control codes in a cc stream can be repeated, and must be ignored.
however, repeated characters must not be ignored. the code attempted to
wipe prev_cmd in handle_char to allow repeated characters to be
processed, but prev_cmd would previously get reset _after_ handle_char()

i also moved the prev_cmd reset out from handle_char() so it can be
re-used for special character sets, which _must_ be ignored when
repeated.
---
 libavcodec/ccaption_dec.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
index 790f071..5fb2ec6 100644
--- a/libavcodec/ccaption_dec.c
+++ b/libavcodec/ccaption_dec.c
@@ -484,9 +484,6 @@ static void handle_char(CCaptionSubContext *ctx, char hi, 
char lo, int64_t pts)
 if (ctx->mode != CCMODE_POPON)
 ctx->screen_touched = 1;
 
-/* reset prev command since character can repeat */
-ctx->prev_cmd[0] = 0;
-ctx->prev_cmd[1] = 0;
 if (lo)
ff_dlog(ctx, "(%c,%c)\n", hi, lo);
 else
@@ -497,8 +494,15 @@ static void process_cc608(CCaptionSubContext *ctx, int64_t 
pts, uint8_t hi, uint
 {
 if (hi == ctx->prev_cmd[0] && lo == ctx->prev_cmd[1]) {
 /* ignore redundant command */
-} else if ( (hi == 0x10 && (lo >= 0x40 && lo <= 0x5f)) ||
-  ( (hi >= 0x11 && hi <= 0x17) && (lo >= 0x40 && lo <= 0x7f) ) ) {
+return;
+}
+
+/* set prev command */
+ctx->prev_cmd[0] = hi;
+ctx->prev_cmd[1] = lo;
+
+if ( (hi == 0x10 && (lo >= 0x40 && lo <= 0x5f)) ||
+   ( (hi >= 0x11 && hi <= 0x17) && (lo >= 0x40 && lo <= 0x7f) ) ) {
 handle_pac(ctx, hi, lo);
 } else if ( ( hi == 0x11 && lo >= 0x20 && lo <= 0x2f ) ||
 ( hi == 0x17 && lo >= 0x2e && lo <= 0x2f) ) {
@@ -559,14 +563,11 @@ static void process_cc608(CCaptionSubContext *ctx, 
int64_t pts, uint8_t hi, uint
 } else if (hi >= 0x20) {
 /* Standard characters (always in pairs) */
 handle_char(ctx, hi, lo, pts);
+ctx->prev_cmd[0] = ctx->prev_cmd[1] = 0;
 } else {
 /* Ignoring all other non data code */
 ff_dlog(ctx, "Unknown command 0x%hhx 0x%hhx\n", hi, lo);
 }
-
-/* set prev command */
-ctx->prev_cmd[0] = hi;
-ctx->prev_cmd[1] = lo;
 }
 
 static int decode(AVCodecContext *avctx, void *data, int *got_sub, AVPacket 
*avpkt)
-- 
2.5.3

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

Re: [FFmpeg-devel] [PATCH v2 2/2] lavc/ccaption_dec: implement special and extended character sets

[Clément Bœsch]

On Sat, Feb 13, 2016 at 12:35:18PM -0800, Aman Gupta wrote:
[...]
> +static const char *charset_overrides[4][128] =
> +{
> +[CCSET_BASIC_AMERICAN] = {
> +[0x27] = "’",
> +[0x2a] = "á",
> +[0x5c] = "é",
> +[0x5e] = "í",
> +[0x5f] = "ó",
> +[0x60] = "ú",
> +[0x7b] = "ç",
> +[0x7c] = "÷",
> +[0x7d] = "Ñ",
> +[0x7e] = "ñ",
> +[0x7f] = "\u2588"
> +},
> +[CCSET_SPECIAL_AMERICAN] = {
> +[0x30] = "®",
> +[0x31] = "°",
> +[0x32] = "½",
> +[0x33] = "¿",
> +[0x34] = "™",
> +[0x35] = "¢",
> +[0x36] = "£",
> +[0x37] = "♪",
> +[0x38] = "à",
> +[0x39] = "\u00A0",
> +[0x3a] = "è",
> +[0x3b] = "â",
> +[0x3c] = "ê",
> +[0x3d] = "î",
> +[0x3e] = "ô",
> +[0x3f] = "û",
> +},
[...]

I'm not exactly comfortable about using an implicit coding in the code
itself... I feel like some character encoding at some random level (editor
sender side, mail sender side, mail receiver side, ...) could mess up the
encoding one way or another. Would you mind using the \u form everywhere?

[...]

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] avutil/imgutils: av_image_get_buffer_size(): do not insert padding between stride*height and palette

[Michael Niedermayer]

On Sat, Feb 13, 2016 at 08:46:34PM +0100, wm4 wrote:
> On Sat, 13 Feb 2016 19:38:01 +0100
> Michael Niedermayer  wrote:
> 
> > This fixes the layout that is stored in pal8 nut with odd width*height
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/avpicture.c |2 ++
> >  libavutil/imgutils.c   |4 
> >  2 files changed, 6 insertions(+)
> > 
> > diff --git a/libavcodec/avpicture.c b/libavcodec/avpicture.c
> > index 56435f4..cac9287 100644
> > --- a/libavcodec/avpicture.c
> > +++ b/libavcodec/avpicture.c
> > @@ -51,6 +51,8 @@ int avpicture_layout(const AVPicture* src, enum 
> > AVPixelFormat pix_fmt, int width
> >  
> >  int avpicture_get_size(enum AVPixelFormat pix_fmt, int width, int height)
> >  {
> > +if (pix_fmt == AV_PIX_FMT_PAL8)
> > +return FFALIGN(width*height, 4) + 1024;
> >  return av_image_get_buffer_size(pix_fmt, width, height, 1);
> >  }
> >  
> > diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
> > index adf6fdd..976bd23 100644
> > --- a/libavutil/imgutils.c
> > +++ b/libavutil/imgutils.c
> > @@ -372,6 +372,10 @@ int av_image_get_buffer_size(enum AVPixelFormat 
> > pix_fmt,
> >  if (desc->flags & AV_PIX_FMT_FLAG_PSEUDOPAL)
> >  return FFALIGN(width, align) * height;
> >  
> > +// For paletted images we do not align the palette as in AVFrames
> > +if (desc->flags & AV_PIX_FMT_FLAG_PAL)
> > +return FFALIGN(width, align) * height + 1024;
> > +
> >  return av_image_fill_arrays(data, linesize, NULL, pix_fmt,
> >  width, height, align);
> >  }
> 
> It seems wrong to litter the code with specific checks for an obscure
> pixel format, and change behavior, just to make these function's
> behavior line up with what NUT needs?

I think my commit message was poorly worded

we need to either fix the code or fix/clarify the documentation

av_image_get_buffer_size() is documented as

 * Return the size in bytes of the amount of data required to store an
 * image with the given parameters.

it does not do this, after the patch it does.

the docs could be changed to something like:

 * Return the size in bytes of the amount of data required to store an
 * image with the given parameters. Except for PAL8 where the size is
 * rounded up to the next multiple of 4 even if the user asks for
 * less alignment

and likely there are other ways it could be documented


> 
> It's also possible that this is actually what the API user wants; there
> are many implications.

yes, that is possible, should i add a av_image_get_buffer_size2() ?
but iam not sure what use av_image_get_buffer_size() has then
in its current form
its not the AVFrame required size and its not the storage size in
any container (for all pixel formats) i think, either would have
exceptions

> 
> Also, is this consistent with av_image_fill_arrays etc.?

no, and that also was not teh case before the patch. for example
av_image_fill_arrays() sets pointers up for pseudopal formats
that would be outside the array space given from
av_image_get_buffer_size()

maybe stefano could comment as i think he wrote a lot of this

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

Re: [FFmpeg-devel] Fwd: Fwd: libavformat/segment : add option to increment timecode

[Martin Vignali]

2016-02-08 20:04 GMT+01:00 Stefano Sabatini :

> On date Friday 2016-02-05 11:41:06 +0100, Martin Vignali encoded:
> > 2016-01-30 10:44 GMT+01:00 Stefano Sabatini :
> >
> > > On date Friday 2016-01-29 17:38:13 +0100, Martin Vignali encoded:
> > > > 2016-01-29 12:35 GMT+01:00 Stefano Sabatini :
> > > [...]
> > > > > +AVDictionaryEntry * tcr = av_dict_get(s->metadata,
> "timecode",
> > > > > NULL, 0);
> > > > > > +if (tcr){
> > > > > > +if (s->nb_streams > 0){
> > > > >
> > > > > > +rate = s->streams[0]->avg_frame_rate;//Get fps
> from
> > > > > first stream
> > > > >
> > > > > this looks a bit arbitrary, why the first stream?
> > > > >
> > > > > > +err = av_timecode_init_from_string(, rate,
> > > > > tcr->value, s);
> > > > > > +if (err < 0)
> > > > > > +return err;
> > > > >
> > > > > > +tc.start += (int)(seg->time / 100.) *
> > > > > av_q2d(rate);//second count * fps
> > > > >
> > > > > You're losing precision here. Consider using the rescaling
> utilities
> > > > > in libavutil/mathematics.h or something like (seg->time *
> rate.num) /
> > > > > (rate.den * 100).
> > > [...]
> > > > Thanks you for your comments, i will make the modifications.
> > > >
> > > > For the fps issue, you're right, i use the first stream because in my
> > > tests
> > > > it's always the video stream.
> > > > Is there a better way, to get fps ? without choosing one of the
> stream ?
> > >
> > > My guess is that timecode is always related to a video stream, right?
> > >
> > > In this case you can loop through the streams and select the first
> > > video stream (check also the select_reference_stream() function in
> > > segment.c).
> > >
> > >
> > I follow your proposal, and search the first video stream, to take fps.
> >
> > In attach the new patch (and a documentation).
> >
> > Best regards
> >
> > Martin
> >
> >
> >
> > ping
>
> > From c266385a63b5f768e484e0aaccfa27de1f870663 Mon Sep 17 00:00:00 2001
> > From: Martin Vignali 
> > Date: Sat, 30 Jan 2016 20:52:54 +0100
> > Subject: [PATCH 1/2] add increment timecode option using segment v2
>
> Nit: lavf/segment: add increment timecode option
>
> You could describe a use case in the log (optional).
>
> >
> > ---
> >  libavformat/segment.c | 29 +
> >  1 file changed, 29 insertions(+)
> >
> > diff --git a/libavformat/segment.c b/libavformat/segment.c
> > index 9da5168..933abd1 100644
> > --- a/libavformat/segment.c
> > +++ b/libavformat/segment.c
> > @@ -40,6 +40,7 @@
> >  #include "libavutil/parseutils.h"
> >  #include "libavutil/mathematics.h"
> >  #include "libavutil/time.h"
> > +#include "libavutil/timecode.h"
> >  #include "libavutil/time_internal.h"
> >  #include "libavutil/timestamp.h"
> >
> > @@ -94,6 +95,7 @@ typedef struct SegmentContext {
> >  char *time_str;///< segment duration specification string
> >  int64_t time;  ///< segment duration
> >  int use_strftime;  ///< flag to expand filename with strftime
> > +int increment_tc;  ///< flag to increment timecode if found
> >
> >  char *times_str;   ///< segment times specification string
> >  int64_t *times;///< list of segment interval specification
> > @@ -223,6 +225,32 @@ static int segment_start(AVFormatContext *s, int
> write_header)
> >  SegmentContext *seg = s->priv_data;
> >  AVFormatContext *oc = seg->avf;
> >  int err = 0;
> > +AVTimecode tc;
> > +AVRational rate;
> > +int i;
> > +
> > +if (seg->increment_tc) {
> > +AVDictionaryEntry * tcr = av_dict_get(s->metadata, "timecode",
> NULL, 0);
>
> nit: *tcr
>
> > +if (tcr) {
> > +/* search the first video stream */
> > +for (i = 0; i < s->nb_streams; i++) {
> > +if (s->streams[i]->codec->codec_type ==
> AVMEDIA_TYPE_VIDEO) {
> > +rate = s->streams[i]->avg_frame_rate;/* Get fps
> from the video stream */
> > +err = av_timecode_init_from_string(, rate,
> tcr->value, s);
> > +if (err < 0)
> > +return err;
>
> > +tc.start += (seg->time * rate.num) / (rate.den
> > * 100);/* increment timecode */
>
> This can overflow (yes I know you literally used my own
> suggestion). You can use av_mul_q() to avoid that, or cast to floating
> point numbers before the multiplication.
>
> > +char buf[AV_TIMECODE_STR_SIZE];
> > +av_dict_set(>metadata, "timecode",
> > +av_timecode_make_string(, buf, 0),
> 0);/* Set the new tc. */
> > +break;
> > +}
> > +}
>
> Please drop the comments in this section, since the code is
> self-evident.
>
> > +}
> > +else{
> > +av_log(s, 

Re: [FFmpeg-devel] [PATCH] libavdevice/dshow.c: Correct CoGetMalloc check

[Michael Niedermayer]

On Sat, Feb 13, 2016 at 05:23:27PM +0100, FearThe1337 wrote:
> Fixes a typo in a return code conditional check.

>  dshow.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> f75116cffe806352539bc5a90dc8fb3365a4a26e  
> 0001-libavdevice-dshow.c-Correct-CoGetMalloc-check.patch
> From 678cbd8a78e28e19de7644dcbb75088e2b2400bf Mon Sep 17 00:00:00 2001
> From: FearThe1337 
> Date: Sat, 13 Feb 2016 16:55:02 +0100
> Subject: [PATCH] libavdevice/dshow.c: Correct CoGetMalloc check
> 
> Current if statement would always be false due to assigning the value of
> S_OK which equals 0.

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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

Re: [FFmpeg-devel] [PATCH] avutil/imgutils: av_image_get_buffer_size(): do not insert padding between stride*height and palette

[wm4]

On Sat, 13 Feb 2016 21:51:48 +0100
Michael Niedermayer  wrote:

> On Sat, Feb 13, 2016 at 08:46:34PM +0100, wm4 wrote:
> > On Sat, 13 Feb 2016 19:38:01 +0100
> > Michael Niedermayer  wrote:
> >   
> > > This fixes the layout that is stored in pal8 nut with odd width*height
> > > 
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  libavcodec/avpicture.c |2 ++
> > >  libavutil/imgutils.c   |4 
> > >  2 files changed, 6 insertions(+)
> > > 
> > > diff --git a/libavcodec/avpicture.c b/libavcodec/avpicture.c
> > > index 56435f4..cac9287 100644
> > > --- a/libavcodec/avpicture.c
> > > +++ b/libavcodec/avpicture.c
> > > @@ -51,6 +51,8 @@ int avpicture_layout(const AVPicture* src, enum 
> > > AVPixelFormat pix_fmt, int width
> > >  
> > >  int avpicture_get_size(enum AVPixelFormat pix_fmt, int width, int height)
> > >  {
> > > +if (pix_fmt == AV_PIX_FMT_PAL8)
> > > +return FFALIGN(width*height, 4) + 1024;
> > >  return av_image_get_buffer_size(pix_fmt, width, height, 1);
> > >  }
> > >  
> > > diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
> > > index adf6fdd..976bd23 100644
> > > --- a/libavutil/imgutils.c
> > > +++ b/libavutil/imgutils.c
> > > @@ -372,6 +372,10 @@ int av_image_get_buffer_size(enum AVPixelFormat 
> > > pix_fmt,
> > >  if (desc->flags & AV_PIX_FMT_FLAG_PSEUDOPAL)
> > >  return FFALIGN(width, align) * height;
> > >  
> > > +// For paletted images we do not align the palette as in AVFrames
> > > +if (desc->flags & AV_PIX_FMT_FLAG_PAL)
> > > +return FFALIGN(width, align) * height + 1024;
> > > +
> > >  return av_image_fill_arrays(data, linesize, NULL, pix_fmt,
> > >  width, height, align);
> > >  }  
> > 
> > It seems wrong to litter the code with specific checks for an obscure
> > pixel format, and change behavior, just to make these function's
> > behavior line up with what NUT needs?  
> 
> I think my commit message was poorly worded
> 
> we need to either fix the code or fix/clarify the documentation
> 
> av_image_get_buffer_size() is documented as
> 
>  * Return the size in bytes of the amount of data required to store an
>  * image with the given parameters.
> 
> it does not do this, after the patch it does.
> 
> the docs could be changed to something like:
> 
>  * Return the size in bytes of the amount of data required to store an
>  * image with the given parameters. Except for PAL8 where the size is
>  * rounded up to the next multiple of 4 even if the user asks for
>  * less alignment
> 
> and likely there are other ways it could be documented

Why 4?

Also, why do av_image_get_buffer_size() and avpicture_get_size() do
different things?

I'd totally expect each line _and_ the start of the palette to be
aligned to the requested slignment.

> 
> > 
> > It's also possible that this is actually what the API user wants; there
> > are many implications.  
> 
> yes, that is possible, should i add a av_image_get_buffer_size2() ?

Either that or a minor bump and a warning in APIchanges, depending on
how this plays out.

> but iam not sure what use av_image_get_buffer_size() has then
> in its current form
> its not the AVFrame required size and its not the storage size in
> any container (for all pixel formats) i think, either would have
> exceptions

Maybe one could argue that it shouldn't include the palette? It's kind
of a special case, and many uses do not store the palette directly along
with the image data, but somewhere else.

> 
> > 
> > Also, is this consistent with av_image_fill_arrays etc.?  
> 
> no, and that also was not teh case before the patch. for example
> av_image_fill_arrays() sets pointers up for pseudopal formats
> that would be outside the array space given from
> av_image_get_buffer_size()

I thought these functions build on each other: one to get the buffer
size, and another one to get the offsets into the buffer. Does it make
sense that they are not consistent?

> 
> maybe stefano could comment as i think he wrote a lot of this
> 
> [...]
> 

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

[FFmpeg-devel] [PATCH] checkasm: Add vf_blend tests

[Timothy Gu]

---
 tests/checkasm/Makefile   |   1 +
 tests/checkasm/checkasm.c |   3 ++
 tests/checkasm/checkasm.h |   1 +
 tests/checkasm/vf_blend.c | 130 ++
 4 files changed, 135 insertions(+)
 create mode 100644 tests/checkasm/vf_blend.c

diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index 07fe5bc..bfd7c11 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -1,5 +1,6 @@
 # libavcodec tests
 AVCODECOBJS-$(CONFIG_ALAC_DECODER) += alacdsp.o
+AVCODECOBJS-$(CONFIG_BLEND_FILTER) += vf_blend.o
 AVCODECOBJS-$(CONFIG_BSWAPDSP) += bswapdsp.o
 AVCODECOBJS-$(CONFIG_DCA_DECODER) += synth_filter.o
 AVCODECOBJS-$(CONFIG_FLACDSP)  += flacdsp.o
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index 49fd2af..1e73e34 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -68,6 +68,9 @@ static const struct {
 #if CONFIG_ALAC_DECODER
 { "alacdsp", checkasm_check_alacdsp },
 #endif
+#if CONFIG_BLEND_FILTER
+{ "vf_blend", checkasm_check_blend },
+#endif
 #if CONFIG_BSWAPDSP
 { "bswapdsp", checkasm_check_bswapdsp },
 #endif
diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
index 5c07f89..0c8bc2d 100644
--- a/tests/checkasm/checkasm.h
+++ b/tests/checkasm/checkasm.h
@@ -31,6 +31,7 @@
 #include "libavutil/timer.h"
 
 void checkasm_check_alacdsp(void);
+void checkasm_check_blend(void);
 void checkasm_check_bswapdsp(void);
 void checkasm_check_flacdsp(void);
 void checkasm_check_fmtconvert(void);
diff --git a/tests/checkasm/vf_blend.c b/tests/checkasm/vf_blend.c
new file mode 100644
index 000..51e1391
--- /dev/null
+++ b/tests/checkasm/vf_blend.c
@@ -0,0 +1,130 @@
+/*
+ * Copyright (c) 2016 Tiancheng "Timothy" Gu
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with FFmpeg; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include 
+#include "checkasm.h"
+#include "libavfilter/blend.h"
+#include "libavutil/common.h"
+#include "libavutil/internal.h"
+#include "libavutil/intreadwrite.h"
+
+#define WIDTH 256
+#define HEIGHT 256
+#define BUF_UNITS 9
+#define SIZE_PER_UNIT (WIDTH * HEIGHT)
+#define BUF_SIZE (BUF_UNITS * SIZE_PER_UNIT)
+
+#define randomize_buffers()   \
+do {  \
+int i, j; \
+for (i = 0; i < HEIGHT; i++) {\
+for (j = 0; j < WIDTH; j++) { \
+top1[i * WIDTH + j] = \
+top2[i * WIDTH + j] = i;  \
+bot1[i * WIDTH + j] = \
+bot2[i * WIDTH + j] = j;  \
+} \
+} \
+for (i = 0; i < SIZE_PER_UNIT; i += 4) { \
+uint32_t r = rnd();   \
+AV_WN32A(dst1 + i, r);\
+AV_WN32A(dst2 + i, r);\
+} \
+for (; i < BUF_SIZE; i += 4) {\
+uint32_t r = rnd();   \
+AV_WN32A(top1 + i, r);\
+AV_WN32A(top2 + i, r);\
+r = rnd();\
+AV_WN32A(bot1 + i, r);\
+AV_WN32A(bot2 + i, r);\
+r = rnd();\
+AV_WN32A(dst1 + i, r);\
+AV_WN32A(dst2 + i, r);\
+} \
+} while (0)
+
+#define check_blend_func() 
\
+do {   
\
+int i; 
\
+declare_func(void, const uint8_t *top, ptrdiff_t top_linesize, 
\
+ const uint8_t *bottom, ptrdiff_t bottom_linesize, 
\
+ uint8_t *dst, ptrdiff_t dst_linesize, 
\
+ ptrdiff_t width, ptrdiff_t start, ptrdiff_t end,  
\
+ struct FilterParams *param, double *values);  
\
+

Re: [FFmpeg-devel] [PATCH] lavc/hevc Parse SEI_TYPE_MASTERING_DISPLAY_INFO and propagate contents into the AVMasteringDisplayMetadata side data.

[Michael Niedermayer]

On Mon, Feb 08, 2016 at 09:36:42AM -0800, Neil Birkbeck wrote:
> I'm sending an updated patch that persists the data within the CVS
> (between IRAP access units with no_rasl_output_flag=1). If this seems
> like overkill, we can fallback to Hendrik's suggestion of just sending
> it once. I did consider this alternative but figured the side data
> could get lost if some frames were dropped in some part of the filter
> chain.
> 
> 
> On Thu, Feb 4, 2016 at 11:04 PM, Hendrik Leppkes  wrote:
> > On Fri, Feb 5, 2016 at 3:05 AM, Neil Birkbeck  
> > wrote:
> >> According to the ITU-T H.265 v3, in Table D - 1, the persistence scope
> >> of the mastering display metadata is "The Coded Video Sequence (CVS)
> >> containing the SEI message". So I guess we want to clear when we start
> >> the next CVS, so I guess when we see the next IDR frame.
> >>
> >> Given that the SEI comes before the IDR, I don't see a great way to do
> >> this aside from initializing the flag to 2 and decrementing (when > 0)
> >> when we see an IDR.
> >>
> >
> > The usual way I would handle such SEI metadata is just to send the
> > sidedata once when it appears in the bitstream and not repeat it with
> > every single frame, and let the user worry about its lifetime.
> >
> > - Hendrik
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

>  hevc.c |   52 
>  hevc.h |7 +++
>  hevc_sei.c |   26 ++
>  version.h  |2 +-
>  4 files changed, 86 insertions(+), 1 deletion(-)
> 6b6743db49b2982e684f6ef2df94d336bae76947  
> 0001-lavc-hevc-Parse-SEI_TYPE_MASTERING_DISPLAY_INFO-and-.patch
> From e6602d1191a9166e5a38c4c27b430fbe0b84aeca Mon Sep 17 00:00:00 2001
> From: Neil Birkbeck 
> Date: Thu, 21 Jan 2016 10:56:50 -0800
> Subject: [PATCH] lavc/hevc Parse SEI_TYPE_MASTERING_DISPLAY_INFO and propagate
>  content into the AVMasteringDisplayMetadata side data.
> 
> Add support for parsing SEI_TYPE_MASTERING_DISPLAY_INFO and propagate 
> contents into
> the AVMasteringDisplayMetadata side data. Primaries are ordered in RGB order 
> and
> the values are converted to rationals ([0,1] for CEI 1931 Chroma coords,
> and cd/m^2 for luma).
> 
> Signed-off-by: Neil Birkbeck 
> ---
>  libavcodec/hevc.c | 52 
> +++
>  libavcodec/hevc.h |  7 +++
>  libavcodec/hevc_sei.c | 26 ++
>  libavcodec/version.h  |  2 +-
>  4 files changed, 86 insertions(+), 1 deletion(-)

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


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

Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (v2)

[Michael Niedermayer]

On Wed, Feb 03, 2016 at 12:47:47PM +, John Cox wrote:
> On Tue, 2 Feb 2016 12:52:15 +0100, you wrote:
> 
> >Hi,
> >
> >as a motus operandi for this review, I have no time for a proper one,
> >or at least not fitting with John's timeframe. I'll try to close as
> >many pending discussions, and would prefer if someone else completed
> >the review/validation/commit.
> 
> Do we have another volunteer?

i can test and commit the code, it seems everyone who wanted to
comment did comment

what parts are left ?

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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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

[FFmpeg-devel] [PATCH 1/2] vf_blend: Templatize identity function and use a better name

[Timothy Gu]

---
 libavfilter/vf_blend.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/libavfilter/vf_blend.c b/libavfilter/vf_blend.c
index 2b734b4..c24013d 100644
--- a/libavfilter/vf_blend.c
+++ b/libavfilter/vf_blend.c
@@ -118,15 +118,21 @@ static const AVOption blend_options[] = {
 
 AVFILTER_DEFINE_CLASS(blend);
 
-static void blend_normal(const uint8_t *top, ptrdiff_t top_linesize,
- const uint8_t *bottom, ptrdiff_t bottom_linesize,
- uint8_t *dst, ptrdiff_t dst_linesize,
- ptrdiff_t width, ptrdiff_t start, ptrdiff_t end,
- FilterParams *param, double *values)
-{
-av_image_copy_plane(dst, dst_linesize, top, top_linesize, width, end - 
start);
+#define COPY(src)\
+static void blend_copy ## src(const uint8_t *top, ptrdiff_t top_linesize,\
+const uint8_t *bottom, ptrdiff_t bottom_linesize,\
+uint8_t *dst, ptrdiff_t dst_linesize,\
+ptrdiff_t width, ptrdiff_t start, ptrdiff_t end, \
+FilterParams *param, double *values) \
+{\
+av_image_copy_plane(dst, dst_linesize, src, src ## _linesize,\
+width, end - start); \
 }
 
+COPY(top)
+
+#undef COPY
+
 static void blend_normal_8bit(const uint8_t *top, ptrdiff_t top_linesize,
   const uint8_t *bottom, ptrdiff_t bottom_linesize,
   uint8_t *dst, ptrdiff_t dst_linesize,
@@ -505,7 +511,7 @@ static int config_output(AVFilterLink *outlink)
 case BLEND_MULTIPLY:   param->blend = is_16bit ? blend_multiply_16bit  
 : blend_multiply_8bit;   break;
 case BLEND_MULTIPLY128:param->blend = is_16bit ? 
blend_multiply128_16bit: blend_multiply128_8bit;break;
 case BLEND_NEGATION:   param->blend = is_16bit ? blend_negation_16bit  
 : blend_negation_8bit;   break;
-case BLEND_NORMAL: param->blend = param->opacity == 1 ? 
blend_normal:
+case BLEND_NORMAL: param->blend = param->opacity == 1 ? 
blend_copytop :
   is_16bit ? blend_normal_16bit
 : blend_normal_8bit; break;
 case BLEND_OR: param->blend = is_16bit ? blend_or_16bit
 : blend_or_8bit; break;
 case BLEND_OVERLAY:param->blend = is_16bit ? blend_overlay_16bit   
 : blend_overlay_8bit;break;
-- 
2.1.4

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

[FFmpeg-devel] [PATCH 2/2] vf_blend: Use memcpy when opacity is 0

[Timothy Gu]

For xor mode, 1.8x faster on Haswell.
---
 libavfilter/vf_blend.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavfilter/vf_blend.c b/libavfilter/vf_blend.c
index c24013d..599084f 100644
--- a/libavfilter/vf_blend.c
+++ b/libavfilter/vf_blend.c
@@ -130,6 +130,7 @@ static void blend_copy ## src(const uint8_t *top, ptrdiff_t 
top_linesize,\
 }
 
 COPY(top)
+COPY(bottom)
 
 #undef COPY
 
@@ -512,6 +513,7 @@ static int config_output(AVFilterLink *outlink)
 case BLEND_MULTIPLY128:param->blend = is_16bit ? 
blend_multiply128_16bit: blend_multiply128_8bit;break;
 case BLEND_NEGATION:   param->blend = is_16bit ? blend_negation_16bit  
 : blend_negation_8bit;   break;
 case BLEND_NORMAL: param->blend = param->opacity == 1 ? 
blend_copytop :
+  param->opacity == 0 ? 
blend_copybottom :
   is_16bit ? blend_normal_16bit
 : blend_normal_8bit; break;
 case BLEND_OR: param->blend = is_16bit ? blend_or_16bit
 : blend_or_8bit; break;
 case BLEND_OVERLAY:param->blend = is_16bit ? blend_overlay_16bit   
 : blend_overlay_8bit;break;
@@ -528,6 +530,10 @@ static int config_output(AVFilterLink *outlink)
 if (ARCH_X86)
 ff_blend_init_x86(param, is_16bit);
 
+if (param->opacity == 0 && param->mode != BLEND_NORMAL) {
+param->blend = blend_copytop;
+}
+
 if (s->all_expr && !param->expr_str) {
 param->expr_str = av_strdup(s->all_expr);
 if (!param->expr_str)
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH v2 2/2] libavcodec/dnxhd_parser: add parser and probe support raw 444 and dnxhr formats

[Mark Reid]

On Fri, Feb 12, 2016 at 6:12 AM, Michael Niedermayer
 wrote:
> On Thu, Feb 11, 2016 at 08:41:16PM -0800, Mark Reid wrote:
>> ---
>>  libavcodec/dnxhd_parser.c | 11 +++
>>  libavformat/dnxhddec.c|  7 ---
>>  2 files changed, 11 insertions(+), 7 deletions(-)
>
> what effect on speed does this have ?
> AV_RB*() might be better than memcmp(), also a inline function or
> macro might be better if this is called alot
>

Its definitely a lot worse then my initial attempt. It gets called
lots in the parser loop. I think I got a better idea and will send a
new patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads

[Ronald S. Bultje]

Hi,

On Sat, Feb 13, 2016 at 2:38 PM, Michael Niedermayer  wrote:

> On Sat, Jan 23, 2016 at 11:42:54AM +0100, Hendrik Leppkes wrote:
> > On Sat, Jan 23, 2016 at 10:12 AM, Andreas Cadhalpun
> >  wrote:
> > > VLC uses hwaccel with frame threads and it works fine, but returning
> > > an error here made it fail.
> > >
> > > This regression was introduced in commit 31741ae.
> > >
> >
> > I'm still opposed to this, and so is everyone else that commented on the
> issue.
> > Also, the vp9 hwaccel will most definitely misbehave with MT, so this
> > one needs to be re-factored before MT is allowed at the very least.
>
> vp9 has been fixed
>
> from IRC:
>
>  BBB, can the vp9 & hwaccel-mt patches be applied or is there a
> reason to wait ?
>  no reason to wait, can be applied
>  sorry, I haven’t kept track very closely of that patch
>  I can apply if you want, but it’s probably faster if you merge for me
>  I believe with that patch, we can revert the previous patch that
> prevented mt+hwaccel, as andreas requested
>  it will still not work for dxva2, but that’s unrelated to vp9 since
> it fails for h264 also
>  i can apply the patchs, i just dont want to step on anyones
> toes, the vp9 one seems clear but which is the 2nd one, the one from anreas
> that changes it to a warning or revert 31741ae ?
>
> just want to make double sure i dont step on anyones toes, thus asking
> on the ML here too before applying the patch


I think it's fine to apply, please ask for Hendrik's opinion also.

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

[FFmpeg-devel] [PATCH] x86/vf_blend: Add SSE4.1 optimization for divide

[Timothy Gu]

---

The reason why this function uses SSE4.1 is the roundps instruction. Would
love to find a way to truncate a float to integer in SSE2.

---
 libavfilter/x86/vf_blend.asm| 32 
 libavfilter/x86/vf_blend_init.c |  6 ++
 2 files changed, 38 insertions(+)

diff --git a/libavfilter/x86/vf_blend.asm b/libavfilter/x86/vf_blend.asm
index a5ea74c..dac04d7 100644
--- a/libavfilter/x86/vf_blend.asm
+++ b/libavfilter/x86/vf_blend.asm
@@ -24,6 +24,7 @@
 
 SECTION_RODATA
 
+ps_255: times 4 dd 255.0
 pw_1:   times 8 dw 1
 pw_128: times 8 dw 128
 pw_255: times 8 dw 255
@@ -285,3 +286,34 @@ INIT_XMM sse2
 BLEND_ABS
 INIT_XMM ssse3
 BLEND_ABS
+
+INIT_XMM sse4
+BLEND_INIT divide, 4
+pxor   m2, m2
+mova   m3, [ps_255]
+.nextrow:
+movxq, widthq
+
+.loop:
+movdm0, [topq + xq]  ; 00xx
+movdm1, [bottomq + xq]
+punpcklbw   m0, m2   ; 0x0x
+punpcklbw   m1, m2
+punpcklwd   m0, m2   ; 000x000x
+punpcklwd   m1, m2
+
+cvtdq2psm0, m0
+cvtdq2psm1, m1
+divps   m0, m1   ; a / b
+mulps   m0, m3   ; a / b * 255
+roundps m0, m0, 3; truncate
+minps   m0, m3
+cvtps2dqm0, m0
+
+packusdwm0, m0   ; 0x0x
+packuswbm0, m0   ; 00xx
+movd   [dstq + xq], m0
+add xq, mmsize / 4
+
+jl .loop
+BLEND_END
diff --git a/libavfilter/x86/vf_blend_init.c b/libavfilter/x86/vf_blend_init.c
index a6baf94..f542870 100644
--- a/libavfilter/x86/vf_blend_init.c
+++ b/libavfilter/x86/vf_blend_init.c
@@ -48,6 +48,7 @@ BLEND_FUNC(difference, sse2)
 BLEND_FUNC(difference, ssse3)
 BLEND_FUNC(negation, sse2)
 BLEND_FUNC(negation, ssse3)
+BLEND_FUNC(divide, sse4)
 
 av_cold void ff_blend_init_x86(FilterParams *param, int is_16bit)
 {
@@ -79,4 +80,9 @@ av_cold void ff_blend_init_x86(FilterParams *param, int 
is_16bit)
 case BLEND_NEGATION:   param->blend = ff_blend_negation_ssse3;   break;
 }
 }
+if (EXTERNAL_SSE4(cpu_flags) && param->opacity == 1 && !is_16bit) {
+switch (param->mode) {
+case BLEND_DIVIDE:   param->blend = ff_blend_divide_sse4;   break;
+}
+}
 }
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH] Add mkdir support for HLS localtime-generated segment files

[Michael Niedermayer]

On Wed, Feb 03, 2016 at 10:44:28PM +0100, Johan Ström wrote:
> Hi,
> 
> this patch adds -use_localtime_mkdir option to the HLS encoder.
> Use with -use_localtime, and set -hls_segment_filename to a path
> which contains a subdirectory i.e.
> /some/path/%Y%m%d/%Y%m%dT%H%M%S-%s.ts
> This will mkdir the %Y%m%d-part of the path if it does not already exist.
> 
> In addition, each filename in the playlist output will be prefixed
> with this subdirectory (if playlist and segment shares the same base
> path).
> 
> Example:
> 
> $ ffmpeg  -f hls -use_localtime 1 -use_localtime_mkdir 1
> -hls_segment_filename /dvr/test/%Y%m%d/%Y%m%dT%H%M%S-%s.ts
> /dvr/test/playlist.m3u8
> 
> This will create put segments created (today) in
> /dvr/test/20160203/, and the 20160203 dir will be automatically
> created if it does not already exist.
> The m3u8 playlist will contain segment paths like this:
> 
> 20160203/20160203T224121-1454535681.ts
> 
> The subdir support could possibly be enabled outside of the
> localtime/mkdir-scope.
> 
> 
> Regards
> Johan
> 

>  hlsenc.c |   46 --
>  1 file changed, 40 insertions(+), 6 deletions(-)
> f3bbd115d143c8dd40fef92eb4a84b6c4ef574e7  
> 0001-hlsenc-add-use_localtime_mkdir-option-to-automatical.patch
> From 40327f78d70b3f1b97b222de5adf70020c466db9 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Johan=20Str=C3=B6m?= 
> Date: Wed, 3 Feb 2016 22:20:07 +0100
> Subject: [PATCH] hlsenc: add use_localtime_mkdir option to automatically
>  create time-based directory
> 
> Use with -use_localtime, and set -hls_segment_filename to a path which
> contains a subdirectory i.e. /some/path/%Y%m%d/%Y%m%dT%H%M%S-%s.ts
> This will mkdir the %Y%m%d-part of the path if it does not already
> exist.
> In addition, each filename in the playlist output will be prefixed with
> this subdirectory (if playlist and segment shares the same base path).
> ---
>  libavformat/hlsenc.c | 46 --
>  1 file changed, 40 insertions(+), 6 deletions(-)

missing update to the docs


> 
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index bc28e3c..073618d 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -82,6 +82,7 @@ typedef struct HLSContext {
>  char *segment_filename;
>  
>  int use_localtime;  ///< flag to expand filename with localtime
> +int use_localtime_mkdir;///< flag to mkdir dirname in timebased filename
>  int allowcache;
>  int64_t recording_time;
>  int has_video;
> @@ -303,16 +304,33 @@ static int hls_mux_init(AVFormatContext *s)
>  }
>  
>  /* Create a new segment and append it to the segment list */
> -static int hls_append_segment(HLSContext *hls, double duration, int64_t pos,
> -  int64_t size)
> +static int hls_append_segment(struct AVFormatContext *s, HLSContext *hls, 
> double duration,
> +  int64_t pos, int64_t size)
>  {
>  HLSSegment *en = av_malloc(sizeof(*en));
> +char *tmp, *p;
> +const char *pl_dir, *filename;
>  int ret;
>  
>  if (!en)
>  return AVERROR(ENOMEM);
>  
> -av_strlcpy(en->filename, av_basename(hls->avf->filename), 
> sizeof(en->filename));
> +filename = av_basename(hls->avf->filename);
> +
> +if (hls->use_localtime_mkdir) {
> +/* Possibly prefix with mkdir'ed subdir, if playlist share same
> + * base path. */
> +tmp = av_strdup(s->filename);

> +if (!tmp)
> +return AVERROR(ENOMEM);

en leaks here

also can you add a fate test for this feature ?

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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

Re: [FFmpeg-devel] [PATCH] avutil: Remove x86_cpu.h

[Timothy Gu]

On Sun, Feb 07, 2016 at 09:29:23AM -0800, Timothy Gu wrote:
> It is private (uninstalled) and unused.
> ---
>  libavutil/x86_cpu.h | 1 -
>  1 file changed, 1 deletion(-)
>  delete mode 100644 libavutil/x86_cpu.h

Pushed.

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

[FFmpeg-devel] [PATCH v3] libavcodec/dnxhd_parser: add parser and probe support raw 444 and dnxhr formats

[Mark Reid]

---
 libavcodec/dnxhd_parser.c |  7 +++
 libavcodec/dnxhddata.c|  8 
 libavcodec/dnxhddata.h| 18 +-
 libavcodec/dnxhddec.c | 12 
 libavformat/dnxhddec.c|  7 ---
 5 files changed, 36 insertions(+), 16 deletions(-)

diff --git a/libavcodec/dnxhd_parser.c b/libavcodec/dnxhd_parser.c
index fffb98f..033b8ee 100644
--- a/libavcodec/dnxhd_parser.c
+++ b/libavcodec/dnxhd_parser.c
@@ -25,8 +25,7 @@
  */
 
 #include "parser.h"
-
-#define DNXHD_HEADER_PREFIX 0x02800100
+#include "dnxhddata.h"
 
 typedef struct {
 ParseContext pc;
@@ -47,7 +46,7 @@ static int dnxhd_find_frame_end(DNXHDParserContext *dctx,
 if (!pic_found) {
 for (i = 0; i < buf_size; i++) {
 state = (state << 8) | buf[i];
-if ((state & 0xff00LL) == DNXHD_HEADER_PREFIX) {
+if (ff_dnxhd_check_header_prefix(state & 0xff00LL) != 0) {
 i++;
 pic_found = 1;
 interlaced = (state&2)>>1; /* byte following the 5-byte header 
prefix */
@@ -62,7 +61,7 @@ static int dnxhd_find_frame_end(DNXHDParserContext *dctx,
 return 0;
 for (; i < buf_size; i++) {
 state = (state << 8) | buf[i];
-if ((state & 0xff00LL) == DNXHD_HEADER_PREFIX) {
+if (ff_dnxhd_check_header_prefix(state & 0xff00LL) != 0) {
 if (!interlaced || dctx->cur_field) {
 pc->frame_start_found = 0;
 pc->state64 = -1;
diff --git a/libavcodec/dnxhddata.c b/libavcodec/dnxhddata.c
index 82fbfdf..6955fd0 100644
--- a/libavcodec/dnxhddata.c
+++ b/libavcodec/dnxhddata.c
@@ -22,6 +22,7 @@
 #include "avcodec.h"
 #include "dnxhddata.h"
 #include "libavutil/common.h"
+#include "libavutil/intreadwrite.h"
 
 /* The quantization tables below are in zigzag order! */
 
@@ -1102,6 +1103,13 @@ int avpriv_dnxhd_get_interlaced(int cid)
 return ff_dnxhd_cid_table[i].flags & DNXHD_INTERLACED ? 1 : 0;
 }
 
+uint64_t avpriv_dnxhd_parse_header_prefix(const uint8_t *buf)
+{
+  uint64_t prefix = AV_RB32(buf);
+  prefix = (prefix << 16) | buf[4] << 8;
+  return ff_dnxhd_check_header_prefix(prefix);
+}
+
 int ff_dnxhd_find_cid(AVCodecContext *avctx, int bit_depth)
 {
 int i, j;
diff --git a/libavcodec/dnxhddata.h b/libavcodec/dnxhddata.h
index d973888..11e3204 100644
--- a/libavcodec/dnxhddata.h
+++ b/libavcodec/dnxhddata.h
@@ -31,6 +31,12 @@
 #define DNXHD_MBAFF(1<<1)
 #define DNXHD_444  (1<<2)
 
+/** Frame headers, extra 0x00 added to end for parser */
+#define DNXHD_HEADER_INITIAL 0x02800100
+#define DNXHD_HEADER_444 0x02800200
+#define DNXHD_HEADER_HR1 0x02800300
+#define DNXHD_HEADER_HR2 0x038C0300
+
 /** Indicate that a CIDEntry value must be read in the bitstream */
 #define DNXHD_VARIABLE 0
 
@@ -59,7 +65,17 @@ int ff_dnxhd_get_cid_table(int cid);
 int ff_dnxhd_find_cid(AVCodecContext *avctx, int bit_depth);
 void ff_dnxhd_print_profiles(AVCodecContext *avctx, int loglevel);
 
+static av_always_inline uint64_t ff_dnxhd_check_header_prefix(uint64_t prefix)
+{
+  if (prefix == DNXHD_HEADER_INITIAL ||
+  prefix == DNXHD_HEADER_444 ||
+  prefix == DNXHD_HEADER_HR1 ||
+  prefix == DNXHD_HEADER_HR2)
+return prefix;
+  return 0;
+}
+
 int avpriv_dnxhd_get_frame_size(int cid);
 int avpriv_dnxhd_get_interlaced(int cid);
-
+uint64_t avpriv_dnxhd_parse_header_prefix(const uint8_t *buf);
 #endif /* AVCODEC_DNXHDDATA_H */
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index 5c09c64..1808080 100644
--- a/libavcodec/dnxhddec.c
+++ b/libavcodec/dnxhddec.c
@@ -163,21 +163,17 @@ static int dnxhd_decode_header(DNXHDContext *ctx, AVFrame 
*frame,
const uint8_t *buf, int buf_size,
int first_field)
 {
-static const uint8_t header_prefix[]= { 0x00, 0x00, 0x02, 0x80, 0x01 };
-static const uint8_t header_prefix444[] = { 0x00, 0x00, 0x02, 0x80, 0x02 };
-static const uint8_t header_prefixhr1[] = { 0x00, 0x00, 0x02, 0x80, 0x03 };
-static const uint8_t header_prefixhr2[] = { 0x00, 0x00, 0x03, 0x8C, 0x03 };
 int i, cid, ret;
 int old_bit_depth = ctx->bit_depth, bitdepth;
-
+uint64_t header_prefix;
 if (buf_size < 0x280) {
 av_log(ctx->avctx, AV_LOG_ERROR,
"buffer too small (%d < 640).\n", buf_size);
 return AVERROR_INVALIDDATA;
 }
 
-if (memcmp(buf, header_prefix, 5) && memcmp(buf, header_prefix444, 5) &&
-memcmp(buf, header_prefixhr1, 5) && memcmp(buf, header_prefixhr2, 5)) {
+header_prefix = avpriv_dnxhd_parse_header_prefix(buf);
+if (header_prefix == 0) {
 av_log(ctx->avctx, AV_LOG_ERROR,
"unknown header 0x%02X 0x%02X 0x%02X 0x%02X 0x%02X\n",
buf[0], buf[1], buf[2], buf[3], buf[4]);
@@ -279,7 +275,7 @@ static int dnxhd_decode_header(DNXHDContext *ctx, AVFrame 
*frame,

Re: [FFmpeg-devel] [PATCH 1/2] avformat/img2enc: return error if image rename fails

[Marton Balint]

On Thu, 11 Feb 2016, Michael Niedermayer wrote:


On Thu, Feb 11, 2016 at 02:23:10AM +0100, Marton Balint wrote:

Signed-off-by: Marton Balint 
---
 libavformat/img2enc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)


should be ok


Applied, thanks.

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

[FFmpeg-devel] [PATCH v3] libavcodec/dnxhd_parser: add parser and probe support raw 444 and dnxhr formats

[Mark Reid]

changes since v2:
removed table and enums, using defines for prefixes instead.
parser now uses a inline function.

Mark Reid (1):
  libavcodec/dnxhd_parser: add parser and probe support raw 444 and
dnxhr formats

 libavcodec/dnxhd_parser.c |  7 +++
 libavcodec/dnxhddata.c|  8 
 libavcodec/dnxhddata.h| 18 +-
 libavcodec/dnxhddec.c | 12 
 libavformat/dnxhddec.c|  7 ---
 5 files changed, 36 insertions(+), 16 deletions(-)

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/img2enc: disable atomic file creation by default

[Marton Balint]

On Sat, 13 Feb 2016, Marton Balint wrote:


On Thu, 11 Feb 2016, Marton Balint wrote:


Currently it is broken when explicitly using the file protocol, it uses an
insecure temporary file name, and in commit b4431c80 disabling the option 

by
default was already considered. Also it is not very consistent to have such 

an

option for one particular muxer.


Is there anybody against this patch?

I will apply it soon if I get no feedback.



Applied.

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

[FFmpeg-devel] [PATCH] x86/vc1dsp: Port vc1_*_hor_16b_shift2 to NASM format

[Timothy Gu]

---
 libavcodec/x86/vc1dsp.asm   | 92 -
 libavcodec/x86/vc1dsp_mmx.c | 61 --
 2 files changed, 99 insertions(+), 54 deletions(-)

diff --git a/libavcodec/x86/vc1dsp.asm b/libavcodec/x86/vc1dsp.asm
index 91a1991..2e9f067 100644
--- a/libavcodec/x86/vc1dsp.asm
+++ b/libavcodec/x86/vc1dsp.asm
@@ -25,6 +25,7 @@
 cextern pw_4
 cextern pw_5
 cextern pw_9
+cextern pw_128
 
 section .text
 
@@ -319,9 +320,47 @@ cglobal vc1_h_loop_filter8, 3,5,8
 RET
 
 %if HAVE_MMX_INLINE
+
+; XXX some of these macros are not used right now, but they will in the future
+; when more functions are ported.
+
+%macro OP_PUT 2 ; dst, src
+%endmacro
+
+%macro OP_AVG 2 ; dst, src
+pavgb   %1, %2
+%endmacro
+
+%macro NORMALIZE_MMX 1 ; shift
+paddw   m3, m7 ; +bias-r
+paddw   m4, m7 ; +bias-r
+psraw   m3, %1
+psraw   m4, %1
+%endmacro
+
+%macro TRANSFER_DO_PACK 2 ; op, dst
+packuswbm3, m4
+%1  m3, [%2]
+mova  [%2], m3
+%endmacro
+
+%macro TRANSFER_DONT_PACK 2 ; op, dst
+%1  m3, [%2]
+%1  m3, [%2 + mmsize]
+mova  [%2], m3
+mova [mmsize + %2], m4
+%endmacro
+
+; see MSPEL_FILTER13_CORE for use as UNPACK macro
+%macro DO_UNPACK 1 ; reg
+punpcklbw   %1, m0
+%endmacro
+%macro DONT_UNPACK 1 ; reg
+%endmacro
+
 ; Compute the rounder 32-r or 8-r and unpacks it to m7
 %macro LOAD_ROUNDER_MMX 1 ; round
-movd  m7, %1
+movh  m7, %1
 punpcklwd m7, m7
 punpckldq m7, m7
 %endmacro
@@ -394,6 +433,57 @@ cglobal vc1_put_ver_16b_shift2, 4,7,0, dst, src, stride
 dec i
 jnz .loop
 REP_RET
+%undef rnd
+%undef shift
+%undef stride_neg2
+%undef stride_9minus4
+%undef i
+
+; void ff_vc1_*_hor_16b_shift2_mmx(uint8_t *dst, x86_reg stride,
+;  const int16_t *src, int rnd);
+; Data is already unpacked, so some operations can directly be made from
+; memory.
+%macro HOR_16B_SHIFT2 2 ; op, opname
+cglobal vc1_%2_hor_16b_shift2, 4, 5, 0, dst, stride, src, rnd, h
+movhq, 8
+sub  srcq, 2
+sub  rndd, (-1+9+9-1) * 1024 ; add -1024 bias
+LOAD_ROUNDER_MMX rndq
+mova   m5, [pw_9]
+mova   m6, [pw_128]
+pxor   m0, m0
+
+.loop:
+mova   m1, [srcq + 2 * 0]
+mova   m2, [srcq + 2 * 0 + mmsize]
+mova   m3, [srcq + 2 * 1]
+mova   m4, [srcq + 2 * 1 + mmsize]
+paddw  m3, [srcq + 2 * 2]
+paddw  m4, [srcq + 2 * 2 + mmsize]
+paddw  m1, [srcq + 2 * 3]
+paddw  m2, [srcq + 2 * 3 + mmsize]
+pmullw m3, m5
+pmullw m4, m5
+psubw  m3, m1
+psubw  m4, m2
+NORMALIZE_MMX  7
+; remove bias
+paddw  m3, m6
+paddw  m4, m6
+TRANSFER_DO_PACK   %1, dstq
+add  srcq, 24
+add  dstq, strideq
+dechq
+jnz .loop
+
+RET
+%endmacro
+
+INIT_MMX mmx
+HOR_16B_SHIFT2 OP_PUT, put
+
+INIT_MMX mmxext
+HOR_16B_SHIFT2 OP_AVG, avg
 %endif ; HAVE_MMX_INLINE
 
 %macro INV_TRANS_INIT 0
diff --git a/libavcodec/x86/vc1dsp_mmx.c b/libavcodec/x86/vc1dsp_mmx.c
index ff13d9b..8325648 100644
--- a/libavcodec/x86/vc1dsp_mmx.c
+++ b/libavcodec/x86/vc1dsp_mmx.c
@@ -38,6 +38,10 @@
 void ff_vc1_put_ver_16b_shift2_mmx(int16_t *dst,
const uint8_t *src, x86_reg stride,
int rnd, int64_t shift);
+void ff_vc1_put_hor_16b_shift2_mmx(uint8_t *dst, x86_reg stride,
+   const int16_t *src, int rnd);
+void ff_vc1_avg_hor_16b_shift2_mmxext(uint8_t *dst, x86_reg stride,
+  const int16_t *src, int rnd);
 
 #define OP_PUT(S,D)
 #define OP_AVG(S,D) "pavgb " #S ", " #D " \n\t"
@@ -71,55 +75,6 @@ void ff_vc1_put_ver_16b_shift2_mmx(int16_t *dst,
  "punpckldq %%mm7, %%mm7   \n\t"
 
 /**
- * Data is already unpacked, so some operations can directly be made from
- * memory.
- */
-#define VC1_HOR_16b_SHIFT2(OP, OPNAME)\
-static void OPNAME ## vc1_hor_16b_shift2_mmx(uint8_t *dst, x86_reg stride,\
- const int16_t *src, int rnd)\
-{\
-int h = 8;\
-\
-src -= 1;\
-rnd -= (-1+9+9-1)*1024; /* Add -1024 bias */\
-__asm__ volatile(\
-LOAD_ROUNDER_MMX("%4")\
-"movq  "MANGLE(ff_pw_128)", %%mm6\n\t"\
-"movq  "MANGLE(ff_pw_9)", %%mm5 \n\t"\
-"1:\n\t"\
-"movq  2*0+0(%1), %%mm1\n\t"\
-"movq  2*0+8(%1), %%mm2\n\t"\
-"movq  2*1+0(%1), %%mm3\n\t"\
-"movq  2*1+8(%1), %%mm4\n\t"\
-"paddw 

[FFmpeg-devel] [PATCH] LICENSE: Thorough editing

[Timothy Gu]

The changes in "Incompatible libraries" section are strictly based on
what our configure script says.
---
 LICENSE.md | 64 +-
 1 file changed, 38 insertions(+), 26 deletions(-)

diff --git a/LICENSE.md b/LICENSE.md
index 0c53d0f..a70f486 100644
--- a/LICENSE.md
+++ b/LICENSE.md
@@ -1,4 +1,4 @@
-#FFmpeg:
+# License
 
 Most files in FFmpeg are under the GNU Lesser General Public License version 
2.1
 or later (LGPL v2.1+). Read the file `COPYING.LGPLv2.1` for details. Some other
@@ -13,16 +13,19 @@ configure to activate them. In this case, FFmpeg's license 
changes to GPL v2+.
 Specifically, the GPL parts of FFmpeg are:
 
 - libpostproc
-- optional x86 optimizations in the files
-  - `libavcodec/x86/flac_dsp_gpl.asm`
-  - `libavcodec/x86/idct_mmx.c`
-  - `libavfilter/x86/vf_removegrain.asm`
-- libutvideo encoding/decoding wrappers in
-  `libavcodec/libutvideo*.cpp`
+- optional x86 optimization in the files
+- `libavcodec/x86/flac_dsp_gpl.asm`
+- `libavcodec/x86/idct_mmx.c`
+- `libavfilter/x86/vf_removegrain.asm`
+- libutvideo encoding/decoding wrappers in `libavcodec/libutvideo*.cpp`
 - the X11 grabber in `libavdevice/x11grab.c`
-- the swresample test app in
-  `libswresample/swresample-test.c`
-- the `texi2pod.pl` tool
+- the following building and testing tools
+- `compat/solaris/make_sunver.pl`
+- `doc/t2h.pm`
+- `doc/texi2pod.pl`
+- `libswresample/swresample-test.c`
+- `tests/checkasm/*`
+- `tests/tiny_ssim.c`
 - the following filters in libavfilter:
 - `f_ebur128.c`
 - `vf_blackframe.c`
@@ -47,9 +50,9 @@ Specifically, the GPL parts of FFmpeg are:
 - `vf_pp.c`
 - `vf_pp7.c`
 - `vf_pullup.c`
+- `vf_repeatfields.c`
 - `vf_sab.c`
 - `vf_smartblur.c`
-- `vf_repeatfields.c`
 - `vf_spp.c`
 - `vf_stereo3d.c`
 - `vf_super2xsai.c`
@@ -73,14 +76,12 @@ There are a handful of files under other licensing terms, 
namely:
 * `tests/reference.pnm` is under the expat license.
 
 
-external libraries
-==
+## External libraries
 
 FFmpeg can be combined with a number of external libraries, which sometimes
 affect the licensing of binaries resulting from the combination.
 
-compatible libraries
-
+### Compatible libraries
 
 The following libraries are under GPL:
 - frei0r
@@ -101,14 +102,25 @@ license is incompatible with the LGPL v2.1 and the GPL 
v2, but not with
 version 3 of those licenses. So to combine these libraries with FFmpeg, the
 license version needs to be upgraded by passing `--enable-version3` to 
configure.
 
-incompatible libraries
---
-
-The Fraunhofer AAC library and FAAC are under licenses which
-are incompatible with the GPLv2 and v3. We do not know for certain if their
-licenses are compatible with the LGPL.
-If you wish to enable these libraries, pass `--enable-nonfree` to configure.
-But note that if you enable any of these libraries the resulting binary will
-be under a complex license mix that is more restrictive than the LGPL and that
-may result in additional obligations. It is possible that these
-restrictions cause the resulting binary to be unredistributeable.
+### Incompatible libraries
+
+There are certain libraries you can combine with FFmpeg whose licenses are not
+compatible with the GPL and/or the LGPL. If you wish to enable these
+libraries, even in circumstances that their license may be incompatible, pass
+`--enable-nonfree` to configure. But note that if you enable any of these
+libraries the resulting binary will be under a complex license mix that is
+more restrictive than the LGPL and that may result in additional obligations.
+It is possible that these restrictions cause the resulting binary to be
+unredistributable.
+
+The Fraunhofer FDK AAC and OpenSSL libraries are under licenses which are
+incompatible with the GPLv2 and v3. To the best of our knowledge, they are
+compatible with the LGPL.
+
+The FAAC library is incompatible with all versions of GPL and LGPL.
+
+The NVENC library, while its header file is licensed under the compatible MIT
+license, requires a proprietary binary blob at run time, and is deemed to be
+incompatible with the GPL. We are not certain if it is compatible with the
+LGPL, but we require `--enable-nonfree` even with LGPL configurations in case
+it is not.
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH 12/12] ffmpeg: remove hardcoded 'now' creation_time support

[Marton Balint]

On Sat, 6 Feb 2016, Marton Balint wrote:


Every date parsing routine now uses av_parse_time which handles 'now' and
provides greater precision as well. This change also enables the segmenter
muxer to set the proper 'now' creation time at the beginning of each segment.

Signed-off-by: Marton Balint 
---
ffmpeg_opt.c | 11 ---
1 file changed, 11 deletions(-)

diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 669976b..7451e21 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -2430,17 +2430,6 @@ loop_end:
}
*val++ = 0;

-if (!strcmp(o->metadata[i].u.str, "creation_time") &&
-!strcmp(val, "now")) {
-time_t now = time(0);
-struct tm *ptm, tmbuf;
-ptm = localtime_r(, );
-if (ptm) {
-if (strftime(now_time, sizeof(now_time), "%Y-%m-%d %H:%M:%S", 
ptm))
-val = now_time;
-}
-}
-


Like I mentioned, this change causes the existing muxers which blindly 
write all metadata as string to write "now" into creation_time if 
-metadata creation_time=now is specified as an option.


Is this acceptable?

The muxers affected (assuming I did the grep right):

caf
flv
id3v2
lrc
nut
smjpeg
wtv

If it is not acceptable then would it be OK to introduce an avformat flag 
which signals that the format needs creation_time strings parsed?


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

Re: [FFmpeg-devel] [PATCH] x86/vf_blend: Add SSE2 optimization for divide

[Timothy Gu]

On Sat, Feb 13, 2016 at 07:21:25PM -0800, Timothy Gu wrote:
> ---
>  libavfilter/x86/vf_blend.asm| 30 ++
>  libavfilter/x86/vf_blend_init.c |  2 ++
>  2 files changed, 32 insertions(+)

Locally added commit message:

 4.5x faster than C float version with autovectorization
10  x faster than C int version
25  x faster than C float version without autovectorization

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

[FFmpeg-devel] [PATCH] vf_blend: Reduce number of arguments for kernel function

[Timothy Gu]

---
 libavfilter/blend.h |  2 +-
 libavfilter/vf_blend.c  | 27 ++-
 libavfilter/x86/vf_blend.asm|  3 +--
 libavfilter/x86/vf_blend_init.c |  2 +-
 4 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/libavfilter/blend.h b/libavfilter/blend.h
index 161055c..7003505 100644
--- a/libavfilter/blend.h
+++ b/libavfilter/blend.h
@@ -67,7 +67,7 @@ typedef struct FilterParams {
 void (*blend)(const uint8_t *top, ptrdiff_t top_linesize,
   const uint8_t *bottom, ptrdiff_t bottom_linesize,
   uint8_t *dst, ptrdiff_t dst_linesize,
-  ptrdiff_t width, ptrdiff_t start, ptrdiff_t end,
+  ptrdiff_t width, ptrdiff_t height,
   struct FilterParams *param, double *values);
 } FilterParams;
 
diff --git a/libavfilter/vf_blend.c b/libavfilter/vf_blend.c
index 2b734b4..1c9924a 100644
--- a/libavfilter/vf_blend.c
+++ b/libavfilter/vf_blend.c
@@ -121,22 +121,22 @@ AVFILTER_DEFINE_CLASS(blend);
 static void blend_normal(const uint8_t *top, ptrdiff_t top_linesize,
  const uint8_t *bottom, ptrdiff_t bottom_linesize,
  uint8_t *dst, ptrdiff_t dst_linesize,
- ptrdiff_t width, ptrdiff_t start, ptrdiff_t end,
+ ptrdiff_t width, ptrdiff_t height,
  FilterParams *param, double *values)
 {
-av_image_copy_plane(dst, dst_linesize, top, top_linesize, width, end - 
start);
+av_image_copy_plane(dst, dst_linesize, top, top_linesize, width, height);
 }
 
 static void blend_normal_8bit(const uint8_t *top, ptrdiff_t top_linesize,
   const uint8_t *bottom, ptrdiff_t bottom_linesize,
   uint8_t *dst, ptrdiff_t dst_linesize,
-  ptrdiff_t width, ptrdiff_t start, ptrdiff_t end,
+  ptrdiff_t width, ptrdiff_t height,
   FilterParams *param, double *values)
 {
 const double opacity = param->opacity;
 int i, j;
 
-for (i = start; i < end; i++) {
+for (i = 0; i < height; i++) {
 for (j = 0; j < width; j++) {
 dst[j] = top[j] * opacity + bottom[j] * (1. - opacity);
 }
@@ -149,7 +149,7 @@ static void blend_normal_8bit(const uint8_t *top, ptrdiff_t 
top_linesize,
 static void blend_normal_16bit(const uint8_t *_top, ptrdiff_t top_linesize,
   const uint8_t *_bottom, ptrdiff_t 
bottom_linesize,
   uint8_t *_dst, ptrdiff_t dst_linesize,
-  ptrdiff_t width, ptrdiff_t start, ptrdiff_t 
end,
+  ptrdiff_t width, ptrdiff_t height,
   FilterParams *param, double *values)
 {
 const uint16_t *top = (uint16_t*)_top;
@@ -161,7 +161,7 @@ static void blend_normal_16bit(const uint8_t *_top, 
ptrdiff_t top_linesize,
 top_linesize /= 2;
 bottom_linesize /= 2;
 
-for (i = start; i < end; i++) {
+for (i = 0; i < height; i++) {
 for (j = 0; j < width; j++) {
 dst[j] = top[j] * opacity + bottom[j] * (1. - opacity);
 }
@@ -175,13 +175,13 @@ static void blend_normal_16bit(const uint8_t *_top, 
ptrdiff_t top_linesize,
 static void blend_## name##_8bit(const uint8_t *top, ptrdiff_t top_linesize,   
  \
  const uint8_t *bottom, ptrdiff_t 
bottom_linesize,   \
  uint8_t *dst, ptrdiff_t dst_linesize, 
  \
- ptrdiff_t width, ptrdiff_t start, ptrdiff_t 
end,\
+ ptrdiff_t width, ptrdiff_t height,
\
  FilterParams *param, double *values)  
\
 {  
\
 double opacity = param->opacity;   
\
 int i, j;  
\

\
-for (i = start; i < end; i++) {
\
+for (i = 0; i < height; i++) { 
\
 for (j = 0; j < width; j++) {  
\
 dst[j] = top[j] + ((expr) - top[j]) * opacity; 
\
 }  
\
@@ -195,7 +195,7 @@ static void blend_## name##_8bit(const uint8_t *top, 
ptrdiff_t top_linesize,
 static void blend_## name##_16bit(const uint8_t *_top, ptrdiff_t top_linesize, 
  \
   const uint8_t *_bottom, ptrdiff_t 
bottom_linesize, \
   uint8_t *_dst, ptrdiff_t dst_linesize,   
  

[FFmpeg-devel] [PATCH] Improve os2threads

[KO Myung-Hun]

Hi/2.

These are patches to improve os2threads.

Review, please...

[PATCH 1/3] compat/os2threads: Improve pthread_cond_xxx() functions
[PATCH 2/3] compat/os2threads: support the return value of joined
[PATCH 3/3] compat/os2threads: split long lines
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/3] compat/os2threads: Improve pthread_cond_xxx() functions

[KO Myung-Hun]

1. Manipulate waiting count in pthread_cond_wait()
2. Use builtin atomic functions to manipulate waiting count
---
 compat/os2threads.h | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/compat/os2threads.h b/compat/os2threads.h
index 7c0fe13..b461f83 100644
--- a/compat/os2threads.h
+++ b/compat/os2threads.h
@@ -32,6 +32,7 @@
 #undef __STRICT_ANSI__  /* for _beginthread() */
 #include 
 
+#include 
 #include 
 
 #include "libavutil/mem.h"
@@ -44,7 +45,7 @@ typedef void pthread_mutexattr_t;
 
 typedef struct {
 HEV  event_sem;
-int  wait_count;
+volatile unsigned  wait_count;
 } pthread_cond_t;
 
 typedef void pthread_condattr_t;
@@ -139,21 +140,17 @@ static av_always_inline int 
pthread_cond_destroy(pthread_cond_t *cond)
 
 static av_always_inline int pthread_cond_signal(pthread_cond_t *cond)
 {
-if (cond->wait_count > 0) {
+if (!__atomic_cmpxchg32(>wait_count, 0, 0))
 DosPostEventSem(cond->event_sem);
 
-cond->wait_count--;
-}
-
 return 0;
 }
 
 static av_always_inline int pthread_cond_broadcast(pthread_cond_t *cond)
 {
-while (cond->wait_count > 0) {
-DosPostEventSem(cond->event_sem);
-
-cond->wait_count--;
+while (!__atomic_cmpxchg32(>wait_count, 0, 0)) {
+if (DosPostEventSem(cond->event_sem))
+DosSleep(1);
 }
 
 return 0;
@@ -161,12 +158,14 @@ static av_always_inline int 
pthread_cond_broadcast(pthread_cond_t *cond)
 
 static av_always_inline int pthread_cond_wait(pthread_cond_t *cond, 
pthread_mutex_t *mutex)
 {
-cond->wait_count++;
+__atomic_increment(>wait_count);
 
 pthread_mutex_unlock(mutex);
 
 DosWaitEventSem(cond->event_sem, SEM_INDEFINITE_WAIT);
 
+__atomic_decrement(>wait_count);
+
 pthread_mutex_lock(mutex);
 
 return 0;
-- 
2.7.0

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

[FFmpeg-devel] [PATCH 3/3] compat/os2threads: split long lines

[KO Myung-Hun]

---
 compat/os2threads.h | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/compat/os2threads.h b/compat/os2threads.h
index f2e5d9f..5767190 100644
--- a/compat/os2threads.h
+++ b/compat/os2threads.h
@@ -70,7 +70,10 @@ static void thread_entry(void *arg)
 thread->result = thread->start_routine(thread->arg);
 }
 
-static av_always_inline int pthread_create(pthread_t *thread, const 
pthread_attr_t *attr, void *(*start_routine)(void*), void *arg)
+static av_always_inline int pthread_create(pthread_t *thread,
+   const pthread_attr_t *attr,
+   void *(*start_routine)(void*),
+   void *arg)
 {
 thread->start_routine = start_routine;
 thread->arg = arg;
@@ -91,7 +94,8 @@ static av_always_inline int pthread_join(pthread_t thread, 
void **value_ptr)
 return 0;
 }
 
-static av_always_inline int pthread_mutex_init(pthread_mutex_t *mutex, const 
pthread_mutexattr_t *attr)
+static av_always_inline int pthread_mutex_init(pthread_mutex_t *mutex,
+   const pthread_mutexattr_t *attr)
 {
 DosCreateMutexSem(NULL, (PHMTX)mutex, 0, FALSE);
 
@@ -119,7 +123,8 @@ static av_always_inline int 
pthread_mutex_unlock(pthread_mutex_t *mutex)
 return 0;
 }
 
-static av_always_inline int pthread_cond_init(pthread_cond_t *cond, const 
pthread_condattr_t *attr)
+static av_always_inline int pthread_cond_init(pthread_cond_t *cond,
+  const pthread_condattr_t *attr)
 {
 DosCreateEventSem(NULL, >event_sem, DCE_POSTONE, FALSE);
 
@@ -153,7 +158,8 @@ static av_always_inline int 
pthread_cond_broadcast(pthread_cond_t *cond)
 return 0;
 }
 
-static av_always_inline int pthread_cond_wait(pthread_cond_t *cond, 
pthread_mutex_t *mutex)
+static av_always_inline int pthread_cond_wait(pthread_cond_t *cond,
+  pthread_mutex_t *mutex)
 {
 __atomic_increment(>wait_count);
 
@@ -168,7 +174,8 @@ static av_always_inline int 
pthread_cond_wait(pthread_cond_t *cond, pthread_mute
 return 0;
 }
 
-static av_always_inline int pthread_once(pthread_once_t *once_control, void 
(*init_routine)(void))
+static av_always_inline int pthread_once(pthread_once_t *once_control,
+ void (*init_routine)(void))
 {
 if (!once_control->done)
 {
-- 
2.7.0

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

[FFmpeg-devel] [PATCH 2/3] compat/os2threads: support the return value of joined thread

[KO Myung-Hun]

---
 compat/os2threads.h | 39 ++-
 1 file changed, 18 insertions(+), 21 deletions(-)

diff --git a/compat/os2threads.h b/compat/os2threads.h
index b461f83..f2e5d9f 100644
--- a/compat/os2threads.h
+++ b/compat/os2threads.h
@@ -35,9 +35,15 @@
 #include 
 #include 
 
-#include "libavutil/mem.h"
+#include "libavutil/attributes.h"
+
+typedef struct {
+TID tid;
+void *(*start_routine)(void *);
+void *arg;
+void *result;
+} pthread_t;
 
-typedef TID  pthread_t;
 typedef void pthread_attr_t;
 
 typedef HMTX pthread_mutex_t;
@@ -57,39 +63,30 @@ typedef struct {
 
 #define PTHREAD_ONCE_INIT {0, _FMUTEX_INITIALIZER}
 
-struct thread_arg {
-void *(*start_routine)(void *);
-void *arg;
-};
-
 static void thread_entry(void *arg)
 {
-struct thread_arg *thread_arg = arg;
-
-thread_arg->start_routine(thread_arg->arg);
+pthread_t *thread = arg;
 
-av_free(thread_arg);
+thread->result = thread->start_routine(thread->arg);
 }
 
 static av_always_inline int pthread_create(pthread_t *thread, const 
pthread_attr_t *attr, void *(*start_routine)(void*), void *arg)
 {
-struct thread_arg *thread_arg;
-
-thread_arg = av_mallocz(sizeof(struct thread_arg));
-if (!thread_arg)
-return ENOMEM;
+thread->start_routine = start_routine;
+thread->arg = arg;
+thread->result = NULL;
 
-thread_arg->start_routine = start_routine;
-thread_arg->arg = arg;
-
-*thread = _beginthread(thread_entry, NULL, 256 * 1024, thread_arg);
+thread->tid = _beginthread(thread_entry, NULL, 1024 * 1024, thread);
 
 return 0;
 }
 
 static av_always_inline int pthread_join(pthread_t thread, void **value_ptr)
 {
-DosWaitThread((PTID), DCWW_WAIT);
+DosWaitThread(, DCWW_WAIT);
+
+if (value_ptr)
+*value_ptr = thread.result;
 
 return 0;
 }
-- 
2.7.0

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

Re: [FFmpeg-devel] [PATCH 01/12] avutil/parseutils: use microsecond precision when parsing "now" in av_parse_time()

[Marton Balint]

On Wed, 10 Feb 2016, Marton Balint wrote:



On Sun, 7 Feb 2016, Marton Balint wrote:



On Sun, 7 Feb 2016, Michael Niedermayer wrote:


On Sat, Feb 06, 2016 at 08:13:12PM +0100, Marton Balint wrote:

Use av_gettime() instead of time(0) for querying current time.

Signed-off-by: Marton Balint 
---
 libavutil/parseutils.c| 12 +++-
 tests/ref/fate/parseutils |  4 ++--
 2 files changed, 9 insertions(+), 7 deletions(-)


after this (whole) patchset
./ffmpeg  -i lena.pnm -timestamp "2016-01-01 01:01:01" test.mp4
exiftool test.mp4
results in
Create Date : 1904:01:01 00:00:00
Modify Date : 1904:01:01 00:00:00



Hmm, apparently I missed the fact iso 8601 time specs can have timezone 
specifiers as well, even if they were not parsed but silently ignored by 
the existing function.


I will rework the second patch to fix that.


Anybody against this series? With the issues fixed pointed out by Michael, 
I believe it is pretty safe to apply, the one patch which may need 
consideration is the last one patching ffmpeg_opt.c and removing hardcoded 
"now" support in creation_time metadata because it may cause writing the 
actual string "now" as creation time for formats which do not parse 
creation_time metadata but write all metadata to the output blindly as a 
string.


I have applied the series except the last one patching ffmpeg_opt.

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

Re: [FFmpeg-devel] [PATCH] avformat/asfenc: write group_mutual_exclusion_objects on multiple languages

[Michael Niedermayer]

On Sun, Feb 07, 2016 at 11:02:56PM +0100, Marton Balint wrote:
> Improves streaming compatibility with Windows Media Services. Also tested for
> compatilbility in Windows Media Player, Windows Media ASF Viewer and VLC.
> 
> Signed-off-by: Marton Balint 
> ---
>  libavformat/asf.c|  8 
>  libavformat/asf.h|  2 ++
>  libavformat/asfenc.c | 15 +++
>  3 files changed, 25 insertions(+)
> 
> diff --git a/libavformat/asf.c b/libavformat/asf.c
> index 455ca4d..719cae9 100644
> --- a/libavformat/asf.c
> +++ b/libavformat/asf.c
> @@ -147,6 +147,14 @@ const ff_asf_guid 
> ff_asf_extended_stream_properties_object = {
>  0xcb, 0xa5, 0xe6, 0x14, 0x72, 0xc6, 0x32, 0x43, 0x83, 0x99, 0xa9, 0x69, 
> 0x52, 0x06, 0x5b, 0x5a
>  };
>  
> +const ff_asf_guid ff_asf_group_mutual_exclusion_object = {
> +0x40, 0x5a, 0x46, 0xd1, 0x79, 0x5a, 0x38, 0x43, 0xb7, 0x1b, 0xe3, 0x6b, 
> 0x8f, 0xd6, 0xc2, 0x49
> +};
> +
> +const ff_asf_guid ff_asf_mutex_language = {
> +0x00, 0x2a, 0xe2, 0xd6, 0xda, 0x35, 0xd1, 0x11, 0x90, 0x34, 0x00, 0xa0, 
> 0xc9, 0x03, 0x49, 0xbe
> +};
> +
>  /* List of official tags at 
> http://msdn.microsoft.com/en-us/library/dd743066(VS.85).aspx */
>  const AVMetadataConv ff_asf_metadata_conv[] = {
>  { "WM/AlbumArtist",  "album_artist" },
> diff --git a/libavformat/asf.h b/libavformat/asf.h
> index 914ddef..43288dd 100644
> --- a/libavformat/asf.h
> +++ b/libavformat/asf.h
> @@ -100,6 +100,8 @@ extern const ff_asf_guid ff_asf_content_encryption;
>  extern const ff_asf_guid ff_asf_ext_content_encryption;
>  extern const ff_asf_guid ff_asf_digital_signature;
>  extern const ff_asf_guid ff_asf_extended_stream_properties_object;
> +extern const ff_asf_guid ff_asf_group_mutual_exclusion_object;
> +extern const ff_asf_guid ff_asf_mutex_language;
>  
>  extern const AVMetadataConv ff_asf_metadata_conv[];
>  
> diff --git a/libavformat/asfenc.c b/libavformat/asfenc.c
> index a6a8242..3317133 100644
> --- a/libavformat/asfenc.c
> +++ b/libavformat/asfenc.c
> @@ -396,6 +396,7 @@ static int asf_write_header1(AVFormatContext *s, int64_t 
> file_size,
>  int64_t header_offset, cur_pos, hpos;
>  int bit_rate;
>  int64_t duration;
> +int language_counts[128] = { 0 };
>  
>  ff_metadata_conv(>metadata, ff_asf_metadata_conv, NULL);
>  
> @@ -447,6 +448,7 @@ static int asf_write_header1(AVFormatContext *s, int64_t 
> file_size,
>  asf->streams[n].stream_language_index = 
> asf->nb_languages;
>  asf->nb_languages++;
>  }
> +language_counts[asf->streams[n].stream_language_index]++;
>  }
>  } else {
>  asf->streams[n].stream_language_index = 128;
> @@ -496,6 +498,19 @@ static int asf_write_header1(AVFormatContext *s, int64_t 
> file_size,
>  }
>  end_header(pb, hpos2);
>  
> +if (asf->nb_languages > 1) {
> +hpos2 = put_header(pb, _asf_group_mutual_exclusion_object);
> +ff_put_guid(pb, _asf_mutex_language);
> +avio_wl16(pb, asf->nb_languages);
> +for (i = 0; i < asf->nb_languages; i++) {
> +avio_wl16(pb, language_counts[i]);
> +for (n = 0; n < s->nb_streams; n++)
> +if (asf->streams[n].stream_language_index == i)
> +avio_wl16(pb, n + 1);
> +}
> +end_header(pb, hpos2);
> +}

would this make a subtitle and a audio track exclude each other ?
one can want a subtitle ad audio stream of the same language as well
as different languages play at teh same time

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

Democracy is the form of government in which you can choose your dictator


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

[FFmpeg-devel] [PATCH] vf_blend: Use integers for divide mode

[Timothy Gu]

2.5x faster for 8-bit mode without autovectorization in GCC, 2x
slower with it on x86. However, since the platforms we enable GCC
autovectorization on most probably has support for SSE2
optimization (added in the subsequent commit), this commit should
in general do good.
---
 libavfilter/vf_blend.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavfilter/vf_blend.c b/libavfilter/vf_blend.c
index 2b734b4..b9e5add 100644
--- a/libavfilter/vf_blend.c
+++ b/libavfilter/vf_blend.c
@@ -240,7 +240,7 @@ DEFINE_BLEND8(hardlight,  (B < 128) ? MULTIPLY(2, B, A) : 
SCREEN(2, B, A))
 DEFINE_BLEND8(hardmix,(A < (255 - B)) ? 0: 255)
 DEFINE_BLEND8(darken, FFMIN(A, B))
 DEFINE_BLEND8(lighten,FFMAX(A, B))
-DEFINE_BLEND8(divide, av_clip_uint8(((float)A / ((float)B) * 255)))
+DEFINE_BLEND8(divide, av_clip_uint8(B == 0 ? 255 : 255 * A / B))
 DEFINE_BLEND8(dodge,  DODGE(A, B))
 DEFINE_BLEND8(burn,   BURN(A, B))
 DEFINE_BLEND8(softlight,  (A > 127) ? B + (255 - B) * (A - 127.5) / 127.5 * 
(0.5 - fabs(B - 127.5) / 255): B - B * ((127.5 - A) / 127.5) * (0.5 - fabs(B - 
127.5)/255))
@@ -280,7 +280,7 @@ DEFINE_BLEND16(hardlight,  (B < 32768) ? MULTIPLY(2, B, A) 
: SCREEN(2, B, A))
 DEFINE_BLEND16(hardmix,(A < (65535 - B)) ? 0: 65535)
 DEFINE_BLEND16(darken, FFMIN(A, B))
 DEFINE_BLEND16(lighten,FFMAX(A, B))
-DEFINE_BLEND16(divide, av_clip_uint16(((float)A / ((float)B) * 65535)))
+DEFINE_BLEND16(divide, av_clip_uint16(B == 0 ? 65535 : 65535 * A / B))
 DEFINE_BLEND16(dodge,  DODGE(A, B))
 DEFINE_BLEND16(burn,   BURN(A, B))
 DEFINE_BLEND16(softlight,  (A > 32767) ? B + (65535 - B) * (A - 32767.5) / 
32767.5 * (0.5 - fabs(B - 32767.5) / 65535): B - B * ((32767.5 - A) / 32767.5) 
* (0.5 - fabs(B - 32767.5)/65535))
-- 
2.1.4

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

[FFmpeg-devel] [PATCH] x86/vf_blend: Add SSE2 optimization for divide

[Timothy Gu]

---
 libavfilter/x86/vf_blend.asm| 30 ++
 libavfilter/x86/vf_blend_init.c |  2 ++
 2 files changed, 32 insertions(+)

diff --git a/libavfilter/x86/vf_blend.asm b/libavfilter/x86/vf_blend.asm
index a5ea74c..303ea3a 100644
--- a/libavfilter/x86/vf_blend.asm
+++ b/libavfilter/x86/vf_blend.asm
@@ -24,6 +24,7 @@
 
 SECTION_RODATA
 
+ps_255: times 4 dd 255.0
 pw_1:   times 8 dw 1
 pw_128: times 8 dw 128
 pw_255: times 8 dw 255
@@ -219,6 +220,35 @@ BLEND_INIT hardmix, 5
 jl .loop
 BLEND_END
 
+BLEND_INIT divide, 4
+pxor   m2, m2
+mova   m3, [ps_255]
+.nextrow:
+movxq, widthq
+
+.loop:
+movdm0, [topq + xq]  ; 00xx
+movdm1, [bottomq + xq]
+punpcklbw   m0, m2   ; 0x0x
+punpcklbw   m1, m2
+punpcklwd   m0, m2   ; 000x000x
+punpcklwd   m1, m2
+
+cvtdq2psm0, m0
+cvtdq2psm1, m1
+divps   m0, m1   ; a / b
+mulps   m0, m3   ; a / b * 255
+minps   m0, m3
+cvttps2dq   m0, m0
+
+packssdwm0, m0   ; 0x0x
+packuswbm0, m0   ; 00xx
+movd   [dstq + xq], m0
+add xq, mmsize / 4
+
+jl .loop
+BLEND_END
+
 BLEND_INIT phoenix, 4
 mova   m3, [pb_255]
 .nextrow:
diff --git a/libavfilter/x86/vf_blend_init.c b/libavfilter/x86/vf_blend_init.c
index a6baf94..677e759 100644
--- a/libavfilter/x86/vf_blend_init.c
+++ b/libavfilter/x86/vf_blend_init.c
@@ -39,6 +39,7 @@ BLEND_FUNC(difference128, sse2)
 BLEND_FUNC(multiply, sse2)
 BLEND_FUNC(screen, sse2)
 BLEND_FUNC(hardmix, sse2)
+BLEND_FUNC(divide, sse2)
 BLEND_FUNC(lighten, sse2)
 BLEND_FUNC(or, sse2)
 BLEND_FUNC(phoenix, sse2)
@@ -61,6 +62,7 @@ av_cold void ff_blend_init_x86(FilterParams *param, int 
is_16bit)
 case BLEND_AVERAGE:  param->blend = ff_blend_average_sse2;  break;
 case BLEND_DARKEN:   param->blend = ff_blend_darken_sse2;   break;
 case BLEND_DIFFERENCE128: param->blend = ff_blend_difference128_sse2; 
break;
+case BLEND_DIVIDE:   param->blend = ff_blend_divide_sse2;   break;
 case BLEND_HARDMIX:  param->blend = ff_blend_hardmix_sse2;  break;
 case BLEND_LIGHTEN:  param->blend = ff_blend_lighten_sse2;  break;
 case BLEND_MULTIPLY: param->blend = ff_blend_multiply_sse2; break;
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH] x86/vf_blend: Add SSE4.1 optimization for divide

[Timothy Gu]

I've already answered these on IRC but for the sake of completion I'll include
the answers here as well.

On Sat, Feb 13, 2016 at 10:26:58PM -0300, James Almer wrote:
> On 2/13/2016 9:27 PM, Timothy Gu wrote:
> > ---
> > 
> > The reason why this function uses SSE4.1 is the roundps instruction. Would
> > love to find a way to truncate a float to integer in SSE2.

CVTTPS2DQ—Convert with Truncation Packed Single-Precision FP Values to Packed
Dword Integers

> > +punpcklwd   m0, m2   ; 000x000x
> > +punpcklwd   m1, m2
> > +
> > +cvtdq2psm0, m0
> > +cvtdq2psm1, m1
> > +divps   m0, m1   ; a / b
> > +mulps   m0, m3   ; a / b * 255
> > +roundps m0, m0, 3; truncate
> > +minps   m0, m3
> 
> Are these two really needed? After a quick glance GCC seems to simply 
> generate more
> or less the same code you're using here sans these two. (convert to float, 
> div, mul,
> convert to int, saturate to uint8_t).

roundps becomes unnecessary after cvttps2dq. minps is needed for divide-by-0
cases.

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

[FFmpeg-devel] [PATCH 3/3] lavf/mpjpeg: do not include CRLF preceding boundary as, part of the returned frame

[Alexander Agranovsky]

From b2ef061db32933e896dbeecb68268a62c47d6e0a Mon Sep 17 00:00:00 2001
From: Alex Agranovsky 
Date: Sat, 13 Feb 2016 23:16:45 -0500
Subject: [PATCH 3/3] lavf/mpjpeg: do not include CRLF preceding boundary as
 part of the returned frame

Signed-off-by: Alex Agranovsky 
---
 libavformat/mpjpegdec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
index 2a46671..9d539bb 100644
--- a/libavformat/mpjpegdec.c
+++ b/libavformat/mpjpegdec.c
@@ -351,8 +351,8 @@ static int mpjpeg_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 do {
 if (!memcmp(start, mpjpeg->searchstr, mpjpeg->searchstr_len)) {
 // got the boundary! rewind the stream
-avio_seek(s->pb, -(len-2), SEEK_CUR);
-pkt->size -= (len-2);
+avio_seek(s->pb, -len, SEEK_CUR);
+pkt->size -= len;
 return pkt->size;
 }
 len--;
-- 
2.5.4 (Apple Git-61)

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

[FFmpeg-devel] [PATCH 1/2] lavc/rawdec: Remove temporary switching code for 1 bpp AVI without a palette

[Mats Peterson]

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 without a palette

---
 libavcodec/rawdec.c   |   19 ---
 tests/ref/vsynth/vsynth1-bpp1 |4 ++--
 tests/ref/vsynth/vsynth2-bpp1 |4 ++--
 tests/ref/vsynth/vsynth3-bpp1 |4 ++--
 tests/ref/vsynth/vsynth_lena-bpp1 |4 ++--
 5 files changed, 8 insertions(+), 27 deletions(-)

diff --git a/libavcodec/rawdec.c b/libavcodec/rawdec.c
index 287be96..10bca05 100644
--- a/libavcodec/rawdec.c
+++ b/libavcodec/rawdec.c
@@ -128,10 +128,6 @@ static av_cold int raw_init_decoder(AVCodecContext *avctx)
 avctx->pix_fmt   == AV_PIX_FMT_YUYV422)
 context->is_yuv2 = 1;
 
-/* Temporary solution until PAL8 is implemented in nut */
-if (context->is_pal8 && avctx->bits_per_coded_sample == 1)
-avctx->pix_fmt = AV_PIX_FMT_NONE;
-
 return 0;
 }
 
@@ -206,21 +202,6 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
 return AVERROR_INVALIDDATA;
 }
 
-/* Temporary solution until PAL8 is implemented in nut */
-if (avctx->pix_fmt == AV_PIX_FMT_NONE &&
-avctx->bits_per_coded_sample == 1 &&
-avctx->frame_number == 0 &&
-context->palette &&
-AV_RB64(context->palette->data) == 0x
-) {
-const uint8_t *pal = av_packet_get_side_data(avpkt, AV_PKT_DATA_PALETTE, NULL);
-if (!pal) {
-avctx->pix_fmt = AV_PIX_FMT_MONOWHITE;
-context->is_pal8 = 0;
-context->is_mono = 1;
-} else
-avctx->pix_fmt = AV_PIX_FMT_PAL8;
-}
 desc = av_pix_fmt_desc_get(avctx->pix_fmt);
 
 if ((avctx->bits_per_coded_sample == 8 || avctx->bits_per_coded_sample == 4
diff --git a/tests/ref/vsynth/vsynth1-bpp1 b/tests/ref/vsynth/vsynth1-bpp1
index 0bd1a77..0abadd6 100644
--- a/tests/ref/vsynth/vsynth1-bpp1
+++ b/tests/ref/vsynth/vsynth1-bpp1
@@ -1,4 +1,4 @@
 611de0803ff6bd0ef385dde59964a105 *tests/data/fate/vsynth1-bpp1.avi
 640452 tests/data/fate/vsynth1-bpp1.avi
-576b690e8a8921c54d777463b63a8307 *tests/data/fate/vsynth1-bpp1.out.rawvideo
-stddev:   97.41 PSNR:  8.36 MAXDIFF:  238 bytes:  7603200/  7603200
+cd1e1448d9895561347ceb66d0add34d *tests/data/fate/vsynth1-bpp1.out.rawvideo
+stddev:   84.48 PSNR:  9.60 MAXDIFF:  218 bytes:  7603200/  7603200
diff --git a/tests/ref/vsynth/vsynth2-bpp1 b/tests/ref/vsynth/vsynth2-bpp1
index d283d6c..38e745f 100644
--- a/tests/ref/vsynth/vsynth2-bpp1
+++ b/tests/ref/vsynth/vsynth2-bpp1
@@ -1,4 +1,4 @@
 b51ad49892eb8f8912c5a983718a17bb *tests/data/fate/vsynth2-bpp1.avi
 640452 tests/data/fate/vsynth2-bpp1.avi
-338fb9039a4564e471bf8179f0c48a95 *tests/data/fate/vsynth2-bpp1.out.rawvideo
-stddev:   80.40 PSNR: 10.02 MAXDIFF:  238 bytes:  7603200/  7603200
+f0dfc0e87e5d96bce29a5944b1bd7471 *tests/data/fate/vsynth2-bpp1.out.rawvideo
+stddev:   68.98 PSNR: 11.36 MAXDIFF:  218 bytes:  7603200/  7603200
diff --git a/tests/ref/vsynth/vsynth3-bpp1 b/tests/ref/vsynth/vsynth3-bpp1
index 5a65728..b4267cf 100644
--- a/tests/ref/vsynth/vsynth3-bpp1
+++ b/tests/ref/vsynth/vsynth3-bpp1
@@ -1,4 +1,4 @@
 98852649c5201df7d85d0e9b5a5b9f15 *tests/data/fate/vsynth3-bpp1.avi
 15352 tests/data/fate/vsynth3-bpp1.avi
-0b1ea21b69d384564dd3a978065443b2 *tests/data/fate/vsynth3-bpp1.out.rawvideo
-stddev:   97.64 PSNR:  8.34 MAXDIFF:  248 bytes:86700/86700
+52ae74ef7910e5b603c12288d425b9ae *tests/data/fate/vsynth3-bpp1.out.rawvideo
+stddev:   84.76 PSNR:  9.57 MAXDIFF:  232 bytes:86700/86700
diff --git a/tests/ref/vsynth/vsynth_lena-bpp1 b/tests/ref/vsynth/vsynth_lena-bpp1
index 63ab9e1..2577733 100644
--- a/tests/ref/vsynth/vsynth_lena-bpp1
+++ b/tests/ref/vsynth/vsynth_lena-bpp1
@@ -1,4 +1,4 @@
 2859022fac452b59e49a1189c4fbb3ec *tests/data/fate/vsynth_lena-bpp1.avi
 640452 tests/data/fate/vsynth_lena-bpp1.avi
-3be3497f8ca548c9196dcecc5bc7cb2b *tests/data/fate/vsynth_lena-bpp1.out.rawvideo
-stddev:   96.52 PSNR:  8.44 MAXDIFF:  231 bytes:  7603200/  7603200
+6183ba861d4e48d4aaefc514fde270e5 *tests/data/fate/vsynth_lena-bpp1.out.rawvideo
+stddev:   83.28 PSNR:  9.72 MAXDIFF:  215 bytes:  7603200/  7603200
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH 2/2] lavc/rawdec: Retrieve nut palette in packets

[Mats Peterson]

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 +0100
Subject: [PATCH 2/2] lavc/rawdec: Retrieve nut palette in packets

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

diff --git a/libavcodec/rawdec.c b/libavcodec/rawdec.c
index 10bca05..b401452 100644
--- a/libavcodec/rawdec.c
+++ b/libavcodec/rawdec.c
@@ -365,7 +365,6 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
 if (avctx->pix_fmt == AV_PIX_FMT_PAL8) {
 const uint8_t *pal = av_packet_get_side_data(avpkt, AV_PKT_DATA_PALETTE,
  NULL);
-
 if (pal) {
 av_buffer_unref(>palette);
 context->palette = av_buffer_alloc(AVPALETTE_SIZE);
@@ -375,6 +374,14 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
 }
 memcpy(context->palette->data, pal, AVPALETTE_SIZE);
 frame->palette_has_changed = 1;
+} else if (context->is_nut_pal8) {
+int vid_size = avctx->width * avctx->height;
+vid_size = (vid_size + 3) & ~3;
+if (avpkt->size - vid_size) {
+uint8_t *pal = avpkt->data + vid_size;
+memcpy(context->palette->data, pal, AVPALETTE_SIZE);
+frame->palette_has_changed = 1;
+}
 }
 }
 
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH 2/2] lavc/rawdec: Retrieve nut palette in packets

[Mats Peterson]

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

[FFmpeg-devel] [PATCH 2/2 v2] lavc/rawdec: Retrieve nut palette in packets

[Mats Peterson]

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 2001
From: Mats Peterson 
Date: Sun, 14 Feb 2016 07:13:24 +0100
Subject: [PATCH 2/2] lavc/rawdec: Retrieve nut palette in packets

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

diff --git a/libavcodec/rawdec.c b/libavcodec/rawdec.c
index 10bca05..b86e5c3 100644
--- a/libavcodec/rawdec.c
+++ b/libavcodec/rawdec.c
@@ -365,7 +365,6 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
 if (avctx->pix_fmt == AV_PIX_FMT_PAL8) {
 const uint8_t *pal = av_packet_get_side_data(avpkt, AV_PKT_DATA_PALETTE,
  NULL);
-
 if (pal) {
 av_buffer_unref(>palette);
 context->palette = av_buffer_alloc(AVPALETTE_SIZE);
@@ -375,6 +374,14 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
 }
 memcpy(context->palette->data, pal, AVPALETTE_SIZE);
 frame->palette_has_changed = 1;
+} else if (context->is_nut_pal8) {
+int vid_size = avctx->width * avctx->height;
+vid_size = (vid_size + 3) & ~3;
+if (avpkt->size - vid_size) {
+uint8_t *pal = avpkt->data + vid_size;
+memcpy(context->palette->data, pal, avpkt->size - vid_size);
+frame->palette_has_changed = 1;
+}
 }
 }
 
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH] x86/vf_blend: Add SSE4.1 optimization for divide

[James Almer]

On 2/13/2016 9:27 PM, Timothy Gu wrote:
> ---
> 
> The reason why this function uses SSE4.1 is the roundps instruction. Would
> love to find a way to truncate a float to integer in SSE2.
> 
> ---
>  libavfilter/x86/vf_blend.asm| 32 
>  libavfilter/x86/vf_blend_init.c |  6 ++
>  2 files changed, 38 insertions(+)
> 
> diff --git a/libavfilter/x86/vf_blend.asm b/libavfilter/x86/vf_blend.asm
> index a5ea74c..dac04d7 100644
> --- a/libavfilter/x86/vf_blend.asm
> +++ b/libavfilter/x86/vf_blend.asm
> @@ -24,6 +24,7 @@
>  
>  SECTION_RODATA
>  
> +ps_255: times 4 dd 255.0
>  pw_1:   times 8 dw 1
>  pw_128: times 8 dw 128
>  pw_255: times 8 dw 255
> @@ -285,3 +286,34 @@ INIT_XMM sse2
>  BLEND_ABS
>  INIT_XMM ssse3
>  BLEND_ABS
> +
> +INIT_XMM sse4
> +BLEND_INIT divide, 4
> +pxor   m2, m2
> +mova   m3, [ps_255]
> +.nextrow:
> +movxq, widthq
> +
> +.loop:
> +movdm0, [topq + xq]  ; 00xx
> +movdm1, [bottomq + xq]
> +punpcklbw   m0, m2   ; 0x0x
> +punpcklbw   m1, m2

Assuming you keep using sse4, you could instead do

pmovzxbd m0, [topq + xq]
pmovzxbd m1, [bottomq + xq]

> +punpcklwd   m0, m2   ; 000x000x
> +punpcklwd   m1, m2
> +
> +cvtdq2psm0, m0
> +cvtdq2psm1, m1
> +divps   m0, m1   ; a / b
> +mulps   m0, m3   ; a / b * 255
> +roundps m0, m0, 3; truncate
> +minps   m0, m3

Are these two really needed? After a quick glance GCC seems to simply generate 
more
or less the same code you're using here sans these two. (convert to float, div, 
mul,
convert to int, saturate to uint8_t).

> +cvtps2dqm0, m0
> +
> +packusdwm0, m0   ; 0x0x
> +packuswbm0, m0   ; 00xx
> +movd   [dstq + xq], m0
> +add xq, mmsize / 4
> +
> +jl .loop
> +BLEND_END
> diff --git a/libavfilter/x86/vf_blend_init.c b/libavfilter/x86/vf_blend_init.c
> index a6baf94..f542870 100644
> --- a/libavfilter/x86/vf_blend_init.c
> +++ b/libavfilter/x86/vf_blend_init.c
> @@ -48,6 +48,7 @@ BLEND_FUNC(difference, sse2)
>  BLEND_FUNC(difference, ssse3)
>  BLEND_FUNC(negation, sse2)
>  BLEND_FUNC(negation, ssse3)
> +BLEND_FUNC(divide, sse4)
>  
>  av_cold void ff_blend_init_x86(FilterParams *param, int is_16bit)
>  {
> @@ -79,4 +80,9 @@ av_cold void ff_blend_init_x86(FilterParams *param, int 
> is_16bit)
>  case BLEND_NEGATION:   param->blend = ff_blend_negation_ssse3;   
> break;
>  }
>  }
> +if (EXTERNAL_SSE4(cpu_flags) && param->opacity == 1 && !is_16bit) {
> +switch (param->mode) {
> +case BLEND_DIVIDE:   param->blend = ff_blend_divide_sse4;   break;
> +}
> +}
>  }
> 

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

Re: [FFmpeg-devel] [PATCH v3] libavcodec/dnxhd_parser: add parser and probe support raw 444 and dnxhr formats

[Michael Niedermayer]

On Sat, Feb 13, 2016 at 04:35:24PM -0800, Mark Reid wrote:
> ---
>  libavcodec/dnxhd_parser.c |  7 +++
>  libavcodec/dnxhddata.c|  8 
>  libavcodec/dnxhddata.h| 18 +-
>  libavcodec/dnxhddec.c | 12 
>  libavformat/dnxhddec.c|  7 ---
>  5 files changed, 36 insertions(+), 16 deletions(-)
> 
> diff --git a/libavcodec/dnxhd_parser.c b/libavcodec/dnxhd_parser.c
> index fffb98f..033b8ee 100644
> --- a/libavcodec/dnxhd_parser.c
> +++ b/libavcodec/dnxhd_parser.c
> @@ -25,8 +25,7 @@
>   */
>  
>  #include "parser.h"
> -
> -#define DNXHD_HEADER_PREFIX 0x02800100
> +#include "dnxhddata.h"
>  
>  typedef struct {
>  ParseContext pc;
> @@ -47,7 +46,7 @@ static int dnxhd_find_frame_end(DNXHDParserContext *dctx,
>  if (!pic_found) {
>  for (i = 0; i < buf_size; i++) {
>  state = (state << 8) | buf[i];
> -if ((state & 0xff00LL) == DNXHD_HEADER_PREFIX) {
> +if (ff_dnxhd_check_header_prefix(state & 0xff00LL) != 0) 
> {
>  i++;
>  pic_found = 1;
>  interlaced = (state&2)>>1; /* byte following the 5-byte 
> header prefix */
> @@ -62,7 +61,7 @@ static int dnxhd_find_frame_end(DNXHDParserContext *dctx,
>  return 0;
>  for (; i < buf_size; i++) {
>  state = (state << 8) | buf[i];
> -if ((state & 0xff00LL) == DNXHD_HEADER_PREFIX) {
> +if (ff_dnxhd_check_header_prefix(state & 0xff00LL) != 0) 
> {
>  if (!interlaced || dctx->cur_field) {
>  pc->frame_start_found = 0;
>  pc->state64 = -1;
> diff --git a/libavcodec/dnxhddata.c b/libavcodec/dnxhddata.c
> index 82fbfdf..6955fd0 100644
> --- a/libavcodec/dnxhddata.c
> +++ b/libavcodec/dnxhddata.c
> @@ -22,6 +22,7 @@
>  #include "avcodec.h"
>  #include "dnxhddata.h"
>  #include "libavutil/common.h"
> +#include "libavutil/intreadwrite.h"
>  
>  /* The quantization tables below are in zigzag order! */
>  
> @@ -1102,6 +1103,13 @@ int avpriv_dnxhd_get_interlaced(int cid)
>  return ff_dnxhd_cid_table[i].flags & DNXHD_INTERLACED ? 1 : 0;
>  }
>  
> +uint64_t avpriv_dnxhd_parse_header_prefix(const uint8_t *buf)
> +{
> +  uint64_t prefix = AV_RB32(buf);
> +  prefix = (prefix << 16) | buf[4] << 8;
> +  return ff_dnxhd_check_header_prefix(prefix);
> +}
> +

[...]

> +static av_always_inline uint64_t ff_dnxhd_check_header_prefix(uint64_t 
> prefix)
> +{
> +  if (prefix == DNXHD_HEADER_INITIAL ||
> +  prefix == DNXHD_HEADER_444 ||
> +  prefix == DNXHD_HEADER_HR1 ||
> +  prefix == DNXHD_HEADER_HR2)
> +return prefix;
> +  return 0;
> +}

the indention depth is inconsistent with the existing code

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

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.


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

[FFmpeg-devel] [PATCH v4] libavcodec/dnxhd_parser: add parser and probe support raw 444 and dnxhr formats

[Mark Reid]

---
 libavcodec/dnxhd_parser.c |  7 +++
 libavcodec/dnxhddata.c|  8 
 libavcodec/dnxhddata.h| 18 +-
 libavcodec/dnxhddec.c | 12 
 libavformat/dnxhddec.c|  7 ---
 5 files changed, 36 insertions(+), 16 deletions(-)

diff --git a/libavcodec/dnxhd_parser.c b/libavcodec/dnxhd_parser.c
index fffb98f..033b8ee 100644
--- a/libavcodec/dnxhd_parser.c
+++ b/libavcodec/dnxhd_parser.c
@@ -25,8 +25,7 @@
  */
 
 #include "parser.h"
-
-#define DNXHD_HEADER_PREFIX 0x02800100
+#include "dnxhddata.h"
 
 typedef struct {
 ParseContext pc;
@@ -47,7 +46,7 @@ static int dnxhd_find_frame_end(DNXHDParserContext *dctx,
 if (!pic_found) {
 for (i = 0; i < buf_size; i++) {
 state = (state << 8) | buf[i];
-if ((state & 0xff00LL) == DNXHD_HEADER_PREFIX) {
+if (ff_dnxhd_check_header_prefix(state & 0xff00LL) != 0) {
 i++;
 pic_found = 1;
 interlaced = (state&2)>>1; /* byte following the 5-byte header 
prefix */
@@ -62,7 +61,7 @@ static int dnxhd_find_frame_end(DNXHDParserContext *dctx,
 return 0;
 for (; i < buf_size; i++) {
 state = (state << 8) | buf[i];
-if ((state & 0xff00LL) == DNXHD_HEADER_PREFIX) {
+if (ff_dnxhd_check_header_prefix(state & 0xff00LL) != 0) {
 if (!interlaced || dctx->cur_field) {
 pc->frame_start_found = 0;
 pc->state64 = -1;
diff --git a/libavcodec/dnxhddata.c b/libavcodec/dnxhddata.c
index 82fbfdf..7d935a3 100644
--- a/libavcodec/dnxhddata.c
+++ b/libavcodec/dnxhddata.c
@@ -22,6 +22,7 @@
 #include "avcodec.h"
 #include "dnxhddata.h"
 #include "libavutil/common.h"
+#include "libavutil/intreadwrite.h"
 
 /* The quantization tables below are in zigzag order! */
 
@@ -1102,6 +1103,13 @@ int avpriv_dnxhd_get_interlaced(int cid)
 return ff_dnxhd_cid_table[i].flags & DNXHD_INTERLACED ? 1 : 0;
 }
 
+uint64_t avpriv_dnxhd_parse_header_prefix(const uint8_t *buf)
+{
+uint64_t prefix = AV_RB32(buf);
+prefix = (prefix << 16) | buf[4] << 8;
+return ff_dnxhd_check_header_prefix(prefix);
+}
+
 int ff_dnxhd_find_cid(AVCodecContext *avctx, int bit_depth)
 {
 int i, j;
diff --git a/libavcodec/dnxhddata.h b/libavcodec/dnxhddata.h
index d973888..3ae4683 100644
--- a/libavcodec/dnxhddata.h
+++ b/libavcodec/dnxhddata.h
@@ -31,6 +31,12 @@
 #define DNXHD_MBAFF(1<<1)
 #define DNXHD_444  (1<<2)
 
+/** Frame headers, extra 0x00 added to end for parser */
+#define DNXHD_HEADER_INITIAL 0x02800100
+#define DNXHD_HEADER_444 0x02800200
+#define DNXHD_HEADER_HR1 0x02800300
+#define DNXHD_HEADER_HR2 0x038C0300
+
 /** Indicate that a CIDEntry value must be read in the bitstream */
 #define DNXHD_VARIABLE 0
 
@@ -59,7 +65,17 @@ int ff_dnxhd_get_cid_table(int cid);
 int ff_dnxhd_find_cid(AVCodecContext *avctx, int bit_depth);
 void ff_dnxhd_print_profiles(AVCodecContext *avctx, int loglevel);
 
+static av_always_inline uint64_t ff_dnxhd_check_header_prefix(uint64_t prefix)
+{
+if (prefix == DNXHD_HEADER_INITIAL ||
+prefix == DNXHD_HEADER_444 ||
+prefix == DNXHD_HEADER_HR1 ||
+prefix == DNXHD_HEADER_HR2)
+return prefix;
+return 0;
+}
+
 int avpriv_dnxhd_get_frame_size(int cid);
 int avpriv_dnxhd_get_interlaced(int cid);
-
+uint64_t avpriv_dnxhd_parse_header_prefix(const uint8_t *buf);
 #endif /* AVCODEC_DNXHDDATA_H */
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index 5c09c64..1808080 100644
--- a/libavcodec/dnxhddec.c
+++ b/libavcodec/dnxhddec.c
@@ -163,21 +163,17 @@ static int dnxhd_decode_header(DNXHDContext *ctx, AVFrame 
*frame,
const uint8_t *buf, int buf_size,
int first_field)
 {
-static const uint8_t header_prefix[]= { 0x00, 0x00, 0x02, 0x80, 0x01 };
-static const uint8_t header_prefix444[] = { 0x00, 0x00, 0x02, 0x80, 0x02 };
-static const uint8_t header_prefixhr1[] = { 0x00, 0x00, 0x02, 0x80, 0x03 };
-static const uint8_t header_prefixhr2[] = { 0x00, 0x00, 0x03, 0x8C, 0x03 };
 int i, cid, ret;
 int old_bit_depth = ctx->bit_depth, bitdepth;
-
+uint64_t header_prefix;
 if (buf_size < 0x280) {
 av_log(ctx->avctx, AV_LOG_ERROR,
"buffer too small (%d < 640).\n", buf_size);
 return AVERROR_INVALIDDATA;
 }
 
-if (memcmp(buf, header_prefix, 5) && memcmp(buf, header_prefix444, 5) &&
-memcmp(buf, header_prefixhr1, 5) && memcmp(buf, header_prefixhr2, 5)) {
+header_prefix = avpriv_dnxhd_parse_header_prefix(buf);
+if (header_prefix == 0) {
 av_log(ctx->avctx, AV_LOG_ERROR,
"unknown header 0x%02X 0x%02X 0x%02X 0x%02X 0x%02X\n",
buf[0], buf[1], buf[2], buf[3], buf[4]);
@@ -279,7 +275,7 @@ static int dnxhd_decode_header(DNXHDContext *ctx, 

[FFmpeg-devel] [PATCH v4] libavcodec/dnxhd_parser: add parser and probe support raw 444 and dnxhr formats

[Mark Reid]

changes since v3:
fixed inconsistent indentation.

Mark Reid (1):
  libavcodec/dnxhd_parser: add parser and probe support raw 444 and
dnxhr formats

 libavcodec/dnxhd_parser.c |  7 +++
 libavcodec/dnxhddata.c|  8 
 libavcodec/dnxhddata.h| 18 +-
 libavcodec/dnxhddec.c | 12 
 libavformat/dnxhddec.c|  7 ---
 5 files changed, 36 insertions(+), 16 deletions(-)

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

[FFmpeg-devel] [PATCH 2/2 v3] lavc/rawdec: Retrieve nut palette in packets

[Mats Peterson]

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 |9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/libavcodec/rawdec.c b/libavcodec/rawdec.c
index 10bca05..d998f8e 100644
--- a/libavcodec/rawdec.c
+++ b/libavcodec/rawdec.c
@@ -365,7 +365,6 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
 if (avctx->pix_fmt == AV_PIX_FMT_PAL8) {
 const uint8_t *pal = av_packet_get_side_data(avpkt, AV_PKT_DATA_PALETTE,
  NULL);
-
 if (pal) {
 av_buffer_unref(>palette);
 context->palette = av_buffer_alloc(AVPALETTE_SIZE);
@@ -375,6 +374,14 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
 }
 memcpy(context->palette->data, pal, AVPALETTE_SIZE);
 frame->palette_has_changed = 1;
+} else if (context->is_nut_pal8) {
+int vid_size = avctx->width * avctx->height;
+vid_size = (vid_size + 3) & ~3;
+if (avpkt->size - vid_size) {
+pal = avpkt->data + vid_size;
+memcpy(context->palette->data, pal, avpkt->size - vid_size);
+frame->palette_has_changed = 1;
+}
 }
 }
 
-- 
1.7.10.4

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