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

[burek]

[00:07:03 CEST] <JEEB> michaelni__: cheers. feel free to note if you see anything wrong with the second one ( https://patchwork.ffmpeg.org/patch/741/ )
[00:08:04 CEST] <michaelni__> JEEB, i see nothing wrong with it
[00:08:34 CEST] <JEEB> k
[00:33:54 CEST] <llogan> to sourceforge's credit it only took them less than an hour to remove a license violator
[00:34:14 CEST] <cone-480> ffmpeg 03James Almer 07master:a68f1ae6b1f2: doc/codecs.texi: fix and expand color related options
[00:47:38 CEST] <Chloe> jamrial: your fate patch doesnt pass fate: http://sprunge.us/XbMU
[00:48:10 CEST] <jamrial> Chloe: what patch?
[00:48:11 CEST] <Chloe> oh
[00:48:12 CEST] <Chloe> my bad
[00:48:43 CEST] <Chloe> It helps if I have the samples needed for the test
[00:48:55 CEST] <JEEB> classic
[00:48:57 CEST] <nevcairiel> it does, doesnt it
[00:49:03 CEST] <JEEB> I think there was make fate-rsync or so
[00:49:07 CEST] <Chloe> yep
[00:50:22 CEST] <Chloe> jamrial: I'm testing the framehash patch
[00:50:33 CEST] <jamrial> ah
[00:52:02 CEST] <jamrial> Chloe: don't bother testing it, it can't go in like this. it would break anything parsing framecrc and framehash/framemd5 output if it cares about the channel layout hex value
[00:52:24 CEST] <Chloe> ok
[01:06:30 CEST] <cone-480> ffmpeg 03Steven Liu 07master:95f2dcafe189: doc/muxers: fix hlsenc options examples error
[01:24:32 CEST] <cone-480> ffmpeg 03Moritz Barsnick 07master:1846a3eac854: ffmpeg_vaapi: fix choice of decoder_format
[04:04:42 CEST] <cone-480> ffmpeg 03Sasi Inguva 07master:7e0235bdb145: lavc/utils.c: Subtract skip_samples when frame is DISCARDed.
[04:04:43 CEST] <cone-480> ffmpeg 03Sasi Inguva 07master:dba2db6c0e4a: lavf/mov.c: Make audio timestamps strictly monotonically increasing inside an edit list.
[05:01:11 CEST] <philipl> BtbN: cuda transcoding working for you after the recent merges? Something's gone wrong for me
[05:05:54 CEST] <philipl> resource registration is failing
[05:31:01 CEST] <philipl> bisected.
[05:31:03 CEST] <philipl> lavc: allow using AVCodecContext.hw_frames_ctx for decoding
[05:31:20 CEST] <philipl> This is what broke mpv for me (because it does the format comparison) and it broke transcoding.
[05:32:30 CEST] <philipl> I guess because it ends up using a different get_buffer that doesn't return something nvenc can handle?
[05:40:20 CEST] <philipl> Ok.
[05:42:29 CEST] <philipl> https://github.com/FFmpeg/FFmpeg/commit/32c25f06b79f9edcda726f6e043325d40036cdce#diff-d7031e4f689033d5546668b25eb9dd30R1125
[05:42:34 CEST] <philipl> This line is what breaks it.
[05:42:41 CEST] <philipl> I guess he thinks he's fixing a leak here?
[05:44:06 CEST] <philipl> I suspect the problem is that cuvid and nvenc are the same hw_frames_ctx and it gets unrefed too many times? Something like that?
[05:46:46 CEST] <philipl> It seems to get ref'ed the right number of times in ffmpeg_cuvid.c, so I don't think that's the problem.
[08:10:33 CEST] <nevcairiel> hw_frames_ctx wasnt properly documented for decoding before, so if stuff needs changes afterwards in user code that may be expected
[08:10:59 CEST] <nevcairiel> ie. hw_frames_ctx said "encoding only" in the doxy
[08:18:25 CEST] <nevcairiel> one change thats still missing is probable this one https://git.libav.org/?p=libav.git;a=commit;h=232399e3ee219d16d0e0d482c9f31a26202d4993 for ffmpeg.c hwaccels
[10:30:07 CEST] <BtbN> nevcairiel, yes, cherry-picking that fixes it for me.
[10:30:12 CEST] <BtbN> Can I just push it?
[11:33:34 CEST] <cone-307> ffmpeg 03Jan Ekström 07master:cc725ebe484c: movenc: Add support for writing language codes into ISML manifests
[12:05:11 CEST] <JEEB> yayifications^2
[12:05:22 CEST] <JEEB> I can now remove patches from my local usage :)
[14:44:43 CEST] <cone-307> ffmpeg 03Carl Eugen Hoyos 07master:29a76ff525e3: Changelog: Mention edts support.
[15:06:46 CEST] <BtbN> ubitux, or whoever is doing merges right now. Can I just push a cherry-picked https://git.libav.org/?p=libav.git;a=commit;h=232399e3ee219d16d0e0d482c9f31a26202d4993 ?
[15:07:03 CEST] <BtbN> without that essentialy all the ffmpeg hwaccels are broken
[15:08:15 CEST] <ubitux> if it doesn't depend on previous unmerged commits i have no objection, but that's not exactly my area
[15:08:30 CEST] <BtbN> it applies "cleanly"
[15:08:41 CEST] <BtbN> only avconv.c vs. ffmpeg.c
[15:08:56 CEST] <BtbN> I fixed that by just applying it manually
[15:09:33 CEST] <BtbN> With it, hwaccel decoding works again.
[15:09:44 CEST] <BtbN> Some recently merged change depends on it I think.
[15:10:50 CEST] <BtbN> Or rather, it is updating ffmpeg/avconv for this change: https://github.com/FFmpeg/FFmpeg/commit/32c25f06b79f9edcda726f6e043325d40036cdce
[15:57:13 CEST] <cone-307> ffmpeg 03Carl Eugen Hoyos 07master:fcce25ee5d2f: lavf/mov: Read display aspect ratio from ares atom also for dnxhd.
[15:57:14 CEST] <cone-307> ffmpeg 03Carl Eugen Hoyos 07master:e84eeca5779b: lavf/movenc: Put correct display aspect ratio in ARES atom.
[16:12:40 CEST] <cone-307> ffmpeg 03Anton Khirnov 07master:bfbf86ef18f7: ffmpeg: pass the hwaccel frames context to the decoder
[16:12:41 CEST] <cone-307> ffmpeg 03Timo Rothenpieler 07master:856e1eacf7f3: ffmpeg_cuvid: make use of new av_hwdevice_ctx_create api
[17:01:06 CEST] <philipl> BtbN: thanks
[17:18:51 CEST] <cone-307> ffmpeg 03Jan Sebechlebsky 07master:81bab1074ff9: avformat/tee: Copy interrupt callback and flags to slave
[17:41:06 CEST] <jamrial> Chloe: did you address the rest of Lukas Marek's items on his sdl2 device review?
[17:41:17 CEST] <Chloe> yes
[17:45:06 CEST] <jamrial> Chloe: i ask because in https://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/200003.html he says you ignored some, as they are still in the committed file
[17:45:48 CEST] <Chloe> they were fixed, see the current master
[17:51:25 CEST] <jamrial> i am looking at master, and some (like the "while" instead of "if") were not addressed
[17:51:47 CEST] <jamrial> if you think it's good as is then you should reply to that email explaining why
[17:52:19 CEST] <wm4> haha ffmpeg.c rescaling NOPTS timestamps to different timebases
[17:53:26 CEST] <Chloe> jamrial: sorry, where's the while instead of an if?
[17:57:50 CEST] <jamrial> Chloe: in his review https://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/199732.html he says you should use a while instead of an if
[17:58:44 CEST] <Chloe> oh right, I see now. Yes, that'd block the packet until an SDL event occurs, which is not very helpful.
[18:00:07 CEST] <atomnuker> jamrial: btw I remember in webm mode the mkv muxer writes the field order flag despite it being forbidden in the webm spec
[18:00:36 CEST] <jamrial> atomnuker: it shouldn't. not in git master or even after my patch
[18:00:40 CEST] <atomnuker> it was broken during a libav merge a few months ago
[18:01:05 CEST] <atomnuker> maybe it was fixed since then, but I clearly remember a commit message saying it should be fixed
[18:01:35 CEST] <jamrial> right now it's not even writing the flag interlaced element in webm, which is supported
[18:01:53 CEST] <jamrial> my patch changes that, so it writes flag interlaced but not field order
[18:02:09 CEST] <jamrial> so i guess it was fixed at some point
[18:06:13 CEST] <wm4> how can I know why ffmpeg.c is dropping a frame?
[18:11:48 CEST] <jamrial> wm4: loglevel verbose/debug doesn't help?
[18:15:19 CEST] <wm4> I suspect it's because this POS doesn't drain filters on video configuration changes (which happens with this test)
[18:16:23 CEST] <wm4> but I don't know
[18:17:14 CEST] <wm4> I'm definitely decoding 2 frames, and get only 1 (the second) back from the filters
[18:17:38 CEST] <wm4> it's showing "Input stream #0:0 frame changed from size:191x287 fmt:rgba to size:191x231 fmt:rgb24"
[18:18:28 CEST] <wm4> this happens when I enable threads
[18:18:47 CEST] <wm4> with 1 thread, it gets the frame back before reconfiguring (?)
[18:21:20 CEST] <wm4> adding filter draining is probably not really feasible, because lavfi's API of course makes this excessively hard
[18:21:58 CEST] <JEEB> does -vsync passthrough -copyts help?
[18:22:13 CEST] <JEEB> "if in doubt, try disabling timestamp fuckery"
[18:22:30 CEST] <JEEB> although I guess avfilter might be a less simple of a problem
[18:22:33 CEST] <wm4> JEEB: no
[18:22:38 CEST] <JEEB> :<
[18:53:45 CEST] <ubitux> 17:53 <+wm4> haha ffmpeg.c rescaling NOPTS timestamps to different timebases // i think av_rescale* have an exception for NOPTS?
[18:54:43 CEST] <wm4> I don't think so
[18:54:49 CEST] <ubitux> or maybe that's just just INT*_MAX things
[18:55:14 CEST] <ubitux> check the doxy in mathematics.h
[18:55:31 CEST] <ubitux> NOPTS is referenced
[18:56:09 CEST] <wm4> it doesn't use that flag though
[18:56:12 CEST] <wm4> also this is not my code
[19:37:38 CEST] <wm4> lol more demuxers which return 0 sized packets?
[22:36:26 CEST] <BtbN> https://bpaste.net/show/2ed5612872bb ...what? make fails with a compiler error because of a missing include, "make V=1" succeeds
[22:39:14 CEST] <BtbN> same happens with all the other cuda files.
[22:39:28 CEST] <BtbN> Like it does not apply the --extra-cflags without V=1 oO
[22:49:43 CEST] <BtbN> well... it works great if I just build with V=1
[22:49:58 CEST] <BtbN> it's surprisingly quite a bit faster than a mingw build
[22:58:22 CEST] <nevcairiel_> Then you probably did one of those wrong :D
[22:59:13 CEST] <BtbN> I'll investigate that tomorrow.
[22:59:27 CEST] <BtbN> But that build failure without V=1 is very strange.
[23:00:01 CEST] <rcombs> BtbN: run make with "SHELL=bash -v"?
[23:00:11 CEST] <rcombs> (but without V=1)
[23:00:37 CEST] <rcombs> should tell you if the args are different with V=1 or not (certainly shouldn't be, but I dunno, could be a bug somewhere)
[23:03:03 CEST] <BtbN> rcombs, https://bpaste.net/show/17082231266d well...
[23:03:15 CEST] <BtbN> it definitely dislikes being debugged
[23:05:34 CEST] <nevcairiel> For msvc I personally prefer setting the INCLUDE environment var over passing args anyway
[23:05:39 CEST] <rcombs> where's cuda.h actually
[23:05:55 CEST] <BtbN> D:/Programme/CUDA/include/cuda.h
[23:06:08 CEST] <BtbN> and I pass /ID:/Programme/CUDA/include
[23:08:08 CEST] <nevcairiel> Just have to hope mingw doesn't mangle your path
[23:08:22 CEST] <nevcairiel> Which it kinda likes to do
[23:08:29 CEST] <BtbN> there should be no mingw involved?
[23:09:03 CEST] <rcombs> yeah this sounds like a shell thing
[23:09:14 CEST] <nevcairiel> There is always mingw involved if a mingw executable calls other things through a bash shell
[23:09:18 CEST] <rcombs> ^
[23:09:38 CEST] <BtbN> This is running on cygwin
[23:09:54 CEST] <rcombs> might be related to how you get 2 commands on a line (;-separated) when V=1
[23:10:05 CEST] <nevcairiel> Maybe that's your problem then, cygwin is even worse :P
[23:10:19 CEST] <BtbN> it has no notion of that even being a path.
[23:10:37 CEST] <nevcairiel> Or so you hope!
[23:10:49 CEST] <BtbN> it wouldn't work with V=1 if it would
[23:12:06 CEST] <rcombs> with V=1 the task is just the compiler; otherwise it's a shell script that echoes the line and then runs the compiler
[23:12:26 CEST] <BtbN> you mean without the V=1?
[23:12:43 CEST] <rcombs> no, with it
[23:12:47 CEST] <rcombs> see common.mak
[23:12:58 CEST] <rcombs> $(eval override $(VAR) = @$$(call ECHO,$(VAR),$$(MSG)); $($(VAR))))
[23:13:56 CEST] <nevcairiel> This magic has worked for years tho
[23:14:27 CEST] <nevcairiel> And if anything V=1 is the more natural case
[23:15:07 CEST] <BtbN> so something in that magic breaks msvc commandlines with extra include dirs
[23:16:53 CEST] <nevcairiel> Actually more like the magic fixes something
[23:17:13 CEST] <nevcairiel> Because V=1 just executes the command without magic
[23:17:23 CEST] <BtbN> yes, and that works
[23:17:55 CEST] <BtbN> but passing it through that is what doesn't work.
[23:18:02 CEST] <BtbN> it's in an ifndev V block
[23:18:07 CEST] <BtbN> *def
[23:18:23 CEST] <nevcairiel> It would show a difference in the bash -v thing then though
[23:19:51 CEST] <BtbN> anyway, the stuff I wanted to test works fine and generally compiles.
[23:21:00 CEST] <cone-023> ffmpeg 03Timo Rothenpieler 07master:f0ea96d8a2c9: avcodec/cuvid: use actual frame size for buffer allocation
[23:21:00 CEST] <cone-023> ffmpeg 03Timo Rothenpieler 07master:49511501aa06: avcodec/cuvid: support a pre-initialized hw_frames_ctx
[23:21:00 CEST] <cone-023> ffmpeg 03Timo Rothenpieler 07master:ba0e5165331d: avcodec/cuvid: make use of new av_hwdevice_ctx_create api
[23:21:00 CEST] <cone-023> ffmpeg 03Timo Rothenpieler 07master:97e7f03d356b: avutil/hwcontext_cuda: use proper synchronization flag
[23:28:04 CEST] <rcombs> nevcairiel: unless it's the split on the way into bash where the issue's occurring
[00:00:00 CEST] --- Fri Sep 30 2016