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

[burek]

[16:33:18 CEST] <Jestin> Hey! Is it possible to create a scheduled livestream with FFmpeg thast plays a video at certain times/
[16:45:57 CEST] <thardin> that sounds more like an OBS question
[16:46:10 CEST] <thardin> or some other similar software
[16:49:19 CEST] <philipl> BtbN: so those nvenc hdr metadata patches went nowhere?
[17:26:19 CEST] <BtbN> nope
[17:26:45 CEST] <BtbN> I'm very much against merging that code into nvenc. And nobody seems to have felt the need to implement them as a (bitstream)filter
[17:27:00 CEST] <BtbN> philipl, ^
[19:21:55 CEST] <philipl> BtbN: so how would a bitstream filter work. I assume that from an nvenc perspective, you want to pull the metadata as side-data? and the filter's job is to add the sidedata?
[19:22:20 CEST] <BtbN> Pretty much, yes
[19:22:58 CEST] <philipl> and if it's a transcode, there should be a way to pass it all the way through, and for a raw encoding, the filter would take the command line parameters?
[19:23:37 CEST] <philipl> I want to say we already have hdr sidedata defined. nvenc could consume that today if so.
[19:25:57 CEST] <philipl> AV_FRAME_DATA_DYNAMIC_HDR_PLUS?
[19:26:42 CEST] <JEEB> that's the dynamic one (HDR10+)
[19:27:53 CEST] <philipl> For static, what do we do?
[19:28:24 CEST] <JEEB> there's two things I think. there's the brightness stuff and the mastering screen stuff
[19:28:35 CEST] <philipl> Ok, I thought it might be.
[19:28:35 CEST] <JEEB> time to boot up my development VM :)
[19:28:53 CEST] <JEEB> we have support for the static metadata on the decoder side so checking the HEVC decoder/parser probably would be simplest?
[19:29:24 CEST] <philipl> yeah
[19:33:04 CEST] <philipl> vaapi_encode_h265 already pulls it in, so we can follow that as an example.
[19:33:19 CEST] <jamrial> philipl: look how the h264_metadata bsf inserts display_orientation sei messages
[19:33:37 CEST] <philipl> but yeah, the point is we should add support to nvenc to use the side data and then worry about how a bsf can inject hdr metadata
[19:33:38 CEST] <jamrial> you could do the same for the hdr sei messages in h265_metadata bsf
[19:33:49 CEST] <jamrial> ok
[19:38:29 CEST] <philipl> BtbN: so the guy's change handles side data. That half of the change we could take?
[19:39:01 CEST] <BtbN> I don't think it does. It put all the extraction logic and parameters into nvenc.
[19:39:21 CEST] <BtbN> Patch 1/3 just changed the structure a bit, to generally support multiple SEI parameters.
[19:40:51 CEST] <philipl> So if I read it right, he adds a bunch of fields to nvenccontext and uses those for the encoder param stuff.
[19:41:00 CEST] <philipl> he also reads the side data. Sets it into the fields, and then writes the sei.
[19:41:14 CEST] <philipl> Presumably you'd remove the fields and just copy the side data directly into the sei
[19:43:10 CEST] <philipl> Maybe you still want the command line params that indicate which SEIs to include? Or we just say that if the side data exists, we use it.
[19:44:57 CEST] <BtbN> There probably should be an option to ignore side data, as there is for ac53cc
[20:29:01 CEST] <mkver> Does anybody have a recent version of ISO/IEC 14496-15 (that's the specification how H.264/HEVC should be put into mp4)?
[20:29:42 CEST] <JEEB> I only have the one that I utilized to write the HEVC-in-Matroska draft
[20:30:07 CEST] <JEEB> I really have no idea why 14496-15 is not free while both 14496-12 and HEVC are :P
[20:30:14 CEST] <JEEB> (same for 14496-10)
[20:31:25 CEST] <mkver> You mean this thing that someone (maybe you?) once posted on the Matroska developer mailing list? I already got that.
[20:32:01 CEST] <JEEB> https://lists.matroska.org/pipermail/matroska-devel/2013-September/004567.html
[20:32:04 CEST] <JEEB> yea, this is me :P
[20:32:55 CEST] <mkver> Then thanks for providing this to us, including me.
[20:33:07 CEST] <mkver> Where did you get it in the first place?
[20:33:37 CEST] <JEEB> they had their WIP documents available
[20:33:38 CEST] <JEEB> > Incheon output document W13478
[20:33:54 CEST] <JEEB> Incheon meeting, and the Wxxxx is the working group document ID
[20:34:52 CEST] <mkver> I was actually interested into whether the VisualSampleEntry's width and height really refer to frames and not to fields even for HEVC or whether they changed that eventually.
[20:35:30 CEST] <JEEB> I'm still on the mp4-sys mailing list so let's see if they have anything linked there
[20:35:40 CEST] <mkver> In my experience their WIP documents are always .doc/.docx files, not pdf. But never mind.
[20:36:30 CEST] <JEEB> yes. I just used a PDF printer from office
[20:37:49 CEST] <JEEB> seems like 14496-15 5th ed was in FDIS since Jan-19
[20:37:52 CEST] <JEEB> document ID 18241
[20:39:31 CEST] <JEEB> https://sd.iso.org/projects/project/74429/overview
[20:39:39 CEST] <JEEB> so they've moved to a "secure" document storage :P
[20:39:45 CEST] <JEEB> so you no longer can spy as much
[20:40:36 CEST] <mkver> Does this mean that one could have easily downloaded this freely before Jan-19?
[20:40:41 CEST] <JEEB> no
[20:40:46 CEST] <JEEB> they moved a year or two ago
[20:43:33 CEST] <mkver> Ok. Btw: mkvmerge already uses the frame-dimensions for HEVC (https://gitlab.com/mbunkus/mkvtoolnix/issues/2446).
[20:45:06 CEST] <JEEB> found what probably became 5th ed?
[20:45:07 CEST] <JEEB> w16169 4th ed + 16787C1+16938C2+16490A1+17993A2.docx
[20:45:29 CEST] <JEEB> from end of jan
[20:48:13 CEST] <kurosu> I'm still using mkvtoolnix 8.3, even for hevc... Not happy with the UI afterwards *lame*
[20:49:10 CEST] <mkver> Link doesn't work/is too smart for me.
[20:51:47 CEST] <mkver> That's what I initially thought, too, but nowadays, when using old versions looking for whether a bug is a regression or not, it's the complete opposite. Probably just getting used to it.
[20:52:00 CEST] <jamrial> kurosu: mkvmerge got a crapload of fixes since that version, including for hevc afaik
[20:52:22 CEST] <kurosu> yeah, that's why I'm saying I'm lame
[20:52:42 CEST] <kurosu> though it never really impacted me, apparently
[20:52:48 CEST] <mkver> Yep. And H.264, too. E.g. changing extradata could result in problems in older versions.
[20:53:35 CEST] <JEEB> mkver: try http://fushizen.eu/random/w16169_4th_ed_+_16787C1+16938C2+16490A1+17993A2.pdf
[20:53:41 CEST] <JEEB> that's the last thing I found on the mailing list :P
[20:55:37 CEST] <mkver> Thanks.
[21:02:22 CEST] <mkver> The rules for VisualSampleEntry's width and height are more complicated in this version, but the dimensions still apply to frames, not fields. Good to know.
[00:00:00 CEST] --- Wed Jun 12 2019