Re: [FFmpeg-devel] [PATCH 2/2] avformat: add avformat_flush()
On 30.09.2014, at 22:25, wm4 nfx...@googlemail.com wrote: On Tue, 30 Sep 2014 08:06:16 +0200 Reimar Döffinger reimar.doeffin...@gmx.de wrote: On 29.09.2014, at 22:02, Michael Niedermayer michae...@gmx.at wrote: On Mon, Sep 29, 2014 at 08:34:44PM +0200, wm4 wrote: On Mon, 29 Sep 2014 20:25:47 +0200 Michael Niedermayer michae...@gmx.at wrote: On Mon, Sep 29, 2014 at 07:41:28PM +0200, wm4 wrote: Useful for Bluray and DVD, since the libraries used to read them just change the byte stream under your feet on seeking. Maybe there should be a AVInputFormat callback for this. But the mpeg-ps (DVD) and the mpeg-ts (Bluray) demuxers don't change much state during seeking - they just try to find a new packet with timestamps (in read_timestamp), so I haven't found a need for this yet. I don't want to add unused things. I've also thought about adding a flush callback, and implementing them in mpeg.c and mpegts.c by just calling ff_read_frame_flush(). Might be slightly better, because you can have avformat_flush() fail on formats which don't support this? Or maybe a flag? TODO: add entry to APIchanges, bump minor version. --- libavformat/avformat.h | 13 + libavformat/utils.c| 6 ++ 2 files changed, 19 insertions(+) diff --git a/libavformat/avformat.h b/libavformat/avformat.h index 78054de..eaa52fa 100644 --- a/libavformat/avformat.h +++ b/libavformat/avformat.h @@ -2173,6 +2173,19 @@ int av_seek_frame(AVFormatContext *s, int stream_index, int64_t timestamp, int avformat_seek_file(AVFormatContext *s, int stream_index, int64_t min_ts, int64_t ts, int64_t max_ts, int flags); /** + * Discard all internally buffered data. This can be useful when dealing with + * discontinuities in the byte stream. Generally works only with some simple + * formats. id call them stream based or without a central header instead of simple. I can change that and replace simple with headerless. please do, headerless is more specific Why does it require headerless? I would have expected this feature to work for e.g. Ogg as well, which clearly is not headerless. As such I'd claim headerless may be more specific, but it is also wrong. It should work for all formats that can be read without index and can resync reliably at least. Do you have any concrete suggestions? I'm not sure what documentation would be most appropriate. Maybe formats that can resync. This includes headerless formats like MPEG-TS/TS but should also work with NUT, Ogg and in a limited way AVI for example Not sure that's the best way to do it either though. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] IRC meeting
On date Tuesday 2014-09-30 20:57:33 -0700, Timothy Gu encoded: Hi, On Mon, Sep 29, 2014 at 8:39 AM, Stefano Sabatini stefa...@gmail.com wrote: Hi, I want to propose to have an FFmpeg IRC meeting the next Saturday, 4th October, UTC 16. Alternatively, I propose the Saturday of the next week, Saturday October 11, same time. I don't think I will be available for the entire meeting on either Saturdays, but I slightly prefer October 4th. Do not take my availability as a blocker as I won't say much during the FFmeetings anyway. Candidate topics of the day: - VDD 2014 report and discussion, in particular with regards to relationships with libav - OPW program organization - technical development issues - misc topics Feel free to propose other topics. I can't think of anything else right now. Thank you for organizing the meetings. I have created a wiki page for this FFmeeting here: http://trac.ffmpeg.org/wiki/FFmeeting/2014-10. Feel free to add more stuff to it. So, since we have already two preferences for Saturday 4 October, I think we should stick with it. If I see no other comments, I'll settle the date. Thanks all. -- FFmpeg = Faithful Freak Marvellous Power Entertaining Geisha ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/mpegvideoencdsp: improve ff_pix_sum16_sse2
On Tue, Sep 30, 2014 at 10:24:28PM -0300, James Almer wrote: ~15 faster. Also add an mmxext version that takes advantage of the new code, and build it alongside with the mmx version only on x86_32. Signed-off-by: James Almer jamr...@gmail.com --- libavcodec/x86/mpegvideoencdsp.asm| 51 +++ libavcodec/x86/mpegvideoencdsp_init.c | 7 + 2 files changed, 41 insertions(+), 17 deletions(-) LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/18] avcodec: remove obsolete FF_API_FAST_MALLOC cruft
On 01.10.2014 04:34, Michael Niedermayer wrote: On Mon, Sep 15, 2014 at 10:59:39PM +0200, Andreas Cadhalpun wrote: On 15.09.2014 22:03, Michael Niedermayer wrote: On Mon, Sep 15, 2014 at 04:08:49PM -0300, James Almer wrote: On 15/09/14 6:07 AM, Michael Niedermayer wrote: On Sun, Sep 14, 2014 at 10:46:03PM -0300, James Almer wrote: Signed-off-by: James Almer jamr...@gmail.com about the patchset as a whole, not specifically this one we should check if theres any software left around that still uses the symbols before removing the code completely and if so consider to reintroduce them in a 2.4.1 while removing whats unused Pushed the three you reviewed since either no code depended on them, or in the OpenCL case it's an API that nobody has ever been able to use anyway. I'm not exactly interested in looking around to see if any of this deprecated stuff is still used. And IMO reintroducing them in a point release is quite ugly. An exception could be FF_API_DRAWTEXT_OLD_TIMELINE since as Clément pointed in another email might be needed to remain compatible with libav. probably you only have to wait, as i suspect andreas (in CC) will test building all dependant packages in debian against 2.4 You're right that I'm currently rebuilding those against 2.4, but I don't expect any problems there, since I already have rebuilt them against a git snapshot about two weeks ago and didn't notice anything problematic. any news ? can these be applied ? In case it wasn't sufficiently clear: There were no problems rebuilding them against FFmpeg 2.4, just as expected. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/mpegvideoencdsp: improve ff_pix_sum16_sse2
On 2014-10-01 03:24, James Almer wrote: ~15 faster. 15 what faster? 15 cycles? 15%? 15 times? signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v7] Add SUP/PGS subtitle demuxer
On Wed, 1 Oct 2014 12:58:32 +0200 Michael Niedermayer michae...@gmx.at wrote: On Wed, Oct 01, 2014 at 01:36:58PM +0300, Petri Hintukainen wrote: On ti, 2014-09-30 at 16:09 +0200, wm4 wrote: On Tue, 30 Sep 2014 12:01:33 +0300 Petri Hintukainen phint...@gmail.com wrote: Hello, Missing DTS combined with non-monotonic PTS seems to cause some problems. This is with the file from ticket #2208 (I added dumping timestamps to demuxer and muxer): $ ../ffmpeg -i orig/track_06\ -\ Subtitle.sup -scodec copy 6.sup ffmpeg version N-66546-gea74007 Copyright (c) 2000-2014 the FFmpeg developers built on Sep 30 2014 11:10:08 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1) configuration: libavutil 54. 7.101 / 54. 7.101 libavcodec 56. 1.101 / 56. 1.101 libavformat56. 7.101 / 56. 7.101 libavdevice56. 1.100 / 56. 1.100 libavfilter 5. 1.102 / 5. 1.102 libswscale 3. 1.100 / 3. 1.100 libswresample 1. 1.100 / 1. 1.100 IN pts 00255314 dts Input #0, sup, from 'orig/track_06 - Subtitle.sup': Duration: N/A, start: 2.836822, bitrate: N/A Stream #0:0: Subtitle: hdmv_pgs_subtitle, 1920x1080 Output #0, sup, to '6.sup': Metadata: encoder : Lavf56.7.101 Stream #0:0: Subtitle: hdmv_pgs_subtitle, 1920x1080 Stream mapping: Stream #0:0 - #0:0 (copy) Press [q] to stop, [?] for help OUT pts dts IN pts 00255037 dts OUT pts dts IN pts 00249205 dts [sup @ 0x241f4e0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: -277 = -6109 av_interleaved_write_frame(): Invalid argument size= 0kB time=00:00:00.00 bitrate=N/A video:0kB audio:0kB subtitle:1kB other streams:0kB global headers:0kB muxing overhead: unknown Conversion failed! The DTS in this file are indeed decreasing sometimes. No, there are no DTS timestamps in this file. those dts's are generated by ffmpeg, probably in mux.c compute_pkt_fields2(). Ouch. Yeah, I think this function used to corrupt perfectly fine h264 mpegts timestamps in the past or so... Also note that timestamps are re-positioned to start from 0. This may be problematic, it requires manually synchronizing subtitles to the video. Rebasing the timestamps is apparently the normal operation of ffmpeg.c, there's probably a way to make it stop doing that. Yes, -copyts seems to do the trick. I think all pts timestamps in .sup file should be relative to video start, i.e. if video starts at pts 12345, corresponding .sup file starts at pts = pts_of_first_subtitle - 12345. Remuxing from the original .m2ts file works just well: $ ffmpeg -i orig/00038.m2ts -map 0:6 -scodec copy 6.sup ffmpeg version N-66546-gea74007 Copyright (c) 2000-2014 the FFmpeg developers built on Sep 30 2014 11:10:08 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1) configuration: libavutil 54. 7.101 / 54. 7.101 libavcodec 56. 1.101 / 56. 1.101 libavformat56. 7.101 / 56. 7.101 libavdevice56. 1.100 / 56. 1.100 libavfilter 5. 1.102 / 5. 1.102 libswscale 3. 1.100 / 3. 1.100 libswresample 1. 1.100 / 1. 1.100 [NULL @ 0x1bf9ba0] start time for stream 6 is not set in estimate_timings_from_pts [NULL @ 0x1c146e0] start time for stream 7 is not set in estimate_timings_from_pts [NULL @ 0x1c151c0] start time for stream 8 is not set in estimate_timings_from_pts [mpegts @ 0x1bf1ca0] Could not find codec parameters for stream 6 (Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090)): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options [mpegts @ 0x1bf1ca0] Could not find codec parameters for stream 7 (Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090)): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options [mpegts @ 0x1bf1ca0] Could not find codec parameters for stream 8 (Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090)): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options Input #0, mpegts, from 'orig/00038.m2ts': Duration: 00:00:43.90, start: 11.650667, bitrate: 35145 kb/s Program 1 Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn, 47.95 tbc Stream #0:1[0x1100]: Audio: truehd (AC-3 / 0x332D4341), 48000 Hz, 7.1, s32 (24 bit) Stream #0:2[0x1100]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 640 kb/s Stream #0:3[0x1101]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz,
[FFmpeg-devel] [PATCH] libavfilter: increase vf_drawtext line height
It’s a common practice to add some space between lines (typically 0.2 *
font-height) as it dramatically increases readability. In my opinion, the
default behaviour increasing the height just by max_glyph_h is not a very good
one.
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index 4fbb6c0..9d68a27 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -1232,7 +1232,7 @@ static int draw_text(AVFilterContext *ctx, AVFrame *frame,
if (is_newline(code)) {
max_text_line_w = FFMAX(max_text_line_w, x);
-y += s-max_glyph_h;
+y += s-max_glyph_h * 1.2;
x = 0;
continue;
}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/movenc: AVC Intra support
On Tue, Sep 30, 2014 at 11:07:28AM +0100, Kieran Kunhya wrote: Some of the DPP AVCI100 test samples were created using x264* so could be used for reference. Or I could knock up something if I can find my reference CL I used last time. www.obe.tv/about-us/obe-blog/item/1-oss-dpp-creation Remember to use the latest x264. Even then the values in the UMID SEI that FCP is probably looking for are just a guess. got it working, there was a bug in our libx264 wraper that resulted in the output not being avci compliant patch applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- 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 v7] Add SUP/PGS subtitle demuxer
On Wed, Oct 01, 2014 at 03:07:19PM +0200, wm4 wrote: On Wed, 1 Oct 2014 12:58:32 +0200 Michael Niedermayer michae...@gmx.at wrote: On Wed, Oct 01, 2014 at 01:36:58PM +0300, Petri Hintukainen wrote: On ti, 2014-09-30 at 16:09 +0200, wm4 wrote: On Tue, 30 Sep 2014 12:01:33 +0300 Petri Hintukainen phint...@gmail.com wrote: Hello, Missing DTS combined with non-monotonic PTS seems to cause some problems. This is with the file from ticket #2208 (I added dumping timestamps to demuxer and muxer): $ ../ffmpeg -i orig/track_06\ -\ Subtitle.sup -scodec copy 6.sup ffmpeg version N-66546-gea74007 Copyright (c) 2000-2014 the FFmpeg developers built on Sep 30 2014 11:10:08 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1) configuration: libavutil 54. 7.101 / 54. 7.101 libavcodec 56. 1.101 / 56. 1.101 libavformat56. 7.101 / 56. 7.101 libavdevice56. 1.100 / 56. 1.100 libavfilter 5. 1.102 / 5. 1.102 libswscale 3. 1.100 / 3. 1.100 libswresample 1. 1.100 / 1. 1.100 IN pts 00255314 dts Input #0, sup, from 'orig/track_06 - Subtitle.sup': Duration: N/A, start: 2.836822, bitrate: N/A Stream #0:0: Subtitle: hdmv_pgs_subtitle, 1920x1080 Output #0, sup, to '6.sup': Metadata: encoder : Lavf56.7.101 Stream #0:0: Subtitle: hdmv_pgs_subtitle, 1920x1080 Stream mapping: Stream #0:0 - #0:0 (copy) Press [q] to stop, [?] for help OUT pts dts IN pts 00255037 dts OUT pts dts IN pts 00249205 dts [sup @ 0x241f4e0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: -277 = -6109 av_interleaved_write_frame(): Invalid argument size= 0kB time=00:00:00.00 bitrate=N/A video:0kB audio:0kB subtitle:1kB other streams:0kB global headers:0kB muxing overhead: unknown Conversion failed! The DTS in this file are indeed decreasing sometimes. No, there are no DTS timestamps in this file. those dts's are generated by ffmpeg, probably in mux.c compute_pkt_fields2(). that could be Ouch. Yeah, I think this function used to corrupt perfectly fine h264 mpegts timestamps in the past or so... which trac ticket is that ? or do you mean by past that this is not relevant anymore as it has been fixed already ? Also note that timestamps are re-positioned to start from 0. This may be problematic, it requires manually synchronizing subtitles to the video. Rebasing the timestamps is apparently the normal operation of ffmpeg.c, there's probably a way to make it stop doing that. Yes, -copyts seems to do the trick. I think all pts timestamps in .sup file should be relative to video start, i.e. if video starts at pts 12345, corresponding .sup file starts at pts = pts_of_first_subtitle - 12345. Remuxing from the original .m2ts file works just well: $ ffmpeg -i orig/00038.m2ts -map 0:6 -scodec copy 6.sup ffmpeg version N-66546-gea74007 Copyright (c) 2000-2014 the FFmpeg developers built on Sep 30 2014 11:10:08 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1) configuration: libavutil 54. 7.101 / 54. 7.101 libavcodec 56. 1.101 / 56. 1.101 libavformat56. 7.101 / 56. 7.101 libavdevice56. 1.100 / 56. 1.100 libavfilter 5. 1.102 / 5. 1.102 libswscale 3. 1.100 / 3. 1.100 libswresample 1. 1.100 / 1. 1.100 [NULL @ 0x1bf9ba0] start time for stream 6 is not set in estimate_timings_from_pts [NULL @ 0x1c146e0] start time for stream 7 is not set in estimate_timings_from_pts [NULL @ 0x1c151c0] start time for stream 8 is not set in estimate_timings_from_pts [mpegts @ 0x1bf1ca0] Could not find codec parameters for stream 6 (Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090)): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options [mpegts @ 0x1bf1ca0] Could not find codec parameters for stream 7 (Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090)): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options [mpegts @ 0x1bf1ca0] Could not find codec parameters for stream 8 (Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090)): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options Input #0, mpegts, from 'orig/00038.m2ts': Duration: 00:00:43.90, start: 11.650667, bitrate: 35145 kb/s Program 1 Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 23.98
Re: [FFmpeg-devel] [PATCH v7] Add SUP/PGS subtitle demuxer
On Wed, 1 Oct 2014 17:11:17 +0200 Michael Niedermayer michae...@gmx.at wrote: Ouch. Yeah, I think this function used to corrupt perfectly fine h264 mpegts timestamps in the past or so... which trac ticket is that ? or do you mean by past that this is not relevant anymore as it has been fixed already ? It has been fixed quite a while ago. If we can't reconstruct a correct DTS if it's missing, we definitely should prevent the generic libavformat code from filling in completely broken DTS. Is there a flag for this? dts are not optional in mpeg* if you have no dts you wont have a mpeg-TS They are a integral part of the muxing process used both in the buffering model as well as in stream interleaving. that said its quite easy to add a flag to disable the code that sets the DTS if someone really wants such flag Well, .sup files are not mpeg... and there are some formats that store PTS only (like avi and mkv). I'm not sure if libavformat makes up a (broken) DTS for these. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v7] Add SUP/PGS subtitle demuxer
On Wed, Oct 01, 2014 at 05:32:52PM +0200, wm4 wrote: On Wed, 1 Oct 2014 17:11:17 +0200 Michael Niedermayer michae...@gmx.at wrote: Ouch. Yeah, I think this function used to corrupt perfectly fine h264 mpegts timestamps in the past or so... which trac ticket is that ? or do you mean by past that this is not relevant anymore as it has been fixed already ? It has been fixed quite a while ago. If we can't reconstruct a correct DTS if it's missing, we definitely should prevent the generic libavformat code from filling in completely broken DTS. Is there a flag for this? dts are not optional in mpeg* if you have no dts you wont have a mpeg-TS They are a integral part of the muxing process used both in the buffering model as well as in stream interleaving. that said its quite easy to add a flag to disable the code that sets the DTS if someone really wants such flag Well, .sup files are not mpeg... and there are some formats that store PTS only (like avi and mkv). I'm not sure if libavformat makes up a (broken) DTS for these. no dts implies only 1 stream, as dts are the basis for stream interleaving. You could invent some other interleaving that works based on non montone pts if you think thats easier than just setting dts correctly. you could try something like this, which may prevent dts from being set diff --git a/libavformat/mux.c b/libavformat/mux.c index 55add43..4c58475 100644 --- a/libavformat/mux.c +++ b/libavformat/mux.c @@ -494,7 +494,8 @@ static int compute_pkt_fields2(AVFormatContext *s, AVStream *st, AVPacket *pkt) for (i = 0; idelay st-pts_buffer[i] st-pts_buffer[i + 1]; i++) FFSWAP(int64_t, st-pts_buffer[i], st-pts_buffer[i + 1]); -pkt-dts = st-pts_buffer[0]; +if (st-codec-codec_id != AV_CODEC_ID_HDMV_PGS_SUBTITLE) +pkt-dts = st-pts_buffer[0]; } if (st-cur_dts st-cur_dts != AV_NOPTS_VALUE [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/mpegvideoencdsp: improve ff_pix_sum16_sse2
On 01/10/14 9:57 AM, James Darnley wrote: On 2014-10-01 03:24, James Almer wrote: ~15 faster. 15 what faster? 15 cycles? 15%? 15 times? Percent, thanks for noticing. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter: increase vf_drawtext line height
Sure: http://i.imgur.com/FEaJKJo.png (153 KiB). Current behavior is on the left, the propositional one is on the right. Both are generated by a filter string color=s=512x512,drawtext=fontfile=/Library/Fonts/Arial.ttf:text=123\n456\n789:fontsize=130:fontcolor=white:x=256-text_w/2:y=256-text_h/2”, note that you have to use the actual \u000a symbols instead of “\n”. On 01 окт. 2014 г., at 18:44, Michael Niedermayer michae...@gmx.at wrote: do you have a testcase that shows how the difference looks ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Stop demuxing wtv on eof
Hi!
Attached patch fixes the wtv regression described in tickets #3991 and #3995
for me.
Please review, Carl Eugen
diff --git a/libavformat/wtvdec.c b/libavformat/wtvdec.c
index 4cb3295..674ff6e 100644
--- a/libavformat/wtvdec.c
+++ b/libavformat/wtvdec.c
@@ -789,6 +789,8 @@ static int parse_chunks(AVFormatContext *s, int mode,
int64_t seekts, int *len_p
len = avio_rl32(pb);
if (len 32) {
int ret;
+if (avio_feof(pb))
+return AVERROR(EOF);
av_log(s, AV_LOG_WARNING, encountered broken chunk\n);
if ((ret = recover(wtv, avio_tell(pb) - 20)) 0)
return ret;
diff --git a/tests/ref/seek/lavf-wtv b/tests/ref/seek/lavf-wtv
index 355ab98..13c64a6 100644
--- a/tests/ref/seek/lavf-wtv
+++ b/tests/ref/seek/lavf-wtv
@@ -7,28 +7,32 @@ ret: 0 st: 0 flags:0 ts: 0.788334
ret: 0 st: 1 flags:1 dts: 0.734399 pts: 0.734399 pos: 294672 size:
209
ret: 0 st: 0 flags:1 ts:-0.317499
ret: 0 st: 1 flags:1 dts: 0.029093 pts: 0.029093 pos: 26272 size:
208
-ret:-1 st: 1 flags:0 ts: 2.576668
+ret: 0 st: 1 flags:0 ts: 2.576668
+ret:-EOF
ret: 0 st: 1 flags:1 ts: 1.470835
ret: 0 st: 1 flags:1 dts: 0.734399 pts: 0.734399 pos: 294672 size:
209
ret: 0 st:-1 flags:0 ts: 0.365002
ret: 0 st: 1 flags:1 dts: 0.029093 pts: 0.029093 pos: 26272 size:
208
ret: 0 st:-1 flags:1 ts:-0.740831
ret: 0 st: 1 flags:1 dts: 0.029093 pts: 0.029093 pos: 26272 size:
208
-ret:-1 st: 0 flags:0 ts: 2.153336
+ret: 0 st: 0 flags:0 ts: 2.153336
+ret:-EOF
ret: 0 st: 0 flags:1 ts: 1.047503
ret: 0 st: 1 flags:1 dts: 0.029093 pts: 0.029093 pos: 26272 size:
208
ret: 0 st: 1 flags:0 ts:-0.058330
ret: 0 st: 1 flags:1 dts: 0.029093 pts: 0.029093 pos: 26272 size:
208
ret: 0 st: 1 flags:1 ts: 2.835837
ret: 0 st: 1 flags:1 dts: 0.734399 pts: 0.734399 pos: 294672 size:
209
-ret:-1 st:-1 flags:0 ts: 1.730004
+ret: 0 st:-1 flags:0 ts: 1.730004
+ret:-EOF
ret: 0 st:-1 flags:1 ts: 0.624171
ret: 0 st: 1 flags:1 dts: 0.029093 pts: 0.029093 pos: 26272 size:
208
ret: 0 st: 0 flags:0 ts:-0.481662
ret: 0 st: 1 flags:1 dts: 0.029093 pts: 0.029093 pos: 26272 size:
208
ret: 0 st: 0 flags:1 ts: 2.412505
ret: 0 st: 1 flags:1 dts: 0.734399 pts: 0.734399 pos: 294672 size:
209
-ret:-1 st: 1 flags:0 ts: 1.306672
+ret: 0 st: 1 flags:0 ts: 1.306672
+ret:-EOF
ret: 0 st: 1 flags:1 ts: 0.200839
ret: 0 st: 1 flags:1 dts: 0.211950 pts: 0.211950 pos: 99280 size:
209
ret: 0 st:-1 flags:0 ts:-0.904994
@@ -39,7 +43,8 @@ ret: 0 st: 0 flags:0 ts: 0.883340
ret: 0 st: 1 flags:1 dts: 0.734399 pts: 0.734399 pos: 294672 size:
209
ret: 0 st: 0 flags:1 ts:-0.222493
ret: 0 st: 1 flags:1 dts: 0.029093 pts: 0.029093 pos: 26272 size:
208
-ret:-1 st: 1 flags:0 ts: 2.671674
+ret: 0 st: 1 flags:0 ts: 2.671674
+ret:-EOF
ret: 0 st: 1 flags:1 ts: 1.565841
ret: 0 st: 1 flags:1 dts: 0.734399 pts: 0.734399 pos: 294672 size:
209
ret: 0 st:-1 flags:0 ts: 0.460008
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] lavf/webm_dash: fix hardcode in cues_end computation
Fix an incorrect hard code in cues_end computation. Updating the fate
test reference files related to the fix as well. The earlier computation
was clearly wrong as the cues_end field was greater than the file size
itself in some cases.
Signed-off-by: Vignesh Venkatasubramanian vigne...@google.com
---
libavformat/matroskadec.c | 11 +++
tests/ref/fate/webm-dash-manifest | 4 ++--
tests/ref/fate/webm-dash-manifest-unaligned-audio-streams | 2 +-
tests/ref/fate/webm-dash-manifest-unaligned-video-streams | 2 +-
4 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index b8ddf67..d856fcc 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -3261,10 +3261,13 @@ static int webm_dash_manifest_cues(AVFormatContext *s)
before_pos = avio_tell(matroska-ctx-pb);
cues_start = seekhead[i].pos + matroska-segment_start;
if (avio_seek(matroska-ctx-pb, cues_start, SEEK_SET) == cues_start) {
-uint64_t cues_length = 0, cues_id = 0;
-ebml_read_num(matroska, matroska-ctx-pb, 4, cues_id);
-ebml_read_length(matroska, matroska-ctx-pb, cues_length);
-cues_end = cues_start + cues_length + 11; // 11 is the offset of Cues
ID.
+// cues_end is computed as cues_start + cues_length + length of the
+// Cues element ID + EBML length of the Cues element. cues_end is
+// inclusive and the above sum is reduced by 1.
+uint64_t cues_length = 0, cues_id = 0, bytes_read = 0;
+bytes_read += ebml_read_num(matroska, matroska-ctx-pb, 4, cues_id);
+bytes_read += ebml_read_length(matroska, matroska-ctx-pb,
cues_length);
+cues_end = cues_start + cues_length + bytes_read - 1;
}
avio_seek(matroska-ctx-pb, before_pos, SEEK_SET);
if (cues_start == -1 || cues_end == -1) return -1;
diff --git a/tests/ref/fate/webm-dash-manifest
b/tests/ref/fate/webm-dash-manifest
index 1c1a679..4b88040 100644
--- a/tests/ref/fate/webm-dash-manifest
+++ b/tests/ref/fate/webm-dash-manifest
@@ -20,7 +20,7 @@
Representation id=1 bandwidth=302355
BaseURLdash_video2.webm/BaseURL
SegmentBase
- indexRange=1115782-1115886
+ indexRange=1115782-1115879
Initialization
range=0-249 /
/SegmentBase
@@ -38,7 +38,7 @@
Representation id=1 bandwidth=82814
BaseURLdash_audio2.webm/BaseURL
SegmentBase
- indexRange=335312-335432
+ indexRange=335312-335425
Initialization
range=0-3927 /
/SegmentBase
diff --git a/tests/ref/fate/webm-dash-manifest-unaligned-audio-streams
b/tests/ref/fate/webm-dash-manifest-unaligned-audio-streams
index 5e1743e..6e9de21 100644
--- a/tests/ref/fate/webm-dash-manifest-unaligned-audio-streams
+++ b/tests/ref/fate/webm-dash-manifest-unaligned-audio-streams
@@ -20,7 +20,7 @@
Representation id=1 bandwidth=83502
BaseURLdash_audio3.webm/BaseURL
SegmentBase
- indexRange=335312-335432
+ indexRange=335312-335425
Initialization
range=0-3927 /
/SegmentBase
diff --git a/tests/ref/fate/webm-dash-manifest-unaligned-video-streams
b/tests/ref/fate/webm-dash-manifest-unaligned-video-streams
index 3576b60..ce20563 100644
--- a/tests/ref/fate/webm-dash-manifest-unaligned-video-streams
+++ b/tests/ref/fate/webm-dash-manifest-unaligned-video-streams
@@ -20,7 +20,7 @@
Representation id=1 bandwidth=321574
BaseURLdash_video3.webm/BaseURL
SegmentBase
- indexRange=1116070-1116461
+ indexRange=1116070-1116455
Initialization
range=0-249 /
/SegmentBase
--
2.1.0.rc2.206.gedb03e5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Check for OOM in the dirac parser
Hi! Attached patch fixes two possible null pointer dereferences on oom as described in ticket #3996. Please comment, Carl Eugen diff --git a/libavcodec/dirac_parser.c b/libavcodec/dirac_parser.c index 4119e3b..8b7c55e 100644 --- a/libavcodec/dirac_parser.c +++ b/libavcodec/dirac_parser.c @@ -139,6 +139,8 @@ static int dirac_combine_frame(AVCodecParserContext *s, AVCodecContext *avctx, void *new_buffer = av_fast_realloc(pc-buffer, pc-buffer_size, pc-index + (*buf_size - pc-sync_offset)); +if (!new_buffer) +return AVERROR(ENOMEM); pc-buffer = new_buffer; memcpy(pc-buffer + pc-index, (*buf + pc-sync_offset), *buf_size - pc-sync_offset); @@ -149,6 +151,8 @@ static int dirac_combine_frame(AVCodecParserContext *s, AVCodecContext *avctx, DiracParseUnit pu1, pu; void *new_buffer = av_fast_realloc(pc-buffer, pc-buffer_size, pc-index + next); +if (!new_buffer) +return AVERROR(ENOMEM); pc-buffer = new_buffer; memcpy(pc-buffer + pc-index, *buf, next); pc-index += next; ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter: increase vf_drawtext line height
Yes, that would be awesome. On 01 окт. 2014 г., at 21:32, Timothy Gu timothyg...@gmail.com wrote: I think the line spacing should be user-changeable through an AVOption. Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter: increase vf_drawtext line height
But on the other way, I doubt someone could ever need any other value, 1.2 is kind of standard already, e.g. every major desktop browser uses this value as the default line-height. On 01 окт. 2014 г., at 22:04, Михаил Муковников y...@me.com wrote: Yes, that would be awesome. On 01 окт. 2014 г., at 21:32, Timothy Gu timothyg...@gmail.com wrote: I think the line spacing should be user-changeable through an AVOption. Timothy ___ 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] libavfilter: increase vf_drawtext line height
On Wed, Oct 01, 2014 at 10:10:34PM +0400, Михаил Муковников wrote: But on the other way, I doubt someone could ever need any other value, 1.2 is kind of standard already, e.g. every major desktop browser uses this value as the default line-height. [citation needed] If you don't have any kind of reference document, an option (with 1.2 as default) would sound the most appropriate. It won't make the patch much more complex (don't forget to update the doc/filters.texi file though) Note to the one applying the patch: don't forget to micro bump libavfilter/version.h. [...] -- Clément B. pgpX5TWC9wNTh.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavfilter: increase vf_drawtext line height
I suppose https://developer.mozilla.org/en-US/docs/Web/CSS/line-height could stand as a citation. Anyway, all right, let’s make this option tunable, no problem. I hope I would be able to make other patch in a day or something. On 01 окт. 2014 г., at 22:31, Clément Bœsch u...@pkh.me wrote: [citation needed] If you don't have any kind of reference document, an option (with 1.2 as default) would sound the most appropriate. It won't make the patch much more complex (don't forget to update the doc/filters.texi file though) Note to the one applying the patch: don't forget to micro bump libavfilter/version.h. [...] -- Clément B. ___ 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]Check for OOM in the dirac parser
On Wed, Oct 01, 2014 at 07:32:36PM +0200, Carl Eugen Hoyos wrote: Hi! Attached patch fixes two possible null pointer dereferences on oom as described in ticket #3996. Please comment, Carl Eugen dirac_parser.c |4 1 file changed, 4 insertions(+) b813326b16996c7744858d682bf90956a0b90928 patchdiracoom2.diff diff --git a/libavcodec/dirac_parser.c b/libavcodec/dirac_parser.c should be ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavf/webm_dash: fix hardcode in cues_end computation
On Wed, Oct 01, 2014 at 10:13:30AM -0700, Vignesh Venkatasubramanian wrote: Fix an incorrect hard code in cues_end computation. Updating the fate test reference files related to the fix as well. The earlier computation was clearly wrong as the cues_end field was greater than the file size itself in some cases. Signed-off-by: Vignesh Venkatasubramanian vigne...@google.com --- libavformat/matroskadec.c | 11 +++ tests/ref/fate/webm-dash-manifest | 4 ++-- tests/ref/fate/webm-dash-manifest-unaligned-audio-streams | 2 +- tests/ref/fate/webm-dash-manifest-unaligned-video-streams | 2 +- 4 files changed, 11 insertions(+), 8 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] av_lockmgr_register defines behavior on failure.
On Tue, Sep 30, 2014 at 8:16 PM, Michael Niedermayer michae...@gmx.at
wrote:
On Tue, Sep 30, 2014 at 07:34:28PM -0700, Manfred Georg wrote:
Yeah, that seemed a bit odd to meI guess I get to go correct some
calling code.
Here is yet another update with a comment which tells you not to use a
static mutex.
Subject: [PATCH] av_lockmgr_register defines behavior on failure.
The register function now specifies that the user callback should
leave things in the same state that it found them on failure but
that failure to destroy is ignored by ffmpeg. The register
function is also now explicit about its behavior on failure (it now
unregisters the previous callback and destroys all mutex).
---
libavcodec/avcodec.h | 25 -
libavcodec/utils.c | 31 +--
2 files changed, 37 insertions(+), 19 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 94e82f7..dae3612 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -5120,16 +5120,23 @@ enum AVLockOp {
/**
* Register a user provided lock manager supporting the operations
- * specified by AVLockOp. mutex points to a (void *) where the
- * lockmgr should store/get a pointer to a user allocated mutex. It's
- * NULL upon AV_LOCK_CREATE and != NULL for all other ops.
- *
- * @param cb User defined callback. Note: FFmpeg may invoke calls to
this
- * callback during the call to av_lockmgr_register().
- * Thus, the application must be prepared to handle that.
+ * specified by AVLockOp. The mutex argument to the function points
+ * to a (void *) where the lockmgr should store/get a pointer to a user
+ * allocated mutex. It is NULL upon AV_LOCK_CREATE and equal to the
+ * value left by the last call for all other ops. If the lock manager
+ * is unable to perform the op then it should leave the mutex in the
same
+ * state as when it was called. However, when called with
AV_LOCK_DESTROY
+ * the mutex will always be assumed to have been successfully destroyed.
+ * If av_lockmgr_register succeeds it will return 0, if it fails it will
+ * return non-zero and destroy all mutex and unregister all callbacks.
we have no positve error codes, the positive values could be used
as success like 0 giving us the ability to extend/use them for
something in the future
Changed comment. I also changed the code to propagate the error from the
user function. However, to maintain backwards compatibility, I negate any
positive values that the user provides.
+ *
+ * @param cb User defined callback. FFmpeg invokes calls to this
+ * callback and the previously registered callback during the
+ * call to av_lockmgr_register(). The callback will be used
to
+ * create more than one mutex each of which must be backed
+ * by its own underlying locking mechanism (i.e. do not
+ * use a single static object to implement your lock manager).
* If cb is set to NULL the lockmgr will be unregistered.
- * Also note that during unregistration the previously
registered
- * lockmgr callback may also be invoked.
*/
int av_lockmgr_register(int (*cb)(void **mutex, enum AVLockOp op));
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 778bdc6..717c5b1 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -3457,22 +3457,33 @@ AVHWAccel *av_hwaccel_next(const AVHWAccel
*hwaccel)
int av_lockmgr_register(int (*cb)(void **mutex, enum AVLockOp op))
{
if (lockmgr_cb) {
-if (lockmgr_cb(codec_mutex, AV_LOCK_DESTROY))
-return -1;
-if (lockmgr_cb(avformat_mutex, AV_LOCK_DESTROY))
-return -1;
-codec_mutex = NULL;
-avformat_mutex = NULL;
+// There is no good way to rollback a failure to destroy the
+// mutex, so we ignore failures.
+lockmgr_cb(codec_mutex, AV_LOCK_DESTROY);
+lockmgr_cb(avformat_mutex, AV_LOCK_DESTROY);
}
-lockmgr_cb = cb;
+lockmgr_cb = NULL;
+codec_mutex = NULL;
+avformat_mutex = NULL;
why is this moved outside if (lockmgr_cb) ?
Because I didn't want to think about it too hard. :) I moved all three
assignments inside the if statement (after thinking about it for a bit).
-if (lockmgr_cb) {
-if (lockmgr_cb(codec_mutex, AV_LOCK_CREATE))
+if (cb) {
+void *new_codec_mutex = NULL;
+void *new_avformat_mutex = NULL;
+if (cb(new_codec_mutex, AV_LOCK_CREATE)) {
return -1;
-if (lockmgr_cb(avformat_mutex, AV_LOCK_CREATE))
+}
+if (cb(new_avformat_mutex, AV_LOCK_CREATE))
+{
+// Ignore failures to destroy the newly created mutex.
+cb(new_codec_mutex, AV_LOCK_DESTROY);
Re: [FFmpeg-devel] [PATCH] jpeg2000: split off inverse MCT decoding as Jpeg2000DSP
James Almer jamrial at gmail.com writes: This makes the addition of arch optimized functions easier. Do you think that the functions in question are bitexact wrt the specification? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] jpeg2000: split off inverse MCT decoding as Jpeg2000DSP
On 01/10/14 5:22 PM, Carl Eugen Hoyos wrote: James Almer jamrial at gmail.com writes: This makes the addition of arch optimized functions easier. Do you think that the functions in question are bitexact wrt the specification? Carl Eugen The 53 is afaik. The 97 float isn't, which is why there's a 97 int version. How is this relevant anyway? Any simd implementation that's not bitexact would be marked as such. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] jpeg2000: split off inverse MCT decoding as Jpeg2000DSP
James Almer jamrial at gmail.com writes: On 01/10/14 5:22 PM, Carl Eugen Hoyos wrote: James Almer jamrial at gmail.com writes: This makes the addition of arch optimized functions easier. Do you think that the functions in question are bitexact wrt the specification? The 53 is afaik. The 97 float isn't, which is why there's a 97 int version. How is this relevant anyway? I thought that it is not a good idea to write simd optimizations for C functions that are known to be incorrect because tests are difficult. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] av_lockmgr_register defines behavior on failure.
As a further note. I'm pretty sure that none of the tests make use of av_lockmgr_register...so there's very little guarantee that this function is working correctly (particularly now that it has gotten so complicated). Manfred ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Stop demuxing wtv on eof
On Wed, Oct 01, 2014 at 06:18:56PM +0200, Carl Eugen Hoyos wrote:
Hi!
Attached patch fixes the wtv regression described in tickets #3991 and #3995
for me.
Please review, Carl Eugen
diff --git a/libavformat/wtvdec.c b/libavformat/wtvdec.c
index 4cb3295..674ff6e 100644
--- a/libavformat/wtvdec.c
+++ b/libavformat/wtvdec.c
@@ -789,6 +789,8 @@ static int parse_chunks(AVFormatContext *s, int mode,
int64_t seekts, int *len_p
len = avio_rl32(pb);
if (len 32) {
int ret;
+if (avio_feof(pb))
+return AVERROR(EOF);
av_log(s, AV_LOG_WARNING, encountered broken chunk\n);
Please commit. I have tested it also.
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] av_lockmgr_register defines behavior on failure.
On Wed, Oct 01, 2014 at 01:01:33PM -0700, Manfred Georg wrote:
On Tue, Sep 30, 2014 at 8:16 PM, Michael Niedermayer michae...@gmx.at
wrote:
On Tue, Sep 30, 2014 at 07:34:28PM -0700, Manfred Georg wrote:
Yeah, that seemed a bit odd to meI guess I get to go correct some
calling code.
Here is yet another update with a comment which tells you not to use a
static mutex.
Subject: [PATCH] av_lockmgr_register defines behavior on failure.
The register function now specifies that the user callback should
leave things in the same state that it found them on failure but
that failure to destroy is ignored by ffmpeg. The register
function is also now explicit about its behavior on failure (it now
unregisters the previous callback and destroys all mutex).
---
libavcodec/avcodec.h | 25 -
libavcodec/utils.c | 31 +--
2 files changed, 37 insertions(+), 19 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 94e82f7..dae3612 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -5120,16 +5120,23 @@ enum AVLockOp {
/**
* Register a user provided lock manager supporting the operations
- * specified by AVLockOp. mutex points to a (void *) where the
- * lockmgr should store/get a pointer to a user allocated mutex. It's
- * NULL upon AV_LOCK_CREATE and != NULL for all other ops.
- *
- * @param cb User defined callback. Note: FFmpeg may invoke calls to
this
- * callback during the call to av_lockmgr_register().
- * Thus, the application must be prepared to handle that.
+ * specified by AVLockOp. The mutex argument to the function points
+ * to a (void *) where the lockmgr should store/get a pointer to a user
+ * allocated mutex. It is NULL upon AV_LOCK_CREATE and equal to the
+ * value left by the last call for all other ops. If the lock manager
+ * is unable to perform the op then it should leave the mutex in the
same
+ * state as when it was called. However, when called with
AV_LOCK_DESTROY
+ * the mutex will always be assumed to have been successfully destroyed.
+ * If av_lockmgr_register succeeds it will return 0, if it fails it will
+ * return non-zero and destroy all mutex and unregister all callbacks.
we have no positve error codes, the positive values could be used
as success like 0 giving us the ability to extend/use them for
something in the future
Changed comment. I also changed the code to propagate the error from the
user function. However, to maintain backwards compatibility, I negate any
positive values that the user provides.
+ *
+ * @param cb User defined callback. FFmpeg invokes calls to this
+ * callback and the previously registered callback during the
+ * call to av_lockmgr_register(). The callback will be used
to
+ * create more than one mutex each of which must be backed
+ * by its own underlying locking mechanism (i.e. do not
+ * use a single static object to implement your lock manager).
* If cb is set to NULL the lockmgr will be unregistered.
- * Also note that during unregistration the previously
registered
- * lockmgr callback may also be invoked.
*/
int av_lockmgr_register(int (*cb)(void **mutex, enum AVLockOp op));
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 778bdc6..717c5b1 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -3457,22 +3457,33 @@ AVHWAccel *av_hwaccel_next(const AVHWAccel
*hwaccel)
int av_lockmgr_register(int (*cb)(void **mutex, enum AVLockOp op))
{
if (lockmgr_cb) {
-if (lockmgr_cb(codec_mutex, AV_LOCK_DESTROY))
-return -1;
-if (lockmgr_cb(avformat_mutex, AV_LOCK_DESTROY))
-return -1;
-codec_mutex = NULL;
-avformat_mutex = NULL;
+// There is no good way to rollback a failure to destroy the
+// mutex, so we ignore failures.
+lockmgr_cb(codec_mutex, AV_LOCK_DESTROY);
+lockmgr_cb(avformat_mutex, AV_LOCK_DESTROY);
}
-lockmgr_cb = cb;
+lockmgr_cb = NULL;
+codec_mutex = NULL;
+avformat_mutex = NULL;
why is this moved outside if (lockmgr_cb) ?
Because I didn't want to think about it too hard. :) I moved all three
assignments inside the if statement (after thinking about it for a bit).
-if (lockmgr_cb) {
-if (lockmgr_cb(codec_mutex, AV_LOCK_CREATE))
+if (cb) {
+void *new_codec_mutex = NULL;
+void *new_avformat_mutex = NULL;
+if (cb(new_codec_mutex, AV_LOCK_CREATE)) {
return -1;
-if (lockmgr_cb(avformat_mutex, AV_LOCK_CREATE))
+}
+if
Re: [FFmpeg-devel] [PATCH] jpeg2000: split off inverse MCT decoding as Jpeg2000DSP
On 01/10/14 8:04 PM, Michael Niedermayer wrote:
On Wed, Oct 01, 2014 at 05:14:38PM -0300, James Almer wrote:
This makes the addition of arch optimized functions easier.
Signed-off-by: James Almer jamr...@gmail.com
---
libavcodec/Makefile | 2 +-
libavcodec/jpeg2000dec.c | 71 +--
libavcodec/jpeg2000dsp.c | 98
libavcodec/jpeg2000dsp.h | 35 +
libavcodec/jpeg2000dwt.h | 3 +-
5 files changed, 153 insertions(+), 56 deletions(-)
create mode 100644 libavcodec/jpeg2000dsp.c
create mode 100644 libavcodec/jpeg2000dsp.h
[...]
+static void mct_decode97_float(void *_src0, void *_src1, void *_src2, int
csize)
+{
+float *src0 = _src0, *src1 = _src1, *src2 = _src2;
+float i0f, i1f, i2f;
+int i;
+
+for (i = 0; i csize; i++) {
+i0f = *src0 + (f_ict_params[0] * *src2);
+i1f = *src0 - (f_ict_params[1] * *src1)
+- (f_ict_params[2] * *src2);
+i2f = *src0 + (f_ict_params[3] * *src1);
+*src0++ = i0f;
+*src1++ = i1f;
+*src2++ = i2f;
+}
+}
+
+static void mct_decode97_int(void *_src0, void *_src1, void *_src2, int
csize)
+{
+int32_t *src0 = _src0, *src1 = _src1, *src2 = _src2;
+int32_t i0, i1, i2;
+int i;
+
+for (i = 0; i csize; i++) {
+i0 = *src0 + (((i_ict_params[0] * *src2) + (1 15)) 16);
+i1 = *src0 - (((i_ict_params[1] * *src1) + (1 15)) 16)
+ - (((i_ict_params[2] * *src2) + (1 15)) 16);
+i2 = *src0 + (((i_ict_params[3] * *src1) + (1 15)) 16);
+*src0++ = i0;
+*src1++ = i1;
+*src2++ = i2;
+}
+}
+
+static void mct_decode53(void *_src0, void *_src1, void *_src2, int csize)
the function names are not good
the code is not related to the 5/3 and 9/7 wavelets
Well, the code checks for one of the three DWTType values (FF_DWT97,
FF_DWT97_INT and
FF_DWT53) to choose what to run, so these names seemed adequate to me.
What names do you suggest then?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] av_lockmgr_register defines behavior on failure.
[snip]
@@ -3457,22 +3457,53 @@ AVHWAccel *av_hwaccel_next(const AVHWAccel
*hwaccel)
int av_lockmgr_register(int (*cb)(void **mutex, enum AVLockOp op))
{
if (lockmgr_cb) {
-if (lockmgr_cb(codec_mutex, AV_LOCK_DESTROY))
-return -1;
-if (lockmgr_cb(avformat_mutex, AV_LOCK_DESTROY))
-return -1;
+// There is no good way to rollback a failure to destroy the
+// mutex, so we ignore failures.
+lockmgr_cb(codec_mutex, AV_LOCK_DESTROY);
+lockmgr_cb(avformat_mutex, AV_LOCK_DESTROY);
+avpriv_atomic_ptr_cas((void * volatile *)lockmgr_cb,
+ lockmgr_cb, NULL);
+avpriv_atomic_ptr_cas((void * volatile *)codec_mutex,
+ codec_mutex, NULL);
+avpriv_atomic_ptr_cas((void * volatile *)avformat_mutex,
+ avformat_mutex, NULL);
+}
+
+if (lockmgr_cb || codec_mutex || avformat_mutex) {
+// Some synchronization error occurred.
+lockmgr_cb = NULL;
codec_mutex = NULL;
avformat_mutex = NULL;
+return AVERROR(EDEADLK);
}
this should be av_assert0()
we dont want to continue after we know that the variables have
been corrupted
also it could be a seperate patch
I feel that if we use the atomic operation then this should be included in
this patch (since otherwise what's the point in having atomic operations
which we never check whether they succeed. I'd be happy to replace the
atomic operations with = again. Please advise whether I should use
av_assert0() or return to =.
-lockmgr_cb = cb;
-
-if (lockmgr_cb) {
-if (lockmgr_cb(codec_mutex, AV_LOCK_CREATE))
-return -1;
-if (lockmgr_cb(avformat_mutex, AV_LOCK_CREATE))
-return -1;
+if (cb) {
+void *new_codec_mutex = NULL;
+void *new_avformat_mutex = NULL;
+int err;
+if (err = cb(new_codec_mutex, AV_LOCK_CREATE)) {
+return err 0 ? -err : err;
+}
+if (err = cb(new_avformat_mutex, AV_LOCK_CREATE)) {
+// Ignore failures to destroy the newly created mutex.
+cb(new_codec_mutex, AV_LOCK_DESTROY);
+return err 0 ? -err : err;
how does this work ?
It ensures that the returned value is negative on failure. It also passes
through error codes if they are used. Note that we have to do something
with positive values, since even the lock manager in ffplay.c uses a
positive value to denote failure (it uses 1).
return err 0 ? AVERROR(SOMETHING) : err;
would also work (or -1).
Please advise.
if cb() was previously specified to return AVERROR* codes then they
are negative, otherwise if that wasnt specified than above wont
translate its return codes into AVERROR* ones
Correct.
Manfred
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] av_lockmgr_register defines behavior on failure.
On Wed, Oct 01, 2014 at 04:37:21PM -0700, Manfred Georg wrote:
[snip]
@@ -3457,22 +3457,53 @@ AVHWAccel *av_hwaccel_next(const AVHWAccel
*hwaccel)
int av_lockmgr_register(int (*cb)(void **mutex, enum AVLockOp op))
{
if (lockmgr_cb) {
-if (lockmgr_cb(codec_mutex, AV_LOCK_DESTROY))
-return -1;
-if (lockmgr_cb(avformat_mutex, AV_LOCK_DESTROY))
-return -1;
+// There is no good way to rollback a failure to destroy the
+// mutex, so we ignore failures.
+lockmgr_cb(codec_mutex, AV_LOCK_DESTROY);
+lockmgr_cb(avformat_mutex, AV_LOCK_DESTROY);
+avpriv_atomic_ptr_cas((void * volatile *)lockmgr_cb,
+ lockmgr_cb, NULL);
+avpriv_atomic_ptr_cas((void * volatile *)codec_mutex,
+ codec_mutex, NULL);
+avpriv_atomic_ptr_cas((void * volatile *)avformat_mutex,
+ avformat_mutex, NULL);
+}
+
+if (lockmgr_cb || codec_mutex || avformat_mutex) {
+// Some synchronization error occurred.
+lockmgr_cb = NULL;
codec_mutex = NULL;
avformat_mutex = NULL;
+return AVERROR(EDEADLK);
}
this should be av_assert0()
we dont want to continue after we know that the variables have
been corrupted
also it could be a seperate patch
I feel that if we use the atomic operation then this should be included in
this patch (since otherwise what's the point in having atomic operations
which we never check whether they succeed. I'd be happy to replace the
atomic operations with = again. Please advise whether I should use
av_assert0() or return to =.
the point of the 2nd set of atomic operations is to ensure we
dont overwrite a non null pointer
the set above could check that the overwritten pointer equals what
was set before destroy
as they are iam not sure if they provide an advantage over a normal
a=b, iam also not sure the first set is really that usefull
-lockmgr_cb = cb;
-
-if (lockmgr_cb) {
-if (lockmgr_cb(codec_mutex, AV_LOCK_CREATE))
-return -1;
-if (lockmgr_cb(avformat_mutex, AV_LOCK_CREATE))
-return -1;
+if (cb) {
+void *new_codec_mutex = NULL;
+void *new_avformat_mutex = NULL;
+int err;
+if (err = cb(new_codec_mutex, AV_LOCK_CREATE)) {
+return err 0 ? -err : err;
+}
+if (err = cb(new_avformat_mutex, AV_LOCK_CREATE)) {
+// Ignore failures to destroy the newly created mutex.
+cb(new_codec_mutex, AV_LOCK_DESTROY);
+return err 0 ? -err : err;
how does this work ?
It ensures that the returned value is negative on failure. It also passes
through error codes if they are used. Note that we have to do something
with positive values, since even the lock manager in ffplay.c uses a
positive value to denote failure (it uses 1).
return err 0 ? AVERROR(SOMETHING) : err;
would also work (or -1).
Please advise.
AVERROR_EXTERNAL seems like an option
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- 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] jpeg2000: split off inverse MCT decoding as Jpeg2000DSP
On Wed, Oct 01, 2014 at 08:08:18PM -0300, James Almer wrote:
On 01/10/14 8:04 PM, Michael Niedermayer wrote:
On Wed, Oct 01, 2014 at 05:14:38PM -0300, James Almer wrote:
This makes the addition of arch optimized functions easier.
Signed-off-by: James Almer jamr...@gmail.com
---
libavcodec/Makefile | 2 +-
libavcodec/jpeg2000dec.c | 71 +--
libavcodec/jpeg2000dsp.c | 98
libavcodec/jpeg2000dsp.h | 35 +
libavcodec/jpeg2000dwt.h | 3 +-
5 files changed, 153 insertions(+), 56 deletions(-)
create mode 100644 libavcodec/jpeg2000dsp.c
create mode 100644 libavcodec/jpeg2000dsp.h
[...]
+static void mct_decode97_float(void *_src0, void *_src1, void *_src2, int
csize)
+{
+float *src0 = _src0, *src1 = _src1, *src2 = _src2;
+float i0f, i1f, i2f;
+int i;
+
+for (i = 0; i csize; i++) {
+i0f = *src0 + (f_ict_params[0] * *src2);
+i1f = *src0 - (f_ict_params[1] * *src1)
+- (f_ict_params[2] * *src2);
+i2f = *src0 + (f_ict_params[3] * *src1);
+*src0++ = i0f;
+*src1++ = i1f;
+*src2++ = i2f;
+}
+}
+
+static void mct_decode97_int(void *_src0, void *_src1, void *_src2, int
csize)
+{
+int32_t *src0 = _src0, *src1 = _src1, *src2 = _src2;
+int32_t i0, i1, i2;
+int i;
+
+for (i = 0; i csize; i++) {
+i0 = *src0 + (((i_ict_params[0] * *src2) + (1 15)) 16);
+i1 = *src0 - (((i_ict_params[1] * *src1) + (1 15)) 16)
+ - (((i_ict_params[2] * *src2) + (1 15)) 16);
+i2 = *src0 + (((i_ict_params[3] * *src1) + (1 15)) 16);
+*src0++ = i0;
+*src1++ = i1;
+*src2++ = i2;
+}
+}
+
+static void mct_decode53(void *_src0, void *_src1, void *_src2, int csize)
the function names are not good
the code is not related to the 5/3 and 9/7 wavelets
Well, the code checks for one of the three DWTType values (FF_DWT97,
FF_DWT97_INT and
FF_DWT53) to choose what to run, so these names seemed adequate to me.
What names do you suggest then?
the terms used by jpeg2000 are rct and ict, for
Reversible multiple component transformation (RCT)
and
Irreversible multiple component transformation (ICT)
we have 2 implementations of the ICT, one float and one int
so id suggest
ict_float, ict_int, rct_int
maybe throwing a f/i in for forward and inverse, maybe instead not
abbreviating something, i dunno, pick what you prefer
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] patch 1/4: libavcodec/ppc/pixblockdsp.c: fix get_pixels_altivec() and diff_pixels_altivec() for POWER LE
On Tue, Sep 30, 2014 at 07:51:38PM +0200, Reimar Döffinger wrote: On Tue, Sep 30, 2014 at 03:51:55PM +0800, rongyan wrote: Hi, I present 4 patches to fix bugs for POWER8 little endian. I will send 4 patches in 4 different email. This is the first. The fate test result after merge these 4 patches can be found on http://fate.ffmpeg.org/ by search ibmcrl, also attached here to facilitate the review: The passed test cases increased from 1649/2169 to 1675/2174. This one seems wrong. I assume HAVE_VSX is a feature related define, which means it should be possible to disable it without breaking anything. If the altivec implementation is broken on little-endian, the correct bug-fix is to disable it. Then as a next step can a different optimized implementation be added. you mean #if HAVE_VSX #elif HAVE_ALTIVEC HAVE_BIGENDIAN ... #endif ? if so this would also apply to the other patches probably and also to existing code in git though [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] jpeg2000: split off inverse MCT decoding as Jpeg2000DSP
On Wed, Oct 01, 2014 at 10:35:59PM -0300, James Almer wrote: This makes the addition of arch optimized functions easier. Signed-off-by: James Almer jamr...@gmail.com --- libavcodec/Makefile | 2 +- libavcodec/jpeg2000dec.c | 71 +-- libavcodec/jpeg2000dsp.c | 98 libavcodec/jpeg2000dsp.h | 35 + libavcodec/jpeg2000dwt.h | 3 +- 5 files changed, 153 insertions(+), 56 deletions(-) create mode 100644 libavcodec/jpeg2000dsp.c create mode 100644 libavcodec/jpeg2000dsp.h LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: add jpeg2000 support
On Tue, Sep 30, 2014 at 04:08:23PM +0200, Matthieu Bouron wrote: On Tue, Sep 30, 2014 at 3:37 PM, Benoit Fouet benoit.fo...@free.fr wrote: Hi, Hi Benoit, Thanks for your patch. I've reviewed the ULs values and they look good to me. applied thanks this patch adds support for j2k muxing in MXF. tested with: $ ffmpeg -t 5 -f lavfi -i testsrc -y -c:v libopenjpeg -y out.mxf Played back in ffplay (linux), vlc (windows), Acrok MXF converter (windows). I have no idea against what other players this should be tested. Maybe some testing can be done with the bmx tool and check if it reports the stream correctly and is able to extract the video bytestream. Best regards, Matthieu ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] *** GMX Spamverdacht *** Re: patch 1/4: libavcodec/ppc/pixblockdsp.c: fix get_pixels_altivec() and diff_pixels_altivec() for POWER LE
On 02.10.2014, at 03:38, Michael Niedermayer michae...@gmx.at wrote: On Tue, Sep 30, 2014 at 07:51:38PM +0200, Reimar Döffinger wrote: On Tue, Sep 30, 2014 at 03:51:55PM +0800, rongyan wrote: Hi, I present 4 patches to fix bugs for POWER8 little endian. I will send 4 patches in 4 different email. This is the first. The fate test result after merge these 4 patches can be found on http://fate.ffmpeg.org/ by search ibmcrl, also attached here to facilitate the review: The passed test cases increased from 1649/2169 to 1675/2174. This one seems wrong. I assume HAVE_VSX is a feature related define, which means it should be possible to disable it without breaking anything. If the altivec implementation is broken on little-endian, the correct bug-fix is to disable it. Then as a next step can a different optimized implementation be added. you mean #if HAVE_VSX #elif HAVE_ALTIVEC HAVE_BIGENDIAN ... #endif ? if so this would also apply to the other patches probably and also to existing code in git though Yes, I saw that its already done like that in a lot of places, which also should be changed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
