[FFmpeg-devel] [PATCH 2/2] examples: Fix use of AV_CODEC_FLAG_GLOBAL_HEADER
AV_CODEC_FLAG_GLOBAL_HEADER should be set before calling avcodec_open2() to
have any effect.
---
doc/examples/transcoding.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/doc/examples/transcoding.c b/doc/examples/transcoding.c
index a83fa3a..e48837c 100644
--- a/doc/examples/transcoding.c
+++ b/doc/examples/transcoding.c
@@ -172,6 +172,9 @@ static int open_output_file(const char *filename)
enc_ctx->time_base = (AVRational){1, enc_ctx->sample_rate};
}
+if (ofmt_ctx->oformat->flags & AVFMT_GLOBALHEADER)
+enc_ctx->flags |= AV_CODEC_FLAG_GLOBAL_HEADER;
+
/* Third parameter can be used to pass settings to encoder */
ret = avcodec_open2(enc_ctx, encoder, NULL);
if (ret < 0) {
@@ -183,8 +186,6 @@ static int open_output_file(const char *filename)
av_log(NULL, AV_LOG_ERROR, "Failed to copy encoder parameters
to output stream #%u\n", i);
return ret;
}
-if (ofmt_ctx->oformat->flags & AVFMT_GLOBALHEADER)
-enc_ctx->flags |= AV_CODEC_FLAG_GLOBAL_HEADER;
out_stream->time_base = enc_ctx->time_base;
stream_ctx[i].enc_ctx = enc_ctx;
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] Fix typos
--- libavcodec/qsvenc_h264.c | 2 +- libavutil/avassert.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c index 7aa65e9..dfa4666 100644 --- a/libavcodec/qsvenc_h264.c +++ b/libavcodec/qsvenc_h264.c @@ -1,5 +1,5 @@ /* - * Intel MediaSDK QSV based H.264 enccoder + * Intel MediaSDK QSV based H.264 encoder * * copyright (c) 2013 Yukinori Yamazoe * diff --git a/libavutil/avassert.h b/libavutil/avassert.h index 46f3fea..9abeade 100644 --- a/libavutil/avassert.h +++ b/libavutil/avassert.h @@ -66,7 +66,7 @@ #endif /** - * Assert that floating point opperations can be executed. + * Assert that floating point operations can be executed. * * This will av_assert0() that the cpu is not in MMX state on X86 */ -- 2.7.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] avcodec/mips: [loongson] reoptimize h264_chroma_mc8_mmi v2.
Reoptimize function ff_put_h264_chroma_mc8_mmi and ff_avg_h264_chroma_mc8_mmi.
Performance of h264 decoding improved about 5%(from 69fps to 73fps, tested on
loongson 3A3000).
Change-Id: Iccd7f4e480b2d0bfc47e4d409874c4adb77416cc
---
libavcodec/mips/h264chroma_mmi.c | 744 ---
1 file changed, 455 insertions(+), 289 deletions(-)
diff --git a/libavcodec/mips/h264chroma_mmi.c b/libavcodec/mips/h264chroma_mmi.c
index bafe0f9..91b2cc4 100644
--- a/libavcodec/mips/h264chroma_mmi.c
+++ b/libavcodec/mips/h264chroma_mmi.c
@@ -29,326 +29,322 @@
void ff_put_h264_chroma_mc8_mmi(uint8_t *dst, uint8_t *src, ptrdiff_t stride,
int h, int x, int y)
{
-const int A = (8 - x) * (8 - y);
-const int B = x * (8 - y);
-const int C = (8 - x) * y;
-const int D = x * y;
-const int E = B + C;
+int A = 64, B, C, D, E;
double ftmp[10];
uint64_t tmp[1];
-mips_reg addr[1];
-DECLARE_VAR_ALL64;
-if (D) {
+if (!(x || y)) {
+/* x=0, y=0, A=64 */
__asm__ volatile (
-"xor%[ftmp0], %[ftmp0], %[ftmp0]\n\t"
-"dli%[tmp0],0x06\n\t"
-"pshufh %[A], %[A], %[ftmp0]\n\t"
-"pshufh %[B], %[B], %[ftmp0]\n\t"
-"mtc1 %[tmp0],%[ftmp9]\n\t"
-"pshufh %[C], %[C], %[ftmp0]\n\t"
-"pshufh %[D], %[D], %[ftmp0]\n\t"
+"xor%[ftmp0], %[ftmp0], %[ftmp0] \n\t"
+"dli%[tmp0],0x06 \n\t"
+"mtc1 %[tmp0],%[ftmp4] \n\t"
-"1: \n\t"
-PTR_ADDU "%[addr0], %[src], %[stride] \n\t"
+"1:\n\t"
MMI_ULDC1(%[ftmp1], %[src], 0x00)
-MMI_ULDC1(%[ftmp2], %[src], 0x01)
-MMI_ULDC1(%[ftmp3], %[addr0], 0x00)
-MMI_ULDC1(%[ftmp4], %[addr0], 0x01)
-
-"punpcklbh %[ftmp5], %[ftmp1], %[ftmp0]\n\t"
-"punpckhbh %[ftmp6], %[ftmp1], %[ftmp0]\n\t"
-"punpcklbh %[ftmp7], %[ftmp2], %[ftmp0]\n\t"
-"punpckhbh %[ftmp8], %[ftmp2], %[ftmp0]\n\t"
-"pmullh %[ftmp5], %[ftmp5], %[A]\n\t"
-"pmullh %[ftmp7], %[ftmp7], %[B]\n\t"
-"paddh %[ftmp1], %[ftmp5], %[ftmp7]\n\t"
-"pmullh %[ftmp6], %[ftmp6], %[A]\n\t"
-"pmullh %[ftmp8], %[ftmp8], %[B]\n\t"
-"paddh %[ftmp2], %[ftmp6], %[ftmp8]\n\t"
-
-"punpcklbh %[ftmp5], %[ftmp3], %[ftmp0]\n\t"
-"punpckhbh %[ftmp6], %[ftmp3], %[ftmp0]\n\t"
-"punpcklbh %[ftmp7], %[ftmp4], %[ftmp0]\n\t"
-"punpckhbh %[ftmp8], %[ftmp4], %[ftmp0]\n\t"
-"pmullh %[ftmp5], %[ftmp5], %[C]\n\t"
-"pmullh %[ftmp7], %[ftmp7], %[D]\n\t"
-"paddh %[ftmp3], %[ftmp5], %[ftmp7]\n\t"
-"pmullh %[ftmp6], %[ftmp6], %[C]\n\t"
-"pmullh %[ftmp8], %[ftmp8], %[D]\n\t"
-"paddh %[ftmp4], %[ftmp6], %[ftmp8]\n\t"
-
-"paddh %[ftmp1], %[ftmp1], %[ftmp3]\n\t"
-"paddh %[ftmp2], %[ftmp2], %[ftmp4]\n\t"
-"paddh %[ftmp1], %[ftmp1], %[ff_pw_32] \n\t"
-"paddh %[ftmp2], %[ftmp2], %[ff_pw_32] \n\t"
-"psrlh %[ftmp1], %[ftmp1], %[ftmp9]\n\t"
-"psrlh %[ftmp2], %[ftmp2], %[ftmp9]\n\t"
-"packushb %[ftmp1], %[ftmp1], %[ftmp2]\n\t"
-"addi %[h], %[h], -0x01 \n\t"
+"addi %[h], %[h], -0x04 \n\t"
+PTR_ADDU "%[src], %[src], %[stride] \n\t"
+MMI_ULDC1(%[ftmp5], %[src], 0x00)
+PTR_ADDU "%[src], %[src], %[stride] \n\t"
+MMI_ULDC1(%[ftmp6], %[src], 0x00)
+PTR_ADDU "%[src], %[src], %[stride] \n\t"
+MMI_ULDC1(%[ftmp7], %[src], 0x00)
+
+"punpcklbh %[ftmp2], %[ftmp1],
Re: [FFmpeg-devel] [PATCH]tests/ref/fate/pixelutils: Add a newline
On Thu, Aug 30, 2018 at 5:36 AM Carl Eugen Hoyos wrote: > > Hi! > > Attached patch fixes fate-pixelutils on aix. > > Please comment, Carl Eugen LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] libavformat/mxfenc: add missing dnxhr mxf container essence ULs
Hey Jay, On Sun, Aug 26, 2018 at 12:20 AM wrote: > Baptiste you are right that DNxHR is variable frame size (0) from > avpriv_dnxhd_get_frame_size and that it breaks the index. > > is there a reason not to use the pkt->size as frame_size since DNxHR is a > constant frame_size for a given resolution and quality profile? > > That's a good idea if that works and a check is added to guarantee that the frame size doesn't change during the muxing. -- Baptiste ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/utils: Don't parse encrypted packets.
On Wed, Aug 29, 2018 at 03:30:39PM -0700, Jacob Trimble wrote: > On Wed, Aug 29, 2018 at 3:20 PM James Almer wrote: > > > > On 8/29/2018 7:07 PM, Michael Niedermayer wrote: > > > On Tue, Aug 28, 2018 at 10:58:43AM -0700, Jacob Trimble wrote: > > >> If a packet is full-sample encrypted, then packet data can't be parsed > > >> without decrypting it. So this skips the packet parsing for those > > >> packets. If the packet has sub-sample encryption, it is assumed that > > >> the headers are in the clear and the parser will only need that info. > > >> > > >> Signed-off-by: Jacob Trimble > > >> --- > > >> libavformat/utils.c | 21 - > > >> 1 file changed, 20 insertions(+), 1 deletion(-) > > > > > > Hmm, please correct me if iam wrong but IIUC > > > 1. The demuxer has set need_parsing, indicating that it _requires_ a > > > parser > > There isn't a flag for "try parsing and ignore errors". So my choice > (from an app) is to either require parsing or don't do parsing at all > (which can result in incorrect timestamps). > > > > 2. Parsing cannot be done before decrypting > > > > > > If all this and the set values are correct, logically, the fix would be > > > to decrypt the packet before the parser not to skip the parser. > > There are cases where the packet can't be decrypted before getting to > this point. Can you elaborate on these cases ? I dont think its obvious what these cases are, at least its not obvious to me what exactly you are thinking of here. And i think its not helpfull if i guess what you mean and then argue/comment on that because maybe you meant something entirely different ... > This point is between the demuxer creating the packet and > giving to the app. So the only way to decrypt the frame (as of now) > is for the demuxer to do this. There is no way for the app to handle > the decryption before this point. > > From the app's perspective, I would expect the packet to remain > encrypted for as long as possible. why ? > My app will store the packet for a > while, then decrypt it right before passing it to the decoder and > drawing the frame. So requiring the packet to be decrypted at this > point is not ideal. > > > > > And if that can't be done, then the demuxer could perhaps set > > st->need_parsing to 0 and skip parsing altogether? > > I would want to still have parsing if possible. For example, a lot of > content has a clear lead where the first few seconds are clear. So > they could be used to adjust the starting timestamps (and whatever > parsing needs) and the encrypted content later can be deduced based on > that. > [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/utils: Don't parse encrypted packets.
On Wed, Aug 29, 2018 at 3:20 PM James Almer wrote: > > On 8/29/2018 7:07 PM, Michael Niedermayer wrote: > > On Tue, Aug 28, 2018 at 10:58:43AM -0700, Jacob Trimble wrote: > >> If a packet is full-sample encrypted, then packet data can't be parsed > >> without decrypting it. So this skips the packet parsing for those > >> packets. If the packet has sub-sample encryption, it is assumed that > >> the headers are in the clear and the parser will only need that info. > >> > >> Signed-off-by: Jacob Trimble > >> --- > >> libavformat/utils.c | 21 - > >> 1 file changed, 20 insertions(+), 1 deletion(-) > > > > Hmm, please correct me if iam wrong but IIUC > > 1. The demuxer has set need_parsing, indicating that it _requires_ a parser There isn't a flag for "try parsing and ignore errors". So my choice (from an app) is to either require parsing or don't do parsing at all (which can result in incorrect timestamps). > > 2. Parsing cannot be done before decrypting > > > > If all this and the set values are correct, logically, the fix would be > > to decrypt the packet before the parser not to skip the parser. There are cases where the packet can't be decrypted before getting to this point. This point is between the demuxer creating the packet and giving to the app. So the only way to decrypt the frame (as of now) is for the demuxer to do this. There is no way for the app to handle the decryption before this point. From the app's perspective, I would expect the packet to remain encrypted for as long as possible. My app will store the packet for a while, then decrypt it right before passing it to the decoder and drawing the frame. So requiring the packet to be decrypted at this point is not ideal. > > And if that can't be done, then the demuxer could perhaps set > st->need_parsing to 0 and skip parsing altogether? I would want to still have parsing if possible. For example, a lot of content has a clear lead where the first few seconds are clear. So they could be used to adjust the starting timestamps (and whatever parsing needs) and the encrypted content later can be deduced based on that. > > > > > Am i missing something ? > > > > thx > > > > [...] > > > > > > > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add 10-bit test for hue video filter
On Tue, Aug 28, 2018 at 01:16:03PM +0200, Tobias Rapp wrote: > Signed-off-by: Tobias Rapp > --- > tests/fate/filter-video.mak | 3 +++ > tests/ref/fate/filter-hue4 | 1 + > 2 files changed, 4 insertions(+) > create mode 100644 tests/ref/fate/filter-hue4 > > diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak > index edd51e1..c87a7ba 100644 > --- a/tests/fate/filter-video.mak > +++ b/tests/fate/filter-video.mak > @@ -514,6 +514,9 @@ fate-filter-hue2: CMD = video_filter > "perms=random,hue=h=18*n" -frames:v 20 > FATE_FILTER_VSYNTH-$(call ALLYES, PERMS_FILTER HUE_FILTER) += > fate-filter-hue3 > fate-filter-hue3: CMD = video_filter "perms=random,hue=b=n-10" -frames:v 20 > > +FATE_FILTER_VSYNTH-$(call ALLYES, FORMAT_FILTER PERMS_FILTER HUE_FILTER) += > fate-filter-hue4 > +fate-filter-hue4: CMD = video_filter > "format=yuv422p10,perms=random,hue=h=18*n:s=n/10" -frames:v 20 > + > FATE_FILTER_VSYNTH-$(CONFIG_IDET_FILTER) += fate-filter-idet > fate-filter-idet: CMD = framecrc -flags bitexact -idct simple -i $(SRC) -vf > idet -frames:v 25 -flags +bitexact > > diff --git a/tests/ref/fate/filter-hue4 b/tests/ref/fate/filter-hue4 > new file mode 100644 > index 000..2a08c33 > --- /dev/null > +++ b/tests/ref/fate/filter-hue4 > @@ -0,0 +1 @@ > +hue46279ed43527e7b5be645819e08880107 fails on mips as that uses a big endian output format instead with different md5 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/utils: Don't parse encrypted packets.
On 8/29/2018 7:07 PM, Michael Niedermayer wrote: > On Tue, Aug 28, 2018 at 10:58:43AM -0700, Jacob Trimble wrote: >> If a packet is full-sample encrypted, then packet data can't be parsed >> without decrypting it. So this skips the packet parsing for those >> packets. If the packet has sub-sample encryption, it is assumed that >> the headers are in the clear and the parser will only need that info. >> >> Signed-off-by: Jacob Trimble >> --- >> libavformat/utils.c | 21 - >> 1 file changed, 20 insertions(+), 1 deletion(-) > > Hmm, please correct me if iam wrong but IIUC > 1. The demuxer has set need_parsing, indicating that it _requires_ a parser > 2. Parsing cannot be done before decrypting > > If all this and the set values are correct, logically, the fix would be > to decrypt the packet before the parser not to skip the parser. And if that can't be done, then the demuxer could perhaps set st->need_parsing to 0 and skip parsing altogether? > > Am i missing something ? > > thx > > [...] > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/utils: Don't parse encrypted packets.
On Tue, Aug 28, 2018 at 10:58:43AM -0700, Jacob Trimble wrote: > If a packet is full-sample encrypted, then packet data can't be parsed > without decrypting it. So this skips the packet parsing for those > packets. If the packet has sub-sample encryption, it is assumed that > the headers are in the clear and the parser will only need that info. > > Signed-off-by: Jacob Trimble > --- > libavformat/utils.c | 21 - > 1 file changed, 20 insertions(+), 1 deletion(-) Hmm, please correct me if iam wrong but IIUC 1. The demuxer has set need_parsing, indicating that it _requires_ a parser 2. Parsing cannot be done before decrypting If all this and the set values are correct, logically, the fix would be to decrypt the packet before the parser not to skip the parser. Am i missing something ? thx [...] -- 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 http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]tests/ref/fate/pixelutils: Add a newline
Hi! Attached patch fixes fate-pixelutils on aix. Please comment, Carl Eugen From 2ec8e85758d83bbe44057a454a6490692465dcfc Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Wed, 29 Aug 2018 23:26:01 +0200 Subject: [PATCH] tests/ref/fate/pixelutils: Add a newline. Fixes fate-pixelutils on aix. --- tests/ref/fate/pixelutils |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/ref/fate/pixelutils b/tests/ref/fate/pixelutils index 434904e..df72d52 100644 --- a/tests/ref/fate/pixelutils +++ b/tests/ref/fate/pixelutils @@ -57,4 +57,4 @@ [OK] [AA] SAD [small] 16x16=22986 ref=22986 [OK] [UU] SAD [small] 32x32=86550 ref=86550 [OK] [AU] SAD [small] 32x32=83656 ref=83656 -[OK] [AA] SAD [small] 32x32=85164 ref=85164 \ No newline at end of file +[OK] [AA] SAD [small] 32x32=85164 ref=85164 -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] make work (live) libsrt
Well, when this is done, working, we can begin to talk business: -add an option to ffmpeg to drop unused input data like srt-file-transmit (before first client connects) -add an option/document if it's already working to ffmpeg to have multiple srt clients like gstreamer Regards, On Wed, Aug 29, 2018 at 10:48 AM Marton Balint wrote: > > > On Wed, 29 Aug 2018, Tudor Suciu wrote: > > > Hello Marton, > > > > And should simply set SRTO_PACKETSIZE to our pkt_size parameter if we > >> don't want the libsrt default 1356. > >> > > At least for the specific case of mpegts I believe it's much better to > have > > fixed size packets(188x*). > > It helps error recovery if we don't have to re-synchronize ts so > > (7*188=1316) seems a better default. > > The 1356 value could be treated as a maximum special case value, all > sorts > > of network configurations can eat from the MTU (vpn comes to mind). > > If I understand correctly the working of libsrt, it "creates" a packet > each > > time we send it some data. So without touching on the "maximum" value, > > h->max_packet_size insures that the "medium" value is effectively the > > expected one. > > The 1356 value, assuming no vpn/tunnel will spoil the party, will make ts > > advance with 40 bytes each packet, so almost any packet loss will produce > > ts that does not start with ts header. This doesn't seem good for packet > > loss recovery. > > Rtp encapsulated mpeg ts with pkt_size of 1316 will add an rtp header of > ~ > > 12 bytes so the needed srt payloadsize will be 1328. As wireshark does > not > > recognize the protocol yet, I couldn't check in detail. I'm absolutely > > certain that ffmpeg will do bad things if rtp header is misplaced (not > > synchronized with a lost packet), it will end up happily reading random > ts > > data as rtp header at some point given enough packet loss. > > I am sorry for the consfusion, I meant 1316 and not 1356, and libsrt > provides 1316 as default max payload size exactly for the reasons you > described, and therefore that becomes the default max packet size. So all > is fine in the code as far as I see, only my descriptive text was > misleading, sorry. > > Thanks, > Marton > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg.c: add an option "detail_stats" to allow ffmpeg to output stats for each stream
On Mon, Aug 27, 2018 at 11:48:46PM -0700, Wang Cao wrote: > From: Wang Cao > > Add an option "detail_stats" to ffmpeg to output stats for each video/audio > streams and each ouptut file ffmpeg output log in print_report. The format of > stats is unchanged. this changes -progress output ./ffmpeg -progress progress -i mm-small-short.mp4 -f null - stream_0_0_q=-0.0 bitrate=N/A total_size=N/A -out_time_us=1002667 -out_time_ms=1002667 -out_time=00:00:01.002667 +out_time_us=100 +out_time_ms=100 +out_time=00:00:01.00 dup_frames=0 drop_frames=0 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH V7 0/3] enable multi-slices in vaapi_h264/265 encoder
V7: - Fix h264 first_mb_in_slice setting issue. (root cause by Mark) - Refine the error handle V6: - Use rectangular slices and refine the code. V5: - In h265_vaapi encoder, when setting slice number > max slice number supported by driver, report error and return. Same as h264_vaapi. - Clean the logic when setting first_slice_segment_in_pic_flags. V4: - Change the array malloc function. - Clean the pointless condition check when free the memory. V3: - Making pic->slices be VAAPIEncodeSlice* instead of VAAPIEncodeSlice**. - Fix resource (vaBuffer) lead when realloc pic->param_buffers fail. - Adjust max_slices location in VAAPIEncodeContext. - Re-work distributing the macro-blocks for multi-slices function. V2: - Change the slice/parameter buffers to dynamic alloc and split the mutil-slice support for AVC/HEVC. Jun Zhao (3): lavc/vaapi_encode: Add max slices number query. lavc/vaapi_encode_h264: respect "slices" option in h264 vaapi encoder lavc/vaapi_encode_h265: respect "slices" option in h265 vaapi encoder libavcodec/vaapi_encode.c |4 +++ libavcodec/vaapi_encode.h |4 +++ libavcodec/vaapi_encode_h264.c | 39 + libavcodec/vaapi_encode_h265.c | 41 ++- 4 files changed, 77 insertions(+), 11 deletions(-) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH V7 3/3] lavc/vaapi_encode_h265: respect "slices" option in h265 vaapi encoder
Enable multi-slice support in HEVC/H.265 vaapi encoder.
Signed-off-by: Wang, Yi A
Signed-off-by: Jun Zhao
---
libavcodec/vaapi_encode_h265.c | 41 ++-
1 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 8f191ef..e6ee352 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -615,9 +615,11 @@ static int
vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
static int vaapi_encode_h265_init_picture_params(AVCodecContext *avctx,
VAAPIEncodePicture *pic)
{
+VAAPIEncodeContext *ctx = avctx->priv_data;
VAAPIEncodeH265Context *priv = avctx->priv_data;
VAEncPictureParameterBufferHEVC *vpic = pic->codec_picture_params;
int i;
+int slices;
if (pic->type == PICTURE_TYPE_IDR) {
av_assert0(pic->display_order == pic->encode_order);
@@ -792,7 +794,17 @@ static int
vaapi_encode_h265_init_picture_params(AVCodecContext *avctx,
av_assert0(0 && "invalid picture type");
}
-pic->nb_slices = 1;
+slices = 1;
+if (ctx->max_slices) {
+if (avctx->slices <= FFMIN(ctx->max_slices, priv->ctu_height)) {
+slices = FFMAX(avctx->slices, slices);
+} else {
+av_log(avctx, AV_LOG_ERROR, "The max slices number per frame "
+ "cannot more than %d.\n", FFMIN(ctx->max_slices,
priv->ctu_height));
+return AVERROR(EINVAL);
+}
+}
+pic->nb_slices = slices;
return 0;
}
@@ -809,6 +821,7 @@ static int
vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
VAEncPictureParameterBufferHEVC *vpic = pic->codec_picture_params;
VAEncSliceParameterBufferHEVC *vslice = slice->codec_slice_params;
int i;
+int base, mod;
sh->nal_unit_header = (H265RawNALUnitHeader) {
.nal_unit_type = priv->slice_nal_unit,
@@ -818,9 +831,14 @@ static int
vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
sh->slice_pic_parameter_set_id = pps->pps_pic_parameter_set_id;
-// Currently we only support one slice per frame.
-sh->first_slice_segment_in_pic_flag = 1;
-sh->slice_segment_address = 0;
+base = priv->ctu_height / pic->nb_slices;
+mod = priv->ctu_height % pic->nb_slices;
+sh->first_slice_segment_in_pic_flag = !!(slice->index == 0);
+if (slice->index < mod)
+sh->slice_segment_address = slice->index * priv->ctu_width * (base +
1);
+else
+sh->slice_segment_address = mod * priv->ctu_width * (base + 1) +
+(slice->index - mod) * priv->ctu_width *
base;
sh->slice_type = priv->slice_type;
@@ -910,7 +928,6 @@ static int
vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
*vslice = (VAEncSliceParameterBufferHEVC) {
.slice_segment_address = sh->slice_segment_address,
-.num_ctu_in_slice = priv->ctu_width * priv->ctu_height,
.slice_type = sh->slice_type,
.slice_pic_parameter_set_id = sh->slice_pic_parameter_set_id,
@@ -931,7 +948,6 @@ static int
vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
.slice_tc_offset_div2 = sh->slice_tc_offset_div2,
.slice_fields.bits = {
-.last_slice_of_pic_flag = 1,
.dependent_slice_segment_flag = sh->dependent_slice_segment_flag,
.colour_plane_id = sh->colour_plane_id,
.slice_temporal_mvp_enabled_flag =
@@ -950,6 +966,13 @@ static int
vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
},
};
+if (slice->index < mod)
+vslice->num_ctu_in_slice = priv->ctu_width * (base + 1);
+else
+vslice->num_ctu_in_slice = priv->ctu_width * base;
+if (slice->index == pic->nb_slices - 1)
+vslice->slice_fields.bits.last_slice_of_pic_flag = 1;
+
for (i = 0; i < FF_ARRAY_ELEMS(vslice->ref_pic_list0); i++) {
vslice->ref_pic_list0[i].picture_id = VA_INVALID_ID;
vslice->ref_pic_list0[i].flags = VA_PICTURE_HEVC_INVALID;
@@ -1022,6 +1045,12 @@ static av_cold int
vaapi_encode_h265_configure(AVCodecContext *avctx)
av_assert0(0 && "Invalid RC mode.");
}
+if (!ctx->max_slices && avctx->slices > 0) {
+av_log(avctx, AV_LOG_ERROR, "The encode slice option is not "
+ "supported with the driver.\n");
+return AVERROR(ENOSYS);
+}
+
return 0;
}
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH V7 2/3] lavc/vaapi_encode_h264: respect "slices" option in h264 vaapi encoder
Enable multi-slice support in AVC/H.264 vaapi encoder.
Signed-off-by: Wang, Yi A
Signed-off-by: Jun Zhao
---
libavcodec/vaapi_encode_h264.c | 39 ++-
1 files changed, 34 insertions(+), 5 deletions(-)
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index b65c994..36028fb 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -585,6 +585,7 @@ static int
vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
H264RawSPS *sps = &priv->raw_sps;
VAEncPictureParameterBufferH264 *vpic = pic->codec_picture_params;
int i;
+int slices;
memset(&priv->current_access_unit, 0,
sizeof(priv->current_access_unit));
@@ -700,7 +701,17 @@ static int
vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
vpic->pic_fields.bits.idr_pic_flag = (pic->type == PICTURE_TYPE_IDR);
vpic->pic_fields.bits.reference_pic_flag = (pic->type != PICTURE_TYPE_B);
-pic->nb_slices = 1;
+slices = 1;
+if (ctx->max_slices) {
+if (avctx->slices <= FFMIN(ctx->max_slices, priv->mb_height)) {
+slices = FFMAX(avctx->slices, slices);
+} else {
+av_log(avctx, AV_LOG_ERROR, "The max slices number per frame "
+ "cannot be more than %d.\n", FFMIN(ctx->max_slices,
priv->mb_height));
+return AVERROR(EINVAL);
+}
+}
+pic->nb_slices = slices;
return 0;
}
@@ -716,6 +727,7 @@ static int
vaapi_encode_h264_init_slice_params(AVCodecContext *avctx,
VAEncPictureParameterBufferH264 *vpic = pic->codec_picture_params;
VAEncSliceParameterBufferH264 *vslice = slice->codec_slice_params;
int i;
+int base, mod;
if (pic->type == PICTURE_TYPE_IDR) {
sh->nal_unit_header.nal_unit_type = H264_NAL_IDR_SLICE;
@@ -725,8 +737,13 @@ static int
vaapi_encode_h264_init_slice_params(AVCodecContext *avctx,
sh->nal_unit_header.nal_ref_idc = pic->type != PICTURE_TYPE_B;
}
-// Only one slice per frame.
-sh->first_mb_in_slice = 0;
+base = priv->mb_height / pic->nb_slices;
+mod = priv->mb_height % pic->nb_slices;
+if (slice->index < mod)
+sh->first_mb_in_slice = slice->index * priv->mb_width * (base + 1);
+else
+sh->first_mb_in_slice = mod * priv->mb_width * (base + 1) +
+(slice->index - mod) * priv->mb_width * base;
sh->slice_type= priv->slice_type;
sh->pic_parameter_set_id = pps->pic_parameter_set_id;
@@ -748,13 +765,19 @@ static int
vaapi_encode_h264_init_slice_params(AVCodecContext *avctx,
vslice->macroblock_address = sh->first_mb_in_slice;
-vslice->num_macroblocks= priv->mb_width * priv->mb_height;
+if (slice->index < mod)
+vslice->num_macroblocks = priv->mb_width * (base + 1);
+else
+vslice->num_macroblocks = priv->mb_width * base;
+sh->slice_type= priv->slice_type;
+if (slice->index == pic->nb_slices - 1)
+priv->idr_pic_count++;
vslice->macroblock_info = VA_INVALID_ID;
vslice->slice_type = sh->slice_type % 5;
vslice->pic_parameter_set_id = sh->pic_parameter_set_id;
-vslice->idr_pic_id = sh->idr_pic_id;
+vslice->idr_pic_id = priv->idr_pic_count;
vslice->pic_order_cnt_lsb = sh->pic_order_cnt_lsb;
@@ -863,6 +886,12 @@ static av_cold int
vaapi_encode_h264_configure(AVCodecContext *avctx)
}
}
+if (!ctx->max_slices && avctx->slices > 0) {
+av_log(avctx, AV_LOG_ERROR, "The encode slice option is not "
+ "supported with the driver.\n");
+return AVERROR(ENOSYS);
+}
+
return 0;
}
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH V7 1/3] lavc/vaapi_encode: Add max slices number query.
From: Jun Zhao
Add max slices number query.
Signed-off-by: Jun Zhao
---
libavcodec/vaapi_encode.c |4
libavcodec/vaapi_encode.h |4
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 313f551..e4a104e 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -985,6 +985,7 @@ static av_cold int
vaapi_encode_config_attributes(AVCodecContext *avctx)
{ VAConfigAttribRTFormat },
{ VAConfigAttribRateControl },
{ VAConfigAttribEncMaxRefFrames },
+{ VAConfigAttribEncMaxSlices },
{ VAConfigAttribEncPackedHeaders },
};
@@ -1117,6 +1118,9 @@ static av_cold int
vaapi_encode_config_attributes(AVCodecContext *avctx)
}
}
break;
+case VAConfigAttribEncMaxSlices:
+ctx->max_slices = attr[i].value;
+break;
case VAConfigAttribEncPackedHeaders:
if (ctx->va_packed_headers & ~attr[i].value) {
// This isn't fatal, but packed headers are always
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index c7370a1..0df76b5 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -161,6 +161,10 @@ typedef struct VAAPIEncodeContext {
} quality_params;
#endif
+// Supported max-slices number per frame. (0 means driver cannot
+// support max multi-slices query)
+int max_slices;
+
// Per-sequence parameter structure (VAEncSequenceParameterBuffer*).
void *codec_sequence_params;
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] frei0r: handle string params
This is needed for some of the frei0r filters (facebl0r and facedetect) which accept string parameters. Fixes the issue described here: http://www.ffmpeg-archive.org/Unable-to-set-ffmpeg-frei0r-facedetect-filter-parameter-td4680190.html Signed-off-by: Raphael Graf --- libavfilter/vf_frei0r.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/libavfilter/vf_frei0r.c b/libavfilter/vf_frei0r.c index 8aeac08519..67b2f374c3 100644 --- a/libavfilter/vf_frei0r.c +++ b/libavfilter/vf_frei0r.c @@ -93,6 +93,7 @@ static int set_param(AVFilterContext *ctx, f0r_param_info_t info, int index, cha double d; f0r_param_color_t col; f0r_param_position_t pos; +f0r_param_string *str; } val; char *tail; uint8_t rgba[4]; @@ -126,6 +127,11 @@ static int set_param(AVFilterContext *ctx, f0r_param_info_t info, int index, cha break; } +case F0R_PARAM_STRING: +val.str = param; +break; +} + s->set_param_value(s->instance, &val, index); return 0; -- 2.18.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] avcodec/mips: [loongson] reoptimize simple idct with mmi.
Performance of mpeg4 decoding improved about 23%(from 128fps to 158fps, tested
on loongson 3A3000).
Reoptimized following functions with mmi.
1. ff_simple_idct_put_8_mmi
2. ff_simple_idct_add_8_mmi
3. ff_simple_idct_8_mmi
Change-Id: I109939240d31ccb74127431c92daabcbc3f3aa03
---
libavcodec/mips/idctdsp_init_mips.c |7 +-
libavcodec/mips/idctdsp_mips.h |6 +-
libavcodec/mips/simple_idct_mmi.c | 1167 ---
libavutil/mips/mmiutils.h | 49 ++
4 files changed, 444 insertions(+), 785 deletions(-)
diff --git a/libavcodec/mips/idctdsp_init_mips.c
b/libavcodec/mips/idctdsp_init_mips.c
index 8c26bca..bb33b55 100644
--- a/libavcodec/mips/idctdsp_init_mips.c
+++ b/libavcodec/mips/idctdsp_init_mips.c
@@ -20,6 +20,7 @@
*/
#include "idctdsp_mips.h"
+#include "xvididct_mips.h"
#if HAVE_MSA
static av_cold void idctdsp_init_msa(IDCTDSPContext *c, AVCodecContext *avctx,
@@ -48,8 +49,10 @@ static av_cold void idctdsp_init_mmi(IDCTDSPContext *c,
AVCodecContext *avctx,
if ((avctx->lowres != 1) && (avctx->lowres != 2) && (avctx->lowres != 3) &&
(avctx->bits_per_raw_sample != 10) &&
(avctx->bits_per_raw_sample != 12) &&
-(avctx->idct_algo == FF_IDCT_AUTO)) {
-c->idct = ff_simple_idct_mmi;
+((avctx->idct_algo == FF_IDCT_AUTO) || (avctx->idct_algo ==
FF_IDCT_SIMPLE))) {
+c->idct_put = ff_simple_idct_put_8_mmi;
+c->idct_add = ff_simple_idct_add_8_mmi;
+c->idct = ff_simple_idct_8_mmi;
c->perm_type = FF_IDCT_PERM_NONE;
}
diff --git a/libavcodec/mips/idctdsp_mips.h b/libavcodec/mips/idctdsp_mips.h
index 7ca7c1c..829efeb 100644
--- a/libavcodec/mips/idctdsp_mips.h
+++ b/libavcodec/mips/idctdsp_mips.h
@@ -46,8 +46,8 @@ void ff_put_signed_pixels_clamped_mmi(const int16_t *block,
uint8_t *av_restrict pixels, ptrdiff_t line_size);
void ff_add_pixels_clamped_mmi(const int16_t *block,
uint8_t *av_restrict pixels, ptrdiff_t line_size);
-void ff_simple_idct_mmi(int16_t *block);
-void ff_simple_idct_put_mmi(uint8_t *dest, ptrdiff_t line_size, int16_t
*block);
-void ff_simple_idct_add_mmi(uint8_t *dest, ptrdiff_t line_size, int16_t
*block);
+void ff_simple_idct_8_mmi(int16_t *block);
+void ff_simple_idct_put_8_mmi(uint8_t *dest, ptrdiff_t line_size, int16_t
*block);
+void ff_simple_idct_add_8_mmi(uint8_t *dest, ptrdiff_t line_size, int16_t
*block);
#endif // #ifndef AVCODEC_MIPS_IDCTDSP_MIPS_H
diff --git a/libavcodec/mips/simple_idct_mmi.c
b/libavcodec/mips/simple_idct_mmi.c
index 628e13f..7f4bb74 100644
--- a/libavcodec/mips/simple_idct_mmi.c
+++ b/libavcodec/mips/simple_idct_mmi.c
@@ -24,793 +24,400 @@
#include "idctdsp_mips.h"
#include "constants.h"
+#include "libavutil/mips/asmdefs.h"
+#include "libavutil/mips/mmiutils.h"
-#define C0 23170 //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
-#define C1 22725 //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
-#define C2 21407 //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
-#define C3 19266 //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
-#define C4 16383 //cos(i*M_PI/16)*sqrt(2)*(1<<14) - 0.5
-#define C5 12873 //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
-#define C6 8867 //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
-#define C7 4520 //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
+#define W1 22725 //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
+#define W2 21407 //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
+#define W3 19266 //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
+#define W4 16383 //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
+#define W5 12873 //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
+#define W6 8867 //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
+#define W7 4520 //cos(i*M_PI/16)*sqrt(2)*(1<<14) + 0.5
#define ROW_SHIFT 11
#define COL_SHIFT 20
-
-DECLARE_ALIGNED(8, static const int16_t, coeffs)[]= {
-1<<(ROW_SHIFT-1), 0, 1<<(ROW_SHIFT-1), 0,
-1<<(ROW_SHIFT-1), 1, 1<<(ROW_SHIFT-1), 0,
- C4, C4, C4, C4,
- C4, -C4, C4, -C4,
- C2, C6, C2, C6,
- C6, -C2, C6, -C2,
- C1, C3, C1, C3,
- C5, C7, C5, C7,
- C3, -C7, C3, -C7,
- -C1, -C5, -C1, -C5,
- C5, -C1, C5, -C1,
- C7, C3, C7, C3,
- C7, -C5, C7, -C5,
- C3, -C1, C3, -C1
+#define DC_SHIFT 3
+
+DECLARE_ALIGNED(8, const int16_t, W_arr)[46] = {
+W4, W2, W4, W6,
+W1, W3, W5, W7,
+W4, W6, -W4, -W2,
+W3, -W7, -W1, -W5,
+W4, -W6, -W4, W2,
+W5, -W1, W7, W3,
+W4, -W2, W4, -W6,
+W7, -W5, W3, -W1,
+1024, 0, 1024, 0, //ff_p32_1024 = 0x04000400ULL
+0, -1, -1, -1, //mask = 0xULL
+32, 32, 32, 32 //ff_p16_32 = 0x0020002000200020ULL
};
Re: [FFmpeg-devel] make work (live) libsrt
On Wed, 29 Aug 2018, Tudor Suciu wrote: Hello Marton, And should simply set SRTO_PACKETSIZE to our pkt_size parameter if we don't want the libsrt default 1356. At least for the specific case of mpegts I believe it's much better to have fixed size packets(188x*). It helps error recovery if we don't have to re-synchronize ts so (7*188=1316) seems a better default. The 1356 value could be treated as a maximum special case value, all sorts of network configurations can eat from the MTU (vpn comes to mind). If I understand correctly the working of libsrt, it "creates" a packet each time we send it some data. So without touching on the "maximum" value, h->max_packet_size insures that the "medium" value is effectively the expected one. The 1356 value, assuming no vpn/tunnel will spoil the party, will make ts advance with 40 bytes each packet, so almost any packet loss will produce ts that does not start with ts header. This doesn't seem good for packet loss recovery. Rtp encapsulated mpeg ts with pkt_size of 1316 will add an rtp header of ~ 12 bytes so the needed srt payloadsize will be 1328. As wireshark does not recognize the protocol yet, I couldn't check in detail. I'm absolutely certain that ffmpeg will do bad things if rtp header is misplaced (not synchronized with a lost packet), it will end up happily reading random ts data as rtp header at some point given enough packet loss. I am sorry for the consfusion, I meant 1316 and not 1356, and libsrt provides 1316 as default max payload size exactly for the reasons you described, and therefore that becomes the default max packet size. So all is fine in the code as far as I see, only my descriptive text was misleading, sorry. Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avformat/dashdec: Fix calc_cur_seg_no if availability_start_time not
> 在 2018年8月22日，上午7:36，Steven Liu 写道： > > > >> On Aug 21, 2018, at 20:33, jacek jendrzej wrote: >> >> Hi. >> Here is an example: >> http://vm2.dashif.org/livesim-dev/testpic_2s/Manifest.mpd >> >> ffplay http://vm2.dashif.org/livesim-dev/testpic_2s/Manifest.mpd >> ffplay version N-91650-g6972dae5a4 Copyright (c) 2003-2018 the FFmpeg >> developers >> built with gcc 8.2.0 (Gentoo 8.2.0-r2 p1.2) >> configuration: --prefix=/mnt/BIG/ffmpeg/root/ --disable-doc >> --disable-stripping --enable-debug=1 --enable-libxml2 --enable-demuxer=dash >> --enable-openssl >> libavutil 56. 19.100 / 56. 19.100 >> libavcodec 58. 24.100 / 58. 24.100 >> libavformat58. 17.103 / 58. 17.103 >> libavdevice58. 4.101 / 58. 4.101 >> libavfilter 7. 26.100 / 7. 26.100 >> libswscale 5. 2.100 / 5. 2.100 >> libswresample 3. 2.100 / 3. 2.100 >> [dash @ 0x7ffa8c000b80] Could not read complete fragment.0B f=0/0 >> [dash @ 0x7ffa8c000b80] Could not read complete fragment.0B f=0/0 >> Input #0, dash, from ' >> http://vm2.dashif.org/livesim-dev/testpic_2s/Manifest.mpd': >> Duration: N/A, start: 1534854670.016000, bitrate: N/A >> Program 0 >> Stream #0:0: Video: h264 (High) (avc1 / 0x31637661), yuv420p, 640x360, >> 30 fps, 30 tbr, 90k tbn, 60 tbc >> Metadata: >> variant_bitrate : 30 >> id : V300 >> Stream #0:1: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp >> Metadata: >> variant_bitrate : 48000 >> id : A48 >> [http @ 0x7ffa8c073fc0] HTTP error 404 Not Found 10KB sq=0B f=0/0 >> [dash @ 0x7ffa8c000b80] Failed to open fragment of playlist 0 >> [http @ 0x7ffa8c074780] HTTP error 404 Not Found6KB sq=0B f=0/0 >> [dash @ 0x7ffa8c000b80] Failed to open fragment of playlist 0 >> [http @ 0x7ffa8c236200] HTTP error 404 Not Found0KB sq=0B f=0/0 >> [dash @ 0x7ffa8c000b80] Failed to open fragment of playlist 0 >> [http @ 0x7ffa8c32d940] HTTP error 404 Not Found0KB sq=0B f=0/0 >> [dash @ 0x7ffa8c000b80] Failed to open fragment of playlist 0 >> [http @ 0x7ffa8c086000] HTTP error 404 Not Found0KB sq=0B f=0/0 >> [dash @ 0x7ffa8c000b80] Failed to open fragment of playlist 0 >> [http @ 0x7ffa8c2312c0] HTTP error 404 Not Found0KB sq=0B f=0/0 >> [dash @ 0x7ffa8c000b80] Failed to open fragment of playlist 0 >> [http @ 0x7ffa8c2312c0] HTTP error 404 Not Found0KB sq=0B f=0/0 >> [dash @ 0x7ffa8c000b80] Failed to open fragment of playlist 0 >> [http @ 0x7ffa8c2312c0] HTTP error 404 Not Found0KB sq=0B f=0/0 >> <0001-Fix-calc_cur_seg_no-if-availability_start_time-no.patch>___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > LGTM > Pushed > Thanks > Steven > > > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/dashdec: Add a re-entrance check point after an interrupt operation
> 在 2018年8月9日，上午2:09，Colin NG 写道：
>
> ---
> libavformat/dashdec.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 5730252..310dc20 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -1764,6 +1764,12 @@ static int reopen_demux_for_component(AVFormatContext
> *s, struct representation
> if (pls->ctx) {
> close_demux_for_component(pls);
> }
> +
> +if (ff_check_interrupt(&s->interrupt_callback)) {
> +ret = AVERROR_EXIT;
> +goto fail;
> +}
> +
> if (!(pls->ctx = avformat_alloc_context())) {
> ret = AVERROR(ENOMEM);
> goto fail;
> --
> 2.7.4
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
pushed
Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
