Paul B Mahol:
> Make sure this does not break demuxing/decoding.
>
This patch is designed to not change the packets output by the demuxer
or the demuxer's return value at all. I have tested this with a small
sample created in a hex editor, but only demuxing (as the content of the
packet was garba
Marton Balint 于2020年7月25日周六 下午5:40写道：
>
>
>
> On Sat, 25 Jul 2020, Zlomek, Josef wrote:
>
> > Hi Steven,
> >
> > It is better but still not correct. Consider this test:
> >
> > test("http://server/foo/bar";,
> > "a/b/../c/d/../e../.../..f/g../h../other/url/a.mp3/...");
> > It should give "
> > htt
于2020年7月27日周一 下午2:22写道：
>
> From: hwren
>
> Signed-off-by: hwren
> ---
> libavcodec/libxavs2.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/libavcodec/libxavs2.c b/libavcodec/libxavs2.c
> index 76b57e731e..8519f6925a 100644
> --- a/libavcodec/libxavs2.c
> +++ b/libavcodec/libx
Nicolas George 于2020年7月25日周六 下午7:03写道：
>
> Marton Balint (12020-07-25):
> > And I also would like to point out that using static strings with
> > MAX_URL_SIZE is not OK. This function supports an arbitrary buffer size, so
> > limiting it to MAX_URL_SIZE is a bug.
>
> Excellent point. That would re
On 7/27/20, Andreas Rheinhardt wrote:
> Paul B Mahol:
>> Make sure this does not break demuxing/decoding.
>>
>
> This patch is designed to not change the packets output by the demuxer
> or the demuxer's return value at all. I have tested this with a small
> sample created in a hex editor, but only
在 2020-07-27 15:26:24，"Steven Liu" 写道：
> 于2020年7月27日周一 下午2:22写道：
>>
>> From: hwren
>>
>> Signed-off-by: hwren
>> ---
>> libavcodec/libxavs2.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/libavcodec/libxavs2.c b/libavcodec/libxavs2.c
>> index 76b57e731e..8
A good alternative to work with FFmpeg on Android is Xuggler, it presents
FFmpeg's API directly to Java/Kotlin.
To deal with fd you can declare and implement your own IO handler by
implementing
https://github.com/olivierayache/xuggle-xuggler/blob/ffmpeg-3.x-dev/src/com/xuggle/xuggler/io/IURLProtoc
On Mon, Jul 27, 2020 at 09:55:31AM +0530, Gautam Ramakrishnan wrote:
> On Mon, Jul 27, 2020 at 9:48 AM Gautam Ramakrishnan
> wrote:
> >
> > On Mon, Jul 27, 2020 at 3:16 AM Michael Niedermayer
> > wrote:
> > >
> > > Fixes: division by zero
> > > Fixes:
> > > 24201/clusterfuzz-testcase-minimized-f
hwren 于2020年7月27日周一 下午3:59写道：
>
>
>
> 在 2020-07-27 15:26:24，"Steven Liu" 写道：
> > 于2020年7月27日周一 下午2:22写道：
> >>
> >> From: hwren
> >>
> >> Signed-off-by: hwren
> >> ---
> >> libavcodec/libxavs2.c | 6 ++
> >> 1 file changed, 6 insertions(+)
> >>
> >> diff --git a/libavcodec/libxavs2.c b/lib
get_ue_golomb_31() and get_ue_golomb() can only parse values within
a certain range correctly; if the parsed value is not within said range,
the latter function returns AVERROR_INVALIDDATA, while the former returns
something different from the encountered value. So the return values are
good enough
This happened in get_ue_golomb() if the cached bitstream reader was in
use, because there was no check to handle the case of the read value
not being in the supported range.
For consistency with the uncached bitstream reader and for compliance
with the documentation, every value not in the 0-8190 r
get_ue_golomb_31() reads nine bits and an array with 512 entries to
parse golomb codes. The longest golomb codes that fit into 9 bits use
four leading zeroes and five value bits and can encode numbers in the
0..30 range. 31 meanwhile is encoded on 11 bits and if the nine bits
read coincide with the
instead of get_ue_golomb(). The difference between the two is that the
latter also has to take into account the case in which the read code is
more than 9 bits (four preceding zeroes + at most five value bits) long,
leading to more code.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cavsdec.c
Said error message is not very informative and lacked a proper logging
context; furthermore, many callers already provided more descriptive
error messages of their own. So just drop this one.
Suggested-by: James Almer
Signed-off-by: Andreas Rheinhardt
---
No change since last time. Will apply th
Carl Eugen Hoyos wrote:
>Am So., 26. Juli 2020 um 21:28 Uhr schrieb Paul B Mahol
>:
>>
>> On 7/26/20, Carl Eugen Hoyos wrote:
>> > Hi!
>> >
>> > Attached patch fixes a part of ticket #8819.
>> >
>> > Please comment, Carl Eugen
>> >
>>
>> Looks good, but variable name is unfortunate.
>
>New patch
Quoting Andreas Rheinhardt (2020-07-27 06:13:05)
> Has apparently been copied from ff_choose_timebase() in commit
> a45cf639e6fb8c86aff91a00970060cd0be401c9.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> Btw: There is exactly one user of this, namely the MXF muxer.
> Should this be moved to mxfen
Quoting Kieran Kunhya (2020-07-26 01:51:22)
> Hi,
>
> I notice that some encoders adjust the PTS with initial_padding and some
> don't.
> Is this intentional and should we decide that all encoders should do this?
Which ones don't?
I don't think this is a matter of opinion really - if encoder add
Fixes: 8814
The logic for removing ".." path components and their corresponding
upper directories was reworked.
Now, the function trim_double_dot_url splits the path by "/" into
components, and processes the components one ny one:
- if the component is "..", the last path component in tmp_path is
Signed-off-by: Josef Zlomek
---
libavformat/url.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/libavformat/url.c b/libavformat/url.c
index ccaa28a1ed..28d12fd3de 100644
--- a/libavformat/url.c
+++ b/libavformat/url.c
@@ -186,14 +186,11 @@ void ff_make_absolute
Signed-off-by: Josef Zlomek
---
libavformat/tests/url.c | 2 ++
tests/ref/fate/url | 2 ++
2 files changed, 4 insertions(+)
diff --git a/libavformat/tests/url.c b/libavformat/tests/url.c
index 1d961a1b43..d7f14da49e 100644
--- a/libavformat/tests/url.c
+++ b/libavformat/tests/url.c
@@ -67,6
Josef Zlomek 于2020年7月27日周一 下午6:57写道：
>
> Fixes: 8814
>
> The logic for removing ".." path components and their corresponding
> upper directories was reworked.
>
> Now, the function trim_double_dot_url splits the path by "/" into
> components, and processes the components one ny one:
> - if the com
Josef Zlomek 于2020年7月27日周一 下午6:57写道：
>
> Signed-off-by: Josef Zlomek
> ---
> libavformat/url.c | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/libavformat/url.c b/libavformat/url.c
> index ccaa28a1ed..28d12fd3de 100644
> --- a/libavformat/url.c
> +++ b/liba
Hi Steven,
".." is always a directory.
your tests (diff starting with -) are not correct.
My results (lines starting with +) are correct.
Josef
On Mon, Jul 27, 2020 at 1:36 PM Steven Liu wrote:
> Josef Zlomek 于2020年7月27日周一 下午6:57写道：
> >
> > Fixes: 8814
> >
> > The logic for removing ".." pat
On Sat, Jul 18, 2020 at 8:31 PM myp...@gmail.com wrote:
>
> On Thu, Jul 16, 2020 at 9:35 AM myp...@gmail.com wrote:
> >
> > On Tue, Jul 14, 2020 at 9:47 PM Moritz Barsnick wrote:
> > >
> > > On Sun, Jul 12, 2020 at 22:44:46 +0800, myp...@gmail.com wrote:
> > > > Maybe I give an inaccurate descri
I also noticed that the 3rd part did not make it to patchwork.
Maybe it is because it modifies the same file. I will squash it with the
first part.
Josef
On Mon, Jul 27, 2020 at 1:36 PM Steven Liu wrote:
> Josef Zlomek 于2020年7月27日周一 下午6:57写道：
> >
> > Signed-off-by: Josef Zlomek
> > ---
> > l
Zlomek, Josef 于2020年7月27日周一 下午7:45写道：
>
> Hi Steven,
>
> ".." is always a directory.
>
> your tests (diff starting with -) are not correct.
> My results (lines starting with +) are correct.
>
> Josef
>
> On Mon, Jul 27, 2020 at 1:36 PM Steven Liu wrote:
>>
>> Josef Zlomek 于2020年7月27日周一 下午6:57写道：
On Mon, Jul 27, 2020 at 1:46 PM Michael Niedermayer
wrote:
>
> On Mon, Jul 27, 2020 at 09:55:31AM +0530, Gautam Ramakrishnan wrote:
> > On Mon, Jul 27, 2020 at 9:48 AM Gautam Ramakrishnan
> > wrote:
> > >
> > > On Mon, Jul 27, 2020 at 3:16 AM Michael Niedermayer
> > > wrote:
> > > >
> > > > Fixe
If your code is correct then good.
I also resubmit improved version.
Josef
On Mon, Jul 27, 2020 at 2:05 PM Steven Liu wrote:
> Zlomek, Josef 于2020年7月27日周一 下午7:45写道：
> >
> > Hi Steven,
> >
> > ".." is always a directory.
> >
> > your tests (diff starting with -) are not correct.
> > My results
Fixes: 8814
The logic for removing ".." path components and their corresponding
upper directories was reworked.
Now, the function trim_double_dot_url splits the path by "/" into
components, and processes the components one ny one:
- if the component is "..", the last path component in tmp_path is
Signed-off-by: Josef Zlomek
---
libavformat/tests/url.c | 6 ++
tests/ref/fate/url | 6 ++
2 files changed, 12 insertions(+)
diff --git a/libavformat/tests/url.c b/libavformat/tests/url.c
index 1d961a1b43..a27a875892 100644
--- a/libavformat/tests/url.c
+++ b/libavformat/tests/url.c
Thanks Olivier,
Custom IO looks like a nice way to work around the protocol
limitations. Unfortunately, it cannot work with avio_open(), so the
API becomes trickier for end users.
Also, just like with pipes, I cannot reliably close the file
descriptor when ffmpeg execution is over, can I?
BR,
Al
use two buffer for storage the path and node of URI
remove the last node of the path if the next node is ..
change the static strings to dynamic alloc space by size argument.
Signed-off-by: Steven Liu
---
libavformat/url.c | 83 ---
1 file changed, 64
Signed-off-by: Steven Liu
---
libavformat/tests/url.c | 14 ++
tests/ref/fate/url | 12
2 files changed, 26 insertions(+)
diff --git a/libavformat/tests/url.c b/libavformat/tests/url.c
index 1d961a1b43..0de511caf9 100644
--- a/libavformat/tests/url.c
+++ b/libavform
Josef Zlomek 于2020年7月27日周一 下午8:15写道：
>
> Fixes: 8814
>
> The logic for removing ".." path components and their corresponding
> upper directories was reworked.
>
> Now, the function trim_double_dot_url splits the path by "/" into
> components, and processes the components one ny one:
> - if the com
You're welcome.
Can I suggest you to try IContainer.open with InputStream/OutputStream. If
you use a FileInputStream created from the file descriptor retrieved with
https://developer.android.com/reference/android/content/Intent#ACTION_OPEN_DOCUMENT
Normally fd will be automatically closed by the s
Steven Liu (12020-07-27):
> use two buffer for storage the path and node of URI
> remove the last node of the path if the next node is ..
> change the static strings to dynamic alloc space by size argument.
?!?!??!!!?
Why do you think you need extra buffers?
This patch turns a rather straightfor
Steven Liu (12020-07-27):
> What about use av_malloc? or bprint?
> I think use av_malloc maybe easter to me.
For internal APIs, definitely BPrint over naive av_malloc(). But this is
unrelated to the issue at hand: the size limit exists in the caller of
this function, not in this function.
Regards
Generally, this seems to be too complicated with too much of copying.
On Mon, Jul 27, 2020 at 3:08 PM Steven Liu wrote:
> use two buffer for storage the path and node of URI
> remove the last node of the path if the next node is ..
> change the static strings to dynamic alloc space by size argum
This does not work for the following testcases, + lines are invalid:
+test("/foo/bar", "..");
+test("/foo/bar/baz", "..");
- /foo/bar .. =>
/
- /foo/bar/baz .. =>
/foo/
+
On Fri, Jul 24, 2020 at 11:09 PM Mohammad Izadi <
izadi-at-google@ffmpeg.org> wrote:
> On Fri, Jul 24, 2020 at 9:30 AM Andreas Rheinhardt <
> andreas.rheinha...@gmail.com> wrote:
>
> > Mohammad Izadi:
> > > From: Mohammad Izadi
> > >
> > > HDR10+ is dynamic metadata (A/341 Amendment - SMPTE20
On 27/07/2020 00:55, Satyajit Sahu wrote:
Hi,
I am facing issue with cropping parameters while transcoding. The cropping
parameters are ignored if both the way vaapi hw acceleration is used (for
decoding and encoding). But if sw decoding is used the cropping parameters
are working fine.
For
On 24/07/2020 08:29, Haihao Xiang wrote:
---
libavutil/hwcontext_vaapi.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index fb9be19647..a4dfaba92c 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwco
Yes, I would definitely be glad to join forces.
That's true that the fd will be closed with the stream, or when the
owning ParcelFileDescritpor is closed. But what decides when the
stream/ParcelFileDescritpor can be closed? With `file:` protocol, it's
very natural that avformat closes the fd when
When you close IContainer with InputStream. It will be automatically close.
You can see Implementation here
https://github.com/olivierayache/xuggle-xuggler/blob/ffmpeg-3.x-dev/src/com/xuggle/xuggler/io/InputOutputStreamHandler.java
For the JNI overhead it must be measured but normally by working w
On 05/07/2020 16:49, Mark Thompson wrote:
---
libavdevice/kmsgrab.c | 151 ++
1 file changed, 93 insertions(+), 58 deletions(-)
Ping set.
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 24/07/2020 03:39, Haihao Xiang wrote:
hwcontext_vaapi maps different VA fourcc to the same pix_fmt for U/V
plane swap cases, however duplicate formats are not expected in sw_format
list when merging formats.
For example:
ffmpeg -loglevel debug -init_hw_device vaapi -filter_hw_device vaapi0 \
Mostly a rebase and update - not much has changed since the previous version in
May.
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpe
---
libavcodec/cbs.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/cbs.h b/libavcodec/cbs.h
index e897e348a2..07faf18c5b 100644
--- a/libavcodec/cbs.h
+++ b/libavcodec/cbs.h
@@ -45,8 +45,10 @@ struct CodedBitstreamType;
/**
* The codec-specific type of a bitstream unit.
*
+
Unit types are split into three categories, depending on how their
content is managed:
* POD structure - these require no special treatment.
* Structure containing references to refcounted buffers - these can use
a common free function when the offsets of all the internal references
are known.
Having these together allows us to find both pointers given the address
of only one of them.
---
libavcodec/cbs_av1.h | 6 +++---
libavcodec/cbs_h264.h | 18 +-
libavcodec/cbs_h265.h | 16
libavcodec/cbs_jpeg.h | 2 +-
libavcodec/cbs_mpeg2.h | 10 +-
---
libavcodec/cbs_internal.h | 24
1 file changed, 24 insertions(+)
diff --git a/libavcodec/cbs_internal.h b/libavcodec/cbs_internal.h
index 282492bc88..35159f9c5f 100644
--- a/libavcodec/cbs_internal.h
+++ b/libavcodec/cbs_internal.h
@@ -167,6 +167,30 @@ int ff_cbs_writ
---
libavcodec/cbs_h2645.c | 198 +++--
1 file changed, 93 insertions(+), 105 deletions(-)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index e19fa5249d..b9233f4df7 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -454,72 +454
---
libavcodec/cbs_h2645.c | 163 ++---
1 file changed, 70 insertions(+), 93 deletions(-)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index e5c8012d39..5725539e60 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -454,52 +454,
From: Andreas Rheinhardt
Since c6a63e11092c975b89d824f08682fe31948d3686, the parameter sets
modified as content of PPS units were references shared with the
CodedBitstreamH264Context, so modifying them alters the parsing process
of future access units which meant that frames often got discarded
b
Use the unit type table to determine what we need to do to clone the
internals of the unit content when making copies for refcounting or
writeability. (This will still fail for units with complex content
if they do not have a defined clone function.)
Setup and naming from a patch by Andreas Rhein
---
libavcodec/cbs_mpeg2.c | 70 +-
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index 8b6e5a9852..26400f279f 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -140,28 +140,
Only copying the main structure is not necessarily sufficient - there
could be references to substructures.
---
libavcodec/cbs_h2645.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 5725539e60..e19fa5249d 100644
---
libavcodec/cbs_vp9.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/libavcodec/cbs_vp9.c b/libavcodec/cbs_vp9.c
index 6e0a7dcbea..6a480b4ce3 100644
--- a/libavcodec/cbs_vp9.c
+++ b/libavcodec/cbs_vp9.c
@@ -479,13 +479,6 @@ static int cbs_vp9_split_fragmen
---
libavcodec/cbs_av1.c | 85
1 file changed, 39 insertions(+), 46 deletions(-)
diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
index 75e9cb78df..dd2bc83bd4 100644
--- a/libavcodec/cbs_av1.c
+++ b/libavcodec/cbs_av1.c
@@ -809,50 +809,6 @@ fai
At the same time, move the H.264 SEI functions to a new file - the combined
H.26[45] CBS file is already very large, and these functions do not require
any of the common read/write elements.
---
libavcodec/Makefile| 2 +-
libavcodec/cbs_h264.c | 108 +
---
libavcodec/cbs_h264.c | 47 +++
libavcodec/cbs_h264.h | 8
2 files changed, 55 insertions(+)
diff --git a/libavcodec/cbs_h264.c b/libavcodec/cbs_h264.c
index c86c6d565c..a128745799 100644
--- a/libavcodec/cbs_h264.c
+++ b/libavcodec/cbs_h264.c
---
libavcodec/cbs_h264.h | 24
libavcodec/cbs_h2645.c| 1 +
libavcodec/cbs_h264_syntax_template.c | 40 +++
3 files changed, 65 insertions(+)
diff --git a/libavcodec/cbs_h264.h b/libavcodec/cbs_h264.h
index 88313629f5..ca7
Insert frame packing arrangement messages into the stream when input
frames have associated stereo 3D side-data.
---
doc/encoders.texi | 3 +++
libavcodec/vaapi_encode.h | 1 +
libavcodec/vaapi_encode_h264.c | 24 +++-
3 files changed, 27 insertions(+), 1 de
This was in two disjoint parts in the H.264 and H.265 files. Unify them in
the header to avoid any confusion, because they are really the same enum.
---
libavcodec/vaapi_encode.h | 10 ++
libavcodec/vaapi_encode_h264.c | 6 --
libavcodec/vaapi_encode_h265.c | 5 -
3 files c
This will be helpful when adding new SEI to an existing access unit.
---
libavcodec/cbs.c | 8
libavcodec/cbs.h | 6 ++
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index 7c1aa005c2..6677442d10 100644
--- a/libavcodec/cbs.c
+++ b/
---
libavcodec/h264_metadata_bsf.c | 443 ++---
1 file changed, 242 insertions(+), 201 deletions(-)
diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index eb1503159b..1d00ccdfb8 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h2
---
libavcodec/Makefile | 2 +-
libavcodec/cbs_h265.c | 100 ++
libavcodec/cbs_h265.h | 18
3 files changed, 119 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/cbs_h265.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
inde
The previous code here only worked in more limited cases.
---
libavcodec/h264_metadata_bsf.c | 42 +++---
1 file changed, 29 insertions(+), 13 deletions(-)
diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index 1d00ccdfb8..38c9e7f6f5 100644
---
libavcodec/vaapi_encode_h265.c | 45 +-
1 file changed, 6 insertions(+), 39 deletions(-)
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 90fea83388..f996f78f8e 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi
On Mon, 27 Jul 2020 at 11:09, Anton Khirnov wrote:
> Quoting Kieran Kunhya (2020-07-26 01:51:22)
> > Hi,
> >
> > I notice that some encoders adjust the PTS with initial_padding and some
> > don't.
> > Is this intentional and should we decide that all encoders should do
> this?
>
> Which ones don'
On Mon, 27 Jul 2020, Steven Liu wrote:
Marton Balint 于2020年7月25日周六 下午5:40写道：
On Sat, 25 Jul 2020, Zlomek, Josef wrote:
> Hi Steven,
>
> It is better but still not correct. Consider this test:
>
> test("http://server/foo/bar";,
> "a/b/../c/d/../e../.../..f/g../h../other/url/a.mp3/...");
>
Signed-off-by: James Almer
---
Should prevent regressions like the one fixed in 5ce47d0aad
libavutil/tests/imgutils.c | 38
tests/ref/fate/imgutils| 183 +
2 files changed, 221 insertions(+)
diff --git a/libavutil/tests/imgutils.c b/libavutil/tes
On Sat, 25 Jul 2020, Nicolas George wrote:
Marton Balint (12020-07-25):
And I also would like to point out that using static strings with
MAX_URL_SIZE is not OK. This function supports an arbitrary buffer size, so
limiting it to MAX_URL_SIZE is a bug.
Excellent point. That would require cha
On Sat, 18 Jul 2020, Marton Balint wrote:
Threaded input can increase smoothness of e.g. x11grab significantly. Before
this patch, in order to activate threaded input the user had to specify a
"dummy" additional input, with this change it is no longer required.
Ping, will apply soon.
Regard
On Sun, 19 Jul 2020, Marton Balint wrote:
On Sun, 19 Jul 2020, Steven Liu wrote:
Zhao Zhili 于2020年7月19日周日 下午6:26写道：
> On Jul 19, 2020, at 5:20 PM, Steven Liu wrote:
>
> Marton Balint 于2020年7月19日周日 上午6:04写道：
>>
>> Also query time only once, not for every variant stream, otherwise
v
Steven Liu (12020-07-27):
> Because language barries. maybe I cannot deep understand, maybe need
> more code examples.
> But look interesting, maybe more easy for use.
All right, here is a practical albeit fictional example.
Let us say we want av_metadata_to_user_string() that turns an
AVDictiona
Marton Balint (12020-07-27):
> If I understand correctly, you are speaking about URL handling in general
> all over the codebase, and not only ff_make_absolute_url.
I thought that was what you were speaking in the first place.
ff_make_absolute_url() only does what the caller wants, the caller
deci
It seems FATE is for the regression test. Here is a sample that you can use
and check:
https://www.dropbox.com/s/3ewr2t2lvv2cy8d/20200727_143643.mp4?dl=0
Thanks,
Mohammad
On Mon, Jul 27, 2020 at 7:53 AM Vittorio Giovara
wrote:
> On Fri, Jul 24, 2020 at 11:09 PM Mohammad Izadi <
> izadi-at-go
On 19/07/2020 08:00, Linjie Fu wrote:
On Thu, Jun 18, 2020 at 1:36 PM Linjie Fu wrote:
On Tue, May 12, 2020 at 9:49 PM Linjie Fu wrote:
VA_ENC_SLICE_STRUCTURE_EQUAL_MULTI_ROWS is added to in the latest
libva (1.8.0) which matches the hardware behaviour:
/** \brief Driver supports any numbe
On Sat, 25 Jul 2020, at 13:03, Nicolas George wrote:
> And that's all. Everything is taken care of: the string will grow as
> needed, the size will be tracked, error checks are made. Nothing to
> worry about at all.
How is that different from open_memstream, which is done for this exact purpose?
Marton Balint 于2020年7月28日周二 上午4:15写道：
>
>
>
> On Sun, 19 Jul 2020, Marton Balint wrote:
>
> >
> >
> > On Sun, 19 Jul 2020, Steven Liu wrote:
> >
> >> Zhao Zhili 于2020年7月19日周日 下午6:26写道：
> >>>
> >>>
> >>>
> >>> > On Jul 19, 2020, at 5:20 PM, Steven Liu wrote:
> >>> >
> >>> > Marton Balint 于2020年7
Josef Zlomek 于2020年7月27日周一 下午8:15写道：
>
> Signed-off-by: Josef Zlomek
> ---
> libavformat/tests/url.c | 6 ++
> tests/ref/fate/url | 6 ++
> 2 files changed, 12 insertions(+)
>
> diff --git a/libavformat/tests/url.c b/libavformat/tests/url.c
> index 1d961a1b43..a27a875892 100644
> --
On Mon, Jul 27, 2020 at 7:37 PM myp...@gmail.com wrote:
>
> On Sat, Jul 18, 2020 at 8:31 PM myp...@gmail.com wrote:
> >
> > On Thu, Jul 16, 2020 at 9:35 AM myp...@gmail.com wrote:
> > >
> > > On Tue, Jul 14, 2020 at 9:47 PM Moritz Barsnick wrote:
> > > >
> > > > On Sun, Jul 12, 2020 at 22:44:46
On Mon, Jul 27, 2020 at 8:57 PM Marton Balint wrote:
> It should be implemented in a way which does not use a temporary buffer.
> Seems doable.
>
You are right. I will submit a new version.
Best regards,
Josef
___
ffmpeg-devel mailing list
ffmpeg-deve
Fixes: 8814
The logic for removing ".." path components and their corresponding
upper directories was reworked.
Now, the function trim_double_dot_url splits the path by "/" into
components, and processes the components one ny one:
- if the component is "..", the last path component in output buff
added test cases
Signed-off-by: Josef Zlomek
---
libavformat/tests/url.c | 11 ++-
tests/ref/fate/url | 9 +
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/libavformat/tests/url.c b/libavformat/tests/url.c
index 1d961a1b43..029be6ff10 100644
--- a/libavforma
86 matches
Mail list logo
