Hi,
I try to insert image picture to m4b as cover of the file.
I can read picture like this:
QPixmap pixmap;
if ( avformat_find_stream_info( fmt_ctx, nullptr ) >= 0 ) {
for ( int i = 0; i < fmt_ctx->nb_streams; ++i ) {
AVStream *stream = fmt_ctx->streams[ i ];
if ( stream->disposition
On Mon, Nov 25, 2019 at 09:35:04PM -0500, Andriy Gelman wrote:
> On Mon, 25. Nov 01:50, Michael Niedermayer wrote:
> > On Sun, Nov 24, 2019 at 11:29:18AM -0500, Andriy Gelman wrote:
> > > On Sun, 24. Nov 00:02, Michael Niedermayer wrote:
> > > > On Tue, Oct 15, 2019 at 10:50:39PM -0400, Andriy Gelm
On 11/25/19, Tomas Härdin wrote:
> mån 2019-11-25 klockan 22:09 +0100 skrev Paul B Mahol:
>> Signed-off-by: Paul B Mahol
>> +static int decode_mvdv(MidiVidContext *s, AVCodecContext *avctx, AVFrame
>> *frame)
>> +{
>> +GetByteContext *gb = &s->gb;
>> +GetBitContext mask;
>> +GetByteCo
Signed-off-by: Steven Liu
---
fftools/cmdutils.c | 18 ++
fftools/ffmpeg_opt.c | 2 +-
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 84f98b7c04..e0516296d5 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@
Signed-off-by: Steven Liu
---
doc/APIchanges | 3 +++
libavformat/avio.h | 8
libavformat/protocols.c | 10 ++
libavformat/version.h | 2 +-
4 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 401c65a753..3989614
Attachments are streams in FFmpeg, but they are not tracks in Matroska.
Yet they were counted when checking a limit for the number of tracks that
the Matroska muxer imposes. This is unnecessary and has been changed.
(The Matroska file format actually has practically no limit on the
number of track
This avoids errors lateron after the file header has already been
partially written.
Signed-off-by: Andreas Rheinhardt
---
get_mimetype() doesn't change st, so it can be const. I forgot that in
the first version.
libavformat/matroskaenc.c | 35 ++-
1 file changed
On Tue, 26. Nov 10:52, Michael Niedermayer wrote:
> On Mon, Nov 25, 2019 at 09:35:04PM -0500, Andriy Gelman wrote:
> > On Mon, 25. Nov 01:50, Michael Niedermayer wrote:
> > > On Sun, Nov 24, 2019 at 11:29:18AM -0500, Andriy Gelman wrote:
> > > > On Sun, 24. Nov 00:02, Michael Niedermayer wrote:
> >
On Tue, 26. Nov 19:26, Steven Liu wrote:
> Signed-off-by: Steven Liu
> ---
> doc/APIchanges | 3 +++
> libavformat/avio.h | 8
> libavformat/protocols.c | 10 ++
> libavformat/version.h | 2 +-
> 4 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git
Andriy Gelman (12019-11-26):
> > + * @param name protocol name
> extra name ^
No, it is the normal pattern, to mean "the variable 'name' is the name
of the protocol".
But it is indeed a completely useless precision, much like the infamous
"to print, use the print menu".
Regards,
--
Nicolas
Signed-off-by: James Almer
---
libavformat/avc.c | 38 +-
libavformat/avc.h | 1 +
2 files changed, 34 insertions(+), 5 deletions(-)
diff --git a/libavformat/avc.c b/libavformat/avc.c
index a041e84357..9bd215c07f 100644
--- a/libavformat/avc.c
+++ b/libavform
On Tue, Nov 26, 2019 at 2:07 PM James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavformat/avc.c | 38 +-
> libavformat/avc.h | 1 +
> 2 files changed, 34 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/avc.c b/libavformat/avc.c
> index a
> 在 2019年11月26日，下午8:35，Nicolas George 写道：
>
> Andriy Gelman (12019-11-26):
>>> + * @param name protocol name
>> extra name ^
>
> No, it is the normal pattern, to mean "the variable 'name' is the name
> of the protocol".
>
> But it is indeed a completely useless precision, much like the infa
Liu Steven (12019-11-26):
> What should i do next step? remove the comment of the parameter? or
> just looks good?
My opinion is to remove the comment because it brings nothing.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
__
On Tue, Nov 26, 2019 at 12:27 PM Steven Liu wrote:
>
> Signed-off-by: Steven Liu
> ---
> doc/APIchanges | 3 +++
> libavformat/avio.h | 8
> libavformat/protocols.c | 10 ++
> libavformat/version.h | 2 +-
> 4 files changed, 22 insertions(+), 1 deletion(-)
>
>
applied with some changes regarding flags and device flags
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "un
On Thu, Nov 21, 2019 at 06:27:10PM -0300, ggarr...@gmail.com wrote:
> From: Gonzalo Garramuño
>
> This patch is based on a patch by bsenftner at earthlink.net.
> ---
> libavformat/utils.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> i
Am Di., 26. Nov. 2019 um 10:53 Uhr schrieb Paul B Mahol :
>
> On 11/25/19, Tomas Härdin wrote:
> > mån 2019-11-25 klockan 22:09 +0100 skrev Paul B Mahol:
> >> Signed-off-by: Paul B Mahol
> >> +static int decode_mvdv(MidiVidContext *s, AVCodecContext *avctx, AVFrame
> >> *frame)
> >> +{
> >> +
On 11/26/19, Carl Eugen Hoyos wrote:
> Am Di., 26. Nov. 2019 um 10:53 Uhr schrieb Paul B Mahol :
>>
>> On 11/25/19, Tomas Härdin wrote:
>> > mån 2019-11-25 klockan 22:09 +0100 skrev Paul B Mahol:
>> >> Signed-off-by: Paul B Mahol
>> >> +static int decode_mvdv(MidiVidContext *s, AVCodecContext *a
Am Di., 26. Nov. 2019 um 14:07 Uhr schrieb James Almer :
>
> Signed-off-by: James Almer
> ---
> libavformat/avc.c | 38 +-
> libavformat/avc.h | 1 +
> 2 files changed, 34 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/avc.c b/libavformat/avc.c
> i
On 26/11/19 14:31, Michael Niedermayer wrote:
On Thu, Nov 21, 2019 at 06:27:10PM -0300, ggarr...@gmail.com wrote:
From: Gonzalo Garramuño
This patch is based on a patch by bsenftner at earthlink.net.
---
libavformat/utils.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavfor
Paul B Mahol (12019-11-26):
> >> Nothing of this can actually happen.
> > Then you could add asserts (and cut your quotes).
> Asserts for checking UBs? Non sense.
Assert to have debug builds check that the things you say cannot happen
do not actually happen. That is what asserts are for: check a c
On 11/26/19, Nicolas George wrote:
> Paul B Mahol (12019-11-26):
>> >> Nothing of this can actually happen.
>> > Then you could add asserts (and cut your quotes).
>> Asserts for checking UBs? Non sense.
>
> Assert to have debug builds check that the things you say cannot happen
> do not actually h
On 11/26/2019 6:47 AM, Paul B Mahol wrote:
> On 11/25/19, Tomas Härdin wrote:
>> mån 2019-11-25 klockan 22:09 +0100 skrev Paul B Mahol:
>>> Signed-off-by: Paul B Mahol
>>> +static int decode_mvdv(MidiVidContext *s, AVCodecContext *avctx, AVFrame
>>> *frame)
>>> +{
>>> +GetByteContext *gb = &s
On 11/25/2019 6:09 PM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/avcodec.h| 1 +
> libavcodec/codec_desc.c | 7 ++
> libavcodec/midivid.c| 272
> l
On 11/26/19, James Almer wrote:
> On 11/26/2019 6:47 AM, Paul B Mahol wrote:
>> On 11/25/19, Tomas Härdin wrote:
>>> mån 2019-11-25 klockan 22:09 +0100 skrev Paul B Mahol:
Signed-off-by: Paul B Mahol
+static int decode_mvdv(MidiVidContext *s, AVCodecContext *avctx,
AVFrame
*f
On 11/26/2019 4:29 PM, Paul B Mahol wrote:
> On 11/26/19, James Almer wrote:
>> On 11/26/2019 6:47 AM, Paul B Mahol wrote:
>>> On 11/25/19, Tomas Härdin wrote:
mån 2019-11-25 klockan 22:09 +0100 skrev Paul B Mahol:
> Signed-off-by: Paul B Mahol
> +static int decode_mvdv(MidiVidConte
On 11/26/19, James Almer wrote:
> On 11/26/2019 4:29 PM, Paul B Mahol wrote:
>> On 11/26/19, James Almer wrote:
>>> On 11/26/2019 6:47 AM, Paul B Mahol wrote:
On 11/25/19, Tomas Härdin wrote:
> mån 2019-11-25 klockan 22:09 +0100 skrev Paul B Mahol:
>> Signed-off-by: Paul B Mahol
>>
On 11/26/2019 2:32 PM, Carl Eugen Hoyos wrote:
> Am Di., 26. Nov. 2019 um 14:07 Uhr schrieb James Almer :
>>
>> Signed-off-by: James Almer
>> ---
>> libavformat/avc.c | 38 +-
>> libavformat/avc.h | 1 +
>> 2 files changed, 34 insertions(+), 5 deletions(-)
>>
On 11/26/19, James Almer wrote:
> On 11/25/2019 6:09 PM, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol
>> ---
>> libavcodec/Makefile | 1 +
>> libavcodec/allcodecs.c | 1 +
>> libavcodec/avcodec.h| 1 +
>> libavcodec/codec_desc.c | 7 ++
>> libavcodec/midivid.c| 272 +++
On Fri, May 13, 2016 at 2:29 PM James Almer wrote:
> The header was never installed and the function is only used in libavformat
>
I think av_convert_lang_to would be a useful public function. Do you mind
if I redefine it, and export the header this time?
libavformat returns iso639-2 codes in A
On 11/26/2019 9:29 PM, Aman Gupta wrote:
> On Fri, May 13, 2016 at 2:29 PM James Almer wrote:
>
>> The header was never installed and the function is only used in libavformat
>>
>
> I think av_convert_lang_to would be a useful public function. Do you mind
> if I redefine it, and export the heade
LGTM. WIll apply
Linjie Fu 于2019年11月26日周二 下午12:01写道：
>
> Signed-off-by: Linjie Fu
> ---
> libavcodec/qsvenc.c | 8
> libavcodec/qsvenc.h | 2 +-
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 93d49ba..e176d57 100644
From: Aman Gupta
Signed-off-by: Aman Gupta
---
doc/APIchanges | 3 +++
libavformat/Makefile | 1 +
libavformat/avlanguage.c | 2 --
libavformat/avlanguage.h | 5 +
libavformat/version.h| 2 +-
5 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/doc/APIchanges b/
Suggested-by: Hendrik Leppkes
Suggested-by: Nicolas George
Signed-off-by: Steven Liu
---
doc/APIchanges | 3 +++
libavformat/avio.h | 7 +++
libavformat/protocols.c | 10 ++
libavformat/version.h | 2 +-
4 files changed, 21 insertions(+), 1 deletion(-)
diff --git
Signed-off-by: Steven Liu
---
fftools/cmdutils.c | 18 ++
fftools/ffmpeg_opt.c | 2 +-
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 84f98b7c04..96b823f74a 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@
On Wed, Nov 27, 2019 at 11:11:58AM +0800, Steven Liu wrote:
> Signed-off-by: Steven Liu
> ---
> fftools/cmdutils.c | 18 ++
> fftools/ffmpeg_opt.c | 2 +-
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> index 84f98b
This commit reuses the random seed generated in mkv_init() to determine
the TrackUIDs for the SegmentUID in order to avoid a potentially
expensive call to av_get_random_seed().
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 19 +--
1 file changed, 9 insertions(
AVChapters have an int as id field and therefore this value can appear
<= 0. When remuxing from Matroska, this value is actually the lower 32
bits of the original ChapterUID (which can be 64 bits).
In order to ensure that the ChapterUID be always > 0, they were offset
as follows (since 07704c61):
Up until now, the TrackUID of a Matroska track which is supposed to be
random was not random at all: It always coincided with the TrackNumber
which is usually the 1-based index of the corresponding stream in the
array of AVStreams. This has been changed: It is now set via an AVLFG
if AVFMT_FLAG_BIT
If there are attachments to write, the Matroska muxer currently
allocates two objects: An array that contains an entry for each
attachment containing just the stream index of the corresponding
stream and the uid used for this attachment; and a structure with
a pointer to said array and a counter fo
Using random values for TrackUID and FileUID (as happens when the
AVFMT_FLAG_BITEXACT flag is not set) has the obvious downside of making
the output indeterministic. This commit mitigates this by writing the
potentially random values with a fixed size of eight byte, even if their
actual values woul
Up until e7ddafd5, the Matroska muxer wrote two seekheads: One at the
beginning referencing the main level 1 elements (i.e. not the clusters)
and one at the end, referencing the clusters. This second seekhead was
useless and has therefore been removed. Yet the seekhead-related
functions and structu
The Matroska muxer currently only adds CuePoints in three cases:
a) For video keyframes. b) For the first audio frame in a new cluster if
in dash-mode. c) For subtitles. This means that ordinary Matroska audio
files won't have any cues which impedes seeking.
This commit changes this. For every tra
Several EBML master elements for which a good upper bound of the final
length was available were nevertheless written as unknown-length
EBML-elements, so that their length field was eight bytes long. This has
been changed.
Signed-off-by: Andreas Rheinhardt
---
Resending because of updated FATE-te
> 在 2019年11月27日，12:52，Limin Wang 写道：
>
> On Wed, Nov 27, 2019 at 11:11:58AM +0800, Steven Liu wrote:
>> Signed-off-by: Steven Liu
>> ---
>> fftools/cmdutils.c | 18 ++
>> fftools/ffmpeg_opt.c | 2 +-
>> 2 files changed, 19 insertions(+), 1 deletion(-)
>>
>> diff --git a/fftoo
Signed-off-by: Steven Liu
---
fftools/cmdutils.c | 14 ++
fftools/ffmpeg_opt.c | 2 +-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 84f98b7c04..0e1bb4dbb6 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -18
Suggested-by: Hendrik Leppkes
Suggested-by: Nicolas George
Signed-off-by: Steven Liu
---
doc/APIchanges | 3 +++
libavformat/avio.h | 7 +++
libavformat/protocols.c | 10 ++
libavformat/version.h | 2 +-
4 files changed, 21 insertions(+), 1 deletion(-)
diff --git
Suggested-by: Rodney Baker
Signed-off-by: Steven Liu
---
doc/demuxers.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 4e1a5cb6aa..0d13bdd1b3 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -332,7 +332,7 @@ Maximum num
Attachments are streams in FFmpeg, but they are not tracks in Matroska.
Yet they were counted when checking a limit for the number of tracks that
the Matroska muxer imposes. This is unnecessary and has been changed.
(The Matroska file format actually has practically no limit on the
number of track
On Mon, Nov 25, 2019 at 2:57 PM Michael Niedermayer
wrote:
> On Sun, Nov 24, 2019 at 11:05:03PM +0100, Andreas Rheinhardt wrote:
> > On Sun, Nov 24, 2019 at 8:28 PM Michael Niedermayer
>
> > wrote:
> >
> > > On Sun, Nov 24, 2019 at 09:08:00AM +, Andreas Rheinhardt wrote:
> > > > Michael Nied
Signed-off-by: Zhong Li
---
doc/encoders.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 6cf3a74..efa28ef 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2776,7 +2776,7 @@ recommended value) and do not set a size cons
On 27-11-2019 11:33 am, Steven Liu wrote:
Suggested-by: Rodney Baker
Signed-off-by: Steven Liu
---
doc/demuxers.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 4e1a5cb6aa..0d13bdd1b3 100644
--- a/doc/demuxers.texi
+++ b/d
On 27-11-2019 12:34 pm, Zhong Li wrote:
Signed-off-by: Zhong Li
---
doc/encoders.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 6cf3a74..efa28ef 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2776,7 +2776,7 @@
to its actual behaviour: That it uses the least amount of bytes unless
overridden.
The current documentation leaves it undefined how many bytes will be used
when no number to use has been given explicitly. But several estimates
(used to write EBML Master elements with a small length field) require
The Matroska muxer currently does not check the return value of
ff_isom_write_hvcc(), the function used to write mp4-style
HEVC-extradata as Matroska also uses it. This was intentionally done in
7a5356c72 to allow remuxing from mpeg-ts.
But if ff_isom_write_hvcc() fails, it has not output anything
The extradata is not changed at all.
Signed-off-by: Andreas Rheinhardt
---
libavformat/flacenc.h| 2 +-
libavformat/flacenc_header.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/flacenc.h b/libavformat/flacenc.h
index d5d53a5dcb..b308d0d021 100644
--
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 6e1d575e3f..10599b11df 100644
--- a/libavformat/matroskaenc.c
+++ b/liba
At the end of encoding, the flac encoder sends a packet whose side-data
contains updated extradata (e.g. a correct md5 checksum). The Matroska
muxer uses this to update the CodecPrivate.
In doing so, the streams codecpar was copied. But given that writing
a flac CodecPrivate does not modify the us
On Mon, Nov 25, 2019 at 10:14:41PM +0800, zhilizhao wrote:
> Please help to merge the patch if it’s acceptable, thanks!
no code changes, it is acceptable as-is.
>
> > On Nov 18, 2019, at 7:00 PM, Peter Ross wrote:
> >
> > On Mon, Nov 18, 2019 at 10:34:32AM +0800, zhilizhao wrote:
> >> Ping for
60 matches
Mail list logo
