fre 2018-04-27 klockan 00:50 +0200 skrev wm4:
> On Thu, 26 Apr 2018 14:41:55 +0200
> Daniel Oberhoff wrote:
>
> > > On 26. Apr 2018, at 14:40, wm4 wrote:
> > >
> > > On Thu, 26 Apr 2018 14:12:14 +0200
> > > Hendrik Leppkes mailto:h.lepp...@gmail.com>
> > > > wrote:
> > >
> > > > On Thu, Apr
Just for curious, will you have the common code for H.265 level handling too?
> Including a unit test.
> ---
> libavcodec/Makefile| 3 +-
> libavcodec/h264_levels.c | 130 +
> libavcodec/h264_levels.h | 53
> libavcodec/tests/.g
On 4/27/18 4:26 AM, Michael Niedermayer wrote:
> On Fri, Apr 27, 2018 at 12:35:42AM +0300, Jan Ekström wrote:
>> On Thu, Apr 26, 2018 at 12:00 PM, Jeyapal, Karthick
>> wrote:
>>>
>>>
>>> On 4/23/18 11:40 AM, Karthick J wrote:
From: Karthick Jeyapal
There is a separate muxer(webm
On 4/27/18 3:05 AM, Jan Ekström wrote:
> On Thu, Apr 26, 2018 at 12:00 PM, Jeyapal, Karthick
> wrote:
>>
>>
>> On 4/23/18 11:40 AM, Karthick J wrote:
>>> From: Karthick Jeyapal
>>>
>>> There is a separate muxer(webmdashenc.c) for supporting VP9+webm output in
>>> DASH.
>>> Hence in this muxer
On Sun, 2018-04-22 at 16:29 +0100, Mark Thompson wrote:
> Query which modes are supported and select between VBR and CBR based
> on that. Removes all of the codec-specific rate control mode selection
> code. Also ensures that target percentage and window size match the
> target bitrate and RC buf
> On 26/04/18 06:34, Xiang, Haihao wrote:
> > On Sun, 2018-04-22 at 16:29 +0100, Mark Thompson wrote:
> > > This was previously accessible only via AVCodecContext.compression_level
> > > for all encoders except H.264 where it was also a private option. This
> > > makes it an explicit option every
On Fri, Apr 27, 2018 at 3:51 AM, Jan Ekström wrote:
> Personally I would be for removal of the WebM muxing feature in dashenc
> altogether, since the dashenc feature has never seemingly worked, and
> since there is a whole separate WebM-specific DASH meta muxer in
> webmdashenc.
>
> But these patc
On Thu, Apr 26, 2018 at 10:33:59AM +0530, vdi...@akamai.com wrote:
> From: Vishwanath Dixit
>
> Forced key frames creation functionality was assuming the first PTS
> value to be zero, but, when 'copyts' is enalbed, the first PTS can
> be any big number. This was eventually forcing all the frames
Enables one to test possibly nonstandard formats such as Opus or
FLAC in ISOBMFF, among other things.
This becomes much more useful if output segment format becomes an
option, or if the WebM segment feature gets removed.
---
libavformat/dashenc.c | 9 +
1 file changed, 5 insertions(+), 4
It has not ever been working and has not been validated,
Additionally, mention that the segment file names should be changed
to end with webm instead of m4s, which is utilized for ISOBMFF
fragments.
---
libavformat/dashenc.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavform
Personally I would be for removal of the WebM muxing feature in dashenc
altogether, since the dashenc feature has never seemingly worked, and
since there is a whole separate WebM-specific DASH meta muxer in
webmdashenc.
But these patches should at least make the thing not crash, and put it
under F
From: Rodger Combs
Fixes crash when muxing MKV-in-DASH
---
libavformat/dashenc.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 211ef23cb0..4f8f61b704 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dash
On Fri, Apr 27, 2018 at 12:08:16AM +0100, Josh de Kock wrote:
> The postproc library is only used in a single filter, so should be moved into
> the filter itself if the filter was to stay, but the filter has all of its
> internal filters now in lavfi itself. (Also it's a bit weird to have a
> se
On Thu, Apr 26, 2018, at 2:50 PM, wm4 wrote:
>
> That would mostly get rid of the centralization argument. But I've
> heard bad things from someone who wanted to setup a private instance of
> it. Apparently it has a large number of dependencies, is extremely hard
> to deploy (unless you use their d
2018-04-27 1:57 GMT+02:00, Josh de Kock :
> On 2018/04/27 0:38, Carl Eugen Hoyos wrote:
>> Could you explain which filters in libavfilter are the
>> equivalents for the functionality of libpostproc?
>
> deblocking filters -> vf_deblock
> deinterlacing filters -> vf_yadif
> autolevels -> eq (with s
On 2018/04/27 0:38, Carl Eugen Hoyos wrote:
2018-04-27 1:28 GMT+02:00, Josh de Kock :
On 2018/04/27 0:19, Carl Eugen Hoyos wrote:
2018-04-27 1:08 GMT+02:00, Josh de Kock :
The postproc library is only used in a single filter
Is libswscale used in more filters? Are you planning to
deprecate i
Thank you all for taking the time to reply!
While I may have seemed inactive, I have read each and every reply
multiple times to make sure I understood the points made correctly.
It has really been food for thought and exactly what I hoped for, so
thanks again!
I think it would be best to be inde
On 27/04/18 00:33, John Pilkington wrote:
> Hi: I haven't previously posted here.
>
> I've been on the mythtv lists since 2005 and wrote a cutting script that I
> use daily on mpeg2video SD recordings from DVB-T; it cuts with Project-X, at
> keyframes. I have been trying to write a similar scri
On Thu, Apr 26, 2018 at 11:05:59AM +, Dixit, Vishwanath wrote:
>
>
> On 4/26/18 1:04 AM, Michael Niedermayer wrote:
> > On Tue, Apr 24, 2018 at 02:46:56PM +0530, vdi...@akamai.com wrote:
> >> From: Vishwanath Dixit
> >>
> >> This utility function creates 64-bit NTP time format as per the RFC
2018-04-27 1:28 GMT+02:00, Josh de Kock :
> On 2018/04/27 0:19, Carl Eugen Hoyos wrote:
>> 2018-04-27 1:08 GMT+02:00, Josh de Kock :
>>> The postproc library is only used in a single filter
>>
>> Is libswscale used in more filters? Are you planning to
>> deprecate it?
>
> No, libswscale does not su
Hi: I haven't previously posted here.
I've been on the mythtv lists since 2005 and wrote a cutting script that
I use daily on mpeg2video SD recordings from DVB-T; it cuts with
Project-X, at keyframes. I have been trying to write a similar script
using ffmpeg to cut h264-encoded HD recordings
On 2018/04/27 0:15, James Almer wrote:
On 4/26/2018 8:08 PM, Josh de Kock wrote:
The postproc library is only used in a single filter, so should be moved into
the filter itself if the filter was to stay, but the filter has all of its
internal filters now in lavfi itself. (Also it's a bit weird
On 2018/04/27 0:19, Carl Eugen Hoyos wrote:
2018-04-27 1:08 GMT+02:00, Josh de Kock :
The postproc library is only used in a single filter
Is libswscale used in more filters? Are you planning to
deprecate it?
No, libswscale does not suffer from the same issue of being a secondary
filter lib
2018-04-27 1:08 GMT+02:00, Josh de Kock :
> The postproc library is only used in a single filter
Is libswscale used in more filters? Are you planning to
deprecate it?
Seriously: The library is needed for compliance with
multimedia standards, it should not be deprecated.
Carl Eugen
__
On 4/26/2018 8:08 PM, Josh de Kock wrote:
> The postproc library is only used in a single filter, so should be moved into
> the filter itself if the filter was to stay, but the filter has all of its
> internal filters now in lavfi itself. (Also it's a bit weird to have a
> separate library of fi
The postproc library is only used in a single filter, so should be moved into
the filter itself if the filter was to stay, but the filter has all of its
internal filters now in lavfi itself. (Also it's a bit weird to have a separate
library of filters which is used in a filter in the filter libr
On 4/26/2018 7:30 PM, Mark Thompson wrote:
> On 25/04/18 23:42, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> libavcodec/cbs_mpeg2.c | 9 ++---
>> 1 file changed, 2 insertions(+), 7 deletions(-)
>>
>> diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
>> index 94b9591b2
On Fri, Apr 27, 2018 at 12:35:42AM +0300, Jan Ekström wrote:
> On Thu, Apr 26, 2018 at 12:00 PM, Jeyapal, Karthick
> wrote:
> >
> >
> > On 4/23/18 11:40 AM, Karthick J wrote:
> >> From: Karthick Jeyapal
> >>
> >> There is a separate muxer(webmdashenc.c) for supporting VP9+webm output in
> >> DA
On Thu, 26 Apr 2018 14:41:55 +0200
Daniel Oberhoff wrote:
> > On 26. Apr 2018, at 14:40, wm4 wrote:
> >
> > On Thu, 26 Apr 2018 14:12:14 +0200
> > Hendrik Leppkes mailto:h.lepp...@gmail.com>> wrote:
> >
> >> On Thu, Apr 26, 2018 at 2:02 PM, Daniel Oberhoff
> >> wrote:
> >>>
> Am 2
2018-04-24 21:04 GMT+02:00, Marton Balint :
> Signed-off-by: Marton Balint
> ---
> libavcodec/anm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/anm.c b/libavcodec/anm.c
> index 72684189bb..ab6a3994e9 100644
> --- a/libavcodec/anm.c
> +++ b/libavcodec/anm.c
On 26/04/18 06:34, Xiang, Haihao wrote:
> On Sun, 2018-04-22 at 16:29 +0100, Mark Thompson wrote:
>> This was previously accessible only via AVCodecContext.compression_level
>> for all encoders except H.264 where it was also a private option. This
>> makes it an explicit option everywhere.
>> ---
On 25/04/18 23:42, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/cbs_mpeg2.c | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
> index 94b9591b21..30d2bb6fbf 100644
> --- a/libavcodec/cbs_mpeg2.c
On 2018/04/26 14:14, Paul B Mahol wrote:
Removed slower one, couldn't figure out why it is slower.
Signed-off-by: Paul B Mahol
---
[...]
I agree with this patch in principle (no need to have two decoders which
do the same thing), though it might be nice to show some numbers in the
commit me
On 25/04/18 23:23, James Almer wrote:
> On 4/25/2018 6:31 PM, Mark Thompson wrote:
>> +static int cbs_jpeg_split_fragment(CodedBitstreamContext *ctx,
>> + CodedBitstreamFragment *frag,
>> + int header)
>> +{
>> +AVBufferRef *da
On Thu, Apr 26, 2018 at 12:00 PM, Jeyapal, Karthick wrote:
>
>
> On 4/23/18 11:40 AM, Karthick J wrote:
>> From: Karthick Jeyapal
>>
>> There is a separate muxer(webmdashenc.c) for supporting VP9+webm output in
>> DASH.
>> Hence in this muxer we will focus on supporting VP9 in MP4
>> Have verifi
tor 2018-04-26 klockan 13:15 +0200 skrev Daniel Oberhoff:
> Hello,
>
> I was wondering if there is any chance to move development to github?
> I.e. not just mirror, but as primary development repo, with issues
> and pull requests? Would make collaboration a *lot* easier (think of
> submitting a pr
-benchmark_all separately measures time spent encoding video, decoding
video, encoding audio, and decoding audio. You can't do that with
/usr/bin/time.
It is true that -benchmark could be replaced with /usr/bin/time, but that's
always been true. It seemed to make sense to -benchmark and -benchmark
On Fri, 20 Apr 2018 16:21:13 -0400
Mark Wachsler wrote:
> The -benchmark and -benchmark_all options now show user, system, and real
> time,
> instead of just user time.
> ---
> fftools/ffmpeg.c | 50 ++--
> 1 file changed, 36 insertions(+), 14 deletio
On Tue, 24 Apr 2018, Marton Balint wrote:
Signed-off-by: Marton Balint
---
libavcodec/anm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/anm.c b/libavcodec/anm.c
index 72684189bb..ab6a3994e9 100644
--- a/libavcodec/anm.c
+++ b/libavcodec/anm.c
@@ -54,7 +54,7 @
Friendly ping. Could someone please take a look? Thanks!
On Mon, Apr 23, 2018 at 2:29 PM, Mark Wachsler wrote:
> Ping.
>
> On Fri, Apr 20, 2018 at 4:21 PM, Mark Wachsler
> wrote:
>
>> The -benchmark and -benchmark_all options now show user, system, and real
>> time,
>> instead of just user time
On Thu, 26 Apr 2018, Aman Gupta wrote:
On Thu, Apr 26, 2018 at 8:12 AM, Nicolas George wrote:
Aman Gupta (2018-04-26):
> Another reason I discounted libzvbi is because it seems unmaintained,
> without a new release is over 5 years.
Did the teletext standard evolve in the past five years?
This patch moves AMF library and AMF device management from amfenc to
hwcontext_amf.
Now av_hwdevice_ctx API is used for AMF library/context creation/destroying
Phase 2 probably will include frame interop/map functions using hwframe_ctx API
---
libavcodec/amfenc.c| 250 --
On Tue, Apr 24, 2018 at 07:07:58PM -0700, Aman Gupta wrote:
> From: Aman Gupta
>
> Based largely on VLC's modules/codec/telx.c.
>
> Processes only teletext pages marked as subtitles, so depending
> on the stream it might not produce any output.
>
> Subtitles are rendered directly to ASS, with s
On Sun, Apr 22, 2018 at 05:00:45PM +0200, wm4 wrote:
> On Sun, 22 Apr 2018 16:38:08 +0200
> Clément Bœsch wrote:
>
> > ---
> > TODO: APIChanges + lavu minor bump (not done yet because it will
> > conflict with the threadmessage patch)
> > ---
> > libavutil/opt.c | 6 ++
> > libavutil/opt.h |
On Mon, Apr 23, 2018 at 02:13:41AM +0200, Michael Niedermayer wrote:
[...]
> doesnt document the AVERROR case
>
added
> should be ok otherwise, no more comments from me
>
thx, applied
--
Clément B.
signature.asc
Description: PGP signature
___
ffm
On Thu, 26 Apr 2018 08:59:03 -0800
Lou Logan wrote:
> On Thu, Apr 26, 2018, at 4:40 AM, wm4 wrote:
> >
> > To be fair, I'd prefer the github issue tracker over TRAC any day.
>
> At least it isn't Bugzilla. What are some of the problems with trac? Is there
> a self-hostable bug tracker you pre
Thanks Mark,
You are right, we can implement in our code a sort of "av_hwdevice_ctx_set"
(which does not exist), by using av_hwdevice_ctx_alloc() +
av_hwdevice_ctx_init(). We actually use av_hwdevice_ctx_alloc in our code to
use the feature we implemented already. We are not sure about license
On Thu, Apr 26, 2018, at 4:40 AM, wm4 wrote:
>
> To be fair, I'd prefer the github issue tracker over TRAC any day.
At least it isn't Bugzilla. What are some of the problems with trac? Is there a
self-hostable bug tracker you prefer?
___
ffmpeg-devel ma
On Thu, Apr 26, 2018 at 03:15:08AM +0200, Marton Balint wrote:
>
>
> On Thu, 26 Apr 2018, Carl Eugen Hoyos wrote:
>
> >2018-04-25 4:07 GMT+02:00, Aman Gupta :
> >
> >>Processes only teletext pages marked as subtitles, so
> >>depending on the stream it might not produce any output.
> >
> >Shouldn
On Thu, Apr 26, 2018 at 8:12 AM, Nicolas George wrote:
> Aman Gupta (2018-04-26):
> > Another reason I discounted libzvbi is because it seems unmaintained,
> > without a new release is over 5 years.
>
> Did the teletext standard evolve in the past five years?
>
I don't know, but there it is atle
On 4/26/18, Jerome Borsboom wrote:
> Overlap filtering of the first row and first column must be guarded
> for out of bounds access of v->over_flags_plane.
>
> Signed-off-by: Jerome Borsboom
> ---
> libavcodec/vc1_loopfilter.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
appl
Hello,
Do I need to do any other things to get this patch accepted?
Best Regards,
Somsak
soms...@gmail.com
On Fri, Apr 20, 2018 at 5:05 PM, Somsak Sriprayoonsakul
wrote:
> (Sorry for spamming, forgot the sign off part)
>
> This patch make ffmpeg able to create a single HLS m3u8 with differen
On 4/26/2018 11:49 AM, Jerome Borsboom wrote:
> Overlap filtering of the first row and first column must be guarded
> for out of bounds access of v->over_flags_plane.
>
> Signed-off-by: Jerome Borsboom
> ---
> libavcodec/vc1_loopfilter.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions
Aman Gupta (2018-04-26):
> Another reason I discounted libzvbi is because it seems unmaintained,
> without a new release is over 5 years.
Did the teletext standard evolve in the past five years?
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
On Wed, Apr 25, 2018 at 9:17 PM, Aman Gupta wrote:
>
> On Wed, Apr 25, 2018 at 6:15 PM Marton Balint wrote:
>
>>
>>
>> On Thu, 26 Apr 2018, Carl Eugen Hoyos wrote:
>>
>> > 2018-04-25 4:07 GMT+02:00, Aman Gupta :
>> >
>> >> Processes only teletext pages marked as subtitles, so
>> >> depending on
> On 26. Apr 2018, at 16:20, Daniel Oberhoff wrote:
>
> ---
> include/ffnvcodec/dynlink_cuda.h | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/ffnvcodec/dynlink_cuda.h
> b/include/ffnvcodec/dynlink_cuda.h
> index 2cc50bb..df1d316 100644
> --- a/include/ffnvcodec/dynlink
On Thu, Apr 26, 2018 at 4:35 AM, Carl Eugen Hoyos
wrote:
> 2018-04-26 5:02 GMT+02:00, Aman Gupta :
> > On Wed, Apr 25, 2018 at 5:30 PM Carl Eugen Hoyos
> wrote:
> >
> >> 2018-04-25 4:07 GMT+02:00, Aman Gupta :
> >>
> >> > Processes only teletext pages marked as subtitles, so
> >> > depending on
On 4/26/2018 3:49 PM, Tobias Rapp wrote:
> "ost" is of type OutputStream here, which only has top_field_first with
> values auto=-1/bff=0/tff=1. AVFrame has the
> interlaced_frame/top_field_first pair you mentioned, while
> AVCodecContext has field_order.
Ah, I misunderstood the type and values
On Thu, Apr 26, 2018 at 4:12 PM, Daniel Oberhoff
wrote:
>
>> On 26. Apr 2018, at 14:08, Hendrik Leppkes wrote:
>>
>> On Thu, Apr 26, 2018 at 2:06 PM, Daniel Oberhoff
>> wrote:
>>> Hello,
>>>
>>> I just started programming to directly use the cuda decoded frames on the
>>> gpu (working off maste
On 26.04.2018 16:11, Derek Buitenhuis wrote:
On 4/26/2018 3:06 PM, Tobias Rapp wrote:
+if (ost->top_field_first == 0) {
+enc_ctx->field_order = AV_FIELD_BB;
+} else if (ost->top_field_first == 1) {
+enc_ctx->field_order = AV_FIELD_TT;
+}
This doe
Overlap filtering of the first row and first column must be guarded
for out of bounds access of v->over_flags_plane.
Signed-off-by: Jerome Borsboom
---
libavcodec/vc1_loopfilter.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vc1_loopfilter.c b/libavcodec/v
---
include/ffnvcodec/dynlink_cuda.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/ffnvcodec/dynlink_cuda.h b/include/ffnvcodec/dynlink_cuda.h
index 2cc50bb..df1d316 100644
--- a/include/ffnvcodec/dynlink_cuda.h
+++ b/include/ffnvcodec/dynlink_cuda.h
@@ -68,6 +68,14 @@ typede
*** BLURB HERE ***
Daniel Oberhoff (1):
add CUgraphicsRegisterFlags enum
include/ffnvcodec/dynlink_cuda.h | 8
1 file changed, 8 insertions(+)
--
2.14.3 (Apple Git-98)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.or
On 4/26/2018 3:06 PM, Tobias Rapp wrote:
> +if (ost->top_field_first == 0) {
> +enc_ctx->field_order = AV_FIELD_BB;
> +} else if (ost->top_field_first == 1) {
> +enc_ctx->field_order = AV_FIELD_TT;
> +}
This doesn't look correct; ost->top_field_first
I can't think of a situation where there'd possibly be more than one
nvidia driver installed on a system.
And even if, the same application loading a lib of the same name will
internally hit its reference counter and just use the exact same one again.
signature.asc
Description: OpenPGP digital s
> On 26. Apr 2018, at 14:08, Hendrik Leppkes wrote:
>
> On Thu, Apr 26, 2018 at 2:06 PM, Daniel Oberhoff
> wrote:
>> Hello,
>>
>> I just started programming to directly use the cuda decoded frames on the
>> gpu (working off master). Would it be possible to publicly expose the loaded
>> cuda
Fixes stream field order written by avformat_write_header when "top"
option is specified on the command-line.
Signed-off-by: Tobias Rapp
---
fftools/ffmpeg.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 4dbe721..a28786a 100644
--- a/fftools/
On 4/25/2018 4:07 PM, Derek Buitenhuis wrote:
> Ping.
>
> If there are no further comments, I plan to push tomorrow evening.
It's been over 10 days, and the sole comment was addressed.
Pushed.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.
On 26.04.2018 14:47, Daniel Oberhoff wrote:
> ---
> include/ffnvcodec/dynlink_loader.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/ffnvcodec/dynlink_loader.h
> b/include/ffnvcodec/dynlink_loader.h
> index 352a0c8..3b0a284 100644
> --- a/include/ffnvcodec/dynl
On 4/24/18, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> doc/filters.texi | 15 +
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/vf_mix.c | 158
> +++
> 4 files changed, 136 insertion
On 4/26/2018 12:29 PM, wm4 wrote:
> You never follow that though. You participate in endless flames, until
> the other side is tired and gives up.
This. The one who has endless energy to argue their point wins on ffmpeg-devel,
not the one with the correct or even most-supported point. Observed num
Removed slower one, couldn't figure out why it is slower.
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 -
libavcodec/allcodecs.c | 1 -
libavcodec/proresdec_lgpl.c | 786
3 files changed, 788 deletions(-)
delete mode 10064
On Thu, 26 Apr 2018 14:51:09 +0200
Daniel Oberhoff wrote:
> > On 26. Apr 2018, at 14:49, Nicolas George wrote:
> >
> > Daniel Oberhoff (2018-04-26):
> >> ---
> >> include/ffnvcodec/dynlink_loader.h | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > I may be missing something
> On 26. Apr 2018, at 14:49, Nicolas George wrote:
>
> Daniel Oberhoff (2018-04-26):
>> ---
>> include/ffnvcodec/dynlink_loader.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> I may be missing something obvious, but I am not seeing this file in our
> repository.
sorry, its from t
Daniel Oberhoff (2018-04-26):
> ---
> include/ffnvcodec/dynlink_loader.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
I may be missing something obvious, but I am not seeing this file in our
repository.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
---
include/ffnvcodec/dynlink_loader.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/ffnvcodec/dynlink_loader.h
b/include/ffnvcodec/dynlink_loader.h
index 352a0c8..3b0a284 100644
--- a/include/ffnvcodec/dynlink_loader.h
+++ b/include/ffnvcodec/dynlink_loader.h
@@ -11
Daniel Oberhoff (1):
make headers compile in c++ mode
include/ffnvcodec/dynlink_loader.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.14.3 (Apple Git-98)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/
On Thu, 26 Apr 2018, 14:42 Daniel Oberhoff,
wrote:
>
> > On 26. Apr 2018, at 14:40, wm4 wrote:
> >
> > On Thu, 26 Apr 2018 14:12:14 +0200
> > Hendrik Leppkes mailto:h.lepp...@gmail.com>>
> wrote:
> >
> >> On Thu, Apr 26, 2018 at 2:02 PM, Daniel Oberhoff
> >> wrote:
> >>>
> Am 26.04.2018 um
> On 26. Apr 2018, at 14:40, wm4 wrote:
>
> On Thu, 26 Apr 2018 14:12:14 +0200
> Hendrik Leppkes mailto:h.lepp...@gmail.com>> wrote:
>
>> On Thu, Apr 26, 2018 at 2:02 PM, Daniel Oberhoff
>> wrote:
>>>
Am 26.04.2018 um 13:59 schrieb Daniel Oberhoff
:
> Am 26.04.2018
On Thu, 26 Apr 2018 14:12:14 +0200
Hendrik Leppkes wrote:
> On Thu, Apr 26, 2018 at 2:02 PM, Daniel Oberhoff
> wrote:
> >
> >> Am 26.04.2018 um 13:59 schrieb Daniel Oberhoff
> >> :
> >>
> >>
> >>> Am 26.04.2018 um 13:56 schrieb Daniel Oberhoff
> >>> :
> >>>
> >>>
> Am 26.04.2018 um
>>
>> BTW, is there any kind of issue tracking?
>
> https://trac.ffmpeg.org/
oh, 1784 issues...
signature.asc
Description: Message signed with OpenPGP
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-dev
On Thu, 26 Apr 2018 14:19:51 +0200
Nicolas George wrote:
> Josh de Kock (2018-04-26):
> > >>Generally, adding more things to public API is a bad move
>
> > What I mean by this is making private fields public is generally a bad move.
> > They were initially made private for a reason, and if you
Josh de Kock (2018-04-26):
> >>Generally, adding more things to public API is a bad move
> What I mean by this is making private fields public is generally a bad move.
> They were initially made private for a reason, and if you suddenly need to
> modify them outside then you must ask: What does th
On 2018-04-26 13:15, Daniel Oberhoff wrote:
> I was wondering if there is any chance to move development to github?
> I.e. not just mirror, but as primary development repo, with issues and
> pull requests? Would make collaboration a *lot* easier (think of
> submitting a pr instead of having to gene
On Thu, Apr 26, 2018 at 2:02 PM, Daniel Oberhoff
wrote:
>
>> Am 26.04.2018 um 13:59 schrieb Daniel Oberhoff
>> :
>>
>>
>>> Am 26.04.2018 um 13:56 schrieb Daniel Oberhoff
>>> :
>>>
>>>
Am 26.04.2018 um 13:52 schrieb Nicolas George :
Daniel Oberhoff (2018-04-26):
> I was wonderi
On Thu, Apr 26, 2018 at 2:06 PM, Daniel Oberhoff
wrote:
> Hello,
>
> I just started programming to directly use the cuda decoded frames on the gpu
> (working off master). Would it be possible to publicly expose the loaded cuda
> functions? This way I can inherit the possibility to build with cud
Hello,
I just started programming to directly use the cuda decoded frames on the gpu
(working off master). Would it be possible to publicly expose the loaded cuda
functions? This way I can inherit the possibility to build with cuda support
but run in absence of cuda on the target. Currently the
> Am 26.04.2018 um 13:59 schrieb Daniel Oberhoff
> :
>
>
>> Am 26.04.2018 um 13:56 schrieb Daniel Oberhoff
>> :
>>
>>
>>> Am 26.04.2018 um 13:52 schrieb Nicolas George :
>>>
>>> Daniel Oberhoff (2018-04-26):
I was wondering if there is any chance to move development to github?
I.e
> Am 26.04.2018 um 13:56 schrieb Daniel Oberhoff
> :
>
>
>> Am 26.04.2018 um 13:52 schrieb Nicolas George :
>>
>> Daniel Oberhoff (2018-04-26):
>>> I was wondering if there is any chance to move development to github?
>>> I.e. not just mirror, but as primary development repo, with issues and
>
Daniel Oberhoff (2018-04-26):
> https://hub.github.com/hub.1.html
Thanks. So, how do I read a comment in an issue without a browser?
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel
On 4/26/18, Carl Eugen Hoyos wrote:
> 2018-04-26 13:48 GMT+02:00, Paul B Mahol :
>> On 4/26/18, Carl Eugen Hoyos wrote:
>>> 2018-04-26 13:34 GMT+02:00, Paul B Mahol :
On 4/26/18, Carl Eugen Hoyos wrote:
> 2018-04-26 13:17 GMT+02:00, Josh de Kock :
>> On 2017/06/26 15:09, Paul B Maho
> Am 26.04.2018 um 13:52 schrieb Nicolas George :
>
> Daniel Oberhoff (2018-04-26):
>> I was wondering if there is any chance to move development to github?
>> I.e. not just mirror, but as primary development repo, with issues and
>> pull requests? Would make collaboration a *lot* easier (think o
Paul B Mahol (2018-04-26):
> That was with default configuration for both of them.
Then please post a patch to enhance the default configuration.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
2018-04-26 13:48 GMT+02:00, Paul B Mahol :
> On 4/26/18, Carl Eugen Hoyos wrote:
>> 2018-04-26 13:34 GMT+02:00, Paul B Mahol :
>>> On 4/26/18, Carl Eugen Hoyos wrote:
2018-04-26 13:17 GMT+02:00, Josh de Kock :
> On 2017/06/26 15:09, Paul B Mahol wrote:
>> Rationale:
>> - Slower t
Daniel Oberhoff (2018-04-26):
> I was wondering if there is any chance to move development to github?
> I.e. not just mirror, but as primary development repo, with issues and
> pull requests? Would make collaboration a *lot* easier (think of
> submitting a pr instead of having to generate/format/sp
On Thu, 26 Apr 2018 13:39:56 +0200
Carl Eugen Hoyos wrote:
> 2018-04-26 13:34 GMT+02:00, Paul B Mahol :
> > On 4/26/18, Carl Eugen Hoyos wrote:
> >> 2018-04-26 13:17 GMT+02:00, Josh de Kock :
> >>> On 2017/06/26 15:09, Paul B Mahol wrote:
> Rationale:
> - Slower then other encode
On 4/26/18, Carl Eugen Hoyos wrote:
> 2018-04-26 13:34 GMT+02:00, Paul B Mahol :
>> On 4/26/18, Carl Eugen Hoyos wrote:
>>> 2018-04-26 13:17 GMT+02:00, Josh de Kock :
On 2017/06/26 15:09, Paul B Mahol wrote:
> Rationale:
> - Slower then other encoder
> - Less configurable
> -
2018-04-26 13:34 GMT+02:00, Reino Wijnsma :
> On 22-4-2018 0:52, Reino Wijnsma wrote:
>> 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
2018-04-26 13:34 GMT+02:00, Paul B Mahol :
> On 4/26/18, Carl Eugen Hoyos wrote:
>> 2018-04-26 13:17 GMT+02:00, Josh de Kock :
>>> On 2017/06/26 15:09, Paul B Mahol wrote:
Rationale:
- Slower then other encoder
- Less configurable
- Does not support alpha profile
- Does no
On Thu, 26 Apr 2018 13:34:12 +0200
Paul B Mahol wrote:
> On 4/26/18, Carl Eugen Hoyos wrote:
> > 2018-04-26 13:17 GMT+02:00, Josh de Kock :
> >> On 2017/06/26 15:09, Paul B Mahol wrote:
> >>> Rationale:
> >>> - Slower then other encoder
> >>> - Less configurable
> >>> - Does not support alph
1 - 100 of 120 matches
Mail list logo
