[FFmpeg-devel] [PATCH] refine the method option describe of hlsenc doc
refine the grammar of patch
Thanks for Moritz Barsnick reviewed!
Signed-off-by: LiuQi
Reviewed-by: Moritz Barsnick
---
doc/muxers.texi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 15b63f4..1b99c7e 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -508,6 +508,17 @@ Emit @code{#EXT-X-PLAYLIST-TYPE:EVENT} in the m3u8
header. Forces
@item hls_playlist_type vod
Emit @code{#EXT-X-PLAYLIST-TYPE:VOD} in the m3u8 header. Forces
@option{hls_list_size} to 0; the playlist must not change.
+
+@item method
+Use the given HTTP method to create the hls files.
+@example
+ffmpeg -re -i in.ts -f hls -method PUT http://example.com/live/out.m3u8
+@end example
+This example will upload all the mpegts segment files to the HTTP
+server using the HTTP PUT method, and update the m3u8 files every
+@code{refresh} times using the same method.
+Note that the HTTP server must support the given method for uploading
+files.
@end table
@anchor{ico}
--
2.7.4 (Apple Git-66)
0001-refine-the-method-option-describe-of-hlsenc-doc.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavf/img2: Remove ffv1-img
Hi!
Attached patch removes a line from img2.c, afaict the ffv1 format
cannot be used without a container, at least it doesn't work with
current (and very old) FFmpeg.
Carl Eugen
From 1ca907a8009ae87f728b10be83602f355230cfd6 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Wed, 13 Jul 2016 11:06:59 +0200
Subject: [PATCH] lavf/img2: Remove ffv1-img, the format requires a container.
---
libavformat/img2.c |1 -
1 file changed, 1 deletion(-)
diff --git a/libavformat/img2.c b/libavformat/img2.c
index 0f6f75c..f9f53ff 100644
--- a/libavformat/img2.c
+++ b/libavformat/img2.c
@@ -45,7 +45,6 @@ const IdStrMap ff_img_tags[] = {
{ AV_CODEC_ID_MPEG1VIDEO, "mpg1-img" },
{ AV_CODEC_ID_MPEG2VIDEO, "mpg2-img" },
{ AV_CODEC_ID_MPEG4, "mpg4-img" },
-{ AV_CODEC_ID_FFV1, "ffv1-img" },
{ AV_CODEC_ID_RAWVIDEO, "y"},
{ AV_CODEC_ID_RAWVIDEO, "raw" },
{ AV_CODEC_ID_BMP,"bmp" },
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] what's the general setting for network reading and writing?
Hi, If input or output is set to file, it's easy to set AVFormatContext. But for network application, there are many issues that should be considered, such as network delay, no network connection, and corrupted data. How to set AVFormatContext to deal with those general network issues? Thanks! Regards Andrew ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fwd: [PATCH] Automatically inserted bitstream filter 'h264_mp4toannexb' into hlsenc
On Wed, Jun 29, 2016 at 01:07:13AM +0200, Hendrik Leppkes wrote: > On Wed, Jun 29, 2016 at 12:30 AM, Steven Liu wrote: > > > > > > 2016-06-29 0:16 GMT+08:00 Hendrik Leppkes : > >> > >> On Tue, Jun 28, 2016 at 3:29 PM, Steven Liu > >> wrote: > >> > before patched: > >> > [root@localhost ffmpeg]# ./ffmpeg_g -re -i /root/facebook.mp4 -c copy -f > >> > hls -v verbose -y .m3u8 > >> > ffmpeg version N-80779-gb18d6c5 Copyright (c) 2000-2016 the FFmpeg > >> > developers > >> > >> > >> The way I see it, the auto bsf from the mpegts muxer should already > >> cover this without changes? > > > > > > add the hls_check_bitstream into hls format and call the hls->avf to call > > the mpegtsenc's check_bitstream, > > don't do this operation, it won't call the mpegtsenc's check_bitstream, > > look at the message bellow: > > > > This is the wrong approach to fixing this however, it should be > understood first why its not doing this transparently right now. > hlsenc uses the mpegts muxer like one would use any other muxer, so > why does autobsf not get used? > > If we understand that, maybe it can be fixed in a more generic way, > and not end up in ugly hacks in hlsenc. The issue is that hlsenc does call ff_write_chained() which causes av_write_frame() instead of av_interleaved_write_frame() to be used, bypassing the current auto bsf code Using av_interleaved_write_frame() would, i assume introduce a delay The patch doesnt work either, for example this: ./ffmpeg -i matrixbench_mpeg2.mpg -i fate-suite/sub/MovText_capability_tester.mp4 -f hls file.m3u8 segfaults [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][WIP] avfilter: add libebur128 port
On Mon, Jun 27, 2016 at 11:14:45AM -0500, Kyle Swanson wrote: > On Sun, Jun 19, 2016 at 2:17 AM, Kyle Swanson wrote: > > Hi, > > > > af_loudnorm currently links libebur128. The port makes sense because > > libebur128 is tiny, MIT-licensed, has a good API, and would be useful > > in several filters. Perceptual loudness has become an important topic > > in broadcasting and audio in general, and it'd be nice to provide > > these filters to everybody without having to link an external library. > > > > FFmpeg already has some ebur128 logic in f_ebur128, which I was > > initially interested in breaking out into something reusable, but > > found libebur128 was better suited for this. This was discussed last > > month when the loudnorm filter was pushed, and also with the > > expectation that libebur128 would be ported to FFmpeg. Briefly, > > libebur128 allows several modes of measurement, custom channel > > mappings, doesn't require resampling the input stream, is faster, and > > has a reusable API. > > > > Thanks, > > Kyle > > > > Hi, > > I'm still not clear if I should pursue this or not, I've received > `yes` and `no` from both sides on this issue. Has this been resolved ? Is there a maintainer under whos area this falls ? If not then you could ask teh vote comittee to make a decission I think we do not have a formal process for that but a mail asking for a discussion and then vote and clear explanation what the vote is about should work ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Avoid sending packets to network when multicast ttl is 0 in udp
I attached the patch.
The actual bug is, when creating a local multicast stream (i.e. giving
"rtp://224.1.1.1:1?ttl=0" to avio_open), then you can see the
packets on the network and not just on local machine (despite setting
multicast ttl to 0) which was a security bug in my purpose of usage
(it also made a lot of unused traffic on network)
The user does not choose to enable/disable the kernel hack, that is
how it is designed.
This behavior does NOT happen in Windows machines, but the patch given
does no harm at all (it does nothing in Windows)
On Wed, Jul 13, 2016 at 3:12 AM, Moritz Barsnick wrote:
> On Tue, Jul 12, 2016 at 18:31:36 +0430, Omid Ghaffarinia wrote:
>
> Your mailer has broken the patch by inserting line breaks. You should
> try attaching the patch as a file, or directly using "git send-email".
>
>> Bug is due to kernel handling multicast ttl 0 differently (as noted in
>> kernel code net/ipv4/route.c:2191 see:
>
> ffmpeg is not a Linux-only tool/library, so comments should point out
> which "kernel" more precisely (and possibly which versions this applies
> to). Admitted, the link to github contains the string "linux". ;-)
>
> Furthermore: Please explain what the actual bug (i.e. misbehavior) is,
> and what this fix changes (or how it fixes it).
>
> Are you allowing ffmpeg to work when the user is making use of the
> kernel hack?
>
> What does this patch achieve on non-Linux operating systems?
>
> (Sorry for the stupid questions, all this isn't obvious to me, and I do
> have at least some understanding of network stuff.)
>
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
From aab1658d011f5b3eabd22ddc30f40107c6311c92 Mon Sep 17 00:00:00 2001
From: Omid Ghaffarinia
Date: Tue, 12 Jul 2016 18:23:57 +0430
Subject: [PATCH] Avoid sending packets to network when multicast ttl is 0 in
udp
Signed-off-by: Omid Ghaffarinia
---
libavformat/sdp.c |2 +-
libavformat/udp.c | 28
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/libavformat/sdp.c b/libavformat/sdp.c
index 01b564b..0401f7a 100644
--- a/libavformat/sdp.c
+++ b/libavformat/sdp.c
@@ -61,7 +61,7 @@ static void sdp_write_address(char *buff, int size, const char *dest_addr,
if (dest_addr) {
if (!dest_type)
dest_type = "IP4";
-if (ttl > 0 && !strcmp(dest_type, "IP4")) {
+if (ttl >= 0 && !strcmp(dest_type, "IP4")) {
/* The TTL should only be specified for IPv4 multicast addresses,
* not for IPv6. */
av_strlcatf(buff, size, "c=IN %s %s/%d\r\n", dest_type, dest_addr, ttl);
diff --git a/libavformat/udp.c b/libavformat/udp.c
index 8699c1c..fe46ba5 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -176,6 +176,28 @@ static int udp_set_multicast_ttl(int sockfd, int mcastTTL,
}
}
#endif
+if (mcastTTL == 0) {
+#ifdef IP_MULTICAST_IF
+if (addr->sa_family == AF_INET) {
+struct in_addr localhost_addr;
+inet_pton(AF_INET, "127.0.0.1", &localhost_addr);
+if (setsockopt(sockfd, IPPROTO_IP, IP_MULTICAST_IF, &localhost_addr, sizeof(localhost_addr)) < 0) {
+log_net_error(NULL, AV_LOG_ERROR, "setsockopt(IP_MULTICAST_IF)");
+return -1;
+}
+}
+#endif
+#if defined(IPPROTO_IPV6) && defined(IPV6_MULTICAST_IF)
+if (addr->sa_family == AF_INET6) {
+struct in6_addr localhost_addr;
+inet_pton(AF_INET6, "::1", &localhost_addr);
+if (setsockopt(sockfd, IPPROTO_IPV6, IPV6_MULTICAST_IF, &localhost_addr, sizeof(localhost_addr)) < 0) {
+log_net_error(NULL, AV_LOG_ERROR, "setsockopt(IPV6_MULTICAST_IF)");
+return -1;
+}
+}
+#endif
+}
return 0;
}
@@ -882,6 +904,12 @@ static int udp_open(URLContext *h, const char *uri, int flags)
}
if (h->flags & AVIO_FLAG_READ) {
/* input */
+ if (s->ttl == 0) {
+ if (s->dest_addr.ss_family == AF_INET)
+ inet_pton(AF_INET, "127.0.0.1", &((struct sockaddr_in *)&s->local_addr_storage)->sin_addr);
+ else
+ inet_pton(AF_INET6, "::1", &((struct sockaddr_in6 *)&s->local_addr_storage)->sin6_addr);
+ }
if (num_include_sources && num_exclude_sources) {
av_log(h, AV_LOG_ERROR, "Simultaneously including and excluding multicast sources is not supported\n");
goto fail;
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/7] avformat/tee: Use ff_stream_encode_params_copy()
On 07/13/2016 12:56 PM, Jan Sebechlebsky wrote: On 07/12/2016 10:23 AM, Nicolas George wrote: Le quartidi 24 messidor, an CCXXIV, Jan Sebechlebsky a écrit : I think it is used in decoding only - the documentation of AVStream mentions only decoding and I also tried to search references to that field if it is not used in some of the muxers. If you think it should be copied too I will add it. If you have checked it was never used in muxers, then ok. But you may want to have a look at the "MKV Header: Writing duration early" mail that arrived a few minutes ago. Regards, I think we can safely omit it, it's not used in any current muxers. Soft Works contributors may use duration field in muxing context, I think they (or we) can then add copying of this field to ff_stream_encode_params_copy with their patch . The documentation of the field should be then modified as well. Regards, Jan Resending this to mailing list - sorry I've accidentally replied privately again. Regards, Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fwd: [PATCH] Automatically inserted bitstream filter 'h264_mp4toannexb' into hlsenc
2016-07-13 18:28 GMT+08:00 Michael Niedermayer : > On Wed, Jun 29, 2016 at 01:07:13AM +0200, Hendrik Leppkes wrote: > > On Wed, Jun 29, 2016 at 12:30 AM, Steven Liu > wrote: > > > > > > > > > 2016-06-29 0:16 GMT+08:00 Hendrik Leppkes : > > >> > > >> On Tue, Jun 28, 2016 at 3:29 PM, Steven Liu > > >> wrote: > > >> > before patched: > > >> > [root@localhost ffmpeg]# ./ffmpeg_g -re -i /root/facebook.mp4 -c > copy -f > > >> > hls -v verbose -y .m3u8 > > >> > ffmpeg version N-80779-gb18d6c5 Copyright (c) 2000-2016 the FFmpeg > > >> > developers > > >> > > >> > > >> The way I see it, the auto bsf from the mpegts muxer should already > > >> cover this without changes? > > > > > > > > > add the hls_check_bitstream into hls format and call the hls->avf to > call > > > the mpegtsenc's check_bitstream, > > > don't do this operation, it won't call the mpegtsenc's > check_bitstream, > > > look at the message bellow: > > > > > > > This is the wrong approach to fixing this however, it should be > > understood first why its not doing this transparently right now. > > hlsenc uses the mpegts muxer like one would use any other muxer, so > > why does autobsf not get used? > > > > If we understand that, maybe it can be fixed in a more generic way, > > and not end up in ugly hacks in hlsenc. > > The issue is that hlsenc does call ff_write_chained() which causes > av_write_frame() instead of av_interleaved_write_frame() to be used, > bypassing the current auto bsf code > > Using av_interleaved_write_frame() would, i assume introduce a delay > > The patch doesnt work either, for example this: > ./ffmpeg -i matrixbench_mpeg2.mpg -i > fate-suite/sub/MovText_capability_tester.mp4 -f hls file.m3u8 > > segfaults > > Hi Michael, Can you upload the matrixbench_mpeg2.mpg and fate-suite/sub/MovText_capability_tester.mp4? Let me test and fix it! It's ok here: localhost:ffmpeg liuqi$ ./ffmpeg -i ~/Movies/objectC/xxx.mpg -i ~/Movies/objectC/facebook.mp4 -f hls testtest.m3u8 ffmpeg version N-80982-g151479e Copyright (c) 2000-2016 the FFmpeg developers built with Apple LLVM version 7.3.0 (clang-703.0.31) configuration: --enable-libass --enable-libfaac --enable-libmp3lame --enable-libx264 --enable-libopencv --enable-gpl --enable-nonfree libavutil 55. 28.100 / 55. 28.100 libavcodec 57. 50.100 / 57. 50.100 libavformat57. 41.100 / 57. 41.100 libavdevice57. 0.102 / 57. 0.102 libavfilter 6. 47.100 / 6. 47.100 libswscale 4. 1.100 / 4. 1.100 libswresample 2. 1.100 / 2. 1.100 libpostproc54. 0.100 / 54. 0.100 Input #0, mpeg, from '/Users/liuqi/Movies/objectC/xxx.mpg': Duration: 00:45:45.57, start: 0.529978, bitrate: 833 kb/s Stream #0:0[0x1e0]: Video: mpeg1video, yuv420p(tv), 720x528 [SAR 1:1 DAR 15:11], 104857 kb/s, 25 fps, 25 tbr, 90k tbn, 25 tbc Stream #0:1[0x1c0]: Audio: mp2, 48000 Hz, stereo, s16p, 384 kb/s Input #1, mov,mp4,m4a,3gp,3g2,mj2, from '/Users/liuqi/Movies/objectC/facebook.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf57.34.103 Duration: 00:45:45.64, start: 0.00, bitrate: 1530 kb/s Stream #1:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 720x528 [SAR 1:1 DAR 15:11], 1141 kb/s, 25 fps, 25 tbr, 16k tbn, 50 tbc (default) Metadata: handler_name: VideoHandler Stream #1:1(und): Audio: ac3 (ac-3 / 0x332D6361), 48000 Hz, 5.1(side), fltp, 384 kb/s (default) Metadata: handler_name: SoundHandler Side data: audio service type: main [libx264 @ 0x7f98090e6a00] using SAR=1/1 [libx264 @ 0x7f98090e6a00] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX [libx264 @ 0x7f98090e6a00] profile High, level 3.0 [hls @ 0x7f980900f400] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead. Last message repeated 1 times Output #0, hls, to 'testtest.m3u8': Metadata: encoder : Lavf57.41.100 Stream #0:0: Video: h264 (libx264), yuv420p, 720x528 [SAR 1:1 DAR 15:11], q=-1--1, 25 fps, 90k tbn, 25 tbc Metadata: encoder : Lavc57.50.100 libx264 Side data: cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1 Stream #0:1(und): Audio: aac (LC), 48000 Hz, 5.1(side), fltp, 341 kb/s (default) Metadata: handler_name: SoundHandler encoder : Lavc57.50.100 aac Stream mapping: Stream #0:0 -> #0:0 (mpeg1video (native) -> h264 (libx264)) Stream #1:1 -> #0:1 (ac3 (native) -> aac (native)) Press [q] to stop, [?] for help frame= 678 fps= 97 q=-1.0 Lsize=N/A time=00:00:27.00 bitrate=N/A speed=3.86x video:2479kB audio:1043kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown [libx264 @ 0x7f98090e6a00] frame I:9 Avg QP:17.37 size: 22063 [libx264 @ 0x7f98090e6a00] frame P:561 Avg QP:22.20 size: 3959 [libx264 @ 0x7f98090e6a00] frame B:108 Avg QP:25.34 size: 1097
Re: [FFmpeg-devel] Fwd: [PATCH] Automatically inserted bitstream filter 'h264_mp4toannexb' into hlsenc
On Wed, Jul 13, 2016 at 07:22:52PM +0800, Steven Liu wrote: > 2016-07-13 18:28 GMT+08:00 Michael Niedermayer : > > > On Wed, Jun 29, 2016 at 01:07:13AM +0200, Hendrik Leppkes wrote: > > > On Wed, Jun 29, 2016 at 12:30 AM, Steven Liu > > wrote: > > > > > > > > > > > > 2016-06-29 0:16 GMT+08:00 Hendrik Leppkes : > > > >> > > > >> On Tue, Jun 28, 2016 at 3:29 PM, Steven Liu > > > >> wrote: > > > >> > before patched: > > > >> > [root@localhost ffmpeg]# ./ffmpeg_g -re -i /root/facebook.mp4 -c > > copy -f > > > >> > hls -v verbose -y .m3u8 > > > >> > ffmpeg version N-80779-gb18d6c5 Copyright (c) 2000-2016 the FFmpeg > > > >> > developers > > > >> > > > >> > > > >> The way I see it, the auto bsf from the mpegts muxer should already > > > >> cover this without changes? > > > > > > > > > > > > add the hls_check_bitstream into hls format and call the hls->avf to > > call > > > > the mpegtsenc's check_bitstream, > > > > don't do this operation, it won't call the mpegtsenc's > > check_bitstream, > > > > look at the message bellow: > > > > > > > > > > This is the wrong approach to fixing this however, it should be > > > understood first why its not doing this transparently right now. > > > hlsenc uses the mpegts muxer like one would use any other muxer, so > > > why does autobsf not get used? > > > > > > If we understand that, maybe it can be fixed in a more generic way, > > > and not end up in ugly hacks in hlsenc. > > > > The issue is that hlsenc does call ff_write_chained() which causes > > av_write_frame() instead of av_interleaved_write_frame() to be used, > > bypassing the current auto bsf code > > > > Using av_interleaved_write_frame() would, i assume introduce a delay > > > > The patch doesnt work either, for example this: > > ./ffmpeg -i matrixbench_mpeg2.mpg -i > > fate-suite/sub/MovText_capability_tester.mp4 -f hls file.m3u8 > > > > segfaults > > > > > Hi Michael, > >Can you upload the matrixbench_mpeg2.mpg and > fate-suite/sub/MovText_capability_tester.mp4? Let me test and fix it! > http://samples.ffmpeg.org/benchmark/testsuite1/matrixbench_mpeg2.mpg http://fate-suite.ffmpeg.org/sub/MovText_capability_tester.mp4 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fwd: [PATCH] Automatically inserted bitstream filter 'h264_mp4toannexb' into hlsenc
On Wed, Jul 13, 2016 at 12:28 PM, Michael Niedermayer wrote: > On Wed, Jun 29, 2016 at 01:07:13AM +0200, Hendrik Leppkes wrote: >> On Wed, Jun 29, 2016 at 12:30 AM, Steven Liu wrote: >> > >> > >> > 2016-06-29 0:16 GMT+08:00 Hendrik Leppkes : >> >> >> >> On Tue, Jun 28, 2016 at 3:29 PM, Steven Liu >> >> wrote: >> >> > before patched: >> >> > [root@localhost ffmpeg]# ./ffmpeg_g -re -i /root/facebook.mp4 -c copy -f >> >> > hls -v verbose -y .m3u8 >> >> > ffmpeg version N-80779-gb18d6c5 Copyright (c) 2000-2016 the FFmpeg >> >> > developers >> >> >> >> >> >> The way I see it, the auto bsf from the mpegts muxer should already >> >> cover this without changes? >> > >> > >> > add the hls_check_bitstream into hls format and call the hls->avf to call >> > the mpegtsenc's check_bitstream, >> > don't do this operation, it won't call the mpegtsenc's check_bitstream, >> > look at the message bellow: >> > >> >> This is the wrong approach to fixing this however, it should be >> understood first why its not doing this transparently right now. >> hlsenc uses the mpegts muxer like one would use any other muxer, so >> why does autobsf not get used? >> >> If we understand that, maybe it can be fixed in a more generic way, >> and not end up in ugly hacks in hlsenc. > > The issue is that hlsenc does call ff_write_chained() which causes > av_write_frame() instead of av_interleaved_write_frame() to be used, > bypassing the current auto bsf code > > Using av_interleaved_write_frame() would, i assume introduce a delay > Maybe we should re-factor this BSF logic into a shareable function and make both av_write_frame and av_interleaved_write_frame use it then, instead of adding it to hlsenc (and after that even more playlist-muxers like dash, segment, etc) - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/exr : rename variable in b44_uncompress func
On Sun, Jun 26, 2016 at 10:33:50PM +0200, Martin Vignali wrote: > Hello, > > in attach patch to rename variables use in b44_uncompress func > to be more consistent, to the rest of ffmpeg code. > > also rename variable who was incorrectly named (named from french word). > indexHG_x -> index_tl_x (tl for top left) > > > pass exr fate-tests > > > Martin > Jokyo Images > exr.c | 66 > +- > 1 file changed, 33 insertions(+), 33 deletions(-) > 77b1f2cfaea1f1617bbb865405e159b793b097c8 > 0001-libavcodec-exr-cosmetics-rename-variable-in-b44_unco.patch > From ca4c7f2ce8ffdb5b8bb166e2a7d792f5451c3b89 Mon Sep 17 00:00:00 2001 > From: Martin Vignali > Date: Sun, 26 Jun 2016 22:27:37 +0200 > Subject: [PATCH] libavcodec/exr : cosmetics, rename variable in b44_uncompress > func applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat: Add FIFO pseudo-muxer
On 07/12/2016 10:28 AM, Nicolas George wrote:
Le quintidi 25 messidor, an CCXXIV, Marton Balint a écrit :
The fifo muxer never returns EAGAIN. It silently drops the packets in
non-blocking mode on a full queue. This behaviour is useful for the tee
muxer case, when you don't want one slow/unreliable (network) output to
block reading the input, therefore blocking fast outputs (disk) as well.
Wait a minute. This is way to specific to be the default behaviour, let
alone the only one.
As far as I know, in the current API, if the user gets a negative return
value from av_write_frame(), it should be handled as a fatal error. EAGAIN
is not handled/interpreted specially. The same is true for
av_write_trailer(), and calling av_write_trailer - regardless of the return
value - frees all private resources for the context as well, so you cannot
change the semantics of av_write_trailer to not free private data in case of
EAGAIN, because it would cause unfreed data for legacy users.
You are wrong. Returning EAGAIN so that the caller try again later is the
normal behaviour for muxers that support non-blocking operation. I grant you
that there are only between one and three of them, but still, that is how
they work.
And that is also how they are supposed to work, because that is how
non-blocking protocols work, and also how non-blocking works outside FFmpeg.
If you take a look at av_write_trailer it really frees all the resources
in case
of any error. There is also no other way in API to free the resources
associated
with AVFormatContext, than through
av_write_trailer.
I was able to find two muxers which support AVFMT_FLAG_NONBLOCK -
v4l2enc.c
and pulse_audio_enc.c. Neither of these two can return EAGAIN from
write_trailer_call.
Write trailer of v4l2enc.c contains simple close() call and always
returns 0.
The pulse audio muxer is however similar to FIFO muxer, the
mainloop of the pulse audio is
being run in separate thread. If you take a look at the write_trailer of
pulse audio muxer (also always returns 0):
static av_cold int pulse_write_trailer(AVFormatContext *h)
{
PulseData *s = h->priv_data;
if (s->mainloop) {
...
pa_threaded_mainloop_unlock(s->mainloop);
pa_threaded_mainloop_stop(s->mainloop);
pa_threaded_mainloop_free(s->mainloop);
s->mainloop = NULL;
}
return 0;
}
pa_threaded_mainloop_stop() contains:
void pa_threaded_mainloop_stop(pa_threaded_mainloop *m) {
...
pa_thread_join(m->thread);
}
So I guess the write_trailer call of pulse audio muxer should be
considered blocking too - even when AVFMT_FLAG_NONBLOCK flag is set.
I guess I could implement non-blocking calls in FIFO muxer:
- block_on_overflow should be renamed to something like
drop_packets_on_overflow
to prevent confusion...
- av_write_trailer would have to be modified not to free resources on
AVERROR(EAGAIN)
- separate API function for freeing AVOuputContext resources would have
to be created,
let's say av_format_deinit(AVFormatContext *).
- FIFO muxer would behave the same way as currently in case
AVFMT_FLAG_NONBLOCK
would be unset.
- In case AVFMT_FLAG_NONBLOCK would be set:
- write_packet would return AVERROR(EAGAIN) in case the queue is
full if
drop_packets_on_overflow was not set. If it was, it would drop
packet, request queue flushing
and return 0
- write_trailer would check if the thread is still running. If yes
write_trailer request would be send
(if it was not yet send) and AVERROR(EAGAIN) returned.
- original interrupt callback would be wrapped by custom one which
would check terminating condition
(flag) of FIFO first and if it would be not set, it would call
the original callback.
- deinit function would be modified so it would check if the thread
is still running, if it was, terminating
condition would be set, and pthread_join called, then resources
would be freed. This can be also implemented
in with use of condition variable which would be set at the
moment when the thread is exiting and checked
with pthread_cond_wait_timeout before pthread_join. If the time
out would be reached, thread would be
canceled - but canceling the thread by force can introduce many
problems.
I can implement it, but I'm really in doubt if it is worth increased code
complexity and more risky situations which could happen, so I would
prefer not to :)
Regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 1/7] avformat/utils: Add ff_stream_encode_params_copy()
From: Jan Sebechlebsky
Signed-off-by: Jan Sebechlebsky
---
Chanages from the last version of patch:
-> dst->metadata dictionary is freed before entries are copied from
src->metadata
libavformat/internal.h | 9
libavformat/utils.c| 57 ++
2 files changed, 66 insertions(+)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 647ad65..1b44bea 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -491,6 +491,15 @@ int ff_generate_avci_extradata(AVStream *st);
int ff_stream_add_bitstream_filter(AVStream *st, const char *name, const char
*args);
/**
+ * Copy encoding parameters from source to destination stream
+ *
+ * @param dst pointer to destination AVStream
+ * @param src pointer to source AVStream
+ * @return >=0 on success, AVERROR code on error
+ */
+int ff_stream_encode_params_copy(AVStream *dst, const AVStream *src);
+
+/**
* Wrap errno on rename() error.
*
* @param oldpath source path
diff --git a/libavformat/utils.c b/libavformat/utils.c
index d2a709c..f2b0e6e 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -3951,6 +3951,63 @@ int av_read_pause(AVFormatContext *s)
return AVERROR(ENOSYS);
}
+int ff_stream_encode_params_copy(AVStream *dst, const AVStream *src)
+{
+int ret, i;
+
+dst->id = src->id;
+dst->time_base = src->time_base;
+dst->nb_frames = src->nb_frames;
+dst->disposition = src->disposition;
+dst->sample_aspect_ratio = src->sample_aspect_ratio;
+dst->avg_frame_rate = src->avg_frame_rate;
+dst->r_frame_rate= src->r_frame_rate;
+
+av_dict_free(&dst->metadata);
+ret = av_dict_copy(&dst->metadata, src->metadata, 0);
+if (ret < 0)
+return ret;
+
+ret = avcodec_parameters_copy(dst->codecpar, src->codecpar);
+if (ret < 0)
+return ret;
+
+/* Free existing side data*/
+for (i = 0; i < dst->nb_side_data; i++)
+av_free(dst->side_data[i].data);
+av_freep(&dst->side_data);
+dst->nb_side_data = 0;
+
+/* Copy side data if present */
+if (src->nb_side_data) {
+dst->side_data = av_mallocz_array(src->nb_side_data,
+ sizeof(AVPacketSideData));
+if (!dst->side_data)
+return AVERROR(ENOMEM);
+dst->nb_side_data = src->nb_side_data;
+
+for (i = 0; i < src->nb_side_data; i++) {
+uint8_t *data = av_memdup(src->side_data[i].data,
+ src->side_data[i].size);
+if (!data)
+return AVERROR(ENOMEM);
+dst->side_data[i].type = src->side_data[i].type;
+dst->side_data[i].size = src->side_data[i].size;
+dst->side_data[i].data = data;
+}
+}
+
+av_freep(&dst->recommended_encoder_configuration);
+if (src->recommended_encoder_configuration) {
+const char *conf_str = src->recommended_encoder_configuration;
+dst->recommended_encoder_configuration = av_strdup(conf_str);
+if (!dst->recommended_encoder_configuration)
+return AVERROR(ENOMEM);
+}
+
+return 0;
+}
+
static void free_stream(AVStream **pst)
{
AVStream *st = *pst;
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: fix fate-vp8 dependencies
On 7/13/2016 3:09 AM, Hendrik Leppkes wrote: > On Wed, Jul 13, 2016 at 6:05 AM, James Almer wrote: >> Fix the demuxer dependencies in some of the tests and remove the vp8 decoder >> dependency for the stream copy tests >> > > I assume you actually tested those without the decoder? Some codecs > like to act a bit odd when the decoder can't provide extra > information. Yeah, they pass. > If yes, then LGTM. Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fwd: [PATCH] Automatically inserted bitstream filter 'h264_mp4toannexb' into hlsenc
2016-07-13 19:35 GMT+08:00 Michael Niedermayer : > On Wed, Jul 13, 2016 at 07:22:52PM +0800, Steven Liu wrote: > > 2016-07-13 18:28 GMT+08:00 Michael Niedermayer : > > > > > On Wed, Jun 29, 2016 at 01:07:13AM +0200, Hendrik Leppkes wrote: > > > > On Wed, Jun 29, 2016 at 12:30 AM, Steven Liu < > lingjiujia...@gmail.com> > > > wrote: > > > > > > > > > > > > > > > 2016-06-29 0:16 GMT+08:00 Hendrik Leppkes : > > > > >> > > > > >> On Tue, Jun 28, 2016 at 3:29 PM, Steven Liu < > lingjiujia...@gmail.com> > > > > >> wrote: > > > > >> > before patched: > > > > >> > [root@localhost ffmpeg]# ./ffmpeg_g -re -i /root/facebook.mp4 > -c > > > copy -f > > > > >> > hls -v verbose -y .m3u8 > > > > >> > ffmpeg version N-80779-gb18d6c5 Copyright (c) 2000-2016 the > FFmpeg > > > > >> > developers > > > > >> > > > > >> > > > > >> The way I see it, the auto bsf from the mpegts muxer should > already > > > > >> cover this without changes? > > > > > > > > > > > > > > > add the hls_check_bitstream into hls format and call the hls->avf > to > > > call > > > > > the mpegtsenc's check_bitstream, > > > > > don't do this operation, it won't call the mpegtsenc's > > > check_bitstream, > > > > > look at the message bellow: > > > > > > > > > > > > > This is the wrong approach to fixing this however, it should be > > > > understood first why its not doing this transparently right now. > > > > hlsenc uses the mpegts muxer like one would use any other muxer, so > > > > why does autobsf not get used? > > > > > > > > If we understand that, maybe it can be fixed in a more generic way, > > > > and not end up in ugly hacks in hlsenc. > > > > > > The issue is that hlsenc does call ff_write_chained() which causes > > > av_write_frame() instead of av_interleaved_write_frame() to be used, > > > bypassing the current auto bsf code > > > > > > Using av_interleaved_write_frame() would, i assume introduce a delay > > > > > > The patch doesnt work either, for example this: > > > ./ffmpeg -i matrixbench_mpeg2.mpg -i > > > fate-suite/sub/MovText_capability_tester.mp4 -f hls file.m3u8 > > > > > > segfaults > > > > > > > > Hi Michael, > > > >Can you upload the matrixbench_mpeg2.mpg and > > fate-suite/sub/MovText_capability_tester.mp4? Let me test and fix it! > > > > http://samples.ffmpeg.org/benchmark/testsuite1/matrixbench_mpeg2.mpg > http://fate-suite.ffmpeg.org/sub/MovText_capability_tester.mp4 > > Hi Michael, I have fixed the segfaults, the segfaults is webvtt subtitle stream check_bitstream by the mpegts, so check the conditions before the oc->oformat->check_bitstream(), then fixed it. but i have a question, when i using the ./tools/patcheck, the patcheck give me the message: These functions may need av_cold, please review the whole patch for similar functions needing av_cold 0001-Automatically-inserted-bitstream-filter-h264_mp4toan.patch:30:+static int hls_write_header_init(AVFormatContext *s) How can i fix it in patch? after the patch: localhost:test_movie StevenLiu$ ../ffmpeg/ffmpeg -i ./matrixbench_mpeg2.mpg -i ./MovText_capability_tester.mp4 -f hls file.m3u8 ffmpeg version N-80961-g4f0e388 Copyright (c) 2000-2016 the FFmpeg developers built with Apple LLVM version 7.3.0 (clang-703.0.31) configuration: --enable-libass --enable-opengl --enable-libx264 --enable-libmp3lame --enable-gpl --enable-libfaac --enable-nonfree --prefix=/usr/local --enable-libopencv --enable-libtesseract --enable-libspeex libavutil 55. 28.100 / 55. 28.100 libavcodec 57. 50.100 / 57. 50.100 libavformat57. 41.100 / 57. 41.100 libavdevice57. 0.102 / 57. 0.102 libavfilter 6. 47.100 / 6. 47.100 libswscale 4. 1.100 / 4. 1.100 libswresample 2. 1.100 / 2. 1.100 libpostproc54. 0.100 / 54. 0.100 [mpeg @ 0x7f94a200aa00] start time for stream 0 is not set in estimate_timings_from_pts Input #0, mpeg, from './matrixbench_mpeg2.mpg': Duration: 00:03:07.66, start: 0.22, bitrate: 5633 kb/s Stream #0:0[0x1bf]: Data: dvd_nav_packet Stream #0:1[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, bt470bg/bt470m/bt470m), 720x576 [SAR 16:15 DAR 4:3], 25 fps, 25 tbr, 90k tbn, 50 tbc Stream #0:2[0x1c0]: Audio: mp2, 48000 Hz, stereo, s16p, 384 kb/s Input #1, mov,mp4,m4a,3gp,3g2,mj2, from './MovText_capability_tester.mp4': Metadata: major_brand : isom minor_version : 1 compatible_brands: isom creation_time : 2012-07-04 05:10:41 Duration: 00:00:08.14, bitrate: 0 kb/s Stream #1:0(und): Subtitle: mov_text (tx3g / 0x67337874), 400x60, 0 kb/s (default) Metadata: creation_time : 2012-07-04 05:10:41 handler_name: reference.srt - Imported with GPAC 0.4.6-DEV-rev4019 [libx264 @ 0x7f94a3804800] using SAR=16/15 [libx264 @ 0x7f94a3804800] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2 [libx264 @ 0x7f94a3804800] profile High, level 3.0 [hls @ 0x7f94a2242600] Using AVStream.codec to pass codec
Re: [FFmpeg-devel] what's the general setting for network reading and writing?
On Wed, Jul 13, 2016, at 01:36 AM, qw wrote: > Hi, > > If input or output is set to file, it's easy to set AVFormatContext. But > for network application, there are many issues that should be considered, > such as network delay, no network connection, and corrupted data. How to > set AVFormatContext to deal with those general network issues? Wrong mailing list. ffmpeg-devel is strictly for patch submissions and for discussions involving the development of FFmpeg itself–not for user applications using FFmpeg tools or libraries. The proper mailing list for this question is libav-user: this is the mailing list for questions involving the FFmpeg libraries. For the third time, please read: http://ffmpeg.org/contact.html ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9: add 16x16 idct avx2 (8-bit).
Hi, On Mon, Jul 11, 2016 at 6:15 PM, Henrik Gramner wrote: > On Mon, Jul 11, 2016 at 11:48 PM, Carl Eugen Hoyos > wrote: > > Ronald S. Bultje gmail.com> writes: > > > >> +%if ARCH_X86_64 > > > > Just curious: Why does this not work on x86-32? > > Isn't there some asm magic that moves some > > parameters to the stack if necessary? > > > > Carl Eugen > > Uses more than 8 vector registers. So, to be more precise, yes it can be made to work, and x86inc.asm does help a bit here and there to make this easier, but it's still quite a bit of work so we don't always make that effort anymore. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vp9: add 32x32 idct AVX2 implementation.
About 1.8x speedup compared to AVX version for full IDCT. Other
sub-IDCT scenarios also see speedups. Full --bench output for
idct_32x32_add_{bpp}_${subidct}_${opt} (50k cycles):
nop: 16.5
vp9_inv_dct_dct_32x32_add_8_1_c: 2284.4
vp9_inv_dct_dct_32x32_add_8_1_sse2: 145.0
vp9_inv_dct_dct_32x32_add_8_1_ssse3: 137.4
vp9_inv_dct_dct_32x32_add_8_1_avx: 137.1
vp9_inv_dct_dct_32x32_add_8_1_avx2: 73.2
vp9_inv_dct_dct_32x32_add_8_2_c: 14680.8
vp9_inv_dct_dct_32x32_add_8_2_sse2: 2617.2
vp9_inv_dct_dct_32x32_add_8_2_ssse3: 982.9
vp9_inv_dct_dct_32x32_add_8_2_avx: 958.5
vp9_inv_dct_dct_32x32_add_8_2_avx2: 704.2
vp9_inv_dct_dct_32x32_add_8_4_c: 14443.1
vp9_inv_dct_dct_32x32_add_8_4_sse2: 2717.1
vp9_inv_dct_dct_32x32_add_8_4_ssse3: 965.7
vp9_inv_dct_dct_32x32_add_8_4_avx: 1000.7
vp9_inv_dct_dct_32x32_add_8_4_avx2: 717.1
vp9_inv_dct_dct_32x32_add_8_8_c: 14436.4
vp9_inv_dct_dct_32x32_add_8_8_sse2: 2671.8
vp9_inv_dct_dct_32x32_add_8_8_ssse3: 1038.5
vp9_inv_dct_dct_32x32_add_8_8_avx: 983.0
vp9_inv_dct_dct_32x32_add_8_8_avx2: 729.4
vp9_inv_dct_dct_32x32_add_8_16_c: 14614.7
vp9_inv_dct_dct_32x32_add_8_16_sse2: 2701.7
vp9_inv_dct_dct_32x32_add_8_16_ssse3: 1334.4
vp9_inv_dct_dct_32x32_add_8_16_avx: 1276.7
vp9_inv_dct_dct_32x32_add_8_16_avx2: 719.5
vp9_inv_dct_dct_32x32_add_8_32_c: 14363.6
vp9_inv_dct_dct_32x32_add_8_32_sse2: 2575.6
vp9_inv_dct_dct_32x32_add_8_32_ssse3: 2633.9
vp9_inv_dct_dct_32x32_add_8_32_avx: 2539.6
vp9_inv_dct_dct_32x32_add_8_32_avx2: 1395.0
---
libavcodec/x86/vp9dsp_init.c | 2 +
libavcodec/x86/vp9itxfm.asm | 223 ++-
2 files changed, 222 insertions(+), 3 deletions(-)
diff --git a/libavcodec/x86/vp9dsp_init.c b/libavcodec/x86/vp9dsp_init.c
index 6fa63ae..10751e5 100644
--- a/libavcodec/x86/vp9dsp_init.c
+++ b/libavcodec/x86/vp9dsp_init.c
@@ -115,6 +115,7 @@ itxfm_func(idct, idct, 32, ssse3);
itxfm_func(idct, idct, 32, avx);
itxfm_func(iwht, iwht, 4, mmx);
itxfm_func(idct, idct, 16, avx2);
+itxfm_func(idct, idct, 32, avx2);
#undef itxfm_func
#undef itxfm_funcs
@@ -384,6 +385,7 @@ av_cold void ff_vp9dsp_init_x86(VP9DSPContext *dsp, int
bpp, int bitexact)
if (ARCH_X86_64) {
#if ARCH_X86_64 && HAVE_AVX2_EXTERNAL
dsp->itxfm_add[TX_16X16][DCT_DCT] =
ff_vp9_idct_idct_16x16_add_avx2;
+dsp->itxfm_add[TX_32X32][DCT_DCT] =
ff_vp9_idct_idct_32x32_add_avx2;
init_subpel3_32_64(0, put, 8, avx2);
init_subpel3_32_64(1, avg, 8, avx2);
#endif
diff --git a/libavcodec/x86/vp9itxfm.asm b/libavcodec/x86/vp9itxfm.asm
index 7308b57..ba572fc 100644
--- a/libavcodec/x86/vp9itxfm.asm
+++ b/libavcodec/x86/vp9itxfm.asm
@@ -1993,7 +1993,12 @@ IADST16_FN iadst, IADST16, iadst, IADST16, avx
;-
%macro VP9_IDCT32_1D 2-3 32 ; src, pass, nnzc
-%assign %%str 16*%2*%2
+%if %2 == 1
+%assign %%str mmsize
+%else
+%assign %%str 64
+%endif
+
; first do t0-15, this can be done identical to idct16x16
VP9_IDCT16_1D_START %1, %3/2, 64*2, tmpq, 2*%%str, 1
@@ -2288,17 +2293,125 @@ IADST16_FN iadst, IADST16, iadst, IADST16, avx
mova m3, [tmpq+20*%%str] ; t5
movam13, [tmpq+24*%%str] ; t6
-SUMSUB_BA w, 6, 8, 10
+SUMSUB_BA w, 6, 8, 10
mova[tmpq+ 3*%%str], m8 ; t15
-movam10, [tmpq+28*%%str] ; t7
SUMSUB_BA w, 0, 9, 8
SUMSUB_BA w, 15, 12, 8
SUMSUB_BA w, 14, 11, 8
SUMSUB_BA w, 1, 2, 8
SUMSUB_BA w, 7, 3, 8
SUMSUB_BA w, 5, 13, 8
+movam10, [tmpq+28*%%str] ; t7
SUMSUB_BA w, 4, 10, 8
+%if cpuflag(avx2)
+; the "shitty" about this idct is that the final pass does the outermost
+; interleave sumsubs (t0/31, t1/30, etc) but the tN for the 16x16 need
+; to be sequential, which means I need to load/store half of the sumsub
+; intermediates back to/from memory to get a 16x16 transpose going...
+; This would be easier if we had more (e.g. 32) YMM regs here.
+mova[tmpq+ 7*%%str], m9
+mova[tmpq+11*%%str], m12
+mova[tmpq+15*%%str], m11
+mova[tmpq+19*%%str], m2
+mova[tmpq+23*%%str], m3
+mova[tmpq+27*%%str], m13
+mova[tmpq+31*%%str], m10
+mova[tmpq+12*%%str], m5
+
+movam13, [tmpq+30*%%str] ; t8
+movam12, [tmpq+26*%%str] ; t9
+movam11, [tmpq+22*%%str] ; t10
+movam10, [tmpq+18*%%str] ; t11
+mova m9, [tmpq+17*%%str] ; t20
+mova m8, [tmpq+ 1*%%str] ; t21
+mova m3, [tmpq+25*%%str] ; t22
+mova m2, [tmpq+ 5*%%str] ; t23
+
+SUMSUB_BA w, 9, 10, 5
+SUMSUB_BA w, 8, 11, 5
+SUMSUB_BA w, 3, 12, 5
+SUMSUB_BA
[FFmpeg-devel] [PATCH 2/2] avformat/mux: Apply auto bsfs in av_write_frame() too
Signed-off-by: Michael Niedermayer --- libavformat/mux.c |4 1 file changed, 4 insertions(+) diff --git a/libavformat/mux.c b/libavformat/mux.c index 5cb0ca7..d674bd4 100644 --- a/libavformat/mux.c +++ b/libavformat/mux.c @@ -893,6 +893,10 @@ int av_write_frame(AVFormatContext *s, AVPacket *pkt) return 1; } +ret = do_packet_auto_bsf(s, pkt); +if (ret <= 0) +return ret; + #if FF_API_COMPUTE_PKT_FIELDS2 && FF_API_LAVF_AVCTX ret = compute_muxer_pkt_fields(s, s->streams[pkt->stream_index], pkt); -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avformat/mux: Factor do_packet_auto_bsf() out
Signed-off-by: Michael Niedermayer
---
libavformat/mux.c | 102 ++---
1 file changed, 57 insertions(+), 45 deletions(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index a447645..5cb0ca7 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -817,6 +817,57 @@ static int prepare_input_packet(AVFormatContext *s,
AVPacket *pkt)
return 0;
}
+static int do_packet_auto_bsf(AVFormatContext *s, AVPacket *pkt) {
+AVStream *st = s->streams[pkt->stream_index];
+int i, ret;
+
+if (s->oformat->check_bitstream) {
+if (!st->internal->bitstream_checked) {
+if ((ret = s->oformat->check_bitstream(s, pkt)) < 0)
+return ret;
+else if (ret == 1)
+st->internal->bitstream_checked = 1;
+}
+}
+
+for (i = 0; i < st->internal->nb_bsfcs; i++) {
+AVBSFContext *ctx = st->internal->bsfcs[i];
+if (i > 0) {
+AVBSFContext* prev_ctx = st->internal->bsfcs[i - 1];
+if (prev_ctx->par_out->extradata_size !=
ctx->par_in->extradata_size) {
+if ((ret = avcodec_parameters_copy(ctx->par_in,
prev_ctx->par_out)) < 0)
+return ret;
+}
+}
+// TODO: when any bitstream filter requires flushing at EOF, we'll
need to
+// flush each stream's BSF chain on write_trailer.
+if ((ret = av_bsf_send_packet(ctx, pkt)) < 0) {
+av_log(ctx, AV_LOG_ERROR,
+"Failed to send packet to filter %s for stream %d",
+ctx->filter->name, pkt->stream_index);
+return ret;
+}
+// TODO: when any automatically-added bitstream filter is generating
multiple
+// output packets for a single input one, we'll need to call this in a
loop
+// and write each output packet.
+if ((ret = av_bsf_receive_packet(ctx, pkt)) < 0) {
+if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
+return 0;
+av_log(ctx, AV_LOG_ERROR,
+"Failed to send packet to filter %s for stream %d",
+ctx->filter->name, pkt->stream_index);
+return ret;
+}
+if (i == st->internal->nb_bsfcs - 1) {
+if (ctx->par_out->extradata_size != st->codecpar->extradata_size) {
+if ((ret = avcodec_parameters_copy(st->codecpar,
ctx->par_out)) < 0)
+return ret;
+}
+}
+}
+return 1;
+}
+
int av_write_frame(AVFormatContext *s, AVPacket *pkt)
{
int ret;
@@ -1082,7 +1133,7 @@ static int interleave_packet(AVFormatContext *s, AVPacket
*out, AVPacket *in, in
int av_interleaved_write_frame(AVFormatContext *s, AVPacket *pkt)
{
-int ret, flush = 0, i;
+int ret, flush = 0;
ret = prepare_input_packet(s, pkt);
if (ret < 0)
@@ -1091,50 +1142,11 @@ int av_interleaved_write_frame(AVFormatContext *s,
AVPacket *pkt)
if (pkt) {
AVStream *st = s->streams[pkt->stream_index];
-if (s->oformat->check_bitstream) {
-if (!st->internal->bitstream_checked) {
-if ((ret = s->oformat->check_bitstream(s, pkt)) < 0)
-goto fail;
-else if (ret == 1)
-st->internal->bitstream_checked = 1;
-}
-}
-
-for (i = 0; i < st->internal->nb_bsfcs; i++) {
-AVBSFContext *ctx = st->internal->bsfcs[i];
-if (i > 0) {
-AVBSFContext* prev_ctx = st->internal->bsfcs[i - 1];
-if (prev_ctx->par_out->extradata_size !=
ctx->par_in->extradata_size) {
-if ((ret = avcodec_parameters_copy(ctx->par_in,
prev_ctx->par_out)) < 0)
-goto fail;
-}
-}
-// TODO: when any bitstream filter requires flushing at EOF, we'll
need to
-// flush each stream's BSF chain on write_trailer.
-if ((ret = av_bsf_send_packet(ctx, pkt)) < 0) {
-av_log(ctx, AV_LOG_ERROR,
- "Failed to send packet to filter %s for stream %d",
- ctx->filter->name, pkt->stream_index);
-goto fail;
-}
-// TODO: when any automatically-added bitstream filter is
generating multiple
-// output packets for a single input one, we'll need to call this
in a loop
-// and write each output packet.
-if ((ret = av_bsf_receive_packet(ctx, pkt)) < 0) {
-if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
-return 0;
-av_log(ctx, AV_LOG_ERROR,
- "Failed to send packet to filter %s for stream %d",
- ctx->filter->name, pkt->stream_index);
-goto fail;
-}
-if (i == st->internal->nb_bsfcs - 1) {
-if (ctx->par
Re: [FFmpeg-devel] Fwd: [PATCH] Automatically inserted bitstream filter 'h264_mp4toannexb' into hlsenc
On Wed, Jul 13, 2016 at 02:52:34PM +0200, Hendrik Leppkes wrote: > On Wed, Jul 13, 2016 at 12:28 PM, Michael Niedermayer > wrote: > > On Wed, Jun 29, 2016 at 01:07:13AM +0200, Hendrik Leppkes wrote: > >> On Wed, Jun 29, 2016 at 12:30 AM, Steven Liu > >> wrote: > >> > > >> > > >> > 2016-06-29 0:16 GMT+08:00 Hendrik Leppkes : > >> >> > >> >> On Tue, Jun 28, 2016 at 3:29 PM, Steven Liu > >> >> wrote: > >> >> > before patched: > >> >> > [root@localhost ffmpeg]# ./ffmpeg_g -re -i /root/facebook.mp4 -c copy > >> >> > -f > >> >> > hls -v verbose -y .m3u8 > >> >> > ffmpeg version N-80779-gb18d6c5 Copyright (c) 2000-2016 the FFmpeg > >> >> > developers > >> >> > >> >> > >> >> The way I see it, the auto bsf from the mpegts muxer should already > >> >> cover this without changes? > >> > > >> > > >> > add the hls_check_bitstream into hls format and call the hls->avf to call > >> > the mpegtsenc's check_bitstream, > >> > don't do this operation, it won't call the mpegtsenc's check_bitstream, > >> > look at the message bellow: > >> > > >> > >> This is the wrong approach to fixing this however, it should be > >> understood first why its not doing this transparently right now. > >> hlsenc uses the mpegts muxer like one would use any other muxer, so > >> why does autobsf not get used? > >> > >> If we understand that, maybe it can be fixed in a more generic way, > >> and not end up in ugly hacks in hlsenc. > > > > The issue is that hlsenc does call ff_write_chained() which causes > > av_write_frame() instead of av_interleaved_write_frame() to be used, > > bypassing the current auto bsf code > > > > Using av_interleaved_write_frame() would, i assume introduce a delay > > > > Maybe we should re-factor this BSF logic into a shareable function and > make both av_write_frame and av_interleaved_write_frame use it then, > instead of adding it to hlsenc (and after that even more > playlist-muxers like dash, segment, etc) patchset submited that does this does this look ok to you ? @Steven, does it work for you ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] libzvbi automatically obtain teletext durations
Hello, I am converting DVB teletext to SRT. As far as I know, libzvbi can only set txt_duration to a constant number of miliseconds. Then every time subtitles show, their duration is the same. May we expect an update, which modifies libzvbi to have default behaviour to obtain original durations from teletext? Best regards, Lukas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/mov: fix stream extradata_size allocation
From: Matthieu Bouron Fixes CID 1363963. --- libavformat/mov.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index 2712364..3843ceb 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -2336,7 +2336,7 @@ static int mov_read_stsd(MOVContext *c, AVIOContext *pb, MOVAtom atom) if (!sc->extradata) return AVERROR(ENOMEM); -sc->extradata_size = av_mallocz_array(sc->stsd_count, sizeof(sc->extradata_size)); +sc->extradata_size = av_mallocz_array(sc->stsd_count, sizeof(*sc->extradata_size)); if (!sc->extradata_size) return AVERROR(ENOMEM); -- 2.9.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libzvbi automatically obtain teletext durations
On Wed, Jul 13, 2016 at 15:31:54 +0300, Lukas wrote: > May we expect an update, which modifies libzvbi to have default > behaviour to obtain original durations from teletext? libzvbi is not an ffmpeg project. I believe this limitation is from said library, so you need to ask its developers. (ffmpeg has the command line option "-fix_sub_duration", which makes the decoded subtitles not overlap, i.e. expire when a new one comes.) Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fwd: [PATCH] Automatically inserted bitstream filter 'h264_mp4toannexb' into hlsenc
Michael Niedermayer 于2016年7月14日 周四上午1:12写道： > On Wed, Jul 13, 2016 at 02:52:34PM +0200, Hendrik Leppkes wrote: > > On Wed, Jul 13, 2016 at 12:28 PM, Michael Niedermayer > > wrote: > > > On Wed, Jun 29, 2016 at 01:07:13AM +0200, Hendrik Leppkes wrote: > > >> On Wed, Jun 29, 2016 at 12:30 AM, Steven Liu > wrote: > > >> > > > >> > > > >> > 2016-06-29 0:16 GMT+08:00 Hendrik Leppkes : > > >> >> > > >> >> On Tue, Jun 28, 2016 at 3:29 PM, Steven Liu < > lingjiujia...@gmail.com> > > >> >> wrote: > > >> >> > before patched: > > >> >> > [root@localhost ffmpeg]# ./ffmpeg_g -re -i /root/facebook.mp4 > -c copy -f > > >> >> > hls -v verbose -y .m3u8 > > >> >> > ffmpeg version N-80779-gb18d6c5 Copyright (c) 2000-2016 the > FFmpeg > > >> >> > developers > > >> >> > > >> >> > > >> >> The way I see it, the auto bsf from the mpegts muxer should already > > >> >> cover this without changes? > > >> > > > >> > > > >> > add the hls_check_bitstream into hls format and call the hls->avf > to call > > >> > the mpegtsenc's check_bitstream, > > >> > don't do this operation, it won't call the mpegtsenc's > check_bitstream, > > >> > look at the message bellow: > > >> > > > >> > > >> This is the wrong approach to fixing this however, it should be > > >> understood first why its not doing this transparently right now. > > >> hlsenc uses the mpegts muxer like one would use any other muxer, so > > >> why does autobsf not get used? > > >> > > >> If we understand that, maybe it can be fixed in a more generic way, > > >> and not end up in ugly hacks in hlsenc. > > > > > > The issue is that hlsenc does call ff_write_chained() which causes > > > av_write_frame() instead of av_interleaved_write_frame() to be used, > > > bypassing the current auto bsf code > > > > > > Using av_interleaved_write_frame() would, i assume introduce a delay > > > > > > > Maybe we should re-factor this BSF logic into a shareable function and > > make both av_write_frame and av_interleaved_write_frame use it then, > > instead of adding it to hlsenc (and after that even more > > playlist-muxers like dash, segment, etc) > > patchset submited that does this > does this look ok to you ? > > @Steven, does it work for you ? > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > I do not agree with what you have to say, but I'll defend to the death your > right to say it. -- Voltaire > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > yeah，it's ok，it's work ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avformat/mux: Factor do_packet_auto_bsf() out
2016-07-14 1:08 GMT+08:00 Michael Niedermayer :
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mux.c | 102
> ++---
> 1 file changed, 57 insertions(+), 45 deletions(-)
>
> diff --git a/libavformat/mux.c b/libavformat/mux.c
> index a447645..5cb0ca7 100644
> --- a/libavformat/mux.c
> +++ b/libavformat/mux.c
> @@ -817,6 +817,57 @@ static int prepare_input_packet(AVFormatContext *s,
> AVPacket *pkt)
> return 0;
> }
>
> +static int do_packet_auto_bsf(AVFormatContext *s, AVPacket *pkt) {
> +AVStream *st = s->streams[pkt->stream_index];
> +int i, ret;
> +
> +if (s->oformat->check_bitstream) {
> +if (!st->internal->bitstream_checked) {
> +if ((ret = s->oformat->check_bitstream(s, pkt)) < 0)
> +return ret;
> +else if (ret == 1)
> +st->internal->bitstream_checked = 1;
> +}
> +}
> +
> +for (i = 0; i < st->internal->nb_bsfcs; i++) {
> +AVBSFContext *ctx = st->internal->bsfcs[i];
> +if (i > 0) {
> +AVBSFContext* prev_ctx = st->internal->bsfcs[i - 1];
> +if (prev_ctx->par_out->extradata_size !=
> ctx->par_in->extradata_size) {
> +if ((ret = avcodec_parameters_copy(ctx->par_in,
> prev_ctx->par_out)) < 0)
> +return ret;
> +}
> +}
> +// TODO: when any bitstream filter requires flushing at EOF,
> we'll need to
> +// flush each stream's BSF chain on write_trailer.
> +if ((ret = av_bsf_send_packet(ctx, pkt)) < 0) {
> +av_log(ctx, AV_LOG_ERROR,
> +"Failed to send packet to filter %s for stream %d",
> +ctx->filter->name, pkt->stream_index);
> +return ret;
> +}
> +// TODO: when any automatically-added bitstream filter is
> generating multiple
> +// output packets for a single input one, we'll need to call this
> in a loop
> +// and write each output packet.
> +if ((ret = av_bsf_receive_packet(ctx, pkt)) < 0) {
> +if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
> +return 0;
> +av_log(ctx, AV_LOG_ERROR,
> +"Failed to send packet to filter %s for stream %d",
> +ctx->filter->name, pkt->stream_index);
> +return ret;
> +}
> +if (i == st->internal->nb_bsfcs - 1) {
> +if (ctx->par_out->extradata_size !=
> st->codecpar->extradata_size) {
> +if ((ret = avcodec_parameters_copy(st->codecpar,
> ctx->par_out)) < 0)
> +return ret;
> +}
> +}
> +}
> +return 1;
> +}
> +
> int av_write_frame(AVFormatContext *s, AVPacket *pkt)
> {
> int ret;
> @@ -1082,7 +1133,7 @@ static int interleave_packet(AVFormatContext *s,
> AVPacket *out, AVPacket *in, in
>
> int av_interleaved_write_frame(AVFormatContext *s, AVPacket *pkt)
> {
> -int ret, flush = 0, i;
> +int ret, flush = 0;
>
> ret = prepare_input_packet(s, pkt);
> if (ret < 0)
> @@ -1091,50 +1142,11 @@ int av_interleaved_write_frame(AVFormatContext *s,
> AVPacket *pkt)
> if (pkt) {
> AVStream *st = s->streams[pkt->stream_index];
>
> -if (s->oformat->check_bitstream) {
> -if (!st->internal->bitstream_checked) {
> -if ((ret = s->oformat->check_bitstream(s, pkt)) < 0)
> -goto fail;
> -else if (ret == 1)
> -st->internal->bitstream_checked = 1;
> -}
> -}
> -
> -for (i = 0; i < st->internal->nb_bsfcs; i++) {
> -AVBSFContext *ctx = st->internal->bsfcs[i];
> -if (i > 0) {
> -AVBSFContext* prev_ctx = st->internal->bsfcs[i - 1];
> -if (prev_ctx->par_out->extradata_size !=
> ctx->par_in->extradata_size) {
> -if ((ret = avcodec_parameters_copy(ctx->par_in,
> prev_ctx->par_out)) < 0)
> -goto fail;
> -}
> -}
> -// TODO: when any bitstream filter requires flushing at EOF,
> we'll need to
> -// flush each stream's BSF chain on write_trailer.
> -if ((ret = av_bsf_send_packet(ctx, pkt)) < 0) {
> -av_log(ctx, AV_LOG_ERROR,
> - "Failed to send packet to filter %s for stream %d",
> - ctx->filter->name, pkt->stream_index);
> -goto fail;
> -}
> -// TODO: when any automatically-added bitstream filter is
> generating multiple
> -// output packets for a single input one, we'll need to call
> this in a loop
> -// and write each output packet.
> -if ((ret = av_bsf_receive_packet(ctx, pkt)) < 0) {
> -if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
> -return 0;
> -av_lo
[FFmpeg-devel] [PATCH] remove the check_bitstream from segment
because Michael Niedermayer has re-factor BSF logic into a shareable
function and
make both av_write_frame and av_interleaved_write_frame use it.
Signed-off-by: LiuQi
---
libavformat/segment.c | 21 -
1 file changed, 21 deletions(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index 4c6c6d4..bf29ef8 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -957,25 +957,6 @@ fail:
return ret;
}
-static int seg_check_bitstream(struct AVFormatContext *s, const AVPacket
*pkt)
-{
-SegmentContext *seg = s->priv_data;
-AVFormatContext *oc = seg->avf;
-if (oc->oformat->check_bitstream) {
-int ret = oc->oformat->check_bitstream(oc, pkt);
-if (ret == 1) {
-AVStream *st = s->streams[pkt->stream_index];
-AVStream *ost = oc->streams[pkt->stream_index];
-st->internal->bsfcs = ost->internal->bsfcs;
-st->internal->nb_bsfcs = ost->internal->nb_bsfcs;
-ost->internal->bsfcs = NULL;
-ost->internal->nb_bsfcs = 0;
-}
-return ret;
-}
-return 1;
-}
-
#define OFFSET(x) offsetof(SegmentContext, x)
#define E AV_OPT_FLAG_ENCODING_PARAM
static const AVOption options[] = {
@@ -1037,7 +1018,6 @@ AVOutputFormat ff_segment_muxer = {
.init = seg_init,
.write_packet = seg_write_packet,
.write_trailer = seg_write_trailer,
-.check_bitstream = seg_check_bitstream,
.priv_class = &seg_class,
};
@@ -1056,6 +1036,5 @@ AVOutputFormat ff_stream_segment_muxer = {
.init = seg_init,
.write_packet = seg_write_packet,
.write_trailer = seg_write_trailer,
-.check_bitstream = seg_check_bitstream,
.priv_class = &sseg_class,
};
--
2.7.4 (Apple Git-66)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avformat/mux: Apply auto bsfs in av_write_frame() too
2016-07-14 1:08 GMT+08:00 Michael Niedermayer : > Signed-off-by: Michael Niedermayer > --- > libavformat/mux.c |4 > 1 file changed, 4 insertions(+) > > diff --git a/libavformat/mux.c b/libavformat/mux.c > index 5cb0ca7..d674bd4 100644 > --- a/libavformat/mux.c > +++ b/libavformat/mux.c > @@ -893,6 +893,10 @@ int av_write_frame(AVFormatContext *s, AVPacket *pkt) > return 1; > } > > +ret = do_packet_auto_bsf(s, pkt); > +if (ret <= 0) > +return ret; > + > #if FF_API_COMPUTE_PKT_FIELDS2 && FF_API_LAVF_AVCTX > ret = compute_muxer_pkt_fields(s, s->streams[pkt->stream_index], pkt); > > LGTM,Thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mov: fix stream extradata_size allocation
On Wed, Jul 13, 2016 at 10:51:23PM +0200, Matthieu Bouron wrote: > From: Matthieu Bouron > > Fixes CID 1363963. > --- > libavformat/mov.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] MKV Header: Writing duration early
Nicolas George wrote:
>Le quintidi 25 messidor, an CCXXIV, Soft Works a écrit :
>> Such circumstances are not really "special" or even rare.
>> Especially in most trivial cases (like mkv to mkv) there is a known
>> duration from the source that could be used.
>>
>> No doubt, that it's not available in all cases. But it could be written in
>> those cases where it's available.
>
>There are two sides to this issue: change the muxer to write the value if it
>is known at the beginning and change the command-line tool to compute the
>value for their output.
>
>I suspect the muxer change would be reasonably easy.
>
>The change on the command-line tool, on the other hand, you would have to
>determine if the input duration is reliable, detect if filters may change
>the duration, take mapping from various files into account, etc. This is
>very hard.
>
>> Probably the actual question is: If I would submit a patch to do this,
>> would it have a chance to be included?
>
>If the patch is clean and the feature/size ratio is reasonable, of course.
I had a look at the encoder for WebM files (webmdashenc.c). In this case
the duration is written during "write_header" (and not even overwritten
in "write_trailer").
The duration is determined in webmdashenc.c with this method:
static double get_duration(AVFormatContext *s)
{
int i = 0;
double max = 0.0;
for (i = 0; i < s->nb_streams; i++) {
AVDictionaryEntry *duration = av_dict_get(s->streams[i]->metadata,
DURATION, NULL, 0);
if (!duration || atof(duration->value) < 0) continue;
if (atof(duration->value) > max) max = atof(duration->value);
}
return max / 1000;
}
Another example is from write_metadata in flvenc.c:
// fill in the guessed duration, it'll be corrected later if incorrect
put_amf_double(pb, s->duration / AV_TIME_BASE);
This is evidence that early writing a duration to result file headers
is nothing new and already implemented for other file formats.
So can I just do it in the same way for mkv in matroskaenc.c?
Or should it be guarded by a new command line option?
(I'd say no because this only affects situations where the output
file is being read while ffmpeg is still running and at the end of the
process the duration is overwritten anyway).
What do you think?
softworkz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
