Re: [FFmpeg-devel] [PATCHv2] af_hdcd: Don't warn if converting from AV_SAMPLE_FMT_S16P

[Nicolas George]

Le primidi 21 thermidor, an CCXXIV, Burt P. a écrit :
> Are you now talking about plans of the future or this specific case?

Both.

> As it is, automatic conversion is very helpful, for example from
> WavePack, which uses s16p.

Apparently, not all of them are to your liking. FFmpeg can not guess which
ones. You could try to teach it, but it may prove tricky. The best solution
is to let the user choose, and that is exactly what disabling the automatic
conversion does.

Note that it does not disable conversions, only automatic ones. It also does
not disable format negotiation. The only thing that changes is that the user
has to choose where the conversion happens.

> This filter is only looking at the AVFilterLinks between filters, not
> at the filters themselves.

And with lavfi's design, this is not allowed. As is, the filter is scanning
links that it does not even know are audio, let alone are in any way
connected to it.

> This scan and warn behavior was added to address a real issue.

That is more or less the Transportation Security Administration's motto, and
we all know what a catastrophe that is. Good intentions are not enough to
make a solution correct, and this solution is not correct at all.

> Consider these example cases:

None of them involve anything remotely complicated.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] next Outreachy & GSoC ideas braindump [RFC]

[Michael Niedermayer]

On Sun, Aug 07, 2016 at 07:47:19PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Fri, Aug 5, 2016 at 6:20 PM, Michael Niedermayer 
> wrote:
> 
> > On Wed, Aug 03, 2016 at 07:48:36PM -0400, Ronald S. Bultje wrote:
> > > Hi,
> > >
> > > On Wed, Aug 3, 2016 at 1:57 PM, Michael Niedermayer
> > 
> > > wrote:
> > >
> > > > Hi all
> > > >
> > > > Sun, Jul 31, 2016 at 10:01:00PM +0200, Michael Niedermayer wrote:
> > > > > Hi all
> > > > >
> > > > > you have a great idea for a Outreachy task or a GSoC task ?
> > > > > Or something you always wanted to do but never had the time and
> > > > > it would fit in the time for GSoC/Outreachy ?
> > > > > Or some feature you always wanted which would fit as a task?
> > > > > Also keep in mind Outreachy is more flexible and not limited to
> > > > > coding tasks !
> > > > > reply and dump it here below:
> > > >
> > > > ping ?
> > > >
> > > > also cc-ing ffmpeg-user
> > > >
> > > > or are all feature requests on trac fake and noone has anything they
> > > > think should be implemented ?
> > > >
> > > > we need ideas for Outreachy, the page is EMPTY:
> > > > https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-12
> > >
> > >
> > > I have some ideas. Most are TODOs / extensions to stuff I wrote that I
> > > never ended up doing myself. Some might be hard.
> > >
> > > vp9:
> > > - avx2 loopfilter functions. Qualification task: explain to me without
> > any
> > > guidance why it's an issue for AVX2 (or SSE2) that the loopfilter in
> > vp9.c
> > > works on 8px blocks, and explain how I solved that to work on 16px blocks
> > > to use SSE2 instructions, and likewise explain how you would extend that
> > to
> > > work on 32px blocks.
> >
> > the Qualification task sounds interresting, we required for applicants
> > though always to submit a patch that then gets reveiwed and applied.
> > Generally a small/tiny part of the whole project.
> > So i would suggest to require the applicant to do that as well as your
> > Qualification task
> >
> 
> Progress on cols-only C wrapper sounds like a good qual task.
> 

> please add any projects you want to mentor to the page.
> 
> 

> I noticed the deadline is Aug 22, I'll be on vacation until end of Aug so I
> won't have time to either add things to wiki or to help students get
> started. Should probably hold this off until the next round.

If the dates for this round match last years then
For this round participating organizations will be announced in
september, applicants likely wont do much before september
the internship period will likely be december to march

the next round after that participating orgs would likely be announced
in february and the internship would be may to end of august

so if you have no time in august next year then you certainly cannot
mentor in the next round, this years august has no impact on either
round.

also this round is in winter the next is in summer and will overlap
with GSoC. The winter round allows people to participate who have no
time in the northern summer (generally people living on the southern
side of that blue ball i guess)

So IMO it makes sense for us to participate in this round, in the
next (if we are accepted to GSoC again) we would have to split
resources between 2 "Sponsoring Programs"

Also just to remind we need an admin for this round too!

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.


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

[FFmpeg-devel] [PATCH] cmdutils: remove the current working directory from the DLL search path on win32

[Hendrik Leppkes]

---
 cmdutils.c | 9 +
 cmdutils.h | 5 +
 ffmpeg.c   | 2 ++
 ffplay.c   | 2 ++
 ffprobe.c  | 2 ++
 ffserver.c | 1 +
 6 files changed, 21 insertions(+)

diff --git a/cmdutils.c b/cmdutils.c
index 03a4836..6960f8c 100644
--- a/cmdutils.c
+++ b/cmdutils.c
@@ -107,6 +107,15 @@ static void log_callback_report(void *ptr, int level, 
const char *fmt, va_list v
 }
 }
 
+void init_dynload(void)
+{
+#ifdef _WIN32
+/* Calling SetDllDirectory with the empty string (but not NULL) removes the
+ * current working directory from the DLL search path as a security 
pre-caution. */
+SetDllDirectory("");
+#endif
+}
+
 static void (*program_exit)(int ret);
 
 void register_exit(void (*cb)(int ret))
diff --git a/cmdutils.h b/cmdutils.h
index 83ea4ad..67bf484 100644
--- a/cmdutils.h
+++ b/cmdutils.h
@@ -62,6 +62,11 @@ void register_exit(void (*cb)(int ret));
 void exit_program(int ret) av_noreturn;
 
 /**
+ * Initialize dynamic library loading
+ */
+void init_dynload(void);
+
+/**
  * Initialize the cmdutils option system, in particular
  * allocate the *_opts contexts.
  */
diff --git a/ffmpeg.c b/ffmpeg.c
index d6282bd..bae515d 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -4293,6 +4293,8 @@ int main(int argc, char **argv)
 int ret;
 int64_t ti;
 
+init_dynload();
+
 register_exit(ffmpeg_cleanup);
 
 setvbuf(stderr,NULL,_IONBF,0); /* win32 runtime needs this */
diff --git a/ffplay.c b/ffplay.c
index 651e0cf..adbe9cb 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -3776,6 +3776,8 @@ int main(int argc, char **argv)
 char dummy_videodriver[] = "SDL_VIDEODRIVER=dummy";
 char alsa_bufsize[] = "SDL_AUDIO_ALSA_SET_BUFFER_SIZE=1";
 
+init_dynload();
+
 av_log_set_flags(AV_LOG_SKIP_REPEATED);
 parse_loglevel(argc, argv, options);
 
diff --git a/ffprobe.c b/ffprobe.c
index a49be6a..657867d 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -3241,6 +3241,8 @@ int main(int argc, char **argv)
 char *w_name = NULL, *w_args = NULL;
 int ret, i;
 
+init_dynload();
+
 av_log_set_flags(AV_LOG_SKIP_REPEATED);
 register_exit(ffprobe_cleanup);
 
diff --git a/ffserver.c b/ffserver.c
index 1a27583..453d790 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -3980,6 +3980,7 @@ int main(int argc, char **argv)
 int cfg_parsed;
 int ret = EXIT_FAILURE;
 
+init_dynload();
 
 config.filename = av_strdup("/etc/ffserver.conf");
 
-- 
2.9.2.windows.1

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

[FFmpeg-devel] segment file realease time

[Dan Shamir]

hi all
im creating a hls segment file
and im seeing that the format wrightsthe m3u8 file when your at about 75
frames into the encoding
how can i flush the file sooner
im making the segment very small for testing about 0.5 sec per segment

any ideas?


-- 


Dan shamir
Director of Graphic Technology

*d...@idomoo.com *



[image: idomoo_logo_moving people NEW email signature]


-- 




*This email and any files transmitted with it contain information from 
Idomoo which may be privileged and confidential and intended solely for the 
use of the addressee. If you are not the intended recipient, be aware that 
any disclosure, copying, distribution or use of the contents of this 
information is strictly prohibited; please notify us immediately by* *an 
**email 
reply and delete it from your system. Idomoo accepts no liability for any 
personal views or opinions expressed in this email. Email transmission 
cannot be guaranteed to be secure or error-free. Idomoo therefore is not 
liable for any errors or omissions in the contents of this message, which 
arise as a result of email transmission.*
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] cmdutils: remove the current working directory from the DLL search path on win32

[Matt Oliver]

On 8 August 2016 at 23:27, Hendrik Leppkes  wrote:

> ---
>  cmdutils.c | 9 +
>  cmdutils.h | 5 +
>  ffmpeg.c   | 2 ++
>  ffplay.c   | 2 ++
>  ffprobe.c  | 2 ++
>  ffserver.c | 1 +
>  6 files changed, 21 insertions(+)
>
> diff --git a/cmdutils.c b/cmdutils.c
> index 03a4836..6960f8c 100644
> --- a/cmdutils.c
> +++ b/cmdutils.c
> @@ -107,6 +107,15 @@ static void log_callback_report(void *ptr, int level,
> const char *fmt, va_list v
>  }
>  }
>
> +void init_dynload(void)
> +{
> +#ifdef _WIN32
> +/* Calling SetDllDirectory with the empty string (but not NULL)
> removes the
> + * current working directory from the DLL search path as a security
> pre-caution. */
> +SetDllDirectory("");
> +#endif
> +}
> +
>  static void (*program_exit)(int ret);
>
>  void register_exit(void (*cb)(int ret))
> diff --git a/cmdutils.h b/cmdutils.h
> index 83ea4ad..67bf484 100644
> --- a/cmdutils.h
> +++ b/cmdutils.h
> @@ -62,6 +62,11 @@ void register_exit(void (*cb)(int ret));
>  void exit_program(int ret) av_noreturn;
>
>  /**
> + * Initialize dynamic library loading
> + */
> +void init_dynload(void);
> +
> +/**
>   * Initialize the cmdutils option system, in particular
>   * allocate the *_opts contexts.
>   */
> diff --git a/ffmpeg.c b/ffmpeg.c
> index d6282bd..bae515d 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -4293,6 +4293,8 @@ int main(int argc, char **argv)
>  int ret;
>  int64_t ti;
>
> +init_dynload();
> +
>  register_exit(ffmpeg_cleanup);
>
>  setvbuf(stderr,NULL,_IONBF,0); /* win32 runtime needs this */
> diff --git a/ffplay.c b/ffplay.c
> index 651e0cf..adbe9cb 100644
> --- a/ffplay.c
> +++ b/ffplay.c
> @@ -3776,6 +3776,8 @@ int main(int argc, char **argv)
>  char dummy_videodriver[] = "SDL_VIDEODRIVER=dummy";
>  char alsa_bufsize[] = "SDL_AUDIO_ALSA_SET_BUFFER_SIZE=1";
>
> +init_dynload();
> +
>  av_log_set_flags(AV_LOG_SKIP_REPEATED);
>  parse_loglevel(argc, argv, options);
>
> diff --git a/ffprobe.c b/ffprobe.c
> index a49be6a..657867d 100644
> --- a/ffprobe.c
> +++ b/ffprobe.c
> @@ -3241,6 +3241,8 @@ int main(int argc, char **argv)
>  char *w_name = NULL, *w_args = NULL;
>  int ret, i;
>
> +init_dynload();
> +
>  av_log_set_flags(AV_LOG_SKIP_REPEATED);
>  register_exit(ffprobe_cleanup);
>
> diff --git a/ffserver.c b/ffserver.c
> index 1a27583..453d790 100644
> --- a/ffserver.c
> +++ b/ffserver.c
> @@ -3980,6 +3980,7 @@ int main(int argc, char **argv)
>  int cfg_parsed;
>  int ret = EXIT_FAILURE;
>
> +init_dynload();
>
>  config.filename = av_strdup("/etc/ffserver.conf");
>
> --
>

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

Re: [FFmpeg-devel] [PATCH] lavf/mov: Add support for edit list parsing.

[Clément Bœsch]

Hi,

On Fri, Aug 05, 2016 at 05:18:39PM -0700, Sasi Inguva wrote:
> In YouTube we have long been receiving MOV files from users, which have 
> non-trivial edit lists (Those edit lists which are not just used to offset 
> video start from audio start) and multiple edit lists. Recently the uploads 
> of such files has increased with the introduction of apps that allow video 
> editing and upload like Vine etc. mov.c in ffmpeg does not have edit list 
> parsing support i.e. the support for deciding what video/audio packets should 
> be output with what timestamps, based on edit lists. For this reason, we had 
> built a basic support for edit list parsing in our version of ffmpeg, which 
> fixes the AVIndexEntries built by mov_build_index by looking at edit lists, 
> and introduces new DISCARD flags in AVPacket and AVFrame to signal to the 
> decoder to discard certain packets.
> 
> For a while our edit list support was broken, as in it didn't properly work 
> for multiple edit lists and it had problems with edit-lists ending on 
> B-frames. But we've fixed most of these issues in recent times, and we think 
> that now it is in a good enough condition so that it can be submitted to 
> HEAD. This will not only help the vast userbase of ffmepg, but will also help 
> us with staying up-to-date with ffmpeg and also by adding the power of ffmpeg 
> developer community to our MOV support. So here's a go at it.
> What is supported:
>  - multiple edit lists
>  - edit lists ending on B-frames
>  - zero segment duration edit lists
> 
> What is not supported:
>  - Changing the rate of playing with edit lists. We basically ignore 
> MediaRate field of edit.
> 
> I have added fate tests too. Here is a no-sign-in required link to the test 
> files 
> https://drive.google.com/folderview?id=0Bz6XfEJZ-9N3R3o3QXNHUGRqbms&usp=sharing.

First, thanks for working on this. But it would be much much more
appropriate to discuss such changes with developers before engaging
yourself in such heavy development. As you can guess, this issue has been
discussed many times in the past within the project, and a proper solution
had yet to come out of it. It looks like the approach you took was
dismissed in the past from an infrastructure PoV.

I will have a look to this patch later this week, but please don't follow
this corporate approach when doing such huge contribution. You're risking
too much by doing so (your work could be dismissed, or worse your work
introduce fundamental issues within the project which we'll take years to
fix because $API)

You can use the mailing list, or simply IRC to have quick talk with us.

-- 
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] [PATCHv5] af_hdcd: Add analyze mode

[Burt P.]

applied

On Sun, Aug 7, 2016 at 2:50 AM, Burt P  wrote:
> A new mode, selected by filter option, to aid in analysis of HDCD
> encoded audio. In this mode the audio is replaced by a solid tone and
> the amplitude is adjusted to signal some specified aspect of the process.
> The output file can be loaded in an audio editor alongside the original,
> where the user can see where different features or states are present.
>
> Signed-off-by: Burt P 
> ---
>  doc/filters.texi  |  32 ++
>  libavfilter/af_hdcd.c | 163 
> +++---
>  2 files changed, 187 insertions(+), 8 deletions(-)


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

Re: [FFmpeg-devel] [PATCH] [RFC] libavfilter HRTF/room acoustics filter [1/2]

[Carl Eugen Hoyos]

2016-08-07 2:08 GMT+02:00 Michael Niedermayer :
>> On a somewhat related matter: I was browsing through the matrix encoder
>> in libavresample/audio_mix_matrix.c, and possibly rediscovered the bug
>> in https://trac.ffmpeg.org/ticket/4175 . Also, the 5-channel coefficient
>> seems to disagrees with Dolby (see the notes I wrote at some point while
>> editing the Wikipedia section in
>> https://en.wikipedia.org/wiki/Talk:Dolby_Pro_Logic#Source_of_the_DPLII_encoding_matrix.3F).
>
> is this issue also affecting libswresample ?

The fact that users have reported several times that our Dolby downmix is not
correct / not perfect indicates that there is an issue affecting
libswresample, no?
https://trac.ffmpeg.org/ticket/3455
https://trac.ffmpeg.org/ticket/4175

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

Re: [FFmpeg-devel] [PATCHv2] af_hdcd: Don't warn if converting from AV_SAMPLE_FMT_S16P

[Burt P.]

applied, as dbd7a84c814161926e5f298eae1f5ea17082f814, with an
additional check that AVFilterLink->type is AVMEDIA_TYPE_AUDIO before
calling av_get_sample_fmt_name() on AVFilterLink->format. Thanks for
pointing that out.

I will look into disabling auto-conversions when the filter is used
and removing the invasive scan.


On Mon, Aug 8, 2016 at 5:16 AM, Nicolas George  wrote:
> Le primidi 21 thermidor, an CCXXIV, Burt P. a écrit :
>> Are you now talking about plans of the future or this specific case?
>
> Both.
>
>> As it is, automatic conversion is very helpful, for example from
>> WavePack, which uses s16p.
>
> Apparently, not all of them are to your liking. FFmpeg can not guess which
> ones. You could try to teach it, but it may prove tricky. The best solution
> is to let the user choose, and that is exactly what disabling the automatic
> conversion does.
>
> Note that it does not disable conversions, only automatic ones. It also does
> not disable format negotiation. The only thing that changes is that the user
> has to choose where the conversion happens.
>
>> This filter is only looking at the AVFilterLinks between filters, not
>> at the filters themselves.
>
> And with lavfi's design, this is not allowed. As is, the filter is scanning
> links that it does not even know are audio, let alone are in any way
> connected to it.
>
>> This scan and warn behavior was added to address a real issue.
>
> That is more or less the Transportation Security Administration's motto, and
> we all know what a catastrophe that is. Good intentions are not enough to
> make a solution correct, and this solution is not correct at all.
>
>> Consider these example cases:
>
> None of them involve anything remotely complicated.
>
> Regards,
>
> --
>   Nicolas George
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>



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

Re: [FFmpeg-devel] [PATCH 2/2] [RFC] avutil/version: Improve lib versioning sheme for release branches with the next major release

[Carl Eugen Hoyos]

2016-08-06 12:52 GMT+02:00 Michael Niedermayer :
> + * Starting with FFmpeg 3.2, the released library versions will occupy
> + * a seperate MAJOR.MINOR that is not used on the master development branch

Sounds great.

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

Re: [FFmpeg-devel] [PATCH] cmdutils: remove the current working directory from the DLL search path on win32

[Michael Niedermayer]

On Tue, Aug 09, 2016 at 12:25:21AM +1000, Matt Oliver wrote:
> On 8 August 2016 at 23:27, Hendrik Leppkes  wrote:
> 
> > ---
> >  cmdutils.c | 9 +
> >  cmdutils.h | 5 +
> >  ffmpeg.c   | 2 ++
> >  ffplay.c   | 2 ++
> >  ffprobe.c  | 2 ++
> >  ffserver.c | 1 +
> >  6 files changed, 21 insertions(+)
> >
> > diff --git a/cmdutils.c b/cmdutils.c
> > index 03a4836..6960f8c 100644
> > --- a/cmdutils.c
> > +++ b/cmdutils.c
> > @@ -107,6 +107,15 @@ static void log_callback_report(void *ptr, int level,
> > const char *fmt, va_list v
> >  }
> >  }
> >
> > +void init_dynload(void)
> > +{
> > +#ifdef _WIN32
> > +/* Calling SetDllDirectory with the empty string (but not NULL)
> > removes the
> > + * current working directory from the DLL search path as a security
> > pre-caution. */
> > +SetDllDirectory("");
> > +#endif
> > +}
> > +
> >  static void (*program_exit)(int ret);
> >
> >  void register_exit(void (*cb)(int ret))
> > diff --git a/cmdutils.h b/cmdutils.h
> > index 83ea4ad..67bf484 100644
> > --- a/cmdutils.h
> > +++ b/cmdutils.h
> > @@ -62,6 +62,11 @@ void register_exit(void (*cb)(int ret));
> >  void exit_program(int ret) av_noreturn;
> >
> >  /**
> > + * Initialize dynamic library loading
> > + */
> > +void init_dynload(void);
> > +
> > +/**
> >   * Initialize the cmdutils option system, in particular
> >   * allocate the *_opts contexts.
> >   */
> > diff --git a/ffmpeg.c b/ffmpeg.c
> > index d6282bd..bae515d 100644
> > --- a/ffmpeg.c
> > +++ b/ffmpeg.c
> > @@ -4293,6 +4293,8 @@ int main(int argc, char **argv)
> >  int ret;
> >  int64_t ti;
> >
> > +init_dynload();
> > +
> >  register_exit(ffmpeg_cleanup);
> >
> >  setvbuf(stderr,NULL,_IONBF,0); /* win32 runtime needs this */
> > diff --git a/ffplay.c b/ffplay.c
> > index 651e0cf..adbe9cb 100644
> > --- a/ffplay.c
> > +++ b/ffplay.c
> > @@ -3776,6 +3776,8 @@ int main(int argc, char **argv)
> >  char dummy_videodriver[] = "SDL_VIDEODRIVER=dummy";
> >  char alsa_bufsize[] = "SDL_AUDIO_ALSA_SET_BUFFER_SIZE=1";
> >
> > +init_dynload();
> > +
> >  av_log_set_flags(AV_LOG_SKIP_REPEATED);
> >  parse_loglevel(argc, argv, options);
> >
> > diff --git a/ffprobe.c b/ffprobe.c
> > index a49be6a..657867d 100644
> > --- a/ffprobe.c
> > +++ b/ffprobe.c
> > @@ -3241,6 +3241,8 @@ int main(int argc, char **argv)
> >  char *w_name = NULL, *w_args = NULL;
> >  int ret, i;
> >
> > +init_dynload();
> > +
> >  av_log_set_flags(AV_LOG_SKIP_REPEATED);
> >  register_exit(ffprobe_cleanup);
> >
> > diff --git a/ffserver.c b/ffserver.c
> > index 1a27583..453d790 100644
> > --- a/ffserver.c
> > +++ b/ffserver.c
> > @@ -3980,6 +3980,7 @@ int main(int argc, char **argv)
> >  int cfg_parsed;
> >  int ret = EXIT_FAILURE;
> >
> > +init_dynload();
> >
> >  config.filename = av_strdup("/etc/ffserver.conf");
> >
> > --
> >
> 
> LGTM

applied

thanks to all

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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

Re: [FFmpeg-devel] Log level of message "Increasing reorder buffer to ..."

[Carl Eugen Hoyos]

2016-08-04 14:41 GMT+02:00 Robert Krüger :
> On Thu, Aug 4, 2016 at 1:55 PM, Carl Eugen Hoyos  wrote:
>
>> 2016-08-04 13:50 GMT+02:00 Robert Krüger :
>> > the log level of INFO does not seem appropriate for the message
>> > (h264dec.c, line 531). If it is a condition that shouldn't really happen,
>> > it should be
>>
>> It does happen, see at least two related tickets iirc.
>
> Yes, of course, I am observing it all the time (see below). This was rather
> a (redundant) explanation what my understanding of the purpose of log level
> WARNING usually is. Our logs are full of this

That surprises me a little because I thought no public encoder produces
such streams - see my questions in the related tickets.

>> > a warning, otherwise it should be debug (especially for library
>> > users this floods the logs as this seems to happen for many files.
>> >
>> > Would a patch, setting this to DEBUG be accepted?
>>
>> I don't think so: It was intentionally increased to allow users to

(I am of course not the h264 maintainer.)

>> understand why libavcodec eat a frame.
>
> "Eats a frame" means what exactly? Does the decoder then miss a frame?

Yes, except if I misunderstand the issue.

> If so, I haven't observed this and need to check again as that would
> be serious. So far, I thought this warning was harmless.

I believe in most use cases, a dropped (B-) frame is harmless.

> If the library logging is designed for the command line then I can, of
> course, always patch locally. Just thought I'd ask to better understand.

I don't understand: Isn't this at most one warning per stream to inform
you about -strict 1? And don't you get many warnings for many kind
of streams (mpegts)?

> Do you remember the related tickets?

As git blame would have told you:
https://trac.ffmpeg.org/ticket/5138
https://trac.ffmpeg.org/ticket/5439

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

Re: [FFmpeg-devel] [PATCH 1/2] avutil/version: Mention similarities and differences to semver

[Carl Eugen Hoyos]

2016-08-06 12:52 GMT+02:00 Michael Niedermayer :
> QUESTION: is this the best place for this ?
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavutil/version.h | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/libavutil/version.h b/libavutil/version.h
> index b2dffb7..7692def 100644
> --- a/libavutil/version.h
> +++ b/libavutil/version.h
> @@ -35,6 +35,12 @@
>   * Useful to check and match library version in order to maintain
>   * backward compatibility.
>   *

This is at least not a bad place imo.

> + * The FFmpeg libraries follow a versioning sheme very similar to
> + * Semantic Versioning (http://semver.org/)
> + * The difference is that the component called PATCH is called MICRO in 
> FFmpeg
> + * and its value is reset to 100 instead of 0 to keep it above or equal to 
> 100.

> + * Also we do not increase MICRO for every bugfix or change.

But we want / should increase MICRO for every bugfix and every functional
change, no?

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

Re: [FFmpeg-devel] [PATCH] avcodec/alsdec: implement floating point decoding

[Umair Khan]

Hi,

On Sat, Aug 6, 2016 at 10:35 PM, Thilo Borgmann  wrote:
> Am 06.08.16 um 17:26 schrieb Umair Khan:
>> On Fri, Aug 5, 2016 at 9:27 PM, Carl Eugen Hoyos  wrote:
>>> Hi!
>>>
>>> 2016-08-05 16:57 GMT+02:00 Umair Khan :
 Updated patch attached.
>>>
>>> The Changelog hunk of your patch indicates that the patch should be split.
>>> (Or the change to Changelog could be wrong.)
>>
>> I don't know. I can do it if the other people also think this.
>
> Yes. Split it up into three parts: SoftFloat_IEEE754, MLZ and the ALS 
> decoding of floats.
>
> All these parts alone make sense for a separate commit although they are only 
> used in ALS (by now).
> You can (assuming you are planning to maintain your code) also add yourself 
> to MAINTAINERS for SoftFloat & MLZ files you add.

Attached the 3 separate patches.

- Umair


0001-avcodec-alsdec-Implement-floating-point-sample-data-.patch
Description: Binary data


0001-avcodec-Implement-masked-lz-decompression.patch
Description: Binary data


0001-avutil-Softfloat-implementation-for-IEEE-754-single-.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/alsdec: implement floating point decoding

[Carl Eugen Hoyos]

2016-08-08 19:10 GMT+02:00 Umair Khan :
> Attached the 3 separate patches.

Which other codecs could use mlz decompression in the future?
Which other codecs could use IEEE 754 single floating point
soft float implementation in the future?

I would suggest that there is one easy-to-understand new line
in the Changelog like "Floating point ALS decoding".

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

Re: [FFmpeg-devel] [PATCH] avcodec/alsdec: implement floating point decoding

[Umair Khan]

On Mon, Aug 8, 2016 at 11:09 PM, Carl Eugen Hoyos  wrote:
> 2016-08-08 19:10 GMT+02:00 Umair Khan :
>> Attached the 3 separate patches.
>
> Which other codecs could use mlz decompression in the future?
> Which other codecs could use IEEE 754 single floating point
> soft float implementation in the future?

I have no idea about these. There is lzw implementation already in the
source code though.

> I would suggest that there is one easy-to-understand new line
> in the Changelog like "Floating point ALS decoding".

What do you mean by this? I did not understand this properly.

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

[FFmpeg-devel] [PATCH 0/2] v4 - SCTE-35 work

[Carlos Fernandez Sanz]

* Corrected reported issue (an unrelated change that made it into the patch)

Carlos (1):
  SCTE extraction from mpegts

carlos (1):
  SCTE-35 support in hlsenc

 libavcodec/avcodec.h|   1 +
 libavcodec/codec_desc.c |   6 +
 libavformat/Makefile|   2 +-
 libavformat/hlsenc.c| 110 ---
 libavformat/mpegts.c|  43 -
 libavformat/scte_35.c   | 482 
 libavformat/scte_35.h   |  76 
 7 files changed, 695 insertions(+), 25 deletions(-)
 create mode 100644 libavformat/scte_35.c
 create mode 100644 libavformat/scte_35.h

-- 
2.7.4

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

[FFmpeg-devel] [PATCH 1/2] v4 - SCTE extraction from mpegts

[Carlos Fernandez Sanz]

From: Carlos 

Signed-off-by: carlos 
---
 libavcodec/avcodec.h|  1 +
 libavcodec/codec_desc.c |  6 ++
 libavformat/mpegts.c| 43 ++-
 3 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 3b21537..601ee5c 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -630,6 +630,7 @@ enum AVCodecID {
 /* other specific kind of codecs (generally used for attachments) */
 AV_CODEC_ID_FIRST_UNKNOWN = 0x18000,   ///< A dummy ID pointing at 
the start of various fake codecs.
 AV_CODEC_ID_TTF = 0x18000,
+AV_CODEC_ID_SCTE_35,
 
 AV_CODEC_ID_BINTEXT= 0x18800,
 AV_CODEC_ID_XBIN,
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index dea17c9..5c00be0 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -2950,6 +2950,12 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("binary data"),
 .mime_types= MT("application/octet-stream"),
 },
+{
+.id= AV_CODEC_ID_SCTE_35,
+.type  = AVMEDIA_TYPE_DATA,
+.name  = "scte_35",
+.long_name = NULL_IF_CONFIG_SMALL("SCTE 35 Message Queue"),
+},
 
 /* deprecated codec ids */
 };
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index b31d233..4185af0 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -57,6 +57,7 @@ enum MpegTSFilterType {
 MPEGTS_PES,
 MPEGTS_SECTION,
 MPEGTS_PCR,
+MPEGTS_DATA,
 };
 
 typedef struct MpegTSFilter MpegTSFilter;
@@ -510,6 +511,11 @@ static MpegTSFilter *mpegts_open_pcr_filter(MpegTSContext 
*ts, unsigned int pid)
 return mpegts_open_filter(ts, pid, MPEGTS_PCR);
 }
 
+static MpegTSFilter *mpegts_open_data_filter(MpegTSContext *ts, unsigned int 
pid)
+{
+return mpegts_open_filter(ts, pid, MPEGTS_DATA);
+}
+
 static void mpegts_close_filter(MpegTSContext *ts, MpegTSFilter *filter)
 {
 int pid;
@@ -725,6 +731,12 @@ static const StreamType HDMV_types[] = {
 { 0 },
 };
 
+/* SCTE types */
+static const StreamType SCTE_types[] = {
+{ 0x86, AVMEDIA_TYPE_DATA,  AV_CODEC_ID_SCTE_35},
+{ 0 },
+};
+
 /* ATSC ? */
 static const StreamType MISC_types[] = {
 { 0x81, AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_AC3 },
@@ -872,6 +884,13 @@ static void reset_pes_packet_state(PESContext *pes)
 av_buffer_unref(&pes->buffer);
 }
 
+static void new_data_packet(const uint8_t *buffer, int len, AVPacket *pkt)
+{
+av_init_packet(pkt);
+pkt->data = buffer;
+pkt->size = len;
+}
+
 static int new_pes_packet(PESContext *pes, AVPacket *pkt)
 {
 char *sd;
@@ -1975,6 +1994,19 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t 
*section, int section_len
 pes->st->id = pes->pid;
 }
 st = pes->st;
+} else if (stream_type == 0x86 && prog_reg_desc ==  AV_RL32("CUEI")) {
+int idx = ff_find_stream_index(ts->stream, pid);
+if (idx >= 0) {
+st = ts->stream->streams[idx];
+} else {
+st = avformat_new_stream(ts->stream, NULL);
+if (!st)
+goto out;
+st->id = pid;
+st->codecpar->codec_type = AVMEDIA_TYPE_DATA;
+mpegts_find_stream_type(st, stream_type, SCTE_types);
+mpegts_open_data_filter(ts, pid);
+}
 } else if (stream_type != 0x13) {
 if (ts->pids[pid])
 mpegts_close_filter(ts, ts->pids[pid]); // wrongly added sdt 
filter probably
@@ -2317,7 +2349,14 @@ static int handle_packet(MpegTSContext *ts, const 
uint8_t *packet)
 }
 }
 }
-
+} else if (tss->type == MPEGTS_DATA) {
+int idx = ff_find_stream_index(ts->stream, pid);
+p++;
+new_data_packet(p,p_end - p, ts->pkt);
+if (idx >= 0) {
+ts->pkt->stream_index = idx;
+}
+ts->stop_parse = 1;
 } else {
 int ret;
 // Note: The position here points actually behind the current packet.
@@ -2730,6 +2769,8 @@ static int mpegts_read_packet(AVFormatContext *s, 
AVPacket *pkt)
 ret = 0;
 break;
 }
+} else if (ts->pids[i] && ts->pids[i]->type == MPEGTS_DATA) {
+return ret;
 }
 }
 
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH v2] Add "sar" alias to "aspect" option of video encoders

[Andrey Utkin]

On Thu, Jul 14, 2016 at 05:27:08PM +, Carl Eugen Hoyos wrote:
> Andrey Utkin  fastmail.com> writes:
> 
> > It is impossible to pass "aspect" parameter to encoder from ffmpeg 
> > CLI because option from lavc/options_table.h is eclipsed by option 
> > with same name in ffmpeg_opt.c, which has different meaning (DAR, 
> > not SAR).
> 
> Wasn't the old behaviour intended because it assured you cannot 
> pass contradicting options to the libraries via ffmpeg?

I don't think so.
Proper way to avoid contradiction is explicit check in code.
It is a usability flaw to be unable to pass certain encoder option in
CLI while all other are passed finely.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] v4 - SCTE-35 support in hlsenc

[Carlos Fernandez Sanz]

From: carlos 

Signed-off-by: carlos 
---
 libavformat/Makefile  |   2 +-
 libavformat/hlsenc.c  | 110 +---
 libavformat/scte_35.c | 482 ++
 libavformat/scte_35.h |  76 
 4 files changed, 646 insertions(+), 24 deletions(-)
 create mode 100644 libavformat/scte_35.c
 create mode 100644 libavformat/scte_35.h

diff --git a/libavformat/Makefile b/libavformat/Makefile
index fda1e17..7d47465 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -204,7 +204,7 @@ OBJS-$(CONFIG_HDS_MUXER) += hdsenc.o
 OBJS-$(CONFIG_HEVC_DEMUXER)  += hevcdec.o rawdec.o
 OBJS-$(CONFIG_HEVC_MUXER)+= rawenc.o
 OBJS-$(CONFIG_HLS_DEMUXER)   += hls.o
-OBJS-$(CONFIG_HLS_MUXER) += hlsenc.o
+OBJS-$(CONFIG_HLS_MUXER) += hlsenc.o scte_35.o
 OBJS-$(CONFIG_HNM_DEMUXER)   += hnm.o
 OBJS-$(CONFIG_ICO_DEMUXER)   += icodec.o
 OBJS-$(CONFIG_ICO_MUXER) += icoenc.o
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 9f076ba..162fde2 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -38,6 +38,7 @@
 #include "avio_internal.h"
 #include "internal.h"
 #include "os_support.h"
+#include "scte_35.h"
 
 #define KEYSIZE 16
 #define LINE_BUFFER_SIZE 1024
@@ -48,6 +49,10 @@ typedef struct HLSSegment {
 double duration; /* in seconds */
 int64_t pos;
 int64_t size;
+struct scte_35_event *event;
+int out;
+int adv_count;
+int64_t start_pts;
 
 char key_uri[LINE_BUFFER_SIZE + 1];
 char iv_string[KEYSIZE*2 + 1];
@@ -89,6 +94,8 @@ typedef struct HLSContext {
 uint32_t flags;// enum HLSFlags
 uint32_t pl_type;  // enum PlaylistType
 char *segment_filename;
+char *adv_filename;
+char *adv_subfilename;
 
 int use_localtime;  ///< flag to expand filename with localtime
 int use_localtime_mkdir;///< flag to mkdir dirname in timebased filename
@@ -104,6 +111,7 @@ typedef struct HLSContext {
 int nb_entries;
 int discontinuity_set;
 
+struct scte_35_interface *scte_iface;
 HLSSegment *segments;
 HLSSegment *last_segment;
 HLSSegment *old_segments;
@@ -203,6 +211,8 @@ static int hls_delete_old_segments(HLSContext *hls) {
 av_freep(&path);
 previous_segment = segment;
 segment = previous_segment->next;
+if (hls->scte_iface)
+hls->scte_iface->unref_scte35_event(&previous_segment->event);
 av_free(previous_segment);
 }
 
@@ -314,8 +324,8 @@ static int hls_mux_init(AVFormatContext *s)
 }
 
 /* Create a new segment and append it to the segment list */
-static int hls_append_segment(struct AVFormatContext *s, 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 start_pts, struct scte_35_event *event, 
int64_t size)
 {
 HLSSegment *en = av_malloc(sizeof(*en));
 char *tmp, *p;
@@ -349,11 +359,25 @@ static int hls_append_segment(struct AVFormatContext *s, 
HLSContext *hls, double
 else
 en->sub_filename[0] = '\0';
 
-en->duration = duration;
-en->pos  = pos;
-en->size = size;
+en->duration   = duration;
+en->pos= pos;
+en->event  = event;
+en->size   = size;
+en->start_pts  = start_pts;
 en->next = NULL;
 
+if (hls->scte_iface) {
+if (hls->scte_iface->event_out == EVENT_OUT_CONT) {
+en->adv_count = hls->scte_iface->adv_count;
+hls->scte_iface->adv_count++;
+en->out = hls->scte_iface->event_out;
+} else {
+hls->scte_iface->adv_count = 0;
+en->out = hls->scte_iface->event_out;
+}
+}
+
+
 if (hls->key_info_file) {
 av_strlcpy(en->key_uri, hls->key_uri, sizeof(en->key_uri));
 av_strlcpy(en->iv_string, hls->iv_string, sizeof(en->iv_string));
@@ -475,9 +499,23 @@ static int hls_window(AVFormatContext *s, int last)
 if (hls->flags & HLS_SINGLE_FILE)
  avio_printf(out, "#EXT-X-BYTERANGE:%"PRIi64"@%"PRIi64"\n",
  en->size, en->pos);
-if (hls->baseurl)
-avio_printf(out, "%s", hls->baseurl);
-avio_printf(out, "%s\n", en->filename);
+if (hls->scte_iface && (en->event || en->out) ) {
+char *str;
+char fname[1024] = "";
+if (hls->adv_filename) {
+str = hls->scte_iface->get_hls_string(hls->scte_iface, 
en->event, hls->adv_filename, en->out, en->adv_count, en->start_pts);
+} else {
+if (hls->baseurl)
+strncat(fname, hls->baseurl, 1024);
+strncat(fname, en->filename, 1024);
+str = hls->scte_iface->get_hls_string(hls->scte_iface, 
en->event, 

Re: [FFmpeg-devel] Changing media formats mid stream

[Roger Pack]

On 8/24/15, Michael Niedermayer  wrote:
> On Mon, Aug 24, 2015 at 10:55:07PM +0200, Máté Sebők wrote:
>> Oops, forgot to mention, in dshow_pin.c the libAVPin_QueryAccept() have
>> to
>> be edited to almost the same as libAVPin_ReceiveConnection() just without
>> the pin management.
>
> maybe roger or others can help, i dont have a windows box here nor
> do i really know dshow

For followers, we ended up working around this by sending a "raw
stream" (like URLProtocol) to FFmpeg, that way the stream itself
describes the video formats, and they never change.  The weird dshow
way of doing this is that you set up the graph 'as if" it were always
mpeg2video, then when you "start" the graph, it calls for a
renegotiation. Weird.


>>
>> On Mon, Aug 24, 2015 at 10:44 PM, Máté Sebők 
>> wrote:
>>
>> > I did a dirty little hack to attempt to fix it.
>> > Don't call the dshow_add_device() just in build time, but run the graph
>> > and sleep() a bit, then call dshow_add_device() at the end of the
>> > dshow_read_header().
>> >
>> > Sadly, it does not work, it does not goes beyond the dshow "chit-chat"
>> > between filters/pins.
>> >
>> > After ctrl+c however the right codec stats are displayed...
>> >
>> > Regards,
>> > Máté
>> >
>> >
>> > On Mon, Aug 24, 2015 at 10:29 PM, Michael Niedermayer <
>> > mich...@niedermayer.cc> wrote:
>> >
>> >> On Mon, Aug 24, 2015 at 02:09:28PM -0600, Roger Pack wrote:
>> >> > I've run into the case today where (if we understand it correctly)
>> >> > you
>> >> > setup a directshow graph, it advertises media types, then when you
>> >> > "start" the graph, it actually calls through and says "here's your
>> >> > *real* media type".
>> >> > Does ffmpeg internals have any concept of or support for a "changing
>> >> > media type" at runtime? (any other suggestions for how to handle
>> >> > this
>> >> > if it doesn't?)
>> >>
>> >> do i understand correctly that the type at read_header() stage is
>> >> wrong but the type later at read_packet() stage is correct ?
>> >> if that is the case, you can just wait with setting the type till it
>> >> is reliably known.
>> >>
>> >> [...]
>> >> --
>> >> Michael GnuPG fingerprint:
>> >> 9FF2128B147EF6730BADF133611EC787040B0FAB
>> >>
>> >> I have never wished to cater to the crowd; for what I know they do not
>> >> approve, and what they approve I do not know. -- Epicurus
>> >>
>> >> ___
>> >> ffmpeg-devel mailing list
>> >> ffmpeg-devel@ffmpeg.org
>> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> >>
>> >>
>> >
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> While the State exists there can be no freedom; when there is freedom there
> will be no State. -- Vladimir Lenin
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSoC] BDA (DTV) Capture / tuning -- work-in-progress

[Roger Pack]

As a quick follow up, there is a full working example (windows DTV
[ATSC/DVBT/DVBS], works with MPEG or H264 streams, capture channels
*with their subchannels* all at once)

https://github.com/rdp/ffmpeg/tree/dtv_protocol

It uses the "schizo" way where digital TV comes in as a "protocol"
from libavformat, and the rest is via normal libavdevice device
(suggestions welcome still there...I want to be able to send "raw"
mpeg streams to FFmpeg so that it can use its selectors on it, but
send that in from a device...wish there were an option for a
libavdevice to send "raw" stream-like data :| ).

ATSC usage example:
https://github.com/rdp/FFmpeg/blob/dtv_protocol/go_protocol_local.bat

DVB example: https://github.com/rdp/FFmpeg/blob/dtv_protocol/ffmpeg_dvbt.bat

I haven't had the umph to get something ready for merging yet, just
linking it in case it's useful to someone in the meantime.

Cheers!

On 5/28/16, Roger Pack  wrote:
> On 12/29/15, Hendrik Leppkes  wrote:
>> On Wed, Dec 30, 2015 at 12:33 AM, Hendrik Leppkes 
>> wrote:
>>> On Wed, Dec 30, 2015 at 12:23 AM, Roger Pack 
>>> wrote:
> OK I had this great idea to capture the incoming MPEG2 transport
> stream from the digital TV capture device.  Kind of like "raw" stream,
> so FFmpeg could have access to, for instance, all the audio stream.
>
> It appears that the type coming out of the tuner is:
> MEDIATYPE_Stream
> with subtype
> KSDATAFORMAT_SUBTYPE_BDA_MPEG2_TRANSPORT
> which is apparently treated the same as MEDIASUBTYPE_MPEG2_TRANSPORT
> by the built in directshow mpeg demuxer [1] so I assume is some kind
> of typical MPEG2 TS stream.
>
> I had hoped that if I set dshow's AVStream's codec_id to
>  codec->codec_id = AV_CODEC_ID_NONE;
>  codec->codec_type = AVMEDIA_TYPE_DATA;

 Oops that was meant to be

 codec->codec_id = AV_CODEC_ID_MPEG2TS;
 codec->codec_type = AVMEDIA_TYPE_DATA;

> That it would somehow recognize that I was sending it an MPEG stream
> and insert an appropriate demuxer for me.
>
> However, when I run it, it fails like this:
>
> Input #0, dshow, from 'video=Hauppauge WinTV 885 BDA Tuner/Demod':
>   Duration: N/A, bitrate: N/A
> Codec 0x2 is not in the full list.
> Stream #0:0, 0, 1/2700: Data: unknown_codec, 0/1
> Successfully opened the file.
> Output #0, mp4, to 'yo.mp4':
> Output file #0 does not contain any stream
>
> so it's definitely not, for instance, doing a probe or analyze on the
> MPEG stream
>
> Is this possible or any hints/tips/tricks I could possibly use?

 To answer my own question, I turned the dshow capture device into both
 an AVInputFormat *and* a URLProtocol that "wraps" the AVInputFormat.
 Apparently ffmpeg can receive "raw" bytes only from URLProtocol (?)
 This way worked great both "segmented" MPEG2VIDEO streams as well as
 "raw" MPEG TS streams.

>>>
>>> You should probably just make it use the mpegts demuxer directly, say
>>> like the rtsp demuxer.
>>> We have an API for that in the form of avpriv_mpegts_parse_packet
>>>
>>> Making an input device a protocol seems rather ugly, the user needs to
>>> know beforehand how to call it that way.
>
>
> True, I wish I didn't have to do it (ex: use AV_CODEC_ID_MPEG2TS and
> it "just work" -- any hints or clues to that welcome!) I'd like to
> give them access to the command line demultiplexing options that raw
> MPEG streams currently have.
>
> (ex: if they want 3 streams out of 10, like
> https://trac.ffmpeg.org/wiki/Map#Example8) without having to build
> that functionality into dshow parameters as well.
>
>
>> Or as an alternative, why not just add the mpegts demuxer to the DShow
>> graph as well and directly get video/audio streams.
>> For Live TV functionality, the MS demuxer seems to be working quite well.
>
> Mostly so that they can record a channel and its sibling sub channels
> (from the same card) all at once, which can be convenient at times.
>
> Cheers!
> -roger-
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] Add "sar" alias to "aspect" option of video encoders

[Carl Eugen Hoyos]

2016-08-08 20:58 GMT+02:00 Andrey Utkin :
> On Thu, Jul 14, 2016 at 05:27:08PM +, Carl Eugen Hoyos wrote:
>> Andrey Utkin  fastmail.com> writes:
>>
>> > It is impossible to pass "aspect" parameter to encoder from ffmpeg
>> > CLI because option from lavc/options_table.h is eclipsed by option
>> > with same name in ffmpeg_opt.c, which has different meaning (DAR,
>> > not SAR).
>>
>> Wasn't the old behaviour intended because it assured you cannot
>> pass contradicting options to the libraries via ffmpeg?
>
> I don't think so.
> Proper way to avoid contradiction is explicit check in code.

Where can this be checked?

> It is a usability flaw to be unable to pass certain encoder option in
> CLI while all other are passed finely.

But in which situation (which command line) could you not set the
aspect correctly before your patch?

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

Re: [FFmpeg-devel] [PATCH] [RFC] libavfilter HRTF/room acoustics filter [1/2]

[Michael Niedermayer]

On Mon, Aug 08, 2016 at 06:27:44PM +0200, Carl Eugen Hoyos wrote:
> 2016-08-07 2:08 GMT+02:00 Michael Niedermayer :
> >> On a somewhat related matter: I was browsing through the matrix encoder
> >> in libavresample/audio_mix_matrix.c, and possibly rediscovered the bug
> >> in https://trac.ffmpeg.org/ticket/4175 . Also, the 5-channel coefficient
> >> seems to disagrees with Dolby (see the notes I wrote at some point while
> >> editing the Wikipedia section in
> >> https://en.wikipedia.org/wiki/Talk:Dolby_Pro_Logic#Source_of_the_DPLII_encoding_matrix.3F).
> >
> > is this issue also affecting libswresample ?
> 
> The fact that users have reported several times that our Dolby downmix is not
> correct / not perfect indicates that there is an issue affecting
> libswresample, no?

There are 2 things here.
first, some of the downmix requires a phase shift, there is no
implementation of that in either resampler.

the way i understood the mail here is that the coefficients themselfs
are wrong too, that should not really be in case of libswresample, but
of course a wrong reference might have been used or whatever

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

Never trust a computer, one day, it may think you are the virus. -- Compn


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

Re: [FFmpeg-devel] [PATCH 1/2] avutil/version: Mention similarities and differences to semver

[Michael Niedermayer]

On Mon, Aug 08, 2016 at 06:32:23PM +0200, Carl Eugen Hoyos wrote:
> 2016-08-06 12:52 GMT+02:00 Michael Niedermayer :
> > QUESTION: is this the best place for this ?
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavutil/version.h | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/libavutil/version.h b/libavutil/version.h
> > index b2dffb7..7692def 100644
> > --- a/libavutil/version.h
> > +++ b/libavutil/version.h
> > @@ -35,6 +35,12 @@
> >   * Useful to check and match library version in order to maintain
> >   * backward compatibility.
> >   *
> 
> This is at least not a bad place imo.
> 

> > + * The FFmpeg libraries follow a versioning sheme very similar to
> > + * Semantic Versioning (http://semver.org/)
> > + * The difference is that the component called PATCH is called MICRO in 
> > FFmpeg
> > + * and its value is reset to 100 instead of 0 to keep it above or equal to 
> > 100.
> 
> > + * Also we do not increase MICRO for every bugfix or change.
> 
> But we want / should increase MICRO for every bugfix and every functional
> change, no?

i would say, yes we should

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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

Re: [FFmpeg-devel] [PATCH 1/2] avutil/version: Mention similarities and differences to semver

[Hendrik Leppkes]

On Mon, Aug 8, 2016 at 10:09 PM, Michael Niedermayer
 wrote:
> On Mon, Aug 08, 2016 at 06:32:23PM +0200, Carl Eugen Hoyos wrote:
>> 2016-08-06 12:52 GMT+02:00 Michael Niedermayer :
>> > QUESTION: is this the best place for this ?
>> >
>> > Signed-off-by: Michael Niedermayer 
>> > ---
>> >  libavutil/version.h | 6 ++
>> >  1 file changed, 6 insertions(+)
>> >
>> > diff --git a/libavutil/version.h b/libavutil/version.h
>> > index b2dffb7..7692def 100644
>> > --- a/libavutil/version.h
>> > +++ b/libavutil/version.h
>> > @@ -35,6 +35,12 @@
>> >   * Useful to check and match library version in order to maintain
>> >   * backward compatibility.
>> >   *
>>
>> This is at least not a bad place imo.
>>
>
>> > + * The FFmpeg libraries follow a versioning sheme very similar to
>> > + * Semantic Versioning (http://semver.org/)
>> > + * The difference is that the component called PATCH is called MICRO in 
>> > FFmpeg
>> > + * and its value is reset to 100 instead of 0 to keep it above or equal 
>> > to 100.
>>
>> > + * Also we do not increase MICRO for every bugfix or change.
>>
>> But we want / should increase MICRO for every bugfix and every functional
>> change, no?
>
> i would say, yes we should
>

Incrementing micro with every single commit sounds silly (which this
comes out to be, every bugfix or change?).
You might as well just generate that from the git commit counter then
and save everyone the pain of increasing that, not to mention constant
conflicts when porting commits between branches.

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

Re: [FFmpeg-devel] [PATCH 1/2] avutil/version: Mention similarities and differences to semver

[Carl Eugen Hoyos]

Hi!

2016-08-08 22:21 GMT+02:00 Hendrik Leppkes :
> Incrementing micro with every single commit sounds silly

Yes

> (which this comes out to be, every bugfix or change?).

No.

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

Re: [FFmpeg-devel] [PATCH] [RFC] libavfilter HRTF/room acoustics filter [1/2]

[Carl Eugen Hoyos]

Hi!

2016-08-08 21:59 GMT+02:00 Michael Niedermayer
> the way i understood the mail here is that the coefficients themselfs
> are wrong too, that should not really be in case of libswresample, but
> of course a wrong reference might have been used or whatever

Thanks for explaining, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Change bitrate on-the-fly PoC (Patch)

[Llorx]

New update with a small fix for Linux (Error compiling)

Jorge Fuentes

2016-08-07 1:04 GMT+02:00 Llorx :

> Hi Ronald,
>
> Well, this is a PoC. There are a lot of ways to implement this under a
> security context, so that's not a problem. For example, using ZeroMQ as
> Bodecs Bela says in the other thread, feature already implemented in ffmpeg
> as you can see here: https://www.ffmpeg.org/ffmpeg-all.html#zmq_002c-azmq
>
> As I said, this is just an undocumented-bad-written PoC, to get the point
> and argue about the feature, not argue about the bad implemented code. How
> to implement the feature is something we can discuss about later.
>
> Also, I doubt that every user build needs 99% of the filters, but they are
> there, just in case someone needs it. Why this quantity of filters,
> formats, codecs, etc? Because ffmpeg is a video processor software, it
> needs the maximum number of features, just in case.
>
> This feature is something some people already asked for (I found some of
> them when I googled about this some time ago) and I implemented it about 2
> years ago because I needed it too. Now I just want to release the code to
> the community as I had people contacting me to get a copy. The people that
> do not need it just don't enable it, as I don't enable channelsplit in my
> streams, for example.
>
> I think that this feature belongs to ffmpeg as a good % of users use
> ffmpeg as a live streaming software, including major videomixing software
> companies, using it as their main live video publisher software (See vMix).
> We have to understand that currently ffmpeg is not only a video converting
> software, but a live stream solution for most users, so it needs to have
> live streaming features, like other propietary video streaming software has
> (See Adobe Media Encoder. Altough I don't like how they implemented it).
>
> I use this feature a lot since I created it about 2 years ago, and now I
> just want to share it, as I know that some people will benefit from this
> because there is not any solution (and best of all, opensource solution)
> for these situations.
>
> Thank you for your point of view. I hope I made myself clear.
>
> Jorge Fuentes
>
> 2016-08-07 0:02 GMT+02:00 Ronald S. Bultje :
>
>> Hi,
>>
>> On Sat, Aug 6, 2016 at 9:00 AM, Llorx  wrote:
>>
>> > Hi,
>> >
>> > Some days ago I started a thread here:
>> > http://ffmpeg.org/pipermail/ffmpeg-devel/2016-August/197306.html
>> >
>> > Starting a new thread now because I lost my main thread mail and don't
>> know
>> > how to "reply" without having it in my inbox :-(
>> >
>> > ffmpeg has almost on-the-fly bitrate change control already built-in,
>> > checking rc_buffer_size and rc_max_rate changes, so I only needed to
>> change
>> > those values while ffmpeg was running.
>> >
>> > I attach my Proof of Concept.
>> >
>> > PoC limitations:
>> >  - Not configurable via command line.
>> >  - The build will start listening on localhost (127.0.0.1) UDP port
>> 32000
>> > always.
>>
>>
>> This is a pretty significant feature from a security PoV. I'm honestly not
>> even sure it belongs in upstream ffmpeg... Don't get me wrong, I
>> understand
>> what you're doing and why you're doing it this way and maybe this is the
>> best (or at least quickest) way to do it. I might have done it the same
>> way
>> if I was trying to do what you're doing, I'm not sure.
>>
>> But, having said that, I doubt that every user's build of ffmpeg
>> necessarily needs this feature.
>>
>> Ronald
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
>


0001-Change-bitrate-on-the-fly-PoC.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avutil/version: Mention similarities and differences to semver

[James Almer]

On 8/8/2016 5:09 PM, Michael Niedermayer wrote:
> On Mon, Aug 08, 2016 at 06:32:23PM +0200, Carl Eugen Hoyos wrote:
>> 2016-08-06 12:52 GMT+02:00 Michael Niedermayer :
>>> QUESTION: is this the best place for this ?
>>>
>>> Signed-off-by: Michael Niedermayer 
>>> ---
>>>  libavutil/version.h | 6 ++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/libavutil/version.h b/libavutil/version.h
>>> index b2dffb7..7692def 100644
>>> --- a/libavutil/version.h
>>> +++ b/libavutil/version.h
>>> @@ -35,6 +35,12 @@
>>>   * Useful to check and match library version in order to maintain
>>>   * backward compatibility.
>>>   *
>>
>> This is at least not a bad place imo.
>>
> 
>>> + * The FFmpeg libraries follow a versioning sheme very similar to
>>> + * Semantic Versioning (http://semver.org/)
>>> + * The difference is that the component called PATCH is called MICRO in 
>>> FFmpeg
>>> + * and its value is reset to 100 instead of 0 to keep it above or equal to 
>>> 100.
>>
>>> + * Also we do not increase MICRO for every bugfix or change.
>>
>> But we want / should increase MICRO for every bugfix and every functional
>> change, no?
> 
> i would say, yes we should

We're currently bumping micro when we do small, backwards compatible
changes like adding an AVOption to an existing module or changing a
default to inform API users of said change. This could be to fix bugs,
or just because the new default is more desirable.
Bug fixes that affect internal bits the user never interacts with
IMO don't justify bumping micro.

Besides, minor is bumped pretty often anyway, making micro almost
superfluous. For example, libavcodec got its latest major bump a year
ago and it's already at minor 51. That's like a minor bump per week.

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

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

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

[Paul B Mahol]

Hi,

patch attached.


0001-avfilter-add-fillgaps-filter.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v5 01/11] avformat: Add fifo pseudo-muxer

[Marton Balint]

On Thu, 4 Aug 2016, sebechlebsky...@gmail.com wrote:


From: Jan Sebechlebsky 

Signed-off-by: Jan Sebechlebsky 


applying the patches with "git am" seems to report some whitespace 
issues (empty lines at the end of files) could you have a look at those?


[...]


--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1436,6 +1436,96 @@ Specify whether to remove all fragments when finished. 
Default 0 (do not remove)

@end table

+@section fifo
+
+The fifo pseudo-muxer allows to separate encoding from any other muxer by using


... allows the separation of encoding and muxing by using a ...


+first-in-first-out queue and running the actual muxer in a separate thread. 
This
+is especially useful in combination with the @ref{tee} muxer and output to


I get errors for this line when builiding the docs:
doc/muxers.texi:1443: @ref reference to nonexistent node `tee'


+several destinations with different reliability/writing speed/latency.
+
+The behavior of fifo muxer in case of failure can be configured:


The behaviour of the fifo muxer if the queue fills up or if the output 
fails is selectable,



+@itemize @bullet
+
+@item
+output can be transparently restarted with configurable delay between retries
+based on real time or time of the processed stream.
+
+@item
+encoding can be blocked during temporary failure, or continue transparently
+dropping packets in case fifo queue fills up.
+
+@end itemize
+
+@table @option
+
+@item fifo_format
+Specify the format name. Useful if it cannot be guessed from the
+output name suffix.
+
+@item queue_size
+Specify size of the queue (number of packets). Default value is 60.
+
+@item format_opts
+Specify format options for the underlying muxer. Muxer options can be specified
+as a list of @var{key}=@var{value} pairs separated by ':'.
+
+@item drop_pkts_on_overflow @var{bool}
+If set to 1 (true), in case the fifo queue fills up, packets will be dropped
+rather than blocking the encoder. This allows to continue streaming without
+delaying the output, at the cost of ommiting part of the stream. By default


delaying the input you mean?


+this option is set to 0 (false), so in such cases the encoder will be blocked
+until the muxer processes some of the packets and none of them is lost.
+
+@item attempt_recovery @var{bool}
+If failure occurs, attempt to recover the output. This is especially useful
+when used with network output, allows to restart streaming transparently.
+By default this option set to 0 (false).
+
+@item max_recovery_attempts
+Sets maximum number of successive unsucessful recovery attempts after which
+the output fails permanently. Unlimited if set to zero. Default value is 16.
+
+@item recovery_wait_time @var{duration}
+Waiting time before the next recovery attempt after previous unsuccessfull
+recovery attempt. Default value is 5 seconds.
+
+s@item recovery_wait_streamtime @var{bool}
+If set to 0 (false), the real time is used when waiting for the recovery
+attempt (i.e. the recovery will be attempted after at least
+recovery_wait_time seconds).
+If set to 1 (true), the time of the processed stream is taken into account
+instead (i.e. the recovery will be attempted after at least recovery_wait_time
+seconds of the stream is omitted).
+By default, this option is set to 0 (false).
+
+@item recover_any_error @var{bool}
+If set to 1 (true), recovery will be attempted regardless of type of the error
+causing the failure. By default this option is set to 0 (false) and in case of
+certain errors the recovery is not attempted even when @ref{attempt_recovery}


... in case of certain (usually permanent) errors ...

I also get an error when building docs:
doc/muxers.texi:1504: @ref reference to nonexistent node `attempt_recovery'


+is set to 1.
+
+@item restart_with_keyframe @var{bool}
+Specify whether to wait for the keyframe after recovering from
+queue overflow or failure. This option is set to 0 (false) by default.
+
+@end table
+
+@subsection Examples
+
+@itemize
+
+@item
+Stream something to rtmp server, continue processing the stream at real-time
+rate even in case of temporary failure (network outage) and attempt to recover
+streaming every second indefinitely.
+@example
+ffmpeg -re -i ... -c:v libx264 -c:a mp2 -f fifo -fifo_format flv -map 0:v -map 
0:a
+  -block_on_overflow 0 -attempt_recovery 1 -recovery_wait_time 1
+  -max_recovery_attempts 0 rtmp://example.com/live/stream_name
+@end example
+
+@end itemize
+
@section tee



[...]


+/* If >0 recovery will be attempted regardless of error code
+ * (except AVERROR_EXIT, so exit request is never ignored) */
+int recover_any_error;
+
+/* Whether to drop packets in case the queue is full. */
+int drop_pkts_on_overflow;
+
+/* Whether to wait for keyframe when recovering
+ * from failure or queue overflow */
+int restart_with_keyframe;
+
+pthread_mutex_t overflow_flag_lock;
+/* Value > 0 signalizes queue overflow */


signals

[...]


+static void *fifo_consumer_thread(v

Re: [FFmpeg-devel] [PATCH]lavf/pcmdec: Map mime_type audio/L16 to the s16le demuxer

[Carl Eugen Hoyos]

Hi!

2016-08-05 12:44 GMT+02:00 Nicolas George :
> Le nonidi 19 thermidor, an CCXXIV, Carl Eugen Hoyos a écrit :
>> Hi!
>>
>> Attached patch implements RFC 2586.
>>
>> Please comment, Carl Eugen
>
>> From ba470c643c836826d75854e3e3539eb09ddd288a Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Fri, 5 Aug 2016 12:22:17 +0200
>> Subject: [PATCH] lavf/pcmdec: Map mime_type audio/L16 to s16le as specified
>>  in RFC 2586.
>>
>> ---
>>  libavformat/pcmdec.c |   63 
>> +-
>>  1 file changed, 42 insertions(+), 21 deletions(-)
>>
>> diff --git a/libavformat/pcmdec.c b/libavformat/pcmdec.c
>> index df94345..36ef2c2 100644
>> --- a/libavformat/pcmdec.c
>> +++ b/libavformat/pcmdec.c
>> @@ -36,6 +36,7 @@ static int pcm_read_header(AVFormatContext *s)
>>  {
>>  PCMAudioDemuxerContext *s1 = s->priv_data;
>>  AVStream *st;
>> +uint8_t *mime_type_opt = NULL;
>>
>>  st = avformat_new_stream(s, NULL);
>>  if (!st)
>> @@ -47,6 +48,25 @@ static int pcm_read_header(AVFormatContext *s)
>>  st->codecpar->sample_rate = s1->sample_rate;
>>  st->codecpar->channels= s1->channels;
>>
>> +av_opt_get(s->pb, "mime_type", AV_OPT_SEARCH_CHILDREN, &mime_type_opt);
>> +if (mime_type_opt) {
>
>> +const char *mime_type = mime_type_opt;
>
> I do not understand the need for that line.

Removed.

>> +size_t len = strlen(s->iformat->mime_type);
>
> Maybe I am missing something obvious, but I think s->iformat->mime_type is
> NULL for all the other formats. It needs to be checked.

Added the check.

>> +int rate, channels = 0;
>> +if (!av_strncasecmp(s->iformat->mime_type, mime_type, len)) {
>
>> +if (   !sscanf(mime_type + len, ";rate=%d;channels=%d", &rate, 
>> &channels)
>
> If I understand the way MIME type works, ";channels=2;rate=48000" would be
> exactly as valid, and spaces can surround the semicolons.

I changed this hunk.

>> +|| !rate) {
>> +av_log(s, AV_LOG_ERROR,
>> +   "Invalid sample_rate found in mime_type \"%s\"\n",
>> +   mime_type);
>> +return AVERROR_INVALIDDATA;
>> +}
>> +st->codecpar->sample_rate = rate;
>> +if (channels)
>> +st->codecpar->channels = channels;
>> +}
>> +}
>> +
>>  st->codecpar->bits_per_coded_sample =
>>  av_get_bits_per_sample(st->codecpar->codec_id);
>>
>> @@ -65,7 +85,7 @@ static const AVOption pcm_options[] = {
>>  { NULL },
>>  };
>>
>> -#define PCMDEF(name_, long_name_, ext, codec)   \
>
>> +#define PCMDEF(name_, long_name_, ext, codec, mime_type_)   \
>
> Instead of changing PCMDEF and all the subsequent declarations, you can
> create a new macro PCMDEF_WITH_MIME.
>
> Even simpler: make PCMDEF varadic, add __ARGS__ in the structure definition.
> Then, adding the MIME type is just a matter of adding ".mime_type = ..." in
> the macro call.

Yes, much simpler.

New patch attached.

Thank you, Carl Eugen
From 3ef0951db492f1425a574aac71fe73f144c2d99a Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 9 Aug 2016 00:46:57 +0200
Subject: [PATCH 2/2] lavf/pcmdec: Map mime_type audio/L16 to the s16le
 demuxer as specified in RFC 2586.

---
 libavformat/pcmdec.c  |   34 --
 libavformat/version.h |2 +-
 2 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/libavformat/pcmdec.c b/libavformat/pcmdec.c
index df94345..e3cc2ae 100644
--- a/libavformat/pcmdec.c
+++ b/libavformat/pcmdec.c
@@ -36,6 +36,7 @@ static int pcm_read_header(AVFormatContext *s)
 {
 PCMAudioDemuxerContext *s1 = s->priv_data;
 AVStream *st;
+uint8_t *mime_type = NULL;
 
 st = avformat_new_stream(s, NULL);
 if (!st)
@@ -47,6 +48,34 @@ static int pcm_read_header(AVFormatContext *s)
 st->codecpar->sample_rate = s1->sample_rate;
 st->codecpar->channels= s1->channels;
 
+av_opt_get(s->pb, "mime_type", AV_OPT_SEARCH_CHILDREN, &mime_type);
+if (mime_type && s->iformat->mime_type) {
+int rate = 0, channels = 0;
+size_t len = strlen(s->iformat->mime_type);
+if (!strncmp(s->iformat->mime_type, mime_type, len)) {
+uint8_t *options = mime_type + len;
+len = strlen(mime_type);
+while (options < mime_type + len) {
+options = strstr(options, ";");
+if (!options++)
+break;
+if (!rate)
+sscanf(options, " rate=%d", &rate);
+if (!channels)
+sscanf(options, " channels=%d", &channels);
+}
+if (!rate) {
+av_log(s, AV_LOG_ERROR,
+   "Invalid sample_rate found in mime_type \"%s\"\n",
+   mime_type);
+return AVERROR_INVALIDDATA;
+}
+st->codecpar->sample_rate = 

[FFmpeg-devel] [PATCH v2]Support QT b64a ARGB64 rawvideo

[Carl Eugen Hoyos]

Hi!

New patch attached that fixes ticket #5657.

Please comment, Carl Eugen
From ed664a5b16d0200675d64c564a9f776bdece569a Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 9 Aug 2016 00:55:27 +0200
Subject: [PATCH] lavc/raw: Support QT b64a ARGB64 rawvideo.

Decoder based on a patch by v0lt, v0lt rambler ru
Fixes ticket #5657.
---
 libavcodec/raw.c  |1 +
 libavcodec/rawdec.c   |   11 +++
 libavcodec/rawenc.c   |8 
 libavcodec/version.h  |2 +-
 libavformat/isom.c|1 +
 libavformat/version.h |2 +-
 6 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/libavcodec/raw.c b/libavcodec/raw.c
index d36b68b..d6aaf76 100644
--- a/libavcodec/raw.c
+++ b/libavcodec/raw.c
@@ -225,6 +225,7 @@ const PixelFormatTag ff_raw_pix_fmt_tags[] = {
 { AV_PIX_FMT_ABGR,MKTAG('A', 'B', 'G', 'R') },
 { AV_PIX_FMT_GRAY16BE,MKTAG('b', '1', '6', 'g') },
 { AV_PIX_FMT_RGB48BE, MKTAG('b', '4', '8', 'r') },
+{ AV_PIX_FMT_RGBA64BE,MKTAG('b', '6', '4', 'a') },
 
 /* vlc */
 { AV_PIX_FMT_YUV410P, MKTAG('I', '4', '1', '0') },
diff --git a/libavcodec/rawdec.c b/libavcodec/rawdec.c
index 765e567..87c7259 100644
--- a/libavcodec/rawdec.c
+++ b/libavcodec/rawdec.c
@@ -444,6 +444,17 @@ static int raw_decode(AVCodecContext *avctx, void *data, 
int *got_frame,
 }
 }
 
+if (avctx->codec_tag == AV_RL32("b64a") &&
+avctx->pix_fmt   == AV_PIX_FMT_RGBA64BE) {
+uint8_t *dst = frame->data[0];
+uint64_t v;
+int x;
+for (x = 0; x >> 3 < avctx->width * avctx->height; x += 8) {
+v = AV_RB64(&dst[x]);
+AV_WB64(&dst[x], v << 16 | v >> 48);
+}
+}
+
 if (avctx->field_order > AV_FIELD_PROGRESSIVE) { /* we have interlaced 
material flagged in container */
 frame->interlaced_frame = 1;
 if (avctx->field_order == AV_FIELD_TT || avctx->field_order == 
AV_FIELD_TB)
diff --git a/libavcodec/rawenc.c b/libavcodec/rawenc.c
index d837056..a2d5ccc 100644
--- a/libavcodec/rawenc.c
+++ b/libavcodec/rawenc.c
@@ -69,6 +69,14 @@ static int raw_encode(AVCodecContext *avctx, AVPacket *pkt,
 int x;
 for(x = 1; x < frame->height*frame->width*2; x += 2)
 pkt->data[x] ^= 0x80;
+} else if (avctx->codec_tag == AV_RL32("b64a") && ret > 0 &&
+frame->format == AV_PIX_FMT_RGBA64BE) {
+uint64_t v;
+int x;
+for (x = 0; x < frame->height * frame->width; x++) {
+v = AV_RB64(&pkt->data[8 * x]);
+AV_WB64(&pkt->data[8 * x], v << 48 | v >> 16);
+}
 }
 pkt->flags |= AV_PKT_FLAG_KEY;
 *got_packet = 1;
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 4ded1ee..306c280 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
 
 #define LIBAVCODEC_VERSION_MAJOR  57
 #define LIBAVCODEC_VERSION_MINOR  51
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
diff --git a/libavformat/isom.c b/libavformat/isom.c
index d412f06..cb457dd 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -86,6 +86,7 @@ const AVCodecTag ff_codec_movvideo_tags[] = {
 { AV_CODEC_ID_RAWVIDEO, MKTAG('A', 'B', 'G', 'R') },
 { AV_CODEC_ID_RAWVIDEO, MKTAG('b', '1', '6', 'g') },
 { AV_CODEC_ID_RAWVIDEO, MKTAG('b', '4', '8', 'r') },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('b', '6', '4', 'a') },
 { AV_CODEC_ID_RAWVIDEO, MKTAG('b', 'x', 'b', 'g') }, /* BOXX */
 { AV_CODEC_ID_RAWVIDEO, MKTAG('b', 'x', 'r', 'g') },
 { AV_CODEC_ID_RAWVIDEO, MKTAG('b', 'x', 'y', 'v') },
diff --git a/libavformat/version.h b/libavformat/version.h
index 07df407..590902d 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -33,7 +33,7 @@
 // Also please add any ticket numbers that you belive might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  57
 #define LIBAVFORMAT_VERSION_MINOR  46
-#define LIBAVFORMAT_VERSION_MICRO 100
+#define LIBAVFORMAT_VERSION_MICRO 102
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
-- 
1.7.10.4

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