[Ffmpeg-devel-irc] ffmpeg-devel.log.20140121

[burek]

[01:05] <lukaszmluki> Hi, can I ask somebody to review http://ffmpeg.org/pipermail/ffmpeg-devel/2014-January/153441.html - at least doc update part, I want to send pull request with some other commits before going sleep.
[01:11] <Zeranoe> Does ffplay support SDL 2.x?
[01:13] <lukaszmluki> i think ffmpeg in general support only 1.2 unless you change configure
[01:28] <kierank> lukaszmluki: why does it need inlining
[01:30] <lukaszmluki> it does not, but i wont be called anything else
[01:35] <BBB> ?
[01:47] <mark4o> lukaszmluki: The option is the private key itself, or a file name, or full path name?  The doc should be more clear.
[01:47] <mark4o> lukaszmluki: s/search for keys in/searches for keys in the/
[01:47] <mark4o> lukaszmluki: s/invalid or not existing key/an invalid or nonexistent key/
[01:48] <mark4o> lukaszmluki: s/successed/successful/
[01:49] <lukaszmluki> ok, thanks
[01:52] <BBB> lukaszmluki: if not performance-critical, we typically prefer to not mark with inline attribute and leave it to the compiler
[01:53] <BBB> inline etc. should only be used in performance-critical code
[01:53] <lukaszmluki> got it, i'm removing it
[01:53] <BBB> ty
[01:58] <lukaszmluki> just as question, does it matte when you move some code for better readability  to a function and make it inline?
[01:59] <lukaszmluki> i guess compiler figure it out, but it wont hurt to make a hint
[02:06] <BBB> lukaszmluki: again, all this depends on how performance critical it is
[02:06] <BBB> lukaszmluki: typically it won't matter either way
[02:07] <BBB> lukaszmluki: but in inner loop function in audio and video decoders, there's special needs, so to say, so then it sometimes makes a measurable difference
[02:12] <lukaszmluki> I see . Sometimes it is hard to know what is better :)
[02:13] <lukaszmluki> I hope av_cold is ok anyway because it added it :)
[02:13] <BBB> av_cold means "is only called during initialization"
[02:13] <BBB> so it's probably ok
[02:28] <Timothy_Gu> FFmpeg is now used to endorse Coverity: http://blog.coverity.com/2013/06/18/scanning-ffmpeg-for-your-audio-video-enjoyment/
[02:37] <Compn> huh
[02:37] <Compn> they dedicate 13 pages to ffmpeg in their 2012 report too
[03:27] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:63d2be7533b7: avcodec/x86/lossless_videodsp: use SPLATW in add_int16
[03:27] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:83b67ca05609: avcodec/x86/lossless_videodsp: Port lorens add_hfyu_left_prediction_ssse3/sse4 to 16bit
[03:27] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:3715f9e2c68b: avcodec/lossless_videodsp: fix diff_int16_c on MIPS
[03:27] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:13e0109a5f2c: fate: add a few tests for >8bpc ffvhuff
[04:11] <cone-469> ffmpeg.git 03Justin Ruggles 07master:d01e684186bc: mov: do not set avg_frame_rate in the demuxer
[04:11] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:e9b836cd87c2: Merge commit 'd01e684186bc1631bc176f06b89d33c27ec0d24d'
[04:11] <michaelni> Daemon404, do you have a sample / can you share it that shows wrong fps value ?
[04:13] <michaelni> also did someone compare the wrong code in mov against the default code in terms of which is more accurate for more (real world) files ?
[04:20] <cone-469> ffmpeg.git 03Martin Storsjö 07master:24eb3c791606: rtmpproto: Avoid using uninitialized memory
[04:20] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:ca9d7c57f4b0: Merge commit '24eb3c791606fe98a1591c13a8b2ba6c342bb3b5'
[04:26] <cone-469> ffmpeg.git 03Martin Storsjö 07master:89564be444d2: rtmpproto: Send a full, absolute timestamp if it isn't monotonically growing
[04:26] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:1c7d2870440f: Merge commit '89564be444d24f75ea5add8b6987e414cf7aa7d5'
[04:36] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:dd2d0039b640: vc1: Always reset numref when parsing a new frame header.
[04:36] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:a459891e624c: Merge remote-tracking branch 'qatar/master'
[06:11] <Guest66336>  while compiling ffmpeg i'm getting error /usr/bin/ld.bfd.real : libavutils/aes.o : reloaction R_ARM_THM_MOVW_ABS_NC against a 'local symbol' cannot be used when making a shared object, recompile with -fPIC   libavutils/aes.o : could not read symbols : Bad value
[08:17] <anshul> I was using mjpeg codec from libavcodec, I am getting [mjpeg @ 0xaaf14d20] overread 8 message in the new git code, while I am not getting any error in the fourier release of ffmpeg
[10:01] <nguydavi> Hello ! Can anyone tell me if there is a date for ffmpeg release 2.2 ? As there are many securities patches recently, I would like to know if it's better to wait for the next release or apply all the patches now.
[10:28] <anshul> nguyadavi: if you are not distributor why not use git
[11:56] <cone-745> ffmpeg.git 03Stefano Sabatini 07master:e34ad128a363: examples/muxing: reduce duration, remove wrong and misleading comment
[12:31] <saste> ubitux: https://trac.ffmpeg.org/ticket/3093
[12:32] <saste> you wrote: Filtering audio still needs to some adjustments.
[12:32] <saste> what's wrong with it?
[12:32] <saste> should it use the refcounted obscure API?
[12:40] <nguydavi> I am asking if there are any dates for the next release because I am interested in certain patches such as 459db51271807ba26162db7b67ac1ff444cc0fa9, e630ca5111077fa8adc972fe8a3d7e2b3e8dc91f, 165f96cd2d687122748f862a0bc6e9908fe3d5d2 and more. From the shortlog of 2.1.3 I couldn't find those commits.
[13:03] <Daemon404> michaelni, see pm
[14:12] <sspiff> ubitux: the leak is gone for me
[14:13] <ubitux> send a patch :p
[14:13] <sspiff> the indentation is wrong in that function, can I fix that in the same patch?
[14:17] <ubitux> better not
[14:23] <michaelni> anshul, how can that jpeg issue be reproduced ?
[14:31] <michaelni> nguydavi, these 3 dont look security relevant, 2 are memleaks the 3rd is a assert failure with non default build flags
[14:34] <nguydavi> michaelni, I am interested to know what release will include these commits http://secunia.com/advisories/56352/
[14:36] <nguydavi> michaelni, and if there is an approximate date, I would like to know if it's better to manually apply the patches or simply wait for the next release
[14:47] <wm4> Gynvael Coldwind really is a cool name
[14:49] <michaelni> nguydavi, these commits seem to be a random list of commits, certainly not a list you blindly want to backport ,some of which like 75647dea6f7db79b409bad66a119f5c73da730f3 are backports of ffmpeg fixes in a fork, this one for exxample was fixed in 9ed388f5985992a0a6a43fdc0b1732962b6b5619 in ffmpeg
[14:51] <nguydavi> michaelni, oh so all of these fixes should be included in 2.1.3 ?
[14:52] <michaelni> no, some are missing though the ones i saw did look like normal everyday bugs not security issues, but iam not through with the list yet
[14:53] <michaelni> ill make sure they get backported to the next 2.1 release
[14:53] <nguydavi> great ! thanks ! do you know when is the next release ?
[14:54] <nguydavi> (thank you very much for your time btw, michaelni)
[14:54] <michaelni> dunno about release dates
[14:55] <nguydavi> ok
[14:57] <nguydavi> thanks again for your time
[15:10] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:a7a07cc98ac5: hevc: check that VPS referenced from SPS exists
[15:10] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:42a29015e1bd: Merge commit 'a7a07cc98ac548297b5b0628cb81280e11952e3f'
[15:15] <michaelni> Daemon404, thx, will look at it later
[15:16] <Daemon404> k
[15:16] <Daemon404> we get anough of those samples that we actually remporarily patched ffmpeg in production with that patch
[15:16] <Daemon404> enough*
[15:16] <Daemon404> (that is currently the only modification to ffmpeg)
[15:18] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:d5c15ebeaf19: hevc: Fix modulo operations
[15:18] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:7c4b96f55eb6: Merge commit 'd5c15ebeaf1914ea5e3e0599d4316d7c4cf74434'
[15:24] <cone-745> ffmpeg.git 03Luca Barbato 07master:b37e796082b2: hevc: Use uint64 to check for tile dimensions
[15:24] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:29ba1cff2b79: Merge commit 'b37e796082b2d787aff3cd5631bb89c4fd374708'
[15:27] <cone-745> ffmpeg.git 03Guillaume Martres 07master:a246d06fe0dc: hevc: clip pixels when transquant bypass is used
[15:28] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:ee3e1951af5c: Merge commit 'a246d06fe0dc6c2ea65e95327624b4537ff9bd0d'
[15:30] <cone-745> ffmpeg.git 03Guillaume Martres 07master:faf03ecba031: hevc: Remove useless clip
[15:30] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:c7b454f7a42e: Merge commit 'faf03ecba03155bb1f5416713bd01da043863b43'
[15:36] <cone-745> ffmpeg.git 03Luca Barbato 07master:838740e64205: hevc: Prevent some integer overflows
[15:36] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:5b93b2722dea: Merge commit '838740e6420538ad45982da6b1d3aa3ae91307f5'
[15:39] <cone-745> ffmpeg.git 03Luca Barbato 07master:0d999333f96a: hevc: Bound check slice_qp
[15:40] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:58f437c3f667: Merge commit '0d999333f96a34903448579bf13a3209deaee9da'
[15:53] <cone-745> ffmpeg.git 03Luca Barbato 07master:e22ebd04bcab: hevc: Bound check cu_qp_delta
[15:54] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:a69dd1163b1a: Merge commit 'e22ebd04bcab7f86548794556c28ecca46d9c2ac'
[16:01] <cone-745> ffmpeg.git 03Sam Lantinga 07master:5b2b23f2d69e: dxva2: Retry IDirectXVideoDecoder_BeginFrame()
[16:01] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:9056d0c94af5: Merge commit '5b2b23f2d69e05c5fcd1c933e383fe60e185574d'
[16:09] <cone-745> ffmpeg.git 03Sam Lantinga 07master:9d80b1ae9590: dxva2: Log errors verbosely
[16:09] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:91f4394ed31e: Merge remote-tracking branch 'qatar/master'
[16:16] <Daemon404> ... 90 comments
[16:16] <Daemon404> wow
[16:16] <nevcairiel> the first 80 or so are clueless people poking at random things
[16:16] <nevcairiel> took me 30 minutes to fix the actual issue
[16:17] <nevcairiel> first 70 is more accurate
[16:17] <Daemon404> sounds about right
[16:17] <nevcairiel> the last couple is just some xbmc dudes worrying that one allocation per slice is going to hurt their performance
[16:18] <Daemon404> i am not a big fan of the xbmc devs' practies.
[16:18] <Daemon404> at all.
[16:57] <cone-745> ffmpeg.git 03Michael Niedermayer 07release/2.1:e6299a4cf9ef: cmdutils: update year
[16:57] <cone-745> ffmpeg.git 03Michael Niedermayer 07release/2.1:c9a8dfa5ae16: Merge commit '6892d145a0c80249bd61ee7dd31ec851c5076bcd'
[16:57] <cone-745> ffmpeg.git 03Michael Niedermayer 07release/2.1:9e8464e81bfe: Merge commit '9eef9eb3014b2ed9c3ff4aac510a9f04edb555cf'
[16:57] <cone-745> ffmpeg.git 03Michael Niedermayer 07release/2.1:23ae7bfb4e94: dnxhdenc: fix mb_rc size
[16:57] <cone-745> ffmpeg.git 03Michael Niedermayer 07release/2.1:94e2673f4e45: avformat/ape: free packet on avio_read() failure
[16:58] <cone-745> ffmpeg.git 03Michael Niedermayer 07release/2.1:d35916f6ea49: avformat/mpegts: check sl.timestamp_len
[16:58] <cone-745> ffmpeg.git 03Michael Niedermayer 07release/2.1:fedbba5ea051: avformat/rmdec: move packet allocation down
[16:58] <cone-745> ffmpeg.git 03Michael Niedermayer 07release/2.1:5f56e495aea4: avcodec/apedec: more checks for k
[17:46] <cone-745> ffmpeg.git 03Michael Niedermayer 07release/2.1:32262ca7d781: avcodec/vmnc: Check  that rectangles are within the picture
[17:46] <cone-745> ffmpeg.git 03Michael Niedermayer 07release/2.1:a8ed3685e193: avcodec/jpeg2000dec: fix error detection in pix_fmt_match()
[19:20] <saste> ffmpeg -f lavfi -i testsrc -c:v h264 -map 0 -f segment x-%d.ts
[19:20] <saste> michaelni, this leads to a crash ^^
[19:28] <ubitux> saste: for the audio filtering, as i said, there was the memleak/error, and the splitted packets
[19:32] <saste> ubitux, there was / there is?
[19:32] <saste> i tested with valgring, found no leaks
[19:43] <saste> michaelni, was a segment problem...
[19:44] <michaelni> ahh ok, i just wanted to take a look :)
[19:47] <cone-745> ffmpeg.git 03Reimar Döffinger 07master:76421982d042: lossless_videodsp.asm: fix compilation.
[19:53] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:8e5e84c2a2a2: avformat/mov: Ignore the last frame for duration and fps calculation if it looks suspect
[20:10] <cone-745> ffmpeg.git 03Stefano Sabatini 07master:b539a72bba30: examples/filtering_audio,video: drop call to avcodec_get_frame_defaults()
[20:11] <cone-745> ffmpeg.git 03Stefano Sabatini 07master:a2e78161ce77: lavf/mpegtsenc: fix weird indent
[20:11] <cone-745> ffmpeg.git 03Stefano Sabatini 07master:169065fbfb3d: lavf/segment: remove duplicated and inconsistent cleanup code in seg_write_packet()
[20:11] <cone-745> ffmpeg.git 03Stefano Sabatini 07master:f57baf743f0e: lavf/segment: drop pointless variable oc from seg_write_packet()
[20:43] <ubitux> saste: i guess that's ok
[20:45] <cone-745> ffmpeg.git 03Diego Biurrun 07master:766df7ca89a2: dxva2: Add missing #includes
[20:45] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:075989c33c84: Merge commit '766df7ca89a2398e71182f5f2b46053e3aa9bd69'
[20:46] <saste> ubitux, so, shall we close the ticket?
[20:46] <ubitux> go ahead
[21:01] <cone-745> ffmpeg.git 03Diego Biurrun 07master:ade4ecb42d2d: dxva2: Use correct printf format strings
[21:01] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:57a0c5fa9ca2: Merge commit 'ade4ecb42d2dacd18d04eb8df2afa8131e5ad653'
[21:08] <cone-745> ffmpeg.git 03Kostya Shishkov 07master:e91a3f1bdba9: dxtory: correctly handle YUV slices with average odd height
[21:08] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:9eb954b91d36: Merge commit 'e91a3f1bdba9b4945e42c191d2e35e9844625fb4'
[21:25] <cone-745> ffmpeg.git 03Kostya Shishkov 07master:025fd76e1a26: dxtory: change error code for unexpected slice configuration
[21:25] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:a298f934ec9b: Merge commit '025fd76e1a2623c858d8c686a73cc30980a314b0'
[21:44] <cone-745> ffmpeg.git 03Anton Khirnov 07master:e0ab5078a7d8: lavc: do not force the emu edge flag
[21:44] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:8a77baae6e79: Merge commit 'e0ab5078a7d865f8f6fd6a6d3cbe0f380ead4a3d'
[21:54] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:eb01a25fe145: swscale: fix stride used in planarToNv12Wrapper()
[21:54] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:797d807869f0: Merge commit 'eb01a25fe1452740a7f3ae2cbaff356a5c6e7806'
[22:00] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:9047491f8bcd: swscale: add nv12/nv21->yuv420 converter
[22:01] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:53feab7a4e99: Merge commit '9047491f8bcd87673eed55fb310647a03b0981e9'
[22:09] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:7597e6efe492: swscale/x86/rgb2rgb: add support for AVX
[22:09] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:ef25595b7181: Merge commit '7597e6efe492cb2449bb771054d64cc7fdf62ff5'
[22:13] <saste> merging lavd into lavf, any thought?
[22:14] <kierank> see my response
[22:14] <saste> kierank, "oh my god no" that's not really an argument :)
[22:15] <nevcairiel> i agree with kierank's arguments
[22:24] <JEEB> is this still about that one person trying to make lavd take in lavf packets and do VO with it or whatever?
[22:24] <nevcairiel> nah this is about a certain anton wanting to merge them
[22:33] <wm4> that shit makes me semi-mad... if someone really wants to add video and audio output to ffmpeg, why not create a new API, instead of coercing it into the muxing API?
[22:34] <nevcairiel> isnt most of the stuff in there input anyway
[22:34] <wm4> yes, I guess it used to be for capturing video from various sources
[22:35] <wm4> and then someone had the idea to use it for output
[22:37] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:91c981857bc6: rgb2rgb_template: add MMX/SSE2/AVX-optimized deinterleaveBytes
[22:37] <cone-745> ffmpeg.git 03Michael Niedermayer 07master:977abf9aedec: Merge remote-tracking branch 'qatar/master'
[23:02] <Daemon404> michaelni, did you get a chance to look at that sample?
[23:02] <Daemon404> since i noticed tou didnt merge justins patch
[23:02] <Daemon404> s/tou/you//
[23:05] <michaelni> Daemon404, see 8e5e84c2a2a21a979b48e80c5a8dd44754ab3f21
[23:06] <Daemon404> im not sure i think thats a great idea
[23:06] <Daemon404> a lot of the problem files we get are only slightly longr or shorter than the track says
[23:07] <Daemon404> but enough to make it noticable
[23:07] <Daemon404> e.g. 8:20 vs 8:30
[23:08] <nevcairiel> didnt someone comment on the patch, saying the duration used there is derived from the wrong data, which is why it produces wrong fps  results
[23:08] <Daemon404> well
[23:09] <Daemon404> more like track duration is container defined
[23:09] <Daemon404> and not related to the real turation
[23:09] <Daemon404> container lies.
[23:09] <Daemon404> which is why it should be removed
[23:10] <wm4> is there a way yet to update track duration mid-playback
[23:11] <Daemon404> im going to have to keep patching ffmpeg in production if thats the solution...
[23:14] <michaelni> Daemon404, can you share a file where the my change fails =
[23:14] <michaelni> s/=/?/
[23:15] <Daemon404> i dont have a ginat collection ive saved
[23:15] <Daemon404> but in general i dont understand why we choose to believe the container
[23:16] <nevcairiel> the container also has the timestamps
[23:16] <nevcairiel> you gotta believe it somehow
[23:16] <Daemon404> well yes
[23:16] <nevcairiel> isnt the duration just computed by adding up all timestamps or something
[23:16] <Daemon404> you can
[23:16] <Daemon404> but duration is a single coded value in a mov
[23:16] <nevcairiel> mp4 is one of these formats where the info is actually neatly available
[23:17] <Daemon404> and its wrong
[23:17] <Daemon404> a lot.
[23:17] <Daemon404> you can also get teh duration by parsing timestmaps, or doing stuff with stts
[23:17] <nevcairiel> the code michaelni fixed looked like it was doing something with stts, iirc
[23:18] <nevcairiel> not reading the container duration header
[23:18] <Daemon404> its making up a sample_duration as far as ican tell
[23:18] <Daemon404> based on heuristics
[23:19] <nevcairiel> i guess the last stts can also be easily wrong, since it can contain a much larger sample count then it has actual samples
[23:19] <nevcairiel> who would ever notice
[23:19] <Daemon404> i rely on avg_frame_rate ;)
[23:19] <michaelni> stts data in fps.mov contains a lost sample thats very long
[23:19] <michaelni> lAst
[23:20] Action: nevcairiel still uses r_frame_rate for some reason
[23:20] <Daemon404> dont worry
[23:20] Action: nevcairiel forgot if there was a difference
[23:20] <Daemon404> we're dumping avg_frame_rate soon
[23:20] <Daemon404> using our own code
[23:20] <Daemon404> nevcairiel, yes
[23:20] <Daemon404> theyre entirely different things
[23:20] <nevcairiel> i'm not too worried about the framerate being wrong in any case
[23:21] <nevcairiel> its really just informational
[23:21] <nevcairiel> cant assume its cfr anyway, since you never know
[23:21] <Daemon404> i dont
[23:21] <Daemon404> this is for picking an output framerate
[23:22] <Daemon404> we normalize to cfr
[23:22] <Daemon404> not somethign lav would have to o
[23:22] <Daemon404> do
[23:22] <nevcairiel> thats really the only thing it might be used for in directshow too, determining the frame rate to switch your display to
[23:22] <nevcairiel> s/frame/refresh/
[23:23] <Daemon404> that never works well for me unless i use d3d rendering
[23:23] <Daemon404> which is super annoying since mpc-hc doesnt render a seekba then
[23:23] <JEEB> exclusive mode that is
[23:23] <Daemon404> yes
[23:23] <nevcairiel> mpc-hcs built in switcher is stupid
[23:24] <Daemon404> and yet nothing better exists
[23:24] <nevcairiel> can only hope the new vesa vfr standard makes it into consumer hardware
[23:25] <nevcairiel> (and not only gaming displays to battle vsync issues)
[23:25] <JEEB> yeah
[23:25] <JEEB> user-based refresh would be nice
[23:25] <Daemon404> ... consumer hardware doesnt even implement vesa stuff rght as it is
[23:25] <nevcairiel> no need to change  refresh, just pain the image when it comes in
[23:25] <nevcairiel> paint*
[23:25] <Daemon404> and you expect it to do that?
[23:25] <Daemon404> lol.
[23:25] <nevcairiel> AMD is pushing it for gaming
[23:26] <nevcairiel> maybe TVs will also pick it up
[23:26] <nevcairiel> because of consoles
[23:26] <nevcairiel> who knows
[23:31] <michaelni> Daemon404, about e.g. 8:20 vs 8:30 the heursitic will drop the last frame from the average if its bigger than 10 times the average, a 10sec long last frame will always be droped
[23:31] <Daemon404> hmm ok
[23:32] <michaelni> also either way i want this to be as accurate and fast as possible i dont care if its done with that heuristic or something else
[23:34] <Daemon404> we will see how it works in practice
[23:34] <Daemon404> whenever we roll out a new build
[00:00] --- Wed Jan 22 2014