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

[burek]

[01:47] <cone-365> ffmpeg.git 03Carl Eugen Hoyos 07master:e705d0ce1cd3: Set dwSuggestBufferSize to largest chunk size for every stream in avi.
[03:47] <cone-365> ffmpeg.git 03Olivier Langlois 07master:76191c08f88f: ffmpeg: Use av_gettime_relative()
[06:08] <john2_> I'm considering trying to add support for displaying pre-existing subtitles after seeking to the MKV demuxer, and I had a couple questions about implementation.
[06:09] <john2_> Specifically, should I just make the demuxer's read_packet function return the pre-existing subtitle packets before returning anything else after the seek?
[06:10] <john2_> If so, will the fact that the timecodes of the pre-exisintg subtitles come before the current timecode cause any problems with codecs/consumers?
[06:12] <john2_> (An example of pre-existing subtitles is if we have a video with a subtitle that is on-screen from timecode 00:05 to 00:10 and I seek to 00:7.)
[06:25] <jamrial> can't help you much since this is not my field of expertise, but afaik the CueDuration element was introduced specifically for this
[06:26] <jamrial> http://lists.matroska.org/pipermail/matroska-devel/2012-September/004249.html this is an old email proposing the element. it's been in the spec for a while and might have changed some
[06:27] <jamrial> so at least in theory, devices/demuxers that support that element should be able to handle pre-existing subtitles just fine
[06:29] <jamrial> ffmpeg has been muxing matroska files with that element for a while. the demuxer however ignores it
[06:45] <cone-365> ffmpeg.git 03Michael Niedermayer 07master:4a30f08505a4: avcodec/diracdec: move mc buffer allocation to per frame
[10:18] <kurosu> crash: make fate-h264-reinit-small_420_8-to-large_444_10 CPUFLAGS=sse2
[10:19] <kurosu> fault in ff_hscale8to15_X8_sse2
[10:19] <kurosu> pmaddwd (%r10,%rax,2),%xmm1
[10:19] <kurosu> p/x $rax
[10:19] <kurosu> $3 = 0x1
[10:19] <kurosu> can't pmaddwd from an unaligned address
[10:20] <kurosu> p/x $r10+2*$rax : 0x8ba8b42 btw
[10:20] <kurosu> ($r10 is aligned)
[10:21] <nevcairiel> at least the crash is not in h264 code ;)
[10:22] <kurosu> well, if you intend to test a change that is evaluated by h264, h264 better be working without the change ;)
[10:23] <nevcairiel> that doesnt sound like something that might occur randomly though, and that test passes   in fate generally
[10:24] <kurosu> CPUFLAGS=sse or not specifying CPUFLAGS passes
[10:25] <kurosu> so I guess the issue occurs whenever the cpu isn't > SSE2
[10:25] <kurosu> CPUFLAGS=sse4.2 passes
[10:26] <kurosu> CPUFLAGS=sse4 doesn't crash but is incorrect
[10:26] <kurosu> CPUFLAGS=ssse3 crashes, CPUFLAGS=sse3 (does it exist?) passes
[10:27] <kurosu> I guess a sse2-only device is really needed for fate :D
[10:27] <kurosu> well =<sse2
[10:28] <kurosu> is that swscale or swresample or ?
[10:28] <nevcairiel> swscale
[10:29] <nevcairiel> libswscale\x86\scale.asm
[10:29] <nevcairiel> the only line matching that would be 292
[10:29] <nevcairiel> i think
[10:32] <kurosu> well, it was to fill a bugreport
[10:32] <kurosu> I'm not going to dig into swscale
[10:51] <kurosu> the issue is most probably in the calling code, as i'm wondering what's to scale when the filter size is 1 (haven't checked what it does actually)
[14:02] <cone-612> ffmpeg.git 03Mickaël Raulet 07master:04db5794cd97: hevc: templatize pred_planar
[14:02] <cone-612> ffmpeg.git 03Michael Niedermayer 07master:93318983c3e5: Merge commit '04db5794cd97e4b33ec2f963ef7f967722a456eb'
[14:18] <cone-612> ffmpeg.git 03Anton Khirnov 07master:a1c2b48018b0: hevc: templatize intra_pred
[14:18] <cone-612> ffmpeg.git 03Michael Niedermayer 07master:844765855000: Merge commit 'a1c2b48018b09d2613f075ec0748c95bd520ac00'
[14:27] <Voicu> any ideas why I get the entire buffer in the extradata field instead of just the necessary amount?
[14:28] <Voicu> i.e. I open a buffer and av_find_stream_info consumes the entire buffer and puts it in the extradata field
[14:28] <Voicu> instead of just the 25bytes or so the h264 codec would need
[14:28] <Voicu> I also get the whole thing as a single frame when I do av_read_frame afterwards
[14:34] <cone-612> ffmpeg.git 03Mickaël Raulet 07master:4c390b1ba98e: hevc/intra_pred: optimize EXTEND_()*
[14:34] <cone-612> ffmpeg.git 03Michael Niedermayer 07master:454920187f15: Merge commit '4c390b1ba98e6aec787aa0e7ea57ed7cb38283b7'
[14:54] <cone-612> ffmpeg.git 03Mickaël Raulet 07master:25bb7eaf9eb1: hevc/intra_pred: drop unnecessary conditions in loops
[14:54] <cone-612> ffmpeg.git 03Michael Niedermayer 07master:e98d3a7d51da: Merge commit '25bb7eaf9eb14e6e00264bf584aa4d380d3bc29f'
[15:09] <cone-612> ffmpeg.git 03Anton Khirnov 07master:c9f8809ee4c5: hevc/intra_pred: simplify neighboring sample derivation
[15:10] <cone-612> ffmpeg.git 03Michael Niedermayer 07master:3791741cf97f: Merge commit 'c9f8809ee4c576d5833865039bc1c85754448f67'
[15:36] <cone-612> ffmpeg.git 03Anton Khirnov 07master:dc40d88625d7: avconv: do not use poorly defined and undocumented AVStream.pts
[15:36] <cone-612> ffmpeg.git 03Michael Niedermayer 07master:2de2b991cac6: Merge commit 'dc40d88625d7e402d58ac3f3df69fbf27aa31ea0'
[15:36] <cone-612> ffmpeg.git 03Michael Niedermayer 07master:87f5ede6b52e: ffmpeg: add last_mux_dts_plus_duration
[16:47] <kurosu> nevcairiel, are you "he(ndrik)leppkes" ?
[16:47] <nevcairiel> yes
[16:48] <kurosu> regarding the bug on which you commented, for some reason, the sse4 code doesn't crash
[16:48] <kurosu> doesn't make sense, but running without CPUFLAGS makes it pass
[16:48] <kurosu> and my CPU has sse4.x at best
[16:49] <kurosu> but the ssex instances should be all affected
[16:49] <kurosu> I suspect the real issue is to try and convolve with a filter of size 1
[16:50] <kurosu> maybe it is intended to be generic, but sounds like unnecessary complexity
[16:56] <kurosu> nevcairiel, could you check if those tests fails for you (as you tested the above):
[16:56] <kurosu> make fate-msmpeg4v1 CPUFLAGS=mmxext
[16:56] <kurosu> make fate-msmpeg4v1 CPUFLAGS=sse2
[16:56] <kurosu> both fail for me
[16:58] <kurosu> mmx+mmxext/sse2 does not fail
[16:58] <kurosu> maybe I'm the one failing at understanding CPUFLAGS
[17:22] <nevcairiel> my bet is there is some stupid check somewhere that checks for if flags & MMX or something to change behaviour, but doesnt account for SSE2 only being enabled
[17:35] <Plorkyeran> 0eec06ed8747923faa6a98e474f224d922dc487d appears to have broken statically linking ffmpeg with gcc on linux for me
[17:35] <Plorkyeran> there's a configure check for if -lrt is needed for clock_gettime
[17:35] <Plorkyeran> but it only adds -lrt to lavc's libs in the pkg-config file
[17:36] <Plorkyeran> so the new usage in libavutil fails to link
[17:40] <kurosu> michaelni, is running a fate test with eg only CPUFLAGS=sse2 supported? or should I specify CPUFLAGS=mmx+mmxext+sse2?
[17:42] <michaelni> Plorkyeran, mail the author
[17:43] <michaelni> kurosu, only sse2 possibly is not as theres no such cpu, but either the code should print a warnng or work it shouldnt just fail
[17:47] <kurosu> ok I guess it is ok to assume mmx+mmxext+sse2 in the code
[17:47] <kurosu> I'm going to run CPUFLAGS=mmx+mmxext out of curiosity (one test failing it seems)
[17:50] <michaelni> we have a fate client that tests mmx+mmxext "http://fate.ffmpeg.org/report.cgi?time=20140519042836&slot=x86_32-debian-kfreebsd-gcc-4.4-cpuflags-mmx2"
[17:50] <michaelni> though its hw supports more
[17:53] <kurosu> fate-msmpeg-v1 was failing here but I'll confirm later on
[17:53] <kurosu> (can't remember the test name actually and can't verify atm)
[17:53] <kurosu> win64
[18:31] <kurosu> bah, passes now...
[18:33] <cone-612> ffmpeg.git 03Anton Khirnov 07master:ed7922faac4e: mux: drop one of the hacks comprising compute_pkt_fields2()
[18:34] <cone-612> ffmpeg.git 03Michael Niedermayer 07master:dad54e4a62ae: ffmpeg: set dts for subtitles
[18:34] <cone-612> ffmpeg.git 03Michael Niedermayer 07master:6552e23d560c: avformat/mpegtsenc: fix dts for chained muxing aac in mpegts
[18:34] <cone-612> ffmpeg.git 03Michael Niedermayer 07master:ebbc33a42d1d: avcodec/libmp3lame: do not attempt to flush lame if no data was input
[18:34] <cone-612> ffmpeg.git 03Michael Niedermayer 07master:f29cdfec961d: avcodec/libvorbisenc: do not attempt to flush if no data was input
[18:34] <cone-612> ffmpeg.git 03Michael Niedermayer 07master:e3c1d9a56c71: Merge commit 'ed7922faac4ea4c893efc3cdf8102ebc49fcc011'
[18:49] <cone-612> ffmpeg.git 03Anton Khirnov 07master:a312f71090ee: lavf: deprecate now unused AVStream.pts
[18:49] <cone-612> ffmpeg.git 03Michael Niedermayer 07master:999a99c865cc: Merge commit 'a312f71090ee620ee252f2034aef6b13e2dafe9c'
[18:50] <michaelni> ubitux, can you check if dad54e4a62ae5d81c33530f2748f57e40363921d is correct ? (not setting dts for subtitles doesnt mean it gets the correct value thus it really has to be set but i dont know if thats the correct value)
[18:56] <cone-612> ffmpeg.git 03Anton Khirnov 07master:cdf58f0599c3: avpacket: fix copying side data in av_packet_copy_props()
[18:56] <cone-612> ffmpeg.git 03Michael Niedermayer 07master:4a2fd251f477: Merge commit 'cdf58f0599c39852ee3beafe5f64af7d57d4215b'
[19:01] <ubitux> michaelni: well, in the subtitles demuxing api we do set dts=pts all the time
[19:01] <ubitux> now i don't know if that is meaningful for muxing in ts & friends
[19:01] <ubitux> so& i have no idea
[19:01] <ubitux> is that fixing anything?
[19:02] <ubitux> ah it's after the drop from AVStream.pts
[19:02] <ubitux> michaelni: shouldn't it be set in lavf itself?
[19:03] <ubitux> because if that's necessary, won't it break apps?
[19:03] <michaelni> maybe, also i didnt merge that removial yet as it breaks other things
[19:04] <michaelni> (as written in the commit message)
[19:05] <michaelni> about fixing anything, dts is needed for many muxers to know packet ordering, i dont know if the value and ordering is what ts expects
[19:07] <michaelni> also the dts = nopts support removial itself can also break apps
[19:08] <michaelni> iam also not sure we should try to remove it or if its actually a usefull feature, ffmpeg does use it in some cases
[19:08] <cone-612> ffmpeg.git 03Anton Khirnov 07master:9929b3564c0d: pthread_frame: simplify the code by using new AVPacket API
[19:08] <cone-612> ffmpeg.git 03Michael Niedermayer 07master:af72f62d7b2a: Merge commit '9929b3564c0dca42ed7baa6798ef15b6f0013c83'
[19:20] <cone-612> ffmpeg.git 03Vittorio Giovara 07master:bddd8cbf6855: Add transformation matrix API.
[19:20] <cone-612> ffmpeg.git 03Michael Niedermayer 07master:ef1d4ee2f8b6: Merge commit 'bddd8cbf68551f6405b2bf77cc3e212af9fbe834'
[19:21] <j-b> ah, interesting
[19:28] <cone-612> ffmpeg.git 03Vittorio Giovara 07master:853cc025d63e: mov: store display matrix in a stream side data
[19:28] <cone-612> ffmpeg.git 03Michael Niedermayer 07master:07941c2cb28d: Merge commit '853cc025d63ee2539fc0460dab62c5b9a3fd2043'
[19:35] <cone-612> ffmpeg.git 03Martin Storsjö 07master:82fc9f4b3824: display: Include mathematics.h for fallback definition of NAN
[19:35] <cone-612> ffmpeg.git 03Michael Niedermayer 07master:cd7ae5af16d7: Merge commit '82fc9f4b38244236a6ca7f946662ca653044a04c'
[20:06] <cone-612> ffmpeg.git 03Michael Niedermayer 07master:55fe1582cb28: avcodec/pthread_frame: remove unused variable
[20:18] <compn> i had an idea for a filter. make non-black color pixels brighter. so keep black and near-black pixels dark, but brighten up the other pixels. is that possible ? :)
[20:19] <nevcairiel> thats called gamma
[20:19] <compn> adjusting gamma still adjusts the black 
[20:30] <llogan> compn: play around with curves
[21:15] <J_Darnley> Who organised ffmpeg's migration from svn to git?  I seem to recall talk of a script to parse true authors out of commit messages.  Was that ever published anywhere?
[21:15] <Daemon404> no
[21:15] <Daemon404> and iirc it was janne
[21:17] <beastd> N
[21:18] <beastd> J_Darnley: I do not know what was done for ffmpeg migration, but I remember migrating svn repos to git at work
[21:18] <J_Darnley> Are you janne?
[21:18] <Daemon404> janne is janne
[21:19] <Daemon404> janne is over at libav
[21:19] <J_Darnley> That was my next question.
[21:19] <beastd> no, i am not janne of course ;)
[21:19] <Daemon404> on the internet, nobody knows youre a dog
[21:20] <J_Darnley> :)
[21:21] <J_Darnley> I guess I'll send a email then.]
[21:21] <beastd> J_Darnley: What exactly is your goal? There is only committer information in svn. Do you also want to transfer author information?  i think that is not fully possible
[21:21] <J_Darnley> It isn't anything serious
[21:21] <J_Darnley> git-svn would probably suffice
[21:22] <J_Darnley> beastd: yeah that's want I was looking for
[21:22] <Daemon404> the bets you can do is try and regex the commit message
[21:22] <Daemon404> beastd, little known fact: svn can ave a separate author
[21:22] <J_Darnley> We used to say "patch submitted by $me"
[21:22] <Daemon404> but nobody does it.
[21:24] <beastd> when i converted svn repos to git i could specify a mapping for committer to committer/author i am sure
[21:25] <Daemon404> yeah
[21:25] <Daemon404> but usually the info is in the message (if at all)
[21:25] <Daemon404> you more or less need to manually build up a table of nicks/names and regex
[21:25] <Daemon404> and then poke it more
[21:25] <Daemon404> it is super tedious
[21:25] <beastd> Daemon404: if no one used it, it doesn't help :)  That is sth git got right
[21:26] <Daemon404> http://esr.ibiblio.org/?p=5634
[21:26] <Daemon404> relevant
[21:26] <Daemon404> (yeah its esr, but for once his post is kinda interesting)
[21:28] <beastd> ah yes, i heard about that conversion. i do not envy esr for that task
[21:28] <Daemon404> rcs *and* arch
[21:28] <Daemon404> only at GNU.
[21:29] <Daemon404> this is actually the onl project i know which used arch
[21:29] <Daemon404> only*
[21:43] <J_Darnley> Wow 29 years
[21:43] <cone-612> ffmpeg.git 03Michael Niedermayer 07master:833ec9177d17: ffmpeg/do_video_stats: fix used timebase
[21:52] <beastd> J_Darnley: If it is not so important I would first try to just convert and just map the Subversion committers. Unfortunately I cannot recall what I used to do it at work, but it may just have been git svn with an additional authors file provided. should be in the git docs or maybe the book.
[22:11] <cone-612> ffmpeg.git 03James Almer 07master:b82274487b23: lavc: define STRIDE_ALIGN as 32 when compiling with AVX support
[22:11] <cone-612> ffmpeg.git 03Thierry FAUCK 07master:41b928c5fad7: avcodec/ppc/asm: fix build with ABI v2
[23:08] <michaelni> ubitux, ok to apply: "[FFmpeg-devel] af_silencedetect.c: silencedetect reporting format change to follow blackdetect reporting format" ? (it has one reply that supports the idea but iam not sure if theres any script breaking issue and also the log output would be delayed for silence start IIUC)
[23:16] <ubitux> mmh not really
[23:16] <ubitux> just a moment
[23:17] <ubitux> michaelni: yes i'm concerned about the delayed information
[23:17] <ubitux> but people should not rely on that output anyway, metadata are here for that
[23:17] <ubitux> a micro bump (and an entry in "behaviour changes"? :)) would be welcome i guess
[23:24] <cone-612> ffmpeg.git 03James Almer 07master:d43c303038e9: x86/hevc_deblock: use constants instead of generating values at runtime
[23:25] <michaelni> ubitux, ill leave the patch to you to reject/comment/apply, have uneasy feeling about it :)
[23:26] <ubitux> sure, i'm writing an answer
[23:31] <iive> i'd say this patch definitely needs proper benchmark.
[23:59] <michaelni> iive, 172248 ->171248 dezicycles for master:d43c303038e9
[23:59] <iive> so the patch is faster?
[00:00] --- Tue May 20 2014