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

[burek]

[00:01:41 CET] <Cornelius^> hi guys, whats the story on vp9 hardware accellerated encoding?
[00:02:03 CET] <nevcairiel> there is no story
[00:09:39 CET] <atomnuker> speed of our native flac encoder + multi dimensional quantization - 0.000283x
[00:09:56 CET] <atomnuker> it would take longer than a year to encode 5 minutes according to my math
[00:10:05 CET] <atomnuker> actually 2 years
[00:10:18 CET] <nevcairiel> why does this mode even exist :D
[00:10:57 CET] <nevcairiel> our PCs are not ready for alien technology yet
[00:11:20 CET] <wm4> some sort of audiophile mode
[00:20:11 CET] <cone-336> ffmpeg 03Michael Niedermayer 07master:cde57eee98d2: avformat/hls: Check that filename is not "" in probe before checking its extension
[00:29:41 CET] <JEEB> lol
[00:31:22 CET] <cone-336> ffmpeg 03James Almer 07master:1d8f9b7d1ad2: avcodec/webp: fix decoder dependencies
[00:43:51 CET] <atomnuker> speed=6.53e-05x
[00:44:13 CET] <atomnuker> I didn't even know it was possible to have the speedometer output this format
[00:44:22 CET] <nevcairiel> haha
[00:47:12 CET] <J_Darnley> durandal_170, atomnuker: I need to get my 32-bit flac lpc assembly committed.  That will help (somewhat) after a fairly recent bugfix.
[00:49:10 CET] <atomnuker> yeah, that would allow for more LPC passes
[00:49:32 CET] <atomnuker> but not under x86_64, right?
[00:49:38 CET] <durandal_170> I need to figure frame encoder for audio
[00:50:16 CET] <durandal_170> Multithreaded*
[00:50:17 CET] <J_Darnley> No I mean for 32 bit coeffs not arch
[00:50:48 CET] <J_Darnley> A 32*32=64 bit multiply then
[02:42:02 CET] <BBB> nevcairiel: what a silly question
[02:42:36 CET] <BBB> nevcairiel: try vpxenc passes=2 best cpu-used=0 4kinputvideo.y4m codec=vp9 -o output.webm
[02:42:49 CET] <BBB> nevcairiel: why does that mode exist? nobody knows
[02:43:13 CET] <Timothy_Gu> that's video. there's an excuse to be slow
[02:43:18 CET] <BBB> x265 isnt any better with preset=veryslow
[02:43:39 CET] <BBB> with x265, preset=veryslow passes=2, I believe pass 1 and pass2 are equally slow
[03:00:12 CET] Action: jamrial wants the new dca decoder committed already
[03:00:22 CET] <jamrial> i already wrote some easy simd for it :p
[03:00:52 CET] <jamrial> pity as is it broke decoding of that one file michaelni pointed out
[07:30:18 CET] <ac_slater> with a libavcodec encoder, what's the significance of AVCodec.pix_fmts? Does some auto conversion happen?
[08:00:06 CET] <ac_slater> I see this when I attempt to put rawvideo yuyv422 into my encoder
[08:00:09 CET] <ac_slater> [auto-inserted scaler 0 @ 0x15ee6d0] w:640 h:480 fmt:yuyv422 sar:0/1 -> w:640 h:480 fmt:yuv420p sar:0/1 flags:0x4
[08:01:02 CET] <ac_slater> the result mostly green (always), which tells makes me thing a conversion didn't happen
[08:01:04 CET] <ac_slater> clues?
[08:12:18 CET] <ac_slater> which tells me a conversion didn't happen* 
[10:32:35 CET] <Warblefly_> Gentlemen, thank you for fixing "master:cde57eee98d2: avformat/hls: Check that filename is not "" in probe before checking its extension" -- just about to test
[11:12:26 CET] <cone-569> ffmpeg 03Mats Peterson 07master:fe7639b1c8be: avcodec/rawdec: initialize palette for mono
[11:12:26 CET] <cone-569> ffmpeg 03Mats Peterson 07master:82325dbec144: lavc/rawdec: Use 16-byte line alignment for 1, 2, 4 and 8 bpp
[11:12:26 CET] <cone-569> ffmpeg 03Michael Niedermayer 07master:46f67f4a34ca: avcodec/rawdec: Check height and packet size
[13:52:40 CET] <durandal_1707> michaelni: I added audio support to frame_thread_encoder, but somehow other threading code from decoder kicks in and segv
[14:49:08 CET] <durandal_1707> michaelni: ping
[14:52:30 CET] <atomnuker> so supposing I have a decoder which needs to output an interlaced picture (so I have 2 frames coming in but a single frame coming out)
[14:52:45 CET] <Daemon404> atomnuker, youre screwed
[14:52:53 CET] <Daemon404> i already tried that for libx265 support
[14:53:00 CET] <Daemon404> (hevc interlaced is 2 output packets)
[14:53:16 CET] <wm4> wait, 2 packets in, 1 frame out should be fine
[14:53:19 CET] <wm4> since this is decoding
[14:53:36 CET] <atomnuker> can't I somehow save the contents of an AVFrame and continue with it?
[14:53:36 CET] <Daemon404> oh i misread
[14:53:49 CET] <Daemon404> atomnuker, in the private context
[14:54:04 CET] <Daemon404> unless you mean entirely copyless
[14:54:13 CET] <atomnuker> do I need to just save the pointer or use some copy function?
[14:54:42 CET] <Daemon404> im nto sure of the rules for the buffer returned from get buffer
[14:54:44 CET] <wm4> make a ref
[14:54:47 CET] <wm4> with av_frame_ref
[14:54:57 CET] <atomnuker> would be nice if I could just continue with the same AVFrame I've saved and just signal that that AVFrame is the one I want to output
[14:55:16 CET] <Daemon404> i think wm4 is right here
[14:56:59 CET] <atomnuker> so for the first field I set an AVFrame in my context as a ref
[14:57:15 CET] <atomnuker> but what do I do for the second field?
[14:57:39 CET] <atomnuker> copy whatever I need from my ref to the new AVFrame?
[14:57:49 CET] <Daemon404> dont request a new buffer at all
[14:57:57 CET] <Daemon404> i assume
[14:58:01 CET] <Daemon404> and return the other
[14:58:08 CET] <Daemon404> and properly unref?
[14:58:11 CET] <Daemon404> (im noty 100% myself)
[14:58:15 CET] <wm4> I guess you could also somehow decode into the same AVFrame by playing with the strides?
[14:58:23 CET] <wm4> dunno
[14:59:34 CET] <Daemon404> what stops you from decoding into the same avframe?
[15:00:28 CET] <atomnuker> nothing except I don't know how to output the avframe I have instead of the one I get in the second field
[15:00:48 CET] <Daemon404> there's a function to use the same buffer i think
[15:00:57 CET] <Daemon404> elenril would know best
[15:08:05 CET] <durandal_1707> michaelni: and indeed encode context is same as decoder one
[15:18:59 CET] <michaelni> durandal_1707, encoder and decoder should have seperate contexts
[15:19:31 CET] <michaelni> but maybe i misunderstand
[15:20:36 CET] <nevcairiel> atomnuker: you can just do what you propose, just decode into one avframe and when its done output it
[15:20:54 CET] <durandal_1707> michaelni: clearly, they are shared, I printed pointers
[15:21:26 CET] <michaelni> atomnuker, yes, as nevcairiel says, first field in, no output, 2nd field in output a frame 
[15:22:14 CET] <atomnuker> okay, but I still have to move the stuff from my ref/buffer to the new frame
[15:22:21 CET] <atomnuker> though the overhead would be minimal probably
[15:22:24 CET] <michaelni> durandal_1707, a AVCodecContext is either a encoder or a decoder not both
[15:22:37 CET] <nevcairiel> atomnuker: its just copying a pointer around, many decoders do that
[15:22:50 CET] <nevcairiel> its not like you are copying the frame contents
[15:23:41 CET] <atomnuker> so first field, put stuff in the avframe, make a ref at the end, *got_frame = 0
[15:23:58 CET] <atomnuker> and the second field I just call av_frame_move_ref() to move the stuff to the new avframe
[15:24:01 CET] <nevcairiel> create your own avframe to put stuff into, dont put it into the one you get
[15:24:15 CET] <nevcairiel> only on the second field move_ref your internal avframe over the one decode() is called with
[15:25:22 CET] <Daemon404> sounds right
[15:26:33 CET] <durandal_1707> michaelni: try patch I just posted
[15:54:11 CET] <durandal_1707> michaelni: also frame mt encoder seems to be called for encoders that do not have cap flag
[15:56:19 CET] <Daemon404> i think it may be done for intra-only codecs automatically?
[15:56:22 CET] <Daemon404> (maybe)
[15:57:18 CET] <michaelni> IIRC, yes
[16:06:12 CET] <wm4> BtbN: I'm fighting with vdpau preemption again... god I hope libav wins this API war
[16:09:11 CET] <nevcairiel> you mean libva?
[16:09:25 CET] <nevcairiel> this preemption business sounds like a badly thought out design
[16:10:02 CET] <wm4> err, yes, libva
[16:10:05 CET] <wm4> (interesting typo)
[16:10:19 CET] <wm4> well it seems to be modeled after D3D preemption
[16:10:19 CET] <BtbN> you mean handling of the display device getting taken away at runtime?
[16:10:22 CET] <wm4> aka "lost devices"
[16:10:26 CET] <wm4> yes
[16:10:39 CET] <BtbN> How does libva handle that?
[16:10:44 CET] <wm4> and the new vdpau hwaccel API is also being a fucking pain in the ass about this
[16:10:48 CET] <nevcairiel> interestingly i never had to deal with that from a decoder side, since the video renderers all take care of that
[16:10:52 CET] <wm4> BtbN: it simply doesn't have the concept
[16:10:59 CET] <BtbN> So it would just explode?
[16:11:09 CET] <wm4> I don't know?
[16:11:17 CET] <wm4> does vaapi decoding explode if you change VTs?
[16:11:20 CET] <wm4> because vdpau does
[16:11:24 CET] <BtbN> Never tried that
[16:11:45 CET] <BtbN> But as the libva intel driver communicated directly with the in-kernel drm driver, I wouldn't think so.
[16:12:02 CET] <BtbN> If nvidia were to implement a VAAPI driver, things might be different
[16:13:44 CET] <jkqxz> Yeah, libva doesn't really care about the display at all.  It runs fine headless, connecting to the DRM device directly.
[16:14:16 CET] <wm4> well vdpau doesn't handle display in my case either
[16:14:26 CET] <nevcairiel> easy enough for intel to get away with, they dont have th chance of multiple gpus being available in their igpu setups =p
[16:14:31 CET] <BtbN> Doesn't VDPAU require an active X display?
[16:14:33 CET] <jkqxz> (This is helpful when you are trying to develop things and get random GPU hangs because the driver sucks.)
[16:14:54 CET] <wm4> BtbN: yes
[16:15:02 CET] <BtbN> You can easily kill the CPU entirely when doing stuff with VAAPI
[16:15:14 CET] <BtbN> Forcing you to remove power from the device for a while for it to recover
[16:15:25 CET] <nevcairiel> that bad huh
[16:15:41 CET] <BtbN> Happend a few times while implementing the HEVC stuff
[16:16:04 CET] <BtbN> Wrong parameters? The CPU is out of this for today.
[16:16:05 CET] <jkqxz> I've never had it go that far.  I had to use a headless machine because it messed with X, but it did always recover.
[16:16:46 CET] <nevcairiel> intels windows drivers also like to crash on such things, but in that case usually only the application, not at kernel level, or even hardware =p
[16:17:06 CET] <jkqxz> That was all HEVC too (encode).  H.264 seemed much more solid, but then it is significantly older.
[16:17:52 CET] <BtbN> encoding with libva is ridiculously convoluted.
[16:18:14 CET] <BtbN> It just feels like the developers were trying to do the least possible amount of work.
[16:18:49 CET] <BtbN> We need all those bitstream parameters passed via some structs? Ok, fine, let's not use them to generate the NAL bitstream and instead require the api user to generate it!
[16:20:20 CET] <fritsch> lol sounds like vaapi
[16:20:25 CET] <fritsch> ah it's about vaapi
[16:20:37 CET] <jkqxz> How could we generate that ourselves?  The user might want to use one of the other parameters which we randomly missed out of the structs!
[16:21:03 CET] <BtbN> They could still offer to pass the NAL the same way one has to do right now.
[16:21:16 CET] <BtbN> But instead of erroring out, generate it internaly if it's not given...
[16:34:51 CET] <durandal_1707> michaelni: it is evil, anyway have you tried patch?
[16:41:09 CET] <kierank> BBB: is there a way of getting gcc to treat the variable as a constant?
[16:41:23 CET] <kierank> will it work with const int and a hardcoded branch in the wrapper?
[16:41:46 CET] <BBB> a hardcoded branch works
[16:42:01 CET] <BBB> if (var == 10) { clip(10); } else clip(12);
[16:42:01 CET] <BBB> or so
[16:42:16 CET] <BBB> if thats not easily possible, dont use clip_uint8p2
[16:42:22 CET] <BBB> its only speed advantage is on arm anyway
[16:42:28 CET] <BBB> because you can hardcode the exponent
[16:42:32 CET] <BBB> without it needing a reg
[16:42:33 CET] <kierank> I want to keep the wrappers in place
[16:42:35 CET] <kierank> and avoid macros
[16:42:47 CET] <BBB> do whatever you think is best
[16:44:23 CET] <ubitux> kierank: i'm explaining this in the post of sent you already
[16:44:44 CET] <ubitux> s/of/i/
[16:45:59 CET] <kierank> ubitux: where is this?
[16:46:49 CET] <ubitux> http://blog.pkh.me/p/20-templating-in-c.html
[16:46:59 CET] <kierank> ah no i dont want to use macros for that :(
[16:47:11 CET] <ubitux> the macro overhead is low
[16:47:17 CET] <kierank> they look ugly
[16:47:21 CET] <ubitux> look at "Mixing full functions mechanism and macro"
[16:47:48 CET] <ubitux> or the section just before with no macro
[16:48:24 CET] <cone-102> ffmpeg 03Michael Niedermayer 07master:ed0c550564a8: avcodec/utils: run ff_frame_thread_encoder_init() only for encoders
[16:48:32 CET] <wm4> rewrite in C++
[16:48:37 CET] <kierank> I'm just going to clip normally
[16:48:56 CET] <kierank> I don't care much for the c anyway
[16:50:57 CET] <michaelni> durandal_1707, yes, it segfaults, i fixed one bug but there likely are more 
[16:51:16 CET] <kierank> BBB: also is adding GBRAP12 pixel format hard?
[16:53:06 CET] <jamrial> BBB:, kierank: maybe the arm optimized versions of clip_unit* could use av_builtin_constant_p?
[16:54:22 CET] <jamrial> or yeah, just use generic av_clip. on x86 it should use cmov anyway
[16:54:35 CET] <michaelni> durandal_1707, actually it seems your patch is nearly working now after that single bugfix
[16:54:45 CET] <michaelni> iam getting "sample/frame number mismatch in adjacent frames"
[16:55:04 CET] <michaelni> and it likely still would try to use threading with all non video encoders
[16:55:14 CET] <BBB> kierank: no
[16:55:56 CET] <BBB> jamrial: probably, but there may be compilers not supporting that
[16:56:05 CET] <BBB> jamrial: not sure :)
[16:56:46 CET] <BBB> and do we hae agreement on how hwaccel+mt should work now? Ill get to coding then sometime soon
[16:58:04 CET] <wm4> BBB: if you could somehow lock out concurrency completely in this scenario, that would be ideal
[16:58:18 CET] <BBB> I think thats the goal
[16:58:40 CET] <jamrial> are there arm compilers we support that are not gcc or clang? av_builtin_constant_p seems to check for __GNUC__
[16:58:43 CET] <BBB> i.e. if hwaccel is enabled and active, just lock the child and parent codec context together in their respective calls to decide_frame
[16:58:45 CET] <fritsch> what's the benefit of hwaccel and mt if I may ask?
[16:58:51 CET] <BBB> fritsch: none
[16:58:53 CET] <fritsch> i see really none
[16:59:05 CET] <BBB> fritsch: but we want hwaccel fallback to software to use mt
[16:59:11 CET] <fritsch> wait
[16:59:14 CET] <fritsch> we have something in kodi
[16:59:18 CET] <BBB> fritsch: so we cannot just disable it by setting avcodeccontext.n_threads to 1
[16:59:27 CET] <fritsch> ah! to make it easier
[16:59:33 CET] <fritsch> to not have to recreate everything
[16:59:41 CET] <BBB> well, more for end user transparency
[16:59:58 CET] <BBB> you should be able to enable mt and hwaccel and have us figure out whats good for you
[17:00:00 CET] <fritsch> yeah - we reimplemented this scenario in kodi ~6 months ago
[17:00:07 CET] <fritsch> some patches were send and merged by rainer hochecker
[17:00:11 CET] <fritsch> our player head dev
[17:00:30 CET] <fritsch> for the fallback that is
[17:00:42 CET] <BBB> its hard to know when the fallback is enabled
[17:00:45 CET] <fritsch> did not need "many" ffmpeg changes, something with VC1 was an issue
[17:00:46 CET] <BBB> it can switch within the stream
[17:00:53 CET] <BBB> (adaptive)
[17:01:03 CET] <fritsch> okay - I trust you guys there
[17:01:11 CET] <BBB> its good that you did it, dont get me wrong
[17:01:12 CET] <fritsch> but please don't win MT by locking everything out ...
[17:01:19 CET] <fritsch> that won't help in performance and is just ugly
[17:01:35 CET] <BBB> dont worry, if theres anything Im good at, its performanc
[17:01:40 CET] <fritsch> BBB: i did not take any offense, happy that it gets easier in the future
[17:01:49 CET] <fritsch> to fallback
[17:01:53 CET] <fritsch> hehe, I know - I read your blog
[17:02:12 CET] <BBB> \o/
[17:02:30 CET] <fritsch> you do ffmpeg for living? or work at a university in the topics?
[17:02:41 CET] <fritsch> (sorry for offtopic)
[17:03:49 CET] <BBB> I do & video technology, I guess, for a living
[17:03:55 CET] <BBB> so ffmpeg is part of it
[17:04:00 CET] <BBB> but I do other things also
[17:04:14 CET] <BBB> Ill talk on my blog when its ready to be talked about ;)
[17:04:59 CET] <fritsch> thx for that - looking forward to read it
[17:05:07 CET] <fritsch> and adjusting our fallbacks of course
[17:05:23 CET] <fritsch> though - we will do when it is released as a stable
[17:05:56 CET] <fritsch> BBB: btw. we have some patches in kodi's ffmpeg since a very, very long time - who could we ask to check if they were needed and useful or just too specific and only useful for us?
[17:07:19 CET] <fritsch> https://github.com/xbmc/FFmpeg/commits/release/2.8-xbmc <- just 11 while the second could be interesting for nevcairiel 
[17:07:29 CET] <fritsch> as we had some AMD windows bailouts without that
[17:08:06 CET] <BBB> lemmesee
[17:08:17 CET] <BBB> from e00 onwards?
[17:08:44 CET] <fritsch> exactly, including
[17:09:29 CET] <Daemon404> none of these have any explanation as to why they are dine
[17:09:34 CET] <Daemon404> just "do x" or "fix X"
[17:09:52 CET] <fritsch> as said, historical since many years
[17:10:06 CET] <fritsch> that's why I also did not just want to send them to the ML
[17:11:00 CET] <fritsch> https://github.com/xbmc/FFmpeg/commit/4f9b154ad5b55e50d866a3907a20164d21a2b17c <- what about this one?
[17:12:00 CET] <BBB> I think about half of them seem sensible
[17:12:08 CET] <BBB> I also feel some of them are outdated and may not be necessary anymore
[17:12:19 CET] <BBB> it always helps to have files to reproduce, esp. for things like memleaks
[17:12:26 CET] <BBB> (4f9)
[17:12:28 CET] <fritsch> jep, exactly
[17:12:38 CET] <fritsch> the devs that did them are long gone
[17:12:48 CET] <fritsch> so - that's my issue
[17:12:48 CET] <fritsch> hehe
[17:13:30 CET] <BBB> it suggests that at some point, a code path existed where read_packet bails out without freeing allocated packets
[17:13:43 CET] <BBB> we can trace the code and see if that was the case years ago and if its still the case now
[17:13:46 CET] <BBB> thats not super-hard
[17:14:01 CET] <cone-102> ffmpeg 03Paul B Mahol 07master:06f65fd026a1: avcodec/dcaenc: return correct number of bytes in output packet
[17:14:02 CET] <cone-102> ffmpeg 03Paul B Mahol 07master:5dc37a5d8abd: avcodec/dcaenc: do not change user requested bitrate
[17:14:09 CET] <BBB> and if not, it can go (I suspect this was fixed since then, but its good to check anyway)
[17:14:18 CET] <BBB> if not, we fix a real bug! :)
[17:14:23 CET] <fritsch> hehe
[17:14:30 CET] <BBB> (obv by fixing it instead of keeping state)
[17:14:43 CET] <BBB> because right now you probably still get the memleak if you exit the loop and close the demuxer after
[17:14:45 CET] <BBB> which isnt quite right
[17:20:21 CET] <durandal_1707> michaelni: the pts are wrong, but same doesn't happen with video frame mt
[17:27:30 CET] <nevcairiel> fritsch: i havent had any reports about amd for a long time, i have some work arounds of my own in the user code however, not in avcodec
[17:27:50 CET] <fritsch> nevcairiel: oki
[17:28:23 CET] <fritsch> just wanted to point out, kodi does not have some "secret black magic code" somewhere - we just don't know how / if to send them upstream, cause for most we don't have samples anymore  - nor trac references
[17:28:46 CET] <fritsch> we could: just drop them and see what happens, though
[17:28:47 CET] <fritsch> hehe
[17:29:25 CET] <wm4> cargo cult patches are the best patches
[17:29:29 CET] <fritsch> hehe
[17:29:38 CET] <atomnuker> If I set *got_frame = 0 I get "Unable to parse option value "0x0" as image size"
[17:31:07 CET] <BBB> old patches like these are the best
[17:31:12 CET] <BBB> it fixed some issue 5 years ago"
[17:31:21 CET] <BBB> and nobody knows what to do
[17:31:44 CET] <BBB> ohwell, every project has these issues, its a luxury to be >5 years old I guess
[17:42:25 CET] <durandal_1707> michaelni: how are encoded frames - packets handled? first one wins?
[17:46:30 CET] <michaelni> not sure i understand but order should be maintained, the actual encoding could occur in any order (as it doesnt matter for intra only encoders)
[17:48:47 CET] <BBB> assuming it uses frame-mt, it autoamtiaclly waits the next to finish (so if frame N finished last, it pthread_cond_waits on N+1)
[17:49:06 CET] <BBB> and that automatically means order is maintained
[17:49:45 CET] <BBB> the threads themselves are responsible for handling inter-frame dependencies, so N+2 could finish earlier for intra-only, but the frame will never be handed back to frame-mt layer until N+1 is picked up first
[17:49:58 CET] <durandal_1707> michaelni: flac is busted as it have counter inside code, wavpack produces bitexact audio but pts are wrong
[17:50:45 CET] <BBB> durandal_1707: update_thread_context to sync counters between threads
[17:51:52 CET] <durandal_1707> BBB: we are talking about audio encoders
[17:52:11 CET] <BBB> they work the same
[17:59:24 CET] <atomnuker> here's a horror story for you: the Dirac decoder's way of handling references
[17:59:57 CET] <atomnuker> the format was extended to insane levels back when it was actively developed just to try to make it competitive
[18:00:05 CET] <atomnuker> so naturally it has B-frames
[18:00:14 CET] <durandal_1707> BBB: frame_thread_encoder is different
[18:00:39 CET] <BBB> durandal_1707: I dont think you want to use frame_thread_encoder, theres clearly an inter dependency
[18:00:41 CET] <BBB> (the counter)
[18:00:52 CET] <BBB> :-p
[18:02:37 CET] <durandal_1707> It works with alac
[18:03:25 CET] <durandal_1707> BBB: no code use pthread stuff for frame encoding
[18:03:41 CET] <BBB> I wasnt suggesting that
[18:03:47 CET] <BBB> nevermind
[18:04:11 CET] <durandal_1707> I guess the counter could be derived from pts
[18:05:36 CET] <BBB> oh I see frame_thread_encoder is not mt derived
[18:06:27 CET] <BBB> so & nobody will like me for saying this
[18:06:30 CET] <BBB> and youre just gonna flame me
[18:06:41 CET] <BBB> but you should look at how frame-mt (decoder) uses update_thread_context
[18:06:49 CET] <BBB> and use that callback for frame_thread_encoder.c also
[18:06:52 CET] <BBB> it solves your problem
[18:08:41 CET] <jermy> I need to get some information which is embedded in a SEI message. I assume the only place to sensibly copy data out is in libavcodec/h264?
[18:13:25 CET] <kierank> jermy: there are a number of examples already there
[18:13:26 CET] <kierank> yes
[18:13:28 CET] <kierank> as side data
[18:16:37 CET] <jermy> This is largely the use of AVFrameSideData?
[18:17:36 CET] <kierank> yes
[18:17:45 CET] <kierank> but the way it's handled is a bit nontrivial
[18:18:42 CET] <Daemon404> ^ this quote should be at the top of every libav* API doc
[18:18:43 CET] Action: Daemon404 runs
[18:27:29 CET] <Daemon404> the suspense is killing me
[18:28:50 CET] <jermy> ...profit?
[18:35:50 CET] <BtbN> "I am having issues converting an mp3 to an mp4 with a single watermark image and then converting that mp4 into mpeg ts for streaming." yes, I'd kind of call that an issue oO
[18:36:19 CET] <durandal_1707> BBB: proper flac mt needs syncing between workers 
[18:37:15 CET] <durandal_1707> michaelni: ^
[18:40:37 CET] <ubitux> nevcairiel: when is the next merge scheduled?
[18:41:23 CET] <ubitux> (there are ~80 commits)
[18:42:40 CET] <Daemon404> i can help if need be...
[18:50:39 CET] <michaelni> durandal_1707, some form of sync would need to be added, calling update and waiting for that like BBB suggested, or maybe its enough to just give each encoder a frame number for this case or something else
[18:51:20 CET] <durandal_1707> nah, flac keeps crap in stream info
[18:51:37 CET] <durandal_1707> Of all frames encoded
[19:07:05 CET] <cone-102> ffmpeg 03James Almer 07master:209f50e16b5e: avcodec/synth_filter: split off remaining code from dcadec files
[19:21:13 CET] <BBB> durandal_1707: thats update_thread_context, I just said that
[19:21:31 CET] <BBB> oh michaelni already said that
[19:29:37 CET] <durandal_1707> I don't get how to sync those workers
[19:30:12 CET] <nevcairiel> it would need quite a bunch of infrastructure
[19:30:36 CET] <nevcairiel> and depending on how the encoders work, might not actually work in frame threading
[19:31:03 CET] <nevcairiel> ie. if you only ´know all the parameters after you are done encoding the entire packet, then there is nothing to gain
[19:32:38 CET] <durandal_1707> nah, flac just need to pick between values of all workers after they finish work
[19:33:03 CET] <durandal_1707> and its just metadata
[19:33:22 CET] <durandal_1707> flac format needs it 
[19:33:54 CET] <BBB> durandal_1707: frame-mt uses ff_thread_finish_setup as initiation point of synchronization between workers
[19:34:39 CET] <durandal_1707> But frame-mt is only used for decoding
[19:35:28 CET] <durandal_1707> if it was actually used for frame encoding I would use it
[19:37:26 CET] <durandal_1707> I don't think that infrastructure works for encoding
[19:39:31 CET] <durandal_1707> It's funny because alac may now be faster than flac
[19:41:30 CET] <BBB> Im not saying you use it
[19:41:34 CET] <BBB> Im saying you use something like it
[19:42:00 CET] <BBB> it could even use the same function ptr in AVCodec
[19:42:01 CET] <Venti^> is AV_CODEC_FLAG_INTERLACED_DCT the correct flag to watch for to see if interlaced field coding should be used instead of progressive?
[19:47:56 CET] <cone-102> ffmpeg 03Mats Peterson 07master:191ec55c9fc1: lavc/rawdec: Use 16-byte line alignment for AV_PIX_FMT_MONOWHITE
[19:47:57 CET] <cone-102> ffmpeg 03Vittorio Gambaletta (VittGam) 07master:8b02af1e6fbb: avformat/mpegtsenc: Fix multi program so that it supports adding the same stream to multiple programs.
[19:53:36 CET] <roxlu> Hey! Does someone knows the tool "DVBAnalyzer" ? I'm using ift for a project and I'm getting an log message like "PTS_PCR problem (PTS is -0.90ms in the past!)"  I'm trying to understand the meaning of that message.  I would say that this may be caused by a PTS value which is behind the PCR; though when I log the PCR / PTS values from my MpegTS stream they are all nicely monotonically increasing.  
[20:29:48 CET] <wm4> nevcairiel: does "delaying" frames really help that much?
[20:29:53 CET] <nevcairiel> yes
[20:30:50 CET] <wm4> but only with nvidia?
[20:30:51 CET] <nevcairiel> at least on nvidia, on intel its so-so, i forgot what amd did
[20:30:58 CET] <wm4> ok
[20:31:05 CET] <wm4> maybe I should do this in my own code
[20:31:16 CET] <nevcairiel> its not like its a complex feature
[20:31:32 CET] <nevcairiel> i just have a static AVFrame array with 2 members and a variable that I modulo around to index into it
[20:31:46 CET] <nevcairiel> (not static as in global, mind you)
[20:37:19 CET] <durandal_1707> why is dvaudio decoder in lavf?
[20:38:55 CET] <nevcairiel> because dv is all sorts of crazy
[20:38:58 CET] <nevcairiel> a container in a container
[20:40:52 CET] <Compn> dvaudio in mov and avi...
[20:42:04 CET] <Compn> not sure specifically which dvaudio files need the lavf demuxer, but we probably have such samples.
[20:43:27 CET] <Compn>  should we keep track of such things in some kind of document somewhere ?
[20:43:38 CET] <Compn> like a reason for foobar.c to exist ?
[20:44:37 CET] <nevcairiel> I thought avi specifically had dv support as well
[20:47:30 CET] <Compn> well
[20:47:58 CET] <Compn> it looks like , from that ffmpeg output, that pinnacle didnt write the audio two cc (it says 'none') so i'm guessing thats causing some problem too
[20:49:01 CET] <Compn> oh lol
[20:49:09 CET] <Compn> old ffmpeg output, ignore m
[20:49:26 CET] <nevcairiel> did write a twocc though, 0x0216
[20:49:29 CET] Action: nevcairiel looks it up
[20:49:44 CET] <Compn> thats ulead dv acm yes
[20:49:56 CET] <Compn> it should work in mplayer :P
[20:50:03 CET] <nevcairiel> anyway thats the original file, no idea about the new one
[20:51:26 CET] <Compn> hmmm
[20:51:32 CET] <Compn> https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket1564/Test_DV_Audio.avi
[20:51:34 CET] <cone-102> ffmpeg 03Andreas Cadhalpun 07master:b46aae093634: build: use a link instead of changing current directory when compiling
[21:08:36 CET] <durandal_1707> Compn: where is the ulead decoder in mplayer?
[21:26:58 CET] <Compn> durandal_1707 : binary codec
[21:27:06 CET] <Compn> you mean where is the dll file ?
[21:28:04 CET] <Compn> http://samples.ffmpeg.org/drivers32/newcodecpack/DVACM.acm
[21:28:18 CET] <durandal_1707> vlc have decoder but its gpl
[21:28:52 CET] <Compn> right there is "libdv"
[21:29:01 CET] <durandal_1707> I think guy that wrote it is no longer alive
[21:29:19 CET] <Compn> forever gpl. :p
[21:45:22 CET] <durandal_1707> Compn: miracle, it is relicensed to lgpl
[21:48:27 CET] <wm4> so fast?
[21:59:02 CET] <durandal_1707> I was looking initial version
[21:59:50 CET] <durandal_1707> vlc likes to not give decoders to us, so I will steal from them
[22:02:25 CET] <wm4> don't let j-b know
[22:15:04 CET] <j-b> durandal_1707: what VLC decoder is GPL?
[22:32:56 CET] <durandal_1707> j-b: it was, ulead dv audio
[22:34:15 CET] <nevcairiel> that code looks like it was ripped out of the dv demuxer on a cursory look
[22:34:25 CET] <Compn> what is dvaudio decoder? just libdv ?
[22:34:32 CET] <j-b> durandal_1707: this is LGPL since a long time.
[22:34:43 CET] <nevcairiel> Compn: dvaudio is just jumbled up pcm, no reason to use a library
[22:34:44 CET] <durandal_1707> ubitux: when you gonna comment streamselect
[22:34:52 CET] <j-b> durandal_1707: and it's tless than 120 LoC
[22:35:00 CET] <Compn> nevcairiel : i mean "dvaudio" in libavcodec is listed twice..
[22:35:08 CET] <cone-102> ffmpeg 03Marton Balint 07master:fe4a2cbd4d22: lavc/libzvbi-teletextdec: use the built-in transparent color for transparent background
[22:35:10 CET] <cone-102> ffmpeg 03Marton Balint 07master:92f2a9dbc501: lavc/libzvbi-teletextdec: remove cmax variable
[22:35:11 CET] <cone-102> ffmpeg 03Marton Balint 07master:73e4565dff92: lavc/libzvbi-teletextdec: add support for setting background opacity
[23:09:42 CET] <ubitux> durandal_1707: oh damn i'm sorry i forgot
[23:09:46 CET] <ubitux> give me an hour
[23:10:46 CET] <durandal_1707> no hurry
[23:44:05 CET] <ubitux> durandal_1707: segfault if !map 
[23:44:37 CET] <ubitux> assert if map is empty
[23:46:56 CET] <durandal_1707> default could be set to something
[23:48:46 CET] <ubitux> so i'm trying stuff like ./ffmpeg_g -re -f lavfi -i testsrc2 -ss 30 -re -f lavfi -i testsrc -lavfi "[0][1] streamselect=2:map=1" -f xv - and using 'c' to enter stuff like "all -1 map 0" and it seems to work fine 
[23:49:00 CET] <ubitux> i would love some examples in the documentation though
[23:50:01 CET] <ubitux> if i use:
[23:50:03 CET] <ubitux> ./ffmpeg_g -re -f lavfi -i testsrc2 -ss 30 -re -f lavfi -i testsrc=s=hd720 -lavfi "[0][1] streamselect=2:map=1" -f xv -
[23:50:09 CET] <ubitux> i get glitchy outputs 
[23:50:12 CET] <ubitux> (mismatching dimensions)
[23:51:56 CET] <ubitux> if you set an invalid map value, the filter is in a freezed state apparently
[23:52:45 CET] <ubitux> so 5 things, sigsegv if !map, abort if empty map, examples in documentation, glitches if mismatching resolution, and broken state with invalid map commands
[23:52:59 CET] <ubitux> do you want me to post these on the ml?
[23:53:05 CET] <ubitux> durandal_1707 ^
[23:58:44 CET] <durandal_1707> ubitux: itsnot glitchy, using lavf to test this is wrong
[23:59:03 CET] <ubitux> ah, ok
[00:00:00 CET] --- Tue Jan 26 2016