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

[burek]

[00:27:43 CEST] <ubitux> finally found why nlmeans was badly denoising the bottom right corner of every square with a 3x3 patch
[00:28:11 CEST] <ubitux> spent 2 hours for missing -1 in integral computation
[00:28:13 CEST] <ubitux> grrr
[00:28:54 CEST] <ubitux> anyway, i'm not convinced by the parameter combinations proposed by ipol
[00:29:02 CEST] <ubitux> but maybe i'm implementing them badly
[00:35:06 CEST] <durandal_17> ubitux: what kind of combination?
[00:35:41 CEST] <ubitux> like, you specify a denoising strength, and it suggests good parameters for patch and research window sizes
[00:35:48 CEST] <ubitux> as well as filtering parameter scaling
[00:36:04 CEST] <ubitux> http://www.ipol.im/pub/art/2011/bcm_nlm/ "Parameters"
[00:45:31 CEST] <ubitux> if anyone is looking for some nice undenoisable shit: http://b.pkh.me/IMG_20160914_215659.jpg
[00:47:50 CEST] <ubitux> but now i really need some simd
[00:48:27 CEST] <Chloe> what you simd-ing?
[00:48:44 CEST] <ubitux> nothing yet, but ideally the integral computation
[00:49:00 CEST] <ubitux> running sum of (a-b)²
[01:57:46 CEST] <Chloe> ubitux: I tried to give (a-b)^2 a shot, but I failed miserably: I was thinking to use a^2+b^2-2ab; so dppd xmm1, xmm1 where xmm1 is (a,b), and use dppd again with a -2, 1 constant, then adding both results. I couldn't get the constants working (it didnt compile), I'd be interested to see how you did it
[01:58:20 CEST] <Chloe> s/dppd again/dppd with a,b and a -2,1 constant/
[01:58:29 CEST] <Chloe> err, oh well.
[11:01:53 CEST] <ubitux> so i "fixed" fate-rv20-1239 with https://github.com/ubitux/FFmpeg/commit/3a197e7058a88f2f53b40131b5a1342d57d59e5a
[11:03:04 CEST] <durandal117> sorry state of colorspace in ffmpeg
[11:03:13 CEST] <ubitux> going to do some cleanups and submit that codecpar madness
[11:07:38 CEST] <nevcairiel> ubitux: should probably wrap that in the appropriate ifdefs and disable deprecation warnings
[11:07:56 CEST] <nevcairiel> (and hopefully we can remove it once ffmpeg.c is a bit smarter with graphs)
[11:08:57 CEST] <ubitux> i don't want to silence something that needs fixing
[11:09:29 CEST] <ubitux> ffmpeg.c still has a bunch of crap
[11:09:42 CEST] <durandal117> michaelni: color* options set via ffmpeg are not used at all, see #5852
[11:09:46 CEST] <ubitux> like, codec->debug
[12:32:09 CEST] <ubitux> [~/src/ffmpeg]- git show|grep -c FIXME
[12:32:12 CEST] <ubitux> 5
[12:32:14 CEST] <ubitux> sadness
[12:33:19 CEST] <RiCON> ubitux: look at bigger picture: git grep FIXME | wc -l: 812
[12:34:57 CEST] <ubitux> so 818 FIXME, 259 TODO, 259 XXX
[12:35:08 CEST] <ubitux> heh, exact same number of TODO and XXX
[12:35:20 CEST] <nevcairiel> maybe someone wrote XXX TODO everytime
[12:35:31 CEST] <ubitux> actually a bunch of false positives in XXX
[12:36:46 CEST] <durandal117> michaelni: why "    int interlace; //FIXME use frame.interlaced_frame" in libavcodec/avrndec.c? I don't get it.
[13:36:39 CEST] <nevcairiel> ubitux: am I right when I assume ffmpeg.c already used a dedicated decoding context, and not st->codec for decoding?
[13:36:51 CEST] <nevcairiel> (or encoding, for that matter)
[13:36:57 CEST] <michaelni> durandal117, iam not 100% sure but at the tie the fixme was added there was a AVFrame i the context, the FIXME probably makes no sense in todays design
[13:37:51 CEST] <cone-467> ffmpeg 03Michael Niedermayer 07master:e048b46f14d6: fate: Add rgb24-mkv test
[13:48:16 CEST] <BBB> ubitux: codecpar ffmpeg! amazing!
[13:50:01 CEST] <ubitux> at least it will put an end to the deadlock in merge progress
[13:50:13 CEST] <ubitux> ~320 commits to handle now
[13:50:17 CEST] <ubitux> after this is applied
[13:50:29 CEST] <ubitux> (along with fixing all kind of stuff that this probably breaks)
[13:51:04 CEST] <nevcairiel> i can help with the merges again once those are up and running then, should have some more time now that the summer is over
[13:52:10 CEST] <ubitux> when we're finally back on par with libav and nlmeans is applied i'll be able to finish the new subtitles decoding api
[13:52:27 CEST] <ubitux> speaking of this, let's make nlmeans ready...
[13:53:23 CEST] Action: durandal117 thinks nobody is expert of ffmpeg.c
[13:53:43 CEST] <nevcairiel> we give that title to ubitux now
[13:53:47 CEST] <nevcairiel> he probably really doesnt want it
[13:53:50 CEST] <nevcairiel> but what can you do!
[13:53:53 CEST] <ubitux> :((
[13:54:46 CEST] <ubitux> michaelni: isn't this failure the same as the matroska tests changes?
[13:54:54 CEST] <nevcairiel> probably
[13:54:59 CEST] <ubitux> you're talking about interlacing; that's exactly what it was about
[13:55:13 CEST] <ubitux> previously marked as undefined, now set as progressive (see commit message)
[14:00:18 CEST] <michaelni> ubitux, sorry, i just run some tests yesterday, didnt realize, yes that change is probably ok then if its inteneded
[14:01:35 CEST] <michaelni> still theres a good thing on this, i found a bug unrelated to codecpar too :)
[14:02:40 CEST] <michaelni> unrelated to your stuff, didnt had time to debug that one yet, not important, was just some rounding issue on arm
[14:05:05 CEST] <ubitux> :)
[14:19:03 CEST] <ubitux> btw, i haven't tested the bsf stuff and assumed it was properly covered by fate
[15:10:29 CEST] <durandal117> why pasp atom is not written in mov when sar=1/1?
[15:22:33 CEST] <JEEB> why should it be?
[15:22:52 CEST] <JEEB> it's a thing that overrides the stream value if available, IIRC
[15:23:34 CEST] <durandal117> the only thing that stores sar in mov is pasp atom
[15:27:07 CEST] <JEEB> no
[15:27:15 CEST] <JEEB> actually the display resolution > pasp
[15:27:31 CEST] <JEEB> when I get home I can link you to a write-up I did
[15:28:16 CEST] <durandal117> if pasp is not written for 1/1 case, ffmpeg assumes sar is unknown, 0/1
[15:28:32 CEST] <durandal117> thus dar is unknown too
[15:31:06 CEST] <durandal117> i have mov files with pasp set to 1/1
[15:39:30 CEST] <rhn> hi! I'd like to register on your trac. Can anyone help me get past your blacklist?
[15:41:07 CEST] <JEEB> durandal117: pasp 1/1 is valid but it's [sar in stream] => [par] => [general viewport]
[15:41:17 CEST] <JEEB> latter two being something in the container
[15:41:23 CEST] <durandal117> rhn: what problem do you have?
[15:41:33 CEST] <JEEB> let me see if I can find a separate bug report for a player that actually says what the last thing was
[15:41:47 CEST] <rhn> durandal117: http://wklej.org/id/2857291/
[15:42:15 CEST] <rhn> this is where the registration process ends for me, no emails sent, no account created
[15:42:35 CEST] <JEEB> durandal117: ok, tkhd's width and height is the UBER ALLES thing it seems
[15:43:46 CEST] <JEEB> see https://social.technet.microsoft.com/Forums/windows/en-US/fed910ba-0b25-48f1-8abb-39bc56095831/a-small-bug-in-windows-media-player-12-on-windows-81-and-windows-7?forum=w8itprogeneral (I know, I know - but it has my tl;dr regarding aspect ratios in mp4)
[15:45:42 CEST] <durandal117> JEEB: what are you saying, that because of wmp we should not write pasp if sar=1/1
[15:46:33 CEST] <durandal117> rhn: do you want to report bug?
[15:46:40 CEST] <JEEB> durandal117: no
[15:46:44 CEST] <rhn> durandal117: yes, I want to confirm http://wklej.org/id/2857291/
[15:46:52 CEST] <rhn> *confirm https://trac.ffmpeg.org/ticket/4703
[15:46:56 CEST] <JEEB> that tl;dr just contains an explanation of what is the ordering of aspect ratio information in MP4
[15:47:38 CEST] <JEEB> which is [tkhd width|height (uber alles)] > [pasp] > [stream sar]
[15:47:59 CEST] <JEEB> and pasp in general is something that is not overriding tkhd's width/height
[15:48:53 CEST] <durandal117> JEEB: i'm taliking about writing pasp, not reading
[15:49:46 CEST] <durandal117> rhn: for blacklist thing you will need to wait, i do not control that
[15:50:44 CEST] <rhn> durandal117: can you just confirm on my behalf that Fedora 23 has the same problem? I might forget/not have the time to report later
[15:51:32 CEST] <JEEB> durandal117: yes. I am just not talking why you would need pasp for 1/1 sar
[15:52:15 CEST] <JEEB> durandal117: but if there is a weird if thing removing the pasp writing I'm OK with making that not be there
[16:02:49 CEST] <michaelni> ubitux, posted a fate test with bsf that breaks, should i push it ? (sample file is 32k)
[16:04:00 CEST] <jamrial> michaelni: didn't rcombs send a patchset full of bsf tests, including this one?
[16:04:45 CEST] <jamrial> also, bsf failing after codecpar port make me wonder if it's not related to the fact ubitux's patch didn't yet port the ffmpeg.c bsf code to the new api
[16:05:14 CEST] <ubitux> :x
[16:05:33 CEST] <jamrial> same with that concat failure, seems to rely on bsf for h264
[16:05:38 CEST] <rcombs> I did add a test for adtstoasc
[16:05:50 CEST] <ubitux> any fate test that breaks codecpar is welcome
[16:05:53 CEST] <rcombs> (using autobsf)
[16:06:00 CEST] <ubitux> "welcome"
[16:06:07 CEST] <ubitux> of course a patch to fix the problem is even better :p
[16:06:21 CEST] <ubitux> jamrial: should i look into importing the other changes?
[16:08:00 CEST] <jamrial> ubitux: probably worth a try. it might very well make these bsf issues go away
[16:09:07 CEST] <jamrial> also, lowres needing that much st->codec usage is :(
[16:09:16 CEST] <jamrial> weren't we going to get rid of lowres at some point?
[16:09:44 CEST] <ubitux> dunno what's the plan about lowres, but it needs to be fixed before next bump or it will go away
[16:10:10 CEST] <jamrial> yeah
[16:10:38 CEST] <ubitux> ...or be delayed as usual and prevent a shitton of hacks to go away
[16:11:31 CEST] <jamrial> we need to lobby projects to port in the meantime :p
[16:11:39 CEST] <jamrial> many already did
[16:20:52 CEST] <jamrial> michaelni, ubitux: yeah, the concat failure seems to be bsf related. using mpeg2 or mpeg4 sources with the same command works fine, since unlike h264 thet don't rely on autobsf
[16:24:48 CEST] <michaelni> "<ubitux> any fate test that breaks codecpar is welcome", ok will push fate-adtstoasc_ticket3715 in a few minutes unless i hear objections
[16:26:47 CEST] <ubitux> i thought rcombs had a pending patch for this?
[16:26:54 CEST] <ubitux> jamrial: ah, nice
[16:28:28 CEST] <jamrial> ubitux: yeah, also using an h264 source (like from mpegts) which doesn't trigger the autobsf in concat also works, so pretty much that's what's wrong
[16:29:56 CEST] <michaelni> ubitux, i can drop mine if rcombs can push his, thought his depended on other patches ?
[16:30:03 CEST] <ubitux> i have no idea
[16:30:18 CEST] <ubitux> i have 0 clue about the bsf stuff 
[16:31:26 CEST] <jamrial> michaelni: his uses autobsf, whereas yours seems to force the bsf from the command line
[16:34:10 CEST] <michaelni> aac-autobsf-adtstoasc seems to pass before and after ubitux patch
[16:36:22 CEST] <ubitux> transcode vs streamcopy?
[16:38:45 CEST] <jamrial> no, both are streamcopy
[16:39:27 CEST] <ubitux> do bsf matter in case of transcode?
[16:39:59 CEST] <nevcairiel> they can
[16:40:33 CEST] <ubitux> every bsf test so fare seems to be in the context of streamcopy
[16:40:37 CEST] <ubitux> far*
[16:40:46 CEST] <nevcairiel> thats their major use-case yes, transcode is rather rare
[16:40:59 CEST] <nevcairiel> you would need to have an inflexible encoder or something
[16:41:07 CEST] <nevcairiel> like an aac encoder that can only produce adts and nothing else
[16:45:53 CEST] <rcombs> yeah my bsf tests are all autobsf, which means they test the BSF itself and the auto-insertion infrastructure, but not any corresponding code in ffmpeg.c
[16:46:31 CEST] <rcombs> so if you want to test ffmpeg.c you'll need something separate
[16:47:14 CEST] <jamrial> using -bsf, like in michaelni's patch?
[16:48:03 CEST] <rcombs> sure
[16:50:11 CEST] <jamrial> then they can coexist
[16:51:00 CEST] <jamrial> michaelni: ^
[17:25:30 CEST] <cone-467> ffmpeg 03Michael Niedermayer 07master:492259ccda43: fate: add aac_adtstoasc test (Ticket 3715)
[19:29:08 CEST] <durandal_17> does vaapi hw decoder supports yuv420p10?
[19:29:18 CEST] <durandal_17> for hevc
[19:29:28 CEST] <JEEB> you probably will be getting P010 from it
[19:29:38 CEST] <JEEB> at least looking at the kaby lake related changes
[19:29:45 CEST] <JEEB> but kaby lake not yet here
[19:30:31 CEST] <A3G1S> Hey Guys, any info about x86 text relocations ?
[19:31:19 CEST] <JEEB> A3G1S: disallowing them kind of makes sense for system libraries (maybe), but not for app-specific ones. although android something or another decided to block them altogether
[19:32:01 CEST] <A3G1S> @JEEB thats the problem I am facing right now, on x86 Android FFmpeg ain't working anymore 
[19:33:26 CEST] <JEEB> A3G1S: you can try disabling all asm, but holy hell you will lose optimization in a whole lot of stuff.
[19:34:00 CEST] <JEEB> not sure how it would even be possible to have the x86(_64) asm optimizations work without text relocations (if this is possible, don't kill me)
[19:34:47 CEST] <A3G1S> I am not a C/Assembly coder so don't really have much info about text relocations 
[19:36:29 CEST] <A3G1S> Although I tried to figure out whats happening and it definitely not a piece of cake  
[19:37:16 CEST] <JEEB> the workarounds a person I know is coming up with are no less hardcore :P
[19:37:30 CEST] <JEEB> (completely custom library loader, other hacking)
[19:46:36 CEST] <A3G1S> thats good 
[19:47:46 CEST] <A3G1S> btw @JEEB disabling asm works and your oot works perfectly 
[19:48:56 CEST] <A3G1S> I think users can handle performance for now, they just need something which works
[19:49:09 CEST] <JEEB> well, great to know disabling asm works
[19:49:22 CEST] <JEEB> too bad it will make everything sw decoded slooow
[19:49:37 CEST] <JEEB> but yeah, good point. esp. if you don't use the software decoders
[19:50:17 CEST] <A3G1S> yes but we can't help it unless there is an update from FFmpeg 
[19:50:31 CEST] <JEEB> yeah
[19:50:41 CEST] <JEEB> or google improves the x86(_64) limitations
[19:50:52 CEST] <JEEB> because it almost feels like it kills off hand-optimized code
[19:51:43 CEST] <A3G1S> might be, Its like if Google changes then we all have to 
[19:51:53 CEST] <A3G1S> we can't help it 
[19:51:54 CEST] <Gramner> oh yeah _that_ android 6 change of making all textrels stop working. no idea what the hell they were thinking
[19:52:25 CEST] <JEEB> "security, brah"
[19:52:26 CEST] <Gramner> "fixing" that is not gonna happen. really.
[19:52:30 CEST] <JEEB> yeah
[19:52:37 CEST] <JEEB> it's not realistic
[19:52:53 CEST] <JEEB> unless you do one of those complete hacks that try to circuimvent the protection
[19:53:10 CEST] <Gramner> it's rewriting what, 50k lines of handwritten assembly? making everything harder to understand and maintain in the process
[19:53:24 CEST] <JEEB> http://up-cat.net/p/3566cd2b
[19:53:25 CEST] <A3G1S> holy moly 
[19:53:32 CEST] <A3G1S> 50k lines
[19:53:32 CEST] <A3G1S> :o
[19:53:43 CEST] <JEEB> A3G1S: there is a *lot* of hand-written optimizations in FFmpeg
[19:53:48 CEST] <A3G1S> and its assembly 
[19:54:02 CEST] <A3G1S> I am understanding now 
[19:54:12 CEST] <A3G1S> but we need to figure out a wayaround 
[19:54:24 CEST] <A3G1S> any hack or anything which will remove those text relocations
[19:55:27 CEST] <A3G1S> btw I do maintain this -> https://github.com/WritingMinds/ffmpeg-android
[19:55:36 CEST] <ubitux> this shit is only affecting x86, right? what's the actual % of x86 android?
[19:55:39 CEST] <JEEB> the problem is if you start hacking then GOOG might take that as breaking security and then block that, too
[19:55:39 CEST] <Gramner> x86-64 works btw, it's only 32-bit x86 that has a problem (due to no instruction-pointer-relative addressing available in 32-bit x86)
[19:55:48 CEST] <JEEB> Gramner: oh, good to know
[19:55:50 CEST] <A3G1S> yes @ubitux 
[19:55:58 CEST] <ubitux> so ENOCARE
[19:56:03 CEST] <ubitux> dead arch, especially for android
[19:56:04 CEST] <JEEB> ubitux: yeah it's really small %
[19:56:09 CEST] <A3G1S> @ubitux chromebooks will have play store enable soon 
[19:56:09 CEST] <JEEB> of all
[19:56:13 CEST] <A3G1S> so x86 is not dead I think 
[19:56:19 CEST] <ubitux> but 64-bits
[19:56:25 CEST] <ubitux> so...
[19:56:32 CEST] <A3G1S> I am not sure if it affects x86_64 
[19:56:35 CEST] <A3G1S> never tried that 
[19:56:37 CEST] <ubitux> it doesn't
[19:56:46 CEST] <A3G1S> thats interesting to know 
[19:56:56 CEST] <ubitux> so it's really not worth the trouble
[19:57:02 CEST] <JEEB> yeah, deffo
[19:57:24 CEST] <ubitux> just --disable-asm for the moron who insist on having it
[19:57:45 CEST] <A3G1S> yes 
[19:58:13 CEST] <A3G1S> Thanks for the ubitux 
[19:58:21 CEST] <A3G1S> help*
[19:58:41 CEST] <ubitux> i like that original quote
[19:59:01 CEST] <Gramner> +1
[19:59:01 CEST] <ubitux> so long, and thanks for the ubitux 
[19:59:09 CEST] <A3G1S> haha
[19:59:21 CEST] <A3G1S> yeah 1st one was better
[19:59:47 CEST] <A3G1S> @JEEB thanks to you too man, you are life saver here :-) 
[20:00:06 CEST] <JEEB> I am one of the masochists doing https://github.com/mpv-android/mpv-android
[20:03:41 CEST] <A3G1S> nice 
[20:11:04 CEST] <durandal_17> what could cause to s->pb become NULL?
[20:25:34 CEST] <rcombs> ^ fuck BOMs though
[20:40:55 CEST] <durandal_17> lol vlc coredumped
[20:59:26 CEST] <ubitux> so the TESTPROGS are not run by default?
[21:00:32 CEST] <jamrial> they should be run by fate
[21:00:43 CEST] <jamrial> ubitux: fixed the pkt duration bug, btw
[21:01:11 CEST] <ubitux> you mean the bsf thing?
[21:01:18 CEST] <jamrial> no, my latest email
[21:01:27 CEST] <ubitux> oh, ok
[21:01:29 CEST] <jamrial> you deleted the line copying frame_size from src to dst during stream copy
[21:01:37 CEST] <ubitux> ah, oups
[21:01:42 CEST] <ubitux> sorry about that
[21:01:57 CEST] <ubitux> make fate-list|grep drawutils doesn't show anything
[21:02:05 CEST] <jamrial> just add "par_dst->frame_size = par_src->frame_size;" for audio, around line 2980
[21:02:35 CEST] <ubitux> will do
[21:04:06 CEST] <jamrial> ubitux: oh nice, it fixed fate-adtstoasc_ticket3715 as well!
[21:04:12 CEST] <jamrial> let me check the concat failure
[21:04:15 CEST] <ubitux> heh
[21:05:22 CEST] <jamrial> ubitux: yes, it did
[21:05:31 CEST] <jamrial> :D
[21:05:39 CEST] <ubitux> wait, wasn't this one related to bsf?
[21:05:54 CEST] <jamrial> looks like it wasn't
[21:06:11 CEST] <jamrial> it only happened with h264 after triggering the autobsf
[21:06:27 CEST] <jamrial> but guess that somewhere in the whole process, frame_size was needed
[21:08:37 CEST] <ubitux> give me a few minutes to send the last nlmeans patch and i'm looking back at this stuff
[21:09:32 CEST] <jamrial> ubitux: sure, i'm rechecking everything with a clean tree anyway. added way too many av_logs
[21:18:06 CEST] <jamrial> ubitux: yeah, adding frame_size fixes the pkt duration thing and the concat example. if you also change ost->enc_ctx to avctx in write_frame(), it fixes fate-adtstoasc_ticket3715
[21:52:37 CEST] <ubitux> http://imgur.com/a/XXhJP i really like the results in the 2nd picture
[21:52:45 CEST] <ubitux> (maybe the strength is too high though)
[22:02:01 CEST] <ubitux> jamrial: ok let me look at all of this now
[22:19:24 CEST] <ubitux> jamrial: how did you fixed adtstoasc_ticket3715?
[22:19:36 CEST] <ubitux> i only integrated the frame_size change
[22:19:49 CEST] <ubitux> maybe i should fix the extradata thing you pointed out on the ml?
[22:39:25 CEST] <jamrial> ubitux: yeah, that's what i meant above
[22:41:20 CEST] <jamrial> ubitux: once the bsf stuff is ported that part will be gone or altered anyway
[22:42:16 CEST] <ubitux> did you see a bit above the usage of ost->st->codec?
[22:42:26 CEST] <ubitux> which is almost the same chunk duplicated?
[22:42:35 CEST] <ubitux> i removed it (and now remember it broke things pointed out on the ml)
[22:42:44 CEST] <ubitux> maybe i should just re-add that chunk
[22:43:25 CEST] <jamrial> ubitux: nothing seems to be broken with it removed, though
[22:43:38 CEST] <ubitux> yeah, dunno
[22:44:05 CEST] <ubitux> i need to recheck what michael pointed out on the ml a while back about it
[22:45:00 CEST] <jamrial> maybe it's needed for transcode + bsf, let me do some tests
[22:50:36 CEST] <jamrial> ubitux: doesn't seem to affect bsf + transcoding
[22:50:43 CEST] <jamrial> that chunk was added by commit ab84effde
[22:51:09 CEST] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/198685.html
[22:51:11 CEST] <ubitux> see ^
[22:51:43 CEST] <ubitux> and yeah it didn't make a diff for the ticket associated with that commit
[22:51:52 CEST] <ubitux> but michael pointed out something that broke
[22:52:00 CEST] <ubitux> not sure if it's now covered by fate
[22:54:14 CEST] <jamrial> ubitux: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/198688.html that file he tested is the one he added as fate-adtstoasc_ticket3715 earlier today
[22:54:28 CEST] <jamrial> so it should be ok, since we made that test pass
[22:55:55 CEST] <jamrial> so the chunk can go. and as i said before, it will all most likely change anyway once it's ported to the new bsf api
[22:57:48 CEST] <ubitux> do you think we should have this changed in this commit?
[22:58:27 CEST] <ubitux> i'm not sure what that "new" bsf api is refering to given that libav still has the bsf FIXME
[22:59:41 CEST] <jamrial> the one fixme they left is for parser stuff afaik, not bsf. let me dig the commit that changed this
[23:00:12 CEST] <jamrial> there were like fix commits in total, that i squashed into one diff some time ago
[23:01:32 CEST] <ubitux> ah indeed, it's refering to parser API ok
[23:03:57 CEST] <jamrial> ubitux: https://git.libav.org/?p=libav.git;a=commitdiff;h=4426540f0c3ee516662f79d0a6ab5b95503b6611
[23:04:01 CEST] <jamrial> https://git.libav.org/?p=libav.git;a=commitdiff;h=35c858066840352d6d43385bbc728467c5150974
[23:05:14 CEST] <ubitux> damn, so much commits skipped
[23:06:17 CEST] <jamrial> no, for ffmpeg/avconv codecpar just five or so, but those two above and the one you alredy did are the most important
[23:15:03 CEST] <jamrial> ubitux: the others are 80fb19b and fe7b21c8 which are small and can be squashed with the bsf port commit
[23:15:21 CEST] <jamrial> since they are just bug fixes rather than actual port work
[23:15:39 CEST] <ubitux> i updated my codecpar branch
[23:15:46 CEST] <ubitux> it passes fate
[23:15:56 CEST] <JEEB> yayifications
[23:16:32 CEST] <BtbN> quick, merge it before something else breaks!
[23:16:37 CEST] <ubitux> changes: use of avctx instead of ost->enc_ctx in the extradata stuff as previously, unconditionnally set pkt_timebase (as suggested by nevcairiel) with a new simpler comment, and restored the frame_size copy as pointed out
[23:16:46 CEST] <ubitux> did i forget something?
[23:17:02 CEST] <jamrial> don't think so
[23:17:20 CEST] <nevcairiel> Sounds good
[23:17:49 CEST] <ubitux> should the last version on the ml?
[23:18:01 CEST] <jamrial> yeah, send it
[23:18:21 CEST] <jamrial> and lets hope michael doesn't find another weird scenario that broke :p
[23:21:50 CEST] <ubitux> any visibility on the "new parser api" btw?
[23:22:03 CEST] <ubitux> or it's just the next secret project from Anton?
[23:22:29 CEST] <ubitux> because i'm really looking for improvements in that area wrt probe as already mentioned
[23:22:56 CEST] <BtbN> I wonder if working on ffmpeg.c making use of the new avcodec API is worth it.
[23:23:15 CEST] <BtbN> It shouldn't be too hard to migrate it without breaking existing features, and it would allow for adding new ones.
[23:25:28 CEST] <jamrial> BtbN: you mean the new decode/encode API?
[23:25:51 CEST] <BtbN> yes
[23:26:00 CEST] <BtbN> wm4 has patches for it. Which are mostly working fine
[23:26:17 CEST] <BtbN> Not for my usecase(frame-doubling decoder), but for the normal ones.
[23:33:26 CEST] <philipl> BtbN: did you see my comments on the Alt-Reference frames for vp8/9?
[23:34:02 CEST] <BtbN> uhm, I don't think so? Might have just forgotten if I did.
[23:34:22 CEST] <philipl> https://github.com/philipl/FFmpeg/commit/c09e59938defc325734bd8a2ac36b9c0321c5145
[23:34:42 CEST] <philipl> If you can come up with a way to avoid the waiting_frames count, that would be preferrable.
[23:34:47 CEST] <philipl> The header situation is a mess.
[23:36:01 CEST] <philipl> Your changes work great in mpv even if not with ffmpeg.c
[23:37:15 CEST] <BtbN> The problem is, there has to be some condition to stop accepting new packets with the new API
[23:37:29 CEST] <BtbN> Just watching the fifo length isn't enough
[23:39:13 CEST] <philipl> Then you'll need this check.
[23:39:28 CEST] <philipl> and no one will ever be able to build the code :-)
[23:39:58 CEST] <BtbN> well... could just look up the offset into the struct, and pull it out manually.
[23:39:59 CEST] <philipl> This brings me back to we should add the video sdk headers (BSD licence) and modify them until they work without the dynlink crap.
[23:40:13 CEST] <philipl> They are the only correct headers around.
[23:40:26 CEST] <BtbN> Isn't the dynlink stuff MIT?
[23:40:30 CEST] <philipl> Yes.
[23:40:36 CEST] <philipl> There's no problem there. You could just use it too.
[23:41:03 CEST] <philipl> but the dynlink_cuda is not, so you'd need to make it work with regular cuda.h
[23:41:49 CEST] <BtbN> it shouldn't care.
[23:42:04 CEST] <philipl> I tried building with the unmodified dynlink headers. Blew up at runtime
[23:42:21 CEST] <BtbN> well, of course. You didn't dynload the library
[23:42:32 CEST] <philipl> Doesn't fail at link time. It's a feature!
[23:43:16 CEST] <philipl> But one way or the other, it seems the only way to make it buildable
[23:43:40 CEST] <BtbN> the cuvid functions are variables in those
[23:43:50 CEST] <BtbN> you need to dlopen and load yourself
[00:00:00 CEST] --- Wed Sep 21 2016