Use cellular automata and fluidsynth sequencer to generate tones in major
pentatonic scale
diff --git a/Changelog b/Changelog
index d1572553a5..5ddd2484b0 100644
--- a/Changelog
+++ b/Changelog
@@ -48,6 +48,7 @@ version :
- AMQP 0-9-1 protocol (RabbitMQ)
- Vulkan support
- avgblur_vulkan, over
Quoting James Almer (2020-03-16 22:30:00)
> This commit follows the same logic as 061a0c14bb, but for the encode API: The
> new public encoding API will no longer be a wrapper around the old deprecated
> one, and the internal API used by the encoders now consists of a single
> receive_packet() call
Quoting James Almer (2020-03-16 22:30:01)
> Following the same logic as 061a0c14bb, this commit turns the old encode API
> into a wrapper for the new one.
>
> Signed-off-by: James Almer
> ---
> This could be squashed with the previous commit, like it was done in
> 061a0c14bb,
> but i figured it
Ashutosh Pradhan (12020-03-26):
> Use cellular automata and fluidsynth sequencer to generate tones in major
> pentatonic scale
Can you explain the use cases for this filter?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
I was trying to random tones using cellular automata (it won't sound good
if the tones are too random so I used a scale) for the GSoC audio tones
filter project.
On Thu, Mar 26, 2020 at 2:41 PM Nicolas George wrote:
> Ashutosh Pradhan (12020-03-26):
> > Use cellular automata and fluidsynth seque
Ashutosh Pradhan (12020-03-26):
> I was trying to random tones using cellular automata (it won't sound good
> if the tones are too random so I used a scale) for the GSoC audio tones
> filter project.
Yes, that's already in the doc. What I ask is what good you expect from
it.
> On Thu, Mar 26, 202
Quoting Andreas Rheinhardt (2020-03-22 04:47:36)
> Also simply return 0 in case a packet has been successfully read.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/nsvdec.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
Looks ok.
--
Anton Khirnov
Quoting Andreas Rheinhardt (2020-03-22 04:47:37)
> Also return 0 after successfully reading a packet.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/yop.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
ok
--
Anton Khirnov
__
Quoting Andreas Rheinhardt (2020-03-22 04:47:38)
> Forgotten in 6a67d518.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/mpeg.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
Looks ok
--
Anton Khirnov
___
ffmpeg-devel mai
Quoting Andreas Rheinhardt (2020-03-20 17:51:41)
> Jan Ekström:
> > On Fri, Mar 20, 2020 at 5:45 PM wrote:
> >>
> >> From: Limin Wang
> >>
> >> This fixes webvtt segment output.
> >>
> >> Please testing with the following command and check the output:
> >> ./ffmpeg -i ../fate-suite/sub/MicroDVD_c
On 3/26/20, Nicolas George wrote:
> Ashutosh Pradhan (12020-03-26):
>> I was trying to random tones using cellular automata (it won't sound good
>> if the tones are too random so I used a scale) for the GSoC audio tones
>> filter project.
>
> Yes, that's already in the doc. What I ask is what good
On Thu, Mar 26, 2020 at 2:53 PM Nicolas George wrote:
> Ashutosh Pradhan (12020-03-26):
> > I was trying to random tones using cellular automata (it won't sound good
> > if the tones are too random so I used a scale) for the GSoC audio tones
> > filter project.
>
> Yes, that's already in the doc.
Paul B Mahol (12020-03-26):
> What kind of insinuation is this?
No insinuation at all, just an honest question.
> This is qualification task for GSoC project, if you have something against it,
> ask me directly instead.
Of course, feel free to answer the question. What is the use case for
this f
Ashutosh Pradhan (12020-03-26):
> Since random tones generated using seed( ) was already sent on the mailing
> list, Paul had suggested me to control the duration between tones and to
> generate tones using cellular automata.
I am not asking what YOU are doing, I am asking what benefits our users
Quoting Andreas Rheinhardt (2020-02-12 16:02:21)
> av_packet_ref() mostly treated the destination packet dst as uninitialized,
> i.e. the destination fields were simply overwritten. But if the source
> packet was not reference-counted, dst->buf was treated as if it pointed
> to an already allocated
Quoting Andreas Rheinhardt (2020-03-13 14:28:33)
> It already initializes the packet.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> Resending because of 3117f47f19d051d47ba29c9b78c2ca525f0fdb45.
>
> fftools/ffplay.c | 2 +-
> libavcodec/qsvdec_h2645.c | 2 +-
> libavcodec/qsvdec_other.
On 3/26/20, Nicolas George wrote:
> Paul B Mahol (12020-03-26):
>> What kind of insinuation is this?
>
> No insinuation at all, just an honest question.
We will see...
>
>> This is qualification task for GSoC project, if you have something against
>> it,
>> ask me directly instead.
>
> Of course
Paul B Mahol (12020-03-26):
> > No insinuation at all, just an honest question.
> We will see...
This... is an insinuation.
> Use case is to generate nice listenable music that is computer generated.
> This filter as is just prototype and is not meant to be applied in
> current version but only w
On 3/26/20, Nicolas George wrote:
> Paul B Mahol (12020-03-26):
>> > No insinuation at all, just an honest question.
>> We will see...
>
> This... is an insinuation.
>
>> Use case is to generate nice listenable music that is computer generated.
>> This filter as is just prototype and is not meant
Paul B Mahol (12020-03-26):
> That is just your biased opinion.
No, that is not my opinion, that is the position of the project for
years: we don't control external libraries, their output can change from
one version to the next or with forks and patched versions. Only
internal implementation is s
On 3/26/20, Nicolas George wrote:
> Paul B Mahol (12020-03-26):
>> That is just your biased opinion.
>
> No, that is not my opinion, that is the position of the project for
> years: we don't control external libraries, their output can change from
> one version to the next or with forks and patche
Paul B Mahol (12020-03-26):
> Apparently you are talking about completely different and irrelevant stuff
> for this task.
Apparently, you did not read my previous mails very carefully, because I
already explained.
--
Nicolas George
___
ffmpeg-devel m
Am 26.03.20 um 11:24 schrieb Nicolas George:
> Paul B Mahol (12020-03-26):
>> Apparently you are talking about completely different and irrelevant stuff
>> for this task.
>
> Apparently, you did not read my previous mails very carefully, because I
> already explained.
Please let's stop here, we'r
Thanks for your feedback. Please see the attached patch with all the style
changes addressed which also applies properly.
0001-avformat-Add-Dynacolor-MVC-Demuxer.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https:
Am 26.03.20 um 10:48 schrieb Paul B Mahol:
> On 3/26/20, Nicolas George wrote:
>> Ashutosh Pradhan (12020-03-26):
>>> I was trying to random tones using cellular automata (it won't sound good
>>> if the tones are too random so I used a scale) for the GSoC audio tones
>>> filter project.
>>
>> Yes,
On Thu, 26 Mar 2020, Carl Eugen Hoyos wrote:
Hi!
Attached patch removes an ugly warning shown for every file when using
clang-cl.exe.
Please comment, Carl Eugen
LGTM
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.o
On Thu, 26 Mar 2020, Carl Eugen Hoyos wrote:
Hi!
Attached patch avoids that ffmpeg claims its compiler was "No input
file" when using clang-cl.
Please comment, Carl Eugen
@@ -4663,7 +4663,11 @@ probe_cc(){
_ld_path='-libpath:'
elif $_cc -nologo- 2>&1 | grep -q Microsoft || { $
Quoting Linjie Fu (2019-12-27 09:47:35)
> Resolution/format changes lead to re-initialization of hardware
> accelerations(vaapi/dxva2/..) with new hwaccel_priv_data in
> the worker-thread. But hwaccel_priv_data in user context won't
> be updated until the resolution changing frame is output.
>
> A
Thilo Borgmann (12020-03-26):
> Let's look at this. There are two things here:
>
> a) Is it a good enough solution of the qualfification task Paul has
> given to Ashutosh?
>
> b) Is it unsuitable to apply? Well that might be but we need to get
> clear about a) for the sake of GSoC.
>
> Also, a)
Am 26.03.20 um 11:58 schrieb Nicolas George:
> Thilo Borgmann (12020-03-26):
>> Let's look at this. There are two things here:
>>
>> a) Is it a good enough solution of the qualfification task Paul has
>> given to Ashutosh?
>>
>> b) Is it unsuitable to apply? Well that might be but we need to get
>>
Thilo Borgmann (12020-03-26):
> Ok. So if I understand all of this correctly, the overall goal of the
> tones project is already redundant to your old proposal (or at least
> partially, Paul?).
I do not know what the overall goal of the tones project is: I have not
seen it discussed on the list.
Quoting Linjie Fu (2020-03-05 08:47:37)
> Fix overflow for coeff -32768 in function ADD_RES_MMX_4_8 with no
> performance drop.
>
> ./checkasm --test=hevc_add_res --bench
>
> Mainline:
> - hevc_add_res.add_residual [OK]
> hevc_add_res_4x4_8_mmxext: 15.5
>
> Add overflow test case:
> - he
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/hlsenc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index d7b9c0e20a..694dab42dd 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2950,13 +2950,11 @
From: Limin Wang
Please testing with the following command:
./ffmpeg -y -i input.mkv \
-b:v:0 5250k -c:v h264 -pix_fmt yuv420p -profile:v main -level 4.1 \
-b:a:0 256k \
-c:a mp2 -ar 48000 -ac 2 -map 0:v -map 0:a:0\
-f hls -var_stream_map "v:0,a:0" \
-master_pl_name master.m3u8 -t 300 -hls_t
From: Limin Wang
Test with the following command for the webvtt subtitle:
$ ./ffmpeg -y -i input_with_subtitle.mkv \
-b:v:0 5250k -c:v h264 -pix_fmt yuv420p -profile:v main -level 4.1 \
-b:a:0 256k \
-c:s webvtt -c:a mp2 -ar 48000 -ac 2 -map 0:v -map 0:a:0 -map 0:s:0 \
-f hls -var_stream_map
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/hlsplaylist.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/hlsplaylist.c b/libavformat/hlsplaylist.c
index 9cbd02353f..56244496c0 100644
--- a/libavformat/hlsplaylist.c
+++ b/libavformat/hlsplayl
Quoting James Almer (2020-03-25 18:56:44)
> Increase it in a linear way instead.
> Helps reduce memory usage, especially on long, non fragmented output.
>
> Signed-off-by: James Almer
> ---
> An alternative is using av_fast_realloc(), in a similar fashion as
> ff_add_index_entry(), which will kee
Quoting Andreas Rheinhardt (2020-03-26 01:41:42)
> Signed-off-by: Andreas Rheinhardt
> ---
> This has already been sent in [1]; I'm resending it because it fits
> here.
>
> [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-December/254841.html
>
> libavformat/matroskadec.c | 4 ++--
> 1 file
Quoting Andreas Rheinhardt (2020-03-26 01:41:43)
> A Block (meaning both a Block in a BlockGroup as well as a SimpleBlock)
> must have at least three bytes after the field containing the encoded
> TrackNumber. So a if there are <= 3 bytes, the Matroska demuxer would
> skip this block, believing it
On 3/26/2020 11:06 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-03-25 18:56:44)
>> Increase it in a linear way instead.
>> Helps reduce memory usage, especially on long, non fragmented output.
>>
>> Signed-off-by: James Almer
>> ---
>> An alternative is using av_fast_realloc(), in a simila
Quoting James Almer (2020-03-26 15:18:53)
> On 3/26/2020 11:06 AM, Anton Khirnov wrote:
> > Quoting James Almer (2020-03-25 18:56:44)
> >> Increase it in a linear way instead.
> >> Helps reduce memory usage, especially on long, non fragmented output.
> >>
> >> Signed-off-by: James Almer
> >> ---
>
Quoting Andreas Rheinhardt (2020-03-26 01:41:44)
> Matroska is built around the principle that a reader does not need to
> understand everything in a file in order to be able to make use of it;
> it just needs to ignore the data it doesn't know about.
>
> Our demuxer typically follows this princip
Quoting James Almer (2020-03-06 01:09:39)
> Signed-off-by: James Almer
> ---
> libavcodec/vp9.c| 13 -
> libavcodec/vp9dec.h | 4
> 2 files changed, 16 insertions(+), 1 deletion(-)
>
Looks reasonable. Any measurable performance difference?
--
Anton Khirnov
__
Quoting Andreas Rheinhardt (2020-03-23 03:38:38)
> They are used in several places like CBS.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> doc/developer.texi | 3 +++
> 1 file changed, 3 insertions(+)
Looks ok
--
Anton Khirnov
___
ffmpeg-devel maili
On 3/26/2020 11:30 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-03-06 01:09:39)
>> Signed-off-by: James Almer
>> ---
>> libavcodec/vp9.c| 13 -
>> libavcodec/vp9dec.h | 4
>> 2 files changed, 16 insertions(+), 1 deletion(-)
>>
>
> Looks reasonable. Any measurable pe
Quoting Linjie Fu (2020-03-05 08:47:54)
> Fix overflow for coeff -32768 in function ADD_RES_SSE_8_8 with
> no performance drop.
>
> ./checkasm --test=hevc_add_res --bench
>
> Mainline:
> - hevc_add_res.add_residual [OK]
> hevc_add_res_8x8_8_sse2: 15.5
>
> Add overflow test case:
> - hevc
On 3/26/2020 11:22 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-03-26 15:18:53)
>> On 3/26/2020 11:06 AM, Anton Khirnov wrote:
>>> Quoting James Almer (2020-03-25 18:56:44)
Increase it in a linear way instead.
Helps reduce memory usage, especially on long, non fragmented output.
>
Hi Baptiste,
On Tue, May 14, 2019 at 10:38 AM Thomas Mundt wrote:
> Hi Baptiste,
>
> Am Di., 14. Mai 2019 um 00:33 Uhr schrieb Baptiste Coudurier <
> baptiste.coudur...@gmail.com>:
>
> > ---
> > libavformat/Makefile | 2 +-
> > libavformat/avc.c| 186 +
Steven Liu (12020-03-24):
> These member will be used for get more correct information of the MPD
>
> Suggested-by: Andreas Rheinhardt
> Suggested-by: Nicolas George
> Signed-off-by: Steven Liu
> ---
> libavformat/dashdec.c | 244 --
> 1 file changed, 21
Am 26.03.20 um 12:18 schrieb Nicolas George:
> Thilo Borgmann (12020-03-26):
>> Ok. So if I understand all of this correctly, the overall goal of the
>> tones project is already redundant to your old proposal (or at least
>> partially, Paul?).
>
> I do not know what the overall goal of the tones p
Anton Khirnov:
> Quoting Andreas Rheinhardt (2020-03-23 03:38:38)
>> They are used in several places like CBS.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> doc/developer.texi | 3 +++
>> 1 file changed, 3 insertions(+)
>
> Looks ok
>
Applied, thanks.
- Andreas
Anton Khirnov:
> Quoting Andreas Rheinhardt (2020-03-26 01:41:42)
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> This has already been sent in [1]; I'm resending it because it fits
>> here.
>>
>> [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-December/254841.html
>>
>> libavformat/matroskade
On 3/26/2020 5:57 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-03-16 22:30:01)
>> Following the same logic as 061a0c14bb, this commit turns the old encode API
>> into a wrapper for the new one.
>>
>> Signed-off-by: James Almer
>> ---
>> This could be squashed with the previous commit, like
On 3/26/2020 5:43 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-03-16 22:30:00)
>> This commit follows the same logic as 061a0c14bb, but for the encode API: The
>> new public encoding API will no longer be a wrapper around the old deprecated
>> one, and the internal API used by the encoders
Quoting James Almer (2020-03-26 20:28:12)
> On 3/26/2020 5:57 AM, Anton Khirnov wrote:
> > Quoting James Almer (2020-03-16 22:30:01)
> >> Following the same logic as 061a0c14bb, this commit turns the old encode
> >> API
> >> into a wrapper for the new one.
> >>
> >> Signed-off-by: James Almer
> >
This set follows the same logic as 061a0c14bb, but for the encode API: The
new public API will no longer be a wrapper around the old deprecated one, and
the internal API used by the encoders now consists of a single receive_packet()
callback that pulls frames as required.
Because of the above, PAT
Following the same logic as 061a0c14bb, this commit turns the old encode API
into a wrapper for the new one.
Signed-off-by: James Almer
---
libavcodec/encode.c | 366 +-
libavcodec/internal.h | 1 +
libavcodec/utils.c| 8 +
3 files changed, 118 i
This commit follows the same logic as 061a0c14bb, but for the encode API: The
new public encoding API will no longer be a wrapper around the old deprecated
one, and the internal API used by the encoders now consists of a single
receive_packet() callback that pulls frames as required.
Signed-off-by
Anton Khirnov:
> Quoting Andreas Rheinhardt (2020-03-22 04:47:36)
>> Also simply return 0 in case a packet has been successfully read.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavformat/nsvdec.c | 6 ++
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> Looks ok.
>
Thanks, ap
Anton Khirnov:
> Quoting Andreas Rheinhardt (2020-03-22 04:47:37)
>> Also return 0 after successfully reading a packet.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavformat/yop.c | 9 +++--
>> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> ok
>
Thanks, applied.
- Andreas
Anton Khirnov:
> Quoting Andreas Rheinhardt (2020-03-22 04:47:38)
>> Forgotten in 6a67d518.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavformat/mpeg.c | 8 ++--
>> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> Looks ok
>
Applied, thanks.
- Andreas
__
On 3/26/2020 4:42 PM, Anton Khirnov wrote:
> Quoting James Almer (2020-03-26 20:28:12)
>> On 3/26/2020 5:57 AM, Anton Khirnov wrote:
>>> Quoting James Almer (2020-03-16 22:30:01)
Following the same logic as 061a0c14bb, this commit turns the old encode
API
into a wrapper for the new
Am Do., 26. März 2020 um 11:29 Uhr schrieb Martin Storsjö :
>
> On Thu, 26 Mar 2020, Carl Eugen Hoyos wrote:
>
> > Hi!
> >
> > Attached patch removes an ugly warning shown for every file when using
> > clang-cl.exe.
> >
> > Please comment, Carl Eugen
>
> LGTM
Patch applied.
Thank you, Carl Eugen
Am Do., 26. März 2020 um 11:30 Uhr schrieb Martin Storsjö :
>
> On Thu, 26 Mar 2020, Carl Eugen Hoyos wrote:
>
> > Hi!
> >
> > Attached patch avoids that ffmpeg claims its compiler was "No input
> > file" when using clang-cl.
> >
> > Please comment, Carl Eugen
>
> > @@ -4663,7 +4663,11 @@ probe_cc(
On Wed, Mar 25, 2020 at 06:48:44PM +0530, gautamr...@gmail.com wrote:
> From: Gautam Ramakrishnan
>
> The comments for some of the markers were incorrect.
> This patch fixes the comments associated with the markers.
> ---
> libavcodec/jpeg2000.h | 10 +-
> 1 file changed, 5 insertions(+)
On Wed, Mar 25, 2020 at 06:45:47PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/vf_showinfo.c | 4
> 1 file changed, 4 insertions(+)
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0
On Thu, Mar 26, 2020 at 10:47:37AM +0100, Anton Khirnov wrote:
> Quoting Andreas Rheinhardt (2020-03-20 17:51:41)
> > Jan Ekström:
> > > On Fri, Mar 20, 2020 at 5:45 PM wrote:
> > >>
> > >> From: Limin Wang
> > >>
> > >> This fixes webvtt segment output.
> > >>
> > >> Please testing with the foll
On Thu, 12. Mar 22:40, Andriy Gelman wrote:
> On Sun, 08. Mar 11:49, Andriy Gelman wrote:
> > From: Andriy Gelman
> >
> > struct v4l2_selection contains reserved bytes which should be set to
> > zero before the ioctl call.
> >
> > Fixes valgrind error:
> > Syscall param ioctl(VKI_V4L2_S_SELECTIO
Up until now, it was completely unspecified what the content of the
destination packet dst was on error. Depending upon where the error
happened calling av_packet_unref() on dst might be dangerous.
This commit changes this by making sure that dst is blank on error, so
unreferencing it again is saf
av_packet_ref() mostly treated the destination packet dst as uninitialized,
i.e. the destination fields were simply overwritten. But if the source
packet was not reference-counted, dst->buf was treated as if it pointed
to an already allocated buffer (if != NULL) to be reallocated to the
desired siz
Anton Khirnov:
> Quoting Andreas Rheinhardt (2020-02-12 16:02:21)
>> av_packet_ref() mostly treated the destination packet dst as uninitialized,
>> i.e. the destination fields were simply overwritten. But if the source
>> packet was not reference-counted, dst->buf was treated as if it pointed
>> to
> 2020年3月26日 下午11:46，Nicolas George 写道：
>
> Steven Liu (12020-03-24):
>> These member will be used for get more correct information of the MPD
>>
>> Suggested-by: Andreas Rheinhardt
>> Suggested-by: Nicolas George
>> Signed-off-by: Steven Liu
>> ---
>> libavformat/dashdec.c | 244 ++
72 matches
Mail list logo
