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
---
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
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
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
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
>
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
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
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
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 <
>
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
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
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
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.
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
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
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/...");
>
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
---
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
+++
---
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
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/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
+++
---
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
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
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
+++
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
---
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
+++
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_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
---
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 @@
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
---
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
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
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
---
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
---
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
---
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
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 +-
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.
---
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.
*
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
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 \
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
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
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
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
+++
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.
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 -
This does not work for the following testcases, + lines are invalid:
+test("/foo/bar", "..");
+test("/foo/bar/baz", "..");
- /foo/bar .. =>
/
- /foo/bar/baz .. =>
/foo/
+
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
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.
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
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
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
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
+++
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
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,
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
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
+++
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
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:
> > > >
> > > >
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日周一
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
> > ---
> >
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
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 ".."
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
> +++
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
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
@@
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
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
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
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
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
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
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
---
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
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
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
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
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:
> > >
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
在 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
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
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
于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
> +++
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 "
> >
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
Make sure this does not break demuxing/decoding.
On 7/27/20, Andreas Rheinhardt wrote:
> Avoids an avio_skip(s->pb, 0).
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/3dostr.c | 13 -
> 1 file changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/libavformat/3dostr.c
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/libxavs2.c
@@ -223,6 +223,12 @@ static int
88 matches
Mail list logo
