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

[burek]

[00:03:17 CEST] <Compn> BBB : just make an alias for -ab to -b:a
[00:03:30 CEST] <Compn> we make these kinds of aliases all day long to keep user scripts working
[00:03:31 CEST] <Compn> no big deal
[00:03:35 CEST] <BBB> Compn: alias?
[00:03:37 CEST] <Compn> mask
[00:03:40 CEST] <Compn> whatever its called
[00:03:41 CEST] <BBB> mask?
[00:03:57 CEST] <BBB> Compn: sorry, Im going to sound very stupid here
[00:04:03 CEST] <BBB> but I know tons of stuff about codecs
[00:04:07 CEST] <BBB> but ffmpeg.c is black magic to me
[00:04:21 CEST] <BBB> ffmpeg_*.c also
[00:04:41 CEST] <Compn> ah, we have killed old options before, we just reuse the old option name and map it to the new option name
[00:05:03 CEST] <Compn> i can probably find a commit if you want to see how its done before
[00:05:13 CEST] <BBB> that sounds lovely
[00:05:14 CEST] <BBB> ty
[00:08:27 CEST] <ubitux> BBB: Compn is refering to opt_old2new()
[00:08:31 CEST] <ubitux> in ffmpeg_opt.c
[00:08:36 CEST] <BBB> aha
[00:08:39 CEST] <BBB> ok, Ill have a look
[00:08:52 CEST] <BBB> does that also work for the avfilter syntax changes?
[00:08:56 CEST] <BBB> (: -> |)
[00:09:32 CEST] <ubitux> it justs maps ffmpeg option like -absf to -bsf:a
[00:09:36 CEST] <ubitux> for compatiblity
[00:09:45 CEST] <ubitux> it's a 5 lines function
[00:10:52 CEST] <cone-889> ffmpeg 03Ronald S. Bultje 07master:cdbd3b1e7d0d: fate: move -flags +mv0 -> -mpv_flags +mv0.
[00:11:14 CEST] <ubitux> BBB: and yeah, these are subtitles; it's just ass, but you have to keep in mind that each "time tick" is basically a shit load of markup which are generated with some kind of lua scripting 
[00:11:29 CEST] <BBB> creepy
[00:11:39 CEST] <BBB> Im just going to assume subtitles are from some alien world
[00:11:42 CEST] <ubitux> which you can find in "comments" in ass; aegisub uses them as templates
[00:11:46 CEST] <BBB> video codecs are much easier
[00:11:51 CEST] <ubitux> yeah...
[00:12:02 CEST] <wm4> they're also more efficient
[00:12:03 CEST] <ubitux> let's say codecs are way more structured
[00:12:04 CEST] <wm4> much more
[00:12:15 CEST] <Compn> ubitux : thanks , i was googling and was not finding that :\
[00:12:25 CEST] <wm4> to the point there are performance problems playing "subtitles", while the high bitrate 10 bit h264 doesn't make a dent on the CPU
[00:12:35 CEST] <ubitux> problem with subtitles is that we are giving weapons to monkeys
[00:12:57 CEST] <ubitux> and they love to abuse them, obviously
[00:13:07 CEST] <ubitux> still, it's funny to watch
[00:13:18 CEST] <cone-889> ffmpeg 03Ronald S. Bultje 07master:61043777d747: fate: explicitly specify audio bitrate for adpcm/mp2fixed tests.
[00:13:23 CEST] <ubitux> i personally really enjoy when i see such karaoke madness in animes
[00:13:29 CEST] <ubitux> (not that common anymore unfortunately)
[00:13:44 CEST] <wm4> "unfortunately"
[00:13:59 CEST] <ubitux> well, maybe i'm just watching different kind of animes nowadays
[00:14:30 CEST] <ubitux> wm4: i love when i see ASS nicely exploited
[00:15:01 CEST] <ubitux> i generally notice them when it puts my war machine on its knees
[00:15:20 CEST] <ubitux> it's crazy that a computer won't have troubles decoding 4k in any insane codecs
[00:15:21 CEST] <wm4> "war machine"?
[00:15:27 CEST] <ubitux> but can't handle text
[00:15:36 CEST] <ubitux> yeah well, powerful computer if you prefer
[00:15:36 CEST] <wm4> well that's just ASS being shit
[00:15:43 CEST] <ubitux> dunno
[00:15:49 CEST] <j-b> it's a bad format.
[00:15:51 CEST] <wm4> I got a new computer, I need to test that 80MB subtitle script
[00:15:55 CEST] <ubitux> font handling is some crazy shit man
[00:16:02 CEST] <ubitux> haha
[00:16:12 CEST] <wm4> still not realtime
[00:16:16 CEST] <wm4> drops frames like crazy
[00:16:19 CEST] <ubitux> j-b: it's by far the best out there
[00:16:37 CEST] <wm4> I don't know how old this file is, but the file date says 2012
[00:16:38 CEST] <BBB> font handling is shit indeed
[00:16:45 CEST] <wm4> and this is a skylake cpu
[00:16:47 CEST] <BBB> I did some playing around with gl stuff
[00:16:54 CEST] <wm4> (ok skylake is shit, but you get the idea)
[00:17:17 CEST] <BBB> overlays for mvs, no issue
[00:17:23 CEST] <ubitux> wm4: yeah well, i suppose it was meant to be hardsubbed anyway
[00:17:25 CEST] <BBB> as soon as you do text overlays, *poof*, it all dies
[00:17:31 CEST] <BBB> (performance-wise)
[00:18:08 CEST] <ubitux> shaping, kerning, aliasing
[00:18:22 CEST] <ubitux> hey btw, aren't they introducing some kind of freaky turing machines in font now?
[00:18:30 CEST] <wm4> uh you're late
[00:18:38 CEST] <ubitux> no i mean, new gen
[00:18:44 CEST] <ubitux> where did i see that
[00:18:44 CEST] <wm4> truetype bytecode is how old, 30 years?
[00:19:00 CEST] <ubitux> yeah but now more advanced
[00:19:18 CEST] <ubitux> ah yeah
[00:19:20 CEST] <ubitux> http://blogs.windows.com/bloggingwindows/2015/02/23/windows-shapes-the-worlds-languages/
[00:19:22 CEST] <ubitux> this
[00:19:27 CEST] <wm4> I know they're putting colors and pngs in fonts now
[00:19:43 CEST] <ubitux> yeah, to fix racist emojis
[00:20:06 CEST] <ubitux> anyway, harfbuzz implemented that universal shaping engine in 1.0.0
[00:20:28 CEST] <wm4> this shaping stuff is a good thing
[00:20:36 CEST] <wm4> it actually simplifies software
[00:20:40 CEST] <wm4> or so I heard
[00:20:47 CEST] <wm4> while before, everything had to be hardcoded
[00:21:02 CEST] <wm4> just don't run your font code in an OS kernel
[00:21:27 CEST] <Compn> so is google going to fix this stagefright bug or what
[00:21:35 CEST] <Compn> also, windows caring about security? hahaha
[00:21:42 CEST] <Compn> er s/windows/microsoft
[00:21:58 CEST] <rcombs> Compn: they did
[00:22:03 CEST] <rcombs> a while ago
[00:22:12 CEST] <rcombs> but phone vendors aren't updating
[00:25:22 CEST] <BBB> ubitux: can you check that patch?
[00:25:25 CEST] <BBB> I hope its correct
[00:25:28 CEST] <BBB> but no idea for sure
[00:25:34 CEST] Action: BBB goes home, also
[00:25:35 CEST] <BBB> bbl
[00:25:45 CEST] <ubitux> which one?
[00:25:49 CEST] <ubitux> meh
[00:28:17 CEST] <rcombs> that one!
[00:30:41 CEST] <jamrial> ubitux: the one he sent one minute before he left i assume :p
[01:13:33 CEST] <rcombs> "it'd be neat for the mailing list to have a submission mechanism other than SMTP, and maybe have a nicer thread-based web viewer and& crap, I've invented forums"
[01:15:19 CEST] <Compn> or gmane and its nntp ;p
[01:15:22 CEST] <Compn> if it still has nntp
[01:15:25 CEST] <wm4> forums have nice thread-based views?
[01:16:09 CEST] <cone-889> ffmpeg 03Ronald S. Bultje 07master:a27c9f61bf69: fate: add -fflags +bitexact in a few places.
[01:26:51 CEST] <llogan> rcombs: who said that?
[01:27:56 CEST] <rcombs> me
[01:27:57 CEST] <rcombs> just now
[01:28:22 CEST] <atomnuker> I think gnu mailman 3.0 has some fancy interface, but good luck convincing people to upgrade
[01:29:10 CEST] <llogan> migrating mailman was annoying enough
[01:29:45 CEST] <atomnuker> https://lists.stg.fedoraproject.org/archives/
[01:29:59 CEST] <atomnuker> why did they feel they needed to add like/dislike buttons? just why
[01:30:04 CEST] <Plorkyeran> obv you should use the D forum software
[01:30:17 CEST] <Plorkyeran> can use it as a forum, mailing list, or nntp
[01:31:04 CEST] <llogan> the forum can have one person who answers who doesn't know shit.
[01:31:45 CEST] <wm4> Plorkyeran: I hope that isn't serious
[01:31:54 CEST] <wm4> I used to have the pleasure to use this POS
[01:32:14 CEST] <wm4> atomnuker: mailing lists are social networks
[01:32:19 CEST] <wm4> just like IRC
[01:32:55 CEST] <llogan> mailing lists also act as a filter to (sometimes) keep out the stupidest of people
[01:33:51 CEST] <llogan> it also traps stupid people into receiving ML messages forever because they can't figure out how to unsubscribe
[01:34:23 CEST] <wm4> it's a barrier of entry, both in good and bad ways
[01:37:03 CEST] <cone-889> ffmpeg 03Pedro Arthur 07master:e0a3173a94f2: swscale: refactor horizontal scaling
[01:37:04 CEST] <cone-889> ffmpeg 03Pedro Arthur 07master:737aa902f069: swscale: process horizontal lines in batches
[01:42:21 CEST] <Plorkyeran> it's easy to unsubscribe: you hit the mark as spam button in gmail
[01:43:55 CEST] <kierank> oh god swscale patches
[01:45:20 CEST] <kierank> mind you much more readable
[01:59:28 CEST] <BBB> they are?
[01:59:30 CEST] <BBB> thats good!
[02:03:20 CEST] <kierank> the swscale pipeline is much more unclear
[02:03:25 CEST] <kierank> but the code is at least readable
[02:05:38 CEST] <BBB> so youre happy?
[02:05:39 CEST] <BBB> or not?
[02:14:28 CEST] <kierank> dunno
[02:32:41 CEST] <michaelni> BBB i think your av_dlog patch missed 2 in ftp.c, unless my local tree is messed up
[02:32:51 CEST] <BBB> michaelni: yes, I just rebased
[02:32:53 CEST] <BBB> and one was gone
[02:33:02 CEST] <BBB> Im removing that patch and replacing it with one that uses ff_dlog
[02:33:05 CEST] <BBB> so ignore it for now
[02:33:11 CEST] <michaelni> ko
[02:33:12 CEST] <michaelni> ok
[02:33:25 CEST] <BBB> wm4: will you be at vdd?
[02:46:35 CEST] <BBB> michaelni: done
[02:47:17 CEST] <BBB> does anyone understand how removal of -flags +bitexact forwarding to -fflags +bitexact could break rtp hinting in mov?
[02:47:41 CEST] <BBB> (thats my last outstanding issue for FF_API_LAVF_BITEXACT)
[03:16:00 CEST] <llogan> michaelni: you beat me to the kernel again...was wondering why it didn't respond at the Y/N prompt.
[03:16:53 CEST] <llogan> oh, duh, nevermind. i just assumed that's what happened.
[03:18:51 CEST] <michaelni> llogan, i didnt update yet, i assume you are updating the boxes ?
[03:19:28 CEST] <llogan> just ffbox0.
[03:21:02 CEST] <llogan> i don't have access to trac machine
[03:22:20 CEST] <llogan> anyway, ffbox0 is up-to-date.
[04:00:59 CEST] <michaelni> llogan, ive added your key, you should be able to login
[04:01:06 CEST] <michaelni> to trac box
[04:21:13 CEST] <llogan> michaelni: thanks
[06:12:29 CEST] <philipl> BtbN: so did __gb__ rescue you? sounded nasty
[08:46:31 CEST] <ubitux> > modern codecs (eg. h264) are ...
[08:46:35 CEST] <ubitux> wait, what
[09:01:33 CEST] <cone-467> ffmpeg 03Martin Storsjö 07master:26ac22e5e739: movenc: Add a new flag for writing global sidx indexes for dash
[09:01:33 CEST] <cone-467> ffmpeg 03Hendrik Leppkes 07master:1907e19d0ce2: Merge commit '26ac22e5e7394346e9d59f800e7d4e91f4518d33'
[09:01:53 CEST] <cone-467> ffmpeg 03Henrik Gramner 07master:44b444412031: x86inc: Various minor backports from x264
[09:01:54 CEST] <cone-467> ffmpeg 03Hendrik Leppkes 07master:9c22aedd265e: Merge commit '44b44441203177690305c294be6eff8d9c668954'
[09:02:10 CEST] <cone-467> ffmpeg 03Martin Storsjö 07master:cb2dbe2c762d: configure: arm: Assume softfp ABI on darwin
[09:02:11 CEST] <cone-467> ffmpeg 03Hendrik Leppkes 07master:fdca9350139b: Merge commit 'cb2dbe2c762dae44d890aa26620bcdd9022fd0f3'
[09:02:24 CEST] <cone-467> ffmpeg 03Martin Storsjö 07master:87de6ddb7b76: libfdk-aacdec: Bump the max number of channels to 8
[09:02:25 CEST] <cone-467> ffmpeg 03Hendrik Leppkes 07master:9dc30d081140: Merge commit '87de6ddb7b7674e329d5c96677bd8685bc7f7855'
[09:09:41 CEST] <cone-467> ffmpeg 03Martin Storsjö 07master:1b90433f79de: libfdk-aacdec: Always decode into an intermediate buffer
[09:09:42 CEST] <cone-467> ffmpeg 03Hendrik Leppkes 07master:4cf4831ae7e2: Merge commit '1b90433f79de857550d4d8c35c89fbe954920594'
[09:10:03 CEST] <cone-467> ffmpeg 03Martin Storsjö 07master:f34b152eb7b7: libfdk-aacdec: Clean up properly if the init fails
[09:10:04 CEST] <cone-467> ffmpeg 03Hendrik Leppkes 07master:e721cb8d8b5c: Merge commit 'f34b152eb7b7e8d2aee57c710a072cf74173fbe1'
[09:16:23 CEST] <cone-467> ffmpeg 03Federico Tomassetti 07master:7bf964726430: vp7: bound checking in vp7_decode_frame_header
[09:16:24 CEST] <cone-467> ffmpeg 03Hendrik Leppkes 07master:983fa5a1a922: Merge commit '7bf9647264308d2df74b2b50669f2d02a7ecc90b'
[09:23:59 CEST] <cone-467> ffmpeg 03Luca Barbato 07master:72839fce6457: hlsenc: Use AV_TIME_BASE units for all the computations
[09:24:00 CEST] <cone-467> ffmpeg 03Hendrik Leppkes 07master:316825f3e9d5: Merge commit '72839fce6457fdb5d51b4a5381ac52914ee66389'
[09:35:48 CEST] <cone-467> ffmpeg 03Alexandra Hájková 07master:58c3720a3cc7: fate: Make sure a corner-case for ASF is covered
[09:35:49 CEST] <cone-467> ffmpeg 03Hendrik Leppkes 07master:4b6ccccb03ba: Merge commit '58c3720a3cc71142b5d48d8ccdc9213f9a66cd33'
[09:36:09 CEST] <cone-467> ffmpeg 03Alexandra Hájková 07master:317cfaa5e097: asfdec: prevent the memory leak in the asf_read_metada_obj
[09:36:10 CEST] <cone-467> ffmpeg 03Hendrik Leppkes 07master:649b2e4c8308: Merge commit '317cfaa5e09755ed0b34af512ec687963a67bdbf'
[10:25:42 CEST] <BtbN> philipl, well, gdb did. libva, or rather the intel driver, has no real error reporting except for returning "Invalid Parameter" after you gave it a set of ~200 parameters.
[10:26:01 CEST] <BtbN> So you have to step through there, and see which parameter check returns it.
[10:26:30 CEST] <BtbN> And i learned that gdb reverse debugging is not reliable aparently
[10:26:59 CEST] <BtbN> my idea was to just set a breakpoint on vaEndPicture, and then step backwards, which should bring me right to the failing check
[10:27:46 CEST] <BtbN> But it ended up with an entirely impossible backtrace that caused confusion
[10:28:25 CEST] <BtbN> So now i'm slowly working my way through everything it complains about.
[10:29:10 CEST] <BtbN> It seems to successfully decode I frames though. The reference handling is still broken
[10:50:36 CEST] <__gb__> nevcairiel, people are already required to zero-allocate vaapi_context, so Version would end up to be 0, which is fine. I have also considered renaming the struct, but AVVAAPIContext didn't look quite entertaining to read. If you have suggestions...
[10:50:56 CEST] <__gb__> besides, I anticipate that the version field is read only once when we initialize the internal (real) context
[10:51:10 CEST] <__gb__> well, at a single location
[10:58:00 CEST] <BtbN> Does any other struct in ffmpeg use a version field? Isn't it usualy just "provide an allocation function and add new fields at the end"?
[11:02:28 CEST] <__gb__> afaik, no, but if we want to ever be compatible in every weird combination, I believe this is the proper way
[11:03:14 CEST] <__gb__> oh well, maybe renaming to vaapi_config is more appealing after all
[11:03:38 CEST] <__gb__> since, at the end of the day, that would just hold some lavc/vaapi config options
[11:06:13 CEST] <__gb__> still, ABI can be broken even if we "add new fields at the end"
[11:08:06 CEST] <BtbN> Only if applications manualy allocate the struct
[11:13:36 CEST] <__gb__> how do you prevent him from manually allocating the struct, while preserving existing usage?
[11:19:09 CEST] <BtbN> The classic approach to that is to hide the fields, so the size is unknown.
[11:19:19 CEST] <BtbN> Fields are then only accessible through functions
[11:20:33 CEST] <BtbN> But i don't think there is a clean way to transition to that
[11:21:07 CEST] <__gb__> that's also my concern, and why I introduced that Version field :)
[11:21:39 CEST] <__gb__> thinking further, I believe it's reasonable to start introducing AVOptions until "hwaccel v2" ever happens
[11:21:53 CEST] <__gb__> but AVOptions tied to vaapi only atm
[11:22:07 CEST] <__gb__> e.g. av_init_context(flags, AVDict *)
[11:22:58 CEST] <__gb__> but we still need a way to identify old vs. new vaapi_context, or at least still support older vaapi_context allocated into hwaccel_context
[11:32:19 CEST] <nevcairiel> just stop supporting manual allocations, problem solved :d
[11:33:18 CEST] <__gb__> until I receive tons of angry e-mails saying why my favorite video player no longer works? :)
[11:33:37 CEST] <rcombs> fuck 'em
[11:33:38 CEST] <__gb__> I have just thought about an obscene way to coerce this:
[11:33:41 CEST] <nevcairiel> tell them to complain to the developers of that player, its a one line change to fix that
[11:33:42 CEST] <rcombs> rule #1 of software
[11:33:43 CEST] <rcombs> fuck 'em
[11:34:12 CEST] <wm4> __gb__: sent a reply on the ML
[11:34:38 CEST] <__gb__> 1. have av_vaapi_context_alloc() return a pointer OR'ed with 1
[11:35:14 CEST] <__gb__> this serves as a way to identify the struct was lavc allocated, and ensure the user goes to hell if he doesn't configure the struct through the supplied helper function
[11:35:46 CEST] <wm4> then you may as well use a completely different struct
[11:35:51 CEST] <wm4> (and keep it opaque)
[11:36:01 CEST] <rcombs> rule #2 of software
[11:36:04 CEST] <rcombs> make all structs opaque
[11:36:21 CEST] <wm4> I never liked AVcodecContext.hwaccel_context anyway
[11:36:23 CEST] <__gb__> but I still want to support old usages, whereby older vaapi_context can still be provided to hwaccel_context...
[11:36:27 CEST] <wm4> it has such confusing lifetime rules
[11:36:51 CEST] <wm4> __gb__: so distinguish old and new API users by whether hwaccel_context is set
[11:37:05 CEST] <wm4> if that is possible
[11:37:16 CEST] <nevcairiel> inventing yet another way to handle extensible structs that has no precedence in ffmpeg is just not a good way to go
[11:38:19 CEST] <__gb__> wm4, this would require the introduction of an extra hwaccel_config :-/
[11:38:21 CEST] <nevcairiel> we have slowly moved away from all sorts of user-allocated structs, and given a decent deprecation period, this should just follow
[11:38:58 CEST] <__gb__> oh, well, maybe just time to get people accept AVOptions then :)
[11:39:57 CEST] <__gb__> at least luca & I agreed on the benefits of that but iirc courmisch objected for type safetyness
[11:42:09 CEST] <wm4> __gb__: hm yes, I guess there's no simple way
[11:42:39 CEST] <nevcairiel> i really dont like avoptions for pointers, but i dont know if you need any
[11:42:42 CEST] <wm4> I think vdpau got away by actually requiring av_vdpau_alloc_context for everything and waiting for a deprecation period
[11:43:07 CEST] <wm4> nevcairiel: you can just add accessors for those
[11:43:28 CEST] <wm4> also I'm confused why vdpau has AVVDPAUContext and VDPAUHWContext
[11:43:47 CEST] <__gb__> nevcairiel, I'd only need one for the VADisplay, but I guess I could live with an extra function
[11:43:48 CEST] <wm4> and vdpau_picture_context
[11:43:59 CEST] <__gb__> I don't really want multiple accessors either...
[11:44:22 CEST] <__gb__> but I think I could live with AVOptions + some av_vaapi_context_set_display() for the pointer thing
[11:46:26 CEST] <wm4> __gb__: I'd say just go with a completely internal context for the new API
[11:46:32 CEST] <BtbN> Could also do something like keeping a list of all lavc-allocated hwaccel contexts. And when the one given to hwaccel_context is not in said list, assume it's a user allocated old-style struct, and convert it to the new, opaque one.
[11:46:38 CEST] <wm4> and emulate the old API, which sets hwaccel_context
[11:47:27 CEST] <BtbN> As there isn't usualy a lot of those contexts, this wouldn't be much overhead.
[11:48:23 CEST] <__gb__> nevcairiel, wm4: what do you think of my "obscene way to coerce people"? at least, we can: (i) keep vaapi_context name as is, (ii) identify old/new vaapi_context, new vaapi_context would only have additional flags + AVOptions, (iii) great benefit to have user forced to use the very few accessors
[11:49:35 CEST] <__gb__> wm4, yes, I only use the internal context (FFVAContext) now, but I need some extra configuration options and handle (VADisplay)
[11:50:05 CEST] <wm4> __gb__: so the init function could have a VADisplay argument, and maybe an AVDictionary (for avoptions)
[11:50:34 CEST] <wm4> I'm not quite sure what you mean by your "obscene way to coerce people", but as long as it doesn't crash old programs, it's potentially fine
[11:51:17 CEST] <__gb__> it's obscene because program will crash if developer did not bother going through the accessors :)
[11:51:45 CEST] <wm4> if we make the context really internal, and leave hwaccel_context to NULL, the user won't even get a chance
[11:51:48 CEST] <wm4> (stupid API user!)
[11:53:59 CEST] <__gb__> imho, this is not possible because hwaccel_priv_data is allocated later after user get_format() is called
[11:54:59 CEST] <wm4> oh I see utils.c messes with this
[11:55:00 CEST] <__gb__> when/how do you communicate or instruct initialization of the internal context then?
[11:55:05 CEST] <__gb__> yes
[11:55:05 CEST] <wm4> you could just add a new (internal) field
[11:55:34 CEST] <__gb__> to the struct? this is not possible unless you have a way to identify public/privately allocated struct :)
[11:55:37 CEST] <wm4> (I think that would be ok, because all the existing hwaccel code is a big mess anyway)
[11:56:23 CEST] <wm4> my thinking is: av_vaapi_context_alloc() would set a new AVCodecContext.internal.hwaccel_context field
[11:56:31 CEST] <__gb__> well, I believe this is not so messy as the newer ff_get_format() / setup_hwaccel() bits have a chance to handle fallbacks to SW decode now
[11:56:45 CEST] <wm4> and then the vaapi code can distinguish between new and old API user by whether this field is set, or by a flag set in this context
[11:57:50 CEST] <__gb__> hwaccel_priv_data would be reset in setup_hwaccel() as it only cares to check wether the hwaccel codec has non-zero priv_data_size :)
[11:59:47 CEST] <__gb__> but we could handle this gracefully, without the need to check all existing hwaccels, by adding a new HWACCEL_CODEC_CAP_xxx and checking for it in setup_hwaccel()
[12:00:37 CEST] <__gb__> doable, but I didn't initially want to pollute the existing HWACCEL_CODEC_CAPs
[12:00:45 CEST] <wm4> or just don't use hwaccel_priv_data, or do we have to?
[12:01:48 CEST] <__gb__> .init(), .uninit(), .priv_data_size are existing and convenient to use already, looking for some other infrastructure to initialize the hwaccel codec is not very pretty...
[12:03:43 CEST] <iive> just use hwaccel pixel formats and get_format
[12:58:28 CEST] <cone-467> ffmpeg 03Arttu Ylä-Outinen 07master:b807f7e28664: configure: Use pkg-config for libkvazaar.
[14:20:15 CEST] <__gb__> nevcairiel, wm4: new suggestion: don't change anything, just (i) add a new private AVCodecInternal.hwaccel_config field; (ii) populate it with a single public av_vaapi_set_config() / av_vaapi_set_config_int() ; then AVHWAccel.init() can gracefully populate its own private FFVAContext fields through av_opt_set_dict(). WDYT?
[14:20:28 CEST] <__gb__> + mark everything in vaapi_context as deprecated, except the VADisplay
[14:21:01 CEST] <__gb__> that way, the transition path to an hypothetical hwaccel v2 is even simpler
[14:21:24 CEST] <wm4> sounds kind of ok
[14:21:48 CEST] <wm4> I'd get rid of vaapi_context completely, at least from an API point of view (even if it's still used internally for a while)
[14:21:55 CEST] <nevcairiel> didnt we have an internal context storage for hwaccels somewhere already
[14:21:58 CEST] <__gb__> this means, no get possible -- but we don't care, if the user sets some values, we can expect that he can remember about it later...
[14:22:54 CEST] <__gb__> wm4, I can't get rid of the vaapi_context completely, I'd need to communicate the VADisplay (pointer) as a pointer, and we haven't reached consensus yet for that on options :)
[14:23:05 CEST] <wm4> e can expect that he can remember about it later... <- at least for something as static as the decoder context, sure
[14:23:27 CEST] <wm4> __gb__: couldn't it be passed via av_vaapi_set_config()?
[14:23:30 CEST] <wm4> or similar
[14:23:50 CEST] <nevcairiel> avctx->internal->hwaccel_priv_data? whats with that? no need to use a new one? :)
[14:24:21 CEST] <BtbN> There is also one that's per-frame.
[14:24:22 CEST] <__gb__> the suggested av_vaapi_set_config() would populate an internal hwaccel_config, which is an AVDict
[14:24:22 CEST] <wm4> it's deallocated on reinit I think
[14:24:51 CEST] <__gb__> I don't mind populating AVDict with random pointers but others object to that approach, so we need to find something else
[14:24:52 CEST] <wm4> __gb__: I see... does it have to be an AVDict?
[14:25:21 CEST] <__gb__> if you want hwaccel_config to be fine-tuned per hwaccel, then we have chances to increase messery
[14:25:40 CEST] <__gb__> i.e. you'd need another hook for hwaccel_config init/deinit/ and such :)
[14:26:00 CEST] <__gb__> sticking to AVDict looks simple enough to me and not too intrusive
[14:26:59 CEST] <__gb__> nevcairiel, avctx->internal->hwaccel_priv_data is forcibly initialized in setup_hwaccel()
[14:27:55 CEST] <__gb__> alternative, proposed previously, was to add yet another HWACCEL_CAP flag to be checked thus telling to not deallocate a prior allocation of hwacccel_priv_data
[14:28:52 CEST] <wm4> or add another pointer field
[14:29:55 CEST] <__gb__> yes, and that pointer field can actually be the options/dict hence this new suggestion :)
[14:30:26 CEST] <__gb__> I mean, while we are at adding a new pointer field, let's make it actually useful with little extra effort
[14:31:08 CEST] <__gb__> e.g. av_dict_free() exists already, etc. no need to add other hooks
[14:31:35 CEST] <wm4> I mean I was suggesting adding another field like hwaccel_priv_data, which the vaapi code would manage
[14:31:56 CEST] <wm4> also, note that in theory it's allowed to change the hwaccel method mid-stream
[14:32:17 CEST] <wm4> which is probably why the context is deallocated in the first place
[14:33:17 CEST] <__gb__> this is not an issue in the second proposed model (with AVDict)
[14:34:22 CEST] <__gb__> now, regarding to another field like hwaccel_priv_data but only useful to vaapi, well, this not good either
[14:34:53 CEST] <__gb__> FFVAContext perfectly fits hwaccel_priv_data
[14:35:08 CEST] <__gb__> no need for extra specific-ness for vaapi
[14:35:25 CEST] <__gb__> and the hwaccel_config can actually be useful to others, imho
[14:35:37 CEST] <wm4> then what was this about the HWACCEL_CAP flag?
[14:36:18 CEST] <__gb__> that's the first model so that to avoid setup_hwaccel() to av_mallocz() the hwaccel_priv_data itself
[14:36:26 CEST] <__gb__> in the second model (avdict), I don't need that
[15:02:09 CEST] <__gb__> on further thought, IMHO, type safetyness is a non issue here imho as we know that when an hwaccel is active, the hwaccel_config options are bound to be specific to that specific hwaccel, i.e. hwaccel_config is not public
[15:02:35 CEST] <__gb__> so having an av_vaapi_set_display() looks perfectly fine to me, no matter we internally store it in the hwaccel_config dict or not
[15:02:41 CEST] <__gb__> that's internal sauce
[15:04:27 CEST] <__gb__> nevcairiel, would you accept that now? i.e. av_vaapi_set_config() / av_vaapi_set_config_int() + av_vaapi_set_display() that internally populates the avdict, no extra change needed but deprecation of vaapi_context
[15:05:05 CEST] Action: __gb__ will cook a patch to demonstrate this
[15:22:40 CEST] <ubitux> michaelni: you need to force the dependency from scale filter to scale2ref filter
[15:22:42 CEST] <ubitux> afaict..
[15:47:42 CEST] <cone-467> ffmpeg 03Ronald S. Bultje 07master:70a19c482a62: Move ff_dlog from lavc to lavu.
[15:50:54 CEST] <BBB> I have 20 patches outstanding that dont have an explicit ok or rely on other patches, anyone want to review a couple? https://github.com/rbultje/ffmpeg/commits/api
[16:08:57 CEST] <cone-467> ffmpeg 03Michael Niedermayer 07master:db0f8f3f9d9f: avfilter/vf_scale: Set scale2ref ref output timebase
[16:08:57 CEST] <cone-467> ffmpeg 03Michael Niedermayer 07master:22f85543ed92: scale2ref: override request_frame() and correctly connect them to the corresponding inputs
[16:19:02 CEST] <cone-467> ffmpeg 03Ronald S. Bultje 07master:ad7d972e08dd: lavfi: add error message to help users convert to new lavfi syntax.
[16:47:35 CEST] <kvz> michaelni: Is there still discussion about my hosting proposal? Haven't heard back. We're rolling out something similar now for ImageMagick and tus. Thought maybe this illustrates better what my proposal is about: https://github.com/tus/tusd/blob/master/INFRA.md. We could set this up in a private repo and invite everyone involved as admin, to play around with it, and make a final decision.
[16:47:43 CEST] <cone-467> ffmpeg 03Ronald S. Bultje 07master:229843aa359a: Replace av_dlog with ff_dlog.
[17:08:14 CEST] <BBB> whats the diff between idr and keyframe? is this the can a following frame use previous frames as reference"?
[17:08:23 CEST] <nevcairiel> yes
[17:08:30 CEST] <BBB> and which is which? :)
[17:08:38 CEST] <nevcairiel> idr is a complete reset
[17:08:51 CEST] <nevcairiel> no previous refs afterwards
[17:09:17 CEST] <BBB> (so the case for non-idr is obvious, it allows seeking but gives slightly better compression)
[17:09:27 CEST] <BBB> I just had to get my wording right :-p
[17:09:29 CEST] <nevcairiel> how does it allow seeking
[17:09:40 CEST] <BBB> its an encoder choice
[17:09:40 CEST] <nevcairiel> i cant seek to a normal I frame, it would still distort
[17:09:56 CEST] <BBB> imagine display order of PBBIBBP
[17:10:19 CEST] <BBB> coding order may be IPBBPBB or whatever
[17:10:25 CEST] <BBB> (can get complicated)
[17:10:31 CEST] <BBB> the I and second PBB can still be decoded
[17:10:33 CEST] <BBB> just not the first
[17:11:05 CEST] <nevcairiel> not necessarily, h264 can reference a whole lot of things
[17:11:07 CEST] <BBB> its an encoder choice to discard the frames before the I at encoding of second BBP input set
[17:11:10 CEST] <BBB> I know it can
[17:11:15 CEST] <BBB> but this is an encoder choice
[17:11:24 CEST] <BBB> if I want to allow seeking, I tell my encoder to stop fucking up
[17:11:28 CEST] <BBB> and it does
[17:11:32 CEST] <BBB> and everyone is happy
[17:11:39 CEST] <michaelni> ubitux  "./configure --disable-filters --enable-filter=scale2ref" works, so i dont know what to fix
[17:11:40 CEST] <nevcairiel> but whats the point of forcing normal I frames, they dont allow seeking or cutting
[17:11:51 CEST] <kierank> BBB: you can have keyframes in intra-refresh that are not idr or I
[17:11:55 CEST] <muken> > recovery point sei
[17:12:12 CEST] <BBB> i frames allow seeking
[17:12:18 CEST] <BBB> just not every frame afterwards is necessarily decodable
[17:12:30 CEST] <nevcairiel> i can seek to a B frame then and claim the same =P
[17:12:33 CEST] <BBB> but if the encoder did it right, the seek will succeed and decoding of any _display_ frame after the i will be correct
[17:12:43 CEST] <BBB> no, because the b frame wont decode correctly
[17:13:00 CEST] <BBB> hevc even has explicit nal unit types to indicate this difference
[17:13:08 CEST] <BBB> so its not like Im making this up
[17:13:09 CEST] <nevcairiel> if i want to ensure seeking to a certain point, ie. a chapter boundary, i need to put a IDR there
[17:13:34 CEST] <nevcairiel> otherwise there can be corruption after a seek
[17:14:06 CEST] <nevcairiel> with 16 possible reference frames, a single I is not going to clear up any following frames
[17:14:35 CEST] <BBB> that depends on the encoder
[17:14:41 CEST] <BBB> this is the whole point of radl
[17:14:47 CEST] <nevcairiel> if it does, its essentially a IDR
[17:15:35 CEST] <BBB> do you consider both n_lp and w_radl idr, or just n_lp?
[17:15:49 CEST] <nevcairiel> hevc is not relevant for this discussion =p
[17:15:50 CEST] <muken> you can seek to I with recovery_frame_cnt==0
[17:16:23 CEST] <BBB> the fact that h264 doesnt explicitly indicate nal types doesnt mean the same isnt possible withh h264 also
[17:17:14 CEST] <muken> though discarding undecodable leading frames depends on decoder :P
[17:18:46 CEST] <BBB> I dont see the issue with seeking to a w_radl point
[17:19:02 CEST] <BBB> (which is basically the non-idr case in the x264 patch)
[17:19:52 CEST] <nevcairiel> does it guarantee perfect reconstruction of any frames in display order afterwards? does the other x264 option really do that?
[17:20:34 CEST] <ubitux> michaelni: ./configure --disable-filters --enable-filter=scale ?
[17:20:57 CEST] <BBB> nevcairiel: yes and yes
[17:21:42 CEST] <BBB> (also, guarantee is an obscure word; in the case of x264, yes, it will work; in the sense that the standard guarantees it, no, I dont think so)
[17:22:20 CEST] <ubitux> michaelni: i'm refering to +AVFilter ff_vf_scale2ref; in libavfilter/vf_scale.c
[17:22:38 CEST] <ubitux> it looks like some weird dependency
[17:22:52 CEST] <ubitux> ah wait you declare it in the same file, all the time
[17:22:54 CEST] <ubitux> mmh
[17:23:05 CEST] <ubitux> we don't usually do that
[17:31:01 CEST] <BBB> nevcairiel: will you be at vdd?
[17:31:12 CEST] <BBB> nevcairiel: I can explain the use case for this and the quality implications on a whiteboard if you want
[17:31:36 CEST] <Daemon404> BBB, that is torture and banned under the geneva convention
[17:31:59 CEST] <BBB> doesnt that apply only under war?
[17:32:07 CEST] <BBB> I believe outside war, we can do whatever we want
[17:32:07 CEST] <Daemon404> i actually dont know
[17:32:35 CEST] <nevcairiel> within the countries laws in any case =p
[17:32:41 CEST] <BBB> or I can set up an ethics committee consisting of psychiatrists that I paid to say for me that this is not torture
[17:32:54 CEST] <BBB> theres legal precedence for that, I hear
[17:33:31 CEST] <nevcairiel> sounds like something the US would do to legalize waterboarding
[17:37:11 CEST] <__gb__> fyi, I have updated https://github.com/gbeauchesne/FFmpeg/tree/11.vaapi.lavc.config and https://github.com/gbeauchesne/ffvademo/commits/staging to reflect what I had in mind with AVDict
[17:37:59 CEST] <__gb__> I think it's in good shape now except maybe the actual names... not much inspired today :)
[17:39:03 CEST] <BBB> nevcairiel: whiteboarding != waterboarding
[17:39:13 CEST] <BBB> nevcairiel: they are similar, remarkably so, but not legally identical
[17:39:17 CEST] <nevcairiel> hehe
[17:39:22 CEST] <prelude2004c> hey everyone.. question maybe more poised at the development team. If i want to create a playout server. HOw do i set ffmpeg so it plays one file after another but without delayed start ? Eg. i don't want to loose frames or 1 second while it gets data from DB and starts to play the next one andwhen finished pull data gaain from DB and play the next one, etc etc.  Is there some way to load the new video before the other is finished bu
[17:39:30 CEST] <nevcairiel> i always feel like drowning either way
[17:41:53 CEST] <BBB> Ill take that as a yes :-p
[17:42:11 CEST] <michaelni> ubitux, "./configure --disable-filters --enable-filter=scale  && make -j12" <-- works too
[17:42:25 CEST] <nevcairiel> in any case I do not know yet if i'll be at vdd
[17:42:56 CEST] <BBB> oh.. :(
[17:43:06 CEST] <BBB> anyone want to review more patches? https://github.com/rbultje/ffmpeg/commits/api
[17:43:13 CEST] <BBB> FF_OPT_TYPE_* -> AV_OPT_TYPE_*. should be easy
[17:43:25 CEST] <BBB> or options: mark av_get_{int,double,q} as deprecated.
[17:44:04 CEST] <BBB> lavc: fix compilation with FF_API_XVMC. should be easy also
[17:44:45 CEST] <iive> hum?
[17:44:59 CEST] <iive> is there ticket for that?
[17:49:48 CEST] <BBB> iive: ticket for & ?
[17:52:00 CEST] <wm4> re keyframe discussion, aren't ffmpeg "keyframes" more similar to IDRs?
[17:52:18 CEST] <wm4> I mean the term "keyframe" is pretty inprecise in general anyway...
[17:52:39 CEST] <wm4> BBB: re VDD, seems unlikely...
[17:52:56 CEST] <iive> BBB: broken compilation...
[17:53:05 CEST] <BBB> why do people fundamentally object to vdd or meetings?
[17:53:23 CEST] <BBB> iive: why would there be a ticket for that?
[17:56:14 CEST] <wm4> __gb__: to be honest, I'd still prefer an "atomic" init call, which then could also take options of any type, instead of pulling it through avdict and avoption...
[17:57:21 CEST] <__gb__> I thought about varargs but this complexifies things for no real gain imho
[17:57:34 CEST] <wm4> no, varargs are terrible for anything but printf
[17:58:59 CEST] <wm4> is it really necessary for the user to set config/context id? I imagine the new code could do this automatically
[17:59:08 CEST] <muken> wm4: i dislike the keyframe term since keyframe does not guarantee that the frame is seekable or not and it depends on file format
[17:59:22 CEST] <__gb__> wm4, what do you suggest then? a basic (key,value) array?
[17:59:55 CEST] <wm4> __gb__: maybe a va_vaapi_initialize_with_existing_context()? (ok the name is too long)
[17:59:55 CEST] <__gb__> wm4, yes, config/context id are not needed in future patches, but this is currently optional
[18:00:32 CEST] <__gb__> I really need flexible config options to the pipeline :)
[18:00:44 CEST] <wm4> and we still can have an avdict for whatever else there might be, I just find it rather awkward to use it for the display, which is always needed, and is a pointer
[18:01:44 CEST] <__gb__> I don't really see other possible changes that remain non intrusive, flexible, and small
[18:02:29 CEST] <Compn> BBB : iive maintains xvmc stuff,  he is wondering if xvmc is currently broken because your patch "fixes" it...
[18:02:30 CEST] <wm4> are you opposed to having separate av_vaapi_initialize_with_existing_context() and av_vaapi_initialize_automatically() functions?
[18:02:56 CEST] <iive> BBB: your xvmc patch is correct.
[18:03:40 CEST] <__gb__> wm4, no (names to be improved though), but I don't see how to implement that without touching more to the common hwaccel infrastructure
[18:04:07 CEST] <__gb__> I'd like to avoid having to test every possible other hwaccel
[18:04:14 CEST] <wm4> of course
[18:04:18 CEST] <iive> I would speculate that somebody coded these ifdefs with the thought that FF_API_XVMC indicates if XVMC is compiled... not that it list an api change.
[18:04:18 CEST] <BBB> iive: ty, do you want to mail that to the list?
[18:05:07 CEST] <iive> you can commit it right away
[18:05:31 CEST] <BBB> ty
[18:05:55 CEST] <wm4> __gb__: if we go with such functions, the second argument could be VADisplay, the "low level" one could also take config/context ID, and all of them could take an avdictionary parameter... and we _could_ of course use avdictionary for all of them internally
[18:06:07 CEST] <wm4> but I'm not very convinced, because the vdpau code does just fine without it
[18:06:31 CEST] <wm4> vdpau requires the user to call av_vdpau_bind_context() only, and that's it
[18:06:46 CEST] <wm4> (and get_buffer2 needs to be overridden of course)
[18:08:40 CEST] <__gb__> everything is possible but I believe the latest patch series optimizes best under the following constraints: compatibility, little changes to the common hwaccel structure, flexibility for future pipeline options, very little changes needed
[18:08:50 CEST] <__gb__> vdpau allocates hwaccel_context, which we want to avoid
[18:08:51 CEST] <__gb__> too
[18:09:00 CEST] <cone-467> ffmpeg 03Ronald S. Bultje 07master:6471040f5650: FF_OPT_TYPE_* -> AV_OPT_TYPE_*.
[18:09:01 CEST] <cone-467> ffmpeg 03Ronald S. Bultje 07master:b07d2a250955: libvpxenc: make flags i64 instead of dbl.
[18:09:02 CEST] <cone-467> ffmpeg 03Ronald S. Bultje 07master:ad45121d562d: options: mark av_get_{int,double,q} as deprecated.
[18:09:03 CEST] <cone-467> ffmpeg 03Ronald S. Bultje 07master:e3b7298aedd4: lavc: fix compilation with FF_API_XVMC.
[18:09:23 CEST] <wm4> __gb__: the user doesn't need to access hwaccel_context though (except for deallocation, which strikes me as an API bug)
[18:09:39 CEST] <wm4> I mean, the user doesn't need to access hwaccel_context with the new vdpau APU
[18:09:41 CEST] <wm4> *API
[18:10:07 CEST] <wm4> and I believe our idea how it should look like are very similar anyway
[18:10:09 CEST] <__gb__> yes, but as you mention, he further needs to deallocate the hwaccel_context himself
[18:10:19 CEST] <wm4> but that could surely be fixed
[18:11:39 CEST] <__gb__> I will need other config options, and extending vaapi_context is not an option
[18:13:02 CEST] <wm4> muken: what interests me here is what AV_PKT_FLAG_KEY actually means (although I think it's not relevant to what was discussed)
[18:13:17 CEST] <__gb__> going after the vdpau way means we need to further live with vaapi_context, which we don't need
[18:13:38 CEST] <wm4> __gb__: I don't see this, this has nothing to do with any user-visible contexts
[18:14:28 CEST] <wm4> vdpau kept using hwaccel_context mainly for internal compatibility
[18:15:20 CEST] <wm4> for now feel free to go ahead with your latest approach I guess
[18:15:43 CEST] <wm4> but I think putting mandatory parameters in avdicts (as far as the user API is concerned) is pretty ugly
[18:15:52 CEST] <wm4> especially for pointers
[18:16:05 CEST] <__gb__> it's not a pointer, it's a uintptr :)
[18:16:46 CEST] <__gb__> but you are right, there is a bug for 32-bit systems
[18:23:13 CEST] <__gb__> I now see your point, and that you are not fundamentally opposed to using AVDict internally
[18:24:19 CEST] <muken> wm4: AV_PKT_FLAG_KEY means a packet contains at least one complete frame with an indicator which indicates the decoder does output correctly after a specified frame in output order.
[18:24:46 CEST] <__gb__> I guess I can refactor the 3 functions into a single av_vaapi_set_pipeline_config(avctx, VA-display, options);
[18:25:08 CEST] <wm4> __gb__: yep, that looks nicer IMHO
[18:25:39 CEST] <__gb__> and let the old fashioned way to provide VA config/context with the old vaapi_context, and exclusively use av_vaapi_set_pipeline_config() to let lavc allocate the decoder itself
[18:25:58 CEST] <wm4> sounds good
[18:26:00 CEST] <__gb__> at the end of the day, most of the users would only care to provide a VA display anyway
[18:26:18 CEST] <muken> wm4: this definition of cource requires initialization of the decoder
[18:26:20 CEST] <__gb__> ok, I will work on that
[18:26:41 CEST] <wm4> muken: next problem: do all libavformat demuxers actually follow this definition?
[18:27:21 CEST] <muken> wm4: afaik yes. this defintion covers closed gop, open gop and gradual decoder refresh
[18:29:16 CEST] <muken> this definiton does not gurantee that a packet with AV_PKT_FLAG_KEY is a random accessible point
[18:30:04 CEST] <wm4> then I'd imagine that remuxing to mkv is often broken
[18:32:20 CEST] <muken> yes. current libavformat marks IDR without required parameter sets as keyframe. this issue is sometimes exposed on AVC-in-TS
[18:33:42 CEST] <kierank> is that even legal?
[18:33:57 CEST] <muken> kierank: i have a such sample
[18:34:20 CEST] <kierank> muken: ah so the carl approach :)
[18:35:20 CEST] <muken> i found such streams in anime BDs
[18:35:53 CEST] <muken> the spec of avc does not forbid idr without parameter sets
[18:36:05 CEST] <muken> dunno about the bd spec
[18:36:28 CEST] <kierank> mpegts spec i think forbids that
[18:36:39 CEST] <kierank> and I think gary sullivan said it's illegal
[18:38:27 CEST] <kierank> oh wait mp4
[18:38:29 CEST] <kierank> so it is legal
[18:42:39 CEST] <muken> anyway, theoretically such wild implementations could be appeared, regardless of whether it's legal or illegal, we should handle them
[18:45:14 CEST] <kierank> muken: ok carl
[18:45:34 CEST] Action: kierank trolls muken
[18:46:01 CEST] <muken> no more cehoyos
[19:00:12 CEST] <wm4> does libavcodec/utils.c mess with the timestamps output by the decoder?
[19:00:39 CEST] <nevcairiel> isnt that all in avformat
[19:00:44 CEST] <nevcairiel> timestamp messing
[19:01:00 CEST] <wm4> I thought so too, but right now I'm debugging a strange issue I'm running into
[19:03:04 CEST] <wm4> oh
[19:03:17 CEST] <wm4> it overwrites pkt_dts
[19:03:31 CEST] <wm4> it sets it from the AVPacket passed to the decode call
[19:03:36 CEST] <wm4> which is not useful in mmal...
[19:03:48 CEST] <wm4> because the decoder is asynchronous
[19:04:02 CEST] <nevcairiel> pkt_dts can easily get useless depending on the decoder delay and whatnot
[19:04:30 CEST] <wm4> no, it's actually useful to determine the pts
[19:04:42 CEST] <wm4> the frame threading wrapper handles it specially too
[19:05:16 CEST] <nevcairiel> it still assumes the delay is "perfect"
[19:05:31 CEST] <wm4> seems to work well enough for mpeg stuff
[19:05:39 CEST] <nevcairiel> if the decoder buffers any more than required, it'll go out of sync with pts
[19:26:22 CEST] <cone-467> ffmpeg 03Ronald S. Bultje 07master:3285005347b2: Undeprecate av_opt_set_defaults2().
[19:29:14 CEST] <BBB> nevcairiel: I dont believe thats how it works
[19:29:22 CEST] <BBB> nevcairiel: most decoders assume one in one out
[19:29:30 CEST] <BBB> nevcairiel: so assuming the pts is correct on the input packet
[19:29:47 CEST] <BBB> nevcairiel: you can put that packets timestamp on the AVFrame returned through get_buffer
[19:30:00 CEST] <nevcairiel> pts works
[19:30:00 CEST] <BBB> and then it doesnt matter how long its cached, its always correct
[19:30:02 CEST] <nevcairiel> but dts doesnt
[19:30:04 CEST] <BBB> right
[19:30:27 CEST] <nevcairiel> because it assigns the dts of the latest input packet to the currently outgoing frame
[19:30:29 CEST] <wm4> anway, for some codecs/containers you need DTS to figure out the PTS
[19:30:31 CEST] <nevcairiel> which depends on decoder delay
[19:30:35 CEST] <BBB> if the decoder buffers any more than required, it'll go out of sync with pts < it semeed you were suggesting pts cant work in all cases either
[19:30:44 CEST] <BBB> if not, then nevermind
[19:30:56 CEST] <wm4> so what's the suggested solution?
[19:31:16 CEST] <BBB> you throw timestamps out of the window
[20:46:22 CEST] <Daemon404> nevcairiel / BBB - any opinion on the IDR patch?
[20:46:39 CEST] <Daemon404> (i didnt follow the talking in here completely)
[20:48:16 CEST] <BBB> its ok with me
[20:48:31 CEST] <BBB> michael is right that the option naming is clunky, but thats ok
[20:48:39 CEST] <BBB> its private codec options so -EWHOCARES
[20:49:41 CEST] <Daemon404> BBB, yeah i couldnt think of a better name though
[20:49:58 CEST] <BBB> its ok
[20:50:08 CEST] <BBB> its not just the name, it also feels that the option is kind of spaghetti
[20:50:32 CEST] <Daemon404> no, it definitely is
[20:50:41 CEST] <BBB> but again, codec private option, so its ok
[20:52:16 CEST] <Daemon404> huh... i cant full ffmpeg.git
[20:52:18 CEST] <Daemon404> times out
[20:53:50 CEST] <jamrial> if you meant pull, just tried and it worked
[20:54:49 CEST] <Daemon404> ]$ git pull --rebase
[20:54:49 CEST] <Daemon404> fatal: read error: Connection reset by peer
[20:54:56 CEST] <Daemon404> getting this now
[20:55:38 CEST] <kierank> git.ffmpeg.org?
[20:55:40 CEST] <kierank> or source.ffmpeg.org
[20:57:27 CEST] <nevcairiel> I always use videolan, fuck this redirect business
[21:01:20 CEST] <kierank> same
[21:23:06 CEST] <cone-467> ffmpeg 03Stephen Hutchinson 07master:c5308eea2921: configure: force -mconsole when linking SDL under MinGW
[21:26:20 CEST] <BBB> wm4: do you feel like you could review the outstanding vdpau patches? you tested them at elast
[21:26:51 CEST] <BBB> michaelni: can you approve mpeg4video: use ff_dlog instead of av_log under debug&FF_DEBUG_GENPTS.?
[21:30:24 CEST] <wm4> BBB: right, forgot to reply with LGTM
[21:31:30 CEST] <michaelni> BBB s/FF_DEBUG_GENPTS/FF_DEBUG_PTS/ 
[21:31:42 CEST] <michaelni> with that it LGTM
[21:32:18 CEST] <BBB> updated on github with that, and will push, ty
[21:33:16 CEST] <BBB> wm4: https://github.com/rbultje/ffmpeg/commits/api
[21:33:33 CEST] <BBB> wm4: its lavc: put remaining bits of vdpau-in-decoder under FF_API_CAP_VDPAU., then yours, and then lavu: disable wrong value check in get_version() upon api bump.
[21:33:50 CEST] <wm4> acked the first 2, the 3rd was ok'ed by mini
[21:33:58 CEST] <BBB> https://github.com/rbultje/ffmpeg/commit/9e787b03fac0abe626605b21fee64b844426d47f, https://github.com/rbultje/ffmpeg/commit/7c553d8ca7fcf4c3e95c92dd43502cb45df927d8 (yours) and https://github.com/rbultje/ffmpeg/commit/49c4bd0944a26738f60bc39573f964aae08898ea
[21:34:03 CEST] <BBB> ok ty
[21:34:05 CEST] <wm4> so what about that branch, should I test it, or review commits?
[21:34:25 CEST] <BBB> no my email showed just one review
[21:34:36 CEST] <BBB> the other one popped in as you said I acked the first 2
[21:34:43 CEST] <BBB> so ignore me
[21:35:10 CEST] <BBB> was your comment to the FF_IDCT_* one approval btw?
[21:35:14 CEST] <BBB> or just a question?
[21:37:58 CEST] <wm4> count it as approval (I just replied too)
[21:39:30 CEST] <BBB> ty
[21:40:44 CEST] <cone-467> ffmpeg 03Ronald S. Bultje 07master:9468207e1cba: mpeg4video: use ff_dlog instead of av_log under debug&FF_DEBUG_PTS.
[21:56:41 CEST] <cone-467> ffmpeg 03Ronald S. Bultje 07master:7a629186ba04: Prepare for removal of obsolete FF_IDCT_* members.
[22:06:07 CEST] <cone-467> ffmpeg 03Ronald S. Bultje 07master:030b5a4f777b: lavc: put remaining bits of vdpau-in-decoder under FF_API_CAP_VDPAU.
[22:06:08 CEST] <cone-467> ffmpeg 03wm4 07master:a383f226f02b: lavc: move vdpau decoders under FF_API_VDPAU.
[22:06:09 CEST] <cone-467> ffmpeg 03Ronald S. Bultje 07master:87068ea5c5c8: lavu: disable wrong value check in get_version() upon api bump.
[22:12:41 CEST] <Daemon404> this i really bizzarre
[22:12:45 CEST] <Daemon404> i can clone x264 from videolan
[22:12:51 CEST] <Daemon404> but ffmpeg.git ends with reet by peer
[22:13:44 CEST] <Daemon404> vlc.git either
[22:13:44 CEST] <jamrial> just add the github mirror as remote and fetch from there for the time beign
[22:14:55 CEST] <Daemon404> github works yeah
[22:20:27 CEST] <Daemon404> gah cant push either
[22:20:41 CEST] <Daemon404> someone want to push?
[22:24:18 CEST] <nevcairiel> are you using yodel internet now?
[22:25:13 CEST] <Daemon404> just some videolan repos seem to have issues...
[22:25:15 CEST] <Daemon404> i dunno.
[22:27:12 CEST] <BBB> it works for me
[22:27:17 CEST] <BBB> I think the problem is on your end
[22:27:37 CEST] <BBB> or I s3kr3tly h4x0r3d videolan/ffmpeg git and kicked you guys out
[22:27:42 CEST] <BBB> muhahahaha
[22:27:54 CEST] <Daemon404> probably
[22:27:57 CEST] <Daemon404> it's weird
[22:29:56 CEST] <Daemon404> i guess someone else can push in the meanwhile. oh well.
[22:36:05 CEST] <jamrial> the libx264 idr commit? i can push it
[22:36:13 CEST] <jamrial> no changes to the version in the ml, right?
[22:36:56 CEST] <Daemon404> yea.
[22:37:16 CEST] <Daemon404> as long as the version bump is still valid
[22:42:18 CEST] <llogan> i'm kind of surprised fflogger is still alive. burek vanished a while ago.
[22:42:25 CEST] <cone-467> ffmpeg 03Derek Buitenhuis 07master:c981b1145a85: libx264: Add option to force IDR frames
[22:43:39 CEST] <Daemon404> thx
[22:45:03 CEST] <jamrial> np
[23:06:36 CEST] <philipl> heh.
[23:06:57 CEST] <cone-467> ffmpeg 03Pedro Arthur 07master:0f3687d6fb87: swscale: add license headers and copyrights
[23:06:58 CEST] <cone-467> ffmpeg 03Pedro Arthur 07master:ed80dec621f6: swscale: fixed compiler warnings
[23:06:59 CEST] <cone-467> ffmpeg 03Pedro Arthur 07master:4545906f6038: swscale: Fixed typos
[23:08:19 CEST] <nevcairiel> BBB: told you
[23:14:44 CEST] <Compn> Daemon404 : did you mess up your git credentials ?
[23:14:55 CEST] <Compn> it will reset by peer if you dont have the right login
[23:15:30 CEST] <cone-467> ffmpeg 03Lou Logan 07master:5d410a1db2bf: doc/indevs: fix fbdev typos
[23:16:21 CEST] <jamrial> doesn't that apply only to ssh connections and not pull/fetch?
[23:16:26 CEST] <Daemon404> yes
[23:16:37 CEST] <Daemon404> couldnt clone either
[23:17:40 CEST] <philipl> nevcairiel: Does carl have some secret application he's responsible for but they've lost the source code so it can never be updated to use new APIs?
[23:19:48 CEST] <llogan> works fine for me with remote origin url =  git at source.ffmpeg.org:ffmpeg
[23:20:16 CEST] <nevcairiel> philipl: usually its just mplayer, which due to its brokenness constitutes an almost similar situation, but i dunno
[23:20:17 CEST] <BBB> Daemon404: I had a port mapping that screwed me over
[23:20:25 CEST] <BBB> (although that was very old)
[23:21:18 CEST] <philipl> nevcairiel: I would assume he knows mplayer uses the new vdpau API. Hence my wondering if there's something else.
[23:21:39 CEST] <BBB> a 3 year old version of mplayer, maybe?
[23:21:50 CEST] <BBB> like, one that can still be compiled with gcc-2.95
[23:22:20 CEST] <philipl> Good ol' gcc 2.95.
[23:22:23 CEST] <philipl> And glibc 2.1.3
[23:22:31 CEST] <philipl> Those were the days.
[23:31:26 CEST] <JEEB> I think XBMC guys were really into the old VDPAU stuff
[23:31:41 CEST] <JEEB> but I'd bet they've moved to the new one already?
[23:31:41 CEST] <nevcairiel> i think they migrated because the old way was broken
[23:32:30 CEST] <nevcairiel> (or at least lacking some features)
[23:36:58 CEST] <wm4> rage
[23:37:15 CEST] <wm4> when did he ever "maintain" anything in vdpau
[23:38:10 CEST] <jamrial> btw, regarding the vdpau stuff, shouldn't the guards from a383f226 be FF_API_CAP_VDPAU and not FF_API_VDPAU? The latter is a lavu deprecation guard
[23:39:06 CEST] <wm4> actually he has a bunch of vdpau commits, but I still don't care
[23:39:49 CEST] <wm4> jamrial: maybe both
[23:40:07 CEST] <wm4> there are various other things that would prevent the code from compiling anyway
[23:43:21 CEST] <jamrial> regardless of him having or not vdpau related comits, he's completely in the wrong this time. adding missing guards to prevent compilation failures once a bump takes place does not constitute a new deprecation
[23:59:34 CEST] <Compn> wm4 : our maintainers list actually does mean something
[23:59:41 CEST] <Compn> libav is the one who rm'd theirs
[00:00:00 CEST] --- Wed Aug 19 2015