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

[burek]

[00:04] <cone-797> ffmpeg.git 03Nicolas George 07master:29ebb7ba8d7e: lavu: fix GET_UTF8 macro.
[00:04] <cone-797> ffmpeg.git 03Nicolas George 07master:70feca926b93: lavc: check decoded subtitles encoding.
[00:04] <cone-797> ffmpeg.git 03Michael Niedermayer 07master:d382170c5daa: Merge remote-tracking branch 'cigaes/master'
[00:07] <michaelni> saste, we should fix every bug, the more important ones first ideally, but every should be fixed and all feature requests implemented ...
[00:08] <ubitux> cehoyos: -c copy -movflags faststart
[00:08] <ubitux> ...should work
[00:08] <saste> michaelni, i don't know because i never used that function, and is used apparently only in very few cases
[00:08] <durandal_1707> michaelni: do you realize when that will happen...
[00:09] <saste> now i need to implement a similar function (to factorize asyntotically growing array)
[00:09] <saste> also it doesn't check for int overflows
[00:09] <ubitux> durandal_1707: we still have a few years left to live for most of us, so it's important to keep getting busy for a while ;)
[00:10] <saste> btw ping on: "doc: remove all-components.texi, include verbatim its content"
[00:10] <saste> not a technical matter, just we need to decide what's worse
[00:59] <cone-797> ffmpeg.git 03Clément BSsch 07master:035a3792c223: lavfi/subtitles: zero-init AVSubtitle.
[01:09] <durandal_1707> michaelni: if i increase avpkt->size by 1 bug almos dissappear
[01:17] <cone-797> ffmpeg.git 03Paul B Mahol 07master:aa96439fae67: lavc: remove unused put_bits.h headers
[01:23] <cehoyos> ubitux: At least not for vfr files
[01:24] <cehoyos> (But I think there are other reasons why you don't want to remux, for example unsupported codecs)
[01:29] <durandal_1707> can anyone look at https://github.com/BigHillSoftware/QTFFmpeg/blob/master/QTFFmpeg/QTFFmpeg/Code/QTFFAVStreamer.m and tell what is obviously wrong?
[01:29] <durandal_1707> guy at ml started to claim its our bug
[01:42] <durandal_1707> hmm code uses function thats not used by ffmpeg at all
[01:42] <durandal_1707> the only other user is in examples
[09:42] <highgod> Hi, I want to ask a question, how can we use a raw audio data to encode? I found the decoding_encoding.c, where can I find the input file
[09:42] <highgod> thanks
[10:05] <cone-961> ffmpeg.git 03Anton Khirnov 07master:35386fbf4193: doc/APIchanges: add missing hashes and dates
[10:05] <cone-961> ffmpeg.git 03Vittorio Giovara 07master:fc18cc44ebfa: fate: add CVFC1_Sony_C to h264 conformance tests
[10:05] <cone-961> ffmpeg.git 03Michael Niedermayer 07master:575399c7e116: Merge commit 'fc18cc44ebfae07da153dc782572e7ce2f6fe47d'
[10:15] <ubitux> highgod: you can generate with -c:a pcm_s16le for instance
[10:24] <highgod> @ubitux:thanks, and what is the container name?
[10:25] <ubitux> -f s16le i guess
[10:28] <highgod> OK, thanks
[10:55] <ubitux> michaelni: any reason you didn't use avpriv_atomic_int_get() in av_buffer_get_ref_count()?
[11:24] <michaelni> ubitux, it would be slower, also what would it fix ?
[11:25] <ubitux> i don't know
[11:25] <ubitux> no risk of race in the assert in h264?
[11:25] <ubitux> (or any future code relying on it)
[11:28] <michaelni> avpriv_atomic_int_get() doesnt really protect you against races
[11:29] <cone-961> ffmpeg.git 03Stefano Sabatini 07master:f40cf96ec0f4: doc: remove all-components.texi, include its content verbatim
[11:29] <cone-961> ffmpeg.git 03Stefano Sabatini 07master:cb23de1904e4: doc/filters: remove "q" constant docs for noise mode
[11:29] <cone-961> ffmpeg.git 03Stefano Sabatini 07master:16cecf9c3de8: doc/filters: put vidstab filters documentation in a sensible order
[11:29] <michaelni> about future code its hard to argue, the use in h264 seems safe to me but of course i might be missing something
[11:30] <ubitux> ok
[11:33] <saste> how shaky is the video and how quick is the camera? (default: 5)
[11:33] <saste> ^^ subpar docs
[11:33] <durandal_1707> saste: i gonna apply joinfields soon
[11:34] <saste> durandal_1707, is that the case that it duplicates tinterlace functionality?
[11:34] <saste> (no i didn't yet look at the code)
[11:35] <durandal_1707> tinterlace is GPL
[11:35] <durandal_1707> mp=tinterlace is GPL
[11:35] <durandal_1707> interlace is GPL
[11:35] <ubitux> so we will have 4 filters to interlace?
[11:35] <ubitux> :D
[11:37] <saste> any chance to remove mp=tinterlace?
[11:37] <durandal_1707> i think you can remove mp=tinterlace
[11:37] <durandal_1707> saste: the only one who objected was michaelni 
[11:38] <durandal_1707> but now that there is interlace, i think its fast enough...
[11:38] <saste> is it?
[11:38] <durandal_1707> for what exact mode mp one is faster and for how much?
[11:38] <durandal_1707> also you did said that mp version have less features than native one
[11:39] <saste> yes more modes
[11:40] <saste> i'm going to do a few benchmarks soon
[11:40] <ubitux> it's possible mp got slower recently
[11:41] <ubitux> (see 9b672d401)
[11:41] <ubitux> not sure if that changes something for perf
[11:44] <saste> ubitux: Set virtual tripod mode: @code{tripod=framenum} if framenum>0 otherwise disabled.
[11:44] <saste> ???
[11:48] <ubitux> the doc might have required more reviews
[11:49] <ubitux> i'm debugging the lib right now, i'll see the doc adjustment later
[11:50] <saste> ubitux: i'll send soon a patch for vidstabdetect docs
[11:51] <ubitux> you better fix them directly :p
[12:02] <ubitux> i think we should be able to port most of the vid.stab code natively without that much effort btw
[12:02] <ubitux> and make it way faster too
[12:08] <ubitux> ok i found the problem.
[12:18] <ubitux> oh well i'll let him fix it
[14:24] <cone-961> ffmpeg.git 03Michael Niedermayer 07master:32a6dfeb125d: vc1dec: drop mv_f_last, simplify code
[15:12] <BuxiNess> Hello,
[15:13] <BuxiNess> I made some tests on MT in current jpeg2000 decoder.
[15:14] <BuxiNess> I have the warning  msg :"Mutiple ff_thread_finish_setup calls 
[15:14] <BuxiNess> whne i run with several threads
[15:15] <BuxiNess> But I never call ff_thread_finish_setup in the decoder :(
[15:17] <durandal_1707> BuxiNess: with ffmpeg?
[15:23] <BuxiNess> yes
[15:26] <durandal_1707> maybe recent regression
[15:26] <durandal_1707> indeed, happens with exr too
[15:27] <durandal_1707> michaelni: ^
[15:36] <saste> michaelni, i have a question for you
[15:36] <saste> ffmpeg -f lavfi -i "testsrc=d=200,format=yuv420p,interlace" -f null -
[15:37] <saste> with this command I have no framedups
[15:37] <saste> but if I use: testsrc=d=200,format=yuv420p,tinterlace
[15:37] <saste> then it is dupping frames (was resulting in a slower benchmark)
[15:37] <durandal_1707> pts?
[15:38] <saste> if I modify tinterlace to set the framerate (to half input framerate), and propagate the info in lavfi
[15:38] <saste> i still observe dups
[15:38] <saste> the only way to avoid them is to change the timebase, which doesn't make much sense to me
[15:39] <durandal_1707> but telecine,separatefields and bunch of others do
[15:40] <saste> if i change -y out.avi i don't see the dups
[15:40] <saste> so it seems related to the null muxer
[15:41] <durandal_1707> null muxer doesn't change pts
[15:41] <saste> and so why then ffmpeg dups frames?
[15:41] <saste> how is that related?
[15:42] <durandal_1707> same pts
[15:46] <saste> durandal_1707, "same pts" doesn't explain nothing to me
[15:47] <ubitux> saste: add a showinfo after the filter and check if frames have the same pts
[15:47] <ubitux> if tinterlace is adding frame, the timebase need to be doubled
[15:47] <ubitux> to represent the new pts in some circomstances
[15:48] <ubitux> (or maybe i completely misunderstood your issue)
[15:49] <saste> no what's the point of changing the timebase
[15:49] <saste> how is the timebase related to the framerate
[15:49] <saste> otoh i see that michaelni changed tb in interlace
[15:50] <saste> indeed there are no dups with interlace
[15:51] <ubitux> <@saste> how is the timebase related to the framerate // if you can't represent a timestamp in the timebase, you need to enlarge it, i guess
[15:52] <ubitux> saste: imagine a tb of 1/30 for an input at 30 fps, everything is ok
[15:53] <ubitux> no imagine you want to double fps
[15:53] <ubitux> 1 2 3 4 5 -> 0 1 1 2 2 ...
[15:53] <ubitux> (because you half the pts which are at 1/30)
[15:53] <saste> ubitux, i'm halving the frame rate
[15:53] <saste> so i guess i can keep the same timebase with no problems
[15:53] <saste> the null muxer is not ok
[15:54] <durandal_1707> null muxer have no timestamps at all - it does nothing
[15:55] <ubitux> saste: i see no pts/framerate/timebase change in tinterlace
[15:56] <ubitux> ah, you latest patch.
[15:56] <ubitux> saste: well, it's simply that your frame rate may not be reachable with the given tb
[15:57] <ubitux> so just in case you need to double timebase den
[16:05] <ubitux> saste: note that changing tb & frame rate is not enough
[16:06] <ubitux> you need to adjust the pts of one of the frame going out
[16:11] <cone-961> ffmpeg.git 03Michael Niedermayer 07master:94b3a666fa87: avcodec/pthread: Make sure ff_thread_finish_setup() conditions match
[16:11] <cone-961> ffmpeg.git 03Michael Niedermayer 07master:8f0db04b0869: avcodec/pthread: use THREAD_SAFE_CALLBACKS() to simplifx more code
[16:12] <michaelni> BuxiNess, durandal_1707, warning should be fixed
[16:27] <durandal_1707> wow, benchmarks!!!
[16:27] <ubitux> for one of the most useless filter :)
[16:34] <cone-961> ffmpeg.git 03Paul B Mahol 07master:e1ba5fc96838: dcaenc: update
[16:38] <durandal_1707> byteswap filter ????
[16:39] <durandal_1707> and i think it could use dsp, but does not ....
[16:40] <saste> ubitux: do you have optimizations enabled?
[16:41] <ubitux> saste: yes, i shouldn't?
[16:42] <saste> rxzxdoiiojmmmmmmt6i76tg945i6h8p099u89lomoim8j00k hjh jv hhjm°* hjmkààà
[16:42] <ubitux> nice passwd
[16:42] <av500> nice cat
[16:43] <funman> nice coffee spill
[16:43] <saste> pesty nephew
[16:43] <ubitux> http://3.bp.blogspot.com/_Co8liL2umjM/TAZpJ9ynAyI/AAAAAAAAAC0/aKcsPitvrJU/s1600/1218737914_hit-it-crowbar.jpg
[17:57] <BuxiNess> michaelni, yep its fixe!
[17:58] <durandal_1707> michaelni: interlace filter give green line at bottom
[18:47] <durandal_1707> what?: Stream #0:0: Video: vp8, yuv420p, 854x362, SAR 1:1 DAR 427:181, 1k fps, 1k tbr, 1k tbn, 1k tbc (default)
[19:08] <cone-961> ffmpeg.git 03Paul B Mahol 07master:00acfdd9260a: lavfi/telecine: show time base change too
[19:08] <cone-961> ffmpeg.git 03Paul B Mahol 07master:e86ed98f43ae: lavfi/noise: add missing emms_c()
[19:08] <cone-961> ffmpeg.git 03Paul B Mahol 07master:89b5ed5f1569: lavfi/noise: remove get_video_buffer, its redundant now
[20:40] <cone-961> ffmpeg.git 03Paul B Mahol 07master:084709f6a59e: fate: update dca test and disable dca2 test
[22:21] <ubitux> http://ubitux.fr/pub/pics/_minecraft-fft.png
[22:21] <ubitux> still the squares, but it denoises!
[22:22] <ubitux> (./ffplay tests/lena.pnm -vf "noise=alls=30,format=gray,split[a][b]; [a]pad=iw*2[p]; [b]fft='max((psd-1000)/psd,0)'[f]; [p][f] overlay=w")
[22:23] <cone-961> ffmpeg.git 03Paul B Mahol 07master:77570a390d71: lavc/cdxl: add @file doxy
[22:23] <cone-961> ffmpeg.git 03Paul B Mahol 07master:da2276036470: vima: generate predict_table once, and share it with all decoders
[22:23] <cone-961> ffmpeg.git 03Paul B Mahol 07master:2c5700c5e2be: vima: add @file doxy
[22:23] <xlinkz0> seems to me the one on the left has more detail
[22:24] <ubitux> :(
[22:24] <durandal11707> every denoiser blurs
[22:42] <cone-961> ffmpeg.git 03Michael Niedermayer 07master:5183365aeb9e: vc1dec: fix doxy for vc1_mc_4mv_chroma4()
[22:42] <cone-961> ffmpeg.git 03Michael Niedermayer 07master:dd6e291e4083: vc1dsp: add avg_no_rnd_vc1_chroma_mc4_c()
[22:42] <cone-961> ffmpeg.git 03Michael Niedermayer 07master:9b49d3974e9f: vc1dec: add avg & variable direction support to vc1_mc_4mv_chroma4()
[22:42] <cone-961> ffmpeg.git 03Michael Niedermayer 07master:688fc4ac565d: vc1dec: Try to fix vc1_mc_4mv_chroma4() parameters
[22:52] <michaelni> durandal11707, why did you disable fate-acodec-dca2
[22:52] <michaelni> ?
[22:53] <durandal11707> i couldn't fix it
[22:53] <michaelni> so you just commited the change and ignored fate ?
[22:54] <michaelni> besides the other fate checksums update should have been in the commit changing it
[22:54] <michaelni> fate.org now has breakages as the clients test versions between the decoder update and the fate update
[22:55] <michaelni> http://fate.ffmpeg.org/report.cgi?time=20130425184200&slot=x86_64-linux-gnu-icc-2011.4.191 <--- Example
[22:55] <durandal11707> yes, but i dont see point of test for it at all
[22:57] <durandal11707> i thought there was no dca encoder test at all....
[22:57] <michaelni> IIRC one of the 2 dca tests, tests the encoder the other the decoder
[22:58] <durandal11707> huh?
[22:59] <durandal11707> no its not, both have strict -2
[22:59] <durandal11707> acodec.mak test encoders
[23:00] <durandal11707> some audio ones only ...
[23:01] <michaelni> acodec.mak tests encoder+decoder
[23:01] <michaelni> see "ENCDEC"
[23:01] <durandal11707> if thats only way how dts decoder is tested, its broken one
[23:02] <michaelni> the code now doesnt test if the encoded file is at all similar to what was encoded
[23:02] <durandal11707> i would like to to enable test if i would know how to fix it
[23:22] <ubitux> durandal11707: cool! :)
[23:23] <durandal11707> ubitux: no until 16 bit
[23:23] <ubitux> :)
[23:29] <cone-961> ffmpeg.git 03Michael Niedermayer 07master:667159e718d4: fate: re-enable fate-acodec-dca2
[23:42] <durandal11707> ubitux: it hurts performance by 7.7%
[23:43] <ubitux> what about using the curves->graph index instead?
[23:44] <ubitux> try to dst += step and remove the mult from the loop too maybe
[23:45] <ubitux> *dstp++ = curves->graph[r][*srcp++]; for each comp or something
[23:47] <ubitux> see if using an intermediate ptr for curves->graph helps too..
[23:53] <durandal11707> ubitux: i dont thin that can halp much, the only solution is switch table with code duplication
[23:53] <ubitux> well, i don't care very much about the perf
[23:54] <ubitux> i don't think it really matters
[23:54] <ubitux> (in this case)
[23:54] <ubitux> (assuming the obvious attempt don't work)
[00:00] --- Fri Apr 26 2013