[libav-devel] License consent (cinepakenc.c)
Hi (re-sending the same message I sent to ffmpeg-devel, minus a bit about MAINTAINERS) I got a question from Diego via IRC about what license cinepakenc.c actually has, since the first commit message just has a message by"Rl" saying that I said it was OK but with no appropriately signed message from me. So I'm posting this just to clarify things: I consent to the original license placed on cinepakenc.c on Wed Jan 22 11:12:11 2014 +0100 (commit 59dbc36f49db5cfd9d2ad4b00ef2e3336173ee8d). Just for fun I gave the encoder a try, and the output plays just fine on Windows 3.1 in dosbox-x :) /Tomas signature.asc Description: This is a digitally signed message part ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 4/9] mxfenc: always assume long gop
On Fri, 2014-11-28 at 13:16 +0100, Anton Khirnov wrote:
> Checking the codec context parameters to find out this information is
> far too unreliable to be useful, so it is safer to assume B-frames are
> always present.
> ---
> libavformat/mxfenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index 2cf77df..7a32e0b 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -1295,7 +1295,7 @@ static const UID mxf_mpeg2_codec_uls[] = {
>
> static const UID *mxf_get_mpeg2_codec_ul(AVCodecContext *avctx)
> {
> -int long_gop = avctx->gop_size > 1 || avctx->has_b_frames;
> +int long_gop = 1;
>
> if (avctx->profile == 4) { // Main
> if (avctx->level == 8) // Main
Do you have samples demonstrating this either way?
/Tomas
signature.asc
Description: This is a digitally signed message part
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 7/8] mxfdec: avoid out-of-bounds write
On Fri, 2014-10-24 at 13:11 +0100, Vittorio Giovara wrote:
> On Fri, Oct 24, 2014 at 7:15 AM, Anton Khirnov wrote:
> > Quoting Vittorio Giovara (2014-10-24 01:05:58)
> >> CC: libav-sta...@libav.org
> >> Bug-Id: CID 732262
> >> ---
> >> libavformat/mxfdec.c | 5 +++--
> >> 1 file changed, 3 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> >> index 9aedd47..987dc6a 100644
> >> --- a/libavformat/mxfdec.c
> >> +++ b/libavformat/mxfdec.c
> >> @@ -817,8 +817,9 @@ static void mxf_read_pixel_layout(AVIOContext *pb,
> >> MXFDescriptor *descriptor)
> >> av_dlog(NULL, "pixel layout: code %#x\n", code);
> >>
> >> if (ofs < 16) {
> >> -layout[ofs++] = code;
> >> -layout[ofs++] = value;
> >> +layout[ofs] = code;
> >> +layout[ofs + 1] = value;
> >> +ofs += 2;
> >> }
> >> } while (code != 0); /* SMPTE 377M E.2.46 */
> >>
> >> --
> >> 1.9.3 (Apple Git-50)
> >
> > Eh? Looks very much like a no-op.
>
> It's a little noop, ofs is an even value and it is increased by two at
> every loop, so in the original code ofs gets to 16 when at the last
> operation. Coverity gets a little confused and warns that 16 is out of
> bounds.
> I can drop this if preferred and mark a false positive if preferred.
It doesn't fix anything and makes the code uglier. Perhaps change it to
ofs <= 14? That makes the code clearer and should make coverity happy.
/Tomas
signature.asc
Description: This is a digitally signed message part
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/4] mxf: Support AAC
On 2014-08-14 23:18, Luca Barbato wrote:
On 14/08/14 22:11, Tomas Härdin wrote:
On Wed, 2014-08-13 at 19:37 +0200, Luca Barbato wrote:
On 13/08/14 19:15, Anton Khirnov wrote:
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 410c13b..eb0f5d0 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -972,6 +972,7 @@ static const MXFCodecUL mxf_sound_essence_container_uls[] =
{
{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x02,0x0d,0x01,0x03,0x01,0x02,0x04,0x40,0x01
}, 14, AV_CODEC_ID_MP2 }, /* MPEG-ES Frame wrapped, 0x40 ??? stream id */
{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0d,0x01,0x03,0x01,0x02,0x01,0x01,0x01
}, 14, AV_CODEC_ID_PCM_S16LE }, /* D-10 Mapping 50Mbps PAL Extended Template */
{ {
0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0xff,0x4b,0x46,0x41,0x41,0x00,0x0d,0x4d,0x4F
}, 14, AV_CODEC_ID_PCM_S16LE }, /* 0001GL00.MXF.A1.mxf_opatom.mxf */
+{ {
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x03,0x04,0x02,0x02,0x02,0x03,0x03,0x01,0x00
}, 14, AV_CODEC_ID_AAC }, /* MPEG2 AAC ADTS (legacy) */
{ {
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
}, 0, AV_CODEC_ID_NONE },
};
@@ -1822,6 +1823,7 @@ static const MXFMetadataReadTableEntry mxf_metadata_read_table[] = {
{ {
0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x48,0x00
}, mxf_read_generic_descriptor, sizeof(MXFDescriptor), Descriptor }, /* Wave */
{ {
0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x47,0x00
}, mxf_read_generic_descriptor, sizeof(MXFDescriptor), Descriptor }, /* AES3 */
{ {
0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x5c,0x00
}, mxf_read_generic_descriptor, sizeof(MXFDescriptor), Descriptor }, /*
VANC/VBI - SMPTE 436M */
+{ {
0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x5e,0x00
}, mxf_read_generic_descriptor, sizeof(MXFDescriptor), Descriptor }, /*
MPEG2AudioDescriptor */
{ {
0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x3A,0x00
}, mxf_read_track, sizeof(MXFTrack), Track }, /* Static Track */
{ {
0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x3B,0x00
}, mxf_read_track, sizeof(MXFTrack), Track }, /* Generic Track */
{ {
0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x04,0x01,0x02,0x02,0x00,0x00
}, mxf_read_cryptographic_context, sizeof(MXFCryptoContext), CryptoContext },
@@ -2413,7 +2415,8 @@ static int mxf_read_packet_old(AVFormatContext *s,
AVPacket *pkt)
* < PTS if low_delay = 0 (Sony IMX30) */
pkt->pts = mxf->current_edit_unit;
}
-} else if (codec->codec_type == AVMEDIA_TYPE_AUDIO) {
+} else if (codec->codec_type == AVMEDIA_TYPE_AUDIO &&
+ codec->codec_id != AV_CODEC_ID_AAC) {
The commit message should mention the reason for this
I think that way to calculate pts works only for pcm btw. Anybody has an
mxf with something different inside?
Checking if it's a PCM codec should be fine (assuming it passes FATE of
course).
I extended the check since the soundessence contains the
bits_per_coded_sample information (see the new patch)
There's codec ULs for AC3 and MP2 too - are there corresponding FATE
samples for those?
Sadly not =/ Do you have some handy? I'd like to have a second look at
the whole function behaviour.
Nope, I'm afraid not :/ Maybe one could be created with mxfwrap? See
http://sourceforge.net/projects/mxflib/
/Tomas
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/4] mxf: Support AAC
On Wed, 2014-08-13 at 19:37 +0200, Luca Barbato wrote:
> On 13/08/14 19:15, Anton Khirnov wrote:
> >> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> >> index 410c13b..eb0f5d0 100644
> >> --- a/libavformat/mxfdec.c
> >> +++ b/libavformat/mxfdec.c
> >> @@ -972,6 +972,7 @@ static const MXFCodecUL
> >> mxf_sound_essence_container_uls[] = {
> >> { {
> >> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x02,0x0d,0x01,0x03,0x01,0x02,0x04,0x40,0x01
> >> }, 14, AV_CODEC_ID_MP2 }, /* MPEG-ES Frame wrapped, 0x40 ??? stream
> >> id */
> >> { {
> >> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0d,0x01,0x03,0x01,0x02,0x01,0x01,0x01
> >> }, 14, AV_CODEC_ID_PCM_S16LE }, /* D-10 Mapping 50Mbps PAL Extended
> >> Template */
> >> { {
> >> 0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0xff,0x4b,0x46,0x41,0x41,0x00,0x0d,0x4d,0x4F
> >> }, 14, AV_CODEC_ID_PCM_S16LE }, /* 0001GL00.MXF.A1.mxf_opatom.mxf */
> >> +{ {
> >> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x03,0x04,0x02,0x02,0x02,0x03,0x03,0x01,0x00
> >> }, 14, AV_CODEC_ID_AAC }, /* MPEG2 AAC ADTS (legacy) */
> >> { {
> >> 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
> >> }, 0, AV_CODEC_ID_NONE },
> >> };
> >>
> >> @@ -1822,6 +1823,7 @@ static const MXFMetadataReadTableEntry
> >> mxf_metadata_read_table[] = {
> >> { {
> >> 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x48,0x00
> >> }, mxf_read_generic_descriptor, sizeof(MXFDescriptor), Descriptor }, /*
> >> Wave */
> >> { {
> >> 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x47,0x00
> >> }, mxf_read_generic_descriptor, sizeof(MXFDescriptor), Descriptor }, /*
> >> AES3 */
> >> { {
> >> 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x5c,0x00
> >> }, mxf_read_generic_descriptor, sizeof(MXFDescriptor), Descriptor }, /*
> >> VANC/VBI - SMPTE 436M */
> >> +{ {
> >> 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x5e,0x00
> >> }, mxf_read_generic_descriptor, sizeof(MXFDescriptor), Descriptor }, /*
> >> MPEG2AudioDescriptor */
> >> { {
> >> 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x3A,0x00
> >> }, mxf_read_track, sizeof(MXFTrack), Track }, /* Static Track */
> >> { {
> >> 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x3B,0x00
> >> }, mxf_read_track, sizeof(MXFTrack), Track }, /* Generic Track */
> >> { {
> >> 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x04,0x01,0x02,0x02,0x00,0x00
> >> }, mxf_read_cryptographic_context, sizeof(MXFCryptoContext),
> >> CryptoContext },
> >> @@ -2413,7 +2415,8 @@ static int mxf_read_packet_old(AVFormatContext *s,
> >> AVPacket *pkt)
> >> * < PTS if low_delay = 0 (Sony IMX30) */
> >> pkt->pts = mxf->current_edit_unit;
> >> }
> >> -} else if (codec->codec_type == AVMEDIA_TYPE_AUDIO) {
> >> +} else if (codec->codec_type == AVMEDIA_TYPE_AUDIO &&
> >> + codec->codec_id != AV_CODEC_ID_AAC) {
> >
> > The commit message should mention the reason for this
>
> I think that way to calculate pts works only for pcm btw. Anybody has an
> mxf with something different inside?
Checking if it's a PCM codec should be fine (assuming it passes FATE of
course).
There's codec ULs for AC3 and MP2 too - are there corresponding FATE
samples for those?
/Tomas
signature.asc
Description: This is a digitally signed message part
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 07/20] mxfdec: Correctly support files from Pinnacle Thunder
On Fri, 2014-01-10 at 21:19 +0100, Anton Khirnov wrote:
> On Wed, 8 Jan 2014 03:25:38 +0100, Luca Barbato wrote:
> > From: Tomas Härdin
> >
> > Such files have IndexTableSegments which when parsed cover EditUnit ranges
> > like this:
> >
> > [0,1)
> > [249,250)
> > [249,377)
> > [0,249)
> >
> > where each interval is
> >
> > [IndexStartPosition, IndexStartPosition + IndexDuration)
> >
> > This would be reduced to a sparse index like:
> >
> > [0,1), [249,250)
> >
> > instead of the full range:
> >
> > [0,249), [249,377)
> >
> > Sample: http://streams.videolan.org/issues/7302/TimeCode_HD.mxf
> > Signed-off-by: Luca Barbato
> > ---
> > libavformat/mxfdec.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index 7bca23d..2fc31bf 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -980,19 +980,23 @@ static int mxf_get_sorted_table_segments(MXFContext
> > *mxf, int *nb_sorted_segment
> > /* sort segments by {BodySID, IndexSID, IndexStartPosition}, remove
> > duplicates while we're at it */
> > for (i = 0; i < nb_segments; i++) {
> > int best = -1, best_body_sid = -1, best_index_sid = -1,
> > best_index_start = -1;
> > +uint64_t best_index_duration = 0;
> >
> > for (j = 0; j < nb_segments; j++) {
> > MXFIndexTableSegment *s = unsorted_segments[j];
> >
> > /* Require larger BosySID, IndexSID or IndexStartPosition then
> > the previous entry. This removes duplicates.
> > * We want the smallest values for the keys than what we
> > currently have, unless this is the first such entry this time around.
> > + * If we come across an entry with the same IndexStartPosition
> > but larger IndexDuration, then we'll prefer it over the one we currently
> > have.
> > */
> > if ((i == 0 || s->body_sid > last_body_sid || s->index_sid
> > > last_index_sid || s->index_start_position > last_index_start) &&
> > -(best == -1 || s->body_sid < best_body_sid || s->index_sid
> > < best_index_sid || s->index_start_position < best_index_start)) {
> > +(best == -1 || s->body_sid < best_body_sid || s->index_sid
> > < best_index_sid || s->index_start_position < best_index_start ||
> > +(s->index_start_position == best_index_start &&
> > s->index_duration > best_index_duration))) {
> > best = j;
> > best_body_sid= s->body_sid;
> > best_index_sid = s->index_sid;
> > best_index_start = s->index_start_position;
> > +best_index_duration = s->index_duration;
> > }
> > }
> >
> > --
> > 1.8.5.1
> >
>
> Wow, this format really is insane.
You have no idea..
signature.asc
Description: This is a digitally signed message part
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 10/20] mxfdec: Set audio packets pts
On Fri, 2014-01-17 at 11:38 +, Kieran Kunhya wrote: > On 17 January 2014 09:41, Anton Khirnov wrote: > > > > On Wed, 8 Jan 2014 03:25:41 +0100, Luca Barbato wrote: > >> From: Matthieu Bouron > >> > >> Further fixes from Tomas Härdin. > > Pretty bad commit message (not that I understand what the patch does myself) It extrapolates audio timestamps based on the number of samples demxued. It also deals with some MXF nastiness involving fractional number of samples per EditUnit when seeking (the specs handwave this away). /Tomas signature.asc Description: This is a digitally signed message part ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/1] mxfdec: fix typo in mxf_read_seek()
On Fri, 2012-10-26 at 20:05 +0200, Janne Grunau wrote:
> Check the number of index tables before using byte offset based seeking
> instead of the index_tables pointer.
>
> Found by Måns Rullgård .
> ---
> libavformat/mxfdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index 8595d72..61b9c68 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -2210,7 +2210,7 @@ static int mxf_read_seek(AVFormatContext *s, int
> stream_index, int64_t sample_ti
> int ret;
> MXFIndexTable *t;
>
> -if (mxf->index_tables <= 0) {
> +if (mxf->nb_index_tables <= 0) {
> if (!s->bit_rate)
> return AVERROR_INVALIDDATA;
> if (sample_time < 0)
Yes, that's OK.
/Tomas
signature.asc
Description: This is a digitally signed message part
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/3] avconv: warn about inappropriate output stream format
On Thu, 2012-10-25 at 11:37 +0200, Kostya Shishkov wrote:
> On Thu, Oct 25, 2012 at 11:30:02AM +0200, Tomas Härdin wrote:
> > On Thu, 2012-10-25 at 06:43 +0200, Kostya Shishkov wrote:
> > > On Wed, Oct 24, 2012 at 09:27:57PM +0200, Luca Barbato wrote:
> > > > On 10/24/2012 04:15 PM, Tomas Härdin wrote:
> > > > > Oh boy, here we go.
> > > > >
> > > > > On Wed, 2012-10-24 at 12:10 +0200, Kostya Shishkov wrote:
> > > > >> @@ -1605,6 +1606,12 @@ static int transcode_init(void)
> > > > >> codec->codec_tag = icodec->codec_tag;
> > > > >> }
> > > > >>
> > > > >> +desc = avcodec_descriptor_get(codec->codec_id);
> > > > >> +if (desc && (desc->props & AV_CODEC_PROP_IDIOTIC)) {
> > > > >
> > > > > AV_CODEC_PROP_IDIOTIC? How professional.
> > > >
> > > > Surely AV_CODEC_PROP_DISCOURAGED with a -strict suggest mode to output a
> > > > rationale on why certain codecs should not be generally used beside for
> > > > compatibility, might be a good service.
> > > >
> > > > The patchset as it doesn't really help anybody since "idiotic" as for
> > > > "lovely" is one of those English words with too many meanings and
> > > > nuances.
> > >
> > > This patchset was not serious and it should be obvious from the property
> > > name
> > > selection. But I hoped it might encourage people do something good
> > > instead.
> >
> > What about something like AV_CODEC_PROP_UNMAINTAINED?
>
> That's completely different - the original "intent" was to discourage users
> from creating new files with formats that are not well designed at best. For
> example, Monkey Audio is still maintained but I'd rather not see people
> encode in that format because it's horrible starting from container.
There doesn't appear to exist an encoder or muxer for Monkey's Audio, so
that point may be moot for that format. For the other formats it sounds
like you want to remove support for muxing them. If so, then remove that
support and prepare for user wrath. If not, then this seems pointless -
either you support the formats or you don't.
Oh, and I sincerely hope you're not talking about removing decoding
support, for any format. This doesn't seem to be the case, AFAICT (due
to codec->codec_id and ost->st->codec->codec_id).
/Tomas
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] mov: Do not apply dts shift from edit lists coming from data tracks.
On Thu, 2012-10-11 at 21:52 -0700, Alex Converse wrote:
> Some files in the wild have time code tracks with very negative initial
> offsets.
> ---
> libavformat/mov.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 63049f5..2a41dd5 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -1790,7 +1790,7 @@ static void mov_build_index(MOVContext *mov, AVStream
> *st)
> AVIndexEntry *mem;
>
> /* adjust first dts according to edit list */
> -if (sc->time_offset && mov->time_scale > 0) {
> +if (sc->time_offset && mov->time_scale > 0 && st->codec->codec_type !=
> AVMEDIA_TYPE_DATA) {
> if (sc->time_offset < 0)
> sc->time_offset = av_rescale(sc->time_offset, sc->time_scale,
> mov->time_scale);
> current_dts = -sc->time_offset;
Actually, the muxer should do no such shifting at all. Let an upper
layer take care of cutting the essence according to the EDL when
transcoding (if desired).
/Tomas
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/3] avconv: warn about inappropriate output stream format
On Thu, 2012-10-25 at 06:43 +0200, Kostya Shishkov wrote:
> On Wed, Oct 24, 2012 at 09:27:57PM +0200, Luca Barbato wrote:
> > On 10/24/2012 04:15 PM, Tomas Härdin wrote:
> > > Oh boy, here we go.
> > >
> > > On Wed, 2012-10-24 at 12:10 +0200, Kostya Shishkov wrote:
> > >> @@ -1605,6 +1606,12 @@ static int transcode_init(void)
> > >> codec->codec_tag = icodec->codec_tag;
> > >> }
> > >>
> > >> +desc = avcodec_descriptor_get(codec->codec_id);
> > >> +if (desc && (desc->props & AV_CODEC_PROP_IDIOTIC)) {
> > >
> > > AV_CODEC_PROP_IDIOTIC? How professional.
> >
> > Surely AV_CODEC_PROP_DISCOURAGED with a -strict suggest mode to output a
> > rationale on why certain codecs should not be generally used beside for
> > compatibility, might be a good service.
> >
> > The patchset as it doesn't really help anybody since "idiotic" as for
> > "lovely" is one of those English words with too many meanings and nuances.
>
> This patchset was not serious and it should be obvious from the property name
> selection. But I hoped it might encourage people do something good instead.
What about something like AV_CODEC_PROP_UNMAINTAINED?
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/3] avconv: warn about inappropriate output stream format
Oh boy, here we go.
On Wed, 2012-10-24 at 12:10 +0200, Kostya Shishkov wrote:
> @@ -1605,6 +1606,12 @@ static int transcode_init(void)
> codec->codec_tag = icodec->codec_tag;
> }
>
> +desc = avcodec_descriptor_get(codec->codec_id);
> +if (desc && (desc->props & AV_CODEC_PROP_IDIOTIC)) {
AV_CODEC_PROP_IDIOTIC? How professional.
> +av_log(NULL, AV_LOG_FATAL, "You are trying to copy stream in
> idiotic format, don't do that!\n");
What is the motivation behind this? To eventually remove support for
remuxing such formats? To tell users not to file tickets for code that
no one wants to touch? I'm curious.
> +// return AVERROR(EINVAL);
Useless.
> @@ -1810,6 +1818,13 @@ static int transcode_init(void)
> ost->file_index, ost->index);
> goto dump_format;
> }
> +
> +desc = avcodec_descriptor_get(ost->st->codec->codec_id);
> +if (desc && (desc->props & AV_CODEC_PROP_IDIOTIC)) {
> +av_log(NULL, AV_LOG_FATAL, "You are trying to encode stream
> in idiotic format, don't do that!\n");
If so, then why not remove those encoders?
/Tomas
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] img2dec: Don't leave AVIOContexts open on zero byte files
On Mon, 2012-09-10 at 11:19 +0200, Luca Barbato wrote: > On 9/10/12 10:52 AM, Tomas Härdin wrote: > > On Fri, 2012-09-07 at 11:03 +0200, Tomas Härdin wrote: > >> Hi > >> > >> The attached patch fixes img2dec leaving file descriptors/HTTP > >> connections/etc. open if an image sequence contains a zero-sized file. > >> > >> make fate ran fine. > > > > Here's a prettier patch. Re-ran FATE, works fine. Tested with both > > foo.jpeg and foo.Y/U/V > > > > Looks fine, might be nice set f[i] to NULL as well. Meh, they're not used any further in the function. Feel free to add an f[i] = NULL when pushing if you like. /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] img2dec: Don't leave AVIOContexts open on zero byte files
On Fri, 2012-09-07 at 11:03 +0200, Tomas Härdin wrote:
> Hi
>
> The attached patch fixes img2dec leaving file descriptors/HTTP
> connections/etc. open if an image sequence contains a zero-sized file.
>
> make fate ran fine.
Here's a prettier patch. Re-ran FATE, works fine. Tested with both
foo.jpeg and foo.Y/U/V
/Tomas
>From 9da8cef46914b420e392c03977047327ccc9de17 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Fri, 7 Sep 2012 13:28:48 +0200
Subject: [PATCH] img2dec: Don't leave AVIOContexts open on zero byte files
---
libavformat/img2dec.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index 2f5092f..1151180 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -216,7 +216,7 @@ static int read_packet(AVFormatContext *s1, AVPacket *pkt)
char filename[1024];
int i;
int size[3]={0}, ret[3]={0};
-AVIOContext *f[3];
+AVIOContext *f[3] = {NULL};
AVCodecContext *codec= s1->streams[0]->codec;
if (!s->is_pipe) {
@@ -232,7 +232,7 @@ static int read_packet(AVFormatContext *s1, AVPacket *pkt)
for(i=0; i<3; i++){
if (avio_open2(&f[i], filename, AVIO_FLAG_READ,
&s1->interrupt_callback, NULL) < 0) {
-if(i==1)
+if(i>=1)
break;
av_log(s1, AV_LOG_ERROR, "Could not open file : %s\n",filename);
return AVERROR(EIO);
@@ -259,7 +259,7 @@ static int read_packet(AVFormatContext *s1, AVPacket *pkt)
pkt->size= 0;
for(i=0; i<3; i++){
-if(size[i]){
+if(f[i]){
ret[i]= avio_read(f[i], pkt->data + pkt->size, size[i]);
if (!s->is_pipe)
avio_close(f[i]);
--
1.7.5.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] img2dec: Don't leave AVIOContexts open on zero byte files
Hi
The attached patch fixes img2dec leaving file descriptors/HTTP
connections/etc. open if an image sequence contains a zero-sized file.
make fate ran fine.
/Tomas
>From 9392598119ccbaaa943fa0bee83078ac8122d3dc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Fri, 7 Sep 2012 10:16:15 +0200
Subject: [PATCH] img2dec: Don't leave AVIOContexts open on zero byte files
---
libavformat/img2dec.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index 2f5092f..75a3c90 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -215,7 +215,7 @@ static int read_packet(AVFormatContext *s1, AVPacket *pkt)
VideoDemuxData *s = s1->priv_data;
char filename[1024];
int i;
-int size[3]={0}, ret[3]={0};
+int size[3]={0}, ret[3]={-1,-1,-1};
AVIOContext *f[3];
AVCodecContext *codec= s1->streams[0]->codec;
@@ -230,8 +230,8 @@ static int read_packet(AVFormatContext *s1, AVPacket *pkt)
s->path, s->img_number)<0 && s->img_number > 1)
return AVERROR(EIO);
for(i=0; i<3; i++){
-if (avio_open2(&f[i], filename, AVIO_FLAG_READ,
- &s1->interrupt_callback, NULL) < 0) {
+if ((ret[i] = avio_open2(&f[i], filename, AVIO_FLAG_READ,
+ &s1->interrupt_callback, NULL)) < 0) {
if(i==1)
break;
av_log(s1, AV_LOG_ERROR, "Could not open file : %s\n",filename);
@@ -250,6 +250,7 @@ static int read_packet(AVFormatContext *s1, AVPacket *pkt)
f[0] = s1->pb;
if (f[0]->eof_reached)
return AVERROR(EIO);
+ret[0] = 0;
size[0]= 4096;
}
@@ -259,7 +260,7 @@ static int read_packet(AVFormatContext *s1, AVPacket *pkt)
pkt->size= 0;
for(i=0; i<3; i++){
-if(size[i]){
+if(ret[i] >= 0){
ret[i]= avio_read(f[i], pkt->data + pkt->size, size[i]);
if (!s->is_pipe)
avio_close(f[i]);
@@ -268,7 +269,7 @@ static int read_packet(AVFormatContext *s1, AVPacket *pkt)
}
}
-if (ret[0] <= 0 || ret[1]<0 || ret[2]<0) {
+if (ret[0] <= 0 || (codec->codec_id == AV_CODEC_ID_RAWVIDEO && (ret[1]<0 || ret[2]<0))) {
av_free_packet(pkt);
return AVERROR(EIO); /* signal EOF */
} else {
--
1.7.5.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 09/10] mxfdec: Only parse next partition pack if parsing forward
On Tue, 2012-07-10 at 17:44 +0200, Luca Barbato wrote: > On 07/10/2012 04:19 PM, Tomas Härdin wrote: > > The backward parsing is due to PartitionPack not having any offset to > > the *next* partition - only the previous one (PreviousPartition). Since > > we don't want to parse the essence and in general can't skip over it (if > > it's frame wrapped, like OP1a), then we need to skip to FooterPartition, > > parse it and its metadata, then seek to its PreviousPartition, parse it > > etc. until we end up where we were when we stopped parsing forward. > > Brr > > > There's *supposed* to be a Random Index Pack at the very end of the > > file, but not all files have it. All files I've seen set > > PreviousPartition and FooterPartition correctly though. Hence this > > solution. > > > > A hypothetical file could have a RIP and no FooterPartition values set > > (like if muxed to a pipe), in which case you could fill in the > > PreviousPartition values from the RIP and use the current parsing code > > as-is. However, IIRC FooterPartition *must* be set so this point may be > > moot. > > > > Feel free to read SMPTE 377m if you're curious about the format, and the > > two dozen or so related specifications (S377m is very vague about how > > things like essence are *actually* written). > > Feels like rtp made even more hellish. > > If next morning I wake up early again I might give a stab at the encoder > side as well. I'll just note that I don't know that much about mxfenc. While you're at it you might want to cherry-pick the DNxHD and DV patches from FFmpeg (there's a couple in the works, so I'd wait a day or two). > Thanks for the help =) This way the reasoning behind the demuxer's logic is also archived somewhere for posterity :) /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 09/10] mxfdec: Only parse next partition pack if parsing forward
On Tue, 2012-07-10 at 13:03 +0200, Luca Barbato wrote: > On 07/10/2012 11:59 AM, Diego Biurrun wrote: > > On Tue, Jul 10, 2012 at 05:16:06AM +0200, Luca Barbato wrote: > >> > >> --- a/libavformat/mxfdec.c > >> +++ b/libavformat/mxfdec.c > >> @@ -1873,6 +1873,9 @@ static int mxf_read_header(AVFormatContext *s) > >> /* next partition pack - keep going, seek to previous > >> partition or stop */ > >> if(mxf_parse_handle_partition_or_eof(mxf) <= 0) > >> break; > >> +else if (mxf->parsing_backward) > >> +continue; > >> +/* we're still parsing forward. proceed to parsing this > >> partition pack */ > >> } > > > > The comment looks misplaced after the code. > > It is correct, assumed I understand completely how this two direction > parsing works. Basically once you parse an essence you run the parser > backwards. Depending on where you are while that happens you might end > up parsing the next pack instead of going back. The added lines ensure > you keep parsing backwards instead moving to the next partition. Correct. > I'm a bit curious about this format since this two direction parsing > seems quite original. The backward parsing is due to PartitionPack not having any offset to the *next* partition - only the previous one (PreviousPartition). Since we don't want to parse the essence and in general can't skip over it (if it's frame wrapped, like OP1a), then we need to skip to FooterPartition, parse it and its metadata, then seek to its PreviousPartition, parse it etc. until we end up where we were when we stopped parsing forward. There's *supposed* to be a Random Index Pack at the very end of the file, but not all files have it. All files I've seen set PreviousPartition and FooterPartition correctly though. Hence this solution. A hypothetical file could have a RIP and no FooterPartition values set (like if muxed to a pipe), in which case you could fill in the PreviousPartition values from the RIP and use the current parsing code as-is. However, IIRC FooterPartition *must* be set so this point may be moot. Feel free to read SMPTE 377m if you're curious about the format, and the two dozen or so related specifications (S377m is very vague about how things like essence are *actually* written). /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] mem: introduce av_malloc_array and av_mallocz_array
On Tue, 2012-07-10 at 02:27 +0200, Luca Barbato wrote: > Both function ease allocating large arrays implementing the overflow > check inside it. > --- > > I'd rather be self consistent, pick what you like best. > > libavutil/mem.h | 37 +++-- I suppose this is more consistent, and it'll (presumably) be merged into FFmpeg anyway, meaning subsequent mxfdec changes should merge fine, meaning less differences for me to deal with. /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] Add av_calloc() helper.
On Mon, 2012-07-09 at 14:28 +0200, Luca Barbato wrote:
> On 07/09/2012 12:18 PM, Måns Rullgård wrote:
> > Tomas Härdin writes:
> >
> >> On Sun, 2012-07-08 at 21:12 +0100, Måns Rullgård wrote:
> >>> Tomas Härdin writes:
> >>>> +void *av_calloc(size_t nmemb, size_t size)
> >>>> +{
> >>>> +if (size <= 0 || nmemb >= INT_MAX / size)
> >>>> +return NULL;
> >>>> +return av_mallocz(nmemb * size);
> >>>> +}
> >>>
> >>> The places where this would be used don't in general need zeroed memory.
> >>
> >> Indeed, but calloc() zeroes memory so I'd say it's expected behavior.
> >
> > That's a ridiculous argument. Give the function another name.
That just like, your opinion, man.
> What about something along the lines of
>
> #define av_malloc_array(nmemb, size) \
> av_malloc((size <= 0 || nmemb >= INT_MAX / size) ? 0 : nmemb * size);
Wouldn't a static inline be better, should someone do something like
av_malloc_array(avio_rb32(pb), sizeof(Foo))?
But whatever. I don't want to bikeshed over this. Just keep in mind that
BS like this puts me off porting mxfdec patches that apply cleanly to
FFmpeg to Libav.
/Tomas
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] Add av_calloc() helper.
On Sun, 2012-07-08 at 18:44 +0200, Luca Barbato wrote: > I thought you were making it an inline. Normal function -> smaller binaries. Also, this patch already existed -> less work. /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] Add av_calloc() helper.
On Sun, 2012-07-08 at 21:12 +0100, Måns Rullgård wrote:
> Tomas Härdin writes:
> > +void *av_calloc(size_t nmemb, size_t size)
> > +{
> > +if (size <= 0 || nmemb >= INT_MAX / size)
> > +return NULL;
> > +return av_mallocz(nmemb * size);
> > +}
>
> The places where this would be used don't in general need zeroed memory.
Indeed, but calloc() zeroes memory so I'd say it's expected behavior.
/Tomas
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] Add av_calloc() helper.
On Sun, 2012-07-08 at 18:06 +0200, Diego Biurrun wrote:
> On Sun, Jul 08, 2012 at 05:18:23PM +0200, Tomas Härdin wrote:
> > --- a/libavutil/mem.h
> > +++ b/libavutil/mem.h
> > @@ -113,6 +113,18 @@ void av_free(void *ptr);
> >
> > /**
> > + * Allocate a block of nmemb * size bytes with alignment suitable for all
> > + * memory accesses (including vectors if available on the CPU) and
> > + * zero all the bytes of the block.
> > + * The allocation will fail if nmemb * size is greater than or equal
> > + * to INT_MAX.
> > + * @param nmemb
> > + * @param size
> > + * @return Pointer to the allocated block, NULL if it cannot be allocated.
> > + */
> > +void *av_calloc(size_t nmemb, size_t size) av_malloc_attrib;
>
> Please fix the @param descriptions and squash patch 2/2 into this one.
> Otherwise LGTM.
Done. I kept the original author since the changes to the patch are
trivial.
/Tomas
>From f5d4ce51915b02e440c6598ca601185b725771fc Mon Sep 17 00:00:00 2001
From: Laurent Aimar
Date: Sat, 24 Sep 2011 18:39:13 +0200
Subject: [PATCH] Add av_calloc() helper and bump lavu minor version
Signed-off-by: Michael Niedermayer
---
doc/APIchanges |3 +++
libavutil/mem.c |7 +++
libavutil/mem.h | 12
libavutil/version.h |2 +-
4 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 990e36e..80b9518 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -13,6 +13,9 @@ libavutil: 2011-04-18
API changes, most recent first:
+2012-07-08 - xxx - lavu 51.37.0
+ Add av_calloc()
+
2012-06-22 - xxx - lavu 51.34.0
Add av_usleep()
diff --git a/libavutil/mem.c b/libavutil/mem.c
index 0fe9f54..45b024d 100644
--- a/libavutil/mem.c
+++ b/libavutil/mem.c
@@ -167,6 +167,13 @@ void *av_mallocz(size_t size)
return ptr;
}
+void *av_calloc(size_t nmemb, size_t size)
+{
+if (size <= 0 || nmemb >= INT_MAX / size)
+return NULL;
+return av_mallocz(nmemb * size);
+}
+
char *av_strdup(const char *s)
{
char *ptr= NULL;
diff --git a/libavutil/mem.h b/libavutil/mem.h
index cd8490b..4eb8f1b 100644
--- a/libavutil/mem.h
+++ b/libavutil/mem.h
@@ -113,6 +113,18 @@ void av_free(void *ptr);
void *av_mallocz(size_t size) av_malloc_attrib av_alloc_size(1);
/**
+ * Allocate a block of nmemb * size bytes with alignment suitable for all
+ * memory accesses (including vectors if available on the CPU) and
+ * zero all the bytes of the block.
+ * The allocation will fail if nmemb * size is greater than or equal
+ * to INT_MAX.
+ * @param nmemb Number of elements to allocate
+ * @param size The size of each element in bytes
+ * @return Pointer to the allocated block, NULL if it cannot be allocated.
+ */
+void *av_calloc(size_t nmemb, size_t size) av_malloc_attrib;
+
+/**
* Duplicate the string s.
* @param s string to be duplicated
* @return Pointer to a newly allocated string containing a
diff --git a/libavutil/version.h b/libavutil/version.h
index c42c6b0..f55a99f 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -37,7 +37,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 51
-#define LIBAVUTIL_VERSION_MINOR 36
+#define LIBAVUTIL_VERSION_MINOR 37
#define LIBAVUTIL_VERSION_MICRO 0
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
--
1.7.5.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 2/2] lavu: Bump minor version for av_calloc()
>From f247a5c2c4c61dc5b3fecf348d90f1655ad1bcbe Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= Date: Sun, 8 Jul 2012 16:17:37 +0200 Subject: [PATCH 2/2] lavu: Bump minor version for av_calloc() --- doc/APIchanges |3 +++ libavutil/version.h |2 +- 2 files changed, 4 insertions(+), 1 deletions(-) diff --git a/doc/APIchanges b/doc/APIchanges index 990e36e..80b9518 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -13,6 +13,9 @@ libavutil: 2011-04-18 API changes, most recent first: +2012-07-08 - xxx - lavu 51.37.0 + Add av_calloc() + 2012-06-22 - xxx - lavu 51.34.0 Add av_usleep() diff --git a/libavutil/version.h b/libavutil/version.h index c42c6b0..f55a99f 100644 --- a/libavutil/version.h +++ b/libavutil/version.h @@ -37,7 +37,7 @@ */ #define LIBAVUTIL_VERSION_MAJOR 51 -#define LIBAVUTIL_VERSION_MINOR 36 +#define LIBAVUTIL_VERSION_MINOR 37 #define LIBAVUTIL_VERSION_MICRO 0 #define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \ -- 1.7.5.4 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 1/2] Add av_calloc() helper.
Hi
The attached patch adds av_calloc() to libavutil.
See the mxfdec thread ("[PATCH] mxfdec: replace x>>av_log2(sizeof(..))
by x/sizeof(..)"). This allows for simpler, smaller code and smaller
binaries.
/Tomas
>From f614808c28a58c14906c81962871d2c2dfc73afe Mon Sep 17 00:00:00 2001
From: Laurent Aimar
Date: Sat, 24 Sep 2011 18:39:13 +0200
Subject: [PATCH 1/2] Add av_calloc() helper.
Signed-off-by: Michael Niedermayer
---
libavutil/mem.c |7 +++
libavutil/mem.h | 12
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/libavutil/mem.c b/libavutil/mem.c
index 0fe9f54..45b024d 100644
--- a/libavutil/mem.c
+++ b/libavutil/mem.c
@@ -167,6 +167,13 @@ void *av_mallocz(size_t size)
return ptr;
}
+void *av_calloc(size_t nmemb, size_t size)
+{
+if (size <= 0 || nmemb >= INT_MAX / size)
+return NULL;
+return av_mallocz(nmemb * size);
+}
+
char *av_strdup(const char *s)
{
char *ptr= NULL;
diff --git a/libavutil/mem.h b/libavutil/mem.h
index cd8490b..042bbaf 100644
--- a/libavutil/mem.h
+++ b/libavutil/mem.h
@@ -113,6 +113,18 @@ void av_free(void *ptr);
void *av_mallocz(size_t size) av_malloc_attrib av_alloc_size(1);
/**
+ * Allocate a block of nmemb * size bytes with alignment suitable for all
+ * memory accesses (including vectors if available on the CPU) and
+ * zero all the bytes of the block.
+ * The allocation will fail if nmemb * size is greater than or equal
+ * to INT_MAX.
+ * @param nmemb
+ * @param size
+ * @return Pointer to the allocated block, NULL if it cannot be allocated.
+ */
+void *av_calloc(size_t nmemb, size_t size) av_malloc_attrib;
+
+/**
* Duplicate the string s.
* @param s string to be duplicated
* @return Pointer to a newly allocated string containing a
--
1.7.5.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] mxfdec: replace x>>av_log2(sizeof(..)) by x/sizeof(..).
On Wed, 2012-07-04 at 14:02 -0700, Ronald S. Bultje wrote: > > Why not simply add av_calloc() to lavu and use it? These kind of > > allocations are all over the place - it'd make them prettier. I've > > suggested this before in [1]. You could even have it static inline. > > > > IMO muxers shouldn't have to care about whatever the maximum allocation > > size is. That would also allow changing said size more easily (it'd be > > confined to mem.*) > > > > [1] http://www.mail-archive.com/libav-devel@libav.org/msg16665.html > > I'd say send a patch? Also, it'd be faster if av_calloc() were inlined > in a header file, since then the division (INT_MAX / sizeof(..)) can > be done by the compiler. Call overhead is not a problem (if it were then there are too many allocations). Using a function would result in smaller code which I'd say is a plus when speed isn't an issue. On Wed, 2012-07-04 at 21:32 +0200, Luca Barbato wrote: > You wouldn't have to check nonetheless? av_calloc() would return NULL if the allocation is too large. Anyway, I'll cobble together a patch. /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] mxfdec: replace x>>av_log2(sizeof(..)) by x/sizeof(..).
On Wed, 2012-07-04 at 12:14 +0100, Måns Rullgård wrote: > Kostya Shishkov writes: > > > On Wed, Jul 04, 2012 at 11:09:57AM +0100, Måns Rullgård wrote: > >> "Ronald S. Bultje" writes: > >> > >> > From: "Ronald S. Bultje" > >> > > >> > --- > >> > libavformat/mxfdec.c |8 > >> > 1 file changed, 4 insertions(+), 4 deletions(-) > >> > > >> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c > >> > index dd10240..a7c1890 100644 > >> > --- a/libavformat/mxfdec.c > >> > +++ b/libavformat/mxfdec.c > >> > @@ -700,7 +700,7 @@ static int mxf_read_index_entry_array(AVIOContext > >> > *pb, MXFIndexTableSegment *seg > >> > return 0; > >> > else if (segment->nb_index_entries < 0 || > >> > segment->nb_index_entries > > >> > - (INT_MAX >> > >> > av_log2(sizeof(*segment->stream_offset_entries > >> > + (INT_MAX / sizeof(*segment->stream_offset_entries))) > >> > return AVERROR(ENOMEM); > >> > > >> > length = avio_rb32(pb); > >> > @@ -1084,7 +1084,7 @@ static int mxf_compute_ptses_fake_index(MXFContext > >> > *mxf, MXFIndexTable *index_ta > >> > if (index_table->nb_ptses <= 0) > >> > return 0; > >> > > >> > -if (index_table->nb_ptses > INT_MAX >> > >> > av_log2(sizeof(AVIndexEntry)) + 1) > >> > +if (index_table->nb_ptses >= INT_MAX / sizeof(AVIndexEntry)) > >> > return AVERROR(ENOMEM); > >> > >> What happened to the +1? > > > > merged with > to make >= ? > > But that's not equivalent. It's INT_MAX >> (foo + 1), so the equivalent > division is INT_MAX / (2 * bar). Why use a shift in the first place? Anyway, since it's checking that an allocation is < INT_MAX a normal division should work well enough. x*(INT_MAX/x) <= INT_MAX. So >=. Why not simply add av_calloc() to lavu and use it? These kind of allocations are all over the place - it'd make them prettier. I've suggested this before in [1]. You could even have it static inline. IMO muxers shouldn't have to care about whatever the maximum allocation size is. That would also allow changing said size more easily (it'd be confined to mem.*) [1] http://www.mail-archive.com/libav-devel@libav.org/msg16665.html /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 04/14] avcodec: add YCgCo color space.
On Sun, 2012-04-29 at 13:33 -0400, Derek Buitenhuis wrote:
> From: Hendrik Leppkes
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/avcodec.h |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 0fda1cb..2bd8ed2 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -500,6 +500,7 @@ enum AVColorSpace{
> AVCOL_SPC_BT470BG=5, ///< also ITU-R BT601-6 625 / ITU-R BT1358 625
> / ITU-R BT1700 625 PAL & SECAM / IEC 61966-2-4 xvYCC601
> AVCOL_SPC_SMPTE170M =6, ///< also ITU-R BT601-6 525 / ITU-R BT1358 525
> / ITU-R BT1700 NTSC / functionally identical to above
> AVCOL_SPC_SMPTE240M =7,
> +AVCOL_SPC_YCGCO =8,
AVCOL_SPC_YCOCG perhaps?
/Tomas
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] aiffdec: Fix SIGFPE on pcm_f32be
On Wed, 2012-03-21 at 10:50 -0700, Ronald S. Bultje wrote: > Hi, > > On Wed, Mar 21, 2012 at 5:17 AM, Tomas Härdin > wrote: > > Hi > > > > Running ffprobe/avprobe on > > http://titan.codemill.se/~tomhar/samples/sigfpe.aif results in SIGFPE at > > libavformat/aiffdec.c:162 since aiff->block_duration == 0. > > Attached patch sets block_duration = 1 in the default case. Fixes the > > problem for both projects. > > But that value is not correct. Shouldn't we error out? No idea. Shouldn't all normal PCM formats work kind of the same (have block_duration = 1)? I could understand GSM, QCELP etc. needing special values. Maybe not all PCM variants can be muxed in AIFF-C? Nothing in the code suggests this though. /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] aiffdec: Fix SIGFPE on pcm_f32be
Hi Running ffprobe/avprobe on http://titan.codemill.se/~tomhar/samples/sigfpe.aif results in SIGFPE at libavformat/aiffdec.c:162 since aiff->block_duration == 0. Attached patch sets block_duration = 1 in the default case. Fixes the problem for both projects. /Tomas >From 4923a8eef9273ca993a8818a9cdea1b5be906e01 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= Date: Wed, 21 Mar 2012 13:05:34 +0100 Subject: [PATCH] aiffdec: Fix SIGFPE on pcm_f32be --- libavformat/aiffdec.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/libavformat/aiffdec.c b/libavformat/aiffdec.c index ee4fbde..21b85e7 100644 --- a/libavformat/aiffdec.c +++ b/libavformat/aiffdec.c @@ -144,6 +144,7 @@ static unsigned int get_aiff_header(AVFormatContext *s, int size, aiff->block_duration = 160; break; default: +aiff->block_duration = 1; break; } size -= 4; -- 1.7.5.4 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 01/16] mxfdec: Ignore the last entry in Avid's index table segments
Ping? Some of these fix crashes and/or hangs.. /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] mxfdec: Sanity-check SampleRate
This avoids a SIGFPE if SampleRate is missing or set to naughty values.
---
libavformat/mxfdec.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 9051874..38a0fe9 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1405,7 +1405,10 @@ static int mxf_parse_structural_metadata(MXFContext *mxf)
st->codec->codec_id = container_ul->id;
st->codec->channels = descriptor->channels;
st->codec->bits_per_coded_sample = descriptor->bits_per_sample;
-st->codec->sample_rate = descriptor->sample_rate.num /
descriptor->sample_rate.den;
+
+if (descriptor->sample_rate.den > 0)
+st->codec->sample_rate = descriptor->sample_rate.num /
descriptor->sample_rate.den;
+
/* TODO: implement CODEC_ID_RAWAUDIO */
if (st->codec->codec_id == CODEC_ID_PCM_S16LE) {
if (descriptor->bits_per_sample > 16 &&
descriptor->bits_per_sample <= 24)
--
1.7.5.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 15/16] mxfdec: Handle small EditUnitByteCount
These are common with audio atoms. Without this the demuxer would read two
bytes at a time for a mono 16-bit file.
---
libavformat/mxfdec.c | 43 +--
1 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index cf9751a..d385a7e 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -207,6 +207,7 @@ typedef struct {
int current_edit_unit;
int nb_index_tables;
MXFIndexTable *index_tables;
+int edit_units_per_packet; ///< how many edit units to read at a time
(PCM, OPAtom)
} MXFContext;
enum MXFWrappingScheme {
@@ -1678,6 +1679,38 @@ static inline void
compute_partition_essence_offset(AVFormatContext *s,
}
}
+static int is_pcm(enum CodecID codec_id)
+{
+/* we only care about "normal" PCM codecs until we get samples */
+return codec_id >= CODEC_ID_PCM_S16LE && codec_id < CODEC_ID_PCM_S24DAUD;
+}
+
+/**
+ * Deals with the case where for some audio atoms EditUnitByteCount is very
small (2, 4..).
+ * In those cases we should read more than one sample per call to
mxf_read_packet().
+ */
+static void mxf_handle_small_eubc(AVFormatContext *s)
+{
+MXFContext *mxf = s->priv_data;
+
+/* assuming non-OPAtom == frame wrapped
+ * no sane writer would wrap 2 byte PCM packets with 20 byte headers.. */
+if (mxf->op != OPAtom)
+return;
+
+/* expect PCM with exactly one index table segment and a small (< 32) EUBC
*/
+if (s->nb_streams != 1 || s->streams[0]->codec->codec_type !=
AVMEDIA_TYPE_AUDIO ||
+!is_pcm(s->streams[0]->codec->codec_id) || mxf->nb_index_tables != 1 ||
+mxf->index_tables[0].nb_segments != 1 ||
+mxf->index_tables[0].segments[0]->edit_unit_byte_count >= 32)
+return;
+
+/* arbitrarily default to 48 kHz PAL audio frame size */
+/* TODO: we could compute this from the ratio between the audio and video
edit rates
+ * for 48 kHz NTSC we could use the 1802-1802-1802-1802-1801 pattern
*/
+mxf->edit_units_per_packet = 1920;
+}
+
static int mxf_read_header(AVFormatContext *s, AVFormatParameters *ap)
{
MXFContext *mxf = s->priv_data;
@@ -1686,6 +1719,7 @@ static int mxf_read_header(AVFormatContext *s,
AVFormatParameters *ap)
int ret;
mxf->last_forward_tell = INT64_MAX;
+mxf->edit_units_per_packet = 1;
if (!mxf_read_sync(s->pb, mxf_header_partition_pack_key, 14)) {
av_log(s, AV_LOG_ERROR, "could not find header partition pack key\n");
@@ -1790,6 +1824,8 @@ static int mxf_read_header(AVFormatContext *s,
AVFormatParameters *ap)
return AVERROR_INVALIDDATA;
}
+mxf_handle_small_eubc(s);
+
return 0;
}
@@ -1889,6 +1925,7 @@ static int mxf_read_packet(AVFormatContext *s, AVPacket
*pkt)
int64_t ret64, pos, next_pos;
AVStream *st;
MXFIndexTable *t;
+int edit_units;
if (mxf->op != OPAtom)
return mxf_read_packet_old(s, pkt);
@@ -1901,12 +1938,14 @@ static int mxf_read_packet(AVFormatContext *s, AVPacket
*pkt)
if (mxf->current_edit_unit >= st->duration)
return AVERROR_EOF;
+edit_units = FFMIN(mxf->edit_units_per_packet, st->duration -
mxf->current_edit_unit);
+
if ((ret = mxf_edit_unit_absolute_offset(mxf, t, mxf->current_edit_unit,
NULL, &pos, 1)) < 0)
return ret;
/* compute size by finding the next edit unit or the end of the essence
container
* not pretty, but it works */
-if ((ret = mxf_edit_unit_absolute_offset(mxf, t, mxf->current_edit_unit +
1, NULL, &next_pos, 0)) < 0 &&
+if ((ret = mxf_edit_unit_absolute_offset(mxf, t, mxf->current_edit_unit +
edit_units, NULL, &next_pos, 0)) < 0 &&
(next_pos = mxf_essence_container_end(mxf, t->body_sid)) <= 0) {
av_log(s, AV_LOG_ERROR, "unable to compute the size of the last
packet\n");
return AVERROR_INVALIDDATA;
@@ -1930,7 +1969,7 @@ static int mxf_read_packet(AVFormatContext *s, AVPacket
*pkt)
}
pkt->stream_index = 0;
-mxf->current_edit_unit++;
+mxf->current_edit_unit += edit_units;
return 0;
}
--
1.7.5.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 06/16] mxfdec: Check eof_reached in mxf_read_local_tags()
This fixes the infinite loop with zzuf2.mxf
---
libavformat/mxfdec.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 6c3f0e2..28e8588 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1472,7 +1472,7 @@ static int mxf_read_local_tags(MXFContext *mxf, KLVPacket
*klv, MXFMetadataReadF
if (!ctx)
return AVERROR(ENOMEM);
-while (avio_tell(pb) + 4 < klv_end) {
+while (avio_tell(pb) + 4 < klv_end && !pb->eof_reached) {
int ret;
int tag = avio_rb16(pb);
int size = avio_rb16(pb); /* KLV specified by 0x53 */
--
1.7.5.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 16/16] mxfdec: Fix files > 2 GiB
Accumulating into an int would cause overflow for files with essence
containers larger than 2 GiB.
---
libavformat/mxfdec.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index d385a7e..c09893f 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1010,7 +1010,7 @@ static int64_t mxf_essence_container_end(MXFContext *mxf,
int body_sid)
static int mxf_edit_unit_absolute_offset(MXFContext *mxf, MXFIndexTable
*index_table, int64_t edit_unit, int64_t *edit_unit_out, int64_t *offset_out,
int nag)
{
int i;
-int offset_temp = 0;
+int64_t offset_temp = 0;
for (i = 0; i < index_table->nb_segments; i++) {
MXFIndexTableSegment *s = index_table->segments[i];
--
1.7.5.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 11/16] mxfdec: Zero nb_ptses in mxf_compute_ptses_fake_index()
This fixes SIGSEGV on files with both CBR and VBR index segments (zzuf6.mxf).
---
libavformat/mxfdec.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 0091582..08a5562 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1051,8 +1051,10 @@ static int mxf_compute_ptses_fake_index(MXFContext *mxf,
MXFIndexTable *index_ta
for (i = 0; i < index_table->nb_segments; i++) {
MXFIndexTableSegment *s = index_table->segments[i];
-if (!s->nb_index_entries)
+if (!s->nb_index_entries) {
+index_table->nb_ptses = 0;
return 0; /* no TemporalOffsets */
+}
index_table->nb_ptses += s->index_duration;
}
--
1.7.5.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 14/16] mxfdec: Consider OPAtom files that don't have exactly one EC to be OP1a
This fixes demuxing of 2011_DCPTEST_24FPS.V.mxf.
Signed-off-by: Michael Niedermayer
---
libavformat/mxfdec.c | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 88142ca..cf9751a 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -59,7 +59,7 @@ typedef enum {
} MXFPartitionType;
typedef enum {
-OP1a,
+OP1a = 1,
OP1b,
OP1c,
OP2a,
@@ -410,6 +410,7 @@ static int mxf_read_partition_pack(void *arg, AVIOContext
*pb, int tag, int size
MXFPartition *partition, *tmp_part;
UID op;
uint64_t footer_partition;
+uint32_t nb_essence_containers;
if (mxf->partitions_count+1 >= UINT_MAX / sizeof(*mxf->partitions))
return AVERROR(ENOMEM);
@@ -464,6 +465,7 @@ static int mxf_read_partition_pack(void *arg, AVIOContext
*pb, int tag, int size
avio_skip(pb, 8);
partition->body_sid = avio_rb32(pb);
avio_read(pb, op, sizeof(UID));
+nb_essence_containers = avio_rb32(pb);
/* some files don'thave FooterPartition set in every partition */
if (footer_partition) {
@@ -497,9 +499,19 @@ static int mxf_read_partition_pack(void *arg, AVIOContext
*pb, int tag, int size
else if (op[12] == 3 && op[13] == 1) mxf->op = OP3a;
else if (op[12] == 3 && op[13] == 2) mxf->op = OP3b;
else if (op[12] == 3 && op[13] == 3) mxf->op = OP3c;
-else if (op[12] == 0x10) mxf->op = OPAtom;
else if (op[12] == 64&& op[13] == 1) mxf->op = OPSonyOpt;
-else {
+else if (op[12] == 0x10) {
+/* SMPTE 390m: "There shall be exactly one essence container"
+ * 2011_DCPTEST_24FPS.V.mxf violates this and is frame wrapped, hence
why we assume OP1a */
+if (nb_essence_containers != 1) {
+/* only nag once */
+if (!mxf->op)
+av_log(mxf->fc, AV_LOG_WARNING, "\"OPAtom\" with %u ECs -
assuming OP1a\n", nb_essence_containers);
+
+mxf->op = OP1a;
+} else
+mxf->op = OPAtom;
+} else {
av_log(mxf->fc, AV_LOG_ERROR, "unknown operational pattern: %02xh
%02xh - guessing OP1a\n", op[12], op[13]);
mxf->op = OP1a;
}
--
1.7.5.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 08/16] mxfdec: Move the current_partition check inside mxf_read_header()
This fixes SIGSEGV on files where this is actually the case, such as zzuf4.mxf
---
libavformat/mxfdec.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 4ac90cd..6ae2b24 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1536,11 +1536,6 @@ static int mxf_parse_handle_essence(MXFContext *mxf)
AVIOContext *pb = mxf->fc->pb;
int64_t ret;
-if (!mxf->current_partition) {
-av_log(mxf->fc, AV_LOG_ERROR, "found essence prior to
PartitionPack\n");
-return AVERROR_INVALIDDATA;
-}
-
if (mxf->parsing_backward) {
return mxf_seek_to_previous_partition(mxf);
} else {
@@ -1689,6 +1684,12 @@ static int mxf_read_header(AVFormatContext *s,
AVFormatParameters *ap)
IS_KLV_KEY(klv.key, mxf_essence_element_key) ||
IS_KLV_KEY(klv.key, mxf_avid_essence_element_key) ||
IS_KLV_KEY(klv.key, mxf_system_item_key)) {
+
+if (!mxf->current_partition) {
+av_log(mxf->fc, AV_LOG_ERROR, "found essence prior to first
PartitionPack\n");
+return AVERROR_INVALIDDATA;
+}
+
if (!mxf->current_partition->essence_offset) {
compute_partition_essence_offset(s, mxf, &klv);
}
--
1.7.5.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 12/16] mxfdec: Don't crash in mxf_packet_timestamps() if current_edit_unit overflows
---
libavformat/mxfdec.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 08a5562..a3487bc 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1794,7 +1794,7 @@ static void mxf_packet_timestamps(MXFContext *mxf,
AVPacket *pkt)
return;
/* find mxf->current_edit_unit so that the next edit unit starts ahead of
pkt->pos */
-for (;;) {
+while (mxf->current_edit_unit >= 0) {
if (mxf_edit_unit_absolute_offset(mxf, t, mxf->current_edit_unit + 1,
NULL, &next_ofs, 0) < 0)
break;
@@ -1812,7 +1812,7 @@ static void mxf_packet_timestamps(MXFContext *mxf,
AVPacket *pkt)
mxf->current_edit_unit++;
}
-if (mxf->current_edit_unit >= t->nb_ptses)
+if (mxf->current_edit_unit < 0 || mxf->current_edit_unit >= t->nb_ptses)
return;
pkt->dts = mxf->current_edit_unit + t->first_dts;
--
1.7.5.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 13/16] mxfdec: change av_log formatting %lx to PRIx64 and %li to PRIi64
From: Jean First
Signed-off-by: Jean First
Signed-off-by: Michael Niedermayer
---
libavformat/mxfdec.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index a3487bc..88142ca 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -468,15 +468,15 @@ static int mxf_read_partition_pack(void *arg, AVIOContext
*pb, int tag, int size
/* some files don'thave FooterPartition set in every partition */
if (footer_partition) {
if (mxf->footer_partition && mxf->footer_partition !=
footer_partition) {
-av_log(mxf->fc, AV_LOG_ERROR, "inconsistent FooterPartition value:
%li != %li\n",
+av_log(mxf->fc, AV_LOG_ERROR, "inconsistent FooterPartition value:
%" PRIi64 " != %" PRIi64 "\n",
mxf->footer_partition, footer_partition);
} else {
mxf->footer_partition = footer_partition;
}
}
-av_dlog(mxf->fc, "PartitionPack: ThisPartition = 0x%lx, PreviousPartition
= 0x%lx, "
-"FooterPartition = 0x%lx, IndexSID = %i, BodySID = %i\n",
+av_dlog(mxf->fc, "PartitionPack: ThisPartition = 0x%" PRIx64 ",
PreviousPartition = 0x%" PRIx64 ", "
+"FooterPartition = 0x%" PRIx64 ", IndexSID = %i, BodySID = %i\n",
partition->this_partition,
partition->previous_partition, footer_partition,
partition->index_sid, partition->body_sid);
@@ -964,7 +964,7 @@ static int mxf_absolute_bodysid_offset(MXFContext *mxf, int
body_sid, int64_t of
offset -= p->essence_length;
}
-av_log(mxf->fc, AV_LOG_ERROR, "failed to find absolute offset of %lx in
BodySID %i - partial file?\n",
+av_log(mxf->fc, AV_LOG_ERROR, "failed to find absolute offset of %"
PRIx64" in BodySID %i - partial file?\n",
offset_in, body_sid);
return AVERROR_INVALIDDATA;
@@ -1620,7 +1620,7 @@ static void mxf_compute_essence_containers(MXFContext
*mxf)
if (p->essence_length < 0) {
/* next ThisPartition < essence_offset */
p->essence_length = 0;
-av_log(mxf->fc, AV_LOG_ERROR, "partition %i: bad ThisPartition =
%lx\n",
+av_log(mxf->fc, AV_LOG_ERROR, "partition %i: bad ThisPartition =
%" PRIx64 "\n",
x+1, mxf->partitions[x+1].this_partition);
}
}
--
1.7.5.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 09/16] mxfdec: Never seek back in local sets and KLVs
Specially crafted files can lead the parsing code to take too long.
We fix a lot of these problems by not allowing local tags to extend past the
end of the set and not allowing other KLVs to be read past the end of
themselves.
---
libavformat/mxfdec.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 6ae2b24..75c5e30 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1500,6 +1500,13 @@ static int mxf_read_local_tags(MXFContext *mxf,
KLVPacket *klv, MXFMetadataReadF
else if ((ret = read_child(ctx, pb, tag, size, uid, -1)) < 0)
return ret;
+/* accept the 64k local set limit being exceeded (Avid)
+ * don't accept it extending past the end of the KLV though
(zzuf5.mxf) */
+if (avio_tell(pb) > klv_end) {
+av_log(mxf->fc, AV_LOG_ERROR, "local tag %#04x extends past end of
local set @ %#"PRIx64"\n",
+ tag, klv->offset);
+return AVERROR_INVALIDDATA;
+} else if (avio_tell(pb) <= next) /* only seek forward, else this
can loop for a long time */
avio_seek(pb, next, SEEK_SET);
}
if (ctx_size) ctx->type = type;
@@ -1716,6 +1723,14 @@ static int mxf_read_header(AVFormatContext *s,
AVFormatParameters *ap)
} else {
uint64_t next = avio_tell(s->pb) + klv.length;
res = metadata->read(mxf, s->pb, 0, klv.length, klv.key,
klv.offset);
+
+/* only seek forward, else this can loop for a long time */
+if (avio_tell(s->pb) > next) {
+av_log(s, AV_LOG_ERROR, "read past end of KLV @
%#"PRIx64"\n",
+ klv.offset);
+return AVERROR_INVALIDDATA;
+}
+
avio_seek(s->pb, next, SEEK_SET);
}
if (res < 0) {
--
1.7.5.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 07/16] mxfdec: Fix infinite loop in mxf_packet_timestamps()
This can happen if an index table segment has a very large IndexStartPosition.
zzuf3.mxf is an example of such a file.
---
libavformat/mxfdec.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 28e8588..4ac90cd 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1761,7 +1761,7 @@ static int mxf_read_header(AVFormatContext *s,
AVFormatParameters *ap)
*/
static void mxf_packet_timestamps(MXFContext *mxf, AVPacket *pkt)
{
-int64_t next_ofs;
+int64_t last_ofs = -1, next_ofs;
MXFIndexTable *t = &mxf->index_tables[0];
/* this is called from the OP1a demuxing logic, which means there may be
no index tables */
@@ -1773,9 +1773,17 @@ static void mxf_packet_timestamps(MXFContext *mxf,
AVPacket *pkt)
if (mxf_edit_unit_absolute_offset(mxf, t, mxf->current_edit_unit + 1,
NULL, &next_ofs, 0) < 0)
break;
+if (next_ofs <= last_ofs) {
+/* large next_ofs didn't change or current_edit_unit wrapped around
+ * this fixes the infinite loop on zzuf3.mxf */
+av_log(mxf->fc, AV_LOG_ERROR, "next_ofs didn't change. not
deriving packet timestamps\n");
+return;
+}
+
if (next_ofs > pkt->pos)
break;
+last_ofs = next_ofs;
mxf->current_edit_unit++;
}
--
1.7.5.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 10/16] mxfdec: Sanity check PreviousPartition
Without this certain files could get the demuxer stuck in a loop
---
libavformat/mxfdec.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 75c5e30..0091582 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -481,6 +481,13 @@ static int mxf_read_partition_pack(void *arg, AVIOContext
*pb, int tag, int size
partition->previous_partition, footer_partition,
partition->index_sid, partition->body_sid);
+/* sanity check PreviousPartition if set */
+if (partition->previous_partition &&
+mxf->run_in + partition->previous_partition >= klv_offset) {
+av_log(mxf->fc, AV_LOG_ERROR, "PreviousPartition points to this
partition or forward\n");
+return AVERROR_INVALIDDATA;
+}
+
if (op[12] == 1 && op[13] == 1) mxf->op = OP1a;
else if (op[12] == 1 && op[13] == 2) mxf->op = OP1b;
else if (op[12] == 1 && op[13] == 3) mxf->op = OP1c;
--
1.7.5.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 03/16] mxfdec: Make sure mxf->nb_index_tables > 0 in mxf_packet_timestamps()
Only the OPAtom demuxing logic is guaranteed to have index tables, meaning OP1a
files that lack an index would cause SIGSEGV.
---
libavformat/mxfdec.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index fb9cac4..9051874 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1763,6 +1763,10 @@ static void mxf_packet_timestamps(MXFContext *mxf,
AVPacket *pkt)
int64_t next_ofs;
MXFIndexTable *t = &mxf->index_tables[0];
+/* this is called from the OP1a demuxing logic, which means there may be
no index tables */
+if (mxf->nb_index_tables <= 0)
+return;
+
/* find mxf->current_edit_unit so that the next edit unit starts ahead of
pkt->pos */
for (;;) {
if (mxf_edit_unit_absolute_offset(mxf, t, mxf->current_edit_unit + 1,
NULL, &next_ofs, 0) < 0)
@@ -1844,6 +1848,7 @@ static int mxf_read_packet(AVFormatContext *s, AVPacket
*pkt)
return mxf_read_packet_old(s, pkt);
/* OPAtom - clip wrapped demuxing */
+/* NOTE: mxf_read_header() makes sure nb_index_tables > 0 for OPAtom */
st = s->streams[0];
t = &mxf->index_tables[0];
--
1.7.5.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 01/16] mxfdec: Ignore the last entry in Avid's index table segments
The last entry is the total size of the essence container.
Previously a TemporalOffset error would be logged, even though segments like
these are expected.
---
libavformat/mxfdec.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 0b514db..fa2bb65 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1101,11 +1101,16 @@ static int mxf_compute_ptses_fake_index(MXFContext
*mxf, MXFIndexTable *index_ta
for (i = x = 0; i < index_table->nb_segments; i++) {
MXFIndexTableSegment *s = index_table->segments[i];
int index_delta = 1;
+int n = s->nb_index_entries;
-if (s->nb_index_entries == 2 * s->index_duration + 1)
+if (s->nb_index_entries == 2 * s->index_duration + 1) {
index_delta = 2;/* Avid index */
-for (j = 0; j < s->nb_index_entries; j += index_delta, x++) {
+/* ignore the last entry - it's the size of the essence container
*/
+n--;
+}
+
+for (j = 0; j < n; j += index_delta, x++) {
int offset = s->temporal_offset_entries[j] / index_delta;
int index = x + offset;
--
1.7.5.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 04/16] mxfdec: Sanity-check SampleRate
This avoids a SIGFPE if SampleRate is missing or set to naughty values.
---
libavformat/mxfdec.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 9051874..aa7ebe6 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1405,6 +1405,7 @@ static int mxf_parse_structural_metadata(MXFContext *mxf)
st->codec->codec_id = container_ul->id;
st->codec->channels = descriptor->channels;
st->codec->bits_per_coded_sample = descriptor->bits_per_sample;
+if (descriptor->sample_rate.den > 0)
st->codec->sample_rate = descriptor->sample_rate.num /
descriptor->sample_rate.den;
/* TODO: implement CODEC_ID_RAWAUDIO */
if (st->codec->codec_id == CODEC_ID_PCM_S16LE) {
--
1.7.5.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 02/16] mxfdec: Make sure x < index_table->nb_ptses
Without this the demuxer will SIGSEGV on files with IndexEntryCount <
IndexDuration
---
libavformat/mxfdec.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index fa2bb65..fb9cac4 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1114,6 +1114,12 @@ static int mxf_compute_ptses_fake_index(MXFContext *mxf,
MXFIndexTable *index_ta
int offset = s->temporal_offset_entries[j] / index_delta;
int index = x + offset;
+if (x >= index_table->nb_ptses) {
+av_log(mxf->fc, AV_LOG_ERROR, "x >= nb_ptses - IndexEntryCount
%i < IndexDuration %"PRId64"?\n",
+ s->nb_index_entries, s->index_duration);
+break;
+}
+
index_table->fake_index[x].timestamp = x;
index_table->fake_index[x].flags = !(s->flag_entries[j] & 0x30) ?
AVINDEX_KEYFRAME : 0;
--
1.7.5.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 05/16] mxfdec: Check for NULL component
This fixes SIGSEGV with zzuf1.mxf
---
libavformat/mxfdec.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index aa7ebe6..6c3f0e2 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1311,7 +1311,7 @@ static int mxf_parse_structural_metadata(MXFContext *mxf)
break;
}
}
-if (!source_track)
+if (!source_track || !component)
continue;
if (!(source_track->sequence = mxf_resolve_strong_ref(mxf,
&source_track->sequence_ref, Sequence))) {
--
1.7.5.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/1] mxfdec: fix memleak on mxf_read_close()
On Sun, 2012-01-22 at 19:58 +0100, Janne Grunau wrote:
> ---
> libavformat/mxfdec.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index 4b63b27..0b514db 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -1915,6 +1915,7 @@ static int mxf_read_close(AVFormatContext *s)
>
> for (i = 0; i < mxf->nb_index_tables; i++) {
> av_freep(&mxf->index_tables[i].segments);
> +av_freep(&mxf->index_tables[i].ptses);
> av_freep(&mxf->index_tables[i].fake_index);
> }
> av_freep(&mxf->index_tables);
OK of course.
/Tomas
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] mxfdec: parse MXF partitions
On Sat, 2012-01-21 at 20:09 +0100, Janne Grunau wrote: > On 2012-01-11 10:59:55 +0100, Tomas Härdin wrote: > > On Fri, 2011-12-23 at 14:40 +0100, Janne Grunau wrote: > > > From: Tomas Härdin > > > > > > --- > > > changed enum values back to original names > > > > Anyway, any news on this and the other patch set? > > not really, waiting on ok, so: Ping! > > rebased to today's origin/master is at > > http://git.jannau.net/git/libav/log/?h=mxf-sync-2011-12 Looks reasonable. Don't forget to port the more recent commits too, such as the fuzz fixes. /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] mxfdec: parse MXF partitions
On Fri, 2011-12-23 at 14:40 +0100, Janne Grunau wrote: > From: Tomas Härdin > > --- > changed enum values back to original names > > Janne Hooray! Anyway, any news on this and the other patch set? /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] lxf: add support for version 1 files
On Fri, 2011-12-23 at 11:26 -0600, Phillip Blucas wrote:
> On Wed, Dec 21, 2011 at 4:33 AM, Tomas Härdin
> wrote:
> > On Tue, 2011-12-20 at 20:42 -0600, Phillip Blucas wrote:
> >> This newer format is used by Harris NEXIO playout servers.
> >> ---
> >> Changelog|1 +
> >> libavformat/lxfdec.c | 55
> >> ++---
> >> 2 files changed, 39 insertions(+), 17 deletions(-)
> >
> > Audio doesn't seem to work for some v1 files, such as:
> >
> > http://titan.codemill.se/~tomhar/samples/lxf/BARS01.lxf
> > http://titan.codemill.se/~tomhar/samples/lxf/F0015132.lxf
> >
> > I'm not sure if they actually have audio though. Video works fine for
> > all samples I have though, and all v0 samples with just as well as
> > before.
>
> avconv -i BARS01.lxf -acodec copy out.wav
>
> Audition and Audacity see 12 channels of tone. foobar and Winamp
> won't even try to play it.
>
> I don't see any audio on F0014132.lxf
OK. That sounds fine then.
> Also, the samples I have that disagree on the channel count are
> pcm_lxf. Yours are pcm_s24le.
> I'm not sure what that means (if anything).
Did you upload them somewhere? If not, then please do.
> >> @@ -185,8 +197,14 @@ static int get_packet_header(AVFormatContext *s,
> >> uint8_t *header, uint32_t *form
> >> avpriv_set_pts_info(s->streams[0], 64, 1, 25);
> >> }
> >>
> >> -//TODO: warning if track mask != (1 << channels) - 1?
> >> -ret = av_popcount(AV_RL32(&header[44])) * track_size;
> >> +channels = av_popcount(AV_RL32(&header[44]));
> >> +if (channels != lxf->channels) {
> >> +av_log(s, AV_LOG_DEBUG,
> >> + "Disk segment indicates %d channels, but audio packet
> >> contains %d.\n",
> >> + lxf->channels, channels);
> >> +st->codec->channels = channels = lxf->channels;
> >> +}
> >> +ret = channels * track_size;
> >
> > I don't think it's OK for a demuxer to change codec->channels after it's
> > done parsing the header. Not sure though.
>
> At least in the example command above, this patch produces the same
> output as limiting
> codec->channels to 12 during header parsing.
>
> I can take another look at this now that side_data is in.
Any news on this?
/Tomas
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] MXF changes from FFmpeg
On Thu, 2011-12-22 at 17:18 +0100, Luca Barbato wrote: > On 22/12/11 13:45, Tomas Härdin wrote: > > It's also hard to define "crazy" when it comes to MXF. After all, we're > > talking about a format that allows indexing individual scanlines in raw > > footage.. > > So we should accept 64bit/sizeof(the thing) values on 64bit architectures? *shrugs* An ENOMEM-ish limit is at least a more sensible explanation compared to say arbitrarily going "nope, no more than one million index entries for you". You'd also have to come up with a limit for every kind of table, keeping in mind a lot of tables have variably sized entries.. Thinking a bit further ahead, considering a file may use lots of small table segments that still add up to a lot, allocations should probably happen in some context if you want to place a limit on them. In other words, it seems more fair to say "refusing to allocate more than 1 GiB per demuxer/decoder". An option could then be used to increase said limit. That's obvious quite a bit of work though.. Anyway, INT_MAX is fine. Users with special needs can edit the code. /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] MXF changes from FFmpeg
On Thu, 2011-12-22 at 11:52 +, Måns Rullgård wrote: > Tomas Härdin writes: > > > On Wed, 2011-12-21 at 17:56 +0100, Janne Grunau wrote: > >> On 2011-12-21 15:47:24 +0100, Tomas Härdin wrote: > >> > On Wed, 2011-12-21 at 15:28 +0100, Luca Barbato wrote: > >> > > On 21/12/11 14:58, Tomas Härdin wrote: > >> > > > I hope you made sure the code still work fine on 32-bit systems, > >> > > > especially when entry counts are ~10^9. > >> > > > >> > > Do you have a sample for that? > >> > > >> > FATE sample with a single bit flipped at 0x1e9d, turning the zero-entry > >> > index entry into a 1 Gi entry one: > >> > http://titan.codemill.se/~tomhar/samples/C0023S01-ohnoes.mxf > >> > >> Thanks for noticing. I hope such index size are invalid as in this > >> example. > > > > Why would they be? The spec certainly doesn't imply any such thing - > > neither should the demuxer. > > > >> Since I'm not really sure what a good limit on the number > >> of index entries is, I've added checks against overflowing INT_MAX > >> even on 64-bit. > > > > Why not simply keep av_calloc()? It already does such a check. > > It does not allow you to distinguish between a crazy size and an out of > memory error for a modest size. Values read from the file should be > validated by the demuxer as a matter of principle. While I agree that validation is important, placing arbitrary limits is likely to cause more headache in this case. It's also hard to define "crazy" when it comes to MXF. After all, we're talking about a format that allows indexing individual scanlines in raw footage.. /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 01/19] mxfdec: Parse MXF partitions.
On Wed, 2011-12-21 at 19:45 +0100, Janne Grunau wrote:
> From: Tomas Härdin
>
> ---
> libavformat/mxfdec.c | 108
> +-
> 1 files changed, 107 insertions(+), 1 deletions(-)
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index c4c3f59..b8767c2 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -52,6 +52,35 @@
> #include "internal.h"
> #include "mxf.h"
>
> +typedef enum {
> +PART_TYPE_HEADER,
> +PART_TYPE_BODY,
> +PART_TYPE_FOOTER
> +} MXFPartitionType;
I hate to bikeshed, but these names should really stay CamelCase. Such
is the way the spec and all other MXF software names them, especially
mxfdump. MXF is complicated as it is without increasing impedance.
(Yes, I know I should have raised a fuzz earlier)
/Tomas
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] MXF changes from FFmpeg
On Wed, 2011-12-21 at 17:56 +0100, Janne Grunau wrote: > On 2011-12-21 15:47:24 +0100, Tomas Härdin wrote: > > On Wed, 2011-12-21 at 15:28 +0100, Luca Barbato wrote: > > > On 21/12/11 14:58, Tomas Härdin wrote: > > > > I hope you made sure the code still work fine on 32-bit systems, > > > > especially when entry counts are ~10^9. > > > > > > Do you have a sample for that? > > > > FATE sample with a single bit flipped at 0x1e9d, turning the zero-entry > > index entry into a 1 Gi entry one: > > http://titan.codemill.se/~tomhar/samples/C0023S01-ohnoes.mxf > > Thanks for noticing. I hope such index size are invalid as in this > example. Why would they be? The spec certainly doesn't imply any such thing - neither should the demuxer. > Since I'm not really sure what a good limit on the number > of index entries is, I've added checks against overflowing INT_MAX > even on 64-bit. Why not simply keep av_calloc()? It already does such a check. /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] MXF changes from FFmpeg
On 12/20/2011 05:43 PM, Janne Grunau wrote: > changed memory alloction from the pointless av_calloc > to av_mallocz I hope you made sure the code still work fine on 32-bit systems, especially when entry counts are ~10^9. On Wed, 2011-12-21 at 11:56 +0100, Benjamin Larsson wrote: > On 12/20/2011 05:43 PM, Janne Grunau wrote: > > Hi, > > > > applied mostly as they are in FFmpeg. I've cleaned some commit > > messages, changed memory alloction from the pointless av_calloc > > to av_mallocz, fixed potential memleaks on allocation errors. > > > > Janne > > All in all the set looks good. But lots of index code is added and > removed. Those changes could be squashed but I'm slightly more in favor > of committing as is to preserve history. You could have this entire series as a topic branch then git merge --no-ff so future bisects are less likely to end up in the middle of it. I'm assuming git-bisect is clever about such things. /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] MXF changes from FFmpeg
On Wed, 2011-12-21 at 15:28 +0100, Luca Barbato wrote: > On 21/12/11 14:58, Tomas Härdin wrote: > > I hope you made sure the code still work fine on 32-bit systems, > > especially when entry counts are ~10^9. > > Do you have a sample for that? FATE sample with a single bit flipped at 0x1e9d, turning the zero-entry index entry into a 1 Gi entry one: http://titan.codemill.se/~tomhar/samples/C0023S01-ohnoes.mxf Or you could just simulate a bit being flipped by changing mxf_read_index_entry_array() thusly: -segment->nb_index_entries = avio_rb32(pb); +segment->nb_index_entries = avio_rb32(pb) ^ (1 << 30); Caveat: I don't know how the multiplication and subsequent cast to size_t behaves on 32-bit. Casting to int and using av_mallocz() SIGSEGVs as expected. /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] lxf: add support for version 1 files
On Tue, 2011-12-20 at 20:42 -0600, Phillip Blucas wrote:
> This newer format is used by Harris NEXIO playout servers.
> ---
> Changelog|1 +
> libavformat/lxfdec.c | 55 ++---
> 2 files changed, 39 insertions(+), 17 deletions(-)
Audio doesn't seem to work for some v1 files, such as:
http://titan.codemill.se/~tomhar/samples/lxf/BARS01.lxf
http://titan.codemill.se/~tomhar/samples/lxf/F0015132.lxf
I'm not sure if they actually have audio though. Video works fine for
all samples I have though, and all v0 samples with just as well as
before.
> @@ -185,8 +197,14 @@ static int get_packet_header(AVFormatContext *s, uint8_t
> *header, uint32_t *form
> avpriv_set_pts_info(s->streams[0], 64, 1, 25);
> }
>
> -//TODO: warning if track mask != (1 << channels) - 1?
> -ret = av_popcount(AV_RL32(&header[44])) * track_size;
> +channels = av_popcount(AV_RL32(&header[44]));
> +if (channels != lxf->channels) {
> +av_log(s, AV_LOG_DEBUG,
> + "Disk segment indicates %d channels, but audio packet
> contains %d.\n",
> + lxf->channels, channels);
> +st->codec->channels = channels = lxf->channels;
> +}
> +ret = channels * track_size;
I don't think it's OK for a demuxer to change codec->channels after it's
done parsing the header. Not sure though.
The rest of the patch looks fine.
/Tomas
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] MXF changes from FFmpeg
On 12/20/2011 05:43 PM, Janne Grunau wrote: > changed memory alloction from the pointless av_calloc > to av_mallocz I hope you made sure the code still work fine on 32-bit systems, especially when entry counts are ~10^9. On Wed, 2011-12-21 at 11:56 +0100, Benjamin Larsson wrote: > On 12/20/2011 05:43 PM, Janne Grunau wrote: > > Hi, > > > > applied mostly as they are in FFmpeg. I've cleaned some commit > > messages, changed memory alloction from the pointless av_calloc > > to av_mallocz, fixed potential memleaks on allocation errors. > > > > Janne > > All in all the set looks good. But lots of index code is added and > removed. Those changes could be squashed but I'm slightly more in favor > of committing as is to preserve history. You could have this entire series as a topic branch then git merge --no-ff so future bisects are less likely to end up in the middle of it. I'm assuming git-bisect is clever about such things. (message resent - previous version greylisted?) /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] movenc: Don't wrap whole extradata atoms in glbl.
On Wed, 2011-10-12 at 15:29 -0700, Alex Converse wrote: > On Fri, Sep 30, 2011 at 5:11 AM, Tomas Härdin > wrote: > > On Fri, 2011-09-30 at 13:44 +0200, Luca Barbato wrote: > >> On 9/30/11 10:59 AM, Benjamin Larsson wrote: > >> > > >> >> > >> >> At work we added an "int interlacing;" field to AVCodecContext. It's > >> >> only set by a few decoders though (no demuxer sets it), and doesn't > >> >> provide field order information. > >> >> To support field order, "interlacing" could have the value of 0/1/2 > >> >> (progressive, TFF, BFF) or a separate field could be used (like AVFrame > >> >> does). Do those sound like decent ideas? > >> >> > >> > > >> > Splendid idea :) > >> > >> Ok, Tomas would you like to send a patch about that? > > > > I'll be out of town laptop-less this weekend, about an hour from now. > > You can either wait until monday or maybe Benjamin feels like poking at > > this? > > > > Any update on this? Sorry, no. I've been busy battling MXF and AVC-Intra. /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] mpegts: Attempt to seek back to beginning in non-seekable mpegts files.
On Mon, 2011-10-10 at 15:05 +0200, Luca Barbato wrote: > On 10/10/11 2:34 PM, Tomas Härdin wrote: > > Hi > > > > Attached patch fixes demuxing/probing of > > http://titan.codemill.se/~tomhar/samples/not_playable_on_pipe.ts when > > opened via a pipe (ffplay/avplay -< not_playable_on_pipe.ts). > > Sent to both lists since the problem exists in both projects. Meh. > > Passes make fate on both as well. > > > > /Tomas > > It seems sort of ok. I keep thinking there should be a cleaner way to > declare it though. We could perhaps print something for the non-seekable case failing to seek? Michael went with switching to LOG_INFO since it's less of an error not being able to seek in a stream.. /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] mpegts: Attempt to seek back to beginning in non-seekable mpegts files.
Hi Attached patch fixes demuxing/probing of http://titan.codemill.se/~tomhar/samples/not_playable_on_pipe.ts when opened via a pipe (ffplay/avplay - < not_playable_on_pipe.ts). Sent to both lists since the problem exists in both projects. Meh. Passes make fate on both as well. /Tomas >From ca125c92842fdf509b655b012e1676446f01c898 Mon Sep 17 00:00:00 2001 From: Petter Ericson Date: Mon, 10 Oct 2011 14:22:11 +0200 Subject: [PATCH] mpegts: Attempt to seek back to beginning in non-seekable mpegts files. --- libavformat/mpegts.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c index 02f0d56..dcbdc6b 100644 --- a/libavformat/mpegts.c +++ b/libavformat/mpegts.c @@ -1563,7 +1563,10 @@ static int mpegts_read_header(AVFormatContext *s, /* normal demux */ /* first do a scaning to get all the services */ -if (pb->seekable && avio_seek(pb, pos, SEEK_SET) < 0) +/* NOTE: We attempt to seek on non-seekable files as well, as the + * probe buffer usually is big enough. Only warn if the seek failed + * on files where the seek should work. */ +if (avio_seek(pb, pos, SEEK_SET) < 0 && pb->seekable) av_log(s, AV_LOG_ERROR, "Unable to seek back to the start\n"); mpegts_open_section_filter(ts, SDT_PID, sdt_cb, ts, 1); -- 1.7.4.1 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] movenc: Don't wrap whole extradata atoms in glbl.
On Fri, 2011-09-30 at 13:44 +0200, Luca Barbato wrote: > On 9/30/11 10:59 AM, Benjamin Larsson wrote: > > > >> > >> At work we added an "int interlacing;" field to AVCodecContext. It's > >> only set by a few decoders though (no demuxer sets it), and doesn't > >> provide field order information. > >> To support field order, "interlacing" could have the value of 0/1/2 > >> (progressive, TFF, BFF) or a separate field could be used (like AVFrame > >> does). Do those sound like decent ideas? > >> > > > > Splendid idea :) > > Ok, Tomas would you like to send a patch about that? I'll be out of town laptop-less this weekend, about an hour from now. You can either wait until monday or maybe Benjamin feels like poking at this? /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] movenc: Don't wrap whole extradata atoms in glbl.
On Fri, 2011-09-30 at 01:15 -0700, Alex Converse wrote:
> On Fri, Sep 30, 2011 at 12:19 AM, Tomas Härdin
> wrote:
> > On Thu, 2011-09-29 at 13:44 -0700, Alex Converse wrote:
> >> This should result in more idiomatic output that is less confusing to
> >> marginal implementations.
> >> ---
> >> libavformat/movenc.c | 16 ++--
> >> 1 files changed, 14 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> >> index b79bbe8..066dae0 100644
> >> --- a/libavformat/movenc.c
> >> +++ b/libavformat/movenc.c
> >> @@ -381,6 +381,18 @@ static int mov_write_glbl_tag(AVIOContext *pb,
> >> MOVTrack *track)
> >> return 8+track->vosLen;
> >> }
> >>
> >> +static int mov_write_extradata(AVIOContext *pb, MOVTrack *track)
> >> +{
> >> +if (track->vosLen >= 8 &&
> >> +AV_RB32(track->vosData+4) == MKBETAG('f','i','e','l')) {
> >
> > Check codec_id == CODEC_ID_MJPEG instead? See commit e571305 to mov.c in
> > FFmpeg ("mov: Only touch extradata in mov_read_extradata() if codec_id
> > is what we expect").
> > I haven't gotten around to rebasing and posting that here yet since I'm
> > still bouncing ideas for mov/mxfdec off Baptiste.
> >
>
> The more I think about the more the logical conclusion seems to be
> that 'fiel' data shouldn't be treated as extradata at all but instead
> should be decoded into the avcodec context.
At work we added an "int interlacing;" field to AVCodecContext. It's
only set by a few decoders though (no demuxer sets it), and doesn't
provide field order information.
To support field order, "interlacing" could have the value of 0/1/2
(progressive, TFF, BFF) or a separate field could be used (like AVFrame
does). Do those sound like decent ideas?
> It really doesn't make
> sense to dump a raw fiel atom into another container when remuxing
> mjpeg (or prores), not to mention it conflicts with AVC Intra and
> other interlaced formats that also have extradata.
There's also the fact that FCP requires the fiel atom in a variety of
cases, including AVC-Intra and XDCAM.
/Tomas
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] movenc: Don't wrap whole extradata atoms in glbl.
On Thu, 2011-09-29 at 13:44 -0700, Alex Converse wrote:
> This should result in more idiomatic output that is less confusing to
> marginal implementations.
> ---
> libavformat/movenc.c | 16 ++--
> 1 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index b79bbe8..066dae0 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -381,6 +381,18 @@ static int mov_write_glbl_tag(AVIOContext *pb, MOVTrack
> *track)
> return 8+track->vosLen;
> }
>
> +static int mov_write_extradata(AVIOContext *pb, MOVTrack *track)
> +{
> +if (track->vosLen >= 8 &&
> +AV_RB32(track->vosData+4) == MKBETAG('f','i','e','l')) {
Check codec_id == CODEC_ID_MJPEG instead? See commit e571305 to mov.c in
FFmpeg ("mov: Only touch extradata in mov_read_extradata() if codec_id
is what we expect").
I haven't gotten around to rebasing and posting that here yet since I'm
still bouncing ideas for mov/mxfdec off Baptiste.
/Tomas
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] prores: mark prores as intra-only in libavformat/utils.c:is_intra_only()
On Thu, 2011-09-22 at 17:54 -0700, Alex Converse wrote:
> On Thu, Sep 22, 2011 at 5:51 PM, Justin Ruggles
> wrote:
> > On 09/22/2011 08:33 PM, Måns Rullgård wrote:
> >
> >> Benjamin Larsson writes:
> >>
> >>> On 09/23/2011 12:10 AM, Diego Biurrun wrote:
> ---
> libavformat/utils.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 05d4fda..17b342e 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -852,6 +852,7 @@ static int is_intra_only(AVCodecContext *enc){
> case CODEC_ID_MJPEG:
> case CODEC_ID_MJPEGB:
> case CODEC_ID_LJPEG:
> +case CODEC_ID_PRORES:
> case CODEC_ID_RAWVIDEO:
> case CODEC_ID_DVVIDEO:
> case CODEC_ID_HUFFYUV:
> >>>
> >>> How about a codec capability instead ?
> >>
> >> WTF is that used for at all?
> >
> >
> > looks to me like a shortcut to not require all the demuxers set the key
> > frame flag like they're supposed to.
> >
>
> For mov files the keyframe box is often missing for intra only
> streams. I'm sure some other formats are similar.
Maybe add a comment explaining that?
/Tomas
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Apple ProRes decoder
On Wed, 2011-09-21 at 13:09 +0200, Diego Biurrun wrote:
> From: Maxim Poliakovski
> +static int decode_frame_header(ProresContext *ctx, const uint8_t *buf,
> + const int data_size, AVCodecContext *avctx)
> +{
...
> +
> +ctx->qmat_changed = 0;
> +ptr = buf + 20;
> +flags = buf[19];
> +if (flags & 2) {
> +if (memcmp(ctx->qmat_luma, ptr, 64)) {
> +memcpy(ctx->qmat_luma, ptr, 64);
> +ctx->qmat_changed = 1;
> +}
Won't this read past the end of the buffer if 28 <= data_size < 28+64 or
thereabouts?
> +ptr += 64;
> +} else {
> +memset(ctx->qmat_luma, 4, 64);
> +ctx->qmat_changed = 1;
> +}
> +
> +if (flags & 1) {
> +if (memcmp(ctx->qmat_chroma, ptr, 64)) {
> +memcpy(ctx->qmat_chroma, ptr, 64);
> +ctx->qmat_changed = 1;
> +}
Ditto here.
/Tomas
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] Fix VC-1 width/height handling.
Attached patch cherry-picked from FFmpeg. It fixes issue2076.
I uploaded a sample to
http://titan.codemill.se/~tomhar/samples/double-free.vc1 in case the
original went missing.
/Tomas
>From bde3e96195421df37d879f1cc481a6b542e11b61 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Reimar=20D=C3=B6ffinger?=
Date: Sat, 13 Aug 2011 11:32:10 +0200
Subject: [PATCH] Fix VC-1 width/height handling.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
avcodec_set_dimensions should be used for size changes to ensure
compatibility with future changes.
avctx->width/avctx->height may not be set to display-only dimensions.
Even more so since vc1dec.c would later set coded_width/height based
on this.
coded_width/coded_height should be used instead of width/height for
decoder setup.
This fixes playback of e.g. zz-mcr-nsqr.vc1 sample (containing
display width/height settings) in MPlayer and should fix a crash
with MPC: http://forum.doom9.org/showthread.php?t=162221.
Signed-off-by: Reimar Döffinger
---
libavcodec/vc1.c| 31 +--
libavcodec/vc1dec.c | 10 --
2 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/libavcodec/vc1.c b/libavcodec/vc1.c
index c3649ac..b816ca0 100644
--- a/libavcodec/vc1.c
+++ b/libavcodec/vc1.c
@@ -385,8 +385,9 @@ int vc1_decode_sequence_header(AVCodecContext *avctx, VC1Context *v, GetBitConte
v->finterpflag = get_bits1(gb); //common
if (v->res_sprite) {
-v->s.avctx->width = v->s.avctx->coded_width = get_bits(gb, 11);
-v->s.avctx->height = v->s.avctx->coded_height = get_bits(gb, 11);
+int w = get_bits(gb, 11);
+int h = get_bits(gb, 11);
+avcodec_set_dimensions(v->s.avctx, w, h);
skip_bits(gb, 5); //frame rate
v->res_x8 = get_bits1(gb);
if (get_bits1(gb)) { // something to do with DC VLC selection
@@ -423,6 +424,7 @@ int vc1_decode_sequence_header(AVCodecContext *avctx, VC1Context *v, GetBitConte
static int decode_sequence_header_adv(VC1Context *v, GetBitContext *gb)
{
+int w, h;
v->res_rtm_flag = 1;
v->level = get_bits(gb, 3);
if(v->level >= 5)
@@ -443,18 +445,17 @@ static int decode_sequence_header_adv(VC1Context *v, GetBitContext *gb)
v->bitrtq_postproc = get_bits(gb, 5); //common
v->postprocflag = get_bits1(gb); //common
-v->s.avctx->coded_width = (get_bits(gb, 12) + 1) << 1;
-v->s.avctx->coded_height = (get_bits(gb, 12) + 1) << 1;
-v->s.avctx->width = v->s.avctx->coded_width;
-v->s.avctx->height = v->s.avctx->coded_height;
+w = (get_bits(gb, 12) + 1) << 1;
+h = (get_bits(gb, 12) + 1) << 1;
+avcodec_set_dimensions(v->s.avctx, w, h);
v->broadcast = get_bits1(gb);
v->interlace = get_bits1(gb);
v->tfcntrflag = get_bits1(gb);
v->finterpflag = get_bits1(gb);
skip_bits1(gb); // reserved
-v->s.h_edge_pos = v->s.avctx->coded_width;
-v->s.v_edge_pos = v->s.avctx->coded_height;
+v->s.h_edge_pos = w;
+v->s.v_edge_pos = h;
av_log(v->s.avctx, AV_LOG_DEBUG,
"Advanced Profile level %i:\nfrmrtq_postproc=%i, bitrtq_postproc=%i\n"
@@ -472,11 +473,12 @@ static int decode_sequence_header_adv(VC1Context *v, GetBitContext *gb)
}
v->s.max_b_frames = v->s.avctx->max_b_frames = 7;
if(get_bits1(gb)) { //Display Info - decoding is not affected by it
-int w, h, ar = 0;
+int dw, dh, ar = 0;
av_log(v->s.avctx, AV_LOG_DEBUG, "Display extended info:\n");
-v->s.avctx->width = w = get_bits(gb, 14) + 1;
-v->s.avctx->height = h = get_bits(gb, 14) + 1;
-av_log(v->s.avctx, AV_LOG_DEBUG, "Display dimensions: %ix%i\n", w, h);
+dw = get_bits(gb, 14) + 1;
+dh = get_bits(gb, 14) + 1;
+v->s.avctx->sample_aspect_ratio = av_div_q((AVRational){dw, dh}, (AVRational){w, h});
+av_log(v->s.avctx, AV_LOG_DEBUG, "Display dimensions: %ix%i\n", dw, dh);
if(get_bits1(gb))
ar = get_bits(gb, 4);
if(ar && ar < 14){
@@ -552,8 +554,9 @@ int vc1_decode_entry_point(AVCodecContext *avctx, VC1Context *v, GetBitContext *
}
if(get_bits1(gb)){
-avctx->coded_width = (get_bits(gb, 12)+1)<<1;
-avctx->coded_height = (get_bits(gb, 12)+1)<<1;
+int w = (get_bits(gb, 12)+1)<<1;
+int h = (get_bits(gb, 12)+1)<<1;
+avcodec_set_dimensions(avctx, w, h);
}
if(v->extended_mv)
v->extended_dmv = get_bits1(gb);
diff --git a/libavcodec/vc1dec.c b/libavcodec/vc1dec.c
index f4d6f99..890d755 100644
--- a/libavcodec/vc1dec.c
+++ b/libavcodec/vc1dec.c
@@ -3585,8 +3585,8 @@ static av_cold int vc1_decode_init(AVCodecContext *avctx)
if (vc1_init_common(v) < 0) return -1;
ff_vc1dsp_init(&v->vc1dsp);
-cur_width = avctx->coded_width = avctx->width;
-cur_height = avctx->coded_height = avctx->height;
+cur_width = avctx->coded_width;
+cur_height = avctx->coded_height;
i
Re: [libav-devel] [PATCH] isom: Add missing 'ai52' tag (1080p AVC-Intra 50)
Kostya Shishkov skrev 2011-08-29 13:49:
On Mon, Aug 29, 2011 at 01:46:49PM +0200, Tomas Härdin wrote:
$TOPIC
trivial, hence OK
Updated patch attached. It should have all tags FCP uses, per IRC
discussion.
/Tomas
>From 4b9d8218cfefc8525868f76659ecd886d0667006 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Mon, 29 Aug 2011 13:44:13 +0200
Subject: [PATCH] isom: Add all missing AVC-Intra tags, rearrange list and update comments
---
libavformat/isom.c | 17 -
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/libavformat/isom.c b/libavformat/isom.c
index 7d42e80..48fd8e1 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -137,11 +137,18 @@ const AVCodecTag codec_movvideo_tags[] = {
{ CODEC_ID_RAWVIDEO, MKTAG('W', 'R', 'A', 'W') },
{ CODEC_ID_H264, MKTAG('a', 'v', 'c', '1') }, /* AVC-1/H.264 */
-{ CODEC_ID_H264, MKTAG('a', 'i', '5', '5') }, /* AVC Intra 50 / 1080 interlace */
-{ CODEC_ID_H264, MKTAG('a', 'i', '5', 'q') }, /* AVC Intra 50 / 720 */
-{ CODEC_ID_H264, MKTAG('a', 'i', '1', '5') }, /* AVC Intra 100 / 1080 interlace */
-{ CODEC_ID_H264, MKTAG('a', 'i', '1', 'q') }, /* AVC Intra 100 / 720 */
-{ CODEC_ID_H264, MKTAG('a', 'i', '1', '2') }, /* AVC Intra 100 / 1080 */
+{ CODEC_ID_H264, MKTAG('a', 'i', '5', 'p') }, /* AVC-Intra 50M 720p24/30/60 */
+{ CODEC_ID_H264, MKTAG('a', 'i', '5', 'q') }, /* AVC-Intra 50M 720p25/50 */
+{ CODEC_ID_H264, MKTAG('a', 'i', '5', '2') }, /* AVC-Intra 50M 1080p25/50 */
+{ CODEC_ID_H264, MKTAG('a', 'i', '5', '3') }, /* AVC-Intra 50M 1080p24/30/60 */
+{ CODEC_ID_H264, MKTAG('a', 'i', '5', '5') }, /* AVC-Intra 50M 1080i50 */
+{ CODEC_ID_H264, MKTAG('a', 'i', '5', '6') }, /* AVC-Intra 50M 1080i60 */
+{ CODEC_ID_H264, MKTAG('a', 'i', '1', 'p') }, /* AVC-Intra 100M 720p24/30/60 */
+{ CODEC_ID_H264, MKTAG('a', 'i', '1', 'q') }, /* AVC-Intra 100M 720p25/50 */
+{ CODEC_ID_H264, MKTAG('a', 'i', '1', '2') }, /* AVC-Intra 100M 1080p25/50 */
+{ CODEC_ID_H264, MKTAG('a', 'i', '1', '3') }, /* AVC-Intra 100M 1080p24/30/60 */
+{ CODEC_ID_H264, MKTAG('a', 'i', '1', '5') }, /* AVC-Intra 100M 1080i50 */
+{ CODEC_ID_H264, MKTAG('a', 'i', '1', '6') }, /* AVC-Intra 100M 1080i60 */
{ CODEC_ID_MPEG1VIDEO, MKTAG('m', '1', 'v', '1') }, /* Apple MPEG-1 Camcorder */
{ CODEC_ID_MPEG1VIDEO, MKTAG('m', 'p', 'e', 'g') }, /* MPEG */
--
1.7.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] isom: Add missing 'ai52' tag (1080p AVC-Intra 50)
$TOPIC
/Tomas
>From 980ee54e31006951c95cd297161f1c61f045e0cf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Mon, 29 Aug 2011 13:44:13 +0200
Subject: [PATCH] isom: Add missing 'ai52' tag (1080p AVC-Intra 50)
---
libavformat/isom.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/libavformat/isom.c b/libavformat/isom.c
index 7d42e80..9673a1e 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -139,6 +139,7 @@ const AVCodecTag codec_movvideo_tags[] = {
{ CODEC_ID_H264, MKTAG('a', 'v', 'c', '1') }, /* AVC-1/H.264 */
{ CODEC_ID_H264, MKTAG('a', 'i', '5', '5') }, /* AVC Intra 50 / 1080 interlace */
{ CODEC_ID_H264, MKTAG('a', 'i', '5', 'q') }, /* AVC Intra 50 / 720 */
+{ CODEC_ID_H264, MKTAG('a', 'i', '5', '2') }, /* AVC Intra 50 / 1080 */
{ CODEC_ID_H264, MKTAG('a', 'i', '1', '5') }, /* AVC Intra 100 / 1080 interlace */
{ CODEC_ID_H264, MKTAG('a', 'i', '1', 'q') }, /* AVC Intra 100 / 720 */
{ CODEC_ID_H264, MKTAG('a', 'i', '1', '2') }, /* AVC Intra 100 / 1080 */
--
1.7.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Revert "h264: Properly set coded_{width, height} when parsing H.264."
Måns Rullgård skrev 2011-08-22 18:05:
Tomas Härdin writes:
Måns Rullgård skrev 2011-08-22 16:04:
Luca Barbato writes:
On 8/22/11 11:54 AM, Måns Rullgård wrote:
But that *is* the coded width/height. Using those as display
width/height is broken.
then we have a documentation hole, which field contains the correct values?
Both are correct but for different things. coded_{width,height} are the
actual pixel dimensions of the image including padding to a macroblock
multiple (or other padding). Plain width/height is the display size to
be cropped from the full coded image. This is how it always has been.
Anything using those values differently is broken and should be fixed.
In some cases the container may specify additional cropping which I'm
not sure where it's supposed to be reported.
Just to pre-empt anyone thinking of doing this any other way:
I suggest putting such information in AVFormatContext as four
AVRationals (width, height, xoffset, yoffset) so mov and mxf files can
be remuxed more accurately.
Non-integer dimensions?
Indeed. I've run across more than one such mov sample at work. I'm not
sure why one would want them, but remuxing shouldn't result in such
information being thrown out.
A minor alteration: It could also be carried as metadata I suppose,
instead of cluttering up AVFormatContext.
One common use case is for hiding VBI lines in IMX50 material.
/Tomas
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Revert "h264: Properly set coded_{width, height} when parsing H.264."
Måns Rullgård skrev 2011-08-22 16:04:
Luca Barbato writes:
On 8/22/11 11:54 AM, Måns Rullgård wrote:
But that *is* the coded width/height. Using those as display
width/height is broken.
then we have a documentation hole, which field contains the correct values?
Both are correct but for different things. coded_{width,height} are the
actual pixel dimensions of the image including padding to a macroblock
multiple (or other padding). Plain width/height is the display size to
be cropped from the full coded image. This is how it always has been.
Anything using those values differently is broken and should be fixed.
In some cases the container may specify additional cropping which I'm
not sure where it's supposed to be reported.
Just to pre-empt anyone thinking of doing this any other way:
I suggest putting such information in AVFormatContext as four
AVRationals (width, height, xoffset, yoffset) so mov and mxf files can
be remuxed more accurately.
/Tomas
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] Minimum Quality Standards For (Marginal) Encoders
Mike Melanson skrev 2011-07-23 00:50:
2) There's a usable Cinepak encoder patch out there. It's chatty but it
does the job. I don't know about the overall quality but given the vintage
of the codec, the encoder is probably doing a good job. Should we push it
in?
I just figured out that the author of this patch is on the list. Tomas H.:
Can you comment about whether you think your Cinepak is suitable for
inclusion?
Well, it produces valid output and seems to live up to what Cinepak was
designed for - decent video at 320x200 and 15 fps in under 1x CD rate
(1200 kbps). It also supports grayscale via PIX_FMT_GRAY8.
320x200 nets around 12 fps encoding speed on my laptop in VirtualBox.
Poking a little at it, it seems MAX_STRIPS > 1 is broken (probably never
bothered testing it).
The output size can be controlled via -qscale, just like some of the
other obscure encoders.
Rebased patch attached.
(just got back from vacation, hence the late reply)
/Tomas
>From 98324fbde7d7ce15c7d74ebf5cce6488b5ce283b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Wed, 17 Aug 2011 14:42:56 +0200
Subject: [PATCH] Cinepak encoder
---
libavcodec/Makefile |1 +
libavcodec/allcodecs.c |2 +-
libavcodec/cinepakenc.c | 799 +++
3 files changed, 801 insertions(+), 1 deletions(-)
create mode 100644 libavcodec/cinepakenc.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 36e07a9..ee7f931 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -99,6 +99,7 @@ OBJS-$(CONFIG_CAVS_DECODER)+= cavs.o cavsdec.o cavsdsp.o \
mpeg12data.o mpegvideo.o
OBJS-$(CONFIG_CDGRAPHICS_DECODER) += cdgraphics.o
OBJS-$(CONFIG_CINEPAK_DECODER) += cinepak.o
+OBJS-$(CONFIG_CINEPAK_ENCODER) += cinepakenc.o
OBJS-$(CONFIG_CLJR_DECODER)+= cljr.o
OBJS-$(CONFIG_CLJR_ENCODER)+= cljr.o
OBJS-$(CONFIG_COOK_DECODER)+= cook.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index dcef0d6..d11936c 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -84,7 +84,7 @@ void avcodec_register_all(void)
REGISTER_DECODER (C93, c93);
REGISTER_DECODER (CAVS, cavs);
REGISTER_DECODER (CDGRAPHICS, cdgraphics);
-REGISTER_DECODER (CINEPAK, cinepak);
+REGISTER_ENCDEC (CINEPAK, cinepak);
REGISTER_DECODER (CLJR, cljr);
REGISTER_DECODER (CSCD, cscd);
REGISTER_DECODER (CYUV, cyuv);
diff --git a/libavcodec/cinepakenc.c b/libavcodec/cinepakenc.c
new file mode 100644
index 000..e1658a7
--- /dev/null
+++ b/libavcodec/cinepakenc.c
@@ -0,0 +1,799 @@
+#include "libavutil/intreadwrite.h"
+#include "avcodec.h"
+#include "libavutil/lfg.h"
+#include "elbg.h"
+
+#define CVID_HEADER_SIZE 10
+#define STRIP_HEADER_SIZE 12
+#define CHUNK_HEADER_SIZE 4
+
+#define MB_SIZE 4 //4x4 MBs
+#define MB_AREA (MB_SIZE*MB_SIZE)
+
+#define VECTOR_MAX 6//six or four entries per vector depending on format
+#define CODEBOOK_MAX 256
+#define CODEBOOK_NUM 5 //five potential codebooks (1, 4, 16, 64, 256) for V1 and V4
+
+#define MAX_STRIPS 1 //Note: having fewer choices regarding the number of strip speeds up encoding (obviously)
+#define MIN_STRIPS 1 //Note: having more strips speeds up encoding the frame (this is less obvious)
+
+typedef enum {
+MODE_V1_ONLY = 0,
+MODE_V1_V4,
+MODE_MC,
+
+MODE_COUNT,
+} CinepakMode;
+
+typedef enum {
+ENC_V1,
+ENC_V4,
+ENC_SKIP
+} mb_encoding;
+
+typedef struct {
+int v1_vector; //index into v1 codebook
+int v1_error; //error when using V1 encoding
+int v4_vector[CODEBOOK_NUM][4]; //indices into v4 codebooks
+int v4_error[CODEBOOK_NUM]; //error when using V4 encodings
+int skip_error; //error when block is skipped (aka copied from last frame)
+mb_encoding best_encoding; //last result from calculate_mode_score()
+} mb_info;
+
+typedef struct {
+int v1_codebook[CODEBOOK_MAX*VECTOR_MAX];
+int *v4_codebook;
+} strip_info;
+
+typedef struct {
+AVCodecContext *avctx;
+unsigned char *pict_bufs[3], *strip_buf, *frame_buf;
+AVFrame last_frame;
+AVFrame best_frame;
+AVFrame scratch_frame;
+enum PixelFormat pix_fmt;
+int w, h;
+int curframe, keyint;
+AVLFG randctx;
+uint64_t lambda;
+int *codebook_input;
+int *codebook_closest;
+mb_info *mb;//MB RD state
+#ifdef CINEPAKENC_DEBUG
+mb_info *best_mb; //TODO: remove. only used for printing stats
+#endif
+int num_v1_mode, num_v4_mode, num_mc_mode;
+int num_v1_encs, num_v4_encs, num_skips;
+} CinepakEncContext;
+
+static av_cold int cinepak_encode_init(AVCodecContext *avctx)
+{
+CinepakEncContext *s = avctx->priv_data;
+int x, mb_count, strip_buf_size, frame_buf_size;
+
+if (avc
Re: [libav-devel] [PATCH 1/6] Add bwf muxer, wav file with bext chunk
Anton Khirnov skrev 2011-07-09 11:20: From: Benjamin Larsson Signed-off-by: Anton Khirnov --- Changelog|4 ++ doc/general.texi |1 + libavformat/Makefile |1 + libavformat/allformats.c |1 + libavformat/wav.c| 82 +- 5 files changed, 88 insertions(+), 1 deletions(-) diff --git a/Changelog b/Changelog index b785197..afd1b85 100644 --- a/Changelog +++ b/Changelog @@ -2,6 +2,10 @@ Entries are sorted chronologically from oldest to youngest within each release, releases are sorted from youngest to oldest. +vesion: Typo? +- bwf muxer Maybe capitalize to "BWF"? + + version 0.7: - E-AC-3 audio encoder diff --git a/doc/general.texi b/doc/general.texi index c97a757..2083395 100644 --- a/doc/general.texi +++ b/doc/general.texi @@ -66,6 +66,7 @@ library: @tab Used in Z and Z95 games. @item Brute Force& Ignorance @tab @tab X @tab Used in the game Flash Traffic: City of Angels. +@item BWF @tab @tab X This is a muxer, not a demuxer The actual code looks OK. We might want to add test cases for this, but that can be done later. /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] mpegtsenc: Random Access indicator take 2
Jindřich Makovička skrev 2011-06-29 15:04: On Wed, Jun 29, 2011 at 12:06, Diego Biurrun wrote: On Wed, Jun 29, 2011 at 07:35:30AM +, Gil Pedersen wrote: It most likely breaks fate. It does indeed - Jindrich, this needs to be addressed... biurrun@passion:~/src/priv/libav $ make fate-lavf-ts TESTacodec-aref TESTvsynth1-vref TESTvsynth2-vref TESTlavf-ts --- ./tests/ref/lavf/ts 2011-06-21 22:15:41.490730387 +0200 +++ tests/data/fate/lavf-ts 2011-06-29 12:05:41.926902303 +0200 @@ -1,3 +1,3 @@ -d260ac0534ff2e26b44b5192fd4fdc21 *./tests/data/lavf/lavf.ts +9708011dd80212a0041a96da878122c2 *./tests/data/lavf/lavf.ts 406644 ./tests/data/lavf/lavf.ts ./tests/data/lavf/lavf.ts CRC=0x133216c1 make: *** [fate-lavf-ts] Error 1 Patch including the FATE change attached. Looks OK to me. Have you tried playing the encoded files on some hardware like an STB though? /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 5/6] wav: keep parsing until EOF if the input is seekable and we know the size of the data tag
Anton Khirnov skrev 2011-07-09 11:20:
From: Tomas Härdin
Signed-off-by: Anton Khirnov
---
libavformat/wav.c | 49 +
1 files changed, 33 insertions(+), 16 deletions(-)
diff --git a/libavformat/wav.c b/libavformat/wav.c
index 8a8c0b4..35ec4fb 100644
--- a/libavformat/wav.c
+++ b/libavformat/wav.c
@@ -298,7 +298,7 @@ static int wav_read_header(AVFormatContext *s,
AVStream *st;
WAVContext *wav = s->priv_data;
int ret, got_fmt = 0;
-int64_t next_tag_ofs;
+int64_t next_tag_ofs, data_ofs = -1;
/* check RIFF header */
tag = avio_rl32(pb);
@@ -329,13 +329,13 @@ static int wav_read_header(AVFormatContext *s,
avio_skip(pb, size - 16); /* skip rest of ds64 chunk */
}
-
for (;;) {
-if (pb->eof_reached)
-return -1;
size = next_tag(pb,&tag);
next_tag_ofs = avio_tell(pb) + size;
+if (pb->eof_reached)
+break;
+
switch (tag) {
case MKTAG('f', 'm', 't', ' '):
/* only parse the first 'fmt ' tag found */
@@ -352,26 +352,43 @@ static int wav_read_header(AVFormatContext *s,
return AVERROR_INVALIDDATA;
}
-goto break_loop;
+if (rf64) {
+next_tag_ofs = wav->data_end = avio_tell(pb) + data_size;
+} else {
+data_size = size;
+next_tag_ofs = wav->data_end = size ? next_tag_ofs : INT64_MAX;
+}
+
+data_ofs = avio_tell(pb);
+
+/* don't look for footer metadata if we can't seek or if we don't
+ * know where the data tag ends
+ */
+if (!pb->seekable || (!rf64&& !size))
+goto break_loop;
+break;
case MKTAG('f','a','c','t'):
if(!sample_count)
-sample_count = avio_rl32(pb);
+sample_count = avio_rl32(pb);
+break;
+}
+
+/* seek to next tag unless we know that we'll run into EOF */
+if ((avio_size(pb)> 0&& next_tag_ofs>= avio_size(pb)) ||
+avio_seek(pb, next_tag_ofs, SEEK_SET)< 0) {
break;
}
-avio_seek(pb, next_tag_ofs, SEEK_SET);
}
break_loop:
-if (rf64)
-size = data_size;
-if (size< 0)
-return -1;
-if (!size) {
-wav->data_end = INT64_MAX;
-} else
-wav->data_end= avio_tell(pb) + size;
+if (data_ofs< 0) {
+av_log(s, AV_LOG_ERROR, "no 'data' tag found\n");
+return AVERROR_INVALIDDATA;
+}
+
+avio_seek(pb, data_ofs, SEEK_SET);
if (!sample_count&& st->codec->channels&&
av_get_bits_per_sample(st->codec->codec_id))
-sample_count = (size<<3) / (st->codec->channels *
(uint64_t)av_get_bits_per_sample(st->codec->codec_id));
+sample_count = (data_size<<3) / (st->codec->channels *
(uint64_t)av_get_bits_per_sample(st->codec->codec_id));
if (sample_count)
st->duration = sample_count;
return 0;
I see this patch is squashed with f86d260 in FFmpeg, which is good.
Otherwise I'd complain that this patch introduced a seeking bug.
In other words, looks good.
I was about to post an almost identical rebased patch set myself, but
laziness got the best of me.
/Tomas
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] gxf: Fix 25 fps DV material in GXF being misdetected as 50 fps
Tomas Härdin skrev 2011-06-23 16:22:
Hi
It seems 25 fps DV muxed in GXF is misdetected as 50 fps by lavf.
The attached patch fixes this issue by setting the duration of DV
packets to fields_per_frame.
Oops, forgot to rebase. Updated patch attached.
/Tomas
>From 642a2f05468d0d53e7587d8efae00405495bceb7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Thu, 23 Jun 2011 15:59:33 +0200
Subject: [PATCH] gxf: Fix 25 fps DV material in GXF being misdetected as 50 fps
Set DV packet durations using fields_per_frame.
This requires turning gxf_stream_info into the demuxer's context for access to the value in gxf_packet().
Since MPEG-2 seems to work fine this done only for DV.
---
libavformat/gxf.c | 25 -
1 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/libavformat/gxf.c b/libavformat/gxf.c
index 74d925f..d77fd18 100644
--- a/libavformat/gxf.c
+++ b/libavformat/gxf.c
@@ -264,7 +264,7 @@ static int gxf_header(AVFormatContext *s, AVFormatParameters *ap) {
int map_len;
int len;
AVRational main_timebase = {0, 0};
-struct gxf_stream_info si;
+struct gxf_stream_info *si = s->priv_data;
int i;
if (!parse_packet_header(pb, &pkt_type, &map_len) || pkt_type != PKT_MAP) {
av_log(s, AV_LOG_ERROR, "map packet not found\n");
@@ -282,7 +282,7 @@ static int gxf_header(AVFormatContext *s, AVFormatParameters *ap) {
return 0;
}
map_len -= len;
-gxf_material_tags(pb, &len, &si);
+gxf_material_tags(pb, &len, si);
avio_skip(pb, len);
map_len -= 2;
len = avio_rb16(pb); // length of track description
@@ -300,7 +300,7 @@ static int gxf_header(AVFormatContext *s, AVFormatParameters *ap) {
track_id = avio_r8(pb);
track_len = avio_rb16(pb);
len -= track_len;
-gxf_track_tags(pb, &track_len, &si);
+gxf_track_tags(pb, &track_len, si);
avio_skip(pb, track_len);
if (!(track_type & 0x80)) {
av_log(s, AV_LOG_ERROR, "invalid track type %x\n", track_type);
@@ -316,12 +316,12 @@ static int gxf_header(AVFormatContext *s, AVFormatParameters *ap) {
if (idx < 0) continue;
st = s->streams[idx];
if (!main_timebase.num || !main_timebase.den) {
-main_timebase.num = si.frames_per_second.den;
-main_timebase.den = si.frames_per_second.num * 2;
+main_timebase.num = si->frames_per_second.den;
+main_timebase.den = si->frames_per_second.num * 2;
}
-st->start_time = si.first_field;
-if (si.first_field != AV_NOPTS_VALUE && si.last_field != AV_NOPTS_VALUE)
-st->duration = si.last_field - si.first_field;
+st->start_time = si->first_field;
+if (si->first_field != AV_NOPTS_VALUE && si->last_field != AV_NOPTS_VALUE)
+st->duration = si->last_field - si->first_field;
}
if (len < 0)
av_log(s, AV_LOG_ERROR, "invalid track description length specified\n");
@@ -422,6 +422,8 @@ static int gxf_packet(AVFormatContext *s, AVPacket *pkt) {
AVIOContext *pb = s->pb;
GXFPktType pkt_type;
int pkt_len;
+struct gxf_stream_info *si = s->priv_data;
+
while (!pb->eof_reached) {
AVStream *st;
int track_type, track_id, ret;
@@ -473,6 +475,11 @@ static int gxf_packet(AVFormatContext *s, AVPacket *pkt) {
avio_skip(pb, skip);
pkt->stream_index = stream_index;
pkt->dts = field_nr;
+
+//set duration manually for DV or else lavf misdetects the frame rate
+if (st->codec->codec_id == CODEC_ID_DVVIDEO)
+pkt->duration = si->fields_per_frame;
+
return ret;
}
return AVERROR(EIO);
@@ -518,7 +525,7 @@ static int64_t gxf_read_timestamp(AVFormatContext *s, int stream_index,
AVInputFormat ff_gxf_demuxer = {
"gxf",
NULL_IF_CONFIG_SMALL("GXF format"),
-0,
+sizeof(struct gxf_stream_info),
gxf_probe,
gxf_header,
gxf_packet,
--
1.7.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] gxf: Fix 25 fps DV material in GXF being misdetected as 50 fps
Hi
It seems 25 fps DV muxed in GXF is misdetected as 50 fps by lavf.
The attached patch fixes this issue by setting the duration of DV
packets to fields_per_frame.
Without this ffprobe reports packets as having duration=1, but all
dts:es are even (0, 2, 4, time_base=1/50) which confuses lavf.
I chose only to do this for DV since MPEG-2 seems to work fine, and I
can't find any other samples.
Sample: http://titan.codemill.se/~tomhar/samples/gxf_dv25_fps_misdetect.gxf
/Tomas
>From b4166c842605348319dd20c39cb90b4fc5b26901 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Thu, 23 Jun 2011 15:59:33 +0200
Subject: [PATCH] gxf: Fix 25 fps DV material in GXF being misdetected as 50 fps
Set DV packet durations using fields_per_frame.
This requires turning gxf_stream_info into the demuxer's context for access to the value in gxf_packet().
Since MPEG-2 seems to work fine this done only for DV.
---
libavformat/gxf.c | 25 -
1 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/libavformat/gxf.c b/libavformat/gxf.c
index e278b9b..145b4ad 100644
--- a/libavformat/gxf.c
+++ b/libavformat/gxf.c
@@ -264,7 +264,7 @@ static int gxf_header(AVFormatContext *s, AVFormatParameters *ap) {
int map_len;
int len;
AVRational main_timebase = {0, 0};
-struct gxf_stream_info si;
+struct gxf_stream_info *si = s->priv_data;
int i;
if (!parse_packet_header(pb, &pkt_type, &map_len) || pkt_type != PKT_MAP) {
av_log(s, AV_LOG_ERROR, "map packet not found\n");
@@ -282,7 +282,7 @@ static int gxf_header(AVFormatContext *s, AVFormatParameters *ap) {
return 0;
}
map_len -= len;
-gxf_material_tags(pb, &len, &si);
+gxf_material_tags(pb, &len, si);
avio_skip(pb, len);
map_len -= 2;
len = avio_rb16(pb); // length of track description
@@ -300,7 +300,7 @@ static int gxf_header(AVFormatContext *s, AVFormatParameters *ap) {
track_id = avio_r8(pb);
track_len = avio_rb16(pb);
len -= track_len;
-gxf_track_tags(pb, &track_len, &si);
+gxf_track_tags(pb, &track_len, si);
avio_skip(pb, track_len);
if (!(track_type & 0x80)) {
av_log(s, AV_LOG_ERROR, "invalid track type %x\n", track_type);
@@ -316,12 +316,12 @@ static int gxf_header(AVFormatContext *s, AVFormatParameters *ap) {
if (idx < 0) continue;
st = s->streams[idx];
if (!main_timebase.num || !main_timebase.den) {
-main_timebase.num = si.frames_per_second.den;
-main_timebase.den = si.frames_per_second.num * 2;
+main_timebase.num = si->frames_per_second.den;
+main_timebase.den = si->frames_per_second.num * 2;
}
-st->start_time = si.first_field;
-if (si.first_field != AV_NOPTS_VALUE && si.last_field != AV_NOPTS_VALUE)
-st->duration = si.last_field - si.first_field;
+st->start_time = si->first_field;
+if (si->first_field != AV_NOPTS_VALUE && si->last_field != AV_NOPTS_VALUE)
+st->duration = si->last_field - si->first_field;
}
if (len < 0)
av_log(s, AV_LOG_ERROR, "invalid track description length specified\n");
@@ -422,6 +422,8 @@ static int gxf_packet(AVFormatContext *s, AVPacket *pkt) {
AVIOContext *pb = s->pb;
GXFPktType pkt_type;
int pkt_len;
+struct gxf_stream_info *si = s->priv_data;
+
while (!url_feof(pb)) {
AVStream *st;
int track_type, track_id, ret;
@@ -473,6 +475,11 @@ static int gxf_packet(AVFormatContext *s, AVPacket *pkt) {
avio_skip(pb, skip);
pkt->stream_index = stream_index;
pkt->dts = field_nr;
+
+//set duration manually for DV or else lavf misdetects the frame rate
+if (st->codec->codec_id == CODEC_ID_DVVIDEO)
+pkt->duration = si->fields_per_frame;
+
return ret;
}
return AVERROR(EIO);
@@ -518,7 +525,7 @@ static int64_t gxf_read_timestamp(AVFormatContext *s, int stream_index,
AVInputFormat ff_gxf_demuxer = {
"gxf",
NULL_IF_CONFIG_SMALL("GXF format"),
-0,
+sizeof(struct gxf_stream_info),
gxf_probe,
gxf_header,
gxf_packet,
--
1.7.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] mpegtsenc: Random Access indicator take 2
Jindřich Makovička skrev 2011-06-21 18:52: Hi, I am attaching another, hopefully cleaner, version of the Random Access indicator patch for mpeg-ts muxer. Random Access indicator can be used to mark keyframes, and is required by some DVB recorders to be able to index and replay the recorded stream. From 7c6a9d0618e045af2026218aff92b400e7b8ee0f Mon Sep 17 00:00:00 2001 From: Jindrich Makovicka Date: Tue, 21 Jun 2011 18:50:58 +0200 Subject: [PATCH] set Random Access indicator on keyframe start packets --- libavformat/mpegtsenc.c | 67 +++--- 1 files changed, 56 insertions(+), 11 deletions(-) Looks OK AFAICT - I don't have the spec on hand to double-check the details. /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Clip-Wrapped MXF support (attempt #5)
Maksym Veremeyenko skrev 2011-06-16 13:07: 15.06.11 15:52, Diego Biurrun написав(ла): On Wed, Mar 30, 2011 at 01:59:56PM +0300, Maksym Veremeyenko wrote: This is another attempt to submit patches for clip-wrapped MXF files support (generated by Panasonic's P2 camera). Benjamin, Tomas, may be it is time to commit now? ... ping ... there was some objection against that http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2011-May/111541.html Georg seems to have an almost working patch for this. You might want to check out the thread "[FFmpeg-devel] [PATCH] MXF index table based seeking". The approach taken seems to be the correct one - index tables are parsed and used properly as far as I can see. One possible issue is not handling multiple body partitions. It does handle multiple index segments with different EditUnitByteCounts though, which is important for P2. I haven't looked at his latest patch indepth yet. I'm rebasing it atm, and trying to work it into my partition parsing stuff. /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] dv aspect ratio
Maksym Veremeyenko skrev 2011-05-25 07:06: hi, years ago there was a patch http://git.libav.org/?p=libav.git;a=commitdiff;h=6aafe463e5d1483b95ad259334c45d2741c92fb2 that splits aspect ratio detection for SMPTE 314M and IEC 61834. i have a bunch of files that properly displayed by quicktime, but ffmpeg (dv decoder) report 16:9 aspect ratio for them. files originally are IEC 68134[apt == 0] and apt=0, vsc_pack[2]=CF so they detected as 16:9, albeit Quicktime display it as 4:3. What does ffprobe say about the container's aspect ratio? I'm inclined to believe that the container claims 4:3 while the essence is 16:9 (I've seen this more than once). In that case QuickTime displays it at 4:3 because it trusts the container over the essence. if somebody has IEC 61834 pdf's could he confirm that (vsc_pack[2] & 0x07) == 0x07) really defines 16:9? I don't have it, but I trust Michael read the spec. However: since the value 7 is reserved in S314m, is there really any harm in just taking it to mean 16:9 regardless of apt? We probably don't need to though. at least http://msdn.microsoft.com/en-us/library/dd407313%28v=vs.85%29.aspx did not mention differences in aspect ration detection and meaning of filed *DISP* Uhm, it seems to define DISP to match S314m. Near the bottom: "DISP: Display select mode. 000 = 4:3 aspect ratio, full format; 010 = 16:9 aspect ratio." /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Avoid divide by zero in compute_avg_bitrate()
Ronald S. Bultje skrev 2011-05-12 16:36: Hi, On Wed, May 11, 2011 at 8:25 AM, Tomas Härdin wrote: The attached patch fixes a possibility for movenc.c to SIGFPE if trackDuration is zero when writing esds. This can happen if the user manages to mux a single AAC packet with dts = 0 and duration = 0. This patch does not apply to my local tree, I don't see a function called compute_avg_bitrate() (?). Yes, sorry. I was poking around in the FFmepg tree and found this bug, then accidentally sent the patch to ffmpeg-de...@mplayerhq.hu which seems to cause them to be CC:ed to libav.org. /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] Avoid divide by zero in compute_avg_bitrate()
Hi
The attached patch fixes a possibility for movenc.c to SIGFPE if
trackDuration is zero when writing esds. This can happen if the user
manages to mux a single AAC packet with dts = 0 and duration = 0.
/Tomas
>From 7dbf9ac26ca677fc664a4569601bb0204e8410be Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Wed, 11 May 2011 09:47:50 +0200
Subject: [PATCH] Avoid divide by zero in compute_avg_bitrate()
This can happen if muxing a single AAC packet with duration = 0
---
libavformat/movenc.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index a3d470a..d950664 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -261,6 +261,10 @@ static unsigned compute_avg_bitrate(MOVTrack *track)
{
uint64_t size = 0;
int i;
+
+if (!track->trackDuration)
+return 0;
+
for (i = 0; i < track->entry; i++)
size += track->cluster[i].size;
return size * 8 * track->timescale / track->trackDuration;
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-de...@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] flic: do not set audio sample format. that is done by the decoder.
Justin Ruggles skrev 2011-04-20 18:48: On 04/20/2011 03:29 AM, Tomas Härdin wrote: Justin Ruggles skrev 2011-04-20 01:17: diff --git a/libavformat/flic.c b/libavformat/flic.c index fcdf4c8..ad39d66 100644 --- a/libavformat/flic.c +++ b/libavformat/flic.c @@ -158,7 +158,6 @@ static int flic_read_header(AVFormatContext *s, ast->codec->codec_tag = 0; ast->codec->sample_rate = FLIC_TFTD_SAMPLE_RATE; ast->codec->channels = 1; -ast->codec->sample_fmt = AV_SAMPLE_FMT_U8; ast->codec->bit_rate = st->codec->sample_rate * 8; ast->codec->bits_per_coded_sample = 8; ast->codec->channel_layout = AV_CH_LAYOUT_MONO; Samples still work -> OK well... it seems none of the samples in fate or in the samples archive have an audio stream. mike, do you have any of these stashed away somewhere? Looking some more, it seems setting codec_tag, bit_rate, bits_per_coded_sample and extradata_size can all be dropped as well. true. This reminds me - did I ever upload the TFTD samples? If so, do we want to do anything with them? what are the tftd samples? is that pcm_lxf? No, it's the video files in the CD version of "X-COM: Terror from the Deep". They're FLIs with an audio stream, but improperly chunked - see the comments about FLIC_TFTD_CHUNK_AUDIO. Anyway, I think I uploaded some samples around that time (a year ago). Look for INTRO.VID among the samples. I can upload them again though. /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] flic: do not set audio sample format. that is done by the decoder.
Justin Ruggles skrev 2011-04-20 01:17: diff --git a/libavformat/flic.c b/libavformat/flic.c index fcdf4c8..ad39d66 100644 --- a/libavformat/flic.c +++ b/libavformat/flic.c @@ -158,7 +158,6 @@ static int flic_read_header(AVFormatContext *s, ast->codec->codec_tag = 0; ast->codec->sample_rate = FLIC_TFTD_SAMPLE_RATE; ast->codec->channels = 1; -ast->codec->sample_fmt = AV_SAMPLE_FMT_U8; ast->codec->bit_rate = st->codec->sample_rate * 8; ast->codec->bits_per_coded_sample = 8; ast->codec->channel_layout = AV_CH_LAYOUT_MONO; Samples still work -> OK Looking some more, it seems setting codec_tag, bit_rate, bits_per_coded_sample and extradata_size can all be dropped as well. This reminds me - did I ever upload the TFTD samples? If so, do we want to do anything with them? /Tomas ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
