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

[burek]

[01:36:49 CEST] <klaxa> mmmh, only thing that is left before i implemented all the suggestions is making the save-segment function accept anything for a filename and write the file accordingly
[01:38:55 CEST] <klaxa> hmm... even though this shouldn't be hard, i can't wrap my head around it right now, maybe tomorrow after some sleep :S
[06:41:03 CEST] <wm4> klaxa: I think the idea is just replacing FILE with avio?
[08:36:44 CEST] <cone-097> ffmpeg 03Steven Liu 07master:783df2eb59ca: avformat/hlsenc: avformat/hlsenc: add error message for encrypt fmp4 mode
[09:33:07 CEST] <cone-097> ffmpeg 03Paul B Mahol 07master:e1c8bd2389d6: avfilter/af_headphone: fix type=time with hrir=multich
[09:37:50 CEST] <klaxa> wm4: huh, right... i might have overcomplicated this
[11:29:55 CEST] <durandal_1707> why scte-35 was not merge? I gonna merge it ASAP!
[11:36:20 CEST] <cone-097> ffmpeg 03Martin Vignali 07master:cb2f52b6a709: avfilter/showvolume : add display scale option
[11:36:21 CEST] <cone-097> ffmpeg 03Martin Vignali 07master:fd10a6e2f21f: avfilter/showvolume : add persistent max display
[11:36:22 CEST] <cone-097> ffmpeg 03Martin Vignali 07master:56315df32c48: avfilter/showvolume : cosmetic move bracket after func declaration to a new line
[12:38:12 CEST] <cone-097> ffmpeg 03Michael Niedermayer 07master:e8be46dfe059: doc/APIchanges: Fill in missing stuff
[12:38:13 CEST] <cone-097> ffmpeg 03Michael Niedermayer 07master:1b7b7c6a6222: doc/APIchanges: Add 4.0 cut point
[12:38:14 CEST] <cone-097> ffmpeg 03Michael Niedermayer 07master:7e3a070d9aac: Bump minor versions for branching release/4.0
[12:38:15 CEST] <cone-097> ffmpeg 03Michael Niedermayer 07master:3c1ecb057d76: Bump minor versions after release/4.0 branching
[13:21:52 CEST] <cone-097> ffmpeg 03Michael Niedermayer 07release/4.0:HEAD: Bump minor versions after release/4.0 branching
[14:09:34 CEST] <mustafam> Hi all, sorry to ask this here but I got no answers on #ffmpeg
[14:09:40 CEST] <mustafam> Is there a recommended way to convert bt2020 to bt709? colormatrix, colorspace, zscale, or something else?
[14:18:45 CEST] <durandal_1707> mustafam: zscale, never use colormatrix 
[14:20:12 CEST] <atomnuker> mustafam: he's trolling, vf_colorspace is perfect
[14:21:13 CEST] <TheAMM> Which one do I shoot?!
[14:21:54 CEST] <durandal_1707> atomnuker: you're blind
[14:22:52 CEST] <nevcairiel> we have way too many of those filters, vf_colormatrix should be deprecated and deleted
[14:23:01 CEST] <nevcairiel> colorspace does all it does just better
[14:23:05 CEST] <atomnuker> indeed
[14:23:25 CEST] <atomnuker> durandal_1707: you're sure you're not confusing colorspace with colormatrix?
[14:23:55 CEST] <nevcairiel> why would he, he said to never use colormatrix, which is the truth
[14:25:02 CEST] <mustafam> The problem is that colorspace does not support my input
[14:25:22 CEST] <mustafam> "Unsupported input transfer characteristics 16 (smpte2084)"
[14:26:21 CEST] <nevcairiel> thats because your input is not just bt2020, but also HDR
[14:27:12 CEST] <nevcairiel> zscale may support that, i guess
[14:27:43 CEST] <mustafam> It does support it, but colors become oversaturated
[14:28:11 CEST] <nevcairiel> converting HDR to SDR is more of an art then anything, there is universal answer to that
[14:28:19 CEST] <nevcairiel> no universal answer*
[14:28:45 CEST] <mustafam> So parameters should be tuned for each video?
[14:29:17 CEST] <nevcairiel> you can probably find some that work ok-ish for most of them
[14:31:14 CEST] <mustafam> Thanks a lot, everybody, will try to find the best parameters to use with zscale.
[15:48:04 CEST] <cone-097> ffmpeg 03James Almer 07master:c04609eefce0: configure: extend the check for bcrypt
[15:48:05 CEST] <cone-097> ffmpeg 03James Almer 07master:62bdbb5ce0c5: avformat/movenc: forbid muxing AV1 streams until the spec is finished
[15:51:43 CEST] <cone-097> ffmpeg 03James Almer 07release/4.0:b6ec18124035: configure: extend the check for bcrypt
[15:51:44 CEST] <cone-097> ffmpeg 03James Almer 07release/4.0:6c95a26c1a5f: avformat/movenc: forbid muxing AV1 streams until the spec is finished
[18:45:09 CEST] <cone-097> ffmpeg 03Paul B Mahol 07master:9cf0079638e1: avfilter/af_headphone: switch to activate
[18:53:58 CEST] <cone-097> ffmpeg 03Rodger Combs 07master:00d8598eba2e: avformat/flacenc: support writing attached pictures
[18:53:59 CEST] <cone-097> ffmpeg 03James Almer 07master:6838359448fa: avformat/flacenc: add flac_init()
[19:13:20 CEST] <cone-097> ffmpeg 03Paul B Mahol 07master:6e05a11e8968: avfilter/af_afir: make max IR length configurable
[19:13:58 CEST] <cone-097> ffmpeg 03Rodger Combs 07release/4.0:9ef90ff0a2bf: avformat/flacenc: support writing attached pictures
[19:13:59 CEST] <cone-097> ffmpeg 03James Almer 07release/4.0:7e11a861755d: avformat/flacenc: add flac_init()
[19:25:51 CEST] <cone-097> ffmpeg 03Michael Niedermayer 07master:ec8a5262b03f: doc/APIchanges: Fix typos in hashes
[19:26:27 CEST] <atomnuker> jamrial: awesome, thanks
[22:36:16 CEST] <cone-578> ffmpeg 03Timo Rothenpieler 07master:b3b3a3e3ce1d: configure: add nvcc to CMDLINE_SET
[22:36:43 CEST] <klaxa> grml... so i got the segment_save() thing done with avio stuff, but the files are not exactly what i expected, albeit the streaming works without problems
[22:37:08 CEST] <klaxa> each segment seems to be cut off too early during playback with mpv at least
[22:37:13 CEST] <durandal_1707> ffmpeg -i input -i fl.wav -i fr.wav -i fc.wav -i lfe.wav -i sl.wav -i sr.wav -lavfi 
[22:37:16 CEST] <durandal_1707> "[0:a]asplit=6[fl][fr][fc][lfe][sl][sr],[fl]pan=stereo|c0=c0|c1=c0,aformat=channel_layouts=stereo[fl],[fr]pan=stereo|c0=c1|c1=c1[fr],[fc]pan=stereo|c0=c2|c1=c2[fc],[lfe]pan=stereo|c0=c3|c1=c3[lfe],[sl]pan=stereo|c0=c4|c1=c4[sl],[sr]pan=stereo|c0=c5|c1=c5[sr],[fl][1:a]afir=again=0,aformat=channel_layouts=stereo[fl],[fr][2:a]afir=again=0,aformat=channel_layouts=stereo[fr],[fc][3:a]afir=again=0,af
[22:37:17 CEST] <cone-578> ffmpeg 03Timo Rothenpieler 07release/4.0:9c787a21ce91: configure: add nvcc to CMDLINE_SET
[22:37:22 CEST] <durandal_1707> ormat=channel_layouts=stereo[fc],[lfe][4:a]afir=again=0,aformat=channel_layouts=stereo[lfe],[sl][5:a]afir=again=0,aformat=channel_layouts=stereo[sl],[sr][6:a]afir=again=0,aformat=channel_layouts=stereo:sample_fmts=fltp[sr],[fl][fr][fc][lfe][sl][sr]amerge=6,pan=stereo|c0=c0+c2+c4+c6+c8+c10|c1=c1+c3+c5+c7+c9+c11,volume=-10dB" ----> guess what this do!
[22:38:05 CEST] <klaxa> looks like magic downmixing
[22:38:28 CEST] <cone-578> ffmpeg 03Timo Rothenpieler 07release/3.4:4faa01f20c17: configure: add nvcc to CMDLINE_SET
[22:45:12 CEST] <BtbN> Nobody seems to ever have used that option
[22:48:52 CEST] <durandal_1707> which option?
[22:50:22 CEST] <BtbN> --nvcc
[22:51:17 CEST] <jamrial> BtbN: i don't think a lot of people use the cuda sdk considering you made the hwaccel and the encoder work without it
[23:00:15 CEST] <jamrial> jkqxz: https://github.com/jamrial/FFmpeg/commits/av1_parse PoC for a fast and simple av1 AVCodecParser using the packet split api i wrote the other day, to set profile, pix_fmt, keyframe, and pict_type/structure
[23:01:39 CEST] <jamrial> i'm not sure i'm handling show_existing_frame and seen_frame_header right, tbh
[23:01:41 CEST] <jamrial> the former sort of expects to keep track of reference frames
[23:04:42 CEST] <BtbN> and even the ones that do under normal circumstances don't ever have to touch that option
[23:06:28 CEST] <jamrial> i guess BBB already wrote a better one in any case, seeing lavf apparently does't let you remux av1 out of ivf onto something else without a parser, so any kind of serious testing would need one
[23:06:56 CEST] <BBB> huh what?
[23:07:17 CEST] <BBB> what option?
[23:07:38 CEST] <BBB> show_existing_frame?
[23:07:40 CEST] <BBB> oh god
[23:07:47 CEST] <BBB> please dont release software that doesnt support that
[23:07:54 CEST] <jamrial> BBB: BtbN is talkign about nvidia stuff, no :p
[23:07:57 CEST] <BBB> youre breaking my heart and the whole ecosystem along with it
[23:09:29 CEST] <jamrial> BBB: hence the above being a PoC written just to test the packet split api i wrote. i'm sure it's not handling show_existing_frame right
[23:11:45 CEST] <jamrial> a parser is needed in any case before a native decoder lands. as i said, remuxing from ivf seems to not work without one
[23:12:35 CEST] <nevcairiel> what sort of weird format does it store it in ivf that you need parsing anyway
[23:12:48 CEST] <nevcairiel> get rid of different bitstreams plx
[23:12:58 CEST] <jamrial> it's not that
[23:13:15 CEST] <jamrial> it just doesn't output anything when you try to codec copy
[23:13:53 CEST] <jamrial> i'm leaning towards something going wrong in lavf/utils.c
[23:14:45 CEST] <jamrial> ivf in any case doesn't store any container level flags like keyframe or such on packets, like matroska does, so the parser is needed to set that
[23:15:47 CEST] <jkqxz> -copyinkf
[23:16:07 CEST] <jkqxz> (To get output when using codec copy.)
[23:19:15 CEST] <nevcairiel> that sounds like an odd option
[23:20:25 CEST] <jkqxz> It's pretty common to need it on raw streams or fragments.
[23:20:30 CEST] <jamrial> jkqxz: seems to allow codec copy out of ivf, but it makes packets that should be keyframes lack that flag, since ivf just doesn't carry it in any form
[23:20:59 CEST] <jamrial> so many obscure yet useful options, heh
[23:21:10 CEST] <BtbN> wouldn't that mean that the ivf demuxer needs knowledge about every single codec that can be in it, to fill those gaps?
[23:21:20 CEST] <jkqxz> Well, yeah.  It lets you feed ivf files into bsfs at least.  (Which is why I knew it was needed here...)
[23:21:42 CEST] <nevcairiel> why does ffmpeg need keyframe info to copy anything
[23:21:54 CEST] <nevcairiel> sounds like another of those dumb decisions someone took 10 years ago
[23:22:22 CEST] <iive> ?
[23:22:30 CEST] <jkqxz> Because someone thought it was a good idea to discard all packets before the first one marked as a keyframe.
[23:23:23 CEST] <jamrial> BtbN: ivf is a dumb container for On2/Google codecs. the header has some basic stream information, and each raw packet is preceded by a size and pts values
[23:23:46 CEST] <jamrial> so any other stream/frame information needs to be taken from the bitstream
[23:24:48 CEST] <BtbN> jkqxz, can't it just blindly mark the first packet of each stream as key?
[23:25:29 CEST] <jamrial> it's not really meant to be used outside of testing/development, and was made probably because vp8 didn't have a h264-like annexb raw bitstream form
[23:27:07 CEST] <jkqxz> BtbN:  Because that would be unhelpful if the first packet isn't a keyframe, but there are keyframes later in the stream.  (Consider MPEG-TS fragments, say.)
[23:47:09 CEST] <jamrial> jkqxz: but yeah, that's more or less what i had in mind when i wrote the packet split api
[23:47:17 CEST] <jamrial> using it for simple modules that don't require to dig too deep into the bitstream, and also to simplify cbs_av1's split_fragment()
[23:47:31 CEST] <jamrial> cbs would then be used for more complex things, like bitstream filters and the native decoder
[23:58:15 CEST] <jkqxz> Not sure you want the allocation here.  A parser would probably prefer a lighter API ("find next OBU start"?), while CBS will have to have full read/write code and allocation anyway.
[23:58:46 CEST] <jkqxz> Did you work out that that doesn't overrun?  It kindof looks like it could, though maybe the padding always saves you.
[00:00:00 CEST] --- Tue Apr 17 2018