On Wed, 2018-05-09 at 14:00 +0200, Jerome Borsboom wrote:
> > > Contrary to VC-1 spec, VAAPI expects the row address of the first
> > > macroblock row in the first slice to start from zero for the second
> > > field in a field interlaced picture.
> > >
> > > Signed-off-by: Jerome Borsboom
> > > -
> 2018-05-08 15:11 GMT+02:00, Anton Leontiev :
>> Formats ARGB32, XRGB32, ABGR32, and XBGR32 were added to
>> V4L2 instead of ill-defined deprecated RGB32/BGR32 pixel formats.
>
> Just curious because I am quite sure I tested them:
> Why / how are they ill-defined?
According to [1-2]:
The meani
Lets skip a testcase. It will be not easy to me to prepare it.
Regards,
*Łukasz Krzciuk*
Developer
Vewd
ul. Grabarska 2, Pegaz 2A, 50-079 Wrocław, Polska
On Thu, May 10, 2018 at 3:09 AM, Michael Niedermayer wrote:
> On Wed, May 09, 2018 at 10:19:26AM +0200, Łukasz Krzciuk wrote:
> > Any upda
Am 10.05.2018 um 04:51 schrieb Wang Bin:
-offset += cpy.Height;
+frame->buf[1] = av_buffer_create((uint8_t *)unmap_data,
sizeof(*unmap_data),
+ nvdec_unmap_mapped_frame,
(void*)devptr,
+ AV_BUFFER_FLAG_READONLY
Am 10.05.2018 um 03:48 schrieb Philip Langdale:
The main issue here was the use of [i] instead of [i * 3] for the 32x32
matrix. As part of fixing this, I changed the code to match that used
in vdpau_hevc, which I spent a lot of time verifying.
I also changed to calculating NumPocTotalCurr usin
---
libavcodec/hevc_refs.c | 4 ++--
libavcodec/hevcdec.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
index 68c730edcc..7cf3a55725 100644
--- a/libavcodec/hevc_refs.c
+++ b/libavcodec/hevc_refs.c
@@ -508,12 +508,12 @@ fai
On Thu, 10 May 2018 12:23:01 +0200
Timo Rothenpieler wrote:
> ---
> libavcodec/hevc_refs.c | 4 ++--
> libavcodec/hevcdec.h | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
> index 68c730edcc..7cf3a55725 100644
> --- a
On Thu, 10 May 2018 12:18:13 +0200
Timo Rothenpieler wrote:
> Am 10.05.2018 um 03:48 schrieb Philip Langdale:
> > The main issue here was the use of [i] instead of [i * 3] for the
> > 32x32 matrix. As part of fixing this, I changed the code to match
> > that used in vdpau_hevc, which I spent a lo
On Thu, 10 May 2018 01:24:42 +0200
Jorge Ramirez-Ortiz wrote:
> On 05/09/2018 04:11 PM, Mark Thompson wrote:
> > On 09/05/18 08:57, Jorge Ramirez-Ortiz wrote:
> >> On 05/09/2018 01:33 AM, Mark Thompson wrote:
> >>> diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
> >>> index
On Sun, May 6, 2018 at 11:16 PM, Michael Niedermayer
wrote:
> On Sun, May 06, 2018 at 06:55:01PM +0300, Jan Ekström wrote:
>> Thanks, pushed. This should be back-ported to release/4.0 I guess?
>
> probably yes
>
> thanks
>
Finally got the time, cherry-pick -x'd and pushed to release/4.0.
Jan
___
Formats ARGB32, XRGB32, ABGR32, and XBGR32 were added to V4L2 instead
of ill-defined deprecated RGB32/BGR32 pixel formats.
When pixel format is not specified explicitly FFmpeg tries formats in
order in which they are stored in the table. Therefore formats are
sorted as follows: BGR is preferred ov
This patchset contains a version that is more flexible than the previous
iteration.
To become independent of the specific http server implementation used I
added an interface that http server implementations have to provide. As
mentioned for the time being this is still the libavformat http server
Signed-off-by: Stephan Holljes
---
segment.c | 167 ++
segment.h | 114 ++
2 files changed, 281 insertions(+)
create mode 100644 segment.c
create mode 100644 segment.h
diff --git a/segment.c b/s
Signed-off-by: Stephan Holljes
---
publisher.c | 306
publisher.h | 171 +
2 files changed, 477 insertions(+)
create mode 100644 publisher.c
create mode 100644 publisher.h
diff --git a/publisher.c b/pu
Signed-off-by: Stephan Holljes
---
Makefile | 18 +++
ffserver.c | 514 +
2 files changed, 532 insertions(+)
create mode 100644 Makefile
create mode 100644 ffserver.c
diff --git a/Makefile b/Makefile
new file mode 100644
index
Signed-off-by: Stephan Holljes
---
httpd.h | 58 +++
lavfhttpd.c | 150
2 files changed, 208 insertions(+)
create mode 100644 httpd.h
create mode 100644 lavfhttpd.c
diff --git a/httpd.h b/httpd.h
new file mod
Signed-off-by: Stephan Holljes
---
Documentation.txt | 84 +++
1 file changed, 84 insertions(+)
create mode 100644 Documentation.txt
diff --git a/Documentation.txt b/Documentation.txt
new file mode 100644
index 000..5b52c89
--- /dev/null
+
These demuxers have probes that mainly probe based on file extension,
and map to codec IDs that render text as video. The result is that
ffmpeg will, by default, happily render, for example, .txt files
as images. This is not exactly a good security practice, an only
makes it easier for potential at
On 5/10/18, Derek Buitenhuis wrote:
> These demuxers have probes that mainly probe based on file extension,
> and map to codec IDs that render text as video. The result is that
> ffmpeg will, by default, happily render, for example, .txt files
> as images. This is not exactly a good security pract
On 10 May 2018 at 16:44, Derek Buitenhuis
wrote:
> These demuxers have probes that mainly probe based on file extension,
> and map to codec IDs that render text as video. The result is that
> ffmpeg will, by default, happily render, for example, .txt files
> as images. This is not exactly a good
On Thu, May 10, 2018 at 6:53 PM, Paul B Mahol wrote:
>
> Against.
Hi,
Thank you for your review.
I would recommend you put a bit more effort into explaining which
parts you are opposed to. Think of yourself being on the receiving end
of such comments, how you would like to just get a flat out r
On 5/10/18, Jan Ekstroem wrote:
> On Thu, May 10, 2018 at 6:53 PM, Paul B Mahol wrote:
>>
>> Against.
>
> Hi,
>
> Thank you for your review.
>
> I would recommend you put a bit more effort into explaining which
> parts you are opposed to. Think of yourself being on the receiving end
> of such com
On Thu, May 10, 2018 at 4:55 PM, Rostislav Pehlivanov
wrote:
> Could you send a patch to disable the decoders as well?
> Looks good otherwise.
Yeah, I thought about doing that too. I can add that, though the option
will have to be renamed to something else.
- Derek
__
On Thu, May 10, 2018 at 5:11 PM, Paul B Mahol wrote:
> I do not like it being disabled by default.
With all due respect, this is not a valid technical argument, in any respect.
> There are options to disable compilation of such modules already.
We should be defaulting to 'safe/sane by default'.
applied and backported to 4.0
smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
applied and backported to 4.0
smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Just want to update,
We compiled master branch with this patches, tested and looked at NSIGHT.
Everything correct:
- The internal NVDEC kernel is using the stream we have set in
AVCUDADeviceContext struct.
- It slightly overlaps with other kernels, removing wait times between kernel
executions
On Thu, 10 May 2018, Derek Buitenhuis wrote:
These demuxers have probes that mainly probe based on file extension,
and map to codec IDs that render text as video. The result is that
ffmpeg will, by default, happily render, for example, .txt files
as images. This is not exactly a good security p
On 5/10/2018 11:17 PM, Marton Balint wrote:
Maybe it is better if we simply get rid of the "probing" part, so the
user would have to explicitly specify the demuxer to use them.
+1
Maybe shift such probes to inside a block and add a new generic lavf
option to set whether such probes are en
On Thu, May 10, 2018 at 1:46 AM Łukasz Krzciuk wrote:
> Lets skip a testcase. It will be not easy to me to prepare it.
It should be simple to extract a small sample containing the PMT. If you
link some larger samples I can help extract the relevant bytes for test
case.
Aman
>
> Regards,
>
>
On 10/05/18 04:08, Haihao Xiang wrote:
> The flag of input_available must be set when pic_start is not NULL, so
> add an assert to ensure it is true. In addition, the assert on last_pic
> is unnecessary now, so remove this assert.
>
> Signed-off-by: Haihao Xiang
> ---
> libavcodec/vaapi_encode.c
On Thu, May 10, 2018 at 6:52 PM, Gyan Doshi wrote:
> On 5/10/2018 11:17 PM, Marton Balint wrote:
>> Maybe it is better if we simply get rid of the "probing" part, so the user
>> would have to explicitly specify the demuxer to use them.
>
> +1
>
> Maybe shift such probes to inside a block and add a
On Wed, May 09, 2018 at 02:35:00PM -0700, Aman Gupta wrote:
> From: Aman Gupta
>
> Fixes PMT parsing in some mpegts streams which contain
> multiple tables within the PMT pid. Previously, the parser
> assumed only one table was present in each packet, and discarded
> the rest of the section data
On 10/05/18 06:47, Haihao Xiang wrote:
> Similar to H264, cbs_h265_{read, write}_nal_unit() can handle HEVC
> prefix SEI NAL units. Currently mastering display colour volume SEI
> message is added only, we may add more SEI message if needed later
>
> v2: Fix coding style and rebase the code
>
> v
On 05/10/2018 04:47 PM, wm4 wrote:
so what would be the sequence of calls for an libavcodec client to
request the DRM format?
https://github.com/BayLibre/ffmpeg-drm/blob/master/main.c#L598
Like in 100% of all existing cases in ffmpeg: set a get_format
callback, and return the format from it.
S
tis 2018-05-08 klockan 18:32 +0200 skrev Thomas Mundt:
> 2018-05-07 10:40 GMT+02:00 Tomas Härdin :
>
> > sön 2018-05-06 klockan 21:31 +0200 skrev Thomas Mundt:
> > > 2018-05-06 13:32 GMT+02:00 Tomas Härdin :
> > >
> > > > fre 2018-05-04 klockan 01:52 +0200 skrev Thomas Mundt:
> > > > > Hi,
> > >
On Thu, May 10, 2018 at 04:44:59PM +0100, Derek Buitenhuis wrote:
> These demuxers have probes that mainly probe based on file extension,
> and map to codec IDs that render text as video. The result is that
> ffmpeg will, by default, happily render, for example, .txt files
> as images. This is not
tis 2018-05-08 klockan 18:26 +0200 skrev Michael Niedermayer:
> On Tue, May 08, 2018 at 12:40:49PM +0200, Tomas Härdin wrote:
> > mån 2018-05-07 klockan 12:38 +0200 skrev Michael Niedermayer:
> > > > Signed-off-by: Michael Niedermayer
> > >
> > > +if (sc->interlaced) {
> > > +//Displa
On 08/05/18 12:00, Alexander Kravchenko wrote:
> This patch moves AMF common parts from amfenc to hwcontext_amf.
> Now av_hwdevice_ctx API is used for AMF context creation/destroying.
> This patch does not change component behaviour.
> it contains only restructurization for further patches with new
tor 2018-05-10 klockan 22:44 +0200 skrev Tomas Härdin:
> tis 2018-05-08 klockan 18:32 +0200 skrev Thomas Mundt:
> > 2018-05-07 10:40 GMT+02:00 Tomas Härdin :
> >
> > > sön 2018-05-06 klockan 21:31 +0200 skrev Thomas Mundt:
> > > > 2018-05-06 13:32 GMT+02:00 Tomas Härdin :
> > > >
> > > > > fre 20
2018-05-10 22:44 GMT+02:00, Tomas Härdin :
> Could you attach a patch that applies cleanly? I tried to git am it on
> commit 0612e29 but not luck
Because it was applied as a3a6d4da6
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http:
Hi!
Peter Bubestinger provided a C210 file where every frame starts with
64 bytes of extradata (24 byte "INFO", 16 byte "RDRT", rest "FIEL").
Piotr confirmed that the Canopus decoder accepts files without the
extradata but consumes it if present.
Attached patch fixes the file in question visually.
On Wed, May 09, 2018 at 08:44:25PM +0200, Ramiro Polla wrote:
> This option prevents the mpv encoders from using intra macroblocks in
> predictive frames.
>
> It is useful for glitch artists to generate input material. This option
> allows them to split and merge two video files while maintaining
On Wed, May 09, 2018 at 12:05:48PM +0200, Tobias Rapp wrote:
> Adds tests for the hue angle and brightness filter parameters.
> Renames the existing saturation parameter test for consistency.
>
> Signed-off-by: Tobias Rapp
> ---
> tests/fate/filter-video.mak | 10 --
> tests/ref/fate/fil
2018-05-10 17:44 GMT+02:00, Derek Buitenhuis :
> These demuxers have probes that mainly probe based on file extension,
> and map to codec IDs that render text as video. The result is that
> ffmpeg will, by default, happily render, for example, .txt files
> as images. This is not exactly a good secu
2018-05-05 2:26 GMT+02:00, Carl Eugen Hoyos :
> Attached patch fixes ticket #6195 for me.
Patch applied.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 2018-05-10 17:44, Derek Buitenhuis wrote:
> These demuxers have probes that mainly probe based on file extension,
> and map to codec IDs that render text as video. The result is that
> ffmpeg will, by default, happily render, for example, .txt files
> as images. This is not exactly a good securi
On Thu, May 10, 2018 at 10:48:59PM +0200, Tomas Härdin wrote:
> tis 2018-05-08 klockan 18:26 +0200 skrev Michael Niedermayer:
> > On Tue, May 08, 2018 at 12:40:49PM +0200, Tomas Härdin wrote:
> > > mån 2018-05-07 klockan 12:38 +0200 skrev Michael Niedermayer:
> > > > > Signed-off-by: Michael Nieder
On Thu, 10 May 2018 16:44:59 +0100
Derek Buitenhuis wrote:
> These demuxers have probes that mainly probe based on file extension,
> and map to codec IDs that render text as video. The result is that
> ffmpeg will, by default, happily render, for example, .txt files
> as images. This is not exact
On 5/11/18, wm4 wrote:
> On Thu, 10 May 2018 16:44:59 +0100
> Derek Buitenhuis wrote:
>
>> These demuxers have probes that mainly probe based on file extension,
>> and map to codec IDs that render text as video. The result is that
>> ffmpeg will, by default, happily render, for example, .txt file
On Thu, May 3, 2018 at 10:58 AM, Jan Ekström wrote:
>
> On Thu, May 3, 2018 at 7:50 PM, Alex Converse wrote:
> > From: Alex Converse
> >
> > ---
> > libavformat/flvenc.c | 10 +-
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavformat/flvenc.c b/libavformat/
On Fri, May 4, 2018 at 7:11 AM, Josh de Kock wrote:
>
>> On 4 May 2018, at 12:26, Michael Niedermayer wrote:
>>
>>> On Fri, May 04, 2018 at 11:03:20AM +0800, Steven Liu wrote:
>>>
>>>
On 4 May 2018, at 02:00, Jan Ekström wrote:
On Thu, May 3, 2018 at 8:58 PM, Jan Ekström wrote:
>
> You web people already have options for the various annoying whitelists.
> Is this not covered by one of them?
As noted in my other reply to Paul, I find it a poor choice to shunt
the responsibility
of good/secure defaults to the user.
As a side note, derisively referring to me as "you web peo
On 09/05/18 23:51, James Almer wrote:
> On 5/7/2018 9:30 PM, Mark Thompson wrote:
>> On 08/05/18 01:06, James Almer wrote:
>>> On 5/7/2018 8:11 PM, Mark Thompson wrote:
The artificial sample file sei-1.h264 contains five frames (IDR P B I B)
and the following SEI message types:
* Buf
> Disabling demuxers by default does not seem to be a good idea to me.
So rendering arbitrary text files by default seems like a good idea in
comparsion?
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ff
On 5/11/18, Derek Buitenhuis wrote:
>> Disabling demuxers by default does not seem to be a good idea to me.
>
> So rendering arbitrary text files by default seems like a good idea in
> comparsion?
That is useful feature.
___
ffmpeg-devel mailing list
ff
On Fri, May 11, 2018 at 1:39 AM, Alex Converse wrote:
> On Thu, May 3, 2018 at 10:58 AM, Jan Ekström wrote:
>>
>> Hi,
>>
>> While the timestamp field is 8+24=32 bits, the DTS value is int64_ts.
>> Thus, while I'm really bad at doing wrap-around logic, wouldn't it be
>> something a la ´uint32_t wr
> please correct me if iam wrong, theres quite a bit iam guessing here
> IIUC the problem is that in your usecase
> 1. ffmpeg has access to sensitive files
> 2. one of these files can be opened by an attacker with ffmpeg
> 2b. This involves the file being probed as a supported format
It is "probed
On Fri, May 11, 2018 at 1:48 AM, Alex Converse wrote:
>
> Sorry about the lateness on my part. Were there any later comments. I
> haven't seen any. (And yes I can push this myself when all the
> concerns are resolved).
It's OK, it has been a rather busy time for me as well.
I was already thinkin
On 10 May 2018 at 23:27, Paul B Mahol wrote:
> On 5/11/18, wm4 wrote:
> > On Thu, 10 May 2018 16:44:59 +0100
> > Derek Buitenhuis wrote:
> >
> >> These demuxers have probes that mainly probe based on file extension,
> >> and map to codec IDs that render text as video. The result is that
> >> ff
On 5/11/18, Derek Buitenhuis wrote:
>> please correct me if iam wrong, theres quite a bit iam guessing here
>> IIUC the problem is that in your usecase
>> 1. ffmpeg has access to sensitive files
>> 2. one of these files can be opened by an attacker with ffmpeg
>> 2b. This involves the file being p
> If you think you are fixing security issue you are very wrong.
You've nailed that "saying what you think" part of communication, but
need to word a little
on the all important "saying why you think that" part. Keep
practicing, you can do it. I
believe in you.
- Derek
___
On 11 May 2018 at 00:04, Paul B Mahol wrote:
> On 5/11/18, Derek Buitenhuis wrote:
> >> Disabling demuxers by default does not seem to be a good idea to me.
> >
> > So rendering arbitrary text files by default seems like a good idea in
> > comparsion?
>
> That is useful feature.
> __
On 5/11/18, Derek Buitenhuis wrote:
>> If you think you are fixing security issue you are very wrong.
>
> You've nailed that "saying what you think" part of communication, but
> need to word a little
> on the all important "saying why you think that" part. Keep
> practicing, you can do it. I
> bel
On Fri, 11 May 2018 00:21:37 +0100
Rostislav Pehlivanov wrote:
> On 10 May 2018 at 23:27, Paul B Mahol wrote:
>
> > On 5/11/18, wm4 wrote:
> > > On Thu, 10 May 2018 16:44:59 +0100
> > > Derek Buitenhuis wrote:
> > >
> > >> These demuxers have probes that mainly probe based on file extensi
On Fri, May 11, 2018 at 12:35 AM, Paul B Mahol wrote:
> I do not have time to explain security basics.
> Get a decent book and read it from a start to an end.
Speaking frankly for a second: Why do people put up with this sort of
crud on this
mailing list?
Insult-laden fact-less response. It's in
On Fri, May 11, 2018 at 12:41 AM, Derek Buitenhuis
wrote:
> Speaking frankly for a second: Why do people put up with this sort of
> crud on this
> mailing list?
Unrelatedly, sorry for the broken linebreaks. Bad MUA...
- Derek
___
ffmpeg-devel mailing l
On Fri, 11 May 2018 00:41:20 +0100
Derek Buitenhuis wrote:
> On Fri, May 11, 2018 at 12:35 AM, Paul B Mahol wrote:
> > I do not have time to explain security basics.
> > Get a decent book and read it from a start to an end.
>
> Speaking frankly for a second: Why do people put up with this sor
On Fri, May 11, 2018 at 12:36 AM, wm4 wrote:
> Experience shows that it's always the obscure features which cause
> security issues. Regarding the bloat: these small things add up a lot,
> and suddenly you have hundreds of demuxers. It's hard to filter them
> out manually, and why make each user d
On 2018-05-11 00:57, Derek Buitenhuis wrote:
>> Disabling demuxers by default does not seem to be a good idea to me.
>
> So rendering arbitrary text files by default seems like a good idea in
> comparsion?
I want to argue some more so here you go: it isn't "by default".
It gets rendered because
On Wed, May 09, 2018 at 07:23:35PM -0700, Aman Gupta wrote:
> From: Aman Gupta
>
> This allows remuxing streams from one mpegts container to another,
> without requiring avformat_find_stream_info() (or using `ffmpeg
> -probesize 32` on the cli).
> ---
> libavformat/mpegtsenc.c | 2 +-
> 1 file c
On 11 May 2018 at 00:44, wm4 wrote:
> On Fri, 11 May 2018 00:41:20 +0100
> Derek Buitenhuis wrote:
>
> > On Fri, May 11, 2018 at 12:35 AM, Paul B Mahol wrote:
> > > I do not have time to explain security basics.
> > > Get a decent book and read it from a start to an end.
> >
> > Speaking frankl
On Fri, 11 May 2018 00:53:16 +0100
Rostislav Pehlivanov wrote:
> On 11 May 2018 at 00:44, wm4 wrote:
>
> > On Fri, 11 May 2018 00:41:20 +0100
> > Derek Buitenhuis wrote:
> >
> > > On Fri, May 11, 2018 at 12:35 AM, Paul B Mahol wrote:
> > > > I do not have time to explain security basics.
On Fri, May 11, 2018 at 12:49 AM, James Darnley wrote:
> I want to argue some more so here you go: it isn't "by default".
Strange definition of default, but OK.
> It gets rendered because you asked for it to be rendered. You asked for
> /etc/passwd to be rendered so ffmpeg did that. It produce
On Fri, 11 May 2018 01:49:58 +0200
James Darnley wrote:
> ...
Security in ffmpeg sure is weird. On one hand we get all kinds of crazy
stuff that's supposed to mitigate... something (like whitelists), on
the other hand we get this.
> I haven't tried to stand in the way of other bad changes to ff
On Thu, 2018-05-10 at 21:00 +0100, Mark Thompson wrote:
> On 10/05/18 06:47, Haihao Xiang wrote:
> > Similar to H264, cbs_h265_{read, write}_nal_unit() can handle HEVC
> > prefix SEI NAL units. Currently mastering display colour volume SEI
> > message is added only, we may add more SEI message if n
On Thu, 2018-05-10 at 20:04 +0100, Mark Thompson wrote:
> On 10/05/18 04:08, Haihao Xiang wrote:
> > The flag of input_available must be set when pic_start is not NULL, so
> > add an assert to ensure it is true. In addition, the assert on last_pic
> > is unnecessary now, so remove this assert.
> >
On Thu, May 10, 2018 at 4:08 PM, Jan Ekström wrote:
> On Fri, May 11, 2018 at 1:39 AM, Alex Converse
> wrote:
>> On Thu, May 3, 2018 at 10:58 AM, Jan Ekström wrote:
>>>
>>> Hi,
>>>
>>> While the timestamp field is 8+24=32 bits, the DTS value is int64_ts.
>>> Thus, while I'm really bad at doing
From: Alex Converse
The code is trivial but the semantics in the spec are ambiguous. This
should help keep parts of the muxer interpreting them consistently.
---
libavformat/flvenc.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/libavformat/flvenc.c b/libavform
From: Alex Converse
---
libavformat/flvenc.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 9b7cdfe7db..7aa2dbf9a6 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -485,7 +485,7 @@ static int unsupport
Rename the nal_unit_name to hevc_nal_unit_name, will add a
h264_nal_unit_name function.
Signed-off-by: Jun Zhao
---
libavcodec/h2645_parse.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index ec25c1e..579b2c9 100644
-
Signed-off-by: Jun Zhao
---
libavcodec/h2645_parse.c | 16
1 file changed, 16 insertions(+)
diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index dbf2435..ec25c1e 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -158,12 +158,28 @@ static c
when the NALU data with zero, just give a warning.
Fixes ticket #7200
Signed-off-by: Jun Zhao
---
libavcodec/cbs_h2645.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index ab33cdb..08b060c 100644
--- a/libavcodec/cbs_h2
Signed-off-by: Jun Zhao
---
libavcodec/h2645_parse.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 579b2c9..8d67579 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -
On 5/11/2018 2:11 AM, Jun Zhao wrote:
> when the NALU data with zero, just give a warning.
>
> Fixes ticket #7200
>
> Signed-off-by: Jun Zhao
> ---
> libavcodec/cbs_h2645.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h26
85 matches
Mail list logo
