Re: [FFmpeg-devel] [PATCH] avfilter/drawutils: Check av_pix_fmt_desc_get() return value in ff_fill_line_with_color()
Dana 13. 6. 2015. 00:05 osoba "Michael Niedermayer"
napisala je:
>
> Theres currently no case where this could be triggered but adding this
> provides future robustness
>
> Found-by: Daemon404
> Signed-off-by: Michael Niedermayer
> ---
> libavfilter/drawutils.c |7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
> index 0b2f17e..4385398 100644
> --- a/libavfilter/drawutils.c
> +++ b/libavfilter/drawutils.c
> @@ -66,7 +66,12 @@ int ff_fill_line_with_color(uint8_t *line[4], int
pixel_step[4], int w, uint8_t
> uint8_t rgba_map[4] = {0};
> int i;
> const AVPixFmtDescriptor *pix_desc = av_pix_fmt_desc_get(pix_fmt);
> -int hsub = pix_desc->log2_chroma_w;
> +int hsub;
> +
> +if (!pix_desc)
> +return AVERROR(EINVAL);
> +
> +hsub = pix_desc->log2_chroma_w;
>
> *is_packed_rgba = ff_fill_rgba_map(rgba_map, pix_fmt) >= 0;
>
> --
> 1.7.9.5
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] softfloat: make av_div_sf() inline
Removes a defined but not used warning on files including softfloat.h
Signed-off-by: James Almer
---
libavutil/softfloat.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/softfloat.h b/libavutil/softfloat.h
index 70a9adf..4272363 100644
--- a/libavutil/softfloat.h
+++ b/libavutil/softfloat.h
@@ -97,7 +97,7 @@ static inline av_const SoftFloat av_mul_sf(SoftFloat a,
SoftFloat b){
* b has to be normalized and not zero.
* @return Will not be more denormalized than a.
*/
-static av_const SoftFloat av_div_sf(SoftFloat a, SoftFloat b){
+static inline av_const SoftFloat av_div_sf(SoftFloat a, SoftFloat b){
a.exp -= b.exp;
a.mant = ((int64_t)a.mant<<(ONE_BITS+1)) / b.mant;
return av_normalize1_sf(a);
--
2.4.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter/vf_colorkey: Add colorkey video filter
On Thu, Jun 11, 2015 at 09:06:19PM +0200, Timo Rothenpieler wrote: > --- > Changelog | 1 + > MAINTAINERS | 1 + > doc/filters.texi | 39 > libavfilter/Makefile | 1 + > libavfilter/allfilters.c | 1 + > libavfilter/vf_colorkey.c | 221 > ++ > 6 files changed, 264 insertions(+) > create mode 100644 libavfilter/vf_colorkey.c > > diff --git a/Changelog b/Changelog > index aa5753e..9a53286 100644 > --- a/Changelog > +++ b/Changelog > @@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest > within each release, > releases are sorted from youngest to oldest. > > version : > +- colorkey video filter > > > version 2.7: > diff --git a/MAINTAINERS b/MAINTAINERS > index 795e904..7b239a1 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -352,6 +352,7 @@ Filters: >avf_showcqt.c Muhammad Faiz >vf_blend.cPaul B Mahol >vf_colorbalance.c Paul B Mahol > + vf_colorkey.c Timo Rothenpieler >vf_dejudder.c Nicholas Robbins >vf_delogo.c Jean Delvare (CC > ) >vf_drawbox.c/drawgrid Andrey Utkin > diff --git a/doc/filters.texi b/doc/filters.texi > index 4b5c3c1..5696362 100644 > --- a/doc/filters.texi > +++ b/doc/filters.texi > @@ -3029,6 +3029,45 @@ colorbalance=rs=.3 > @end example > @end itemize > > +@section colorkey > +RGB colorspace color keying. > + > +The filter accepts the following options: > + > +@table @option > +@item color > +The color which will be replaced with transparency. > + > +@item similarity > +Similarity percentage with the key color. > + > +0.01 matches only the exact key color, while 1.0 matches everything. > + > +@item blend > +Blend percentage. > + > +0.0 makes pixels either fully transparent, or not transparent at all. > + > +Higher values result in semi-transparent pixels, with a higher transparency > +the more similar the pixels color is to the key color. > +@end table > + > +@subsection Examples > + > +@itemize > +@item > +Make every green pixel in the input image transparent: > +@example > +ffmpeg -i input.png -vf colorkey=green out.png > +@end example > + > +@item > +Overlay a greenscreen-video on top of a static background image. > +@example > +ffmpeg -i background.png -i video.mp4 -filter_complex > "[1:v]colorkey=0x3BBD1E:0.3:0.2[ckout];[0:v][ckout]overlay[out]" -map "[out]" > output.flv > +@end example > +@end itemize > + > @section colorlevels > > Adjust video input frames using levels. > diff --git a/libavfilter/Makefile b/libavfilter/Makefile > index bf5a549..fc9f455 100644 > --- a/libavfilter/Makefile > +++ b/libavfilter/Makefile > @@ -102,6 +102,7 @@ OBJS-$(CONFIG_BOXBLUR_FILTER)+= > vf_boxblur.o > OBJS-$(CONFIG_CODECVIEW_FILTER) += vf_codecview.o > OBJS-$(CONFIG_COLORBALANCE_FILTER) += vf_colorbalance.o > OBJS-$(CONFIG_COLORCHANNELMIXER_FILTER) += vf_colorchannelmixer.o > +OBJS-$(CONFIG_COLORKEY_FILTER) += vf_colorkey.o > OBJS-$(CONFIG_COLORLEVELS_FILTER)+= vf_colorlevels.o > OBJS-$(CONFIG_COLORMATRIX_FILTER)+= vf_colormatrix.o > OBJS-$(CONFIG_COPY_FILTER) += vf_copy.o > diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c > index 0244585..415ed1b 100644 > --- a/libavfilter/allfilters.c > +++ b/libavfilter/allfilters.c > @@ -118,6 +118,7 @@ void avfilter_register_all(void) > REGISTER_FILTER(CODECVIEW, codecview, vf); > REGISTER_FILTER(COLORBALANCE, colorbalance, vf); > REGISTER_FILTER(COLORCHANNELMIXER, colorchannelmixer, vf); > +REGISTER_FILTER(COLORKEY, colorkey, vf); > REGISTER_FILTER(COLORLEVELS,colorlevels,vf); > REGISTER_FILTER(COLORMATRIX,colormatrix,vf); > REGISTER_FILTER(COPY, copy, vf); > diff --git a/libavfilter/vf_colorkey.c b/libavfilter/vf_colorkey.c > new file mode 100644 > index 000..5db30e8 > --- /dev/null > +++ b/libavfilter/vf_colorkey.c > @@ -0,0 +1,221 @@ > +/* > + * Copyright (c) 2015 Timo Rothenpieler > + * > + * This file is part of FFmpeg. > + * > + * FFmpeg is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * FFmpeg is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with FFmpeg; if not, write to the Free Software > + *
Re: [FFmpeg-devel] [PATCH 4/4] avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for AVC qpel functions
On Thu, Jun 11, 2015 at 11:31:12AM +0530, shivraj.pa...@imgtec.com wrote: > From: Shivraj Patil > > This patch adds MSA (MIPS-SIMD-Arch) optimizations for AVC qpel functions in > new file h264qpel_msa.c > Adds new generic macros (needed for this patch) in > libavutil/mips/generic_macros_msa.h > > Added const to local static array. > > Signed-off-by: Shivraj Patil > --- > libavcodec/h264qpel.c|2 + > libavcodec/h264qpel.h|1 + > libavcodec/mips/Makefile |2 + > libavcodec/mips/h264dsp_mips.h | 198 ++ > libavcodec/mips/h264qpel_init_mips.c | 136 ++ > libavcodec/mips/h264qpel_msa.c | 3600 > ++ > libavutil/mips/generic_macros_msa.h | 124 ++ > 7 files changed, 4063 insertions(+) > create mode 100644 libavcodec/mips/h264qpel_init_mips.c > create mode 100644 libavcodec/mips/h264qpel_msa.c applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] examples/decoding_encoding: Use the AVFrame width/height for processing images after decoding
On Thu, Jun 11, 2015 at 09:45:28AM +0200, Stefano Sabatini wrote:
> On date Wednesday 2015-06-10 22:21:23 +0200, Michael Niedermayer encoded:
> > This is what FFmpeg / FFplay do and it is more robust
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > doc/examples/decoding_encoding.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/doc/examples/decoding_encoding.c
> > b/doc/examples/decoding_encoding.c
> > index 80da664..f6643f6 100644
> > --- a/doc/examples/decoding_encoding.c
> > +++ b/doc/examples/decoding_encoding.c
> > @@ -521,7 +521,7 @@ static int decode_write_frame(const char *outfilename,
> > AVCodecContext *avctx,
> > /* the picture is allocated by the decoder, no need to free it */
> > snprintf(buf, sizeof(buf), outfilename, *frame_count);
> > pgm_save(frame->data[0], frame->linesize[0],
> > - avctx->width, avctx->height, buf);
> > + frame->width, frame->height, buf);
> > (*frame_count)++;
> > }
> > if (pkt->data) {
> > --
> > 1.7.9.5
>
> LGTM, thanks.
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The educated differ from the uneducated as much as the living from the
dead. -- Aristotle
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: enable VSX for ppc64el
On Fri, Jun 12, 2015 at 08:40:28PM +0200, Andreas Cadhalpun wrote: > Together with commit 04f0002 this changes the behavior back to what it > was was before commit b0af404. > > Signed-off-by: Andreas Cadhalpun > --- > configure | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/configure b/configure > index 0c907ff..3a6af6e 100755 > --- a/configure > +++ b/configure > @@ -4610,6 +4610,9 @@ unsigned int endian = 'B' << 24 | 'I' << 16 | 'G' << 8 > | 'E'; > EOF > od -t x1 $TMPO | grep -q '42 *49 *47 *45' && enable bigendian > > +if enabled ppc64 && ! enabled bigendian && enabled altivec; then > +enable vsx > +fi > this breaks --disable-vsx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/drawutils: Check av_pix_fmt_desc_get() return value in ff_fill_line_with_color()
Theres currently no case where this could be triggered but adding this
provides future robustness
Found-by: Daemon404
Signed-off-by: Michael Niedermayer
---
libavfilter/drawutils.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
index 0b2f17e..4385398 100644
--- a/libavfilter/drawutils.c
+++ b/libavfilter/drawutils.c
@@ -66,7 +66,12 @@ int ff_fill_line_with_color(uint8_t *line[4], int
pixel_step[4], int w, uint8_t
uint8_t rgba_map[4] = {0};
int i;
const AVPixFmtDescriptor *pix_desc = av_pix_fmt_desc_get(pix_fmt);
-int hsub = pix_desc->log2_chroma_w;
+int hsub;
+
+if (!pix_desc)
+return AVERROR(EINVAL);
+
+hsub = pix_desc->log2_chroma_w;
*is_packed_rgba = ff_fill_rgba_map(rgba_map, pix_fmt) >= 0;
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH] h264: update avctx width/height when flushing
On Fri, Jun 12, 2015 at 9:01 PM, Andreas Cadhalpun wrote: > On 12.06.2015 21:51, Hendrik Leppkes wrote: >> On Fri, Jun 12, 2015 at 9:23 PM, Andreas Cadhalpun >>> I agree that it is not really elegant, but removing the assumption that >>> the avctx width/height/pix_fmt are from the last decoded frame instead >>> of the last returned frame from the h264 decoder is beyond me. >>> If someone more familiar with the h264 decoder could do that, it would >>> be great. >>> But until then, having this workaround is better than the current state. >>> So I've pushed this. >>> >> >> This patch is super ugly and a mega hack. > > Maybe. ;) > >> Just inform consumers that only AVFrame has the actual up-to-date >> values when a change in the bitstream happens and stop doing such >> crap. > > That's not currently documented, so it would effectively be an API change. > And since the h264 decoder is the only one misbehaving in this way, > fixing it is the better alternative. Not necessarily, a lot of parameters are valid only in the avframe while in the context they might not be completely updated. The first that comes to mind is interlaced_frame -- there are 3 places this might (or might not) be signalled (context, frame and stream or parser iirc) but the RightWay is to check it from the frame only. Do you have a test case where using the API exposes some kind of problem? -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH] h264: update avctx width/height when flushing
On 12.06.2015 22:03, Hendrik Leppkes wrote: > On Fri, Jun 12, 2015 at 10:01 PM, Andreas Cadhalpun > wrote: >> That's not currently documented, so it would effectively be an API change. >> And since the h264 decoder is the only one misbehaving in this way, >> fixing it is the better alternative. >> > > If you would have actually fixed it. But you didn't. You're hiding the > problem under a layer of hacks. It is fixed for the API users, who don't care about the way it's implemented. If you know of a better/simpler way to fix it, please go for it. But letting the problem persist is no good alternative. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mpegts: recognizes and export private streams
Am Fri, 12 Jun 2015 15:53:41 +0200
schrieb Michael Niedermayer :
> On Fri, Jun 12, 2015 at 12:38:19PM +0200, Wolfgang Lorenz wrote:
> > Am Fri, 12 Jun 2015 00:12:37 +0200
> > schrieb Wolfgang Lorenz :
> >
> > > Am Thu, 11 Jun 2015 23:11:37 +0200
> > > schrieb Michael Niedermayer :
> > >
> > > > On Thu, Jun 11, 2015 at 10:59:23PM +0200, Wolfgang Lorenz wrote:
> > > > > Hi Micheal,
> > > > >
> > > > > Am Wed, 10 Jun 2015 23:40:10 +0200
> > > > > schrieb Michael Niedermayer :
> > > > >
> > > > > > Based on patch by Wolfgang Lorenz
> > > > > > Signed-off-by: Michael Niedermayer
> > > > > > ---
> > > > > > libavformat/mpegts.c |7 +++
> > > > > > 1 file changed, 7 insertions(+)
> > > > > >
> > > > > > diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> > > > > > index eff6819..7b35d7f 100644
> > > > > > --- a/libavformat/mpegts.c
> > > > > > +++ b/libavformat/mpegts.c
> > > > > > @@ -835,6 +835,13 @@ static int mpegts_set_stream_info(AVStream
> > > > > > *st, PESContext *pes,
> > > > > > st->codec->codec_id = old_codec_id;
> > > > > > st->codec->codec_type = old_codec_type;
> > > > > > }
> > > > > > +if ((st->codec->codec_id == AV_CODEC_ID_NONE ||
> > > > > > st->request_probe == 1) &&
> > > > > > +!avcodec_is_open(st->codec) &&
> > > > > > +stream_type == 6) {
> > > > > > +st->codec->codec_type = AVMEDIA_TYPE_DATA;
> > > > > > +st->codec->codec_id = AV_CODEC_ID_BIN_DATA;
> > > > > > +st->request_probe = 1;
> > > > > > +}
> > > > > >
> > > > > > return 0;
> > > > > > }
> > > > >
> > > > > First things first: It's breaking fate-acodec-s302m for me.
> > > >
> > > > make sure you use latest git master of ffmpeg, there was a commit
> > > > rather recently that is needed
> > >
> > > Sorry, I had missed that. fate-acodec-s302m is passing now. I haven't
> > > waited until all tests finished, but I think it will be all right.
> > >
> > > > if that doesnt work with your file then please provide that file
> > > >
> > > >
> > > > [...]
> > > > > If in your patch the request_probe value is set to a higher value,
> > > > > like
> > > > > e.g. 10, avformat_find_stream_info() behaves nicely and I do not need
> > > > > to reset the value manually. fate-acodec-s302m is still broken,
> > > > > though.
> > > >
> > > > yes, the value will need finetuning, whats the more or less lowest
> > > > that results in 100% reliable detection ?
> > >
> > > My test case is already happy with a value as low as 2. I can not test
> > > much more right now, though. I don't really feel good, with having such
> > > a low threshold. Maybe the number could be made configurable? (I always
> > > like configurable ;-) ).
> >
> > Okay, I think it doesn't make much sense, to make this threshold
> > configurable. On the other hand, I'm not a friend of just blindly
> > choosing some number, that coincidently passes all tests. I like
> > choosing numbers, that come with a reason. So, how about assigning
> > AVPROBE_SCORE_STREAM_RETRY? The number is already predefined. Any
> > codec beating this threshold with a higher score is considered to have
> > a strong enough probing value, to automatically disable any further
> > probing. Aaand it coincidently passes all tests.
>
> applied patch with some increased threshold,
> using AVPROBE_SCORE_STREAM_RETRY as is would break detection of
> any format "asking" fo retrying so a lower value is better if it
> works
All right. Thank you!
Wolfgang
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH] h264: update avctx width/height when flushing
On Fri, Jun 12, 2015 at 10:01 PM, Andreas Cadhalpun wrote: > On 12.06.2015 21:51, Hendrik Leppkes wrote: >> On Fri, Jun 12, 2015 at 9:23 PM, Andreas Cadhalpun >>> I agree that it is not really elegant, but removing the assumption that >>> the avctx width/height/pix_fmt are from the last decoded frame instead >>> of the last returned frame from the h264 decoder is beyond me. >>> If someone more familiar with the h264 decoder could do that, it would >>> be great. >>> But until then, having this workaround is better than the current state. >>> So I've pushed this. >>> >> >> This patch is super ugly and a mega hack. > > Maybe. ;) > >> Just inform consumers that only AVFrame has the actual up-to-date >> values when a change in the bitstream happens and stop doing such >> crap. > > That's not currently documented, so it would effectively be an API change. > And since the h264 decoder is the only one misbehaving in this way, > fixing it is the better alternative. > If you would have actually fixed it. But you didn't. You're hiding the problem under a layer of hacks. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH] h264: update avctx width/height when flushing
On 12.06.2015 21:51, Hendrik Leppkes wrote: > On Fri, Jun 12, 2015 at 9:23 PM, Andreas Cadhalpun >> I agree that it is not really elegant, but removing the assumption that >> the avctx width/height/pix_fmt are from the last decoded frame instead >> of the last returned frame from the h264 decoder is beyond me. >> If someone more familiar with the h264 decoder could do that, it would >> be great. >> But until then, having this workaround is better than the current state. >> So I've pushed this. >> > > This patch is super ugly and a mega hack. Maybe. ;) > Just inform consumers that only AVFrame has the actual up-to-date > values when a change in the bitstream happens and stop doing such > crap. That's not currently documented, so it would effectively be an API change. And since the h264 decoder is the only one misbehaving in this way, fixing it is the better alternative. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] h264: update avctx width/height when flushing
On 12.06.2015 20:40, Michael Niedermayer wrote: > On Fri, Jun 12, 2015 at 06:19:47PM +0200, Andreas Cadhalpun wrote: >> On 10.06.2015 21:50, Michael Niedermayer wrote: >>> On Wed, Jun 10, 2015 at 09:10:31PM +0200, Andreas Cadhalpun wrote: Could these be fixed to use a new H264Context field instead? >>> >>> i think it might be possible for them to use the AVFrame height >>> but the code should be tested >> >> I tried a few things, but couldn't get it to work that way. >> In the end I decided to work around the differing expectations of the h264 >> decoder and the API users by backing up and restoring the internally >> used values. See attached patch. >> I tested this extensively and it fixes the problem without introducing >> another one as far as I can tell. >> One can see the effect, when using -loglevel debug, e.g. for the >> reinit-small_422_9-to-small_420_9.h264 sample: >> * Without the patch: >> [...] >> [h264 @ 0x196e320] Reinit context to 240x208, pix_fmt: yuv420p9le >> Frame parameters mismatch context 240,196,80 != 240,196,70 >> Last message repeated 1 times >> Input stream #0:0 frame changed from size:240x196 fmt:yuv422p9le to >> size:240x196 fmt:yuv420p9le >> [...] >> >> * With the patch: >> [...] >> [h264 @ 0x2707320] Reinit context to 240x208, pix_fmt: yuv420p9le >> Input stream #0:0 frame changed from size:240x196 fmt:yuv422p9le to >> size:240x196 fmt:yuv420p9le >> [...] >> >> The messages about the parameter mismatch for the two frames disappear. > > Maybe the code should be moved to avcodec_decode_video2() > and the variables to AVCodecInternal > and then maybe a FF_CODEC_CAP_... could be used to mark decoders which > need this code. That way it could be used for other decoders too As far as I know, no other decoder has this problem and I really hope that newly added ones won't have it either. So letting this workaround stay h264-specific seems better. > but the patch as is is probably ok too as is, though it does feel a > bit inelegant either way I agree that it is not really elegant, but removing the assumption that the avctx width/height/pix_fmt are from the last decoded frame instead of the last returned frame from the h264 decoder is beyond me. If someone more familiar with the h264 decoder could do that, it would be great. But until then, having this workaround is better than the current state. So I've pushed this. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] h264: update avctx width/height when flushing
On Fri, Jun 12, 2015 at 06:19:47PM +0200, Andreas Cadhalpun wrote: > On 10.06.2015 21:50, Michael Niedermayer wrote: > > On Wed, Jun 10, 2015 at 09:10:31PM +0200, Andreas Cadhalpun wrote: > >> On 10.06.2015 12:01, Michael Niedermayer wrote: > also avctx->pix_fmt would then still potentially not match the last > output frame, also pix_fmt has the same problem as above > >> > >> Yes, pix_fmt should also be updated. Attached patch does this, but > > > >> this caused changes in some h264 reinit fate tests. Is that a problem? > > > > looking at the testfile with ffplay shows heavy artifacts after the > > patch and no artifacts before > > Yes, that's bad... > > ive fixed one use of width/height not to depend on the AVCodecContext > value but a 2nd remains > >>> > >>> actually theres more code that uses it > >>> ff_h264_draw_horiz_band() and its callers use h->avctx->height too > >> > >> Could these be fixed to use a new H264Context field instead? > > > > i think it might be possible for them to use the AVFrame height > > but the code should be tested > > I tried a few things, but couldn't get it to work that way. > In the end I decided to work around the differing expectations of the h264 > decoder and the API users by backing up and restoring the internally > used values. See attached patch. > I tested this extensively and it fixes the problem without introducing > another one as far as I can tell. > One can see the effect, when using -loglevel debug, e.g. for the > reinit-small_422_9-to-small_420_9.h264 sample: > * Without the patch: > [...] > [h264 @ 0x196e320] Reinit context to 240x208, pix_fmt: yuv420p9le > Frame parameters mismatch context 240,196,80 != 240,196,70 > Last message repeated 1 times > Input stream #0:0 frame changed from size:240x196 fmt:yuv422p9le to > size:240x196 fmt:yuv420p9le > [...] > > * With the patch: > [...] > [h264 @ 0x2707320] Reinit context to 240x208, pix_fmt: yuv420p9le > Input stream #0:0 frame changed from size:240x196 fmt:yuv422p9le to > size:240x196 fmt:yuv420p9le > [...] > > The messages about the parameter mismatch for the two frames disappear. Maybe the code should be moved to avcodec_decode_video2() and the variables to AVCodecInternal and then maybe a FF_CODEC_CAP_... could be used to mark decoders which need this code. That way it could be used for other decoders too but the patch as is is probably ok too as is, though it does feel a bit inelegant either way [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: enable VSX for ppc64el
Together with commit 04f0002 this changes the behavior back to what it
was was before commit b0af404.
Signed-off-by: Andreas Cadhalpun
---
configure | 3 +++
1 file changed, 3 insertions(+)
diff --git a/configure b/configure
index 0c907ff..3a6af6e 100755
--- a/configure
+++ b/configure
@@ -4610,6 +4610,9 @@ unsigned int endian = 'B' << 24 | 'I' << 16 | 'G' << 8 |
'E';
EOF
od -t x1 $TMPO | grep -q '42 *49 *47 *45' && enable bigendian
+if enabled ppc64 && ! enabled bigendian && enabled altivec; then
+enable vsx
+fi
check_gas() {
log "check_gas using '$as' as AS"
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/imgconvert.c: support left band while cropping
On Fri, Jun 12, 2015 at 06:38:05PM +0200, Przemysław Sobala wrote: > Hi > I attach a little patch that introduces support for left band while > cropping. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: Detect jpeg2000 through codec_ul too
On Fri, Jun 12, 2015 at 05:17:46PM +, Paul B Mahol wrote:
> On 6/12/15, Michael Niedermayer wrote:
> > Fixes Ticket2345
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/mxfdec.c | 14 ++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index 78e2393..7389555 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -166,6 +166,7 @@ typedef struct MXFDescriptor {
> > enum MXFMetadataSetType type;
> > UID essence_container_ul;
> > UID essence_codec_ul;
> > +UID codec_ul;
> > AVRational sample_rate;
> > AVRational aspect_ratio;
> > int width;
> > @@ -974,6 +975,9 @@ static int mxf_read_generic_descriptor(void *arg,
> > AVIOContext *pb, int tag, int
> > case 0x3004:
> > avio_read(pb, descriptor->essence_container_ul, 16);
> > break;
> > +case 0x3005:
> > +avio_read(pb, descriptor->codec_ul, 16);
> > +break;
> > case 0x3006:
> > descriptor->linked_track_id = avio_rb32(pb);
> > break;
> > @@ -1151,6 +1155,11 @@ static const MXFCodecUL
> > mxf_data_essence_container_uls[] = {
> > { {
> > 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
> > }, 0, AV_CODEC_ID_NONE },
> > };
> >
> > +static const MXFCodecUL mxf_codec_uls[] = {
> > +{ {
> > 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x09,0x04,0x01,0x02,0x02,0x03,0x01,0x01,0x00
> > }, 14, AV_CODEC_ID_JPEG2000 },
> > +{ {
> > 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
> > }, 0, AV_CODEC_ID_NONE },
> > +};
> > +
> > static const char* const mxf_data_essence_descriptor[] = {
> > "vbi_vanc_smpte_436M",
> > };
> > @@ -1950,6 +1959,11 @@ static int mxf_parse_structural_metadata(MXFContext
> > *mxf)
> > /* TODO: drop PictureEssenceCoding and SoundEssenceCompression,
> > only check EssenceContainer */
> > codec_ul = mxf_get_codec_ul(ff_mxf_codec_uls,
> > &descriptor->essence_codec_ul);
> > st->codec->codec_id = (enum AVCodecID)codec_ul->id;
> > +if (st->codec->codec_id == AV_CODEC_ID_NONE) {
> > +codec_ul = mxf_get_codec_ul(mxf_codec_uls,
> > &descriptor->codec_ul);
> > +st->codec->codec_id = (enum AVCodecID)codec_ul->id;
> > +}
> > +
> > av_log(mxf->fc, AV_LOG_VERBOSE, "%s: Universal Label: ",
> > avcodec_get_name(st->codec->codec_id));
> > for (k = 0; k < 16; k++) {
> > --
> > 1.7.9.5
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
>
> lgtm
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Observe your enemies, for they first find out your faults. -- Antisthenes
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] matroskadec: verify seekhead IDs
On Fri, Jun 12, 2015 at 01:11:41PM +0200, wm4 wrote: > Some files have SeekHead elements with broken IDs. They mismatch with > the ID of the destination element. These files are written by > "IDMmkvlib0.1" (as identified by the MuxingApp and WritingApp elements), > and the SeekHead IDs are actually endian-swapped. > > This confuses the SeekHead logic of the demuxer. It will read some > elements twice, because the SeekHead ID is used to identify and remember > already read elements. With the file at hand, the stream list was > duplicated by reading the Tracks element twice. > > Fix this by rejecting invalid EBML IDs in SeekHead entries. (This fix is > relatively specific to the broken file at hand, and doesn't protect > against some other cases of broken SeekHead, such as valid but > mismatching target element IDs.) > --- > libavformat/matroskadec.c | 12 > 1 file changed, 12 insertions(+) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: Detect jpeg2000 through codec_ul too
On 6/12/15, Michael Niedermayer wrote:
> Fixes Ticket2345
>
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mxfdec.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index 78e2393..7389555 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -166,6 +166,7 @@ typedef struct MXFDescriptor {
> enum MXFMetadataSetType type;
> UID essence_container_ul;
> UID essence_codec_ul;
> +UID codec_ul;
> AVRational sample_rate;
> AVRational aspect_ratio;
> int width;
> @@ -974,6 +975,9 @@ static int mxf_read_generic_descriptor(void *arg,
> AVIOContext *pb, int tag, int
> case 0x3004:
> avio_read(pb, descriptor->essence_container_ul, 16);
> break;
> +case 0x3005:
> +avio_read(pb, descriptor->codec_ul, 16);
> +break;
> case 0x3006:
> descriptor->linked_track_id = avio_rb32(pb);
> break;
> @@ -1151,6 +1155,11 @@ static const MXFCodecUL
> mxf_data_essence_container_uls[] = {
> { {
> 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
> }, 0, AV_CODEC_ID_NONE },
> };
>
> +static const MXFCodecUL mxf_codec_uls[] = {
> +{ {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x09,0x04,0x01,0x02,0x02,0x03,0x01,0x01,0x00
> }, 14, AV_CODEC_ID_JPEG2000 },
> +{ {
> 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
> }, 0, AV_CODEC_ID_NONE },
> +};
> +
> static const char* const mxf_data_essence_descriptor[] = {
> "vbi_vanc_smpte_436M",
> };
> @@ -1950,6 +1959,11 @@ static int mxf_parse_structural_metadata(MXFContext
> *mxf)
> /* TODO: drop PictureEssenceCoding and SoundEssenceCompression,
> only check EssenceContainer */
> codec_ul = mxf_get_codec_ul(ff_mxf_codec_uls,
> &descriptor->essence_codec_ul);
> st->codec->codec_id = (enum AVCodecID)codec_ul->id;
> +if (st->codec->codec_id == AV_CODEC_ID_NONE) {
> +codec_ul = mxf_get_codec_ul(mxf_codec_uls,
> &descriptor->codec_ul);
> +st->codec->codec_id = (enum AVCodecID)codec_ul->id;
> +}
> +
> av_log(mxf->fc, AV_LOG_VERBOSE, "%s: Universal Label: ",
> avcodec_get_name(st->codec->codec_id));
> for (k = 0; k < 16; k++) {
> --
> 1.7.9.5
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] matroskadec: verify seekhead IDs
wm4 googlemail.com> writes: > Some files have SeekHead elements with broken IDs. > They mismatch with the ID of the destination > element. These files are written by "IDMmkvlib0.1" An additional sample "Kyrie Irving" is in incoming. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/mxfdec: Detect jpeg2000 through codec_ul too
Fixes Ticket2345
Signed-off-by: Michael Niedermayer
---
libavformat/mxfdec.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 78e2393..7389555 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -166,6 +166,7 @@ typedef struct MXFDescriptor {
enum MXFMetadataSetType type;
UID essence_container_ul;
UID essence_codec_ul;
+UID codec_ul;
AVRational sample_rate;
AVRational aspect_ratio;
int width;
@@ -974,6 +975,9 @@ static int mxf_read_generic_descriptor(void *arg,
AVIOContext *pb, int tag, int
case 0x3004:
avio_read(pb, descriptor->essence_container_ul, 16);
break;
+case 0x3005:
+avio_read(pb, descriptor->codec_ul, 16);
+break;
case 0x3006:
descriptor->linked_track_id = avio_rb32(pb);
break;
@@ -1151,6 +1155,11 @@ static const MXFCodecUL mxf_data_essence_container_uls[]
= {
{ {
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
}, 0, AV_CODEC_ID_NONE },
};
+static const MXFCodecUL mxf_codec_uls[] = {
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x09,0x04,0x01,0x02,0x02,0x03,0x01,0x01,0x00
}, 14, AV_CODEC_ID_JPEG2000 },
+{ {
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
}, 0, AV_CODEC_ID_NONE },
+};
+
static const char* const mxf_data_essence_descriptor[] = {
"vbi_vanc_smpte_436M",
};
@@ -1950,6 +1959,11 @@ static int mxf_parse_structural_metadata(MXFContext *mxf)
/* TODO: drop PictureEssenceCoding and SoundEssenceCompression, only
check EssenceContainer */
codec_ul = mxf_get_codec_ul(ff_mxf_codec_uls,
&descriptor->essence_codec_ul);
st->codec->codec_id = (enum AVCodecID)codec_ul->id;
+if (st->codec->codec_id == AV_CODEC_ID_NONE) {
+codec_ul = mxf_get_codec_ul(mxf_codec_uls, &descriptor->codec_ul);
+st->codec->codec_id = (enum AVCodecID)codec_ul->id;
+}
+
av_log(mxf->fc, AV_LOG_VERBOSE, "%s: Universal Label: ",
avcodec_get_name(st->codec->codec_id));
for (k = 0; k < 16; k++) {
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavcodec/imgconvert.c: support left band while cropping
Hi
I attach a little patch that introduces support for left band while
cropping.
--
Regards
Przemysław Sobala
Główne Spółki Grupy Wirtualna Polska:
Wirtualna Polska Holding Spółka Akcyjna z siedzibą w Warszawie, ul. Jutrzenki
137A, 02-231 Warszawa, wpisana do Krajowego Rejestru Sądowego - Rejestru
Przedsiębiorców prowadzonego przez Sąd Rejonowy dla m.st. Warszawy w Warszawie
pod nr KRS: 407130, kapitał zakładowy: 1 245 651,90 zł (w całości
wpłacony), Numer Identyfikacji Podatkowej (NIP): 521-31-11-513
Grupa Wirtualna Polska Spółka z ograniczoną odpowiedzialnością z siedzibą w
Warszawie, ul. Jutrzenki 137A, 02-231 Warszawa, wpisana do Krajowego Rejestru
Sądowego - Rejestru Przedsiębiorców prowadzonego przez Sąd Rejonowy dla m.st.
Warszawy w Warszawie pod nr KRS: 373814, kapitał zakładowy: 311.005.050,00
zł, Numer Identyfikacji Podatkowej (NIP): 527-26-45-593
WP Shopping Spółka z ograniczoną odpowiedzialnością z siedzibą w Gdańsku, ul.
Romualda Traugutta 115 C, 80-226 Gdańsk, wpisana do Krajowego Rejestru Sądowego
- Rejestru Przedsiębiorców prowadzonego przez Sąd Rejonowy Gdańsk - Północ w
Gdańsku pod nr KRS: 546914, kapitał zakładowy: 170.000,00 złotych (w
całości wpłacony), Numer Identyfikacji Podatkowej (NIP): 957-07-51-216
diff --git a/libavcodec/imgconvert.c b/libavcodec/imgconvert.c
index 158bc73..381a077 100644
--- a/libavcodec/imgconvert.c
+++ b/libavcodec/imgconvert.c
@@ -201,12 +209,14 @@ int av_picture_crop(AVPicture *dst, const AVPicture *src,
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
int y_shift;
int x_shift;
+int max_step[4];
if (pix_fmt < 0 || pix_fmt >= AV_PIX_FMT_NB)
return -1;
y_shift = desc->log2_chroma_h;
x_shift = desc->log2_chroma_w;
+av_image_fill_max_pixsteps(max_step, NULL, desc);
if (is_yuv_planar(desc)) {
dst->data[0] = src->data[0] + (top_band * src->linesize[0]) + left_band;
@@ -215,9 +225,7 @@ int av_picture_crop(AVPicture *dst, const AVPicture *src,
} else{
if(top_band % (1data[0] + (top_band * src->linesize[0]) + left_band;
+dst->data[0] = src->data[0] + (top_band * src->linesize[0]) + (left_band * max_step[0]);
}
dst->linesize[0] = src->linesize[0];
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] h264: update avctx width/height when flushing
On 10.06.2015 21:50, Michael Niedermayer wrote:
> On Wed, Jun 10, 2015 at 09:10:31PM +0200, Andreas Cadhalpun wrote:
>> On 10.06.2015 12:01, Michael Niedermayer wrote:
also avctx->pix_fmt would then still potentially not match the last
output frame, also pix_fmt has the same problem as above
>>
>> Yes, pix_fmt should also be updated. Attached patch does this, but
>
>> this caused changes in some h264 reinit fate tests. Is that a problem?
>
> looking at the testfile with ffplay shows heavy artifacts after the
> patch and no artifacts before
Yes, that's bad...
ive fixed one use of width/height not to depend on the AVCodecContext
value but a 2nd remains
>>>
>>> actually theres more code that uses it
>>> ff_h264_draw_horiz_band() and its callers use h->avctx->height too
>>
>> Could these be fixed to use a new H264Context field instead?
>
> i think it might be possible for them to use the AVFrame height
> but the code should be tested
I tried a few things, but couldn't get it to work that way.
In the end I decided to work around the differing expectations of the h264
decoder and the API users by backing up and restoring the internally
used values. See attached patch.
I tested this extensively and it fixes the problem without introducing
another one as far as I can tell.
One can see the effect, when using -loglevel debug, e.g. for the
reinit-small_422_9-to-small_420_9.h264 sample:
* Without the patch:
[...]
[h264 @ 0x196e320] Reinit context to 240x208, pix_fmt: yuv420p9le
Frame parameters mismatch context 240,196,80 != 240,196,70
Last message repeated 1 times
Input stream #0:0 frame changed from size:240x196 fmt:yuv422p9le to
size:240x196 fmt:yuv420p9le
[...]
* With the patch:
[...]
[h264 @ 0x2707320] Reinit context to 240x208, pix_fmt: yuv420p9le
Input stream #0:0 frame changed from size:240x196 fmt:yuv422p9le to
size:240x196 fmt:yuv420p9le
[...]
The messages about the parameter mismatch for the two frames disappear.
> especially with a file that uses croping and some application that
> uses these codepathes
> iam not sure this codepath works currently with files using croping
> and using the AVFrame height and if needed an adjusted pointer
> offset might fix that or might break it depending on what applications
> expect
I don't know, whether or not this currently works, but it shouldn't
be affected by attached patch.
Best regards,
Andreas
>From 61f8aad99f05173a15ec28802ee8c92439bb2b0c Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Tue, 9 Jun 2015 23:38:26 +0200
Subject: [PATCH] h264: update avctx width/height/pix_fmt when returning frame
Inconsistencies between the dimensions/pixel format of avctx and the
frame can confuse API users.
For example this can crash the demuxing_decoding example.
Back up the previous values and restore them, when decoding the next
frame. This is necessary, because these can be different between the
returned frame and the last decoded frame.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/h264.c | 24
libavcodec/h264.h | 8
libavcodec/h264_slice.c | 3 +++
3 files changed, 35 insertions(+)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 9a00214..9be317c 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -591,6 +591,9 @@ static int h264_init_context(AVCodecContext *avctx, H264Context *h)
int i;
h->avctx = avctx;
+h->backup_width = -1;
+h->backup_height = -1;
+h->backup_pix_fmt= AV_PIX_FMT_NONE;
h->dequant_coeff_pps = -1;
h->current_sps_id= -1;
h->cur_chroma_format_idc = -1;
@@ -1675,6 +1678,14 @@ static int output_frame(H264Context *h, AVFrame *dst, H264Picture *srcp)
av_dict_set(&dst->metadata, "stereo_mode", ff_h264_sei_stereo_mode(h), 0);
+h->backup_width = h->avctx->width;
+h->backup_height = h->avctx->height;
+h->backup_pix_fmt = h->avctx->pix_fmt;
+
+h->avctx->width = dst->width;
+h->avctx->height = dst->height;
+h->avctx->pix_fmt = dst->format;
+
if (srcp->sei_recovery_frame_cnt == 0)
dst->key_frame = 1;
if (!srcp->crop)
@@ -1726,6 +1737,19 @@ static int h264_decode_frame(AVCodecContext *avctx, void *data,
h->flags = avctx->flags;
+if (h->backup_width != -1) {
+avctx->width= h->backup_width;
+h->backup_width = -1;
+}
+if (h->backup_height != -1) {
+avctx->height= h->backup_height;
+h->backup_height = -1;
+}
+if (h->backup_pix_fmt != AV_PIX_FMT_NONE) {
+avctx->pix_fmt= h->backup_pix_fmt;
+h->backup_pix_fmt = AV_PIX_FMT_NONE;
+}
+
ff_h264_unref_picture(h, &h->last_pic_for_ec);
/* end of stream, output what is still in the buffers */
diff --git a/libavcodec/h264.h b/libavcodec/h264.h
index 95db912..548510d 100644
--- a/libavcodec/h264.h
+++ b/libavcodec/h264.h
@@ -519,6 +519,14 @@ typedef struct H264Context {
Re: [FFmpeg-devel] Contributing to the project?
Hi George, On Thu, Jun 11, 2015 at 1:57 PM, George Boyle wrote: > Hi Ronald, > > On 11/06/15 17:01, Ronald S. Bultje wrote: > > > > It would also be helpful if you could identify what you would like to be > > doing, i.e. do you have any particular aspect that you find particularly > > exciting or intriguing and would like to learn more about? E.g. you might > > like one of video codecs or audio codecs or muxing formats more; you > might > > prefer decoding algorithms, encoding algorithms or optimizations more; > you > > might be more interested in the fundamentals of any one of those (either > by > > fixing algorithm bugs/extending algorithms to handle wider aspects of > > existing formats, or by writing new codecs/(de)muxers from scratch), or > > initially learning more through testing techniques (code coverage, > fuzzing). > > > > (That sounds like a lot, but it helps point you in a particular direction > > if we know where you'd like to go.) > > > > Thanks for your reply. Yes, a more specific goal would be useful! In > thinking about it, there are 2 areas in particular that I find most > interesting, both originally stemming from being an avid user of the > ffmpeg command-line tool. > > The first is the program itself, and the workings of the project around > it - its pace, scale and robustness. In that regard, I thought learning > about the testing system would be a good place to start. This is also > the closest thing to a match with my existing experience. Plus, I do > enjoy testing. I think the suggestion of doing some documentation would > also be a good way to get familiar with the codebase. > > Second would be container formats and muxing/demuxing. The matroska and > ogg formats spring to mind, but I'd like to learn about any of them. The > idea of coding one up from scratch sounds very interesting, though I'd > need to study up a lot first. > > Those would be the standouts, but I'd enjoy getting involved in any of > the things you mentioned. I'd like to do some bug-fixing too, and I keep > an eye on the tracker, but I heven't got enough knowledge to take one on > yet. Hopefully I will soon. > > > == tl;dr == > I was thinking of the following ramp: > 1. Start with testing and docs > 2. Learn about and work on container formats and (de)muxing > > > Does that sound like a reasonable way to proceed? Yeah, absolutely; most of us started with tasks to get us up and running and familiar with this whole thing. You'll know when you're comfortable doing that kind of stuff, and that's probably when it's the right time to write your complete own demuxers (even if you don't think it is yet; it should be a bit of a challenge, after all). There's always stuff to be done. Good luck! Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] jpeg2000: unsupported marker 0xFF5F at pos 0x73
On Saturday 28 September 2013 07:58:41 am Wolfgang Woehl wrote: > See fdfcde74_excerpt_00-23 (on > ftp://upload.ffmpeg.org/MPlayer/incoming/ as suggested by ffplay). > > The dir contains a MXF (DCI specs) with 24 4K frames The 40kb mxf file decodes bit-exact now with current FFmpeg (compared to libopenjpeg), all 24 frames are entirely black. > and a 1/4-sized proxy video of that segment. The h264 file you also uploaded looks visually different though... Thank you for the sample! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mpegts: recognizes and export private streams
On Fri, Jun 12, 2015 at 12:38:19PM +0200, Wolfgang Lorenz wrote:
> Am Fri, 12 Jun 2015 00:12:37 +0200
> schrieb Wolfgang Lorenz :
>
> > Am Thu, 11 Jun 2015 23:11:37 +0200
> > schrieb Michael Niedermayer :
> >
> > > On Thu, Jun 11, 2015 at 10:59:23PM +0200, Wolfgang Lorenz wrote:
> > > > Hi Micheal,
> > > >
> > > > Am Wed, 10 Jun 2015 23:40:10 +0200
> > > > schrieb Michael Niedermayer :
> > > >
> > > > > Based on patch by Wolfgang Lorenz
> > > > > Signed-off-by: Michael Niedermayer
> > > > > ---
> > > > > libavformat/mpegts.c |7 +++
> > > > > 1 file changed, 7 insertions(+)
> > > > >
> > > > > diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> > > > > index eff6819..7b35d7f 100644
> > > > > --- a/libavformat/mpegts.c
> > > > > +++ b/libavformat/mpegts.c
> > > > > @@ -835,6 +835,13 @@ static int mpegts_set_stream_info(AVStream *st,
> > > > > PESContext *pes,
> > > > > st->codec->codec_id = old_codec_id;
> > > > > st->codec->codec_type = old_codec_type;
> > > > > }
> > > > > +if ((st->codec->codec_id == AV_CODEC_ID_NONE ||
> > > > > st->request_probe == 1) &&
> > > > > +!avcodec_is_open(st->codec) &&
> > > > > +stream_type == 6) {
> > > > > +st->codec->codec_type = AVMEDIA_TYPE_DATA;
> > > > > +st->codec->codec_id = AV_CODEC_ID_BIN_DATA;
> > > > > +st->request_probe = 1;
> > > > > +}
> > > > >
> > > > > return 0;
> > > > > }
> > > >
> > > > First things first: It's breaking fate-acodec-s302m for me.
> > >
> > > make sure you use latest git master of ffmpeg, there was a commit
> > > rather recently that is needed
> >
> > Sorry, I had missed that. fate-acodec-s302m is passing now. I haven't
> > waited until all tests finished, but I think it will be all right.
> >
> > > if that doesnt work with your file then please provide that file
> > >
> > >
> > > [...]
> > > > If in your patch the request_probe value is set to a higher value, like
> > > > e.g. 10, avformat_find_stream_info() behaves nicely and I do not need
> > > > to reset the value manually. fate-acodec-s302m is still broken, though.
> > >
> > > yes, the value will need finetuning, whats the more or less lowest
> > > that results in 100% reliable detection ?
> >
> > My test case is already happy with a value as low as 2. I can not test
> > much more right now, though. I don't really feel good, with having such
> > a low threshold. Maybe the number could be made configurable? (I always
> > like configurable ;-) ).
>
> Okay, I think it doesn't make much sense, to make this threshold
> configurable. On the other hand, I'm not a friend of just blindly
> choosing some number, that coincidently passes all tests. I like
> choosing numbers, that come with a reason. So, how about assigning
> AVPROBE_SCORE_STREAM_RETRY? The number is already predefined. Any
> codec beating this threshold with a higher score is considered to have
> a strong enough probing value, to automatically disable any further
> probing. Aaand it coincidently passes all tests.
applied patch with some increased threshold,
using AVPROBE_SCORE_STREAM_RETRY as is would break detection of
any format "asking" fo retrying so a lower value is better if it
works
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] encoders.texi: update libvpx documentation
On date Wednesday 2015-06-10 20:58:33 -0700, James Zern encoded:
> modeled after the libx264 section.
> ---
> doc/encoders.texi | 163
> ++
> 1 file changed, 92 insertions(+), 71 deletions(-)
>
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index 753e683..e0ad13e 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -1416,113 +1416,134 @@ You need to explicitly configure the build with
> @code{--enable-libvpx}.
>
> @subsection Options
>
> -Mapping from FFmpeg to libvpx options with conversion notes in parentheses.
> +The following options are supported by the libvpx wrapper. The
> +@command{vpxenc}-equivalent options or values are listed in parentheses
> +for easy migration.
>
> -@table @option
> +To reduce the duplication of documentation, only the private options
> +and some others requiring special attention are documented here. For
> +the documentation of the undocumented generic options, see
> +@ref{codec-options,,the Codec Options chapter}.
>
> -@item threads
> -g_threads
> +To get more documentation of the libvpx options, invoke the command
> +@command{ffmpeg -h encoder=libvpx}, @command{ffmpeg -h encoder=libvpx-vp9} or
> +@command{vpxenc --help}. Further information is available in the libvpx API
> +documentation.
>
> -@item profile
> -g_profile
> +@table @option
>
> -@item vb
> -rc_target_bitrate
> +@item b (@emph{target-bitrate})
> +Set bitrate in bits/s. Note that FFmpeg's @option{b} option is
> +expressed in bits/s, while @command{vpxenc}'s @option{target-bitrate} is in
> +kilobits/s.
>
> -@item g
> -kf_max_dist
> +@item g (@emph{kf-max-dist})
>
> -@item keyint_min
> -kf_min_dist
> +@item keyint_min (@emph{kf-min-dist})
>
> -@item qmin
> -rc_min_quantizer
> +@item qmin (@emph{min-q})
>
> -@item qmax
> -rc_max_quantizer
> +@item qmax (@emph{max-q})
>
> -@item bufsize, vb
> -rc_buf_sz
> -@code{(bufsize * 1000 / vb)}
> +@item bufsize (@emph{buf-sz}, @emph{buf-optimal-sz})
> +Set ratecontrol buffer size (in bits). Note @command{vpxenc}'s options are
> +specified in milliseconds, the libvpx wrapper converts this value as follows:
> +@code{buf-sz = bufsize * 1000 / bitrate},
> +@code{buf-optimal-sz = bufsize * 1000 / bitrate * 5 / 6}.
>
> -rc_buf_optimal_sz
> -@code{(bufsize * 1000 / vb * 5 / 6)}
> +@item rc_init_occupancy (@emph{buf-initial-sz})
> +Set number of bits which should be loaded into the rc buffer before decoding
> +starts. Note @command{vpxenc}'s option is specified in milliseconds, the
> libvpx
> +wrapper converts this value as follows:
> +@code{rc_init_occupancy * 1000 / bitrate}.
>
> -@item rc_init_occupancy, vb
> -rc_buf_initial_sz
> -@code{(rc_init_occupancy * 1000 / vb)}
> +@item undershoot-pct
> +Datarate undershoot (min) percentage of the target bitrate.
>
> -@item rc_buffer_aggressivity
> -rc_undershoot_pct
> +@item overshoot-pct
> +Datarate overshoot (max) percentage of the target bitrate.
>
> -@item skip_threshold
> -rc_dropframe_thresh
> +@item skip_threshold (@emph{drop-frame})
>
> -@item qcomp
> -rc_2pass_vbr_bias_pct
> +@item qcomp (@emph{bias-pct})
>
> -@item maxrate, vb
> -rc_2pass_vbr_maxsection_pct
> -@code{(maxrate * 100 / vb)}
> +@item maxrate (@emph{maxsection-pct})
> +GOP max bitrate in bits/s. Note @command{vpxenc}'s option is specified as a
> +percentage of the target bitrate, the libvpx wrapper converts this value as
> +follows: @code{(maxrate * 100 / bitrate)}.
>
> -@item minrate, vb
> -rc_2pass_vbr_minsection_pct
> -@code{(minrate * 100 / vb)}
> +@item minrate (@emph{minsection-pct})
> +GOP min bitrate in bits/s. Note @command{vpxenc}'s option is specified as a
> +percentage of the target bitrate, the libvpx wrapper converts this value as
> +follows: @code{(minrate * 100 / bitrate)}.
>
> -@item minrate, maxrate, vb
> -@code{VPX_CBR}
> -@code{(minrate == maxrate == vb)}
> +@item minrate, maxrate, b @emph{end-usage=cbr}
> +@code{(minrate == maxrate == bitrate)}.
>
> -@item crf
> -@code{VPX_CQ}, @code{VP8E_SET_CQ_LEVEL}
> +@item crf (@emph{end-usage=cq}, @emph{cq-level})
>
> -@item quality
> +@item quality, deadline (@emph{deadline})
> @table @option
> @item @var{best}
> -@code{VPX_DL_BEST_QUALITY}
> +Use best quality deadline. Poorly named and quite slow, this option should be
> +avoided as it may give worse quality output than good.
> @item @var{good}
> -@code{VPX_DL_GOOD_QUALITY}
> +Use good quality deadline. This is a good trade-off between speed and quality
> +when used with the @option{cpu-used} option.
> @item @var{realtime}
> -@code{VPX_DL_REALTIME}
> +Use realtime quality deadline.
> @end table
>
> -@item speed
> -@code{VP8E_SET_CPUUSED}
> +@item speed, cpu-used (@emph{cpu-used})
> +Quality/Speed ratio modifier.
Nit: Set quality/speed ...
In general, a verbal form is favored ("Set number of foos in the bar.",
rather than "number of foos in the bar").
>
> -@item nr
> -@code{VP8E_SET_NOISE_SENSITIVITY}
> +@item nr (@emph{noise
[FFmpeg-devel] [PATCH] matroskadec: verify seekhead IDs
Some files have SeekHead elements with broken IDs. They mismatch with
the ID of the destination element. These files are written by
"IDMmkvlib0.1" (as identified by the MuxingApp and WritingApp elements),
and the SeekHead IDs are actually endian-swapped.
This confuses the SeekHead logic of the demuxer. It will read some
elements twice, because the SeekHead ID is used to identify and remember
already read elements. With the file at hand, the stream list was
duplicated by reading the Tracks element twice.
Fix this by rejecting invalid EBML IDs in SeekHead entries. (This fix is
relatively specific to the broken file at hand, and doesn't protect
against some other cases of broken SeekHead, such as valid but
mismatching target element IDs.)
---
libavformat/matroskadec.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 1606341..3512f0f 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -995,6 +995,15 @@ static int ebml_parse_nest(MatroskaDemuxContext *matroska,
EbmlSyntax *syntax,
return res;
}
+static int is_ebml_id_valid(uint32_t id)
+{
+// Due to endian nonsense in Matroska, the highest byte with any bits set
+// will contain the leading length bit. This bit in turn identifies the
+// total byte length of the element by its position within the byte.
+unsigned int bits = av_log2(id);
+return id && (bits + 7) / 8 == (8 - bits % 8);
+}
+
/*
* Allocate and return the entry for the level1 element with the given ID. If
* an entry already exists, return the existing entry.
@@ -1005,6 +1014,9 @@ static MatroskaLevel1Element
*matroska_find_level1_elem(MatroskaDemuxContext *ma
int i;
MatroskaLevel1Element *elem;
+if (!is_ebml_id_valid(id))
+return NULL;
+
// Some files link to all clusters; useless.
if (id == MATROSKA_ID_CLUSTER)
return NULL;
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mpegts: recognizes and export private streams
Am Fri, 12 Jun 2015 00:12:37 +0200
schrieb Wolfgang Lorenz :
> Am Thu, 11 Jun 2015 23:11:37 +0200
> schrieb Michael Niedermayer :
>
> > On Thu, Jun 11, 2015 at 10:59:23PM +0200, Wolfgang Lorenz wrote:
> > > Hi Micheal,
> > >
> > > Am Wed, 10 Jun 2015 23:40:10 +0200
> > > schrieb Michael Niedermayer :
> > >
> > > > Based on patch by Wolfgang Lorenz
> > > > Signed-off-by: Michael Niedermayer
> > > > ---
> > > > libavformat/mpegts.c |7 +++
> > > > 1 file changed, 7 insertions(+)
> > > >
> > > > diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> > > > index eff6819..7b35d7f 100644
> > > > --- a/libavformat/mpegts.c
> > > > +++ b/libavformat/mpegts.c
> > > > @@ -835,6 +835,13 @@ static int mpegts_set_stream_info(AVStream *st,
> > > > PESContext *pes,
> > > > st->codec->codec_id = old_codec_id;
> > > > st->codec->codec_type = old_codec_type;
> > > > }
> > > > +if ((st->codec->codec_id == AV_CODEC_ID_NONE || st->request_probe
> > > > == 1) &&
> > > > +!avcodec_is_open(st->codec) &&
> > > > +stream_type == 6) {
> > > > +st->codec->codec_type = AVMEDIA_TYPE_DATA;
> > > > +st->codec->codec_id = AV_CODEC_ID_BIN_DATA;
> > > > +st->request_probe = 1;
> > > > +}
> > > >
> > > > return 0;
> > > > }
> > >
> > > First things first: It's breaking fate-acodec-s302m for me.
> >
> > make sure you use latest git master of ffmpeg, there was a commit
> > rather recently that is needed
>
> Sorry, I had missed that. fate-acodec-s302m is passing now. I haven't
> waited until all tests finished, but I think it will be all right.
>
> > if that doesnt work with your file then please provide that file
> >
> >
> > [...]
> > > If in your patch the request_probe value is set to a higher value, like
> > > e.g. 10, avformat_find_stream_info() behaves nicely and I do not need
> > > to reset the value manually. fate-acodec-s302m is still broken, though.
> >
> > yes, the value will need finetuning, whats the more or less lowest
> > that results in 100% reliable detection ?
>
> My test case is already happy with a value as low as 2. I can not test
> much more right now, though. I don't really feel good, with having such
> a low threshold. Maybe the number could be made configurable? (I always
> like configurable ;-) ).
Okay, I think it doesn't make much sense, to make this threshold
configurable. On the other hand, I'm not a friend of just blindly
choosing some number, that coincidently passes all tests. I like
choosing numbers, that come with a reason. So, how about assigning
AVPROBE_SCORE_STREAM_RETRY? The number is already predefined. Any
codec beating this threshold with a higher score is considered to have
a strong enough probing value, to automatically disable any further
probing. Aaand it coincidently passes all tests.
Greetings,
Wolfgang
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] colormatrix high-bit-depth input support
> Date: Fri, 5 Jun 2015 13:56:08 -0400 > From: c319ch...@aol.com > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] colormatrix high-bit-depth input support > > Here is some interesting reading on the subject: > > http://en.wikipedia.org/wiki/Rec._2020 > > https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2020-1-201406-I!!PDF-E.pdf > > There are two bit depths in BT.2020: 10 bits and 12 bits. There are also two > screen resolutions, known informally as "4k" and "8k". > > -Original Message- > From: Kevin Wells > To: FFmpeg development discussions and patches > Sent: Fri, Jun 5, 2015 8:34 am > Subject: Re: [FFmpeg-devel] colormatrix high-bit-depth input support > > > >> To: ffmpeg-devel@ffmpeg.org >> From: > ceho...@ag.or.at >> Date: Wed, 3 Jun 2015 22:53:09 + >> Subject: Re: > [FFmpeg-devel] colormatrix high-bit-depth input support >> >> Kevin Wells > hotmail.co.uk> writes: >> >>> Hi, I believe that currently the > colormatrix filter >>> only supports up to 8-bit input files. Is there any >>> > chance it will, in the future, support >>> high-bit-depth input files > (10-bit)? >> >> Patch certainly welcome. >> >> Carl Eugen >> >> > ___ >> ffmpeg-devel mailing list >> > ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > As > I have no experience in this area, any chance someone would look into > this? > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Anyone up for writing this patch, would be extremely useful. Kind regards. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 01/12] libavcodec: Implementation of AAC_fixed_decoder (LC-module) [1/4]
>On Thu, Jun 11, 2015 at 4:08 PM, Nedeljko Babic > wrote: >> From: Jovan Zelincevic >> >> Move existing code to the new template files >> > >Please setup your Git to track renames (add -M parameter), this is >really hard to review in this form. This patch is just moving parts of the code that can be used in both float and in fixed aac in appropriate template files. It does not do renames (or anything else for that matter). For example, the parts of code are moved from aacdec.c to new aacdec_template.c, but original file is still present with what was left of the code. Adding -M will not change anything in the patch. I tried from -M20% to -M75% just to be sure. - Nedeljko ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] Encoding of styles - Bold, Italic, Underlined for timed-text subttiles
Yes, the patch is for single style record only. I'll work on multiple
style records now.
Thanks,
Niklesh
On 6/12/15, Philip Langdale wrote:
> On Thu, 11 Jun 2015 10:18:53 +0530
> Niklesh Lalwani wrote:
>
>> From: Niklesh
>>
>> Encoding of bold, Italic, underlined styles for 3gpp timed text
>> subtitles. All the formatting information is appended into the buffer
>> after the text, unlike other encoders like srt, which can write out
>> styling information as it goes. Another tricky part is to take care
>> of the Endianness properly while writing into the buffer.
>>
>> Signed-off-by: Niklesh
>> ---
>> libavcodec/movtextenc.c | 104
>> +++- 1 file changed, 76
>> insertions(+), 28 deletions(-)
>>
>> diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
>> index 1b8f454..adbe19d 100644
>> --- a/libavcodec/movtextenc.c
>> +++ b/libavcodec/movtextenc.c
>> @@ -24,14 +24,27 @@
>> #include "libavutil/avassert.h"
>> #include "libavutil/avstring.h"
>> #include "libavutil/intreadwrite.h"
>> +#include "libavutil/common.h"
>> #include "ass_split.h"
>> #include "ass.h"
>>
>> +#define STYLE_FLAG_BOLD 1
>> +#define STYLE_FLAG_ITALIC 2
>> +#define STYLE_FLAG_UNDERLINE4
>> +
>> typedef struct {
>> ASSSplitContext *ass_ctx;
>> -char buffer[2048];
>> -char *ptr;
>> -char *end;
>> +AVBPrint buffer;
>> +uint32_t tsmb_size;
>> +uint32_t tsmb_type;
>> +uint16_t style_entries;
>> +uint16_t style_start;
>> +uint16_t style_end;
>> +uint16_t style_fontID;
>> +uint8_t style_flag;
>> +uint8_t style_fontsize;
>> +uint32_t style_color;
>> +uint16_t text_pos;
>> } MovTextContext;
>>
>>
>> @@ -47,10 +60,10 @@ static av_cold int
>> mov_text_encode_init(AVCodecContext *avctx)
>> 0xFF, // int8_t vertical-justification 0x00, 0x00,
>> 0x00, 0x00, // uint8_t background-color-rgba[4] // BoxRecord {
>> -0x00, 0x00, // int16_t top
>> -0x00, 0x00, // int16_t left
>> -0x00, 0x00, // int16_t bottom
>> -0x00, 0x00, // int16_t right
>> +0x00, 0x01, // int16_t top
>> +0x00, 0x01, // int16_t left
>> +0x00, 0x1E, // int16_t bottom
>> +0x00, 0xC8, // int16_t right
>
> Leave this part out of this diff. We'll deal with sizing later.
>
>> // };
>> // StyleRecord {
>> 0x00, 0x00, // uint16_t startChar
>> @@ -79,32 +92,54 @@ static av_cold int
>> mov_text_encode_init(AVCodecContext *avctx) if (!avctx->extradata)
>> return AVERROR(ENOMEM);
>>
>> +av_bprint_init(&s->buffer, 0, AV_BPRINT_SIZE_UNLIMITED);
>> +
>> memcpy(avctx->extradata, text_sample_entry,
>> avctx->extradata_size);
>> s->ass_ctx = ff_ass_split(avctx->subtitle_header);
>> return s->ass_ctx ? 0 : AVERROR_INVALIDDATA;
>> }
>>
>> +static void mov_text_style_cb(void *priv, const char style, int
>> close) +{
>> +MovTextContext *s = priv;
>> +s->tsmb_type = MKTAG('s','t','y','l');
>
> You don't need to do this. Use a simple boolean flag to indicate if any
> styles were generated.
>
>> +if (!close) {
>> +s->style_start = AV_RB16(&s->text_pos);
>> +switch (style){
>> +case 'b':
>> +s->style_flag += STYLE_FLAG_BOLD;
>> +break;
>> +case 'i':
>> +s->style_flag += STYLE_FLAG_ITALIC;
>> +break;
>> +case 'u':
>> +s->style_flag += STYLE_FLAG_UNDERLINE;
>> +break;
>> +}
>> +} else {
>> +s->style_end = AV_RB16(&s->text_pos);
>> +}
>> +}
>
> You are only storing a single set of style properties. So if multiple
> styles are used in the original subtitles, only the last one will take
> effect. You need to build up an array of style entries.
>
>> static void mov_text_text_cb(void *priv, const char *text, int len)
>> {
>> MovTextContext *s = priv;
>> -av_assert0(s->end >= s->ptr);
>> -av_strlcpy(s->ptr, text, FFMIN(s->end - s->ptr, len + 1));
>> -s->ptr += FFMIN(s->end - s->ptr, len);
>> +av_bprint_append_data(&s->buffer, text, len);
>> +s->text_pos += len;
>> }
>>
>> static void mov_text_new_line_cb(void *priv, int forced)
>> {
>> MovTextContext *s = priv;
>> -av_assert0(s->end >= s->ptr);
>> -av_strlcpy(s->ptr, "\n", FFMIN(s->end - s->ptr, 2));
>> -if (s->end > s->ptr)
>> -s->ptr++;
>> +av_bprint_append_data(&s->buffer, "\n", 2);
>> +s->text_pos += 2;
>> }
>>
>> static const ASSCodesCallbacks mov_text_callbacks = {
>> .text = mov_text_text_cb,
>> .new_line = mov_text_new_line_cb,
>> +.style= mov_text_style_cb,
>> };
>>
>> static int mov_text_encode_frame(AVCodecContext *avctx, unsigned
>> char *buf, @@ -112,10 +147,9 @@ static int
>> mov_text_encode_frame(AVCodecContext *avctx, unsigned char *buf, {
>>
