Re: [FFmpeg-devel] [PATCH] avformat/segafilm - revert keyframe detection

[James Almer]

On 4/21/2018 4:34 AM, Gyan Doshi wrote:
> References:
> 
> http://www.ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228596.html
> http://www.ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228602.html
> 
> 
> 
> 0001-avformat-segafilm-revert-keyframe-detection.patch
> 
> 
> From a9b55290722ee6222b5cb5d067544f3846e1b07b Mon Sep 17 00:00:00 2001
> From: Gyan Doshi 
> Date: Sat, 21 Apr 2018 12:44:12 +0530
> Subject: [PATCH] avformat/segafilm - revert keyframe detection
> 
> Keyframe detection was inverted in cfe1a9d311 in order to fix keyframe
> flags set for the sample attached to trac #7091. However, that sample is
> errantly muxed.
> 
> As noted at
> https://web.archive.org/web/20020803104640/http://www.pcisys.net:80/~melanson/codecs/film-format.txt,
> the original keyframe detection logic is correct, and this patch
> restores it.
> ---
>  libavformat/segafilm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/segafilm.c b/libavformat/segafilm.c
> index e72c26b144..b0c6c419ce 100644
> --- a/libavformat/segafilm.c
> +++ b/libavformat/segafilm.c
> @@ -239,7 +239,7 @@ static int film_read_header(AVFormatContext *s)
>  } else {
>  film->sample_table[i].stream = film->video_stream_index;
>  film->sample_table[i].pts = AV_RB32([8]) & 0x7FFF;
> -film->sample_table[i].keyframe = (scratch[8] & 0x80) ? 
> AVINDEX_KEYFRAME : 0;
> +film->sample_table[i].keyframe = (scratch[8] & 0x80) ? 0 : 
> AVINDEX_KEYFRAME;
>  video_frame_counter++;
>  if (film->video_type)
>  av_add_index_entry(s->streams[film->video_stream_index],
> -- 2.12.2.windows.2

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

Re: [FFmpeg-devel] [PATCH] lavu/threadmessage: add av_thread_message_queue_nelem()

[Rostislav Pehlivanov]

On 21 April 2018 at 20:51, Clément Bœsch  wrote:

> ---
> Been away from FFmpeg for way too long. Hope this patch get me back on
> track. Feel free to nitpick on the name.
> ---
>  doc/APIchanges | 3 +++
>  libavutil/threadmessage.c  | 9 +
>  libavutil/threadmessage.h  | 5 +
>  libavutil/version.h| 2 +-
>  tests/api/api-threadmessage-test.c | 4 +++-
>  5 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 4f6ac2a031..393491c8e9 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>
>  API changes, most recent first:
>
> +2018-04-xx - xx - lavu 56.16.100 - threadmessage.h
> +  Add av_thread_message_queue_nelem().
> +
>   8< - FFmpeg 4.0 was cut here  8< -
>
>  2018-04-03 - d6fc031caf - lavu 56.13.100 - pixdesc.h
> diff --git a/libavutil/threadmessage.c b/libavutil/threadmessage.c
> index 872e9392b1..fed398926a 100644
> --- a/libavutil/threadmessage.c
> +++ b/libavutil/threadmessage.c
> @@ -102,6 +102,15 @@ void av_thread_message_queue_free(AVThreadMessageQueue
> **mq)
>  #endif
>  }
>
> +int av_thread_message_queue_nelem(AVThreadMessageQueue *mq)
> +{
> +int ret;
> +pthread_mutex_lock(>lock);
> +ret = av_fifo_size(mq->fifo);
> +pthread_mutex_unlock(>lock);
> +return ret / mq->elsize;
> +}
> +
>  #if HAVE_THREADS
>
>  static int av_thread_message_queue_send_locked(AVThreadMessageQueue *mq,
> diff --git a/libavutil/threadmessage.h b/libavutil/threadmessage.h
> index 8480a0a3db..e41d95ccf7 100644
> --- a/libavutil/threadmessage.h
> +++ b/libavutil/threadmessage.h
> @@ -95,6 +95,11 @@ void 
> av_thread_message_queue_set_err_recv(AVThreadMessageQueue
> *mq,
>  void av_thread_message_queue_set_free_func(AVThreadMessageQueue *mq,
> void (*free_func)(void *msg));
>
> +/**
> + * Return the current number of messages in the queue.
> + */
> +int av_thread_message_queue_nelem(AVThreadMessageQueue *mq);
> +
>  /**
>   * Flush the message queue
>   *
> diff --git a/libavutil/version.h b/libavutil/version.h
> index 387421775f..23567000a3 100644
> --- a/libavutil/version.h
> +++ b/libavutil/version.h
> @@ -79,7 +79,7 @@
>   */
>
>  #define LIBAVUTIL_VERSION_MAJOR  56
> -#define LIBAVUTIL_VERSION_MINOR  15
> +#define LIBAVUTIL_VERSION_MINOR  16
>  #define LIBAVUTIL_VERSION_MICRO 100
>
>  #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
> diff --git a/tests/api/api-threadmessage-test.c
> b/tests/api/api-threadmessage-test.c
> index 05a8062b8c..494808f176 100644
> --- a/tests/api/api-threadmessage-test.c
> +++ b/tests/api/api-threadmessage-test.c
> @@ -130,7 +130,9 @@ static void *receiver_thread(void *arg)
>
>  for (i = 0; i < rd->workload; i++) {
>  if (rand() % rd->workload < rd->workload / 10) {
> -av_log(NULL, AV_LOG_INFO, "receiver #%d: flushing the
> queue\n", rd->id);
> +av_log(NULL, AV_LOG_INFO, "receiver #%d: flushing the queue, "
> +   "discarding %d message(s)\n", rd->id,
> +   av_thread_message_queue_nelem(rd->queue));
>  av_thread_message_flush(rd->queue);
>  } else {
>  struct message msg;
> --
> 2.17.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

I think av_thread_message_queue_elems would be a better name, had to think
for a good period of time what "nelem" meant.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]configure: Assume MSVCRT when compiling with MingW

[Hendrik Leppkes]

On Sun, Apr 22, 2018 at 1:50 AM, Carl Eugen Hoyos  wrote:
> 2018-04-22 1:29 GMT+02:00, Hendrik Leppkes :
>> On Sun, Apr 22, 2018 at 1:02 AM, Carl Eugen Hoyos 
>> wrote:
>>> 2018-04-22 0:53 GMT+02:00, Reino Wijnsma :
 On 21-4-2018 22:43, Carl Eugen Hoyos  wrote:
> Attached patch is supposed to fix an old issue with debug messages and
> a currently reported compilation warning that I believe also indicates
> a possible abort() on Windows:
> libavformat/hlsenc.c:1676:63: warning: unknown conversion type
> character 's' in format
> Patch untested.
>
> Please review, Carl Eugen
 I'm hardly an expert, but I'm not sure this is a good idea.
 After configuring FFmpeg summarizes:
 [...]
 C library msvcrt
 [...]
 This has always been "mingw64" before. And next:

 $ make libavformat/hlsenc.o
 CC  libavformat/hlsenc.o
 In file included from ./libavutil/common.h:491:0,
  from ./libavutil/avutil.h:296,
  from ./libavutil/avassert.h:31,
  from libavformat/hlsenc.c:36:
 ./libavutil/internal.h:250:10: fatal error: crtversion.h: No such file or
 directory
>>>
>>> Thank you for testing.
>>
>> To clarify: The C library flag controls both the build and runtime
>> environment, not only the runtime environment. Usually thats
>> identical, but in the case of mingw it is not, so extra care has to be
>> taken.
>>
>>>
>>> Note that I believe the warning indicates a possible
>>> crash on runtime.
>>>
>>
>> It would only crash if you use the security-enhanced versions of the
>> format functions (ie. with a _s suffix), which we obviously don't.
>
> People repeatedly reported such crashes (they only happen
> in rare cases because debug output and/or broken streams
> are needed) - how did they change the functions?
>

This hlsenc thing is unrelated to any input data or any debug logging,
its always executed if you request the date-based filename scheme.
What you are referring to is probably related to using unsupported
format specifiers in av_log statements, which may end up in a custom
log callback that the user wrote, possibly using the secure printf
functions. But this is strftime.

Anyway nothing wrong with fixing this warning, but this was just not
the way to do it.

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

Re: [FFmpeg-devel] [PATCH]lavf/dashdec: Do not use memcpy() to copy a struct

[Liu Steven]

> 在 2018年4月22日，上午5:23，wm4  写道：
> 
> On Sat, 21 Apr 2018 22:55:33 +0200
> Carl Eugen Hoyos  wrote:
> 
>> 2018-04-19 4:45 GMT+02:00, Steven Liu :
>>> 
>>> 
 On 19 Apr 2018, at 03:20, wm4  wrote:
 
 On Wed, 18 Apr 2018 16:10:26 -0300
 James Almer  wrote:
 
> On 4/18/2018 2:45 PM, Carl Eugen Hoyos wrote:  
>> Hi!
>> 
>> Attached patch is supposed to fix a warning (and a bug), is this the
>> right and preferred fix?
>> 
>> Please comment, Carl Eugen
>> 
>> 
>> 0001-lavf-dashdec-Do-not-use-memcpy-to-copy-a-struct.patch
>> 
>> 
>> From cf7d2aefc1a3b3a2e9f578ede43906ed6ee96bfd Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Wed, 18 Apr 2018 19:42:57 +0200
>> Subject: [PATCH] lavf/dashdec: Do not use memcpy() to copy a struct.
>> 
>> Fixes a warning:
>> libavformat/dashdec.c:1900:65: warning: argument to 'sizeof' in 'memcpy'
>> call is the same pointer type 'struct fragment *' as the destination;
>> expected 'struct fragment' or an explicit length
>> ---
>> libavformat/dashdec.c |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
>> index 6304ad9..917fb54 100644
>> --- a/libavformat/dashdec.c
>> +++ b/libavformat/dashdec.c
>> @@ -1897,7 +1897,7 @@ static int init_section_compare_audio(DASHContext
>> *c)
>> 
>> static void copy_init_section(struct representation *rep_dest, struct
>> representation *rep_src)
>> {
>> -memcpy(rep_dest->init_section, rep_src->init_section,
>> sizeof(rep_src->init_section));
>> +rep_dest->init_section = rep_src->init_section;  
> 
> This would only copy the pointer. The fact memcpy was used here makes me
> think the intention was to copy the contents of the struct, so something
> like
> 
> *rep_dest->init_section = *rep_src->init_section;
> 
> or
> 
> memcpy(rep_dest->init_section, rep_src->init_section,
> sizeof(*rep_src->init_section));
> 
> Would be the correct fix.  
 
 The first version would be preferable. But I think the original code
 makes no sense and was never really tested. Looking slightly closer at
 the code, init_section points to a struct that contains a further
 pointer, which would require allocating and dup'ing the memory.
 
 Also the rep_dest->init_sec_buf allocation call isn't even checked. It
 just memcpy's to a NULL pointer. This is some seriously shit code, and
 all of dashdec.c is shit. I'd like to ask Steven Liu (who
 reviewed/pushed the patch that added this copy_init_section code) to
 _actually_ review the patches and to keep up the quality standards in
 this project (which are slightly higher than this).  
>>> Yes, that is my mistake, patch welcome and welcome you to contribute code
>>> for refine the dashdec  
> 
> The problem was that you didn't actually review the patch. There's
> really no excuse for the code that has been added. It's not even valid
> C. It's sort of your responsibility to make sure this doesn't happen.
> Sorry if my words were a bit too direct, but for very new code dashdec
> has a bit too many issues than it should have. Reviewing means more
> than just replying "LGTM" and pushing a patch.
The problem is how do you check i have not check the patch is ok or not?
Only myself review the patch, where are the other guys when i response LGTM?
you guys can objections the patch, but no, isn’t it?
> 
>> No (independently of what I think of Vincent's character and tone).
> 
> Agreed, independently of what I think of you.
> 
> Just by the way, some have lamented that they think of it as "doxing"
> when you post my real name on this list. Do you think this is acceptable
> behavior? Don't worry, my real name has been on my github profile for
> years (and before that on the mplayer2 website), in both cases visible
> to anyone, so you don't have to fear that your childish attempts to
> achieve whatever have any effect.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



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

Re: [FFmpeg-devel] [PATCH]configure: Assume MSVCRT when compiling with MingW

[Carl Eugen Hoyos]

2018-04-22 1:29 GMT+02:00, Hendrik Leppkes :
> On Sun, Apr 22, 2018 at 1:02 AM, Carl Eugen Hoyos 
> wrote:
>> 2018-04-22 0:53 GMT+02:00, Reino Wijnsma :
>>> On 21-4-2018 22:43, Carl Eugen Hoyos  wrote:
 Attached patch is supposed to fix an old issue with debug messages and
 a currently reported compilation warning that I believe also indicates
 a possible abort() on Windows:
 libavformat/hlsenc.c:1676:63: warning: unknown conversion type
 character 's' in format
 Patch untested.

 Please review, Carl Eugen
>>> I'm hardly an expert, but I'm not sure this is a good idea.
>>> After configuring FFmpeg summarizes:
>>> [...]
>>> C library msvcrt
>>> [...]
>>> This has always been "mingw64" before. And next:
>>>
>>> $ make libavformat/hlsenc.o
>>> CC  libavformat/hlsenc.o
>>> In file included from ./libavutil/common.h:491:0,
>>>  from ./libavutil/avutil.h:296,
>>>  from ./libavutil/avassert.h:31,
>>>  from libavformat/hlsenc.c:36:
>>> ./libavutil/internal.h:250:10: fatal error: crtversion.h: No such file or
>>> directory
>>
>> Thank you for testing.
>
> To clarify: The C library flag controls both the build and runtime
> environment, not only the runtime environment. Usually thats
> identical, but in the case of mingw it is not, so extra care has to be
> taken.
>
>>
>> Note that I believe the warning indicates a possible
>> crash on runtime.
>>
>
> It would only crash if you use the security-enhanced versions of the
> format functions (ie. with a _s suffix), which we obviously don't.

People repeatedly reported such crashes (they only happen
in rare cases because debug output and/or broken streams
are needed) - how did they change the functions?

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

Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[Carl Eugen Hoyos]

2018-04-22 1:30 GMT+02:00, Hendrik Leppkes :
> On Sat, Apr 21, 2018 at 10:15 PM, Carl Eugen Hoyos 
> wrote:
>> 2018-04-21 21:59 GMT+02:00, Thomas Volkert :
>>> On 21.04.2018 21:46, Carl Eugen Hoyos wrote:
>>>
 2018-04-21 21:37 GMT+02:00, Hendrik Leppkes :
>>
> Can you elaborate what you think the problem is?
 Given that we allow muxing against gpl and Apache, I believe
 the patch can be improved.
>>>
>>> Okay, what do you suggest  in detail?
>>
>> I believe the easiest solution is to "require version 3"
>> as we do for other Apache libraries (libvmaf and
>> libopencore).
>>
>
> mbedTLS is dual-licensed under GPLv2 as well, so why
> not allow it with GPL version 2 as well?

Because - iiuc - only releases are GPL, not the "current versions".

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

Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[Hendrik Leppkes]

On Sat, Apr 21, 2018 at 10:15 PM, Carl Eugen Hoyos  wrote:
> 2018-04-21 21:59 GMT+02:00, Thomas Volkert :
>> On 21.04.2018 21:46, Carl Eugen Hoyos wrote:
>>
>>> 2018-04-21 21:37 GMT+02:00, Hendrik Leppkes :
>
 Can you elaborate what you think the problem is?
>>> Given that we allow muxing against gpl and Apache, I believe
>>> the patch can be improved.
>>
>> Okay, what do you suggest  in detail?
>
> I believe the easiest solution is to "require version 3"
> as we do for other Apache libraries (libvmaf and
> libopencore).
>

mbedTLS is dual-licensed under GPLv2 as well, so why not allow it with
GPL version 2 as well?

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

Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[Thomas Volkert]

On 22.04.2018 01:33, Thomas Volkert wrote:
> From: Thomas Volkert 
>
> ---
>  Changelog |   1 +
>  configure |  31 ++--
>  libavformat/Makefile  |   1 +
>  libavformat/rtmpdh.c  |  55 
>  libavformat/rtmpdh.h  |   5 +
>  libavformat/tls_mbedtls.c | 351 
> ++
>  libavformat/version.h |   2 +-
>  7 files changed, 436 insertions(+), 10 deletions(-)
>  create mode 100644 libavformat/tls_mbedtls.c
>
>

...license has changed.

Best regards,
Thomas.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[Thomas Volkert]

From: Thomas Volkert 

---
 Changelog |   1 +
 configure |  31 ++--
 libavformat/Makefile  |   1 +
 libavformat/rtmpdh.c  |  55 
 libavformat/rtmpdh.h  |   5 +
 libavformat/tls_mbedtls.c | 351 ++
 libavformat/version.h |   2 +-
 7 files changed, 436 insertions(+), 10 deletions(-)
 create mode 100644 libavformat/tls_mbedtls.c

diff --git a/Changelog b/Changelog
index 3ed4874..0a344f3 100644
--- a/Changelog
+++ b/Changelog
@@ -3,6 +3,7 @@ releases are sorted from youngest to oldest.
 
 version :
 - deblock filter
+- support mbedTLS based TLS
 
 
 version 4.0:
diff --git a/configure b/configure
index dee507c..c1f21cd 100755
--- a/configure
+++ b/configure
@@ -213,7 +213,7 @@ External library support:
   --enable-gmp enable gmp, needed for rtmp(t)e support
if openssl or librtmp is not used [no]
   --enable-gnutls  enable gnutls, needed for https support
-   if openssl or libtls is not used [no]
+   if openssl, libtls or mbedtls is not used [no]
   --disable-iconv  disable iconv [autodetect]
   --enable-jni enable JNI support [no]
   --enable-ladspa  enable LADSPA audio filtering [no]
@@ -262,7 +262,7 @@ External library support:
   --enable-libtesseractenable Tesseract, needed for ocr filter [no]
   --enable-libtheora   enable Theora encoding via libtheora [no]
   --enable-libtls  enable LibreSSL (via libtls), needed for https 
support
-   if openssl or gnutls is not used [no]
+   if openssl, gnutls or mbedtls is not used [no]
   --enable-libtwolame  enable MP2 encoding via libtwolame [no]
   --enable-libv4l2 enable libv4l2/v4l-utils [no]
   --enable-libvidstab  enable video stabilization using vid.stab [no]
@@ -290,13 +290,15 @@ External library support:
   --disable-lzma   disable lzma [autodetect]
   --enable-decklinkenable Blackmagic DeckLink I/O support [no]
   --enable-libndi_newtek   enable Newteck NDI I/O support [no]
+  --enable-mbedtls enable mbedTLS, needed for https support
+   if openssl, gnutls or libtls is not used [no]
   --enable-mediacodec  enable Android MediaCodec support [no]
   --enable-libmysofa   enable libmysofa, needed for sofalizer filter [no]
   --enable-openal  enable OpenAL 1.1 capture support [no]
   --enable-opencl  enable OpenCL processing [no]
   --enable-opengl  enable OpenGL rendering [no]
   --enable-openssl enable openssl, needed for https support
-   if gnutls or libtls is not used [no]
+   if gnutls, libtls or mbedtls is not used [no]
   --disable-sndio  disable sndio support [autodetect]
   --disable-schannel   disable SChannel SSP, needed for TLS support on
Windows if openssl and gnutls are not used 
[autodetect]
@@ -1654,6 +1656,7 @@ EXTERNAL_LIBRARY_VERSION3_LIST="
 libopencore_amrwb
 libvmaf
 libvo_amrwbenc
+mbedtls
 rkmpp
 "
 
@@ -3117,7 +3120,7 @@ fifo_muxer_deps="threads"
 flac_demuxer_select="flac_parser"
 hds_muxer_select="flv_muxer"
 hls_muxer_select="mpegts_muxer"
-hls_muxer_suggest="gcrypt openssl"
+hls_muxer_suggest="gcrypt openssl mbedtls"
 image2_alias_pix_demuxer_select="image2_demuxer"
 image2_brender_pix_demuxer_select="image2_demuxer"
 ipod_muxer_select="mov_muxer"
@@ -3229,7 +3232,7 @@ xv_outdev_extralibs="-lXv -lX11 -lXext"
 async_protocol_deps="threads"
 bluray_protocol_deps="libbluray"
 ffrtmpcrypt_protocol_conflict="librtmp_protocol"
-ffrtmpcrypt_protocol_deps_any="gcrypt gmp openssl"
+ffrtmpcrypt_protocol_deps_any="gcrypt gmp openssl mbedtls"
 ffrtmpcrypt_protocol_select="tcp_protocol"
 ffrtmphttp_protocol_conflict="librtmp_protocol"
 ffrtmphttp_protocol_select="http_protocol"
@@ -3249,7 +3252,7 @@ librtmpt_protocol_deps="librtmp"
 librtmpte_protocol_deps="librtmp"
 libsmbclient_protocol_deps="libsmbclient gplv3"
 libssh_protocol_deps="libssh"
-libtls_conflict="openssl gnutls"
+libtls_conflict="openssl gnutls mbedtls"
 mmsh_protocol_select="http_protocol"
 mmst_protocol_select="network"
 libsrt_protocol_deps="libsrt"
@@ -3269,13 +3272,13 @@ rtmpte_protocol_suggest="zlib"
 rtmpts_protocol_select="ffrtmphttp_protocol https_protocol"
 rtmpts_protocol_suggest="zlib"
 rtp_protocol_select="udp_protocol"
-schannel_conflict="openssl gnutls libtls"
+schannel_conflict="openssl gnutls libtls mbedtls"
 sctp_protocol_deps="struct_sctp_event_subscribe struct_msghdr_msg_flags"
 sctp_protocol_select="network"
-securetransport_conflict="openssl gnutls libtls"
+securetransport_conflict="openssl gnutls libtls mbedtls"
 srtp_protocol_select="rtp_protocol srtp"
 tcp_protocol_select="network"
-tls_protocol_deps_any="gnutls openssl schannel 

Re: [FFmpeg-devel] [PATCH]configure: Assume MSVCRT when compiling with MingW

[Hendrik Leppkes]

On Sun, Apr 22, 2018 at 1:02 AM, Carl Eugen Hoyos  wrote:
> 2018-04-22 0:53 GMT+02:00, Reino Wijnsma :
>> On 21-4-2018 22:43, Carl Eugen Hoyos  wrote:
>>> Attached patch is supposed to fix an old issue with debug messages and
>>> a currently reported compilation warning that I believe also indicates
>>> a possible abort() on Windows:
>>> libavformat/hlsenc.c:1676:63: warning: unknown conversion type
>>> character 's' in format
>>> Patch untested.
>>>
>>> Please review, Carl Eugen
>> I'm hardly an expert, but I'm not sure this is a good idea.
>> After configuring FFmpeg summarizes:
>> [...]
>> C library msvcrt
>> [...]
>> This has always been "mingw64" before. And next:
>>
>> $ make libavformat/hlsenc.o
>> CC  libavformat/hlsenc.o
>> In file included from ./libavutil/common.h:491:0,
>>  from ./libavutil/avutil.h:296,
>>  from ./libavutil/avassert.h:31,
>>  from libavformat/hlsenc.c:36:
>> ./libavutil/internal.h:250:10: fatal error: crtversion.h: No such file or
>> directory
>
> Thank you for testing.

To clarify: The C library flag controls both the build and runtime
environment, not only the runtime environment. Usually thats
identical, but in the case of mingw it is not, so extra care has to be
taken.

>
> Note that I believe the warning indicates a possible
> crash on runtime.
>

It would only crash if you use the security-enhanced versions of the
format functions (ie. with a _s suffix), which we obviously don't.
That particular code in hlsenc has always been very weird though,
maybe configure should just check support for that format code instead
of somehow probing that at runtime.

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

Re: [FFmpeg-devel] [PATCH] lavu/threadmessage: add av_thread_message_queue_nelem()

[Michael Niedermayer]

On Sat, Apr 21, 2018 at 09:51:37PM +0200, Clément Bœsch wrote:
> ---
> Been away from FFmpeg for way too long. Hope this patch get me back on
> track. Feel free to nitpick on the name.
> ---
>  doc/APIchanges | 3 +++
>  libavutil/threadmessage.c  | 9 +
>  libavutil/threadmessage.h  | 5 +
>  libavutil/version.h| 2 +-
>  tests/api/api-threadmessage-test.c | 4 +++-
>  5 files changed, 21 insertions(+), 2 deletions(-)

breaks build with:
make distclean ; ./configure --disable-pthreads && make -j12

libavutil/threadmessage.c: In function ‘av_thread_message_queue_nelem’:
libavutil/threadmessage.c:108:5: error: implicit declaration of function 
‘pthread_mutex_lock’ [-Werror=implicit-function-declaration]
 pthread_mutex_lock(>lock);
 ^
libavutil/threadmessage.c:108:27: error: ‘AVThreadMessageQueue’ has no member 
named ‘lock’
 pthread_mutex_lock(>lock);
   ^
libavutil/threadmessage.c:109:26: error: ‘AVThreadMessageQueue’ has no member 
named ‘fifo’
 ret = av_fifo_size(mq->fifo);
  ^
libavutil/threadmessage.c:110:5: error: implicit declaration of function 
‘pthread_mutex_unlock’ [-Werror=implicit-function-declaration]
 pthread_mutex_unlock(>lock);
 ^
libavutil/threadmessage.c:110:29: error: ‘AVThreadMessageQueue’ has no member 
named ‘lock’
 pthread_mutex_unlock(>lock);
 ^
libavutil/threadmessage.c:111:20: error: ‘AVThreadMessageQueue’ has no member 
named ‘elsize’
 return ret / mq->elsize;
^
libavutil/threadmessage.c:112:1: error: control reaches end of non-void 
function [-Werror=return-type]
 }
 ^

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

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


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

Re: [FFmpeg-devel] [PATCH]configure: Assume MSVCRT when compiling with MingW

[Carl Eugen Hoyos]

2018-04-22 0:53 GMT+02:00, Reino Wijnsma :
> On 21-4-2018 22:43, Carl Eugen Hoyos  wrote:
>> Attached patch is supposed to fix an old issue with debug messages and
>> a currently reported compilation warning that I believe also indicates
>> a possible abort() on Windows:
>> libavformat/hlsenc.c:1676:63: warning: unknown conversion type
>> character 's' in format
>> Patch untested.
>>
>> Please review, Carl Eugen
> I'm hardly an expert, but I'm not sure this is a good idea.
> After configuring FFmpeg summarizes:
> [...]
> C library msvcrt
> [...]
> This has always been "mingw64" before. And next:
>
> $ make libavformat/hlsenc.o
> CC  libavformat/hlsenc.o
> In file included from ./libavutil/common.h:491:0,
>  from ./libavutil/avutil.h:296,
>  from ./libavutil/avassert.h:31,
>  from libavformat/hlsenc.c:36:
> ./libavutil/internal.h:250:10: fatal error: crtversion.h: No such file or
> directory

Thank you for testing.

Note that I believe the warning indicates a possible
crash on runtime.

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

Re: [FFmpeg-devel] [PATCH]configure: Assume MSVCRT when compiling with MingW

[Reino Wijnsma]

On 21-4-2018 22:43, Carl Eugen Hoyos  wrote:
> Attached patch is supposed to fix an old issue with debug messages and
> a currently reported compilation warning that I believe also indicates
> a possible abort() on Windows:
> libavformat/hlsenc.c:1676:63: warning: unknown conversion type
> character 's' in format
> Patch untested.
>
> Please review, Carl Eugen
I'm hardly an expert, but I'm not sure this is a good idea.
After configuring FFmpeg summarizes:
[...]
C library msvcrt
[...]
This has always been "mingw64" before. And next:

$ make libavformat/hlsenc.o
CC  libavformat/hlsenc.o
In file included from ./libavutil/common.h:491:0,
 from ./libavutil/avutil.h:296,
 from ./libavutil/avassert.h:31,
 from libavformat/hlsenc.c:36:
./libavutil/internal.h:250:10: fatal error: crtversion.h: No such file or 
directory
 #include 
  ^~
compilation terminated.
make: *** [ffbuild/common.mak:60: libavformat/hlsenc.o] Error 1

Also when I use the makefile it errors out right from the start:

CC  libavdevice/alldevices.o
In file included from ./libavutil/common.h:491:0,
 from ./libavutil/avutil.h:296,
 from ./libavutil/samplefmt.h:24,
 from ./libavcodec/avcodec.h:31,
 from ./libavformat/avformat.h:319,
 from ./libavformat/internal.h:27,
 from libavdevice/alldevices.c:23:
./libavutil/internal.h:250:10: fatal error: crtversion.h: No such file or 
directory
 #include 
  ^~
compilation terminated.
make: *** [ffbuild/common.mak:60: libavdevice/alldevices.o] Error 1

-- Reino

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

Re: [FFmpeg-devel] [PATCH]lavf/rtmpcrypt: Add a cast to silence a warning

[Reino Wijnsma]

On 16-4-2018 0:19, Carl Eugen Hoyos  wrote:
> rtmpe_write() exploits knowledge about av_rc4_crypt() internals and
> passes the same
> pointer as src and dst. I assume this is intentional for performance
> reasons, the only
> way to silence the resulting warning is a cast afaict.
>
> Please comment, Carl Eugen
$ make libavformat/rtmpcrypt.o
CC  libavformat/rtmpcrypt.o

No more warning.

-- Reino

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

Re: [FFmpeg-devel] lavf/os_support: Only compile inet_aton() if getaddrinfo() is needed

[Reino Wijnsma]

On 16-4-2018 1:33, Carl Eugen Hoyos  wrote:
> Attached patch is supposed to silence a user-reported warning when
> inet_aton() is missing but getaddrinfo() is supported.
> Untested.
>
> Please review, Carl Eugen
$ make libavformat/os_support.o
CC  libavformat/os_support.o
libavformat/os_support.c: In function 'ff_poll':
libavformat/os_support.c:248:23: warning: comparison of unsigned expression < 0 
is always false [-Wtype-limits]
 if (fds[i].fd < 0)
   ^

The warning this patch is for is gone now. Thanks.

-- Reino

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

Re: [FFmpeg-devel] [PATCH 3/8] lavu: add a Vulkan hwcontext

[Carl Eugen Hoyos]

2018-04-21 23:33 GMT+02:00, Rostislav Pehlivanov :
> On 21 April 2018 at 21:24, Carl Eugen Hoyos  wrote:
>
>> 2018-04-20 6:30 GMT+02:00, Rostislav Pehlivanov :
>>
>> > +[AV_PIX_FMT_P010]  =
>> > VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16,
>>
>> > +[AV_PIX_FMT_YUV420P10] =
>> > VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_420_UNORM_3PACK16,
>>
>> I don't think both can be correct (unless "PACK16" has no meaning).

> They're both correct and work.

That's really strange...
(Could this be a bug in the driver?)

Thank you for testing, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/dashdec: Do not use memcpy() to copy a struct

[wm4]

On Sat, 21 Apr 2018 17:56:27 -0400
"Helmut K. C. Tessarek"  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> 
> On 2018-04-21 17:23, wm4 wrote:
> > Just by the way, some have lamented that they think of it as
> > "doxing" when you post my real name on this list.  
> 
> I don't really care, if somebody is using a pseudonym or their real name.

Well I'm just saying how others interpreted CE's behavior.

> However, I have to say that if sombody is using not their real name,
> especially when their tone is often agressive and unfiltered, it
> rather begs the question why that is.
> 
> Is that person afraid that an employer might come across some of this
> crap when doing research on a potential candidate?
> Is that person not confident enough to stand by their opinion.
> 
> Seriously, what is it?
> 
> Btw, I myself often use blunt comments, which are mostly seen and read
> as harsh, undiplomatic, and rude. I hate poltical correctness and love
> sarcasm. Non of these traits are a plus in public. People love sugar
> coating and talking around a problem, all in the name of diplomacy.

It would be a big bother to change everything. Often you need a
pseudonym anyway, because account names are handier when they are
short. So why throw 2 names around?

Also this email address was meant as spam sink in the first place so it
has no meaningful name (registering to dozens of sites and mailing
lists which all show the mail address in plain text, which meant it'd
likely get a lot of spam). And one thing I don't want to do for sure is
giving Google my name for free. So I'd probably want to change my email
and email service too if I were to use my real name on this list.

Regarding employers, they'd get my "pseudonym" anyway because I'd put
a link to my github repository on my resume.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/dashdec: Do not use memcpy() to copy a struct

[Helmut K. C. Tessarek]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


On 2018-04-21 17:23, wm4 wrote:
> Just by the way, some have lamented that they think of it as
> "doxing" when you post my real name on this list.

I don't really care, if somebody is using a pseudonym or their real name.

However, I have to say that if sombody is using not their real name,
especially when their tone is often agressive and unfiltered, it
rather begs the question why that is.

Is that person afraid that an employer might come across some of this
crap when doing research on a potential candidate?
Is that person not confident enough to stand by their opinion.

Seriously, what is it?

Btw, I myself often use blunt comments, which are mostly seen and read
as harsh, undiplomatic, and rude. I hate poltical correctness and love
sarcasm. Non of these traits are a plus in public. People love sugar
coating and talking around a problem, all in the name of diplomacy.

- -- 
regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE191csiqpm8f5Ln9WvgmFNJ1E3QAFAlrbs4MACgkQvgmFNJ1E
3QDEMA//SZNScbz+ngk0UU040cWdT6Tek83Dh5RhKwfTRzY7VlvTnsQTYG/ktJn8
2yiLUvMQWh+ENr+Kxe9MosFR7kDOkD4s/P199IkmQSC0Vdh0YwLNsaVamziAFjHP
ZXbpn0v+PasU5raGbpJfQE0QXNAdDbRUORzEv4cz+8oZ3syTfGvSArkbVKsULrrX
haOLbb/lb/qt2igduLBEa2Ir/3WYpMw5Ead11FH57828QKzCywtdS3ZYKf4PuBRT
3T1N1NI1P+9oMQC860TPa7xzFVBIl3kvsUh6J7QurG5UnuGR0AznAMRiDC+YoW9m
588ZX/Z5nlYFiW3VIDvwoErWWf/3EvcZrGAbqvOoAVFEnlQ2eKdSFEHrwkkhF8Zg
St/O3ZEP+IzBzlr8stxVLxXSN81URHHlB4f3SLUtVZ45HHwR4WlMDk960SYwRzym
2mst91cS5fyEeCPkTvBkbhPQaVnYUBmYVqq1VN3v/9Y7W5DpKIxhIYBa4wXGSJ1I
2jaYXhxskNvbiiPogfRBWFZUvnx2oAMTUa0+3IXp05MlPh/1r1swv30KRyzRscjE
pLQVJo6s97pM1sTvd2fBWJnWCPYm3/dZSqNHPZt8BjmRvotXOhD29zb6FPaYJCs9
nyKR78VZVC9vPycFdWiUQYG2dG7GMcxL5ruDvEyqkU5YL8zAYZ8=
=WBwZ
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/dashdec: Do not use memcpy() to copy a struct

[wm4]

On Sat, 21 Apr 2018 23:30:35 +0200
Carl Eugen Hoyos  wrote:

> 2018-04-21 23:23 GMT+02:00, wm4 :
> 
> >> No (independently of what I think of Vincent's character and tone).  
> >
> > Agreed, independently of what I think of you.
> >
> > Just by the way, some have lamented that they think of it as "doxing"  
> 
> What is "doxing"?

Something which most codes of conduct forbid.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/8] lavu: add a Vulkan hwcontext

[Rostislav Pehlivanov]

On 21 April 2018 at 21:24, Carl Eugen Hoyos  wrote:

> 2018-04-20 6:30 GMT+02:00, Rostislav Pehlivanov :
>
> > +[AV_PIX_FMT_P010]  =
> > VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16,
>
> > +[AV_PIX_FMT_YUV420P10] =
> > VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_420_UNORM_3PACK16,
>
> I don't think both can be correct (unless "PACK16" has no meaning).
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

They're both correct and work.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/dashdec: Do not use memcpy() to copy a struct

[Carl Eugen Hoyos]

2018-04-21 23:23 GMT+02:00, wm4 :

>> No (independently of what I think of Vincent's character and tone).
>
> Agreed, independently of what I think of you.
>
> Just by the way, some have lamented that they think of it as "doxing"

What is "doxing"?

> when you post my real name on this list. Do you think this is acceptable
> behavior? Don't worry, my real name has been on my github profile for
> years (and before that on the mplayer2 website), in both cases visible
> to anyone, so you don't have to fear that your childish attempts to
> achieve whatever have any effect.

Yes, other developers told me they found your name on github.
I believe my attempts to produce readable sentences works at least
sometimes, so I mostly achieve the effect I want.

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

Re: [FFmpeg-devel] [PATCH]lavf/dashdec: Do not use memcpy() to copy a struct

[wm4]

On Sat, 21 Apr 2018 22:55:33 +0200
Carl Eugen Hoyos  wrote:

> 2018-04-19 4:45 GMT+02:00, Steven Liu :
> >
> >  
> >> On 19 Apr 2018, at 03:20, wm4  wrote:
> >>
> >> On Wed, 18 Apr 2018 16:10:26 -0300
> >> James Almer  wrote:
> >>  
> >>> On 4/18/2018 2:45 PM, Carl Eugen Hoyos wrote:  
>  Hi!
> 
>  Attached patch is supposed to fix a warning (and a bug), is this the
>  right and preferred fix?
> 
>  Please comment, Carl Eugen
> 
> 
>  0001-lavf-dashdec-Do-not-use-memcpy-to-copy-a-struct.patch
> 
> 
>  From cf7d2aefc1a3b3a2e9f578ede43906ed6ee96bfd Mon Sep 17 00:00:00 2001
>  From: Carl Eugen Hoyos 
>  Date: Wed, 18 Apr 2018 19:42:57 +0200
>  Subject: [PATCH] lavf/dashdec: Do not use memcpy() to copy a struct.
> 
>  Fixes a warning:
>  libavformat/dashdec.c:1900:65: warning: argument to 'sizeof' in 'memcpy'
>  call is the same pointer type 'struct fragment *' as the destination;
>  expected 'struct fragment' or an explicit length
>  ---
>  libavformat/dashdec.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
>  diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
>  index 6304ad9..917fb54 100644
>  --- a/libavformat/dashdec.c
>  +++ b/libavformat/dashdec.c
>  @@ -1897,7 +1897,7 @@ static int init_section_compare_audio(DASHContext
>  *c)
> 
>  static void copy_init_section(struct representation *rep_dest, struct
>  representation *rep_src)
>  {
>  -memcpy(rep_dest->init_section, rep_src->init_section,
>  sizeof(rep_src->init_section));
>  +rep_dest->init_section = rep_src->init_section;  
> >>>
> >>> This would only copy the pointer. The fact memcpy was used here makes me
> >>> think the intention was to copy the contents of the struct, so something
> >>> like
> >>>
> >>> *rep_dest->init_section = *rep_src->init_section;
> >>>
> >>> or
> >>>
> >>> memcpy(rep_dest->init_section, rep_src->init_section,
> >>> sizeof(*rep_src->init_section));
> >>>
> >>> Would be the correct fix.  
> >>
> >> The first version would be preferable. But I think the original code
> >> makes no sense and was never really tested. Looking slightly closer at
> >> the code, init_section points to a struct that contains a further
> >> pointer, which would require allocating and dup'ing the memory.
> >>
> >> Also the rep_dest->init_sec_buf allocation call isn't even checked. It
> >> just memcpy's to a NULL pointer. This is some seriously shit code, and
> >> all of dashdec.c is shit. I'd like to ask Steven Liu (who
> >> reviewed/pushed the patch that added this copy_init_section code) to
> >> _actually_ review the patches and to keep up the quality standards in
> >> this project (which are slightly higher than this).  
> > Yes, that is my mistake, patch welcome and welcome you to contribute code
> > for refine the dashdec  

The problem was that you didn't actually review the patch. There's
really no excuse for the code that has been added. It's not even valid
C. It's sort of your responsibility to make sure this doesn't happen.
Sorry if my words were a bit too direct, but for very new code dashdec
has a bit too many issues than it should have. Reviewing means more
than just replying "LGTM" and pushing a patch.

> No (independently of what I think of Vincent's character and tone).

Agreed, independently of what I think of you.

Just by the way, some have lamented that they think of it as "doxing"
when you post my real name on this list. Do you think this is acceptable
behavior? Don't worry, my real name has been on my github profile for
years (and before that on the mplayer2 website), in both cases visible
to anyone, so you don't have to fear that your childish attempts to
achieve whatever have any effect.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/dashdec: Do not use memcpy() to copy a struct

[Carl Eugen Hoyos]

2018-04-18 22:00 GMT+02:00, wm4 :
> On Wed, 18 Apr 2018 21:52:45 +0200
> Carl Eugen Hoyos  wrote:
>
>> From cf7d2aefc1a3b3a2e9f578ede43906ed6ee96bfd Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Wed, 18 Apr 2018 19:42:57 +0200
>> Subject: [PATCH] lavf/dashdec: Do not use memcpy() to copy a struct.
>>
>> Fixes a warning:
>> libavformat/dashdec.c:1900:65: warning: argument to 'sizeof' in 'memcpy'
>> call is the same pointer type 'struct fragment *' as the destination;
>> expected 'struct fragment' or an explicit length
>> ---
>>  libavformat/dashdec.c |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
>> index 6304ad9..917fb54 100644
>> --- a/libavformat/dashdec.c
>> +++ b/libavformat/dashdec.c
>> @@ -1897,7 +1897,7 @@ static int init_section_compare_audio(DASHContext
>> *c)
>>
>>  static void copy_init_section(struct representation *rep_dest, struct
>> representation *rep_src)
>>  {
>> -memcpy(rep_dest->init_section, rep_src->init_section,
>> sizeof(rep_src->init_section));
>> +*rep_dest->init_section = *rep_src->init_section;
>>  rep_dest->init_sec_buf = av_mallocz(rep_src->init_sec_buf_size);
>>  memcpy(rep_dest->init_sec_buf, rep_src->init_sec_buf,
>> rep_src->init_sec_data_len);
>>  rep_dest->init_sec_buf_size = rep_src->init_sec_buf_size;
>
> Probably not complete, because it doesn't copy the url field.

I don't disagree but failed to test my attached approach.

Patch applied, Carl Eugen
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 6304ad9..c1b3131 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -1895,14 +1895,27 @@ static int init_section_compare_audio(DASHContext *c)
 return 1;
 }
 
-static void copy_init_section(struct representation *rep_dest, struct 
representation *rep_src)
+static int copy_init_section(struct representation *rep_dest, struct 
representation *rep_src)
 {
+void *buf, *buf2;
+buf  = av_mallocz(rep_src->init_section->size);
+if (!buf)
+return AVERROR(ENOMEM);
+buf2 = av_mallocz(rep_src->init_sec_buf_size);
+if (!buf2) {
+av_free(buf);
+return AVERROR(ENOMEM);
+}
 *rep_dest->init_section = *rep_src->init_section;
+rep_dest->init_section->url = buf;
+memcpy(rep_dest->init_section->url, rep_src->init_section->url, 
rep_src->init_section->size);
-rep_dest->init_sec_buf = av_mallocz(rep_src->init_sec_buf_size);
+rep_dest->init_sec_buf = buf2;
 memcpy(rep_dest->init_sec_buf, rep_src->init_sec_buf, 
rep_src->init_sec_data_len);
 rep_dest->init_sec_buf_size = rep_src->init_sec_buf_size;
 rep_dest->init_sec_data_len = rep_src->init_sec_data_len;
 rep_dest->cur_timestamp = rep_src->cur_timestamp;
+
+return 0;
 }
 
 
@@ -1942,7 +1955,9 @@ static int dash_read_header(AVFormatContext *s)
 for (i = 0; i < c->n_videos; i++) {
 struct representation *cur_video = c->videos[i];
 if (i > 0 && c->is_init_section_common_video) {
-copy_init_section(cur_video,c->videos[0]);
+ret = copy_init_section(cur_video,c->videos[0]);
+if (ret < 0)
+return ret;
 }
 ret = open_demux_for_component(s, cur_video);
 
@@ -1959,7 +1974,9 @@ static int dash_read_header(AVFormatContext *s)
 for (i = 0; i < c->n_audios; i++) {
 struct representation *cur_audio = c->audios[i];
 if (i > 0 && c->is_init_section_common_audio) {
-copy_init_section(cur_audio,c->audios[0]);
+ret = copy_init_section(cur_audio,c->audios[0]);
+if (ret < 0)
+return ret;
 }
 ret = open_demux_for_component(s, cur_audio);
 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/dashdec: Do not use memcpy() to copy a struct

[Carl Eugen Hoyos]

2018-04-19 4:45 GMT+02:00, Steven Liu :
>
>
>> On 19 Apr 2018, at 03:20, wm4  wrote:
>>
>> On Wed, 18 Apr 2018 16:10:26 -0300
>> James Almer  wrote:
>>
>>> On 4/18/2018 2:45 PM, Carl Eugen Hoyos wrote:
 Hi!

 Attached patch is supposed to fix a warning (and a bug), is this the
 right and preferred fix?

 Please comment, Carl Eugen


 0001-lavf-dashdec-Do-not-use-memcpy-to-copy-a-struct.patch


 From cf7d2aefc1a3b3a2e9f578ede43906ed6ee96bfd Mon Sep 17 00:00:00 2001
 From: Carl Eugen Hoyos 
 Date: Wed, 18 Apr 2018 19:42:57 +0200
 Subject: [PATCH] lavf/dashdec: Do not use memcpy() to copy a struct.

 Fixes a warning:
 libavformat/dashdec.c:1900:65: warning: argument to 'sizeof' in 'memcpy'
 call is the same pointer type 'struct fragment *' as the destination;
 expected 'struct fragment' or an explicit length
 ---
 libavformat/dashdec.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
 index 6304ad9..917fb54 100644
 --- a/libavformat/dashdec.c
 +++ b/libavformat/dashdec.c
 @@ -1897,7 +1897,7 @@ static int init_section_compare_audio(DASHContext
 *c)

 static void copy_init_section(struct representation *rep_dest, struct
 representation *rep_src)
 {
 -memcpy(rep_dest->init_section, rep_src->init_section,
 sizeof(rep_src->init_section));
 +rep_dest->init_section = rep_src->init_section;
>>>
>>> This would only copy the pointer. The fact memcpy was used here makes me
>>> think the intention was to copy the contents of the struct, so something
>>> like
>>>
>>> *rep_dest->init_section = *rep_src->init_section;
>>>
>>> or
>>>
>>> memcpy(rep_dest->init_section, rep_src->init_section,
>>> sizeof(*rep_src->init_section));
>>>
>>> Would be the correct fix.
>>
>> The first version would be preferable. But I think the original code
>> makes no sense and was never really tested. Looking slightly closer at
>> the code, init_section points to a struct that contains a further
>> pointer, which would require allocating and dup'ing the memory.
>>
>> Also the rep_dest->init_sec_buf allocation call isn't even checked. It
>> just memcpy's to a NULL pointer. This is some seriously shit code, and
>> all of dashdec.c is shit. I'd like to ask Steven Liu (who
>> reviewed/pushed the patch that added this copy_init_section code) to
>> _actually_ review the patches and to keep up the quality standards in
>> this project (which are slightly higher than this).
> Yes, that is my mistake, patch welcome and welcome you to contribute code
> for refine the dashdec

No (independently of what I think of Vincent's character and tone).

You have to either fix the most obvious issues or revert the patch.

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

Re: [FFmpeg-devel] [PATCH] avcodec/allcodecs: add FFMPEG_PREFER_* env vars

[Carl Eugen Hoyos]

2018-04-19 12:15 GMT+02:00, Martin Dørum :
> Anotehr point is that some applications make assumptions about the
> pix_fmt the decoder they get from `avcodec_find_decoder` uses.

(Unrelated to your patch afaict)
This assumption is invalid, FFmpeg has changed pix_fmt (and
sample_fmt, the same is true for audio) for decoders before
and may change it again in the future.
(Iirc, it was changed without any version bump in the past.)

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

[FFmpeg-devel] [PATCH]configure: Assume MSVCRT when compiling with MingW

[Carl Eugen Hoyos]

Hi!

Attached patch is supposed to fix an old issue with debug messages and
a currently reported compilation warning that I believe also indicates
a possible abort() on Windows:
libavformat/hlsenc.c:1676:63: warning: unknown conversion type
character 's' in format
Patch untested.

Please review, Carl Eugen
From 7a1ceb3c66c477edf83a29845efe42a52452b98f Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 21 Apr 2018 22:37:02 +0200
Subject: [PATCH] configure: Assume MSVCRT when compiling with MingW.

Should fix several issues with format conversions unsupported on Windows
and a compilation warning:
libavformat/hlsenc.c:1676:63: warning: unknown conversion type character 's' in format
---
 configure |2 ++
 1 file changed, 2 insertions(+)

diff --git a/configure b/configure
index dee507c..ab2f490 100755
--- a/configure
+++ b/configure
@@ -5304,6 +5304,7 @@ probe_libc(){
 add_${pfx}cppflags -D__printf__=__gnu_printf__
 test_${pfx}cpp_condition windows.h "!defined(_WIN32_WINNT) || _WIN32_WINNT < 0x0600" &&
 add_${pfx}cppflags -D_WIN32_WINNT=0x0600
+eval ${pfx}libc_type=msvcrt
 elif test_${pfx}cpp_condition _mingw.h "defined __MINGW_VERSION"  ||
  test_${pfx}cpp_condition _mingw.h "defined __MINGW32_VERSION"; then
 eval ${pfx}libc_type=mingw32
@@ -5317,6 +5318,7 @@ probe_libc(){
 add_${pfx}cppflags -D_WIN32_WINNT=0x0600
 eval test \$${pfx_no_}cc_type = "gcc" &&
 add_${pfx}cppflags -D__printf__=__gnu_printf__
+eval ${pfx}libc_type=msvcrt
 elif test_${pfx}cpp_condition crtversion.h "defined _VC_CRT_MAJOR_VERSION"; then
 eval ${pfx}libc_type=msvcrt
 if test_${pfx}cpp_condition crtversion.h "_VC_CRT_MAJOR_VERSION < 14"; then
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH 3/8] lavu: add a Vulkan hwcontext

[Carl Eugen Hoyos]

2018-04-20 6:30 GMT+02:00, Rostislav Pehlivanov :

> +[AV_PIX_FMT_P010]  =
> VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16,

> +[AV_PIX_FMT_YUV420P10] =
> VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_420_UNORM_3PACK16,

I don't think both can be correct (unless "PACK16" has no meaning).

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

[FFmpeg-devel] [PATCH] avcodec/ffv1enc: Check that the crc + version combination is supported

[Michael Niedermayer]

The crc flag is only stored since version 3 thus before this crcs do not
work. We increase the version as needed same as we do with pix_fmts

Signed-off-by: Michael Niedermayer 
---
 libavcodec/ffv1enc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index dd4d7429f5..23e8d3dfa4 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -539,6 +539,10 @@ static av_cold int encode_init(AVCodecContext *avctx)
 s->ec = (s->version >= 3);
 }
 
+// CRC requires version 3+
+if (s->ec)
+s->version = FFMAX(s->version, 3);
+
 if ((s->version == 2 || s->version>3) && avctx->strict_std_compliance > 
FF_COMPLIANCE_EXPERIMENTAL) {
 av_log(avctx, AV_LOG_ERROR, "Version 2 needed for requested features 
but version 2 is experimental and not enabled\n");
 return AVERROR_INVALIDDATA;
-- 
2.17.0

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

Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[Carl Eugen Hoyos]

2018-04-21 21:59 GMT+02:00, Thomas Volkert :
> On 21.04.2018 21:46, Carl Eugen Hoyos wrote:
>
>> 2018-04-21 21:37 GMT+02:00, Hendrik Leppkes :

>>> Can you elaborate what you think the problem is?
>> Given that we allow muxing against gpl and Apache, I believe
>> the patch can be improved.
>
> Okay, what do you suggest  in detail?

I believe the easiest solution is to "require version 3"
as we do for other Apache libraries (libvmaf and
libopencore).

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

Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[Thomas Volkert]

On 21.04.2018 21:46, Carl Eugen Hoyos wrote:

> 2018-04-21 21:37 GMT+02:00, Hendrik Leppkes :
>> On Sat, Apr 21, 2018 at 6:18 PM, Carl Eugen Hoyos 
>> wrote:
>>> 2018-04-21 16:01 GMT+02:00, Thomas Volkert :
>>>
 +++ b/Changelog
 @@ -3,6 +3,7 @@ releases are sorted from youngest to oldest.

  version :
  - deblock filter
 +- support mbedTLS based TLS
>>> From a quick look, I believe this library is not license-compatible,
>>> please solve this before committing.
>>>
>> mbedTLS is available both under Apache 2.0 and GPL 2.0 -

Confirmed.

>> and the patch even adds it as nonfree only.
> I missed the nonfree part of the patch (and it surprises me now).

Yes, the patch is quite restrictive related to the license.

>> Can you elaborate what you think the problem is?
> Given that we allow muxing against gpl and Apache, I believe
> the patch can be improved.

Okay, what do you suggest  in detail?

Best regards,
Thomas.

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

Re: [FFmpeg-devel] [PATCH 2/2] vaapi_encode_h265: Insert mastering display colour colume if needed

[Mark Thompson]

On 20/04/18 08:27, Haihao Xiang wrote:
> '-sei xxx' is added to control SEI insertion, so far only mastering
> display colour colume is available for testing. Another patch is
> required to change mastering display settings later.
> 
> Signed-off-by: Haihao Xiang 
> ---
>  libavcodec/vaapi_encode_h265.c | 94 
> +-
>  1 file changed, 93 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
> index 5203c6871d..a8cb6a6d8b 100644
> --- a/libavcodec/vaapi_encode_h265.c
> +++ b/libavcodec/vaapi_encode_h265.c
> @@ -29,10 +29,14 @@
>  #include "cbs.h"
>  #include "cbs_h265.h"
>  #include "hevc.h"
> +#include "hevc_sei.h"
>  #include "internal.h"
>  #include "put_bits.h"
>  #include "vaapi_encode.h"
>  
> +enum {
> +SEI_MASTERING_DISPLAY   = 0x01,

Since the options are essentially the same I think it would be nice if these 
values matched the H.264 ones?  (That is, make this value 8.)

Should this be mastering display specifically, or would it be better for this 
option to be called something like "HDR metadata" (just "hdr" as the option 
name?) which also includes content light level?  (Compare the -sei timing 
option on H.264, which gives you both buffering period and picture timing SEI.)

> +};
>  
>  typedef struct VAAPIEncodeH265Context {
>  unsigned int ctu_width;
> @@ -47,6 +51,9 @@ typedef struct VAAPIEncodeH265Context {
>  H265RawSPS sps;
>  H265RawPPS pps;
>  H265RawSlice slice;
> +H265RawSEI sei;
> +
> +H265RawSEIMasteringDiplayColorVolume mastering_display;
>  
>  int64_t last_idr_frame;
>  int pic_order_cnt;
> @@ -58,6 +65,7 @@ typedef struct VAAPIEncodeH265Context {
>  CodedBitstreamContext *cbc;
>  CodedBitstreamFragment current_access_unit;
>  int aud_needed;
> +int sei_needed;
>  } VAAPIEncodeH265Context;
>  
>  typedef struct VAAPIEncodeH265Options {
> @@ -65,6 +73,7 @@ typedef struct VAAPIEncodeH265Options {
>  int aud;
>  int profile;
>  int level;
> +int sei;
>  } VAAPIEncodeH265Options;
>  
>  
> @@ -175,6 +184,61 @@ fail:
>  return err;
>  }
>  
> +static int vaapi_encode_h265_write_extra_header(AVCodecContext *avctx,
> +VAAPIEncodePicture *pic,
> +int index, int *type,
> +char *data, size_t *data_len)
> +{
> +VAAPIEncodeContext  *ctx = avctx->priv_data;
> +VAAPIEncodeH265Context *priv = ctx->priv_data;
> +VAAPIEncodeH265Options  *opt = ctx->codec_options;
> +CodedBitstreamFragment   *au = >current_access_unit;
> +int err, i;
> +
> +if (priv->sei_needed) {
> +if (priv->aud_needed) {
> +err = vaapi_encode_h265_add_nal(avctx, au, >aud);
> +if (err < 0)
> +goto fail;
> +priv->aud_needed = 0;
> +}
> +
> +memset(>sei, 0, sizeof(priv->sei));
> +priv->sei.nal_unit_header.nal_unit_type = HEVC_NAL_SEI_PREFIX;
> +priv->sei.nal_unit_header.nuh_temporal_id_plus1 = 1;

Might look nicer as a compound literal?

> +i = 0;
> +
> +if (opt->sei & SEI_MASTERING_DISPLAY && pic->type == 
> PICTURE_TYPE_IDR) {
> +priv->sei.payload[i].payload_type = 
> HEVC_SEI_TYPE_MASTERING_DISPLAY_INFO;
> +priv->sei.payload[i].payload.mastering_display = 
> priv->mastering_display;
> +++i;
> +}
> +
> +priv->sei.payload_count = i;
> +av_assert0(priv->sei.payload_count > 0);
> +
> +err = vaapi_encode_h265_add_nal(avctx, au, >sei);
> +if (err < 0)
> +goto fail;
> +priv->sei_needed = 0;
> +
> +err = vaapi_encode_h265_write_access_unit(avctx, data, data_len, au);
> +if (err < 0)
> +goto fail;
> +
> +ff_cbs_fragment_uninit(priv->cbc, au);
> +
> +*type = VAEncPackedHeaderRawData;
> +return 0;
> +} else {
> +return AVERROR_EOF;
> +}
> +
> +fail:
> +ff_cbs_fragment_uninit(priv->cbc, au);
> +return err;
> +}
> +
>  static int vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
>  {
>  VAAPIEncodeContext*ctx = avctx->priv_data;
> @@ -587,6 +651,23 @@ static int 
> vaapi_encode_h265_init_picture_params(AVCodecContext *avctx,
>  priv->aud_needed = 0;
>  }
>  
> +if ((opt->sei & SEI_MASTERING_DISPLAY) &&
> +(pic->type == PICTURE_TYPE_I || pic->type == PICTURE_TYPE_IDR)) {
> +// hard-coded value for testing, change it later
> +for (i = 0; i < 3; i++) {
> +priv->mastering_display.display_primaries[i].x = 5;
> +priv->mastering_display.display_primaries[i].y = 5;
> +}
> +
> +priv->mastering_display.white_point_x = 5;
> +priv->mastering_display.white_point_y = 5;
> +
> +

[FFmpeg-devel] [PATCH] lavu/threadmessage: add av_thread_message_queue_nelem()

[Clément Bœsch]

---
Been away from FFmpeg for way too long. Hope this patch get me back on
track. Feel free to nitpick on the name.
---
 doc/APIchanges | 3 +++
 libavutil/threadmessage.c  | 9 +
 libavutil/threadmessage.h  | 5 +
 libavutil/version.h| 2 +-
 tests/api/api-threadmessage-test.c | 4 +++-
 5 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 4f6ac2a031..393491c8e9 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2018-04-xx - xx - lavu 56.16.100 - threadmessage.h
+  Add av_thread_message_queue_nelem().
+
  8< - FFmpeg 4.0 was cut here  8< -
 
 2018-04-03 - d6fc031caf - lavu 56.13.100 - pixdesc.h
diff --git a/libavutil/threadmessage.c b/libavutil/threadmessage.c
index 872e9392b1..fed398926a 100644
--- a/libavutil/threadmessage.c
+++ b/libavutil/threadmessage.c
@@ -102,6 +102,15 @@ void av_thread_message_queue_free(AVThreadMessageQueue 
**mq)
 #endif
 }
 
+int av_thread_message_queue_nelem(AVThreadMessageQueue *mq)
+{
+int ret;
+pthread_mutex_lock(>lock);
+ret = av_fifo_size(mq->fifo);
+pthread_mutex_unlock(>lock);
+return ret / mq->elsize;
+}
+
 #if HAVE_THREADS
 
 static int av_thread_message_queue_send_locked(AVThreadMessageQueue *mq,
diff --git a/libavutil/threadmessage.h b/libavutil/threadmessage.h
index 8480a0a3db..e41d95ccf7 100644
--- a/libavutil/threadmessage.h
+++ b/libavutil/threadmessage.h
@@ -95,6 +95,11 @@ void 
av_thread_message_queue_set_err_recv(AVThreadMessageQueue *mq,
 void av_thread_message_queue_set_free_func(AVThreadMessageQueue *mq,
void (*free_func)(void *msg));
 
+/**
+ * Return the current number of messages in the queue.
+ */
+int av_thread_message_queue_nelem(AVThreadMessageQueue *mq);
+
 /**
  * Flush the message queue
  *
diff --git a/libavutil/version.h b/libavutil/version.h
index 387421775f..23567000a3 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  56
-#define LIBAVUTIL_VERSION_MINOR  15
+#define LIBAVUTIL_VERSION_MINOR  16
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
diff --git a/tests/api/api-threadmessage-test.c 
b/tests/api/api-threadmessage-test.c
index 05a8062b8c..494808f176 100644
--- a/tests/api/api-threadmessage-test.c
+++ b/tests/api/api-threadmessage-test.c
@@ -130,7 +130,9 @@ static void *receiver_thread(void *arg)
 
 for (i = 0; i < rd->workload; i++) {
 if (rand() % rd->workload < rd->workload / 10) {
-av_log(NULL, AV_LOG_INFO, "receiver #%d: flushing the queue\n", 
rd->id);
+av_log(NULL, AV_LOG_INFO, "receiver #%d: flushing the queue, "
+   "discarding %d message(s)\n", rd->id,
+   av_thread_message_queue_nelem(rd->queue));
 av_thread_message_flush(rd->queue);
 } else {
 struct message msg;
-- 
2.17.0

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

Re: [FFmpeg-devel] [PATCH] avcodec/vc1_pred: properly clip interlaced motion vectors

[Carl Eugen Hoyos]

2018-04-21 21:05 GMT+02:00, Jerome Borsboom :
>> Fixes #2557.
>>
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavcodec/vc1_pred.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/vc1_pred.c b/libavcodec/vc1_pred.c
>> index 54712f6b7a..9f42a930fe 100644
>> --- a/libavcodec/vc1_pred.c
>> +++ b/libavcodec/vc1_pred.c
>> @@ -98,9 +98,9 @@ static av_always_inline int scaleforsame_y(VC1Context
>> *v, int i, int n /* MV */,
>>  }
>>
>>  if (v->cur_field_type && !v->ref_field_type[dir])
>> -return av_clip(scaledvalue, -v->range_y / 2 + 1, v->range_y / 2);
>> +return av_clip(scaledvalue, -v->range_y / 2 - 1, v->range_y / 2);
>>  else
>> -return av_clip(scaledvalue, -v->range_y / 2, v->range_y / 2 - 1);
>> +return av_clip(scaledvalue, -v->range_y / 2, v->range_y / 2 + 1);
>>  }
>>
>>  static av_always_inline int scaleforopp_x(VC1Context *v, int n /* MV */)
>> --
>> 2.11.0
>
> scaleforsame_y references ref_field_type. Therefore, it needs to be set
> before scaleforsame is called.

Please mention ticket #2557 in the commit message.

> Signed-off-by: Jerome Borsboom 
> ---
> I am not sure your patch is correct. The existing implementation agrees with
> VC-1 spec.
> See Figure 119 in 10.3.5.4.3.4.2 in particular. Please have a look if the
> patch below solves
> the issue. ref_field_type is referenced in scaleforsame_y and needs to be
> set earlier in
> ff_vc1_pred_mv to have the desired effect.

This patch also fixes the issue for the given sample

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

Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[Carl Eugen Hoyos]

2018-04-21 21:37 GMT+02:00, Hendrik Leppkes :
> On Sat, Apr 21, 2018 at 6:18 PM, Carl Eugen Hoyos 
> wrote:
>> 2018-04-21 16:01 GMT+02:00, Thomas Volkert :
>>
>>> +++ b/Changelog
>>> @@ -3,6 +3,7 @@ releases are sorted from youngest to oldest.
>>>
>>>  version :
>>>  - deblock filter
>>> +- support mbedTLS based TLS
>>
>> From a quick look, I believe this library is not license-compatible,
>> please solve this before committing.
>>
>
> mbedTLS is available both under Apache 2.0 and GPL 2.0 -
> and the patch even adds it as nonfree only.

I missed the nonfree part of the patch (and it surprises me now).

> Can you elaborate what you think the problem is?

Given that we allow muxing against gpl and Apache, I believe
the patch can be improved.

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

Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[Hendrik Leppkes]

On Sat, Apr 21, 2018 at 6:18 PM, Carl Eugen Hoyos  wrote:
> 2018-04-21 16:01 GMT+02:00, Thomas Volkert :
>
>> +++ b/Changelog
>> @@ -3,6 +3,7 @@ releases are sorted from youngest to oldest.
>>
>>  version :
>>  - deblock filter
>> +- support mbedTLS based TLS
>
> From a quick look, I believe this library is not license-compatible,
> please solve this before committing.
>

mbedTLS is available both under Apache 2.0 and GPL 2.0 - and the patch
even adds it as nonfree only. Can you elaborate what you think the
problem is?

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

Re: [FFmpeg-devel] [PATCH 1/2] cbs_h265: read/write HEVC PREFIX SEI

[Mark Thompson]

On 20/04/18 08:27, Haihao Xiang wrote:
> Similar to cbs_h264, cbs_h265_{read, write}_nal_unit() can handle HEVC
> prefix SEI NAL units now. Currently mastering display colour volume SEI
> message is added only, we may add more SEI message if needed later
> 
> Signed-off-by: Haihao Xiang 
> ---
>  libavcodec/cbs_h2645.c|  43 ++
>  libavcodec/cbs_h265.h |  38 +
>  libavcodec/cbs_h265_syntax_template.c | 150 
> ++
>  3 files changed, 231 insertions(+)
> 
> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> index 5585831cf6..6fc5832966 100644
> --- a/libavcodec/cbs_h2645.c
> +++ b/libavcodec/cbs_h2645.c
> @@ -29,6 +29,7 @@
>  #include "h264_sei.h"
>  #include "h2645_parse.h"
>  #include "hevc.h"
> +#include "hevc_sei.h"
>  
>  
>  static int cbs_read_ue_golomb(CodedBitstreamContext *ctx, GetBitContext *gbc,
> @@ -465,6 +466,26 @@ static void cbs_h265_free_slice(void *unit, uint8_t 
> *content)
>  av_freep();
>  }
>  
> +static void cbs_h265_free_sei_payload(H265RawSEIPayload *payload)
> +{
> +switch (payload->payload_type) {
> +case HEVC_SEI_TYPE_MASTERING_DISPLAY_INFO:
> +break;
> +default:
> +av_buffer_unref(>payload.other.data_ref);
> +break;
> +}
> +}
> +
> +static void cbs_h265_free_sei(void *unit, uint8_t *content)
> +{
> +H265RawSEI *sei = (H265RawSEI*)content;
> +int i;
> +for (i = 0; i < sei->payload_count; i++)
> +cbs_h265_free_sei_payload(>payload[i]);
> +av_freep();
> +}
> +
>  static int cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
> CodedBitstreamFragment *frag,
> const H2645Packet *packet)
> @@ -972,6 +993,20 @@ static int cbs_h265_read_nal_unit(CodedBitstreamContext 
> *ctx,
>  }
>  break;
>  
> +case HEVC_NAL_SEI_PREFIX:

I don't think it would be too hard to handling SEI_SUFFIX here too?  (The 
different set of valid payloads doesn't matter when we aren't checking that 
below.)

> +err = ff_cbs_alloc_unit_content(ctx, unit, sizeof(H265RawSEI),
> +_h265_free_sei);
> +
> +if (err < 0)
> +return err;
> +
> +err = cbs_h265_read_sei(ctx, , unit->content);
> +
> +if (err < 0)
> +return err;
> +
> +break;
> +
>  default:
>  return AVERROR(ENOSYS);
>  }
> @@ -1212,6 +1247,14 @@ static int 
> cbs_h265_write_nal_unit(CodedBitstreamContext *ctx,
>  }
>  break;
>  
> +case HEVC_NAL_SEI_PREFIX:
> +err = cbs_h265_write_sei(ctx, pbc, unit->content);
> +
> +if (err < 0)
> +return err;
> +
> +break;
> +

Please make these cases match the styling of the others.

>  default:
>  av_log(ctx->log_ctx, AV_LOG_ERROR, "Write unimplemented for "
> "NAL unit type %"PRIu32".\n", unit->type);
> diff --git a/libavcodec/cbs_h265.h b/libavcodec/cbs_h265.h
> index 33e71fc234..e37c1b8d94 100644
> --- a/libavcodec/cbs_h265.h
> +++ b/libavcodec/cbs_h265.h
> @@ -25,6 +25,14 @@
>  #include "cbs_h2645.h"
>  #include "hevc.h"
>  
> +enum {
> +// This limit is arbitrary - it is sufficient for one message of each
> +// type plus some repeats, and will therefore easily cover all sane
> +// streams.  However, it is possible to make technically-valid streams
> +// for which it will fail (for example, by including a large number of
> +// user-data-unregistered messages).
> +H265_MAX_SEI_PAYLOADS = 64,
> +};
>  
>  typedef struct H265RawNALUnitHeader {
>  uint8_t forbidden_zero_bit;
> @@ -516,6 +524,36 @@ typedef struct H265RawSlice {
>  AVBufferRef *data_ref;
>  } H265RawSlice;
>  
> +typedef struct H265RawSEIMasteringDiplayColorVolume {

The H.265 standard uses English spelling of colour, not USAian.

> +struct {
> +uint16_t x;
> +uint16_t y;
> +} display_primaries[3];

Make it two arrays, display_primaries_x and display_primaries_y, so that it 
matches the standard.

> +uint16_t white_point_x;
> +uint16_t white_point_y;
> +uint32_t max_display_mastering_luminance;
> +uint32_t min_display_mastering_luminance;
> +} H265RawSEIMasteringDiplayColorVolume;
> +
> +typedef struct H265RawSEIPayload {
> +uint32_t payload_type;
> +uint32_t payload_size;
> +union {
> +H265RawSEIMasteringDiplayColorVolume mastering_display;
> +struct {
> +uint8_t *data;
> +size_t data_length;
> +AVBufferRef *data_ref;
> +} other;
> +} payload;
> +} H265RawSEIPayload;
> +
> +typedef struct H265RawSEI {
> +H265RawNALUnitHeader nal_unit_header;
> +
> +H265RawSEIPayload payload[H265_MAX_SEI_PAYLOADS];
> +uint8_t payload_count;
> +} H265RawSEI;
>  
>  typedef struct CodedBitstreamH265Context {
>  // Reader/writer 

Re: [FFmpeg-devel] [PATCH v2 1/2] lavf: make overlay_qsv work based on framesync

[Mark Thompson]

On 03/04/18 02:50, Ruiling Song wrote:
> The existing version which was cherry-picked from Libav does not work
> with FFmpeg framework, because ff_request_frame() was totally
> different between Libav (recursive) and FFmpeg (non-recursive).
> The existing overlay_qsv implementation depends on the recursive version
> of ff_request_frame to trigger immediate call to request_frame() on input pad.
> But this has been removed in FFmpeg since "lavfi: make request_frame() 
> non-recursive."
> Now that we have handy framesync support in FFmpeg, so I make it work
> based on framesync. Some other fixing which is also needed to make
> overlay_qsv work are put in a separate patch.
> 
> v2:
> add .preinit field to initilize framesync options.
> export more options like vf_overlay.c
> 
> Signed-off-by: Ruiling Song 
> ---
>  libavfilter/Makefile |   2 +-
>  libavfilter/vf_overlay_qsv.c | 213 
> ---
>  2 files changed, 78 insertions(+), 137 deletions(-)
> 
On 03/04/18 02:50, Ruiling Song wrote:
> For filters based on framesync, the input frame was managed
> by framesync, so we should not directly keep and destroy it,
> instead we make a clone of it here, or else double-free will occur.
> But for other filters not based on framesync, we still need to
> free the input frame inside filter_frame. That's why I made
> this v2 to fix the side-effect on normal filters.
> 
> v2:
> and one av_frame_free() in vf_vpp_qsv.c
> 
> Signed-off-by: Ruiling Song 
> ---
>  libavfilter/qsvvpp.c | 4 ++--
>  libavfilter/vf_vpp_qsv.c | 5 -
>  2 files changed, 6 insertions(+), 3 deletions(-)

Tested, LGTM, set applied with one minor merge fixup - it collided with the 
change to pass through unmodified frames directly.  (Apologies for the delay!)

Shall I apply this to the 4.0 branch as well?

Thanks,

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

Re: [FFmpeg-devel] [PATCH] avcodec/vc1_pred: properly clip interlaced motion vectors

[Jerome Borsboom]

> Fixes #2557.
> 
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/vc1_pred.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/vc1_pred.c b/libavcodec/vc1_pred.c
> index 54712f6b7a..9f42a930fe 100644
> --- a/libavcodec/vc1_pred.c
> +++ b/libavcodec/vc1_pred.c
> @@ -98,9 +98,9 @@ static av_always_inline int scaleforsame_y(VC1Context *v, 
> int i, int n /* MV */,
>  }
>  
>  if (v->cur_field_type && !v->ref_field_type[dir])
> -return av_clip(scaledvalue, -v->range_y / 2 + 1, v->range_y / 2);
> +return av_clip(scaledvalue, -v->range_y / 2 - 1, v->range_y / 2);
>  else
> -return av_clip(scaledvalue, -v->range_y / 2, v->range_y / 2 - 1);
> +return av_clip(scaledvalue, -v->range_y / 2, v->range_y / 2 + 1);
>  }
>  
>  static av_always_inline int scaleforopp_x(VC1Context *v, int n /* MV */)
> -- 
> 2.11.0

scaleforsame_y references ref_field_type. Therefore, it needs to be set
before scaleforsame is called.

Signed-off-by: Jerome Borsboom 
---
I am not sure your patch is correct. The existing implementation agrees with 
VC-1 spec.
See Figure 119 in 10.3.5.4.3.4.2 in particular. Please have a look if the patch 
below solves
the issue. ref_field_type is referenced in scaleforsame_y and needs to be set 
earlier in
ff_vc1_pred_mv to have the desired effect.

 libavcodec/vc1_pred.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/vc1_pred.c b/libavcodec/vc1_pred.c
index 54712f6b7a..3a52a22bc6 100644
--- a/libavcodec/vc1_pred.c
+++ b/libavcodec/vc1_pred.c
@@ -341,6 +341,8 @@ void ff_vc1_pred_mv(VC1Context *v, int n, int dmv_x, int 
dmv_y,
 } else
 opposite = 0;
 if (opposite) {
+v->mv_f[dir][xy + v->blocks_off] = 1;
+v->ref_field_type[dir] = !v->cur_field_type;
 if (a_valid && !a_f) {
 field_predA[0] = scaleforopp(v, field_predA[0], 0, dir);
 field_predA[1] = scaleforopp(v, field_predA[1], 1, dir);
@@ -353,9 +355,9 @@ void ff_vc1_pred_mv(VC1Context *v, int n, int dmv_x, int 
dmv_y,
 field_predC[0] = scaleforopp(v, field_predC[0], 0, dir);
 field_predC[1] = scaleforopp(v, field_predC[1], 1, dir);
 }
-v->mv_f[dir][xy + v->blocks_off] = 1;
-v->ref_field_type[dir] = !v->cur_field_type;
 } else {
+v->mv_f[dir][xy + v->blocks_off] = 0;
+v->ref_field_type[dir] = v->cur_field_type;
 if (a_valid && a_f) {
 field_predA[0] = scaleforsame(v, n, field_predA[0], 0, dir);
 field_predA[1] = scaleforsame(v, n, field_predA[1], 1, dir);
@@ -368,8 +370,6 @@ void ff_vc1_pred_mv(VC1Context *v, int n, int dmv_x, int 
dmv_y,
 field_predC[0] = scaleforsame(v, n, field_predC[0], 0, dir);
 field_predC[1] = scaleforsame(v, n, field_predC[1], 1, dir);
 }
-v->mv_f[dir][xy + v->blocks_off] = 0;
-v->ref_field_type[dir] = v->cur_field_type;
 }
 
 if (a_valid) {
-- 
2.13.6


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

Re: [FFmpeg-devel] [PATCH] avcodec/vc1_pred: properly clip interlaced motion vectors

[Paul B Mahol]

On 4/21/18, Carl Eugen Hoyos  wrote:
> 2018-04-21 10:22 GMT+02:00, Paul B Mahol :
>> Fixes #2557.
>>
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavcodec/vc1_pred.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/vc1_pred.c b/libavcodec/vc1_pred.c
>> index 54712f6b7a..9f42a930fe 100644
>> --- a/libavcodec/vc1_pred.c
>> +++ b/libavcodec/vc1_pred.c
>> @@ -98,9 +98,9 @@ static av_always_inline int scaleforsame_y(VC1Context
>> *v,
>> int i, int n /* MV */,
>>  }
>>
>>  if (v->cur_field_type && !v->ref_field_type[dir])
>> -return av_clip(scaledvalue, -v->range_y / 2 + 1, v->range_y / 2);
>> +return av_clip(scaledvalue, -v->range_y / 2 - 1, v->range_y / 2);
>>  else
>> -return av_clip(scaledvalue, -v->range_y / 2, v->range_y / 2 - 1);
>> +return av_clip(scaledvalue, -v->range_y / 2, v->range_y / 2 + 1);
>
> Makes the affected frames bit-exact, so lgtm.

This probably needs no + 1 and - 1 part, so will commit without it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/vc1_pred: properly clip interlaced motion vectors

[Carl Eugen Hoyos]

2018-04-21 10:22 GMT+02:00, Paul B Mahol :
> Fixes #2557.
>
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/vc1_pred.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/vc1_pred.c b/libavcodec/vc1_pred.c
> index 54712f6b7a..9f42a930fe 100644
> --- a/libavcodec/vc1_pred.c
> +++ b/libavcodec/vc1_pred.c
> @@ -98,9 +98,9 @@ static av_always_inline int scaleforsame_y(VC1Context *v,
> int i, int n /* MV */,
>  }
>
>  if (v->cur_field_type && !v->ref_field_type[dir])
> -return av_clip(scaledvalue, -v->range_y / 2 + 1, v->range_y / 2);
> +return av_clip(scaledvalue, -v->range_y / 2 - 1, v->range_y / 2);
>  else
> -return av_clip(scaledvalue, -v->range_y / 2, v->range_y / 2 - 1);
> +return av_clip(scaledvalue, -v->range_y / 2, v->range_y / 2 + 1);

Makes the affected frames bit-exact, so lgtm.

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

Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[Carl Eugen Hoyos]

2018-04-21 16:01 GMT+02:00, Thomas Volkert :

> +++ b/Changelog
> @@ -3,6 +3,7 @@ releases are sorted from youngest to oldest.
>
>  version :
>  - deblock filter
> +- support mbedTLS based TLS

From a quick look, I believe this library is not license-compatible,
please solve this before committing.

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

Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[Nicolas George]

Thomas Volkert (2018-04-21):
> It needs less memory than other TLS implementations.
> This is especially interesting for embedded systems.
> (There is at least one real project which demands for this.)

Thanks. Do you know how it compares in terms of speed?

Also, did you check bearssl? It has similar goals and benefits, and I
think it is a very trustworthy project.

Anyway, I think this should be stated somewhere, because users will not
be able to decide which library is better for their needs. Not blocking
for this patch, but to keep in mind.

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] [PATCH] libavformat: add mbedTLS based TLS

[Thomas Volkert]

On 21.04.2018 16:05, Nicolas George wrote:
> Thomas Volkert (2018-04-21):
>> +- support mbedTLS based TLS
> What is the benefit?

It needs less memory than other TLS implementations.
This is especially interesting for embedded systems.
(There is at least one real project which demands for this.)

Best regards,
Thomas.

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

Re: [FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[Nicolas George]

Thomas Volkert (2018-04-21):
> +- support mbedTLS based TLS

What is the benefit?

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH] libavformat: add mbedTLS based TLS

[Thomas Volkert]

From: Thomas Volkert 

---
 Changelog |   1 +
 configure |  31 ++--
 libavformat/Makefile  |   1 +
 libavformat/rtmpdh.c  |  55 
 libavformat/rtmpdh.h  |   5 +
 libavformat/tls_mbedtls.c | 351 ++
 libavformat/version.h |   2 +-
 7 files changed, 436 insertions(+), 10 deletions(-)
 create mode 100644 libavformat/tls_mbedtls.c

diff --git a/Changelog b/Changelog
index 3ed4874..0a344f3 100644
--- a/Changelog
+++ b/Changelog
@@ -3,6 +3,7 @@ releases are sorted from youngest to oldest.
 
 version :
 - deblock filter
+- support mbedTLS based TLS
 
 
 version 4.0:
diff --git a/configure b/configure
index dee507c..4dda466 100755
--- a/configure
+++ b/configure
@@ -213,7 +213,7 @@ External library support:
   --enable-gmp enable gmp, needed for rtmp(t)e support
if openssl or librtmp is not used [no]
   --enable-gnutls  enable gnutls, needed for https support
-   if openssl or libtls is not used [no]
+   if openssl, libtls or mbedtls is not used [no]
   --disable-iconv  disable iconv [autodetect]
   --enable-jni enable JNI support [no]
   --enable-ladspa  enable LADSPA audio filtering [no]
@@ -262,7 +262,7 @@ External library support:
   --enable-libtesseractenable Tesseract, needed for ocr filter [no]
   --enable-libtheora   enable Theora encoding via libtheora [no]
   --enable-libtls  enable LibreSSL (via libtls), needed for https 
support
-   if openssl or gnutls is not used [no]
+   if openssl, gnutls or mbedtls is not used [no]
   --enable-libtwolame  enable MP2 encoding via libtwolame [no]
   --enable-libv4l2 enable libv4l2/v4l-utils [no]
   --enable-libvidstab  enable video stabilization using vid.stab [no]
@@ -290,13 +290,15 @@ External library support:
   --disable-lzma   disable lzma [autodetect]
   --enable-decklinkenable Blackmagic DeckLink I/O support [no]
   --enable-libndi_newtek   enable Newteck NDI I/O support [no]
+  --enable-mbedtls enable mbedTLS, needed for https support
+   if openssl, gnutls or libtls is not used [no]
   --enable-mediacodec  enable Android MediaCodec support [no]
   --enable-libmysofa   enable libmysofa, needed for sofalizer filter [no]
   --enable-openal  enable OpenAL 1.1 capture support [no]
   --enable-opencl  enable OpenCL processing [no]
   --enable-opengl  enable OpenGL rendering [no]
   --enable-openssl enable openssl, needed for https support
-   if gnutls or libtls is not used [no]
+   if gnutls, libtls or mbedtls is not used [no]
   --disable-sndio  disable sndio support [autodetect]
   --disable-schannel   disable SChannel SSP, needed for TLS support on
Windows if openssl and gnutls are not used 
[autodetect]
@@ -1646,6 +1648,7 @@ EXTERNAL_LIBRARY_NONFREE_LIST="
 libfdk_aac
 openssl
 libtls
+mbedtls
 "
 
 EXTERNAL_LIBRARY_VERSION3_LIST="
@@ -3117,7 +3120,7 @@ fifo_muxer_deps="threads"
 flac_demuxer_select="flac_parser"
 hds_muxer_select="flv_muxer"
 hls_muxer_select="mpegts_muxer"
-hls_muxer_suggest="gcrypt openssl"
+hls_muxer_suggest="gcrypt openssl mbedtls"
 image2_alias_pix_demuxer_select="image2_demuxer"
 image2_brender_pix_demuxer_select="image2_demuxer"
 ipod_muxer_select="mov_muxer"
@@ -3229,7 +3232,7 @@ xv_outdev_extralibs="-lXv -lX11 -lXext"
 async_protocol_deps="threads"
 bluray_protocol_deps="libbluray"
 ffrtmpcrypt_protocol_conflict="librtmp_protocol"
-ffrtmpcrypt_protocol_deps_any="gcrypt gmp openssl"
+ffrtmpcrypt_protocol_deps_any="gcrypt gmp openssl mbedtls"
 ffrtmpcrypt_protocol_select="tcp_protocol"
 ffrtmphttp_protocol_conflict="librtmp_protocol"
 ffrtmphttp_protocol_select="http_protocol"
@@ -3249,7 +3252,7 @@ librtmpt_protocol_deps="librtmp"
 librtmpte_protocol_deps="librtmp"
 libsmbclient_protocol_deps="libsmbclient gplv3"
 libssh_protocol_deps="libssh"
-libtls_conflict="openssl gnutls"
+libtls_conflict="openssl gnutls mbedtls"
 mmsh_protocol_select="http_protocol"
 mmst_protocol_select="network"
 libsrt_protocol_deps="libsrt"
@@ -3269,13 +3272,13 @@ rtmpte_protocol_suggest="zlib"
 rtmpts_protocol_select="ffrtmphttp_protocol https_protocol"
 rtmpts_protocol_suggest="zlib"
 rtp_protocol_select="udp_protocol"
-schannel_conflict="openssl gnutls libtls"
+schannel_conflict="openssl gnutls libtls mbedtls"
 sctp_protocol_deps="struct_sctp_event_subscribe struct_msghdr_msg_flags"
 sctp_protocol_select="network"
-securetransport_conflict="openssl gnutls libtls"
+securetransport_conflict="openssl gnutls libtls mbedtls"
 srtp_protocol_select="rtp_protocol srtp"
 tcp_protocol_select="network"
-tls_protocol_deps_any="gnutls openssl schannel 

[FFmpeg-devel] [PATCH] avcodec/vc1_pred: properly clip interlaced motion vectors

[Paul B Mahol]

Fixes #2557.

Signed-off-by: Paul B Mahol 
---
 libavcodec/vc1_pred.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vc1_pred.c b/libavcodec/vc1_pred.c
index 54712f6b7a..9f42a930fe 100644
--- a/libavcodec/vc1_pred.c
+++ b/libavcodec/vc1_pred.c
@@ -98,9 +98,9 @@ static av_always_inline int scaleforsame_y(VC1Context *v, int 
i, int n /* MV */,
 }
 
 if (v->cur_field_type && !v->ref_field_type[dir])
-return av_clip(scaledvalue, -v->range_y / 2 + 1, v->range_y / 2);
+return av_clip(scaledvalue, -v->range_y / 2 - 1, v->range_y / 2);
 else
-return av_clip(scaledvalue, -v->range_y / 2, v->range_y / 2 - 1);
+return av_clip(scaledvalue, -v->range_y / 2, v->range_y / 2 + 1);
 }
 
 static av_always_inline int scaleforopp_x(VC1Context *v, int n /* MV */)
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] avformat/segafilm - revert keyframe detection

[Gyan Doshi]

On 4/21/2018 1:18 PM, Paul B Mahol wrote:


what about muxer?


Will wait a few days first for author to fix it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/3] doc/examples/hw_decode: Remove setting deprecated refcounted_frames

[Jun Zhao]

When use new decode APIs(avcodec_send_packet/avcodec_receive_frame),
don't need to setting the deprecated field refcounted_frames.

Signed-off-by: Jun Zhao 
---
 doc/examples/hw_decode.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/doc/examples/hw_decode.c b/doc/examples/hw_decode.c
index 77ae8df..4a4e7fc 100644
--- a/doc/examples/hw_decode.c
+++ b/doc/examples/hw_decode.c
@@ -211,7 +211,6 @@ int main(int argc, char *argv[])
 return -1;
 
 decoder_ctx->get_format  = get_hw_format;
-av_opt_set_int(decoder_ctx, "refcounted_frames", 1, 0);
 
 if (hw_decoder_init(decoder_ctx, type) < 0)
 return -1;
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 3/3] doc/examples/filtering_audio: Remove setting deprecated refcounted_frames

[Jun Zhao]

When use new decode APIs(avcodec_send_packet/avcodec_receive_frame),
don't need to setting the deprecated field refcounted_frames.

Signed-off-by: Jun Zhao 
---
 doc/examples/filtering_audio.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/doc/examples/filtering_audio.c b/doc/examples/filtering_audio.c
index b109dbc..834b137 100644
--- a/doc/examples/filtering_audio.c
+++ b/doc/examples/filtering_audio.c
@@ -74,7 +74,6 @@ static int open_input_file(const char *filename)
 if (!dec_ctx)
 return AVERROR(ENOMEM);
 avcodec_parameters_to_context(dec_ctx, 
fmt_ctx->streams[audio_stream_index]->codecpar);
-av_opt_set_int(dec_ctx, "refcounted_frames", 1, 0);
 
 /* init the audio decoder */
 if ((ret = avcodec_open2(dec_ctx, dec, NULL)) < 0) {
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH] avformat/segafilm - revert keyframe detection

[Paul B Mahol]

On 4/21/18, Gyan Doshi  wrote:
> References:
>
> http://www.ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228596.html
> http://www.ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228602.html
>
>
>

what about muxer?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/segafilm - revert keyframe detection

[Gyan Doshi]

References:

http://www.ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228596.html
http://www.ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228602.html


From a9b55290722ee6222b5cb5d067544f3846e1b07b Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Sat, 21 Apr 2018 12:44:12 +0530
Subject: [PATCH] avformat/segafilm - revert keyframe detection

Keyframe detection was inverted in cfe1a9d311 in order to fix keyframe
flags set for the sample attached to trac #7091. However, that sample is
errantly muxed.

As noted at
https://web.archive.org/web/20020803104640/http://www.pcisys.net:80/~melanson/codecs/film-format.txt,
the original keyframe detection logic is correct, and this patch
restores it.
---
 libavformat/segafilm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/segafilm.c b/libavformat/segafilm.c
index e72c26b144..b0c6c419ce 100644
--- a/libavformat/segafilm.c
+++ b/libavformat/segafilm.c
@@ -239,7 +239,7 @@ static int film_read_header(AVFormatContext *s)
 } else {
 film->sample_table[i].stream = film->video_stream_index;
 film->sample_table[i].pts = AV_RB32([8]) & 0x7FFF;
-film->sample_table[i].keyframe = (scratch[8] & 0x80) ? 
AVINDEX_KEYFRAME : 0;
+film->sample_table[i].keyframe = (scratch[8] & 0x80) ? 0 : 
AVINDEX_KEYFRAME;
 video_frame_counter++;
 if (film->video_type)
 av_add_index_entry(s->streams[film->video_stream_index],
-- 
2.12.2.windows.2___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel