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

[burek]

[00:15] <durandal_1707> michaelni: nvm
[00:21] <durandal_1707> how many "mentors" currently FFmpeg have?
[01:00] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r776c89f019 10ffmpeg/libavfilter/vsrc_mptestsrc.c: 
[01:00] <CIA-17> ffmpeg: vsrx_mptestsrc: remove duplicate config_props init.
[01:00] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[01:00] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r4707f1da8a 10ffmpeg/libswscale/utils.c: 
[01:00] <CIA-17> ffmpeg: swscale: remove duplicate PIX_FMT_GBRP entry from format_entries.
[01:00] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[01:00] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r3a5836038d 10ffmpeg/libavcodec/cook.c: 
[01:00] <CIA-17> ffmpeg: cook: silence some signed overflow warnings.
[01:00] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[01:00] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r902bdf706f 10ffmpeg/libavcodec/h264.c: 
[01:00] <CIA-17> ffmpeg: h264: fix warning about "uint8_t *p" and const
[01:00] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[01:00] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r7d75febe0f 10ffmpeg/libavcodec/mjpegenc.c: 
[01:00] <CIA-17> ffmpeg: mjpegenc: Fix const correctness and avoid writes into AVFrame of amv_encode_picture()
[01:00] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[01:00] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r57986c501e 10ffmpeg/libavcodec/utils.c: 
[01:00] <CIA-17> ffmpeg: lavc/utils: fix const correctness of AVClass cast
[02:26] <Compn> MPEG 4 Studio Profile format.
[02:26] <Compn> This  format is used in HDCAM-SR decks, but Sony is now making it available as files based. It uses MXF container. It's high quality intermediate codec- aka Cineform.
[02:26] <Compn> anyone know this format ?
[02:26] <Compn> Here is link to the free Sony app, which also has directshow decoder and dll libraries for decoder. I also attached encoder dll- you can find it in free Lite version of Black-magic Resolve grading software.
[02:26] <Compn>  I don't know if this is enough, but if you can get 10bit out of it than please let me know.
[02:26] <Compn> http://support.sonybiz.ca/esupport/downloads/[10059]SRViewer_V1.1.zip
[02:32] <kierank> not used very often because the decks to make them are so bloody expensive
[02:33] <kierank> you don't need a dll because it's an open standard
[02:33] <kierank> though it wouldn't surprise me if sony implemented it wrong
[02:34] <Compn> mpeg4 in mxf ?
[02:35] <kierank> yes
[02:35] <Compn> ah
[02:35] <Compn> well i asked him for a sample anyways 
[02:35] <kierank> it's not normal mpeg-4
[02:35] <Compn> so we can add support for it
[02:35] <kierank> asked whom?
[02:35] <Compn> the guy who sent me the above email
[02:35] <kierank> ah
[02:43] <iive> samples?
[02:43] <iive> btw, is it mpeg-4-2 or h264?
[02:44] <kierank> the former
[02:53] <iive> that may be bad...  if it uses more stuff than simple profile
[02:55] <iive> I don't think that Studio Profile, is official standard profile. Otherwise it must be a more recent one.
[03:37] <CIA-17> ffmpeg: 03Anton Khirnov 07master * r39da3b223f 10ffmpeg/avconv.c: 
[03:37] <CIA-17> ffmpeg: avconv: fix counting encoded video size.
[03:37] <CIA-17> ffmpeg: avcodec_encode_video2() return value is 0 on success, encoded frame size
[03:37] <CIA-17> ffmpeg: is stored in the packet.
[03:37] <CIA-17> ffmpeg: 03Martin Storsjö 07master * r338978a7c1 10ffmpeg/libavcodec/libx264.c: 
[03:37] <CIA-17> ffmpeg: libx264: Allow overriding the sliced threads option
[03:37] <CIA-17> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[03:37] <CIA-17> ffmpeg: 03Ronald S. Bultje 07master * r6193ff6854 10ffmpeg/libavcodec/error_resilience.c: 
[03:37] <CIA-17> ffmpeg: error_resilience: initialize s->block_index[].
[03:37] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[03:37] <CIA-17> ffmpeg: CC: libav-stable at libav.org
[03:37] <CIA-17> ffmpeg: 03Ronald S. Bultje 07master * r11b940a1a8 10ffmpeg/libavcodec/svq3.c: 
[03:37] <CIA-17> ffmpeg: svq3: protect against negative quantizers.
[03:37] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[03:37] <CIA-17> ffmpeg: CC: libav-stable at libav.org
[03:37] <CIA-17> ffmpeg: 03Ronald S. Bultje 07master * rc23acbaed4 10ffmpeg/libavcodec/ (9 files): 
[03:37] <CIA-17> ffmpeg: Don't use ff_cropTbl[] for IDCT.
[03:37] <CIA-17> ffmpeg: Results of IDCT can by far outreach the range of ff_cropTbl[], leading
[03:37] <CIA-17> ffmpeg: to overreads and potentially crashes.
[03:37] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[03:37] <CIA-17> ffmpeg: CC: libav-stable at libav.org
[03:38] <CIA-17> ffmpeg: avconv: add -cpuflags option for setting supported cpuflags.
[03:38] <CIA-17> ffmpeg: Useful for testing.
[03:38] <CIA-17> ffmpeg: 03Ronald S. Bultje 07master * r2254b559cb 10ffmpeg/libswscale/ (7 files in 3 dirs): 
[03:38] <CIA-17> ffmpeg: swscale: make filterPos 32bit.
[03:38] <CIA-17> ffmpeg: Fixes overflows for large image sizes.
[03:38] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[03:38] <CIA-17> ffmpeg: CC: libav-stable at libav.org
[03:38] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r6df42f9874 10ffmpeg/: (log message trimmed)
[03:38] <CIA-17> ffmpeg: Merge remote-tracking branch 'qatar/master'
[03:38] <CIA-17> ffmpeg: * qatar/master:
[03:38] <CIA-17> ffmpeg:  SBR DSP: fix SSE code to not use SSE2 instructions.
[03:38] <CIA-17> ffmpeg:  cpu: initialize mask to -1, so that by default, optimizations are used.
[03:39] <CIA-17> ffmpeg:  error_resilience: initialize s->block_index[].
[03:39] <CIA-17> ffmpeg:  svq3: protect against negative quantizers.
[03:39] <CIA-17> ffmpeg: 03Ronald S. Bultje 07master * ra9c5b6f602 10ffmpeg/libavutil/cpu.c: cpu: initialize mask to -1, so that by default, optimizations are used.
[03:39] <CIA-17> ffmpeg: 03Reimar Döffinger 07master * rb5161908e0 10ffmpeg/libavcodec/x86/sbrdsp.asm: 
[03:39] <CIA-17> ffmpeg: SBR DSP: fix SSE code to not use SSE2 instructions.
[03:39] <CIA-17> ffmpeg: movq from SSE register _to_ memory is an SSE2 instruction.
[03:39] <CIA-17> ffmpeg: Use the SSE movlps function instead that does the same thing.
[03:39] <CIA-17> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
[03:39] <CIA-17> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[03:39] <CIA-17> (1 lines omitted)
[03:39] <Daemon404> lul unicode fail :3
[03:43] <Compn> reimar's name isnt unicode
[03:43] <Compn> well it wasnt before, dunno what git uses :D
[03:57] <Daemon404> pasteeater, are you still alive?
[04:05] <Daemon404> hmm nvm
[05:15] <CIA-17> ffmpeg: 03Paul B Mahol 07master * r1eabd71c2b 10ffmpeg/libavcodec/ffv1.c: 
[05:15] <CIA-17> ffmpeg: ffv1: PIX_FMT_YUV444P10 support
[05:15] <CIA-17> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[05:15] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[05:15] <CIA-17> ffmpeg: 03Paul B Mahol 07master * r65491fa3d5 10ffmpeg/libavcodec/ffv1.c: 
[05:15] <CIA-17> ffmpeg: ffv1: PIX_FMT_YUV444P9 & PIX_FMT_YUV422P9 support
[05:15] <CIA-17> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[05:15] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[05:15] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * reff2399f24 10ffmpeg/libavcodec/error_resilience.c: 
[05:15] <CIA-17> ffmpeg: Revert "error_resilience: initialize s->block_index[]."
[05:15] <CIA-17> ffmpeg: This reverts commit 6193ff68549ecbaf1a4d63a0e06964ec580ac620.
[05:15] <CIA-17> ffmpeg: This change is unneeded.
[10:09] <ubitux> https://github.com/id3 fun
[12:58] <ubitux> the post about coverage from mike is nice
[13:55] <Tjoppen> github down?
[13:57] <av500> there was that exploit....
[13:59] <j-b> "why don't you host vlc at github? You are so old open-source: all cool projects are on github..." some week ago, on IRC...
[14:00] <av500> at least host ruby-vlc there....
[14:17] <Tjoppen> michaelni: test case for the problem I described two days ago posted
[16:58] <CIA-17> ffmpeg: 03Nicolas George 07master * re5dd4ae728 10ffmpeg/libavcodec/assdec.c: assdec: avoid a possible NULL dereference.
[16:58] <CIA-17> ffmpeg: 03Nicolas George 07master * rc088b7f389 10ffmpeg/libavcodec/ass_split.c: 
[16:58] <CIA-17> ffmpeg: ass_split: accept files with only \n and no \r.
[16:58] <CIA-17> ffmpeg: The +1 is there to skip the ','.
[16:58] <CIA-17> ffmpeg: With \r\n, the +1 skips the \r but that is ok.
[16:58] <CIA-17> ffmpeg: With only \n, the +1 skips it and all hell breaks loose.
[16:59] <Tjoppen> -_-
[16:59] <Tjoppen> pktl->pkt.pts += st->first_dts;
[16:59] <durandal_1707> michaelni: i cant get unscaled info output at all
[16:59] <Tjoppen> hah: //FIXME think more about this check
[17:10] <Tjoppen> more fun: mov uses no parsers for video but mxfdec does
[17:11] <Tjoppen> hence why the same essence remuxed to mov doesn't get messed up timestamps - has_b_frames = 1 never gets parsed. indeed, if I set AVSTREAM_PARSE_HEADERS in mov.c the same issue is visible
[17:12] <Tjoppen> anyway, the whole thing with first_dts is rather dubious
[17:32] <Tjoppen> it seems it's required by fate-nsv-demux
[18:14] <Tjoppen> what does fate-lavfi-pp do?
[18:18] <Tjoppen> it's failing even though I've stashed my changes and made clean
[18:24] <funman> so you've got the answer: it fails :P
[18:24] <ubitux> it runs mp=pp[...]
[18:24] <ubitux> you need to --enable-gpl
[18:24] <ubitux> so the libmpcodecs wrapper is enabled
[18:24] <Tjoppen> but why does it run at all?
[18:24] <ubitux> no conditionnal run
[18:24] <Tjoppen> .. but that makes fate fail by default?
[18:25] <ubitux> no, fate by default assume --enable-gpl when you setup a box
[18:25] <ubitux> of course, on standalone it fails yes
[18:25] <Tjoppen> ic. it should probably check that
[18:25] <ubitux> this issue has been raise on the ml
[18:26] <ubitux> (see tests/fate.sh:configure for the --enable-gpl flag when you setup a fate box)
[18:26] <ubitux> anyway, quick fix is to build with --enable-gpl
[18:26] <Tjoppen> alrighty then. now I just need to figure out why the pp case changes with my attempt at limiting the fallout of first_dts
[18:27] <Tjoppen> do the lavfi tests check frame ptses?
[18:28] <ubitux> filters are run with -f nut as output container, so i guess the pts are implicitely checked
[18:32] <Tjoppen> input seems to be image2. let's see if it sets pts the way I expect
[18:34] <Tjoppen> no timestamps set at all..
[18:49] <Tjoppen> success!
[18:50] <Tjoppen> also fixed WTV in the same fashion - it got PTSes like -40000,40000,80000 instead of 0,40000,80000
[18:55] <michaelni> Tjoppen, how did you fix it ?
[18:55] <michaelni> was afk till 30min ago or so ...
[18:59] <Tjoppen> posting patch to ML
[19:05] <Tjoppen> sent
[19:19] <Tjoppen> michaelni: does the patch look reasonable?
[19:24] <michaelni> i think it would still fail with B frames
[19:24] <michaelni> iam thinking atm about how to solve this in a non fragile way
[19:25] <Tjoppen> that'd be a file with the first packet being a B-frame?
[19:27] <Tjoppen> also: aren't there any FATE samples with B-frames?
[19:28] <michaelni> there are but they have pts+dts
[19:28] <michaelni> the problem occurs when only pts is set
[19:28] <michaelni> i have an idea but i need to test it ...
[19:29] <Tjoppen> you could use http://titan.codemill.se/~tomhar/samples/tidkod-svep-10s-1920x1080i50-xdcam-hd-50-PB.mxf  and remove the line that sets pkt->dts in mxfdec
[20:13] <pasteeater> Daemon404: pong
[20:37] <durandal_1707> michaelni: why is there warning for multiple ff_thread_finish_setup() calls? Are you sure that DnxD and utvideo still works as expected with multiple threads?
[20:44] <Daemon404> pasteeater, hi
[20:44] <Daemon404> do you have an x86 (not x86_64) you can test a utvideo patch on?
[20:44] <Daemon404> i dont have one... oddly enough
[20:44] <Daemon404> (linux i mean)
[20:45] <durandal_1707> Daemon404: i would test it if there is way to compile shared libutvideo
[20:46] <Daemon404> sure there is
[20:46] <Daemon404> i just havent bothered adding it
[20:46] <Daemon404> i decided to get asm working on mingw first, but it doesnt much care for x64 linux, need to test x86 linux
[20:46] <ohsix> qemu-system-i386? not that you need it
[20:47] <Daemon404> :effort:
[20:47] <pasteeater> Daemon404: i might. let me look at this other old machine.
[20:47] <ohsix> debootstrap & schroot ftw :>
[20:47] <Daemon404> id like to try and fix x64 asm on linux (x86 -should- work)
[20:48] <Daemon404> but i suck at debuggig macros + asm lol
[20:48] <durandal_1707> what? native utvideo decoder is buggy?
[20:48] <Daemon404> libutvideo works fine
[20:48] <Daemon404> im getting libutvideo's asm to work
[20:49] <Daemon404> works on mingw32/64 after patching
[20:49] <pasteeater> Daemon404: yes, it's a P4 running Ubuntu.
[20:49] <ohsix> use orc, if not directly; tune the output manually ;]
[20:49] <Daemon404> https://japland.org/tools/linux/utvideo-10.2.4-mingw-asm.patch 
[20:49] <Daemon404> it handles linux too, so name is misleading
[20:51] <michaelni> durandal_1707, ping me about the thread issue in a day or 2, iam ATM busy with the compute pkt values problem
[20:52] <pasteeater> Daemon404: ok. i'll look at it today.
[20:52] <durandal_1707> michaelni: i dunno if it is really issue because i have only single core cpu
[20:54] <durandal_1707> so someone only needs to tell me that frame multithreading for utvideo decoder works as expected on multi core cpu with FFmpeg code
[20:55] <durandal_1707> or any other intra only decoder which supports frame multithreading
[21:04] <michaelni> durandal_1707, if you simply copy and paste me a comand line to run/test i can test it 
[21:32] <pasteeater> Daemon404: it compiled just fine with the patch.
[21:54] <michaelni> Tjoppen, my solution seems to need the same change to wtv seek :)
[21:54] <michaelni> also i think you will like mine more than yours
[21:54] <michaelni> or at least i hope
[21:55] <michaelni> it also makes the update* code cleaner and less fragile
[22:06] <Daemon404> pasteeater, yes btu does it crash
[22:06] <Daemon404> is what im curious about :P
[22:16] <cbsrobot> michaelni: http://pastie.org/pastes/3544011/text ?
[22:17] <michaelni> cbsrobot, LGTM
[22:17] <michaelni> Tjoppen, my suggestion is on the ML
[22:20] <Tjoppen> looking at it now
[22:22] <Tjoppen> what about timestamps > 2^32? 13.2 hours in 90 kHz..
[22:24] <beastd> cbsrobot: you might probably want to s/bugtracker/issue tracker/ . anyway works and looks fine to me.
[22:28] <michaelni> Tjoppen, not sure i understand, the base is at INT64_MAX - 2^32
[22:28] <Tjoppen> yes, that only leaves room for 2^32. say a TS file start 15 hours in.. (I'm assuming they can)
[22:29] <michaelni> you have nearly 2^64 for normal timestamos
[22:29] <michaelni> timestamps
[22:29] <michaelni> for relative ones with the current suggestion it would be around 2^32
[22:30] <michaelni> but in which case does this get used up ? TS should have timestamps and thus only a second relative ones or so
[22:30] <Tjoppen> ah, this is relative to the first dts found? I confess I haven't studied it too closely
[22:31] <michaelni> well absolute timestamps are just normal timestamps, relative ones are when you just know durations but never had a timestamp
[22:32] <michaelni> so their relative relation can be kept track of
[22:32] <michaelni> easily that is
[22:32] <Tjoppen> ah, alright then. durations > 2^32 are quite unlikely
[22:33] <Tjoppen> or rather: pkt->duration is an int, so impossible :)
[22:34] <michaelni> its not impossible if you had 13 hours without timestamps but durations (that is with many frames so the int duration doesnt limit it)
[22:34] <michaelni> at a 90khz timebase
[22:34] <michaelni> 15hours or whatever :)
[22:35] <Tjoppen> what I mean is you can't get such durations out of the demuxer anyway. unless you compute duration outside of course
[22:35] <michaelni> yes
[22:35] <Tjoppen> discontinuities shouldn't result in  duration being set anyway (or it should be extrapolated, IMO)
[22:35] <michaelni> the base is also just internal so we can just change it to 2^48 at any time
[22:36] <michaelni> discontinuities without timestamps is hard
[22:36] <michaelni> and a timestamps would generally end the relative timestamp use and convert them to absolute ones
[22:36] <kierank> ts doesn't have to have timestamps :)
[22:37] <michaelni> kierank, does that exist in reality ?
[22:37] <michaelni> the syntax allows it of course ...
[22:37] <kierank> yes
[22:37] <michaelni> hmm
[22:37] <michaelni> where ?
[22:37] <kierank> ask fenrir
[22:38] <kierank> fenrir wrote a ton of stuff in vlc to fix that
[22:38] <kierank> teletext doesn't have timestamps at all
[22:38] <kierank> that's very common
[22:39] <michaelni> hmm, ill change it to 48bit then
[22:39] <michaelni> that makes room for 99 years at 90khz
[22:40] <durandal11707> michaelni: toke look at sws_flags print_info issue?
[22:40] <Tjoppen> in 2111 someone will read the IRC logs and shake their head
[22:44] <Tjoppen> time to fiddle more with my new camera
[22:45] <michaelni> in 2111 they cant just increase it and run a compiler anymore ?
[22:45] <Daemon404> in 2111, timestamps will be irrelevant because we will have broken space-time
[22:46] <durandal11707> in 2111 there will be no time
[22:47] <Tjoppen> o/~ In the year 2525, if man is still alive.. o/~
[22:47] <ubitux> jesus will soon resurrect so we will just reset the year to zero
[22:48] <ubitux> of course, non-believers will have to deal with the issue differently
[22:48] <Daemon404> we wouldnt have these problems if time was cyclical
[22:48] <Daemon404> then we could just use a modulus system
[22:49] <michaelni> Daemon404, do you have a proof time is not cyclical ?
[22:49] <Daemon404> well i havent picked up any tetrion particles
[22:50] <Daemon404> /nerd
[22:50] <Daemon404> or tetryon.. howveer it is spelled
[22:50] <Tjoppen> tachyon?
[22:51] <Daemon404> http://en.memory-alpha.org/wiki/Tetryon
[22:51] <Tjoppen> man, kdenlive is really choppy and the render window doesn't always show the correct frame. such a shame
[22:51] <Daemon404> i think tachyon is what i9 wanted tho
[22:51] <Daemon404> is*
[23:38] <cbsrobot> ubitux: I thought it was the "closing paragraph day" today
[23:41] <ubitux> :)
[23:44] <cbsrobot> michaelni: I sent another patch
[23:48] <ubitux> it's already applied\
[23:49] <ubitux> michaelni is trying to reach the time wrap as fast as possible so we can have more than 99yrs at 90khz
[23:49] <Orphis> Are you aware that ffmpeg doesn't build with brew on OSX with LLVM ?
[23:50] <ubitux> vf fspp?
[23:50] <Orphis> Yes
[23:51] <ubitux> yes we are aware of that
[23:51] <Orphis> Two undefined symbols like _MM_FIX_0_707106781 and _MM_FIX_0_541196100 on x86_64
[23:51] <Orphis> Ok
[23:51] <Orphis> I guess configure --disable-filter=mp will "fix" it
[23:52] <ubitux> if you have a patch for this& :)
[23:52] <ubitux> most of the dev can't really test
[23:52] <Orphis> I can test and dev, but I don't quite understand that assembly :p
[23:53] <CIA-17> ffmpeg: 03Nicolas George 07master * r1ea3b657d6 10ffmpeg/libavfilter/vf_yadif.c: 
[23:53] <CIA-17> ffmpeg: vf_yadif: accept input with several frames available.
[23:53] <CIA-17> ffmpeg: Fixes ticket #1040.
[23:54] <Orphis> I could try to give you a preprocessed file if you want
[23:54] <Orphis> Or the symbols in the .o
[23:59] <ubitux> Orphis: http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2012-February/120830.html
[23:59] <ubitux> you may want to look at this
[23:59] <ubitux> i don't want to blindly try to patch this again :)
[23:59] <Orphis> That seems to go in the same direction as I thought
[00:00] --- Thu Mar  8 2012