[FFmpeg-devel] [PATCH] avfilter/vf_dnn_processing: fix fate-source
Signed-off-by: Guo, Yejun
---
libavfilter/vf_dnn_processing.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_dnn_processing.c b/libavfilter/vf_dnn_processing.c
index 87ad354..a916d38 100644
--- a/libavfilter/vf_dnn_processing.c
+++ b/libavfilter/vf_dnn_processing.c
@@ -241,7 +241,7 @@ static int copy_from_dnn_to_frame(AVFrame *out, const
DNNData *dnn_data)
for(int j = 0; j < out->width * 3; j++) {
int k = i * out->linesize[0] + j;
int t = i * out->width * 3 + j;
-out->data[0][k] = av_clip((int)(dnn_output[t] * 255.0f), 0,
255);
+out->data[0][k] = av_clip_uintp2((int)(dnn_output[t] *
255.0f), 8);
}
}
} else {
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/vp9_raw_reorder_bsf.c adjust params keep same with api
oh, no, I'm a student learning ffmpeg now, and just learing git nowis there any
shell tools like make patch, send to my email use Private letter, thx
At 2019-11-08 14:24:28, "myp...@gmail.com" wrote: >On Fri,
Nov 8, 2019 at 2:14 PM darling.zhong wrote: >> >> >> >>
Signed-off-by: darling.zhong >> --- >>
libavcodec/h265_metadata_bsf.c | 2 +- >> 1 file changed, 1 insertion(+), 1
deletion(-) >> mode change 100644 => 100755 libavcodec/h265_metadata_bsf.c >>
>Please don't change the file mode >> >> diff --git
a/libavcodec/h265_metadata_bsf.c b/libavcodec/h265_metadata_bsf.c >> old mode
100644 >> new mode 100755 >> index b3a1fda144..730f7ac28f >> ---
a/libavcodec/h265_metadata_bsf.c >> +++ b/libavcodec/h265_metadata_bsf.c >> @@
-131,7 +131,7 @@ static void h265_metadata_guess_level(AVBSFContext *bsf, >> }
>> >> desc = ff_h265_guess_level(ptl, bit_rate, width, height, >> - 0,
tile_cols, tile_rows, >> + 0, tile_rows, tile_cols, >> max_dec_pic_buffering);
>> if (desc) { >> av_log(bsf, AV_LOG_DEBUG, "Stream appears to conform to " >>
-- >> 2.17.1 >___ >ffmpeg-devel
mailing list >ffmpeg-devel@ffmpeg.org
>https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >To unsubscribe, visit link
above, or email >ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avformat/mp3dec: Check for occurances of headers within frames during probing
On Thu, Nov 07, 2019 at 10:25:32PM +0100, Michael Niedermayer wrote:
> From: Limin Wang
>
> Fixes misdetection of zYLx.wav
>
> Co-Author: Michael Niedermayer
> Signed-off-by: Michael Niedermayer
why it's same?
> ---
> libavformat/mp3dec.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> index 6848415657..eb40362548 100644
> --- a/libavformat/mp3dec.c
> +++ b/libavformat/mp3dec.c
> @@ -73,7 +73,7 @@ static int mp3_read_probe(const AVProbeData *p)
> int frames, ret;
> int framesizes, max_framesizes;
> uint32_t header;
> -const uint8_t *buf, *buf0, *buf2, *end;
> +const uint8_t *buf, *buf0, *buf2, *buf3, *end;
>
> buf0 = p->buf;
> end = p->buf + p->buf_size - sizeof(uint32_t);
> @@ -88,11 +88,19 @@ static int mp3_read_probe(const AVProbeData *p)
> buf2 = buf;
> for(framesizes = frames = 0; buf2 < end; frames++) {
> MPADecodeHeader h;
> +int header_emu = 0;
>
> header = AV_RB32(buf2);
> ret = avpriv_mpegaudio_decode_header(, header);
> if (ret != 0 || end - buf2 < h.frame_size)
> break;
> +
> +for (buf3 = buf2 + 4; buf3 < buf2 + h.frame_size; buf3++) {
Sorry, please ignore my comments for the first patch, with patch2, it's
necessary.
The patch looks good to me, I have tested and OK.
> +uint32_t next_sync = AV_RB32(buf3);
> +header_emu += (next_sync & MP3_MASK) == (header & MP3_MASK);
> +}
> +if (header_emu > 2)
> +break;
> buf2 += h.frame_size;
> framesizes += h.frame_size;
> }
> --
> 2.23.0
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avformat/mp3dec: Check that the frame fits within the probe buffer
On Thu, Nov 07, 2019 at 10:25:31PM +0100, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavformat/mp3dec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c > index 258f19174b..6848415657 100644 > --- a/libavformat/mp3dec.c > +++ b/libavformat/mp3dec.c > @@ -91,7 +91,7 @@ static int mp3_read_probe(const AVProbeData *p) > > header = AV_RB32(buf2); > ret = avpriv_mpegaudio_decode_header(, header); > -if (ret != 0) > +if (ret != 0 || end - buf2 < h.frame_size) I think it's unneed to do the extra checking, as the buf2 will add the h.frame_size in the next code, it'll break still if buf2 > end for the for condition. > break; > buf2 += h.frame_size; > framesizes += h.frame_size; > -- > 2.23.0 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/vp9_raw_reorder_bsf.c adjust params keep same with api
On Fri, Nov 8, 2019 at 2:14 PM darling.zhong wrote:
>
>
>
> Signed-off-by: darling.zhong
> ---
> libavcodec/h265_metadata_bsf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> mode change 100644 => 100755 libavcodec/h265_metadata_bsf.c
>
Please don't change the file mode
>
> diff --git a/libavcodec/h265_metadata_bsf.c b/libavcodec/h265_metadata_bsf.c
> old mode 100644
> new mode 100755
> index b3a1fda144..730f7ac28f
> --- a/libavcodec/h265_metadata_bsf.c
> +++ b/libavcodec/h265_metadata_bsf.c
> @@ -131,7 +131,7 @@ static void h265_metadata_guess_level(AVBSFContext *bsf,
> }
>
> desc = ff_h265_guess_level(ptl, bit_rate, width, height,
> - 0, tile_cols, tile_rows,
> + 0, tile_rows, tile_cols,
> max_dec_pic_buffering);
> if (desc) {
> av_log(bsf, AV_LOG_DEBUG, "Stream appears to conform to "
> --
> 2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/vp9_raw_reorder_bsf.c adjust params keep same with api
Signed-off-by: darling.zhong
---
libavcodec/h265_metadata_bsf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
mode change 100644 => 100755 libavcodec/h265_metadata_bsf.c
diff --git a/libavcodec/h265_metadata_bsf.c b/libavcodec/h265_metadata_bsf.c
old mode 100644
new mode 100755
index b3a1fda144..730f7ac28f
--- a/libavcodec/h265_metadata_bsf.c
+++ b/libavcodec/h265_metadata_bsf.c
@@ -131,7 +131,7 @@ static void h265_metadata_guess_level(AVBSFContext *bsf,
}
desc = ff_h265_guess_level(ptl, bit_rate, width, height,
- 0, tile_cols, tile_rows,
+ 0, tile_rows, tile_cols,
max_dec_pic_buffering);
if (desc) {
av_log(bsf, AV_LOG_DEBUG, "Stream appears to conform to "
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/yuv4mpegenc.c adjust numerator and denominator
Signed-off-by: darling.zhong --- libavformat/yuv4mpegenc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) mode change 100644 => 100755 libavformat/yuv4mpegenc.c diff --git a/libavformat/yuv4mpegenc.c b/libavformat/yuv4mpegenc.c old mode 100644 new mode 100755 index e84dbf9568..e3c5b5dd5d --- a/libavformat/yuv4mpegenc.c +++ b/libavformat/yuv4mpegenc.c @@ -42,8 +42,8 @@ static int yuv4_generate_header(AVFormatContext *s, char* buf) field_order = st->codecpar->field_order; // TODO: should be avg_frame_rate -av_reduce(, , st->time_base.den, - st->time_base.num, (1UL << 31) - 1); +av_reduce(, , st->time_base.num, + st->time_base.den, (1UL << 31) - 1); aspectn = st->sample_aspect_ratio.num; aspectd = st->sample_aspect_ratio.den; -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_dnn_processing: correct duplicate statement
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> leozhang
> Sent: Friday, November 08, 2019 11:55 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH] avfilter/vf_dnn_processing: correct duplicate
> statement
>
> Signed-off-by: leozhang
> ---
> libavfilter/vf_dnn_processing.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/vf_dnn_processing.c b/libavfilter/vf_dnn_processing.c
> index 87ad354..e119f4d 100644
> --- a/libavfilter/vf_dnn_processing.c
> +++ b/libavfilter/vf_dnn_processing.c
> @@ -204,7 +204,7 @@ static int config_output(AVFilterLink *outlink)
> static int copy_from_frame_to_dnn(DNNData *dnn_data, const AVFrame *in)
> {
> // extend this function to support more formats
> -av_assert0(in->format == AV_PIX_FMT_RGB24 || in->format ==
> AV_PIX_FMT_RGB24);
> +av_assert0(in->format == AV_PIX_FMT_RGB24 || in->format ==
> AV_PIX_FMT_BGR24);
>
> if (dnn_data->dt == DNN_FLOAT) {
> float *dnn_input = dnn_data->data;
> @@ -233,7 +233,7 @@ static int copy_from_frame_to_dnn(DNNData
> *dnn_data, const AVFrame *in)
> static int copy_from_dnn_to_frame(AVFrame *out, const DNNData
> *dnn_data)
> {
> // extend this function to support more formats
> -av_assert0(out->format == AV_PIX_FMT_RGB24 || out->format ==
> AV_PIX_FMT_RGB24);
> +av_assert0(out->format == AV_PIX_FMT_RGB24 || out->format ==
> AV_PIX_FMT_BGR24);
>
> if (dnn_data->dt == DNN_FLOAT) {
> float *dnn_output = dnn_data->data;
> --
yes, thanks for the catch.
> 1.8.3.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavf/movenc: Replace dts by pts to calculate duration
From: Mengyang Yuan
In this case, the input video is of dynamic frame rate and we don't want to
duplicate or drop frames, but the output video duration calculated by DTS is
incorrect, I solved it by using PTS.
There are many UGC videos with dynamic frame rates, which are represented by
PTS jumps. After transcoding with ffmpeg -vsync 0 or -vsync 2, the output
video duration becomes longer.By reading the code of x264/encoder/encoder.c,
I found that in order to predict the B frame, x264 needs to ensure that there
are enough reference frames when DTS = 0, so the DTS of these reference frames
will subtract the cache time. However, the cache time includes the part of PTS
jumps, which results in the abnormal small DTS.
Signed-off-by: Mengyang Yuan
---
libavformat/movenc.c | 23 ++-
libavformat/movenc.h | 2 ++
tests/ref/fate/binsub-movtextenc | 2 +-
tests/ref/fate/movenc| 20 ++--
tests/ref/lavf/mov | 4 ++--
tests/ref/lavf/mp4 | 4 ++--
6 files changed, 31 insertions(+), 24 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 715bec1c2f..206aa48d8c 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1015,7 +1015,7 @@ static int get_cluster_duration(MOVTrack *track, int
cluster_idx)
return 0;
if (cluster_idx + 1 == track->entry)
-next_dts = track->track_duration + track->start_dts;
+next_dts = track->end_dts;
else
next_dts = track->cluster[cluster_idx + 1].dts;
@@ -5149,8 +5149,7 @@ static int mov_flush_fragment(AVFormatContext *s, int
force)
mov->mdat_size = 0;
for (i = 0; i < mov->nb_streams; i++) {
if (mov->tracks[i].entry)
-mov->tracks[i].frag_start += mov->tracks[i].start_dts +
- mov->tracks[i].track_duration -
+mov->tracks[i].frag_start += mov->tracks[i].end_dts -
mov->tracks[i].cluster[0].dts;
mov->tracks[i].entry = 0;
mov->tracks[i].end_reliable = 0;
@@ -5208,7 +5207,7 @@ static int mov_flush_fragment(AVFormatContext *s, int
force)
int64_t duration = 0;
if (track->entry)
-duration = track->start_dts + track->track_duration -
+duration = track->end_dts -
track->cluster[0].dts;
if (mov->flags & FF_MOV_FLAG_SEPARATE_MOOF) {
if (!track->mdat_buf)
@@ -5281,7 +5280,7 @@ static int check_pkt(AVFormatContext *s, AVPacket *pkt)
ref = trk->cluster[trk->entry - 1].dts;
} else if ( trk->start_dts != AV_NOPTS_VALUE
&& !trk->frag_discont) {
-ref = trk->start_dts + trk->track_duration;
+ref = trk->end_dts;
} else
ref = pkt->dts; // Skip tests for the first packet
@@ -5494,7 +5493,7 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt)
* of the last packet of the previous fragment based on
track_duration,
* which might not exactly match our dts. Therefore adjust the dts
* of this packet to be what the previous packets duration
implies. */
-trk->cluster[trk->entry].dts = trk->start_dts +
trk->track_duration;
+trk->cluster[trk->entry].dts = trk->end_dts;
/* We also may have written the pts and the corresponding duration
* in sidx/tfrf/tfxd tags; make sure the sidx pts and duration
match up with
* the next fragment. This means the cts of the first sample must
@@ -5546,13 +5545,17 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket
*pkt)
"this case.\n",
pkt->stream_index, pkt->dts);
}
-trk->track_duration = pkt->dts - trk->start_dts + pkt->duration;
-trk->last_sample_is_subtitle_end = 0;
-
if (pkt->pts == AV_NOPTS_VALUE) {
av_log(s, AV_LOG_WARNING, "pts has no value\n");
pkt->pts = pkt->dts;
}
+if (trk->start_pts == AV_NOPTS_VALUE) {
+trk->start_pts = pkt->pts;
+}
+trk->track_duration = FFMAX(pkt->pts - trk->start_pts + pkt->duration,
trk->track_duration);
+trk->end_dts = pkt->dts + pkt->duration;
+trk->last_sample_is_subtitle_end = 0;
+
if (pkt->dts != pkt->pts)
trk->flags |= MOV_TRACK_CTTS;
trk->cluster[trk->entry].cts = pkt->pts - pkt->dts;
@@ -6295,7 +6298,9 @@ static int mov_init(AVFormatContext *s)
* this is updated. */
track->hint_track = -1;
track->start_dts = AV_NOPTS_VALUE;
+track->start_pts = AV_NOPTS_VALUE;
track->start_cts = AV_NOPTS_VALUE;
+track->end_dts= AV_NOPTS_VALUE;
track->end_pts= AV_NOPTS_VALUE;
track->dts_shift = AV_NOPTS_VALUE;
if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
diff --git a/libavformat/movenc.h b/libavformat/movenc.h
[FFmpeg-devel] [PATCH] avformat/utils.c fix mkdir always true
Signed-off-by: darling.zhong
---
libavformat/utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
mode change 100644 => 100755 libavformat/utils.c
diff --git a/libavformat/utils.c b/libavformat/utils.c
old mode 100644
new mode 100755
index 8196442dd1..0917cc81df
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4869,7 +4869,7 @@ int ff_mkdir_p(const char *path)
}
}
-if ((*(pos - 1) != '/') || (*(pos - 1) != '\\')) {
+if ((*(pos - 1) != '/') && (*(pos - 1) != '\\')) {
ret = mkdir(temp, 0755);
}
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavf/movenc: Replace dts by pts to calculate duration
On Fri, Nov 8, 2019 at 10:58 AM manuelyuan wrote: > > I have try to make fate again and it still works, I do not know why it breaks > fate-binsub-movtextenc on your side > My steps are： > 1、./configure > 2、make fate > If I'm wrong, what should I do？ > > > At 2019-11-08 02:21:16, "Michael Niedermayer" wrote: > >On Thu, Nov 07, 2019 at 05:55:18PM +0800, manuelyuan wrote: > >> From: Mengyang Yuan > >> > >> In this case, the input video is of dynamic frame rate and we don't want to > >> duplicate or drop frames, but the output video duration calculated by DTS > >> is > >> incorrect, I solved it by using PTS. > >> There are many UGC videos with dynamic frame rates, which are represented > >> by > >> PTS jumps. After transcoding with ffmpeg -vsync 0 or -vsync 2, the output > >> video duration becomes longer.By reading the code of > >> x264/encoder/encoder.c, > >> I found that in order to predict the B frame, x264 needs to ensure that > >> there > >> are enough reference frames when DTS = 0, so the DTS of these reference > >> frames > >> will subtract the cache time. However, the cache time includes the part of > >> PTS > >> jumps, which results in the abnormal small DTS. > >> > >> Signed-off-by: Mengyang Yuan > >> --- > >> libavformat/movenc.c | 23 ++- > >> libavformat/movenc.h | 2 ++ > >> tests/ref/fate/movenc | 20 ++-- > >> tests/ref/lavf/mov| 4 ++-- > >> tests/ref/lavf/mp4| 4 ++-- > >> 5 files changed, 30 insertions(+), 23 deletions(-) > > > >breaks fate-binsub-movtextenc > >... > > > >[mp4 @ 0x29327c0] Estimating the duration of the last packet in a fragment, > >consider setting the duration field in AVPacket instead. > >size= 1kB time=00:00:05.85 bitrate= 1.3kbits/s speed=6.03e+04x > >video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing > >overhead: 1809.803955% > >make: *** [fate-binsub-movtextenc] Error 1 > > > >[...] > >-- Please try: make fate-binsub-movtextenc, tks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavf/movenc: Replace dts by pts to calculate duration
I have try to make fate again and it still works, I do not know why it breaks fate-binsub-movtextenc on your side My steps are： 1、./configure 2、make fate If I'm wrong, what should I do？ At 2019-11-08 02:21:16, "Michael Niedermayer" wrote: >On Thu, Nov 07, 2019 at 05:55:18PM +0800, manuelyuan wrote: >> From: Mengyang Yuan >> >> In this case, the input video is of dynamic frame rate and we don't want to >> duplicate or drop frames, but the output video duration calculated by DTS is >> incorrect, I solved it by using PTS. >> There are many UGC videos with dynamic frame rates, which are represented by >> PTS jumps. After transcoding with ffmpeg -vsync 0 or -vsync 2, the output >> video duration becomes longer.By reading the code of x264/encoder/encoder.c, >> I found that in order to predict the B frame, x264 needs to ensure that there >> are enough reference frames when DTS = 0, so the DTS of these reference >> frames >> will subtract the cache time. However, the cache time includes the part of >> PTS >> jumps, which results in the abnormal small DTS. >> >> Signed-off-by: Mengyang Yuan >> --- >> libavformat/movenc.c | 23 ++- >> libavformat/movenc.h | 2 ++ >> tests/ref/fate/movenc | 20 ++-- >> tests/ref/lavf/mov| 4 ++-- >> tests/ref/lavf/mp4| 4 ++-- >> 5 files changed, 30 insertions(+), 23 deletions(-) > >breaks fate-binsub-movtextenc >... > >[mp4 @ 0x29327c0] Estimating the duration of the last packet in a fragment, >consider setting the duration field in AVPacket instead. >size= 1kB time=00:00:05.85 bitrate= 1.3kbits/s speed=6.03e+04x >video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing >overhead: 1809.803955% >make: *** [fate-binsub-movtextenc] Error 1 > >[...] >-- >Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > >Any man who breaks a law that conscience tells him is unjust and willingly >accepts the penalty by staying in jail in order to arouse the conscience of >the community on the injustice of the law is at that moment expressing the >very highest respect for law. - Martin Luther King Jr ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V1 1/5] lavf/hls: fix the log context setting in log message
On Sat, Nov 2, 2019 at 10:55 PM Jun Zhao wrote:
>
> From: Jun Zhao
>
> Fix the log context setting in log message
>
> Signed-off-by: Jun Zhao
> ---
> libavformat/hls.c | 14 +++---
> 1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index ac151d5..8ce1ad9 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -476,20 +476,20 @@ static struct rendition *new_rendition(HLSContext *c,
> struct rendition_info *inf
> return NULL;
>
> if (type == AVMEDIA_TYPE_UNKNOWN) {
> -av_log(c, AV_LOG_WARNING, "Can't support the type: %s\n",
> info->type);
> +av_log(c->ctx, AV_LOG_WARNING, "Can't support the type: %s\n",
> info->type);
> return NULL;
> }
>
> /* URI is mandatory for subtitles as per spec */
> if (type == AVMEDIA_TYPE_SUBTITLE && !info->uri[0]) {
> -av_log(c, AV_LOG_ERROR, "The URI tag is REQUIRED for subtitle.\n");
> +av_log(c->ctx, AV_LOG_ERROR, "The URI tag is REQUIRED for
> subtitle.\n");
> return NULL;
> }
>
> /* TODO: handle subtitles (each segment has to parsed separately) */
> if (c->ctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL)
> if (type == AVMEDIA_TYPE_SUBTITLE) {
> -av_log(c, AV_LOG_WARNING, "Can't support the subtitle(uri:
> %s)\n", info->uri);
> +av_log(c->ctx, AV_LOG_WARNING, "Can't support the subtitle(uri:
> %s)\n", info->uri);
> return NULL;
> }
>
> @@ -1067,7 +1067,7 @@ static void handle_id3(AVIOContext *pb, struct playlist
> *pls)
>
> } else {
> if (!pls->id3_changed && id3_has_changed_values(pls, metadata,
> apic)) {
> -avpriv_report_missing_feature(pls->ctx, "Changing ID3 metadata
> in HLS audio elementary stream");
> +avpriv_report_missing_feature(pls->parent, "Changing ID3
> metadata in HLS audio elementary stream");
> pls->id3_changed = 1;
> }
> av_dict_free();
> @@ -1118,7 +1118,7 @@ static void intercept_id3(struct playlist *pls, uint8_t
> *buf,
> int remaining = taglen - tag_got_bytes;
>
> if (taglen > maxsize) {
> -av_log(pls->ctx, AV_LOG_ERROR, "Too large HLS ID3 tag (%d >
> %"PRId64" bytes)\n",
> +av_log(pls->parent, AV_LOG_ERROR, "Too large HLS ID3 tag (%d
> > %"PRId64" bytes)\n",
> taglen, maxsize);
> break;
> }
> @@ -1139,14 +1139,14 @@ static void intercept_id3(struct playlist *pls,
> uint8_t *buf,
> /* strip the intercepted bytes */
> *len -= tag_got_bytes;
> memmove(buf, buf + tag_got_bytes, *len);
> -av_log(pls->ctx, AV_LOG_DEBUG, "Stripped %d HLS ID3 bytes\n",
> tag_got_bytes);
> +av_log(pls->parent, AV_LOG_DEBUG, "Stripped %d HLS ID3 bytes\n",
> tag_got_bytes);
>
> if (remaining > 0) {
> /* read the rest of the tag in */
> if (read_from_url(pls, seg, pls->id3_buf + id3_buf_pos,
> remaining) != remaining)
> break;
> id3_buf_pos += remaining;
> -av_log(pls->ctx, AV_LOG_DEBUG, "Stripped additional %d HLS
> ID3 bytes\n", remaining);
> +av_log(pls->parent, AV_LOG_DEBUG, "Stripped additional %d
> HLS ID3 bytes\n", remaining);
> }
>
> } else {
> --
> 1.7.1
>
Will apply the patchset, talked & agreed by Steven Liu in IM.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/vp9_raw_reorder_bsf.c fix deadcode
Here if (in->data[in->size - 1] & 0) nerver true?
Signed-off-by: darling.zhong
---
libavcodec/vp9_raw_reorder_bsf.c | 2 +-
patcheck.tmp | 0
2 files changed, 1 insertion(+), 1 deletion(-)
mode change 100644 => 100755 libavcodec/vp9_raw_reorder_bsf.c
create mode 100644 patcheck.tmp
diff --git a/libavcodec/vp9_raw_reorder_bsf.c b/libavcodec/vp9_raw_reorder_bsf.c
old mode 100644
new mode 100755
index f19b4c7198..e55a358457
--- a/libavcodec/vp9_raw_reorder_bsf.c
+++ b/libavcodec/vp9_raw_reorder_bsf.c
@@ -292,7 +292,7 @@ static int vp9_raw_reorder_filter(AVBSFContext *bsf,
AVPacket *out)
return err;
}
-if (in->data[in->size - 1] & 0xe0 == 0xc0) {
+if ((in->data[in->size - 1] & 0xe0) == 0xc0) {
av_log(bsf, AV_LOG_ERROR, "Input in superframes is not "
"supported.\n");
av_packet_free();
diff --git a/patcheck.tmp b/patcheck.tmp
new file mode 100644
index 00..e69de29bb2
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1] avfilter/vf_vaguedenoiser: use fabsf() instead of FFABS()
On Fri, Nov 8, 2019 at 10:09 AM Limin Wang wrote:
>
> On Wed, Nov 06, 2019 at 08:10:53PM +0100, Carl Eugen Hoyos wrote:
> > Am Mi., 6. Nov. 2019 um 12:04 Uhr schrieb Limin Wang
> > :
> > >
> > > On Wed, Nov 06, 2019 at 11:11:08AM +0100, Carl Eugen Hoyos wrote:
> > > > Am Mi., 6. Nov. 2019 um 10:31 Uhr schrieb :
> > > > >
> > > > > From: Limin Wang
> > > > >
> > > > > Signed-off-by: Limin Wang
> > > > > ---
> > > > > libavfilter/vf_vaguedenoiser.c | 6 +++---
> > > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/libavfilter/vf_vaguedenoiser.c
> > > > > b/libavfilter/vf_vaguedenoiser.c
> > > > > index a68f7626e6..75a58c363b 100644
> > > > > --- a/libavfilter/vf_vaguedenoiser.c
> > > > > +++ b/libavfilter/vf_vaguedenoiser.c
> > > > > @@ -335,7 +335,7 @@ static void hard_thresholding(float *block, const
> > > > > int width, const int height,
> > > > >
> > > > > for (y = 0; y < height; y++) {
> > > > > for (x = 0; x < width; x++) {
> > > > > -if (FFABS(block[x]) <= threshold)
> > > > > +if (fabsf(block[x]) <= threshold)
> > > > > block[x] *= frac;
> > > > > }
> > > > > block += stride;
> > > > > @@ -359,7 +359,7 @@ static void soft_thresholding(float *block, const
> > > > > int width, const int height, c
> > > > > for (y = 0; y < height; y++) {
> > > > > const int x0 = (y < h) ? w : 0;
> > > > > for (x = x0; x < width; x++) {
> > > > > -const float temp = FFABS(block[x]);
> > > > > +const float temp = fabsf(block[x]);
> > > > > if (temp <= threshold)
> > > > > block[x] *= frac;
> > > > > else
> > > > > @@ -380,7 +380,7 @@ static void qian_thresholding(float *block, const
> > > > > int width, const int height,
> > > > >
> > > > > for (y = 0; y < height; y++) {
> > > > > for (x = 0; x < width; x++) {
> > > > > -const float temp = FFABS(block[x]);
> > > > > +const float temp = fabsf(block[x]);
> > > > > if (temp <= threshold) {
> > > > > block[x] *= frac;
> > > > > } else {
> > > >
> > > > Please add a sentence to the commit message that explains why this
> > > > change is a good idea.
> > >
> > > block is float type, so I think it's better to use fabsf, isn't right?
> >
> > Looking at the definition of FFABS(), I don't think this is correct.
>
> Below is one old commit log to describe about it. What's the result for the
> discussion?
>
>
> commit 8507b98c10d948653375400e2b0a3d4389f74be4
> Author: Ganesh Ajjanagadde
> Date: Mon Oct 12 01:30:22 2015 -0400
>
> avfilter,swresample,swscale: use fabs, fabsf instead of FFABS
>
> It is well known that fabs and fabsf are at least as fast and sometimes
> faster than the FFABS macro, at least on the gcc+glibc combination.
> For instance, see the reference:
> http://patchwork.sourceware.org/patch/6735/.
> This was a patch to glibc in order to remove their usages of a macro.
>
> The reason essentially boils down to fabs using the __builtin_fabs of
> the compiler, while FFABS needs to infer to not use a branch and to
> simply change the sign bit. Usually the inference works, but sometimes
> it does not. This may be easily checked by looking at the asm.
>
> This also has the added benefit of reducing macro usage, which has
> problems with side-effects.
>
> Note that avcodec is not handled here, as it is huge and
> most things there are integer arithmetic anyway.
>
> Tested with FATE.
>
> Reviewed-by: Clément Bœsch
> Signed-off-by: Ganesh Ajjanagadde
>
>
>
> >
Is it has some performance data after change FFABS to fabsf in this filter? As
my personal opinion, if FFABS is not a performance bottleneck in this filter,
keep the old way may be better.
Swresample, swscale are the other thing, they are basic components for
another part
in FFmpeg, so I think we can use the fabsf for potential performance income.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avfilter/Makefile: add missing framesync dependency to bm3d & mix filters
On Thu, Nov 7, 2019 at 3:53 AM Lou Logan wrote: > Signed-off-by: Lou Logan > --- > bm3d > /usr/bin/ld: libavfilter/libavfilter.a(vf_bm3d.o): in function `activate': > vf_bm3d.c:(.text+0x3100): undefined reference to `ff_framesync_activate' > /usr/bin/ld: libavfilter/libavfilter.a(vf_bm3d.o): in function > `process_frame': > vf_bm3d.c:(.text+0x3182): undefined reference to `ff_framesync_get_frame' > /usr/bin/ld: vf_bm3d.c:(.text+0x31ac): undefined reference to > `ff_framesync_get_frame' > /usr/bin/ld: libavfilter/libavfilter.a(vf_bm3d.o): in function > `config_output': > vf_bm3d.c:(.text+0x36fe): undefined reference to `ff_framesync_init' > /usr/bin/ld: vf_bm3d.c:(.text+0x37c1): undefined reference to > `ff_framesync_configure' > /usr/bin/ld: libavfilter/libavfilter.a(vf_bm3d.o): in function `uninit': > vf_bm3d.c:(.text+0x383a): undefined reference to `ff_framesync_uninit' > > mix > /usr/bin/ld: libavfilter/libavfilter.a(vf_mix.o): in function > `process_frame': > vf_mix.c:(.text+0x954): undefined reference to `ff_framesync_get_frame' > /usr/bin/ld: libavfilter/libavfilter.a(vf_mix.o): in function > `config_output': > vf_mix.c:(.text+0xd2c): undefined reference to `ff_framesync_init' > /usr/bin/ld: vf_mix.c:(.text+0xe77): undefined reference to > `ff_framesync_configure' > /usr/bin/ld: libavfilter/libavfilter.a(vf_mix.o): in function `uninit': > vf_mix.c:(.text+0xeba): undefined reference to `ff_framesync_uninit' > /usr/bin/ld: libavfilter/libavfilter.a(vf_mix.o): in function `activate': > vf_mix.c:(.text+0xf8a): undefined reference to `ff_framesync_activate' > --- > libavfilter/Makefile | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libavfilter/Makefile b/libavfilter/Makefile > index 2080eed559..ec2ed4a8e7 100644 > --- a/libavfilter/Makefile > +++ b/libavfilter/Makefile > @@ -169,7 +169,7 @@ OBJS-$(CONFIG_BITPLANENOISE_FILTER) += > vf_bitplanenoise.o > OBJS-$(CONFIG_BLACKDETECT_FILTER)+= vf_blackdetect.o > OBJS-$(CONFIG_BLACKFRAME_FILTER) += vf_blackframe.o > OBJS-$(CONFIG_BLEND_FILTER) += vf_blend.o framesync.o > -OBJS-$(CONFIG_BM3D_FILTER) += vf_bm3d.o > +OBJS-$(CONFIG_BM3D_FILTER) += vf_bm3d.o framesync.o > OBJS-$(CONFIG_BOXBLUR_FILTER)+= vf_boxblur.o boxblur.o > OBJS-$(CONFIG_BOXBLUR_OPENCL_FILTER) += vf_avgblur_opencl.o > opencl.o \ > opencl/avgblur.o boxblur.o > @@ -303,7 +303,7 @@ OBJS-$(CONFIG_MESTIMATE_FILTER) += > vf_mestimate.o motion_estimation > OBJS-$(CONFIG_METADATA_FILTER) += f_metadata.o > OBJS-$(CONFIG_MIDEQUALIZER_FILTER) += vf_midequalizer.o > framesync.o > OBJS-$(CONFIG_MINTERPOLATE_FILTER) += vf_minterpolate.o > motion_estimation.o > -OBJS-$(CONFIG_MIX_FILTER)+= vf_mix.o > +OBJS-$(CONFIG_MIX_FILTER)+= vf_mix.o framesync.o > OBJS-$(CONFIG_MPDECIMATE_FILTER) += vf_mpdecimate.o > OBJS-$(CONFIG_NEGATE_FILTER) += vf_lut.o > OBJS-$(CONFIG_NLMEANS_FILTER)+= vf_nlmeans.o > -- > 2.24.0 > > ___ > > LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1] avfilter/vf_vaguedenoiser: use fabsf() instead of FFABS()
On Wed, Nov 06, 2019 at 08:10:53PM +0100, Carl Eugen Hoyos wrote:
> Am Mi., 6. Nov. 2019 um 12:04 Uhr schrieb Limin Wang :
> >
> > On Wed, Nov 06, 2019 at 11:11:08AM +0100, Carl Eugen Hoyos wrote:
> > > Am Mi., 6. Nov. 2019 um 10:31 Uhr schrieb :
> > > >
> > > > From: Limin Wang
> > > >
> > > > Signed-off-by: Limin Wang
> > > > ---
> > > > libavfilter/vf_vaguedenoiser.c | 6 +++---
> > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/libavfilter/vf_vaguedenoiser.c
> > > > b/libavfilter/vf_vaguedenoiser.c
> > > > index a68f7626e6..75a58c363b 100644
> > > > --- a/libavfilter/vf_vaguedenoiser.c
> > > > +++ b/libavfilter/vf_vaguedenoiser.c
> > > > @@ -335,7 +335,7 @@ static void hard_thresholding(float *block, const
> > > > int width, const int height,
> > > >
> > > > for (y = 0; y < height; y++) {
> > > > for (x = 0; x < width; x++) {
> > > > -if (FFABS(block[x]) <= threshold)
> > > > +if (fabsf(block[x]) <= threshold)
> > > > block[x] *= frac;
> > > > }
> > > > block += stride;
> > > > @@ -359,7 +359,7 @@ static void soft_thresholding(float *block, const
> > > > int width, const int height, c
> > > > for (y = 0; y < height; y++) {
> > > > const int x0 = (y < h) ? w : 0;
> > > > for (x = x0; x < width; x++) {
> > > > -const float temp = FFABS(block[x]);
> > > > +const float temp = fabsf(block[x]);
> > > > if (temp <= threshold)
> > > > block[x] *= frac;
> > > > else
> > > > @@ -380,7 +380,7 @@ static void qian_thresholding(float *block, const
> > > > int width, const int height,
> > > >
> > > > for (y = 0; y < height; y++) {
> > > > for (x = 0; x < width; x++) {
> > > > -const float temp = FFABS(block[x]);
> > > > +const float temp = fabsf(block[x]);
> > > > if (temp <= threshold) {
> > > > block[x] *= frac;
> > > > } else {
> > >
> > > Please add a sentence to the commit message that explains why this
> > > change is a good idea.
> >
> > block is float type, so I think it's better to use fabsf, isn't right?
>
> Looking at the definition of FFABS(), I don't think this is correct.
Below is one old commit log to describe about it. What's the result for the
discussion?
commit 8507b98c10d948653375400e2b0a3d4389f74be4
Author: Ganesh Ajjanagadde
Date: Mon Oct 12 01:30:22 2015 -0400
avfilter,swresample,swscale: use fabs, fabsf instead of FFABS
It is well known that fabs and fabsf are at least as fast and sometimes
faster than the FFABS macro, at least on the gcc+glibc combination.
For instance, see the reference:
http://patchwork.sourceware.org/patch/6735/.
This was a patch to glibc in order to remove their usages of a macro.
The reason essentially boils down to fabs using the __builtin_fabs of
the compiler, while FFABS needs to infer to not use a branch and to
simply change the sign bit. Usually the inference works, but sometimes
it does not. This may be easily checked by looking at the asm.
This also has the added benefit of reducing macro usage, which has
problems with side-effects.
Note that avcodec is not handled here, as it is huge and
most things there are integer arithmetic anyway.
Tested with FATE.
Reviewed-by: Clément Bœsch
Signed-off-by: Ganesh Ajjanagadde
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avformat/mp3dec: Check for occurances of headers within frames during probing
On Thu, Nov 07, 2019 at 10:37:05PM +0100, Hendrik Leppkes wrote:
> On Thu, Nov 7, 2019 at 10:34 PM Michael Niedermayer
> wrote:
> >
> > From: Limin Wang
> >
> > Fixes misdetection of zYLx.wav
> >
> > Co-Author: Michael Niedermayer
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/mp3dec.c | 10 +-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> > index 6848415657..eb40362548 100644
> > --- a/libavformat/mp3dec.c
> > +++ b/libavformat/mp3dec.c
> > @@ -73,7 +73,7 @@ static int mp3_read_probe(const AVProbeData *p)
> > int frames, ret;
> > int framesizes, max_framesizes;
> > uint32_t header;
> > -const uint8_t *buf, *buf0, *buf2, *end;
> > +const uint8_t *buf, *buf0, *buf2, *buf3, *end;
> >
> > buf0 = p->buf;
> > end = p->buf + p->buf_size - sizeof(uint32_t);
> > @@ -88,11 +88,19 @@ static int mp3_read_probe(const AVProbeData *p)
> > buf2 = buf;
> > for(framesizes = frames = 0; buf2 < end; frames++) {
> > MPADecodeHeader h;
> > +int header_emu = 0;
> >
> > header = AV_RB32(buf2);
> > ret = avpriv_mpegaudio_decode_header(, header);
> > if (ret != 0 || end - buf2 < h.frame_size)
> > break;
> > +
> > +for (buf3 = buf2 + 4; buf3 < buf2 + h.frame_size; buf3++) {
> > +uint32_t next_sync = AV_RB32(buf3);
> > +header_emu += (next_sync & MP3_MASK) == (header &
> > MP3_MASK);
> > +}
> > +if (header_emu > 2)
> > +break;
> > buf2 += h.frame_size;
> > framesizes += h.frame_size;
> > }
>
> I still have the same question - how possible is it that the actual
> audio data actually has these same bits? Is it actually impossible? Or
> are we just trading detection flaws here?
By the iso 11172-3 and 13818-3 specs, every mp3 audio frame has a header, below
is the header bitstream
syntax:
header()
{
syncword 12bits bslsf
id 1bitbslsf
layer 2bitbslsf
protection_bit 1bit bslsf
bitrate_index 4bits bslsf
sampling_frequency 2bits bslsf
padding_bit 1bit bslsf
private_bit 1bit bslsf
mode 2bits bslsf
mode_extension 2bits bslsf
copyright 1bit bslsf
original/home 1bit bslsf
emphasis 2bits bslsf
}
so if the header is masking with MP3_MASK(0xFFFE0CCF), it'll zero out these
field:
protection_bit set to 0
bitrate_index set to 0
sampling_freqency set to 0
mode set to 0
So the header should be keep same pattern if the audio frame is encode with
same id and layer. If not, it's
error or something else.
>
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/mlvdec:drop unnecessary check before ff_format_io_close
On Fri, Nov 8, 2019 at 6:50 AM Steven Liu wrote: > Signed-off-by: Steven Liu > --- > libavformat/mlvdec.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/libavformat/mlvdec.c b/libavformat/mlvdec.c > index 68ca2c5e1c..3b4cb6befd 100644 > --- a/libavformat/mlvdec.c > +++ b/libavformat/mlvdec.c > @@ -462,7 +462,6 @@ static int read_close(AVFormatContext *s) > MlvContext *mlv = s->priv_data; > int i; > for (i = 0; i < 100; i++) > -if (mlv->pb[i]) > ff_format_io_close(s, >pb[i]); > return 0; > } > -- > 2.15.1 > > LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/mlvdec:drop unnecessary check before ff_format_io_close
> -Original Message- > From: ffmpeg-devel On Behalf Of > Steven Liu > Sent: Friday, November 8, 2019 06:50 > To: ffmpeg-devel@ffmpeg.org > Cc: Steven Liu > Subject: [FFmpeg-devel] [PATCH] avformat/mlvdec:drop unnecessary check > before ff_format_io_close > > Signed-off-by: Steven Liu > --- > libavformat/mlvdec.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/libavformat/mlvdec.c b/libavformat/mlvdec.c > index 68ca2c5e1c..3b4cb6befd 100644 > --- a/libavformat/mlvdec.c > +++ b/libavformat/mlvdec.c > @@ -462,7 +462,6 @@ static int read_close(AVFormatContext *s) > MlvContext *mlv = s->priv_data; > int i; > for (i = 0; i < 100; i++) > -if (mlv->pb[i]) > ff_format_io_close(s, >pb[i]); > return 0; > } Missing indentation fixing? - linjie ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/mlvdec:drop unnecessary check before ff_format_io_close
Signed-off-by: Steven Liu --- libavformat/mlvdec.c | 1 - 1 file changed, 1 deletion(-) diff --git a/libavformat/mlvdec.c b/libavformat/mlvdec.c index 68ca2c5e1c..3b4cb6befd 100644 --- a/libavformat/mlvdec.c +++ b/libavformat/mlvdec.c @@ -462,7 +462,6 @@ static int read_close(AVFormatContext *s) MlvContext *mlv = s->priv_data; int i; for (i = 0; i < 100; i++) -if (mlv->pb[i]) ff_format_io_close(s, >pb[i]); return 0; } -- 2.15.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: add the missing vp9 file
On Wed, 6 Nov 2019 at 16:31, Fu, Linjie wrote:
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Dennis Mungai
> > Sent: Wednesday, November 6, 2019 20:36
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Cc: Zhong Li
> > Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: add the missing vp9 file
> >
> > On Tue, 5 Nov 2019 at 12:22, Fu, Linjie wrote:
> > >
> > > > -Original Message-
> > > > From: ffmpeg-devel On Behalf Of
> > > > Dennis Mungai
> > > > Sent: Tuesday, November 5, 2019 13:04
> > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org>
> > > > Cc: Zhong Li
> > > > Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: add the missing vp9
> > file
> > > >
> > > > On Mon, 4 Nov 2019 at 10:12, Zhong Li wrote:
> > > > >
> > > > > It is missed in commit 3358380
> > > > >
> > > > > Signed-off-by: Zhong Li
> > > > > ---
> > > > > libavcodec/qsvenc_vp9.c | 113
> > > >
> > > > > 1 file changed, 113 insertions(+)
> > > > > create mode 100644 libavcodec/qsvenc_vp9.c
> > > > >
> > > > > diff --git a/libavcodec/qsvenc_vp9.c b/libavcodec/qsvenc_vp9.c
> > > > > new file mode 100644
> > > > > index 000..9402f80
> > > > > --- /dev/null
> > > > > +++ b/libavcodec/qsvenc_vp9.c
> > > > > @@ -0,0 +1,113 @@
> > > > > +/*
> > > > > + * Intel MediaSDK QSV based VP9 encoder
> > > > > + *
> > > > > + * 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
> > > > > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> > > > > 02110-
> > 1301
> > > > USA
> > > > > + */
> > > > > +
> > > > > +
> > > > > +#include
> > > > > +#include
> > > > > +
> > > > > +#include
> > > > > +
> > > > > +#include "libavutil/common.h"
> > > > > +#include "libavutil/opt.h"
> > > > > +
> > > > > +#include "avcodec.h"
> > > > > +#include "internal.h"
> > > > > +#include "qsv.h"
> > > > > +#include "qsv_internal.h"
> > > > > +#include "qsvenc.h"
> > > > > +
> > > > > +typedef struct QSVVP9EncContext {
> > > > > +AVClass *class;
> > > > > +QSVEncContext qsv;
> > > > > +} QSVVP9EncContext;
> > > > > +
> > > > > +static av_cold int qsv_enc_init(AVCodecContext *avctx)
> > > > > +{
> > > > > +QSVVP9EncContext *q = avctx->priv_data;
> > > > > +q->qsv.low_power = 1;
> > > > > +
> > > > > +return ff_qsv_enc_init(avctx, >qsv);
> > > > > +}
> > > > > +
> > > > > +static int qsv_enc_frame(AVCodecContext *avctx, AVPacket *pkt,
> > > > > + const AVFrame *frame, int *got_packet)
> > > > > +{
> > > > > +QSVVP9EncContext *q = avctx->priv_data;
> > > > > +
> > > > > +return ff_qsv_encode(avctx, >qsv, pkt, frame, got_packet);
> > > > > +}
> > > > > +
> > > > > +static av_cold int qsv_enc_close(AVCodecContext *avctx)
> > > > > +{
> > > > > +QSVVP9EncContext *q = avctx->priv_data;
> > > > > +
> > > > > +return ff_qsv_enc_close(avctx, >qsv);
> > > > > +}
> > > > > +
> > > > > +#define OFFSET(x) offsetof(QSVVP9EncContext, x)
> > > > > +#define VE AV_OPT_FLAG_VIDEO_PARAM |
> > > > AV_OPT_FLAG_ENCODING_PARAM
> > > > > +static const AVOption options[] = {
> > > > > +QSV_COMMON_OPTS
> > > > > +
> > > > > +{ "profile", NULL, OFFSET(qsv.profile), AV_OPT_TYPE_INT, {
> > > > > .i64 =
> > > > MFX_PROFILE_UNKNOWN }, 0, INT_MAX, VE, "profile" },
> > > > > +{ "unknown", NULL, 0, AV_OPT_TYPE_CONST, {
> > > > > .i64 =
> > > > MFX_PROFILE_UNKNOWN}, INT_MIN, INT_MAX, VE, "profile" },
> > > > > +{ "profile0", NULL, 0, AV_OPT_TYPE_CONST, {
> > > > > .i64 =
> > > > MFX_PROFILE_VP9_0 }, INT_MIN, INT_MAX, VE, "profile" },
> > > > > +{ "profile1", NULL, 0, AV_OPT_TYPE_CONST, {
> > > > > .i64 =
> > > > MFX_PROFILE_VP9_1 }, INT_MIN, INT_MAX, VE, "profile" },
> > > > > +{ "profile2", NULL, 0, AV_OPT_TYPE_CONST, {
> > > > > .i64 =
> > > > MFX_PROFILE_VP9_2 }, INT_MIN, INT_MAX, VE, "profile" },
> > > > > +{ "profile3", NULL, 0, AV_OPT_TYPE_CONST, {
> > > > > .i64 =
> > > > MFX_PROFILE_VP9_3 }, INT_MIN, INT_MAX, VE, "profile" },
> > > > > +
> > > > > +
Re: [FFmpeg-devel] [PATCH 2/2] avformat/mp3dec: Check for occurances of headers within frames during probing
On Thu, Nov 7, 2019 at 10:34 PM Michael Niedermayer
wrote:
>
> From: Limin Wang
>
> Fixes misdetection of zYLx.wav
>
> Co-Author: Michael Niedermayer
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mp3dec.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> index 6848415657..eb40362548 100644
> --- a/libavformat/mp3dec.c
> +++ b/libavformat/mp3dec.c
> @@ -73,7 +73,7 @@ static int mp3_read_probe(const AVProbeData *p)
> int frames, ret;
> int framesizes, max_framesizes;
> uint32_t header;
> -const uint8_t *buf, *buf0, *buf2, *end;
> +const uint8_t *buf, *buf0, *buf2, *buf3, *end;
>
> buf0 = p->buf;
> end = p->buf + p->buf_size - sizeof(uint32_t);
> @@ -88,11 +88,19 @@ static int mp3_read_probe(const AVProbeData *p)
> buf2 = buf;
> for(framesizes = frames = 0; buf2 < end; frames++) {
> MPADecodeHeader h;
> +int header_emu = 0;
>
> header = AV_RB32(buf2);
> ret = avpriv_mpegaudio_decode_header(, header);
> if (ret != 0 || end - buf2 < h.frame_size)
> break;
> +
> +for (buf3 = buf2 + 4; buf3 < buf2 + h.frame_size; buf3++) {
> +uint32_t next_sync = AV_RB32(buf3);
> +header_emu += (next_sync & MP3_MASK) == (header & MP3_MASK);
> +}
> +if (header_emu > 2)
> +break;
> buf2 += h.frame_size;
> framesizes += h.frame_size;
> }
I still have the same question - how possible is it that the actual
audio data actually has these same bits? Is it actually impossible? Or
are we just trading detection flaws here?
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] avformat/rtpdec_rfc4175: support non-zero based line numbers
On Thu, Nov 07, 2019 at 10:27:31PM +0800, Kah Goh wrote:
> On Mon, Sep 30, 2019 at 09:27:20PM +0800, Kah Goh wrote:
> > There are differing standards that define different starting line
> > numbers. For example, VSF TR-03 says the line numbers starts at 1,
> > whereas SMPTE 2110-20 says it should start at 0.
> >
> > This change adds support for non-zero based line numbers and addresses
> > the following issues when it starts at 1:
> > - The first scan line was being incorrectly interpreted as the second
> > scan line. This means the first line in the frame was never being
> > populated.
> > - The last packet for the video frame would be treated as invalid
> > because it would have been copied outside of the frame. Consequently,
> > the packet would never be "finalized" and the next packet triggers a
> > missed RTP marker ("Missed previous RTP marker" would keep being
> > logged).
> >
> > VSF TR-03:
> > http://www.videoservicesforum.org/download/technical_recommendations/VSF_TR-03_2015-11-12.pdf
> >
> > Co-Authored-By: Jacob Siddall
> > Co-Authored-By: Kah Goh
> > Signed-off-by: Kah Goh
> > ---
> > libavformat/rtpdec_rfc4175.c | 49 +---
> > 1 file changed, 45 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavformat/rtpdec_rfc4175.c b/libavformat/rtpdec_rfc4175.c
> > index e9c62c1389..47d5d23dd6 100644
> > --- a/libavformat/rtpdec_rfc4175.c
> > +++ b/libavformat/rtpdec_rfc4175.c
> > @@ -25,6 +25,7 @@
> > #include "rtpdec_formats.h"
> > #include "libavutil/avstring.h"
> > #include "libavutil/pixdesc.h"
> > +#include
> >
> > struct PayloadContext {
> > char *sampling;
> > @@ -37,6 +38,12 @@ struct PayloadContext {
> > unsigned int pgroup; /* size of the pixel group in bytes */
> > unsigned int xinc;
> >
> > +/* The line number of the first line in the frame (usually either 0 or
> > 1). */
> > +int first_line_number;
> > +
> > +/* This is set to true once the first line number is confirmed. */
> > +bool first_line_number_known;
> > +
> > uint32_t timestamp;
> > };
> >
> > @@ -136,6 +143,13 @@ static int rfc4175_finalize_packet(PayloadContext
> > *data, AVPacket *pkt,
> > return ret;
> > }
> >
> > +static int rfc4175_initialize(AVFormatContext *s, int st_index,
> > PayloadContext *data)
> > +{
> > +data->first_line_number = 0;
> > +data->first_line_number_known = false;
> > +return 0;
> > +}
> > +
> > static int rfc4175_handle_packet(AVFormatContext *ctx, PayloadContext
> > *data,
> > AVStream *st, AVPacket *pkt, uint32_t
> > *timestamp,
> > const uint8_t * buf, int len,
> > @@ -188,7 +202,7 @@ static int rfc4175_handle_packet(AVFormatContext *ctx,
> > PayloadContext *data,
> >
> > /* and now iterate over every scan lines */
> > do {
> > -int copy_offset;
> > +int copy_offset, copy_to_line;
> >
> > if (payload_len < data->pgroup)
> > return AVERROR_INVALIDDATA;
> > @@ -199,17 +213,34 @@ static int rfc4175_handle_packet(AVFormatContext
> > *ctx, PayloadContext *data,
> > cont = headers[4] & 0x80;
> > headers += 6;
> >
> > +if (line == 0) {
> > +data->first_line_number = 0;
> > +data->first_line_number_known = true;
> > +}
> > +
> > if (length % data->pgroup)
> > return AVERROR_INVALIDDATA;
> >
> > if (length > payload_len)
> > length = payload_len;
> >
> > -/* prevent ill-formed packets to write after buffer's end */
> > -copy_offset = (line * data->width + offset) * data->pgroup /
> > data->xinc;
> > -if (copy_offset + length > data->frame_size)
> > +copy_to_line = line - data->first_line_number;
> > +if (copy_to_line < 0)
> > +/* This means the first line number we have calculated is too
> > large, which indicates that we
> > +may have received some bad data. */
> > return AVERROR_INVALIDDATA;
> >
> > +/* prevent ill-formed packets to write after buffer's end */
> > +copy_offset = (copy_to_line * data->width + offset) * data->pgroup
> > / data->xinc;
> > +if (copy_offset + length > data->frame_size) {
> > +if (data->first_line_number_known)
> > +return AVERROR_INVALIDDATA;
> > +
> > +// This would happen if the line numbering is 1 based. We
> > still need to check for the RTP flag
> > +// marker (as per after the while loop).
> > +break;
> > +}
> > +
> > dest = data->frame + copy_offset;
> > memcpy(dest, payload, length);
> >
> > @@ -218,6 +249,15 @@ static int rfc4175_handle_packet(AVFormatContext *ctx,
> > PayloadContext *data,
> > } while (cont);
> >
> > if ((flags & RTP_FLAG_MARKER)) {
> > +if (!data->first_line_number_known) {
> > +
[FFmpeg-devel] [PATCH 1/2] avformat/mp3dec: Check that the frame fits within the probe buffer
Signed-off-by: Michael Niedermayer --- libavformat/mp3dec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c index 258f19174b..6848415657 100644 --- a/libavformat/mp3dec.c +++ b/libavformat/mp3dec.c @@ -91,7 +91,7 @@ static int mp3_read_probe(const AVProbeData *p) header = AV_RB32(buf2); ret = avpriv_mpegaudio_decode_header(, header); -if (ret != 0) +if (ret != 0 || end - buf2 < h.frame_size) break; buf2 += h.frame_size; framesizes += h.frame_size; -- 2.23.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] avformat/mp3dec: Check for occurances of headers within frames during probing
From: Limin Wang
Fixes misdetection of zYLx.wav
Co-Author: Michael Niedermayer
Signed-off-by: Michael Niedermayer
---
libavformat/mp3dec.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index 6848415657..eb40362548 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -73,7 +73,7 @@ static int mp3_read_probe(const AVProbeData *p)
int frames, ret;
int framesizes, max_framesizes;
uint32_t header;
-const uint8_t *buf, *buf0, *buf2, *end;
+const uint8_t *buf, *buf0, *buf2, *buf3, *end;
buf0 = p->buf;
end = p->buf + p->buf_size - sizeof(uint32_t);
@@ -88,11 +88,19 @@ static int mp3_read_probe(const AVProbeData *p)
buf2 = buf;
for(framesizes = frames = 0; buf2 < end; frames++) {
MPADecodeHeader h;
+int header_emu = 0;
header = AV_RB32(buf2);
ret = avpriv_mpegaudio_decode_header(, header);
if (ret != 0 || end - buf2 < h.frame_size)
break;
+
+for (buf3 = buf2 + 4; buf3 < buf2 + h.frame_size; buf3++) {
+uint32_t next_sync = AV_RB32(buf3);
+header_emu += (next_sync & MP3_MASK) == (header & MP3_MASK);
+}
+if (header_emu > 2)
+break;
buf2 += h.frame_size;
framesizes += h.frame_size;
}
--
2.23.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4] avformat/mp3dec: Fixes misdetection of zYLx.wav
On Fri, Nov 08, 2019 at 12:16:22AM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> By Hendrik comments, I have proposal a more general fix for
> more common case.
> Now It's only tested with fate and all samples in:
> http://samples.ffmpeg.org/A-codecs/MP3-pro
> http://samples.ffmpeg.org/A-codecs/MP3
>
> libavformat/mp3dec.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> index 258f191..551aa56 100644
> --- a/libavformat/mp3dec.c
> +++ b/libavformat/mp3dec.c
> @@ -73,7 +73,8 @@ static int mp3_read_probe(const AVProbeData *p)
> int frames, ret;
> int framesizes, max_framesizes;
> uint32_t header;
> -const uint8_t *buf, *buf0, *buf2, *end;
> +uint32_t next_sync;
> +const uint8_t *buf, *buf0, *buf2, *buf3, *end;
>
> buf0 = p->buf;
> end = p->buf + p->buf_size - sizeof(uint32_t);
> @@ -93,6 +94,16 @@ static int mp3_read_probe(const AVProbeData *p)
> ret = avpriv_mpegaudio_decode_header(, header);
> if (ret != 0)
> break;
> +
> +buf3 = buf2 + 4;
> +while (buf3 < end) {
> +next_sync = AV_RB32(buf3);
> +if ((next_sync & MP3_MASK) == (header & MP3_MASK))
> +break;
> +buf3++;
> +}
> +if (buf3 - buf2 != h.frame_size)
> +break;
iam not sure if a single occurance of the header should trigger rejection
of the frame, the failing sample has hundreads
ill post a modified version of this in a moment which is a bit simpler
and counts these cases
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Whats the most studid thing your enemy could do ? Blow himself up
Whats the most studid thing you could do ? Give up your rights and
freedom because your enemy blew himself up.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V3] avfilter/vf_dnn_processing: add a generic filter for image proccessing with dnn networks
Em qui., 7 de nov. de 2019 às 13:17, Guo, Yejun
escreveu:
>
> > > From: Pedro Arthur [mailto:bygran...@gmail.com]
> > > Sent: Thursday, November 07, 2019 1:18 AM
> > > To: FFmpeg development discussions and patches
> >
> > > Cc: Guo, Yejun
> > > Subject: Re: [FFmpeg-devel] [PATCH V3] avfilter/vf_dnn_processing: add
> a
> > > generic filter for image proccessing with dnn networks
> > >
> > > Hi,
> > >
> > > Em qui., 31 de out. de 2019 às 05:39, Guo, Yejun
> > > escreveu:
> > > This filter accepts all the dnn networks which do image processing.
> > > Currently, frame with formats rgb24 and bgr24 are supported. Other
> > > formats such as gray and YUV will be supported next. The dnn network
> > > can accept data in float32 or uint8 format. And the dnn network can
> > > change frame size.
> > >
> > > The following is a python script to halve the value of the first
> > > channel of the pixel. It demos how to setup and execute dnn model
> > > with python+tensorflow. It also generates .pb file which will be
> > > used by ffmpeg.
> > >
> > > import tensorflow as tf
> > > import numpy as np
> > > import scipy.misc
> > > in_img = scipy.misc.imread('in.bmp')
> > > in_img = in_img.astype(np.float32)/255.0
> > > in_data = in_img[np.newaxis, :]
> > > filter_data = np.array([0.5, 0, 0, 0, 1., 0, 0, 0,
> > > 1.]).reshape(1,1,3,3).astype(np.float32)
> > > filter = tf.Variable(filter_data)
> > > x = tf.placeholder(tf.float32, shape=[1, None, None, 3], name='dnn_in')
> > > y = tf.nn.conv2d(x, filter, strides=[1, 1, 1, 1], padding='VALID',
> > name='dnn_out')
> > > sess=tf.Session()
> > > sess.run(tf.global_variables_initializer())
> > > output = sess.run(y, feed_dict={x: in_data})
> > > graph_def = tf.graph_util.convert_variables_to_constants(sess,
> > > sess.graph_def, ['dnn_out'])
> > > tf.train.write_graph(graph_def, '.', 'halve_first_channel.pb',
> as_text=False)
> > > output = output * 255.0
> > > output = output.astype(np.uint8)
> > > scipy.misc.imsave("out.bmp", np.squeeze(output))
> > >
> > > To do the same thing with ffmpeg:
> > > - generate halve_first_channel.pb with the above script
> > > - generate halve_first_channel.model with tools/python/convert.py
> > > - try with following commands
> > > ./ffmpeg -i input.jpg -vf
> > >
> > dnn_processing=model=halve_first_channel.model:input=dnn_in:output=dnn_
> > > out:fmt=rgb24:dnn_backend=native -y out.native.png
> > > ./ffmpeg -i input.jpg -vf
> > >
> > dnn_processing=model=halve_first_channel.pb:input=dnn_in:output=dnn_out:f
> > > mt=rgb24:dnn_backend=tensorflow -y out.tf.png
> > It would be great if you could transform the above steps in a fate test,
> that
> > way one can automatically ensure the filter is always working properly.
>
> sure, I'll add a fate test to test this filter with
> halve_first_channel.model. There will
> be no test for tensorflow part since the fate test requires no external
> dependency.
>
> furthermore, more industry-famous models can be added into this fate test
> after we support them by
> adding more layers into native mode, and after we optimize the conv2d
> layer which is now
> very very very very slow.
>
> > > +};
> > > +
> > > +AVFilter ff_vf_dnn_processing = {
> > > +.name = "dnn_processing",
> > > +.description = NULL_IF_CONFIG_SMALL("Apply DNN processing
> > filter
> > > to the input."),
> > > +.priv_size = sizeof(DnnProcessingContext),
> > > +.init = init,
> > > +.uninit= uninit,
> > > +.query_formats = query_formats,
> > > +.inputs= dnn_processing_inputs,
> > > +.outputs = dnn_processing_outputs,
> > > +.priv_class= _processing_class,
> > > +};
> > > --
> > > 2.7.4
> > rest LGTM.
>
> thanks, could we first push this patch?
>
patch pushed, thanks.
I slight edited the commit message, changed "scipy.misc" to "imageio" as
the former is deprecated and not present in newer versions.
> I plan to add two more changes for this filter next:
> - add gray8 and gray32 support
> - add y_from_yuv support, in other words, the network only handles the Y
> channel,
> and uv parts are not changed (or just scaled), just like what vf_sr does.
>
> I currently do not have plan to add specific yuv formats, since I do not
> see a famous
> network which handles all the y u v channels.
>
>
> > BTW do you have already concrete use cases (or plans) for this filter?
>
> not yet, the idea of this filter is that it is general for image
> processing and should be very useful,
> and my basic target is to at least cover the features provided by vf_sr
> and vf_derain
>
> actually, I do have a use case plan for a general video analytic filter,
> the side data type might be
> a big challenge, I'm still thinking about it. I choose this image
> processing filter first because
> it is simpler and community can be familiar with dnn based filters step by
> step.
>
> > >
> > >
> > > ___
> > > ffmpeg-devel mailing list
> > >
Re: [FFmpeg-devel] [PATCH] lavf/movenc: Replace dts by pts to calculate duration
On Thu, Nov 07, 2019 at 05:55:18PM +0800, manuelyuan wrote: > From: Mengyang Yuan > > In this case, the input video is of dynamic frame rate and we don't want to > duplicate or drop frames, but the output video duration calculated by DTS is > incorrect, I solved it by using PTS. > There are many UGC videos with dynamic frame rates, which are represented by > PTS jumps. After transcoding with ffmpeg -vsync 0 or -vsync 2, the output > video duration becomes longer.By reading the code of x264/encoder/encoder.c, > I found that in order to predict the B frame, x264 needs to ensure that there > are enough reference frames when DTS = 0, so the DTS of these reference frames > will subtract the cache time. However, the cache time includes the part of PTS > jumps, which results in the abnormal small DTS. > > Signed-off-by: Mengyang Yuan > --- > libavformat/movenc.c | 23 ++- > libavformat/movenc.h | 2 ++ > tests/ref/fate/movenc | 20 ++-- > tests/ref/lavf/mov| 4 ++-- > tests/ref/lavf/mp4| 4 ++-- > 5 files changed, 30 insertions(+), 23 deletions(-) breaks fate-binsub-movtextenc ... [mp4 @ 0x29327c0] Estimating the duration of the last packet in a fragment, consider setting the duration field in AVPacket instead. size= 1kB time=00:00:05.85 bitrate= 1.3kbits/s speed=6.03e+04x video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1809.803955% make: *** [fate-binsub-movtextenc] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Any man who breaks a law that conscience tells him is unjust and willingly accepts the penalty by staying in jail in order to arouse the conscience of the community on the injustice of the law is at that moment expressing the very highest respect for law. - Martin Luther King Jr signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/8] avformat/mxfdec: cleanup on "essence prior to first PartitionPack"
On Wed, Nov 06, 2019 at 09:38:01PM +0100, Tomas Härdin wrote:
> tor 2019-10-31 klockan 18:58 +0100 skrev Michael Niedermayer:
> > Fixes: memleak
> > Fixes: 18473/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-
> > 5738557074833408
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/mxfdec.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index 397f820b3f..f3b1b704f9 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -3199,7 +3199,8 @@ static int mxf_read_header(AVFormatContext *s)
> >
> > if (!mxf->current_partition) {
> > av_log(mxf->fc, AV_LOG_ERROR, "found essence prior
> > to first PartitionPack\n");
> > -return AVERROR_INVALIDDATA;
> > +ret = AVERROR_INVALIDDATA;
> > +goto fail;
>
> Should be OK. I'd add a comment around mxf_read_sync() why we don't
> goto fail there (since no metadata sets will have been parsed yet)
will add and apply
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
"I am not trying to be anyone's saviour, I'm trying to think about the
future and not be sad" - Elon Musk
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/8] avformat/mxfdec: Clear metadata_sets_count in mxf_read_close()
On Wed, Nov 06, 2019 at 09:34:01PM +0100, Tomas Härdin wrote:
> tor 2019-10-31 klockan 18:58 +0100 skrev Michael Niedermayer:
> > This avoids problems if the function is called twice
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/mxfdec.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index f3b1b704f9..68a670154b 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -3582,6 +3582,7 @@ static int mxf_read_close(AVFormatContext *s)
> > for (i = 0; i < mxf->metadata_sets_count; i++) {
> > mxf_free_metadataset(mxf->metadata_sets + i, 1);
> > }
> > +mxf->metadata_sets_count = 0;
> > av_freep(>partitions);
> > av_freep(>metadata_sets);
> > av_freep(>aesc);
>
> Looks OK, but I'd work out why close() is called twice
I dont think i saw a case where it was called twice, i just felt
that its more robust to clear this
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Elect your leaders based on what they did after the last election, not
based on what they say before an election.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] avformat/mp3dec: Fixes misdetection of zYLx.wav
On Thu, Nov 7, 2019 at 3:40 PM Limin Wang wrote: > > On Thu, Nov 07, 2019 at 01:16:32PM +0100, Hendrik Leppkes wrote: > > On Thu, Nov 7, 2019 at 12:38 PM wrote: > > > > > > From: Limin Wang > > > > > > Signed-off-by: Limin Wang > > > --- > > > libavformat/mp3dec.c | 5 + > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c > > > index 258f19174b..f15045dd6f 100644 > > > --- a/libavformat/mp3dec.c > > > +++ b/libavformat/mp3dec.c > > > @@ -73,6 +73,7 @@ static int mp3_read_probe(const AVProbeData *p) > > > int frames, ret; > > > int framesizes, max_framesizes; > > > uint32_t header; > > > +uint32_t next; > > > const uint8_t *buf, *buf0, *buf2, *end; > > > > > > buf0 = p->buf; > > > @@ -93,6 +94,10 @@ static int mp3_read_probe(const AVProbeData *p) > > > ret = avpriv_mpegaudio_decode_header(, header); > > > if (ret != 0) > > > break; > > > +next = AV_RB32(buf2 + 4); > > > +/* detect invalid data after header */ > > > +if ((header & 0xfffe) == (next & 0xfffe)) > > > +break; > > > buf2 += h.frame_size; > > > framesizes += h.frame_size; > > > } > > > > This seems like one check designed to fix exactly one file. Thats > > really not the kind of checks that seem appropriate here. > > I'm not sure you can conclusively proof that the data after the header > > cannot have a certain bit-pattern, since audio data immediately starts > > here. > > 0xffe is the sync word for mp3(0xfffe is sync word for MPEG Version 1 layerI) > if the next sync word is near to the first sync word, that's means no frame > data between them, so we can consider it's invalid header. For the > current sample is such pattern, so I check the kind of case only. > That explanation is not sufficient. What guarantees that the audio data that follows the header cannot actually have this particular pattern? You can't fix every of these cases by such bit-pattern checks. PCM is raw data, it could have any pattern, including a full valid MP3 frame header. A better way to detect this is to check if there is multiple MP3 frames at the correct position in the file, which reduces the likelyness of such a misdetection drastically. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavc/vaapi_encode: Async the encoding and output procedure of encoder
Currently, vaapi encodes a pic if all its references are ready,
and then outputs it immediately by calling vaapi_encode_output.
However, while working on output procedure, hardware is be able to
cope with encoding tasks in the meantime to have the better performance.
So a more efficient way is to send all the pics with available refs to
hardware to allow encoding while output.
It's what vaapi originally did before the regression, and the performance
could be improved for ~20%.
CMD:
ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128
-hwaccel_output_format vaapi -i bbb_sunflower_1080p_30fps_normal.mp4
-c:v h264_vaapi -f h264 -y /dev/null
Source:
https://download.blender.org/demo/movies/BBB/
Before:
~164 fps
After:
~198 fps
Fix #7706.
Signed-off-by: Linjie Fu
---
libavcodec/vaapi_encode.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 3be9159d37..aceb268315 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1109,17 +1109,28 @@ int ff_vaapi_encode_receive_packet(AVCodecContext
*avctx, AVPacket *pkt)
return AVERROR(EAGAIN);
}
+pick_next:
pic = NULL;
err = vaapi_encode_pick_next(avctx, );
-if (err < 0)
-return err;
-av_assert0(pic);
+if (!err) {
+av_assert0(pic);
-pic->encode_order = ctx->encode_order++;
+pic->encode_order = ctx->encode_order++;
-err = vaapi_encode_issue(avctx, pic);
-if (err < 0) {
-av_log(avctx, AV_LOG_ERROR, "Encode failed: %d.\n", err);
+err = vaapi_encode_issue(avctx, pic);
+if (err < 0) {
+av_log(avctx, AV_LOG_ERROR, "Encode failed: %d.\n", err);
+return err;
+}
+goto pick_next;
+} else if (err == AVERROR(EAGAIN)) {
+for (pic = ctx->pic_start; pic; pic = pic->next)
+if (pic->encode_issued && !pic->encode_complete &&
+pic->encode_order == ctx->output_order)
+break;
+if (!pic)
+return err;
+} else {
return err;
}
@@ -1143,7 +1154,7 @@ int ff_vaapi_encode_receive_packet(AVCodecContext *avctx,
AVPacket *pkt)
av_log(avctx, AV_LOG_DEBUG, "Output packet: pts %"PRId64" dts
%"PRId64".\n",
pkt->pts, pkt->dts);
-ctx->output_order = pic->encode_order;
+ctx->output_order++;
vaapi_encode_clear_old(avctx);
return 0;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v4] avformat/mp3dec: Fixes misdetection of zYLx.wav
From: Limin Wang
Signed-off-by: Limin Wang
---
By Hendrik comments, I have proposal a more general fix for
more common case.
Now It's only tested with fate and all samples in:
http://samples.ffmpeg.org/A-codecs/MP3-pro
http://samples.ffmpeg.org/A-codecs/MP3
libavformat/mp3dec.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index 258f191..551aa56 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -73,7 +73,8 @@ static int mp3_read_probe(const AVProbeData *p)
int frames, ret;
int framesizes, max_framesizes;
uint32_t header;
-const uint8_t *buf, *buf0, *buf2, *end;
+uint32_t next_sync;
+const uint8_t *buf, *buf0, *buf2, *buf3, *end;
buf0 = p->buf;
end = p->buf + p->buf_size - sizeof(uint32_t);
@@ -93,6 +94,16 @@ static int mp3_read_probe(const AVProbeData *p)
ret = avpriv_mpegaudio_decode_header(, header);
if (ret != 0)
break;
+
+buf3 = buf2 + 4;
+while (buf3 < end) {
+next_sync = AV_RB32(buf3);
+if ((next_sync & MP3_MASK) == (header & MP3_MASK))
+break;
+buf3++;
+}
+if (buf3 - buf2 != h.frame_size)
+break;
buf2 += h.frame_size;
framesizes += h.frame_size;
}
--
2.6.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V3] avfilter/vf_dnn_processing: add a generic filter for image proccessing with dnn networks
> > From: Pedro Arthur [mailto:bygran...@gmail.com]
> > Sent: Thursday, November 07, 2019 1:18 AM
> > To: FFmpeg development discussions and patches
>
> > Cc: Guo, Yejun
> > Subject: Re: [FFmpeg-devel] [PATCH V3] avfilter/vf_dnn_processing: add a
> > generic filter for image proccessing with dnn networks
> >
> > Hi,
> >
> > Em qui., 31 de out. de 2019 às 05:39, Guo, Yejun
> > escreveu:
> > This filter accepts all the dnn networks which do image processing.
> > Currently, frame with formats rgb24 and bgr24 are supported. Other
> > formats such as gray and YUV will be supported next. The dnn network
> > can accept data in float32 or uint8 format. And the dnn network can
> > change frame size.
> >
> > The following is a python script to halve the value of the first
> > channel of the pixel. It demos how to setup and execute dnn model
> > with python+tensorflow. It also generates .pb file which will be
> > used by ffmpeg.
> >
> > import tensorflow as tf
> > import numpy as np
> > import scipy.misc
> > in_img = scipy.misc.imread('in.bmp')
> > in_img = in_img.astype(np.float32)/255.0
> > in_data = in_img[np.newaxis, :]
> > filter_data = np.array([0.5, 0, 0, 0, 1., 0, 0, 0,
> > 1.]).reshape(1,1,3,3).astype(np.float32)
> > filter = tf.Variable(filter_data)
> > x = tf.placeholder(tf.float32, shape=[1, None, None, 3], name='dnn_in')
> > y = tf.nn.conv2d(x, filter, strides=[1, 1, 1, 1], padding='VALID',
> name='dnn_out')
> > sess=tf.Session()
> > sess.run(tf.global_variables_initializer())
> > output = sess.run(y, feed_dict={x: in_data})
> > graph_def = tf.graph_util.convert_variables_to_constants(sess,
> > sess.graph_def, ['dnn_out'])
> > tf.train.write_graph(graph_def, '.', 'halve_first_channel.pb',
> > as_text=False)
> > output = output * 255.0
> > output = output.astype(np.uint8)
> > scipy.misc.imsave("out.bmp", np.squeeze(output))
> >
> > To do the same thing with ffmpeg:
> > - generate halve_first_channel.pb with the above script
> > - generate halve_first_channel.model with tools/python/convert.py
> > - try with following commands
> > ./ffmpeg -i input.jpg -vf
> >
> dnn_processing=model=halve_first_channel.model:input=dnn_in:output=dnn_
> > out:fmt=rgb24:dnn_backend=native -y out.native.png
> > ./ffmpeg -i input.jpg -vf
> >
> dnn_processing=model=halve_first_channel.pb:input=dnn_in:output=dnn_out:f
> > mt=rgb24:dnn_backend=tensorflow -y out.tf.png
> It would be great if you could transform the above steps in a fate test, that
> way one can automatically ensure the filter is always working properly.
sure, I'll add a fate test to test this filter with halve_first_channel.model.
There will
be no test for tensorflow part since the fate test requires no external
dependency.
furthermore, more industry-famous models can be added into this fate test after
we support them by
adding more layers into native mode, and after we optimize the conv2d layer
which is now
very very very very slow.
> > +};
> > +
> > +AVFilter ff_vf_dnn_processing = {
> > + .name = "dnn_processing",
> > + .description = NULL_IF_CONFIG_SMALL("Apply DNN processing
> filter
> > to the input."),
> > + .priv_size = sizeof(DnnProcessingContext),
> > + .init = init,
> > + .uninit = uninit,
> > + .query_formats = query_formats,
> > + .inputs = dnn_processing_inputs,
> > + .outputs = dnn_processing_outputs,
> > + .priv_class = _processing_class,
> > +};
> > --
> > 2.7.4
> rest LGTM.
thanks, could we first push this patch?
I plan to add two more changes for this filter next:
- add gray8 and gray32 support
- add y_from_yuv support, in other words, the network only handles the Y
channel,
and uv parts are not changed (or just scaled), just like what vf_sr does.
I currently do not have plan to add specific yuv formats, since I do not see a
famous
network which handles all the y u v channels.
> BTW do you have already concrete use cases (or plans) for this filter?
not yet, the idea of this filter is that it is general for image processing and
should be very useful,
and my basic target is to at least cover the features provided by vf_sr and
vf_derain
actually, I do have a use case plan for a general video analytic filter, the
side data type might be
a big challenge, I'm still thinking about it. I choose this image processing
filter first because
it is simpler and community can be familiar with dnn based filters step by step.
> >
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] avformat/mp3dec: Fixes misdetection of zYLx.wav
On Thu, Nov 07, 2019 at 01:16:32PM +0100, Hendrik Leppkes wrote: > On Thu, Nov 7, 2019 at 12:38 PM wrote: > > > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > libavformat/mp3dec.c | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c > > index 258f19174b..f15045dd6f 100644 > > --- a/libavformat/mp3dec.c > > +++ b/libavformat/mp3dec.c > > @@ -73,6 +73,7 @@ static int mp3_read_probe(const AVProbeData *p) > > int frames, ret; > > int framesizes, max_framesizes; > > uint32_t header; > > +uint32_t next; > > const uint8_t *buf, *buf0, *buf2, *end; > > > > buf0 = p->buf; > > @@ -93,6 +94,10 @@ static int mp3_read_probe(const AVProbeData *p) > > ret = avpriv_mpegaudio_decode_header(, header); > > if (ret != 0) > > break; > > +next = AV_RB32(buf2 + 4); > > +/* detect invalid data after header */ > > +if ((header & 0xfffe) == (next & 0xfffe)) > > +break; > > buf2 += h.frame_size; > > framesizes += h.frame_size; > > } > > This seems like one check designed to fix exactly one file. Thats > really not the kind of checks that seem appropriate here. > I'm not sure you can conclusively proof that the data after the header > cannot have a certain bit-pattern, since audio data immediately starts > here. 0xffe is the sync word for mp3(0xfffe is sync word for MPEG Version 1 layerI) if the next sync word is near to the first sync word, that's means no frame data between them, so we can consider it's invalid header. For the current sample is such pattern, so I check the kind of case only. > > - Hendrik > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] avformat/rtpdec_rfc4175: support non-zero based line numbers
On Mon, Sep 30, 2019 at 09:27:20PM +0800, Kah Goh wrote:
> There are differing standards that define different starting line
> numbers. For example, VSF TR-03 says the line numbers starts at 1,
> whereas SMPTE 2110-20 says it should start at 0.
>
> This change adds support for non-zero based line numbers and addresses
> the following issues when it starts at 1:
> - The first scan line was being incorrectly interpreted as the second
> scan line. This means the first line in the frame was never being
> populated.
> - The last packet for the video frame would be treated as invalid
> because it would have been copied outside of the frame. Consequently,
> the packet would never be "finalized" and the next packet triggers a
> missed RTP marker ("Missed previous RTP marker" would keep being
> logged).
>
> VSF TR-03:
> http://www.videoservicesforum.org/download/technical_recommendations/VSF_TR-03_2015-11-12.pdf
>
> Co-Authored-By: Jacob Siddall
> Co-Authored-By: Kah Goh
> Signed-off-by: Kah Goh
> ---
> libavformat/rtpdec_rfc4175.c | 49 +---
> 1 file changed, 45 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/rtpdec_rfc4175.c b/libavformat/rtpdec_rfc4175.c
> index e9c62c1389..47d5d23dd6 100644
> --- a/libavformat/rtpdec_rfc4175.c
> +++ b/libavformat/rtpdec_rfc4175.c
> @@ -25,6 +25,7 @@
> #include "rtpdec_formats.h"
> #include "libavutil/avstring.h"
> #include "libavutil/pixdesc.h"
> +#include
>
> struct PayloadContext {
> char *sampling;
> @@ -37,6 +38,12 @@ struct PayloadContext {
> unsigned int pgroup; /* size of the pixel group in bytes */
> unsigned int xinc;
>
> +/* The line number of the first line in the frame (usually either 0 or
> 1). */
> +int first_line_number;
> +
> +/* This is set to true once the first line number is confirmed. */
> +bool first_line_number_known;
> +
> uint32_t timestamp;
> };
>
> @@ -136,6 +143,13 @@ static int rfc4175_finalize_packet(PayloadContext *data,
> AVPacket *pkt,
> return ret;
> }
>
> +static int rfc4175_initialize(AVFormatContext *s, int st_index,
> PayloadContext *data)
> +{
> +data->first_line_number = 0;
> +data->first_line_number_known = false;
> +return 0;
> +}
> +
> static int rfc4175_handle_packet(AVFormatContext *ctx, PayloadContext *data,
> AVStream *st, AVPacket *pkt, uint32_t
> *timestamp,
> const uint8_t * buf, int len,
> @@ -188,7 +202,7 @@ static int rfc4175_handle_packet(AVFormatContext *ctx,
> PayloadContext *data,
>
> /* and now iterate over every scan lines */
> do {
> -int copy_offset;
> +int copy_offset, copy_to_line;
>
> if (payload_len < data->pgroup)
> return AVERROR_INVALIDDATA;
> @@ -199,17 +213,34 @@ static int rfc4175_handle_packet(AVFormatContext *ctx,
> PayloadContext *data,
> cont = headers[4] & 0x80;
> headers += 6;
>
> +if (line == 0) {
> +data->first_line_number = 0;
> +data->first_line_number_known = true;
> +}
> +
> if (length % data->pgroup)
> return AVERROR_INVALIDDATA;
>
> if (length > payload_len)
> length = payload_len;
>
> -/* prevent ill-formed packets to write after buffer's end */
> -copy_offset = (line * data->width + offset) * data->pgroup /
> data->xinc;
> -if (copy_offset + length > data->frame_size)
> +copy_to_line = line - data->first_line_number;
> +if (copy_to_line < 0)
> +/* This means the first line number we have calculated is too
> large, which indicates that we
> +may have received some bad data. */
> return AVERROR_INVALIDDATA;
>
> +/* prevent ill-formed packets to write after buffer's end */
> +copy_offset = (copy_to_line * data->width + offset) * data->pgroup /
> data->xinc;
> +if (copy_offset + length > data->frame_size) {
> +if (data->first_line_number_known)
> +return AVERROR_INVALIDDATA;
> +
> +// This would happen if the line numbering is 1 based. We still
> need to check for the RTP flag
> +// marker (as per after the while loop).
> +break;
> +}
> +
> dest = data->frame + copy_offset;
> memcpy(dest, payload, length);
>
> @@ -218,6 +249,15 @@ static int rfc4175_handle_packet(AVFormatContext *ctx,
> PayloadContext *data,
> } while (cont);
>
> if ((flags & RTP_FLAG_MARKER)) {
> +if (!data->first_line_number_known) {
> +data->first_line_number = line - data->height + 1;
> +if (data->first_line_number < 0) {
> +// This could happen if the frame does not fill up the
> entire height.
> +data->first_line_number = 0;
> +av_log(ctx, AV_LOG_WARNING, "Video frame does not
[FFmpeg-devel] avformat/mov: add free memory when error
Here may have a mem leak when error
Signed-off-by: darling.zhong
---
libavformat/mov.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
mode change 100644 => 100755 libavformat/mov.c
diff --git a/libavformat/mov.c b/libavformat/mov.c
old mode 100644
new mode 100755
index 4f69664eaf..c2e42ea747
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1327,8 +1327,10 @@ static int update_frag_index(MOVContext *c, int64_t
offset)
for (i = 0; i < c->fc->nb_streams; i++) {
// Avoid building frag index if streams lack track id.
-if (c->fc->streams[i]->id < 0)
+if (c->fc->streams[i]->id < 0) {
+av_free(frag_stream_info);
return AVERROR_INVALIDDATA;
+}
frag_stream_info[i].id = c->fc->streams[i]->id;
frag_stream_info[i].sidx_pts = AV_NOPTS_VALUE;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] avformat/mp3dec: Fixes misdetection of zYLx.wav
On Thu, Nov 7, 2019 at 12:38 PM wrote: > > From: Limin Wang > > Signed-off-by: Limin Wang > --- > libavformat/mp3dec.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c > index 258f19174b..f15045dd6f 100644 > --- a/libavformat/mp3dec.c > +++ b/libavformat/mp3dec.c > @@ -73,6 +73,7 @@ static int mp3_read_probe(const AVProbeData *p) > int frames, ret; > int framesizes, max_framesizes; > uint32_t header; > +uint32_t next; > const uint8_t *buf, *buf0, *buf2, *end; > > buf0 = p->buf; > @@ -93,6 +94,10 @@ static int mp3_read_probe(const AVProbeData *p) > ret = avpriv_mpegaudio_decode_header(, header); > if (ret != 0) > break; > +next = AV_RB32(buf2 + 4); > +/* detect invalid data after header */ > +if ((header & 0xfffe) == (next & 0xfffe)) > +break; > buf2 += h.frame_size; > framesizes += h.frame_size; > } This seems like one check designed to fix exactly one file. Thats really not the kind of checks that seem appropriate here. I'm not sure you can conclusively proof that the data after the header cannot have a certain bit-pattern, since audio data immediately starts here. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3] avformat/mp3dec: Fixes misdetection of zYLx.wav
From: Limin Wang Signed-off-by: Limin Wang --- libavformat/mp3dec.c | 5 + 1 file changed, 5 insertions(+) diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c index 258f19174b..f15045dd6f 100644 --- a/libavformat/mp3dec.c +++ b/libavformat/mp3dec.c @@ -73,6 +73,7 @@ static int mp3_read_probe(const AVProbeData *p) int frames, ret; int framesizes, max_framesizes; uint32_t header; +uint32_t next; const uint8_t *buf, *buf0, *buf2, *end; buf0 = p->buf; @@ -93,6 +94,10 @@ static int mp3_read_probe(const AVProbeData *p) ret = avpriv_mpegaudio_decode_header(, header); if (ret != 0) break; +next = AV_RB32(buf2 + 4); +/* detect invalid data after header */ +if ((header & 0xfffe) == (next & 0xfffe)) +break; buf2 += h.frame_size; framesizes += h.frame_size; } -- 2.21.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3] avformat/utils: Fixes misdetection of zYLx.wav
From: Limin Wang Signed-off-by: Limin Wang --- libavformat/mp3dec.c | 5 + 1 file changed, 5 insertions(+) diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c index 258f19174b..f15045dd6f 100644 --- a/libavformat/mp3dec.c +++ b/libavformat/mp3dec.c @@ -73,6 +73,7 @@ static int mp3_read_probe(const AVProbeData *p) int frames, ret; int framesizes, max_framesizes; uint32_t header; +uint32_t next; const uint8_t *buf, *buf0, *buf2, *end; buf0 = p->buf; @@ -93,6 +94,10 @@ static int mp3_read_probe(const AVProbeData *p) ret = avpriv_mpegaudio_decode_header(, header); if (ret != 0) break; +next = AV_RB32(buf2 + 4); +/* detect invalid data after header */ +if ((header & 0xfffe) == (next & 0xfffe)) +break; buf2 += h.frame_size; framesizes += h.frame_size; } -- 2.21.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat/utils: Fixes misdetection of zYLx.wav
On Thu, Nov 07, 2019 at 06:35:12AM +0100, Carl Eugen Hoyos wrote:
>
>
> > Am 07.11.2019 um 02:23 schrieb lance.lmw...@gmail.com:
> >
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavformat/wavdec.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
> > index 52194f54ef..109c931a22 100644
> > --- a/libavformat/wavdec.c
> > +++ b/libavformat/wavdec.c
> > @@ -149,7 +149,8 @@ static int wav_probe(const AVProbeData *p)
> >
> > static void handle_stream_probing(AVStream *st)
> > {
> > -if (st->codecpar->codec_id == AV_CODEC_ID_PCM_S16LE) {
> > +if (st->codecpar->codec_id == AV_CODEC_ID_PCM_S16LE &&
> > +st->codecpar->sample_rate <= 0 && st->codecpar->channels <= 0) {
>
> Doesn’t this break dca detection?
>
> As said, you have to fix this issue in the mp3 probe function.
000 52 49 46 46 38 bd 7a 00 57 41 56 45 66 6d 74 20
010 10 00 00 00 01 00 02 00 44 ac 00 00 10 b1 02 00
020 04 00 10 00 64 61 74 61 38 bd 7a 00 ff ff e8 ff
030 ff ff e8 ff ff ff e8 ff ff ff e8 ff ff ff e8 ff
"ff ff e8 ff" is valid mp3 header and parse all of mp3 field, but the
pattern, we can observed the header repeat with "ff ff e8 ff", I think
this is invalid. So I can add one invalid check for the repeating
condition which works for the sample only. I can update the patch for
review, it's change in the mp3 probe function.
>
> > st->request_probe = AVPROBE_SCORE_EXTENSION;
> > st->probe_packets = FFMIN(st->probe_packets, 32);
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavf/movenc: Replace dts by pts to calculate duration
From: Mengyang Yuan
In this case, the input video is of dynamic frame rate and we don't want to
duplicate or drop frames, but the output video duration calculated by DTS is
incorrect, I solved it by using PTS.
There are many UGC videos with dynamic frame rates, which are represented by
PTS jumps. After transcoding with ffmpeg -vsync 0 or -vsync 2, the output
video duration becomes longer.By reading the code of x264/encoder/encoder.c,
I found that in order to predict the B frame, x264 needs to ensure that there
are enough reference frames when DTS = 0, so the DTS of these reference frames
will subtract the cache time. However, the cache time includes the part of PTS
jumps, which results in the abnormal small DTS.
Signed-off-by: Mengyang Yuan
---
libavformat/movenc.c | 23 ++-
libavformat/movenc.h | 2 ++
tests/ref/fate/movenc | 20 ++--
tests/ref/lavf/mov| 4 ++--
tests/ref/lavf/mp4| 4 ++--
5 files changed, 30 insertions(+), 23 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 715bec1c2f..206aa48d8c 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1015,7 +1015,7 @@ static int get_cluster_duration(MOVTrack *track, int
cluster_idx)
return 0;
if (cluster_idx + 1 == track->entry)
-next_dts = track->track_duration + track->start_dts;
+next_dts = track->end_dts;
else
next_dts = track->cluster[cluster_idx + 1].dts;
@@ -5149,8 +5149,7 @@ static int mov_flush_fragment(AVFormatContext *s, int
force)
mov->mdat_size = 0;
for (i = 0; i < mov->nb_streams; i++) {
if (mov->tracks[i].entry)
-mov->tracks[i].frag_start += mov->tracks[i].start_dts +
- mov->tracks[i].track_duration -
+mov->tracks[i].frag_start += mov->tracks[i].end_dts -
mov->tracks[i].cluster[0].dts;
mov->tracks[i].entry = 0;
mov->tracks[i].end_reliable = 0;
@@ -5208,7 +5207,7 @@ static int mov_flush_fragment(AVFormatContext *s, int
force)
int64_t duration = 0;
if (track->entry)
-duration = track->start_dts + track->track_duration -
+duration = track->end_dts -
track->cluster[0].dts;
if (mov->flags & FF_MOV_FLAG_SEPARATE_MOOF) {
if (!track->mdat_buf)
@@ -5281,7 +5280,7 @@ static int check_pkt(AVFormatContext *s, AVPacket *pkt)
ref = trk->cluster[trk->entry - 1].dts;
} else if ( trk->start_dts != AV_NOPTS_VALUE
&& !trk->frag_discont) {
-ref = trk->start_dts + trk->track_duration;
+ref = trk->end_dts;
} else
ref = pkt->dts; // Skip tests for the first packet
@@ -5494,7 +5493,7 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt)
* of the last packet of the previous fragment based on
track_duration,
* which might not exactly match our dts. Therefore adjust the dts
* of this packet to be what the previous packets duration
implies. */
-trk->cluster[trk->entry].dts = trk->start_dts +
trk->track_duration;
+trk->cluster[trk->entry].dts = trk->end_dts;
/* We also may have written the pts and the corresponding duration
* in sidx/tfrf/tfxd tags; make sure the sidx pts and duration
match up with
* the next fragment. This means the cts of the first sample must
@@ -5546,13 +5545,17 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket
*pkt)
"this case.\n",
pkt->stream_index, pkt->dts);
}
-trk->track_duration = pkt->dts - trk->start_dts + pkt->duration;
-trk->last_sample_is_subtitle_end = 0;
-
if (pkt->pts == AV_NOPTS_VALUE) {
av_log(s, AV_LOG_WARNING, "pts has no value\n");
pkt->pts = pkt->dts;
}
+if (trk->start_pts == AV_NOPTS_VALUE) {
+trk->start_pts = pkt->pts;
+}
+trk->track_duration = FFMAX(pkt->pts - trk->start_pts + pkt->duration,
trk->track_duration);
+trk->end_dts = pkt->dts + pkt->duration;
+trk->last_sample_is_subtitle_end = 0;
+
if (pkt->dts != pkt->pts)
trk->flags |= MOV_TRACK_CTTS;
trk->cluster[trk->entry].cts = pkt->pts - pkt->dts;
@@ -6295,7 +6298,9 @@ static int mov_init(AVFormatContext *s)
* this is updated. */
track->hint_track = -1;
track->start_dts = AV_NOPTS_VALUE;
+track->start_pts = AV_NOPTS_VALUE;
track->start_cts = AV_NOPTS_VALUE;
+track->end_dts= AV_NOPTS_VALUE;
track->end_pts= AV_NOPTS_VALUE;
track->dts_shift = AV_NOPTS_VALUE;
if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
diff --git a/libavformat/movenc.h b/libavformat/movenc.h
index 68d6f23a5a..ddad2631d7 100644
--- a/libavformat/movenc.h
+++ b/libavformat/movenc.h
@@ -116,7
[FFmpeg-devel] [PATCH] lavf/movenc: Replace dts by pts to calculate duration
From: Mengyang Yuan
In this case, the input video is of dynamic frame rate and we don't want to
duplicate or drop frames, but the output video duration calculated by DTS is
incorrect, I solved it by using PTS.
There are many UGC videos with dynamic frame rates, which are represented by
PTS jumps. After transcoding with ffmpeg -vsync 0 or -vsync 2, the output
video duration becomes longer.By reading the code of x264/encoder/encoder.c,
I found that in order to predict the B frame, x264 needs to ensure that there
are enough reference frames when DTS = 0, so the DTS of these reference frames
will subtract the cache time. However, the cache time includes the part of PTS
jumps, which results in the abnormal small DTS.
Signed-off-by: Mengyang Yuan
---
libavformat/movenc.c | 23 ++-
libavformat/movenc.h | 2 ++
tests/ref/fate/movenc | 20 ++--
tests/ref/lavf/mov| 4 ++--
tests/ref/lavf/mp4| 4 ++--
5 files changed, 30 insertions(+), 23 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 715bec1c2f..206aa48d8c 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1015,7 +1015,7 @@ static int get_cluster_duration(MOVTrack *track, int
cluster_idx)
return 0;
if (cluster_idx + 1 == track->entry)
-next_dts = track->track_duration + track->start_dts;
+next_dts = track->end_dts;
else
next_dts = track->cluster[cluster_idx + 1].dts;
@@ -5149,8 +5149,7 @@ static int mov_flush_fragment(AVFormatContext *s, int
force)
mov->mdat_size = 0;
for (i = 0; i < mov->nb_streams; i++) {
if (mov->tracks[i].entry)
-mov->tracks[i].frag_start += mov->tracks[i].start_dts +
- mov->tracks[i].track_duration -
+mov->tracks[i].frag_start += mov->tracks[i].end_dts -
mov->tracks[i].cluster[0].dts;
mov->tracks[i].entry = 0;
mov->tracks[i].end_reliable = 0;
@@ -5208,7 +5207,7 @@ static int mov_flush_fragment(AVFormatContext *s, int
force)
int64_t duration = 0;
if (track->entry)
-duration = track->start_dts + track->track_duration -
+duration = track->end_dts -
track->cluster[0].dts;
if (mov->flags & FF_MOV_FLAG_SEPARATE_MOOF) {
if (!track->mdat_buf)
@@ -5281,7 +5280,7 @@ static int check_pkt(AVFormatContext *s, AVPacket *pkt)
ref = trk->cluster[trk->entry - 1].dts;
} else if ( trk->start_dts != AV_NOPTS_VALUE
&& !trk->frag_discont) {
-ref = trk->start_dts + trk->track_duration;
+ref = trk->end_dts;
} else
ref = pkt->dts; // Skip tests for the first packet
@@ -5494,7 +5493,7 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt)
* of the last packet of the previous fragment based on
track_duration,
* which might not exactly match our dts. Therefore adjust the dts
* of this packet to be what the previous packets duration
implies. */
-trk->cluster[trk->entry].dts = trk->start_dts +
trk->track_duration;
+trk->cluster[trk->entry].dts = trk->end_dts;
/* We also may have written the pts and the corresponding duration
* in sidx/tfrf/tfxd tags; make sure the sidx pts and duration
match up with
* the next fragment. This means the cts of the first sample must
@@ -5546,13 +5545,17 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket
*pkt)
"this case.\n",
pkt->stream_index, pkt->dts);
}
-trk->track_duration = pkt->dts - trk->start_dts + pkt->duration;
-trk->last_sample_is_subtitle_end = 0;
-
if (pkt->pts == AV_NOPTS_VALUE) {
av_log(s, AV_LOG_WARNING, "pts has no value\n");
pkt->pts = pkt->dts;
}
+if (trk->start_pts == AV_NOPTS_VALUE) {
+trk->start_pts = pkt->pts;
+}
+trk->track_duration = FFMAX(pkt->pts - trk->start_pts + pkt->duration,
trk->track_duration);
+trk->end_dts = pkt->dts + pkt->duration;
+trk->last_sample_is_subtitle_end = 0;
+
if (pkt->dts != pkt->pts)
trk->flags |= MOV_TRACK_CTTS;
trk->cluster[trk->entry].cts = pkt->pts - pkt->dts;
@@ -6295,7 +6298,9 @@ static int mov_init(AVFormatContext *s)
* this is updated. */
track->hint_track = -1;
track->start_dts = AV_NOPTS_VALUE;
+track->start_pts = AV_NOPTS_VALUE;
track->start_cts = AV_NOPTS_VALUE;
+track->end_dts= AV_NOPTS_VALUE;
track->end_pts= AV_NOPTS_VALUE;
track->dts_shift = AV_NOPTS_VALUE;
if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
diff --git a/libavformat/movenc.h b/libavformat/movenc.h
index 68d6f23a5a..ddad2631d7 100644
--- a/libavformat/movenc.h
+++ b/libavformat/movenc.h
@@ -116,7
Re: [FFmpeg-devel] [PATCH] lavf/movenc: Replace dts by pts to calculate duration
Thanks for your reply! My changes break make fate but this is inevitable. I will update the corresponding references to make sure make fate success At 2019-11-07 00:47:42, "Michael Niedermayer" wrote: >On Wed, Nov 06, 2019 at 10:36:11AM +0800, manuelyuan wrote: >> From: Mengyang Yuan >> >> In this case, the input video is of dynamic frame rate and we don't want to >> duplicate or drop frames, but the output video duration calculated by DTS is >> incorrect, I solved it by using PTS. >> There are many UGC videos with dynamic frame rates, which are represented by >> PTS jumps. After transcoding with ffmpeg -vsync 0 or -vsync 2, the output >> video duration becomes longer.By reading the code of x264/encoder/encoder.c, >> I found that in order to predict the B frame, x264 needs to ensure that there >> are enough reference frames when DTS = 0, so the DTS of these reference >> frames >> will subtract the cache time. However, the cache time includes the part of >> PTS >> jumps, which results in the abnormal small DTS. >> >> Signed-off-by: Mengyang Yuan >> --- >> libavformat/movenc.c | 23 ++- >> libavformat/movenc.h | 2 ++ >> 2 files changed, 16 insertions(+), 9 deletions(-) > >this breaks make fate / changes checksums >if the changes are intended, the references would need to be updated >with the patch doing the change > >make: *** [fate-lavf-mp4] Error 1 >make: *** [fate-lavf-mov] Error 1 >make: *** [fate-binsub-movtextenc] Error 1 >make: *** [fate-movenc] Error 1 > >thanks > >[...] >-- >Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > >Asymptotically faster algorithms should always be preferred if you have >asymptotical amounts of data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 0/2] lavf/isom: support for demuxing MPEG-H 3D Audio in MP4
Hi Carl, > From: ffmpeg-devel On Behalf Of Carl > Eugen Hoyo > Does not work here, please use any other filehoster. I have uploaded it to following, so please confirm. https://wetransfer.com/downloads/f6d4468bf755909fb1592e600268930720191107082513/bdc63ea97eada0d939473109c3d4200c20191107082513/dca7fe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
