The newest 14496-12 (4th edition corrected ver.) spec makes the definition
of terms around random access clear.
And the spec adds random access point grouping to signal closed or open
random access points.
14496-15 (AVC file format) spec already says sync sample table describes
only IDR-pictures f
Attached patch fixes seeking to file offset exceeding 2G when int is
defined as 32bit signed integer.
This patch is similar with
https://github.com/FFmpeg/FFmpeg/commit/d37044647f83f53a1cb711ea4655b944ff4af0e5but
ffmpeg's one doesn't work on MinGW (not MinGW-w64) since MinGW ignores
FILE_OFFSET_BIT
This is a regression in
http://git.libav.org/?p=libav.git;a=commitdiff;h=759001c534287a96dc96d1e274665feb7059145d.
0001-libopencore-amr-Add-the-missing-3rd-argument.patch
Description: Binary data
___
libav-devel mailing list
libav-devel@libav.org
https:
2013/3/8 Yusuke Nakamura
> This is a regression in
> http://git.libav.org/?p=libav.git;a=commitdiff;h=759001c534287a96dc96d1e274665feb7059145d.
>
Oops. obviously, commit message is inappropriate.
libopencore-amr: Add the missing 3rd argument of ff_g
Attached patches support setting field order information for H.264, VC-1
and MPEG-2 video stream by parsing.
0001-avcodec-Add-field-order-information-to-AVCodecParser.patch
Description: Binary data
0002-mpegvideo_parser-Set-field_order.patch
Description: Binary data
0003-vc1_parser-Set-field_
2013/4/9 Hendrik Leppkes
> On Tue, Apr 9, 2013 at 10:16 AM, Yusuke Nakamura <
> muken.the.vfrman...@gmail.com> wrote:
>
> > Attached patches support setting field order information for H.264, VC-1
> > and MPEG-2 video stream by parsing.
> >
> >
> AVC
2013/4/9 Luca Barbato
> On 09/04/13 10:16, Yusuke Nakamura wrote:
> > Attached patches support setting field order information for H.264, VC-1
> > and MPEG-2 video stream by parsing.
>
> They look ok, the h264 one might be reformatted a little since chained
> ternaries ar
2013/4/11 Yusuke Nakamura
> 2013/4/9 Luca Barbato
>
>> On 09/04/13 10:16, Yusuke Nakamura wrote:
>> > Attached patches support setting field order information for H.264, VC-1
>> > and MPEG-2 video stream by parsing.
>>
>> They look ok, the h264 one m
2013/4/15 Vittorio Giovara
> On Mon, Apr 15, 2013 at 12:42 PM, Luca Barbato wrote:
>
> > On 04/11/2013 04:56 PM, Yusuke Nakamura wrote:
> > > 2013/4/9 Luca Barbato
> > >
> > >> On 09/04/13 10:16, Yusuke Nakamura wrote:
> > >>> Attached
2013/4/16 Vittorio Giovara
> On 15/apr/2013, at 16:43, Yusuke Nakamura
> wrote:
>
> > As far as I understand, frame_mbs_only_flag == 1 guarantees that frames
> are
> > progressive, while frame_mbs_only_flag == 0 doesn't guarantee that a
> frame
> >
I encountered the following error.
libavcodec/pthread.c: In function 'frame_thread_free':
libavcodec/pthread.c:654:13: error: used struct type value where scalar is
required
make: *** [libavcodec/pthread.o] Error 1
Attached patch fixes this.
0001-pthread-Fix-compilation-regression-at-e524ead.pa
This patch fixes my 10L of following.
http://git.libav.org/?p=libav.git;a=commitdiff;h=5f0bb0baefd506d684adfa1ad4259c65973b455e
0001-mov-Fix-empty-edit-detection.patch
Description: Binary data
___
libav-devel mailing list
libav-devel@libav.org
https://l
2011/6/18 Måns Rullgård
> Yusuke Nakamura writes:
>
> > This patch fixes my 10L of following.
> >
> http://git.libav.org/?p=libav.git;a=commitdiff;h=5f0bb0baefd506d684adfa1ad4259c65973b455e
> >
> > From f3c030ebedabc9a17e377c6f91dc417e6578712b Mon Sep 17 00:00:
2011/6/19 Måns Rullgård
> Yusuke Nakamura writes:
>
> > 2011/6/18 Måns Rullgård
> >
> >> Yusuke Nakamura writes:
> >>
> >> > This patch fixes my 10L of following.
> >> >
> >>
> http://git.libav.org/?p=libav.git;a=
2011/7/29 Diego Biurrun
> ---
> libavformat/movenc.c | 17 -
> 1 files changed, 0 insertions(+), 17 deletions(-)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index c5750d1..10d7abb 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -1400,22
2011/7/30 Alex Converse
> On Fri, Jul 29, 2011 at 11:10 AM, Yusuke Nakamura
> wrote:
> > 2011/7/29 Diego Biurrun
> >>
> >> ---
> >> libavformat/movenc.c | 17 -
> >> 1 files changed, 0 insertions(+), 17 deletions(-)
> >
2012/2/17 Martin Storsjö
> ---
> Some of these are really long, but making them shorter makes
> them a bit ambiguous IMO...
>
> libavformat/isom.h | 10 ++
> libavformat/mov.c|2 +-
> libavformat/movenc.c |6 --
> 3 files changed, 15 insertions(+), 3 deletions(-)
>
>
2012/2/19 Martin Storsjö
> Set keyframe flags based on this atom, too.
>
> This atom contains info about which samples are keyframes in
> some files where it isn't indicated in any other way. (Smooth
> streaming fragments produced by Wowza and ismv files produced
> by Sorenson Squeeze don't indic
2012/2/19 Martin Storsjö
> On Sun, 19 Feb 2012, Yusuke Nakamura wrote:
>
> sample_depends_on = 2 doesn't mean random accessible point (e.g. H.264
>> stream can contain non-RAP I-pictures).
>>
>
> Hmm, the spec says "2: this sample does not depend on others
2012/2/21 Martin Storsjö
> For video, mark the first sample in a trun which doesn't have the
> sample-is-non-sync-sample flag set as a keyframe.
>
> In particular, the "sample does not depend on other samples" flag
> isn't enough to make it a keyframe, since later frames still can
> reference fra
Stss atom without entries doesn't mean every sample is a sync sample.
0001-mov-Fix-detecting-there-is-no-sync-sample.patch
Description: Binary data
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
The second patch may deny
http://git.libav.org/?p=libav.git;a=commit;f=libavformat/mov.c;h=26846ba5151b0fe90e21c1a6beb9a3bcb569d1ac,
while this commit denies splitted files with gradual decoder refresh
(not
marked as a sync sample in 14496-15 spec).
So, I prefer the second patch to this commit.
0
2012年4月18日1:12 Derek Buitenhuis :
> On 16/04/2012 10:52 AM, Yusuke Nakamura wrote:
> > The second patch may deny
> http://git.libav.org/?p=libav.git;a=commit;f=libavformat/mov.c;h=26846ba5151b0fe90e21c1a6beb9a3bcb569d1ac,
> while this commit denies splitted files with gradual
DTS LBR identifier ('dtse') is not included since libavcodec doesn't
support it yet.
0001-isom-Support-more-DTS-codec-indentifiers.patch
Description: Binary data
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo
2012年4月22日8:34 Derek Buitenhuis :
> On 21/04/2012 7:26 PM, Yusuke Nakamura wrote:
> > DTS LBR identifier ('dtse') is not included since libavcodec doesn't
> support it yet.
>
> This looks pretty harmless. Have you confirmed it works properly
> on su
Skip to parse fields for additional independent substreams and its
associated dependent substreams since libavcodec's eac3 decoder doesn't
support them yet.
0001-mov-Parse-EC3SpecificBox-dec3-atom.patch
Description: Binary data
___
libav-devel mailing l
2012年4月26日8:16 Justin Ruggles :
> On 04/25/2012 06:31 PM, Yusuke Nakamura wrote:
>
> > +st->codec->channels = ((int[]){2,1,2,3,3,4,4,5})[acmod] + lfeon;
> > +st->codec->channel_layout = avpriv_ac3_channel_layout_tab[acmod];
> > +if (lfeon)
&g
2012年4月26日8:47 Justin Ruggles :
> On 04/25/2012 07:38 PM, Yusuke Nakamura wrote:
>
> > 2012年4月26日8:16 Justin Ruggles > <mailto:justin.rugg...@gmail.com>>:
> >
> > On 04/25/2012 06:31 PM, Yusuke Nakamura wrote:
> >
> > > +st-
2012/4/30 Derek Buitenhuis
> From: Hendrik Leppkes
>
> This atom typically is used for a track title.
>
> Reviewed-by: Baptiste Coudurier
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mov.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/libavformat/mov.c b
2012/6/29 Alex Converse
> On Tue, Jun 26, 2012 at 10:07 AM, Anton Khirnov wrote:
> > ---
> > libavformat/mov.c | 49
> +
> > 1 file changed, 49 insertions(+)
> >
>
> Is this documented anywhere. I don't see it in the QTFF spec.
>
>
Apple publish
This fixes, for instance, the case that there is a track that has some
samples with composition time offset and has a track run without
sample-composition-time-offsets-present.
---
libavformat/mov.c | 33 ++---
1 files changed, 18 insertions(+), 15 deletions(-)
diff
libav has a bug that libav detects wrong CTS from fragmented ISO base
media file formats.
This bug occurs, for instance, when there is a track that has some
samples with composition time offset and has a track run without
sample-composition-time-
offsets-present.
I attached a patch for this bug an
Sorry, I missed the case that moov atom has any samples and doesn't have
ctts atom.
I attached a new patch.
0001-mov-fix-composition-timestamps-on-movie-fragments.patch
Description: Binary data
___
libav-devel mailing list
libav-devel@libav.org
https:/
2011/4/30 Aℓex Converse
> On Fri, Apr 29, 2011 at 9:37 AM, Yusuke Nakamura
> wrote:
> > Sorry, I missed the case that moov atom has any samples and doesn't have
> > ctts atom.
> >
> > I attached a new patch.
> >
>
> have you tried runn
Attached patch fixes detecting wrong timestamps on large presentation
indicated by edit list atom.
0001-mov-Support-edit-list-atom-version-1.patch
Description: Binary data
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailma
dts, local variable in mov_read_trun, generates wrong timestamps when
time_offset is present, since dts is given by st->duration which doesn't
consider time_offset.
Attached patch fixes this.
0001-mov-Fix-wrong-timestamp-generation-for-fragmented-mo.patch
Description: Binary data
___
2011/5/28 Gil Pedersen
> The current code assumes that the first sample has the earliest composition
> time. When using b-frames, a codec is not required to enforce this, and thus
> I make a quick search for the sample with the earliest composition time.
> ISO/IEC 14496-12 section 8.6.1.1 has an
2013/4/15 Luca Barbato
> On 04/11/2013 04:56 PM, Yusuke Nakamura wrote:
> > 2013/4/9 Luca Barbato
> >
> >> On 09/04/13 10:16, Yusuke Nakamura wrote:
> >>> Attached patches support setting field order information for H.264,
> VC-1
> >>> and MPE
2013/4/25 Yusuke Nakamura
> 2013/4/15 Luca Barbato
>
>> On 04/11/2013 04:56 PM, Yusuke Nakamura wrote:
>> > 2013/4/9 Luca Barbato
>> >
>> >> On 09/04/13 10:16, Yusuke Nakamura wrote:
>> >>> Attached patches support setting field ord
2013/5/8 Janne Grunau
> On 2013-04-25 06:58:05 +0900, Yusuke Nakamura wrote:
> > 2013/4/15 Luca Barbato
> >
> > I got some opinions about the H.264 one by Anton and Janne on IRC, and I
> > took them in a new patch.
>
> > From 0013dc39354577b015e8971f6ebac
2013/5/8 Yusuke Nakamura
> 2013/5/8 Janne Grunau
>
>> On 2013-04-25 06:58:05 +0900, Yusuke Nakamura wrote:
>> > 2013/4/15 Luca Barbato
>> >
>> > I got some opinions about the H.264 one by Anton and Janne on IRC, and I
>
2013/5/21 Janne Grunau
> On 2013-05-15 20:57:42 +0900, Yusuke Nakamura wrote:
> > 2013/5/8 Yusuke Nakamura
> >
> > From ef78ded8954c3fca0ed138b29ee22dfe5a42fb2a Mon Sep 17 00:00:00 2001
> > From: Yusuke Nakamura
> > Date: Wed, 15 May 2013 07:36:15 +0900
>
2013/5/24 Diego Biurrun
> On Thu, May 23, 2013 at 04:37:24PM +0900, Yusuke Nakamura wrote:
> >
> > OK. Attached new patches use an enum for picture_structure and take
> > suggestions on IRC.
>
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avco
ULH0 and ULH2 formats, which indicate BT.709-based colorspace conversion
coefficient, were added at Ut Video ver. 13.0.0.
0001-utvideodec-Support-ULH0-and-ULH2-formats.patch
Description: Binary data
0002-riff-Support-ULH0-and-ULH2-fourccs.patch
Description: Binary data
0003-utvideodec.c-Set-c
44 matches
Mail list logo
