> On 23 Mar 2018, at 13:20, vdi...@akamai.com wrote:
>
> From: Vishwanath Dixit
>
> ---
> doc/muxers.texi | 2 +-
> libavformat/dashenc.c | 10 +-
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index cb75c26..65eec92 100644
On Fri, 23 Mar 2018, 11:04 Gagandeep Singh,
wrote:
>
>
> On Fri, 23 Mar 2018, 04:26 Aurelien Jacobs, wrote:
>
>> On Wed, Mar 21, 2018 at 10:19:58PM +0530, Gagandeep Singh wrote:
>> > alpha decompanding curve added to post process the decoded alpha channel
>> > ---
>> > libavcodec/cfhd.c | 19 ++
On Fri, 23 Mar 2018, 04:26 Aurelien Jacobs, wrote:
> On Wed, Mar 21, 2018 at 10:19:58PM +0530, Gagandeep Singh wrote:
> > alpha decompanding curve added to post process the decoded alpha channel
> > ---
> > libavcodec/cfhd.c | 19 +++
> > 1 file changed, 19 insertions(+)
> >
> >
From: Vishwanath Dixit
The logic is applicable only when use_template is enabled and use_timeline
is disabled. The logic monitors the flow of segment indexes. If a streams's
segment index value is not at the expected real time position, then
the logic corrects that index value.
Typically this lo
From: Vishwanath Dixit
---
libavformat/dashenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index b0ed890..f691fb3 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -552,7 +552,7 @@ static int write_adaptation
From: Vishwanath Dixit
---
libavformat/dashenc.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 0ba9f55..294999a 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -824,20 +824,23 @@ static int write_m
From: Vishwanath Dixit
---
libavformat/dashenc.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index d20bdba..0ba9f55 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -86,6 +86,8 @@ typedef struct OutputStream {
From: Vishwanath Dixit
---
libavformat/dashenc.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 294999a..b0ed890 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -78,7 +78,6 @@ typedef
From: Vishwanath Dixit
availability time of Nth segment = availabilityStartTime + (N*segment duration)
- availabilityTimeOffset.
This field helps to reduce the latency by about a segment duration in streaming
mode.
---
libavformat/dashenc.c | 11 ++-
1 file changed, 10 insertions(+), 1
From: Vishwanath Dixit
@availabilityStartTime specifies the anchor for the computation of the earliest
availability time (in UTC) for any Segment in the Media Presentation.
---
libavformat/dashenc.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavformat/dashenc.c
From: Vishwanath Dixit
Calling 'write_manifest' from 'write_header' was causing creation of
first MPD with invalid values. Ex: zero @duration param value. Also,
the manifest files (MPD or M3U8s) should be created when at-least
one media frame is ready for consumption.
---
libavformat/dashenc.c |
From: Vishwanath Dixit
---
libavformat/dashenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index a489f5e..5fb839d 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -344,7 +344,7 @@ static void output_segment_
From: Vishwanath Dixit
When use_template is enabled and use_timeline is disabled, typically
it is required to generate the segments at the configured segment duration
rate on an average. This commit is particularly needed to handle the
segmentation when video frame rates are fractional like 29.97
From: Vishwanath Dixit
---
doc/muxers.texi | 2 +-
libavformat/dashenc.c | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index cb75c26..65eec92 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -225,7 +225,7 @@ ffmpeg -
>
> Current scaling and colour conversion code is mostly found in libswscale,
> though
> there are also other places like the colorspace filter. I don't know whether
> any
> of these will translate suitably to GPU code and what the right approach is
> here -
> some investigation will be requir
On 21/03/18 13:09, Dylan Fernando wrote:
> On Tue, Mar 20, 2018 at 10:34 AM, Mark Thompson wrote:
>> On 19/03/18 02:30, dylanf...@gmail.com wrote:
>>> From: drfer3
>>>
>>> Behaves like the existing avgblur filter, except working on OpenCL
>>> hardware frames. Takes exactly the same options.
>>> -
Ping?
The other thing: do we have a clean way to handle auto insert scale
filter in pipeline for HWaccel transcoding case in FFmpeg?
On 2018/3/14 16:26, Jun Zhao wrote:
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/lis
On 2018/03/22 22:38, Michael Niedermayer wrote:
> On Thu, Mar 22, 2018 at 02:01:27AM +, Josh de Kock wrote:
> [...]
>> +#ifdef CONFIG_AVDEVICE
>> +opaque = 0;
>> +if (muxdemuxers != SHOW_DEMUXERS) {
>> +while ((ofmt = av_outdev_iterate(&opaque))) {
>> +
On 2018-03-22 16:04 +0100, Nicolas George wrote:
> Paul B Mahol (2018-03-22):
> > So user can pick which channels to extract.
> >
> > Signed-off-by: Paul B Mahol
> > ---
> > doc/filters.texi | 18 ++
> > libavfilter/af_channelsplit.c | 39
On Mon, Mar 5, 2018 at 12:22 PM, Jacob Trimble wrote:
> On Mon, Feb 12, 2018 at 9:35 AM, Jacob Trimble wrote:
>> On Tue, Jan 30, 2018 at 11:27 AM, Jacob Trimble wrote:
>>> On Wed, Jan 24, 2018 at 5:46 PM, Michael Niedermayer
>>> wrote:
On Wed, Jan 24, 2018 at 11:43:26AM -0800, Jacob Trimbl
Hi there!
Thank you for advices, I have fixed the problem when per plane matrices
application was incorrect. Now it works as expected and behaves like the
existing vf_convolution filter.
Tested for yuv and nv12 formats.
The following filters from ffmpeg documentation
(https://ffmpeg.org/ffmpeg-fi
On Thu, Mar 22, 2018 at 02:01:27AM +, Josh de Kock wrote:
[...]
> +#ifdef CONFIG_AVDEVICE
> +opaque = 0;
> +if (muxdemuxers != SHOW_DEMUXERS) {
> +while ((ofmt = av_outdev_iterate(&opaque))) {
> +if ((!name || strcmp(ofmt-> name, name) < 0) &&
> strc
On Wed, Mar 21, 2018 at 10:19:58PM +0530, Gagandeep Singh wrote:
> alpha decompanding curve added to post process the decoded alpha channel
> ---
> libavcodec/cfhd.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
> index fd8
On Mon, Mar 19, 2018 at 10:49:28PM -0800, Lou Logan wrote:
> On Fri, Mar 16, 2018, at 11:44 AM, Paul B Mahol wrote:
> > Signed-off-by: Paul B Mahol
> > ---
> > doc/filters.texi | 60 ++
> > libavfilter/Makefile | 1 +
> > libavfilter/af_hrtfm.c | 486
> >
On 3/13/2018 9:47 PM, Jun Zhao wrote:
>
>
> On 2018/3/11 7:00, James Almer wrote:
>> Based on hevc_parser code. This prevents repeated unnecessary allocations
>> and frees on every packet processed by the bsf.
>>
>> Signed-off-by: James Almer
>> ---
>> libavcodec/extract_extradata_bsf.c | 33 ++
On Thu, Mar 22, 2018 at 9:51 PM, sanilraut wrote:
> Last segment indicated by mpd is not parsed.
> Example stream:
> http://dash.akamaized.net/dash264/TestCasesIOP41/LastSegmentNumber/1/manifest_last_segment_num.mpd
>
> This patch supports parsing of Supplemental Descriptor with @schemeIdUri set
Last segment indicated by mpd is not parsed.
Example stream:
http://dash.akamaized.net/dash264/TestCasesIOP41/LastSegmentNumber/1/manifest_last_segment_num.mpd
This patch supports parsing of Supplemental Descriptor with @schemeIdUri set to
http://dashif.org/guide-
lines/last-segment-number with
On 3/22/2018 4:34 PM, Michael Niedermayer wrote:
> On Wed, Mar 21, 2018 at 10:41:03PM -0300, James Almer wrote:
>> Nothing currently guarantees that the packet passed to the bsf will
>> be writable.
>>
>> Signed-off-by: James Almer
>> ---
>> This supersedes "[PATCH 2/2] avcodec/mpeg4_unpack_bframe
On Thu, Mar 22, 2018 at 01:07:18PM +0100, Nicolas George wrote:
> Josh de Kock (2018-03-22):
> > Merging lavd into lavf may be the best option here, as it allows us to
> > change the return type of av_iterate_indev() etc to an AVDevice or another
> > type which may represent an actual device as opp
On Wed, Mar 21, 2018 at 10:41:03PM -0300, James Almer wrote:
> Nothing currently guarantees that the packet passed to the bsf will
> be writable.
>
> Signed-off-by: James Almer
> ---
> This supersedes "[PATCH 2/2] avcodec/mpeg4_unpack_bframes: allocate a
> new packet when data needs to be changed
On Wed, Mar 21, 2018 at 11:30 PM, Courtland Idstrom
wrote:
>
>
> Please let me know if this is sufficient. I can also upload these movies
> somewhere, I didn't think it would be appropriate to attach them to this
> email.
>
>
> Cheers,
>
> -Courtland
Thanks for the verification, pushed.
Jan
Hi,
This patch is introduced as a qualification task required by Super
Resolution project for GSoC. It passes patchcheck and make fate and
doesn't introduce new warnings. It's implemented by the help of the
mentor: Pedro Arthur. It's been tested over 7 images of which 6 got
expected results
From: Aman Gupta
This is a hacky work-around for #7092, where the lavc h264
parser splits coded fields into separate video packets, only one
of which has a PTS set.
The MediaCodec#queueInputBuffer API expects a PTS along with
incoming video packets, and breaks badly when the PTS is missing
or in
Set the packet flag using constant as well.
From 905cc5f1146c957ae4290b44a06a22a7524a87de Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Wed, 21 Mar 2018 18:59:33 +0530
Subject: [PATCH] avformat/segafilm - fix keyframe detection and set packet
flags
Streams from a Segafilm cpk file can't be st
2018-03-22 16:05 GMT+01:00, Zhong Li :
> RGB32 format may be used as overlay with alpha blending.
> So add RGB32 format support.
>
> Signed-off-by: ChaoX A Liu
> Signed-off-by: Zhong Li
> ---
> libavutil/hwcontext_qsv.c | 43 +--
> 1 file changed, 33 inser
> -Ursprüngliche Nachricht-
> Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag
> von Nicolas George
> Gesendet: Donnerstag, 22. März 2018 16:03
> An: FFmpeg development discussions and patches
> Betreff: Re: [FFmpeg-devel] [PATCH] avformat/opensrt: add Haivision
> Ope
On Thu, Mar 22, 2018 at 3:43 AM, wm4 wrote:
> Why?
Mainly to modify existing videos or encode new videos for Saturn
games. It's particularly useful for fan translation - to mux in new
audio, or encode new video for things like credits sequences.
___
ffm
Currently pict_type are unset.
Add an extra param to fetch the picture type from qsv decoder
v2: remove the key_frame setting because the judgement “key frame is equal
to IDR frame” only suitable for H264.
For HEVC, all IRAP frames are key frames, and other codecs have no IDR
frame.
Signed-off-by
Set the flag MFX_BITSTREAM_COMPLETE_FRAME when it is a progressive picture.
This can fix vc1 decoding segment fault issues because can't set the start
code correctly.
See: ./avconv -hwaccel qsv -c:v vc1_qsv -i /fate-suite/vc1/SA00040.vc1
-vf "hwdownload, format=nv12" -f rawvideo /dev/null
a. field
RGB32 format may be used as overlay with alpha blending.
So add RGB32 format support.
Signed-off-by: ChaoX A Liu
Signed-off-by: Zhong Li
---
libavutil/hwcontext_qsv.c | 43 +--
1 file changed, 33 insertions(+), 10 deletions(-)
diff --git a/libavutil/hwco
Paul B Mahol (2018-03-22):
> So user can pick which channels to extract.
>
> Signed-off-by: Paul B Mahol
> ---
> doc/filters.texi | 18 ++
> libavfilter/af_channelsplit.c | 39 +--
> 2 files changed, 51 insertions(+), 6 deletions(-
Sven Dueking (2018-03-16):
> Ping !?!?
I think I am actually expected to reply.
I think that by reviewing the patch I gave the impression that I was
promising to accept the patch in FFmpeg. It was not so, and I apologize
if it was taken that way. The original patch contained significant
changes i
On 3/22/2018 6:41 AM, wm4 wrote:
> On Thu, 22 Mar 2018 01:41:11 -0300
> James Almer wrote:
>
>> Fixes ticket #7096
>>
>> Signed-off-by: James Almer
>> ---
>> libavcodec/dxva2_vc1.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/libavcodec/dxva2_vc1.c b/libavcodec/dxva2_vc1.c
>> ind
On 3/21/2018 9:30 PM, Courtland Idstrom wrote:
> Please let me know if this is sufficient. I can also upload these movies
> somewhere, I didn't think it would be appropriate to attach them to this
> email.
I'm satisfied with with it, thanks for checking!
Patch LGTM.
- Derek
_
Hi Marton,
> I still think ffmpeg.c should be fixed instead. There is even some logic in
> ffmpeg.c to wait for a frame from all streams before writing the header, so
> it seems doable.
I don’t disagree with this in principle, but we have to be a bit careful.
There are stream types that gener
On 3/21/2018 3:02 AM, Michael Niedermayer wrote:
do you want to also create a fate test for this
Can you suggest an existing fate sample file that I can use? Ideally, a
stream of a video codec with some delay.
Seems to me most samples in the suite are anomalous or broken in one way
or the
On 14.03.2018 18:56, Thomas Mundt wrote:
2018-03-13 16:10 GMT+01:00 Vasile Toncu :
On 06.03.2018 20:38, Thomas Mundt wrote:
Hi,
2018-03-05 13:48 GMT+01:00 Carl Eugen Hoyos :
2018-03-05 12:37 GMT+01:00, Paul B Mahol :
On 3/5/18, Vasile Toncu wrote:
Hello,
Thanks for the review. I've
From: Meng Wang
Signed-off-by: Meng Wang
---
This v2 patch remove unused codes 'stride_dst /= sizeof(uint8_t);' compared to
v1. V1 have this codes because we referred to hevc dsp template codes.
As FFmpeg hevc decoder have no SAO neon optimization, we add sao_band and
sao_edge neon codes in t
On 2018/03/22 12:07, Nicolas George wrote:
Josh de Kock (2018-03-22):
Merging lavd into lavf may be the best option here, as it allows us to
change the return type of av_iterate_indev() etc to an AVDevice or another
type which may represent an actual device as opposed to a purely
input/output de
Josh de Kock (2018-03-22):
> Merging lavd into lavf may be the best option here, as it allows us to
> change the return type of av_iterate_indev() etc to an AVDevice or another
> type which may represent an actual device as opposed to a purely
> input/output device (which is just implemented as an
> On 22 Mar 2018, at 19:15, sanilraut wrote:
>
> ---
> libavformat/dashdec.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index bf61837..db63a99 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
>
On 2018/03/22 11:37, wm4 wrote:
On Thu, 22 Mar 2018 12:32:29 +0100
Nicolas George wrote:
Josh de Kock (2018-03-22):
There is always the option to just merge lavf and lavd. The state of them
being sort-of merged, but not really, isn't very good and adds a lot of
complexity especially in inter-
On Thu, 22 Mar 2018 12:32:29 +0100
Nicolas George wrote:
> Josh de Kock (2018-03-22):
> > There is always the option to just merge lavf and lavd. The state of them
> > being sort-of merged, but not really, isn't very good and adds a lot of
> > complexity especially in inter-library dependencies (
On 3/22/18, Nicolas George wrote:
> Josh de Kock (2018-03-22):
>> There is always the option to just merge lavf and lavd. The state of them
>> being sort-of merged, but not really, isn't very good and adds a lot of
>> complexity especially in inter-library dependencies (which are unneeded
>> if
>>
Josh de Kock (2018-03-22):
> There is always the option to just merge lavf and lavd. The state of them
> being sort-of merged, but not really, isn't very good and adds a lot of
> complexity especially in inter-library dependencies (which are unneeded if
> lavf and lavd are either merged or actually
On 2018/03/22 11:19, Nicolas George wrote:
Josh de Kock (2018-03-22):
I strongly oppose using the same loop. Separating devices' iteration is one
of the first steps to separating lavf from lavd.
And I oppose separating lavf from lavd, was it not clear enough? I have
given technical arguments i
---
libavformat/dashdec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index bf61837..db63a99 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -922,8 +922,8 @@ static int parse_manifest_representation(AVFor
Josh de Kock (2018-03-22):
> I strongly oppose using the same loop. Separating devices' iteration is one
> of the first steps to separating lavf from lavd.
And I oppose separating lavf from lavd, was it not clear enough? I have
given technical arguments in my first mail.
Regards,
--
Nicolas G
On 2018/03/22 10:29, Nicolas George wrote:
Josh de Kock (2018-03-22):
I have -ffunroll'd the macros for you Nicolas.
That is not what I asked. The macros were just a way of making the poor
API a little less poor, but the problem still remains:
+#ifdef CONFIG_AVDEVICE
+opaque = 0;
+
On Wed, 21 Mar 2018 22:46:30 -0700
mi...@brew.sh wrote:
> From: Misty De Meo
>
> This adds a muxer for the Sega FILM format, which was used by
> Sega Saturn games in the 1990s.
>
> This muxer provides a complete implementation of the FILM format, at least
> as far as all features I've seen used
Paul B Mahol (2018-03-22):
> Why? OpenCV != OpenCL
Oh, I had not noticed. Good then.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/f
On 3/22/18, Nicolas George wrote:
> Rostislav Pehlivanov (2018-03-20):
>> There was absolutely nothing in my sentence to imply I'm sarcastic, and I
>> make sure to be obviously sarcastic when I want to be.
>> The filter we have supports a very limited subset of the features of
>> opencv
>> and if
Rostislav Pehlivanov (2018-03-20):
> There was absolutely nothing in my sentence to imply I'm sarcastic, and I
> make sure to be obviously sarcastic when I want to be.
> The filter we have supports a very limited subset of the features of opencv
> and if there's no overlap we should probably write
Josh de Kock (2018-03-22):
> I have -ffunroll'd the macros for you Nicolas.
That is not what I asked. The macros were just a way of making the poor
API a little less poor, but the problem still remains:
> +#ifdef CONFIG_AVDEVICE
> +opaque = 0;
> +if (muxdemuxers != SHOW_DEMUXERS)
On 22.03.2018 00:59, Michael Niedermayer wrote:
On Wed, Mar 21, 2018 at 03:20:30PM +0100, Tobias Rapp wrote:
Allows to manage the AV_LOG_PRINT_LEVEL flag as a prefix to the loglevel
option value, similar to the existing AV_LOG_SKIP_REPEATED flag.
Signed-off-by: Tobias Rapp
---
doc/fftools-co
On Thu, 22 Mar 2018 01:41:11 -0300
James Almer wrote:
> Fixes ticket #7096
>
> Signed-off-by: James Almer
> ---
> libavcodec/dxva2_vc1.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/dxva2_vc1.c b/libavcodec/dxva2_vc1.c
> index f22c73cd1e..06f1083b3a 100644
> --- a/libav
alpha decompanding curve added to post process the decoded alpha channel ticket
#6265
---
libavcodec/cfhd.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index fd834b..e35732df45 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/c
The code looks good to me. I think the wrapper is fine, because that part of
code is not suitable for NEON assembly.
But you can remove the using of `sizeof(uint8_t)` as suggested by Carl.
Shengbin Meng
> On 19 Mar 2018, at 12:41, Yingming Fan wrote:
>
> Hi, is there any review about this pat
Hi,
By checkasm benchmark, I can see a speedup of ~3x for band mode and ~6x for
edge mode on my device (the device has aarch64 CPU, but I configured ffmpeg
with `—arch=arm`). And FATE passed as well.
Results of a checkasm run:
$./tests/checkasm/checkasm --test=hevc_sao --bench
$ sudo ./tests/c
> On 22 Mar 2018, at 15:13, 陈 永岗 wrote:
>
>
> Hello everyone,
>
>
> I'm newbie to ffmpeg, and found ffplay.c is very useful which contains lots
> of command line operations. If press 's', it will play next frame. However I
> want to make it support playing previous frame. Where should I st
> On 22 Mar 2018, at 15:13, 陈 永岗 wrote:
>
>
> Hello everyone,
>
>
> I'm newbie to ffmpeg, and found ffplay.c is very useful which contains lots
> of command line operations. If press 's', it will play next frame. However I
> want to make it support playing previous frame. Where should I st
Hello everyone,
I'm newbie to ffmpeg, and found ffplay.c is very useful which contains lots of
command line operations. If press 's', it will play next frame. However I want
to make it support playing previous frame. Where should I start? Any
recommendations?
Best regards
Dom
_
72 matches
Mail list logo
