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

[burek]

[00:04:47 CEST] <BtbN> hm, yeah. This timestamp interpolation is going to barf on itself when the timebase has the dts/pts increment by one per frame.
[00:26:43 CEST] <BtbN> Yeah, that's exactly what's happening. I guess I can't modify the timebase from within an encoder?
[00:27:18 CEST] <nevcairiel> technically you might get away with that, but its probably not quite nice
[00:27:47 CEST] <BtbN> Not sure what else to do. The alternative is to just disable support for interlaced encoding.
[00:28:33 CEST] <BtbN> "Most notably, H.264 and MPEG-2 specify time_base as half of frame duration" from avcodec.h
[00:28:43 CEST] <BtbN> Why is my timebase 100/2997 then?
[00:28:59 CEST] <BtbN> should be 100/5994
[00:30:44 CEST] <jkqxz> What is the timebase if you encode libx264?
[00:30:59 CEST] <BtbN> That the timebase the encoder init function gets passed
[00:31:03 CEST] <BtbN> So I suppose the same?
[00:31:05 CEST] <jkqxz> (Where would 100/2997 even come from anyway?  Is that 1001/30000 with some weird rounding applied?)
[00:31:14 CEST] <BtbN> From the input file
[00:31:19 CEST] <iive> yes
[00:31:53 CEST] <BtbN> I like how nvenc sees that, and goes "nope" on it, and writes 1001/60000 into the SPS
[00:32:09 CEST] <jkqxz> Shouldn't libx264 going to have exactly the same problem, then?  Since it presumably works, maybe look at that.
[00:32:23 CEST] <nevcairiel> x264 encodes mbaff, which doesnt have that particular issue
[00:32:25 CEST] <BtbN> libx264 does not use field mode interlacing
[00:33:17 CEST] <jkqxz> Huh, oh.  MPEG-2 then?
[00:33:34 CEST] <BtbN> no?
[00:33:48 CEST] <BtbN> It just encodes the two fields as seperate pictures
[00:34:27 CEST] <BtbN> NV_ENC_CAPS_SUPPORT_FIELD_ENCODING can also output: 2 : Interlaced frame encoding and field mode encoding are both supported.
[00:34:31 CEST] <BtbN> Which would be MBAFF
[00:34:49 CEST] <BtbN> So far I have yet to see a card/driver where mode 2 is supported
[00:35:01 CEST] <BtbN> But I could just bump it to 2, set interlace mode to MBAFF, and be done with it...
[00:35:41 CEST] <jkqxz> Wouldn't the two separate pictures in MPEG-2 need the 60000/1001fps timestamps, though?
[00:36:05 CEST] <BtbN> No idea where you are getting mpeg-2 from
[00:36:26 CEST] <nevcairiel> "another codec that has interlaced fields"
[00:36:38 CEST] <jkqxz> And which doesn't have frame coding of interlaced fields.
[00:37:51 CEST] <BtbN> They would, probably
[00:38:06 CEST] <BtbN> But I'm not sure if the mpeg-2 encoder even supports interlaced encoding to begin with
[00:38:13 CEST] <nevcairiel> it does
[00:38:32 CEST] <iive> software mpeg2 encoder does support interlace
[00:38:50 CEST] <BtbN> I really wonder why ticks_per_frame is 1 for this. The input and output is h264. It really should be 2.
[00:40:42 CEST] <nevcairiel> probably because noone sets it? :p
[00:40:42 CEST] <BtbN> h264_decode_init hard-sets it to 2.
[00:43:06 CEST] <BtbN> This almose needs a new encoder capability
[00:43:20 CEST] <BtbN> that signals that ticks_per_frame has to be >1
[00:51:02 CEST] <kierank> eh?
[00:51:09 CEST] <kierank> ffmpeg doesn't support field encoding
[00:51:12 CEST] <kierank> it's irrelevant
[00:51:19 CEST] <kierank> just normalise
[00:51:27 CEST] <BtbN> hm?
[00:51:38 CEST] <BtbN> How would it not support it?
[00:51:48 CEST] <kierank> ffmpeg doesn't have a concept of a field picture alone
[00:51:58 CEST] <kierank> it has two fields and you encode each separately
[00:52:11 CEST] <BtbN> nvenc handles that internally
[00:52:20 CEST] <BtbN> you give it a normal interleaved frame. And two pictures come out
[00:52:26 CEST] <kierank> so timebase is in frames per second
[00:52:30 CEST] <kierank> so it should double internally
[00:52:36 CEST] <kierank> like x264
[00:52:46 CEST] <BtbN> it does. The timebase it writes into the sps is doubled
[00:52:58 CEST] <kierank> so this is not a bug
[00:53:11 CEST] <BtbN> It is, because the container timestamps are not doubled
[00:53:16 CEST] <BtbN> And I don't see a way to achive that
[00:53:32 CEST] <kierank> yadif and similar do the same
[00:53:41 CEST] <kierank> so the encoder needs to double the timebase
[00:53:42 CEST] <BtbN> filters can modify the time_base though
[00:53:48 CEST] <BtbN> encoders can't
[00:54:06 CEST] <kierank> then the encoder can just output both fields as NALs concatenated or something
[00:54:13 CEST] <kierank> would break vfr but who cares about interlaced vfr
[00:54:19 CEST] <BtbN> That results in broken files that skip every second field in playback
[00:54:29 CEST] <BtbN> that's how it works right now
[00:54:44 CEST] <kierank> probably violates some container specs, true
[00:54:50 CEST] <kierank> about one AU per packet
[00:55:35 CEST] <BtbN> wonder what happens if I just set every other pts/dts to NOPTS
[00:59:37 CEST] <BtbN> at least no errors anymore
[00:59:45 CEST] <BBB> jya: yes, vp8 can have alpha channel
[00:59:51 CEST] <BBB> jya: it works same as vp9 with alpha
[01:00:09 CEST] <BtbN> I can't decipher the mpeg* encoder though. It does support interlaced encoding for mpeg2. No idea how it solves that particular problem though.
[01:02:03 CEST] <BtbN> "Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly"
[01:02:16 CEST] <BtbN> it works, but it's unhappy about it
[01:02:50 CEST] <JEEB> yea, I kind of wonder if both AVFrames and AVPackets should have the time base on them as well
[01:03:32 CEST] <JEEB> that way you could just use the frame/packet and rescale the timestamps according to your following component and off you go
[01:03:57 CEST] <BtbN> time_base + ticks_per_frame
[01:04:06 CEST] <BtbN> or just the timebase I suppose is enough
[01:04:22 CEST] <JEEB> having a duration is of course also nice
[01:04:42 CEST] <BtbN> They do have a duration
[01:04:44 CEST] <JEEB> but having the time_base would help tremendously
[01:04:49 CEST] <JEEB> yea, packets do
[01:05:09 CEST] <BtbN> If the packets had their own time_base, that would eliminate that problem.
[01:05:19 CEST] <JEEB> yup
[01:05:22 CEST] <BtbN> The encoder could just multiply the output timebase
[01:05:48 CEST] <JEEB> yup
[01:06:47 CEST] <BtbN> That would be quite an API break though, hm
[01:06:52 CEST] <JEEB> yup
[01:07:12 CEST] <JEEB> but personally it does make sense to have AVFrames and AVPackets contain their own time_base
[01:07:21 CEST] <JEEB> so you don't have to remember where you just got that thing from
[01:07:32 CEST] <JEEB> was it your demuxer, decoder, filter chain or encoder
[01:08:00 CEST] <BtbN> what confuses me right now is, that if I just halve the time_base in the encoder init
[01:08:09 CEST] <BtbN> the encoder suddenly gets double the amount of frames as input?!
[01:08:15 CEST] <BtbN> From the same input file
[01:08:26 CEST] <BtbN> So they are still incremented by 1
[01:09:02 CEST] <BtbN> something must decide that it has to duplicate frames
[01:13:39 CEST] <BtbN> For now, the best bet is to just NOPTS if interlaced
[01:14:01 CEST] <JEEB> not nice, but if the rest of the framework handles that...
[01:22:58 CEST] <BtbN> The muxer uses a way larger timebase
[01:23:07 CEST] <BtbN> so it can easily make up intermediate timestamps
[01:23:11 CEST] <atomnuker> jkqxz: awesome patchset, this will be useful
[01:23:48 CEST] <atomnuker> right now you can't capture stuff on wayland well
[01:24:08 CEST] <jkqxz> Does it work on Wayland?  I didn't try there at all.
[01:24:47 CEST] <atomnuker> it probably does if it can capture VTs
[01:27:33 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/1b24471c0c5b59dd0529a586b1b957d4e3ec28e9 that's what I came up with.
[01:27:46 CEST] <BtbN> Everything looks reasonably to me. Except for the time_base things
[09:56:58 CEST] <cone-859> ffmpeg 03Clément BSsch 07master:b4b1285fa1b6: lavd: drop disabled v4l code
[11:31:14 CEST] <LongChair> could anyone help me to gigure out something. I am working on an hwdec that uses a Lib being Apache 2. hence if --enable-gpl is used it should also fail if --enable-version3 is not specified.
[11:33:15 CEST] <LongChair> if i add the hwdec to EXTERNAL_LIBRARY_VERSION3_LIST it will work properly with --enable-gpl & --enable-version3
[11:33:30 CEST] <LongChair> but it won't allow to build it without --enable-gpl 
[11:33:30 CEST] <BtbN> I don't think that constraint is neccesary
[11:34:13 CEST] <LongChair> i'm not familiar with licensing stuff, that but i got that comment in the ML on my patch 
[11:34:42 CEST] <BtbN> LGPL is rather relaxed in terms of linking against external stuff.
[11:35:28 CEST] <LongChair> possibly, i really don't have a clue :)
[11:35:30 CEST] <BtbN> And I think the GPL2 incompatiblity with Apache2.0 is only for including code?
[11:35:42 CEST] <BtbN> Linking should still be fine. But not a licensing expert either
[11:36:16 CEST] <nevcairiel> linking and including are the same to gpl, afaik
[11:37:07 CEST] <LongChair> Anyways, i'd like it to be working both with --enable-gpl and --enable-version3, but adding it to EXTERNAL_LIBRARY_VERSION3_LIST will not allow to build it even without -enable-gpl 
[11:37:33 CEST] <LongChair> anyone would have a clue on what's required to get both cases work properly ? 
[11:38:08 CEST] <BtbN> I don't think that case exists yet
[11:39:20 CEST] <LongChair> i tried to add it to both EXTERNAL_LIBRARY_VERSION3_LIST and HWACCEL_LIBRARY_LIST, but that still fails with "rkmpp is version3 and --enable-version3 is not specified."
[11:40:44 CEST] <BtbN> well, it's not wrong?
[11:41:21 CEST] <BtbN> you need either an lgpl build, a nonfree build, or a build with gpl3
[11:41:31 CEST] <BtbN> the only case that fails is a gpl2 build
[11:46:05 CEST] <kurosu> jkqxz, btw, tested your h264_metadata cbs for editing wonky streams (ts->mkv + cutting and weird encoding): obviously worked
[11:46:05 CEST] <LongChair> our build doesn't have any specific flags aside --disable-version3 
[11:46:17 CEST] <LongChair> so that would be a gpl2 build ? 
[11:47:03 CEST] <kurosu> jkqxz, I had 1 or 2 streams with multiple sps (afaik, or stream so damaged that wrong detection), some of them damaged apparently
[11:47:30 CEST] <kurosu> consequently, some errors printed, but before the editing, and after, the files were still playing correctly
[11:51:20 CEST] <BtbN> the default is lgpl2 I think.
[11:53:16 CEST] <LongChair> and that is not compatible with Apache 2 ? 
[12:00:42 CEST] <BtbN> Pretty sure LGPL is fine with linking to whatever
[13:04:58 CEST] <cone-859> ffmpeg 03Leo Izen 07master:dda1c23c20d7: doc/filters.texi: Add default values to vf_vaguedenoiser options
[13:20:24 CEST] <cone-859> ffmpeg 03Paul B Mahol 07master:f19e4118e9ca: avfilter/vf_subtitles: enable processing of alpha channel
[13:39:41 CEST] <cone-859> ffmpeg 03Paul B Mahol 07master:06ed3768c88c: avfilter/vf_displace: remove useless requirement that SAR matches between input streams
[13:51:08 CEST] <BBB> ubitux: any ideas on how to debug the avfoundation_indev -> avfoundation entry? Do I need to debug enabled and figure out why it returns true? Or is this a known/expected thing?
[13:51:43 CEST] <BBB> ubitux: the issue I have is that with avfoundation_indev_deps=avfoundation; enabled avfoundation is false, but enabled avfoundation_indev is true (which to me seems wrong and unexpected, but maybe Im stupid)
[13:54:13 CEST] <BBB> ubitux: where / how are dependencies like that resolved? I see functions like check_deps but Im deep in stuff I dont understand here
[13:56:21 CEST] <ubitux> BBB: careful with the states, it's not only enabled vs disabled
[13:56:25 CEST] <ubitux> you also have "unset"
[13:56:37 CEST] <ubitux> so ! enabled doesn't mean disabled
[13:56:43 CEST] <BBB> is it possible check_deps isnt called on avfoundation because its not in any list?
[13:56:53 CEST] <BBB> like the lists on top, hw_list, ext_lib_list, etc.
[13:56:56 CEST] <ubitux> for debug, you can check a the config.log, or maybe sh -x ./configure
[13:57:24 CEST] <ubitux> check_deps is indeed what's call to solve the tree
[13:57:32 CEST] <ubitux> it happens around the end of the script
[13:57:58 CEST] <ubitux> BBB: yeah, might be
[13:59:09 CEST] <BBB> thats easy to test
[13:59:12 CEST] <BBB> hackyhack
[13:59:22 CEST] <BBB> I dont know which list to add avfoundation_indev to or where it should be
[13:59:32 CEST] <BBB> I thought all components were automatically added by parsing the relevant lists?
[14:01:18 CEST] <BBB> is the issue check_deps is run after the check for coregraphics?
[14:02:59 CEST] <BBB> or is the issue that checklib <component> bla bla should add LIBS to <component>_extralibs instead of the global EXTRALIBS? depending on whether the component is finally enabled?
[14:06:44 CEST] <BBB> check_deps already includes the check but is evaluated too late
[14:06:53 CEST] <BBB> the coregraphics check is done before check_deps
[14:06:54 CEST] <BBB> so...
[14:07:05 CEST] <BBB> we need to make sure the etxralibs isnt updated until the component is strictly enabled, or so
[14:07:12 CEST] <ubitux> avfoundation_indev is not supposed to be in a list
[14:07:13 CEST] <BBB> and I would expect check_lib <comp> to do that already
[14:07:14 CEST] <BBB> but thats failing
[14:07:18 CEST] <ubitux> avfoundation should be though
[14:07:33 CEST] <BBB> avfoundation is in the list of autodetect disable thingies
[14:10:01 CEST] <ubitux> speaking of extralibs, i'm confused at why they are set like this
[14:10:13 CEST] <ubitux> typically, when a check_lib succeed, the extralibs are added
[14:10:17 CEST] <ubitux> otherwise they aren't
[14:10:25 CEST] <ubitux> maybe i'm missing something though
[14:10:29 CEST] <ubitux> i have to go
[14:10:31 CEST] <ubitux> bbl
[14:10:46 CEST] <ubitux> ah!
[14:10:48 CEST] <ubitux> i know
[14:10:56 CEST] <ubitux> BBB: check the "requested" list
[14:11:10 CEST] <ubitux> requesting a lib removes its enable/disable state
[14:11:30 CEST] <ubitux> though, i think i'm doing an enable weak after that
[14:11:38 CEST] <ubitux> make sure it's in those list.
[14:11:49 CEST] <ubitux> anyway, bbl
[14:19:44 CEST] <cone-859> ffmpeg 03Paul B Mahol 07master:e6e58de03d60: avfilter/vf_displace: add mirror edge mode
[14:21:29 CEST] <BBB> requested
[14:21:29 CEST] <BBB> aha
[14:21:35 CEST] <BBB> is that for avfoundation or avfoundation_indev?
[14:21:51 CEST] <ubitux> avfoundation
[14:22:09 CEST] <ubitux> every enabled thing by the user becomes "requested"
[14:22:22 CEST] <ubitux> so that if it's not found, it errors out
[14:22:38 CEST] <ubitux> it's what i called "the damned fourth state"
[14:47:22 CEST] <BBB> ubitux: I dont think I understand, sorry
[14:47:31 CEST] <BBB> I dont know what the requested list is
[14:47:50 CEST] <BBB> if its EXTERNAL_AUTODETECT_LIBRARY_LIST, then yes, avfoundation is in there
[14:52:27 CEST] <BBB> ubitux: going from what other extlibs are doing, I think Ill just change enabled avfoundation_indev to enabled avfoundation, that should fix it
[14:52:34 CEST] <BBB> its just something thats not possible yet
[14:53:53 CEST] <BBB> https://pastebin.com/5GS1YJ5H
[15:09:49 CEST] <ubitux> "enabled videotoolbox && check_lib coreservices" mmh
[16:02:02 CEST] <BBB> ubitux: otherwise coreservices is enabled by default, which we obviously dont want
[16:02:09 CEST] <BBB> ubitux: and the only user is ffmpeg_videotoolbox.c
[16:02:13 CEST] <BBB> ubitux: so it seemed appropriate
[16:05:29 CEST] <BBB> and otool -L shows no dependencies other than basic system stuff now, so it seems to work
[20:08:07 CEST] <cone-446> ffmpeg 03Paul B Mahol 07master:05b1c606870c: doc/filters: add one more blend example
[20:08:07 CEST] <cone-446> ffmpeg 03Paul B Mahol 07master:8b193e553055: doc/filters: add missing '' for blend example
[20:43:50 CEST] <cone-446> ffmpeg 03Paul B Mahol 07master:f3c0f34f53c2: avfilter/vf_datascope: add timeline support to pixscope and oscilloscope
[20:52:49 CEST] <durandal_1707> just merge all the libs once for all
[23:39:17 CEST] <guest> Hello all. I'd like to suggest that the default flac compression level be set to its maximum possible value, 12. This has always been the right trade-off of space and time for me.
[23:40:04 CEST] <atomnuker> send a patch
[23:42:15 CEST] <guest> I'll do that if I must, but I'd prefer to avoid it because it would be a lot of hassle for me to get set-up in order to make this small change.
[00:00:00 CEST] --- Mon Sep  4 2017