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

[burek]

[00:08:26 CEST] <cone-444> ffmpeg 03Tucker DiNapoli 07master:cbe27006cee0: postproc: Made QP, nonBQP, and pQPb arrays
[04:21:10 CEST] <BBB> michaelni: if you like, I can upload a tree to github for merging
[04:21:18 CEST] <BBB> michaelni: that may be easier than hand-applying all these patches
[04:37:56 CEST] <michaelni> BBB, sure but you left 1 minute after you asked
[04:41:04 CEST] <Compn> lol
[04:56:18 CEST] <jamrial> av_clip_uint8_c() in common.h, shouldn't "return (-a)>>31" be "return (-a)>>31 & 0xFF"?
[04:58:31 CEST] <michaelni> the return type is uint8_t so it should be fine
[04:59:18 CEST] <jamrial> oh right, missed that
[04:59:20 CEST] <jamrial> nevermind then
[05:08:41 CEST] <cone-292> ffmpeg 03James Almer 07master:d7f62f033c21: fate: add cinepak encoder vsynth tests
[05:29:06 CEST] <cone-292> ffmpeg 03Ronald S. Bultje 07master:e8b4f6d6befc: vp9: add support for resolution changes in inter frames.
[05:29:07 CEST] <cone-292> ffmpeg 03Ronald S. Bultje 07master:df287f3e4362: vp9: add fate size for resolution changes.
[05:37:57 CEST] <j-b> 'morning
[09:17:42 CEST] <durandal_1707> 'morning
[11:40:49 CEST] <BtbN> https://github.com/BtbN/FFmpeg/blob/master/libavfilter/vf_colorkey.c#L110 Now it is to convert this to integer-math. Seems to work fine otherwise.
[11:53:03 CEST] <ubitux> BtbN: ah cool you've started adding threading
[11:53:14 CEST] <ubitux> don't forget to add the flags, otherwise it probably won't have any effect
[11:53:49 CEST] <BtbN> It seems to work already. At least it starts it with 5 jobs
[11:54:09 CEST] <ubitux> strange
[11:54:16 CEST] <ubitux> do you see any performance improvement?
[11:54:40 CEST] <ubitux> maybe it's doing 5 slices but... incrementally :p
[11:54:41 CEST] <BtbN> Nope, but i'm bottlenecked by the yuv->rgb and rgb->yuv conversion.
[11:55:02 CEST] <ubitux> you didn't use the drawutils btw?
[11:55:14 CEST] <ubitux> oh well, i'll wait for your next patch :)
[11:55:34 CEST] <BtbN> It's still very much work in progress, it's very possible i missed obvious helpers because i simply didn't know about them.
[11:55:54 CEST] <ubitux> you shouldn't use av_frame_make_writable
[11:56:25 CEST] <ubitux> anyway, will re-review at the end
[11:56:31 CEST] <BtbN> Why not? I'd have to copy the entire color plane anyway.
[11:56:39 CEST] <ubitux> then get a new buffer
[11:56:57 CEST] <ubitux> making it writable is if you need to modify the frame inplace
[11:57:09 CEST] <ubitux> there are multiple scenario:
[11:57:21 CEST] <ubitux> 1. you can not do in-place processing
[11:57:37 CEST] <ubitux> 2. you need to modify the frame
[11:58:23 CEST] <ubitux> 3. you can do in-place processing, but if it's non writable you can save a frame copy
[11:58:38 CEST] <ubitux> anyway, i'm not sure of your case
[11:58:42 CEST] <BtbN> I potentialy have to modify the frame format though.
[11:58:50 CEST] <BtbN> As BGR0 gets BGRA in the process for example.
[11:59:03 CEST] <ubitux> ah if you have different pixel format, just get a new buffer then
[11:59:22 CEST] <ubitux> but do not make your input writable (don't modify it then, just write in the new out)
[11:59:42 CEST] <BtbN> It's not realy a diffrent format, i just make use of the formerly unused byte.
[12:00:04 CEST] <BtbN> So in-place processing is very much possible.
[12:00:22 CEST] <ubitux> mmmh
[12:00:30 CEST] <ubitux> i see
[12:00:33 CEST] <BtbN> And as the entire RGBA color is in a single plane, i'd have to copy it anyway
[12:00:45 CEST] <BtbN> So there shouldn't be much difference between manualy copying it, or make_writable
[12:00:51 CEST] <ubitux> are you sure it's not going to do something stupid as mapping ARGB to RGBA typically?
[12:01:12 CEST] <ubitux> (like, let's say the previous filters output ARGB and the next filter in the graph can take only RGBA)
[12:01:26 CEST] <ubitux> (to save a convert, it might do this)
[12:02:09 CEST] <BtbN> yes, i wondered about that. I'm currently setting outlink->format in config_props of my output link.
[12:02:12 CEST] <ubitux> you can test it with something like format=abgr,colorkey,format=rgba
[12:02:29 CEST] <ubitux> (i suppose)
[12:02:45 CEST] <BtbN> I'd basicaly have to somehow tell it that 0BGR gets ABGR, BGR0 gets BGRA, and so on.
[12:02:52 CEST] <ubitux> hopefully the pixel format negociation is smart enough to save the convert now
[12:03:08 CEST] <ubitux> BtbN: yeah, i don't remember how to achieve that though
[12:03:12 CEST] <ubitux> saste might know
[12:03:44 CEST] <BtbN> I could avoid that by just accepting Alpha-Formats as input, but then a potentialy unneccsary conversion is done.
[12:03:54 CEST] <ubitux> one thing you can do is basically make the frame writable if and only if the pixel format are "compatible"
[12:04:12 CEST] <ubitux> and otherwise get a new buffer
[12:04:23 CEST] <ubitux> actually... you might just swap the pointers
[12:04:54 CEST] <ubitux> oh and btw, you are rewriting every pixel of the same frame
[12:05:02 CEST] <ubitux> so technically, you can avoid making it writable
[12:05:14 CEST] <ubitux> and if it's not writable, you should get a new buffer instead
[12:05:26 CEST] <BtbN> I'm only re-writing the alpha byte of each pixel.
[12:05:27 CEST] <ubitux> because making it writable will get a new buffer AND copy the frame data
[12:05:34 CEST] <ubitux> ah mmh
[13:10:35 CEST] <cone-969> ffmpeg 03wm4 07master:60191e3aec6a: fate: add mp3 CBR seek test
[13:39:16 CEST] <BtbN> ubitux, https://bpaste.net/show/29fd51b05f71 it seems to select the wrong output format first(line 75), but later, when it gets the first actual output frame, it switches to the right one(line 105).
[13:41:43 CEST] <nevcairiel> dont you have rgba in the command line
[13:50:45 CEST] <BtbN> nevcairiel, yes. The problem is, the colorkey filter "converts" bgr0->bgra, rgb0->rgba, ...
[13:50:57 CEST] <BtbN> But there doesn't seem to be a way to communicate this in query_formats
[13:51:32 CEST] <nevcairiel> there must be other filters that convert some sort of mapping
[13:52:27 CEST] <cone-969> ffmpeg 03Vittorio Giovara 07master:45340f9fc77e: network: Do not leave context locked on error
[13:52:47 CEST] <BtbN> Haven't found one so far
[13:53:15 CEST] <nevcairiel> query_formats does seem to be able to have access the input already, no?
[13:53:28 CEST] <nevcairiel> at least vf_scale references the incoming filter connection to figure out pixel formats
[13:54:28 CEST] <BtbN> Hm, if the input is already accesible
[13:55:07 CEST] <BtbN> I remember reading somewhere that this isn't the case.
[13:55:16 CEST] <wm4> BtbN: from what I remember it's not possible, but I might be very much wrong
[13:55:21 CEST] <nevcairiel> if i were to implement a filter graph, i would connect it one by one, and only call query_formats once the input was connected .. but of course there is no guarantees lavfi is sane in any way
[13:56:11 CEST] <wm4> lavfi tries to do "perfect" format negotiation by doing a global search or something
[13:58:24 CEST] <nevcairiel> most filters do in_format=out_format .. they somehow need to be able to know which format is the input to set the proper output format, no?
[13:58:42 CEST] <ubitux> BtbN: you should just add some code to swap the pointers if necessary
[13:58:58 CEST] <BtbN> swapping what pointers?
[13:58:59 CEST] <nevcairiel> rgba doesnt have pointers, its interleaved :D
[13:59:02 CEST] <ubitux> so whatever it selects you get back on your feet
[13:59:06 CEST] <ubitux> ah damn ofc
[13:59:10 CEST] <ubitux> forgot that "detail"
[14:00:38 CEST] <BtbN> the vf_scale query_formats just asks swscale is the format is a supported input/output format
[14:00:45 CEST] <BtbN> it doesn't reference the actual input format.
[14:01:27 CEST] <BtbN> The only solution i see would be to go BGRA-Only as both input and output format.
[14:02:15 CEST] <BtbN> But something, somehow is able to handle on-the-fly output format changes. At least my filter works, even though it initialy was negotiated for a diffrent output format.
[14:04:48 CEST] <wm4> <nevcairiel> most filters do in_format=out_format .. they somehow need to be able to know which format is the input to set the proper output format, no? <- they set a shared format list for those 2 outputs
[14:05:13 CEST] <wm4> then the common lavfi code "reduces" these format lists while minimizing conversions
[14:05:25 CEST] <wm4> that's where my understanding ends
[14:05:31 CEST] <nevcairiel> sounds evil
[14:06:25 CEST] <BtbN> So basicaly, a filter that does some kind of mapping just isn't supported?
[14:06:38 CEST] <nevcairiel> apparently
[14:06:56 CEST] <nevcairiel> is changing the format after init bad?
[14:07:20 CEST] <BtbN> That's what i'm doing. I change the outlink format in its config_props
[14:07:25 CEST] <BtbN> And it actualy does work
[14:09:50 CEST] <wm4> BtbN: you should ask one of those who actually know
[14:09:58 CEST] <wm4> like saste I suppose?
[14:10:07 CEST] <wm4> maybe ubitux and Nicolas George
[14:10:27 CEST] <ubitux> i think you should just remap yourself inside your code if necessary
[14:11:00 CEST] <BtbN> So basicaly implement full RGB color format conversion?
[14:11:08 CEST] <ubitux> also, you might want to work with native rgb endianess and be done with that
[14:29:42 CEST] <BtbN> ubitux, native means bgr0/bgra on little endian, an argb/0rgb on big endian?
[14:29:43 CEST] <BBB> BtbN: Id ask michael/stefano, I tihnk that it was supported
[14:30:43 CEST] <ubitux> BtbN: #define AV_PIX_FMT_RGB32   AV_PIX_FMT_NE(ARGB, BGRA)
[14:31:01 CEST] <cone-969> ffmpeg 03Vittorio Giovara 07master:32da94fa7f73: lavf: Reset global flag on deinit
[14:31:01 CEST] <ubitux> #define AV_PIX_FMT_RGB32_1 AV_PIX_FMT_NE(RGBA, ABGR)
[14:31:03 CEST] <ubitux> #define AV_PIX_FMT_0RGB32  AV_PIX_FMT_NE(0RGB, BGR0)
[15:29:24 CEST] <vadmeste> Hello everybody. I want to be able to copy the m3u8 file generated by ffmpeg when streaming my video online. I just wonder if it is possible that m3u8 could be corrupted.. Is there any mechanism to know that the current state of the m3u8 file regulary updated by ffmpeg is consistent ?
[15:30:24 CEST] <Daemon404> is this for hls?
[15:30:34 CEST] <Daemon404> if so, it should be atomic.
[15:31:09 CEST] <nevcairiel> i made it atomic a while ago, if you use hlsenc
[15:31:19 CEST] <nevcairiel> speaking of hlsenc, did your overhead-reduction ever get applied Daemon404?
[15:31:32 CEST] <Daemon404> i kinda forgot
[15:31:46 CEST] <Daemon404> after angry email came in from some guu
[15:31:47 CEST] <Daemon404> guy*
[15:32:04 CEST] <nevcairiel> why do people write angry emails about such things
[15:33:03 CEST] <nevcairiel> anyone bothered to check if gcc 5.1 miscompiles ffmpeg yet?
[15:33:30 CEST] <Daemon404> not yet
[15:33:34 CEST] <Daemon404> msys2 has made me lazy
[15:33:41 CEST] <Daemon404> and they dont have 5.1 yet
[15:33:42 CEST] <nevcairiel> i still dont like msys2
[15:33:48 CEST] <Daemon404> why
[15:33:58 CEST] <nevcairiel> i cant just run bash.exe and have a working build env
[15:34:01 CEST] <BtbN> Updating to gcc 5.1 is a major pain for most distributors.
[15:34:13 CEST] <Daemon404> nevcairiel, wut?
[15:34:16 CEST] <Daemon404> you run the shell -> works
[15:34:31 CEST] <nevcairiel> yes, with their script that sets up the environment
[15:34:35 CEST] <BtbN> I prefer cygwin as unix-like environment on windows.
[15:34:36 CEST] <nevcairiel> but not from a plain bash/sh.exe
[15:34:58 CEST] <Daemon404> i would never do that anyway
[15:35:07 CEST] <Daemon404> i always ran msys.bat
[15:35:11 CEST] <nevcairiel> works just fine on my old msys
[15:35:33 CEST] <nevcairiel> and i have a bunch of windows batch scripts that call build scripts using sh.exe
[15:35:36 CEST] <Daemon404> heh
[15:35:53 CEST] <nevcairiel> ie. my fate scripts, for example!
[15:36:42 CEST] <Daemon404> my fate scripts work fine in msys2
[15:36:50 CEST] <Daemon404> since i was lazy and did:
[15:36:55 CEST] <Daemon404> env > myenv
[15:37:02 CEST] <Daemon404> and regex'd it into a shell script
[15:37:04 CEST] <Daemon404> (lol)
[15:37:17 CEST] <vadmeste> Daemon404: yes it is for hls, thanks for answering, could you just tell me how did manage to implement that atomic update, is it tmp + rename ?
[15:37:47 CEST] <Daemon404> yes
[15:37:50 CEST] <Daemon404> look at hlsenc.c
[15:38:06 CEST] <nevcairiel> my main fate scripts are .bat files because they need to call the microsoft env script
[15:38:18 CEST] <nevcairiel> so they just call sh fate-run.sh or something
[15:38:21 CEST] <Daemon404> nevcairiel, mine are too.
[15:38:31 CEST] <Daemon404> the ycall a wrapper script
[15:38:33 CEST] <Daemon404> which loads the env
[15:38:53 CEST] <BtbN> cygwin is somehow able to source bat files, i use that for the VC-Env-Stuff.
[15:39:05 CEST] <nevcairiel> can you at least use the msys.bat to directly call a command with env setup?
[15:39:12 CEST] <wm4> debian already has gcc 5
[15:39:20 CEST] <BtbN> With the old abi only.
[15:39:37 CEST] <BtbN> Or did they rebuild the entire system with the new one?
[15:39:49 CEST] <nevcairiel> they rebuild the entire system all the time anyway
[15:40:06 CEST] <BtbN> Well, this update would require a version bump on absolutele very package.
[15:40:16 CEST] <wm4> even pure C ones?
[15:40:21 CEST] <nevcairiel> no
[15:40:31 CEST] <BtbN> Everything that somehow links against libstdc++
[15:40:33 CEST] <ubitux> it's only related to c++ madness
[15:40:35 CEST] <ubitux> as usual
[15:40:52 CEST] <BtbN> Can also be C stuff, that linkst against a C++ library.
[15:41:02 CEST] <Daemon404> wrong
[15:41:10 CEST] <Daemon404> the c stuff by definition only uses teh c abi
[15:41:17 CEST] <Daemon404> if it links against a lib which uses c++ it doesnt matter
[15:41:20 CEST] <Daemon404> the c abi remains stable
[15:41:25 CEST] <Daemon404> only the extrnal lib needs to be rebuilt
[15:41:36 CEST] <nevcairiel> indeed
[15:53:20 CEST] <cone-969> ffmpeg 03Michael Niedermayer 07master:06747f8484aa: tests/tiny_psnr: do not ignore errors from run_psnr
[16:39:03 CEST] <Prelude2004c> hey guys. can anyone help me with segment.c programming
[16:39:20 CEST] <Prelude2004c> need to encrypt data of each created segment ... doesn't seem to have that capability
[17:00:35 CEST] <cone-969> ffmpeg 03Ronald S. Bultje 07master:d02619fde301: vp9: add fate test for bilinear MC filter.
[17:00:36 CEST] <cone-969> ffmpeg 03Ronald S. Bultje 07master:c82e870c12b2: vp9: maintain lf_delta values if feature is turned off.
[17:00:37 CEST] <cone-969> ffmpeg 03Andreas Cadhalpun 07master:58d605ee9b32: alsdec: only adapt order for positive max_order
[20:35:30 CEST] <cone-969> ffmpeg 03Ronald S. Bultje 07master:d9555adf06d5: vp9: set timestamps for show_existing_frame return images.
[20:35:31 CEST] <cone-969> ffmpeg 03Pedro Arthur 07master:2a7128f4ed00: Add gamma encodign/decoding before/after scaling in libswscale
[20:35:32 CEST] <cone-969> ffmpeg 03Michael Niedermayer 07master:b57f9f57240a: swscale/swscale: Get rid of the SWS_GAMMA_CORRECT flag
[21:17:31 CEST] <cone-969> ffmpeg 03Federico Tomassetti 07master:8eb57dc9d5ea: buffersrc: Use the correct deallocation function
[21:17:32 CEST] <cone-969> ffmpeg 03Michael Niedermayer 07master:16576a66626a: Merge commit '8eb57dc9d5ea13c12573e0759da0f7e79825af98'
[21:31:29 CEST] <cone-969> ffmpeg 03Luca Barbato 07master:aef0be08756e: avcodec: Unref the dummy buffer on the fail path
[21:31:31 CEST] <cone-969> ffmpeg 03Michael Niedermayer 07master:c39b07ff282a: Merge commit 'aef0be08756e00f363c524453c948a6e2a348614'
[21:57:36 CEST] <cone-969> ffmpeg 03Luca Barbato 07master:a78f5548d94f: avcodec: Free the default avoptions on init failure
[21:57:37 CEST] <cone-969> ffmpeg 03Michael Niedermayer 07master:b112e25dde39: Merge commit 'a78f5548d94f23ce23cece41edf0fe9d18926de6'
[22:04:50 CEST] <cone-969> ffmpeg 03Luca Barbato 07master:28eddef689f2: hq_hqa: Validate get_vlc2 return value
[22:04:51 CEST] <cone-969> ffmpeg 03Michael Niedermayer 07master:400810abee8f: Merge commit '28eddef689f2b4843a84f7d05fd9614246f92cc4'
[22:15:09 CEST] <cone-969> ffmpeg 03Luca Barbato 07master:0a51c7d42a51: prores: Set the bits_per_coded_sample for alpha pix_fmt
[22:15:10 CEST] <cone-969> ffmpeg 03Michael Niedermayer 07master:8d31b22869f6: Merge commit '0a51c7d42a519c63178a4f3e35b8967f21da3a6a'
[22:58:35 CEST] <cone-969> ffmpeg 03Timothy Gu 07master:358b7ec3099e: fate: Fix test name for pixfmts tests
[22:58:36 CEST] <cone-969> ffmpeg 03Michael Niedermayer 07master:802c0af68f22: Merge commit '358b7ec3099eca6e999ad9dc0da0a23571a7a2f8'
[00:00:00 CEST] --- Fri Apr 24 2015