Thank you.
This change is really simple: set AV_DISPOSITION_DESCRIPTIONS bit when we
have a specified stream. So a test could be simple too. But I cannot see
many of tests in .../libavformat/tests dir. It seems 'disposition' is not
tested at all currently. So if I will prepare a testcase for
'ff_p
Kieran Kunhya (2018-04-25):
> It was objected heavily to at the time
And eventually a decision was made. This is one of the problems of this
project: developers pulling in every direction without consistency nor
leadership. One step forward, two steps on the side, one step backward;
iterate.
>
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 verified playout support of VP9+MP4 in Chrome and Firefox.
> ---
> libavfor
On 2018/04/25 23:18, Nicolas George wrote:
Josh de Kock (2018-04-25):
If anything, this should have never been added and a suitable
external library should have been picked.
This opinion should have been expressed three years ago. It was decided
then that lavf deserved a HTTP ser
Josh de Kock (2018-04-26):
> It's also not impossible, nor irrational to be removing code which
> doesn't fit or could be written better if an alternative is provided, the
> need was never there or removal can otherwise be justified.
Then justify. But you will need to address all the argu
On Tue, Apr 24, 2018 at 01:59:26PM -0700, Aman Gupta wrote:
> From: Aman Gupta
>
> This fixes issues reported on some devices where both
> avcodec_send_packet and avcodec_receive_frame can return EAGAIN
> at the same time, instead of one or the other blocking.
>
> The new logic follows a recomme
On 2018/04/24 22:33, Stephan Holljes wrote:
Hi all,
I've discussed this on IRC a bit, but I don't want to exclude those
views that are not present there.
The consensus seems to be that there are more disadvantages in using
the http server of libavformat than there are advantages.
I honestly t
Josh de Kock (2018-04-26):
> Generally, adding more things to public API is a bad move
I do not accept this statement as is. Please justify it.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
f
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
>> 5905.
>> A simple explaination of 64-bit NTP time format is here
>> http://ww
On 2018/04/26 11:56, Nicolas George wrote:
Josh de Kock (2018-04-26):
Generally, adding more things to public API is a bad move
I do not accept this statement as is. Please justify it.
What I mean by this is making private fields public is generally a bad
move. They were initially made pri
On 2017/06/26 15:09, Paul B Mahol wrote:
Rationale:
- Slower then other encoder
- Less configurable
- Does not support alpha profile
- Does not set interlaced flag
- Worse output quality
- No need for 2 encoders
Signed-off-by: Paul B Mahol
Is there any reason this was not pushed? I can't seem
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 instead of
having to generate/format/split patches).
Best
Daniel
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 not set interlaced flag
>> - Worse output quality
>> - No need for 2 encoders
>>
>> Signed-off-by:
> On 26 Apr 2018, at 12:15, Daniel Oberhoff
> wrote:
>
> 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 p
On Thu, 26 Apr 2018 12:47:58 +0200
Nicolas George wrote:
> Josh de Kock (2018-04-26):
> >It's also not impossible, nor irrational to be removing code which
> > doesn't fit or could be written better if an alternative is provided, the
> > need was never there or removal can otherwise be ju
On 2018/04/26 12:26, 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 not set interlaced flag
- Worse output quality
- No need for 2 enco
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 not set interlaced flag
>>> - Worse output quality
>>>
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
>> reasons, the only
>> way to silence the resulti
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 the stream it might not produce any output.
>>
>> Shouldn't there be at lea
On Thu, 26 Apr 2018 13:15:52 +0200
Daniel Oberhoff wrote:
> 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
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
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
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
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
> -
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
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
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
> 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
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
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
> 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
>
> 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
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
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
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 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
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 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
>>
>> 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: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
> 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: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
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/
---
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 (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
> 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
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
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 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
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 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/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.
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 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
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 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
*** 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
---
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
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
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
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 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: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 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 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
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 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
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/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
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 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 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
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, 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
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 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 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
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 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?
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 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 @
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
-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
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
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
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 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: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 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.
>> ---
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 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
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 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
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 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
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 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
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
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
1 - 100 of 120 matches
Mail list logo
