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

[burek]

[00:01:03 CET] <BtbN> A github mirror for the nv-codec-headers would be nice. Just for the tarballs and stuff alone.
[00:05:06 CET] <wm4> yeah we should have that
[00:10:17 CET] <BtbN> also makes the whole thing more visible to users
[00:10:34 CET] <BtbN> would like to edit the wiki, but can't, logging in gives me a gateway timeout
[01:45:33 CET] <jamrial> jkqxz: use av_packet_add_side_data(), not av_packet_new_side_data() + memcpy + av_free
[02:01:22 CET] <gagandeep> kierank: i want to ask questions on interlacing in cfhd for the bug
[02:07:30 CET] <gagandeep> atomnuker: i want to ask about the interlaced video bug in cfhd
[02:25:23 CET] <Compn> maybe they arent awake right now
[02:25:34 CET] <Compn> atom is in uk i think
[02:25:40 CET] <Compn> gagandeep : what timezone are you in ?
[02:26:15 CET] <gagandeep> indian standard time ist +5:30
[02:26:43 CET] <gagandeep> kierank is also in uk
[02:27:32 CET] <gagandeep> Compn: can you help me with something regarding interlaced videos in ffmpeg
[02:45:52 CET] <Compn> i can try but i will probably fail
[02:45:56 CET] <Compn> whats the question gagandeep ? 
[02:46:01 CET] <Compn> ask here, someone else may have an idea :)
[02:46:09 CET] <Compn> (sorry was afk)
[02:48:06 CET] <gagandeep> i think i was being confused about something, since the bug states that many issues are not visible using cineform original decoder used in windows media player, so i am first going to run the files in there and confirm what actual difference is there
[02:48:39 CET] <Compn> can you link me to the bug
[02:49:05 CET] <gagandeep> https://trac.ffmpeg.org/ticket/6675#no1
[02:49:19 CET] <gagandeep> https://trac.ffmpeg.org/ticket/5522
[02:49:26 CET] <Compn> ah i was looking at 5522
[02:49:27 CET] <Compn> hehe
[02:49:39 CET] <gagandeep> yeah that one is about interlacing
[02:50:27 CET] <gagandeep> i just noticed that i should also compare the .mov attatched using the windows media player to confirm what the issue is
[02:50:27 CET] <Compn> so it looks like the official decoder doesnt have problems
[02:50:30 CET] <Compn> and our decoder does :\
[02:51:42 CET] <gagandeep> also interlacing is not something related to the decoder or is it
[02:52:19 CET] <gagandeep> also can the metadata of files tell whether the file is interlaced or progressive
[02:52:41 CET] <gagandeep> ffplay does not report that in the console
[02:54:07 CET] <Compn> depends how interlaced is handled with the codec
[02:54:29 CET] <Compn> but yes, otherwise i would say interlacing is part of the decoder
[02:55:50 CET] <gagandeep> also, i have been having difficulties finding some samples of interlaced videos on the net, can you tell me where you guys download samples from
[02:56:34 CET] <Compn> we maintain samples at http://samples.ffmpeg.org
[02:56:45 CET] <gagandeep> cool
[02:57:00 CET] <Compn> its kind of a lot of files, so if you need help finding something
[02:57:27 CET] <Compn> note that some sample names are incorrect , so a file named "interlaced" might be interlaced content but not using the codecs' interlacing feature
[02:57:47 CET] <Compn> some dvds / vobs would be interlaced
[02:58:38 CET] <gagandeep> what do you mean by interlaced content but not using the codec's interlacing feature
[02:59:51 CET] <gagandeep> does that mean we need to convert that file to some other codec to render it properly 
[03:01:22 CET] <gagandeep> Compn:you there?
[03:14:49 CET] <Compn> gaga : 
[03:14:49 CET] <Compn> doh
[03:14:58 CET] Action: Compn needs slep
[03:58:39 CET] <cone-493> ffmpeg 03Steven Liu 07master:aa294ad00a49: avformat/hlsenc: add reference stream index for split segment
[05:28:18 CET] <philipl> BtbN: Just posted a patch set that fixes 12bit input to nvenc by claiming to support p016. This avoids the need for a new pix format and has the advantage of providing a way to still do hardware transcodes. 12bits gets truncated to 10bits but that was always going to happen as swscale doesn't dither either.
[08:27:30 CET] <gagandeep> kierank: are you available right now?
[10:13:51 CET] <gagandeep> what are tags in codecs?
[10:22:04 CET] <durandal_170> gagandeep: way for fast codec type recognition
[10:25:07 CET] <gagandeep> so like normal tags
[10:26:04 CET] <JEEB> some containers utilize tags
[10:26:30 CET] <gagandeep> kierank: i want to discuss about the bugs in the cfhd listed for qualification task
[10:27:19 CET] <gagandeep> JEEB: yeah, like if the video is interlaced or not,mainly present in the header or video format struct 
[10:28:07 CET] <gagandeep> was going through the cineform sdk and there were like a ton of tags, maybe around 200 of them
[10:33:38 CET] <gagandeep> atomnuker: i think kierank is not available right now so can i discuss about how to start fixing the bug in cfhd.c listed for qualification task
[11:33:00 CET] <yingming> Hi there, i wondering how to send patch with introduction like  "Hi!  Attached patch by John Stebbins fixes a warning with mkvalidator here.  Please comment, Carl Eugen -------------- next part -------------- From dab79ea5cd01187567b1761aaf1c329926483786 Wed Oct 29 00:00:00 2014 From: John Stebbins <stebbins at jetheaddev.com> Date: Wed, 29 Oct 2014 10:54:44 -0700 Subject: [PATCH] lavf/matroskaenc: Fix writing zero duration subt
[11:34:44 CET] <yingming> Is there any tool or git send-email command can auto add string "-------------- next part --------------"?
[11:36:01 CET] <nevcairiel> Really shouldnt take Carls patch mails as an example of proper patch submissions
[11:41:36 CET] <iive> wasn't the --- something you can add to the message and it would appear in the mail, but it would not be in the repo when you commit it?
[11:42:16 CET] <jdarnley> What?
[11:42:44 CET] <jdarnley> Nevermind.  Please ignore that.
[11:45:28 CET] <wbs> iive: things after a "---" on a single line gets cut from the commit message, if you apply it with "git am" yes
[11:45:51 CET] <wbs> (the normal git format-patch output also uses --- to separate the diffstat from the commit message)
[13:10:26 CET] <jya> anyone with experience with CoreAudio and AudioUnit ?
[13:25:53 CET] <jkqxz> ZhongLi:  Wrt libmfx lookahead, it's different in the two tines because it was turned on by default here when the feature was added but not there.
[13:27:07 CET] <jkqxz> I think having it off is the right state, but it does change what you need to put on the command line for things to work at all and there are a lot of cargo-cultists copying old command lines around.
[13:28:10 CET] <jkqxz> Hence last time this was an option (a bit over a year ago) I didn't change it.  I've no idea if it's a good idea now, maybe we are in a different state given this will be a new major version.
[13:41:22 CET] <jkqxz> A lot of the usage problem (as demonstrated by that patch just posted and the associated bug, I think) is that the "qsv" implementation of libmfx stuff is very much intended to be used for complex operations by people who actually understand what's going on.
[13:42:04 CET] <jkqxz> If you don't understand what's going on then you're not going to have fun using it even for simple operations, especially on Linux where it has crazy setup requirements.
[16:27:30 CET] <manishv> can someone explain the mechanism or give some source from where i can understand the mechanism how ffmpeg plays a track.I am new to ffmpeg and working on some decoder bug and i need to understand this in order to solve the issue.
[16:31:03 CET] <jamrial> manishv: i told you yesteday, contact the project mentors. if omerjerk doesn't reply, then email Thilo Borgmann instead
[16:31:20 CET] <jamrial> they are the ones that need to guide you for this
[16:33:27 CET] <manishv> ok i thought that someone may help here till the time they reply.
[16:35:32 CET] <manishv> jamrial: can u please tell what type of help can i get here or what type of questions should i ask here?
[16:36:12 CET] <jamrial> manishv: you can get this kind of help here as well, but you have more chances getting it from the project mentors
[16:38:01 CET] <manishv> jamrial: i thought that i can get help from here till the time they reply.
[16:39:08 CET] <manishv> so that i can fix the issue as soon as possible.
[16:39:46 CET] <nevcairiel> This channel is usually not here to explain the entity of ffmpeg code, most of the time we would have to read the code aswell to see whats going on, so you should start with that.
[16:40:06 CET] <nevcairiel> if you're looking into a decoder, its all in libavcodec
[16:40:37 CET] <nevcairiel> utils.c and decode.c for the generic stuff, and the specific decoder files on top of that
[16:41:55 CET] <manishv> nevcairiel: ok thankyou very much.
[17:27:43 CET] <cone-146> ffmpeg 03James Almer 07master:6ce5dd228c40: avformat/mxg: return reference counted packets
[17:29:39 CET] <jdarnley> atomnuker, kierank: What document defines the version of dirac with reference frames and interpolation?
[17:29:41 CET] <jdarnley> Is that version 1 in the bitstream?
[17:29:56 CET] <kierank> on the dirac website i guerss
[17:34:11 CET] <jdarnley> Shit.  The website is gone.
[17:34:14 CET] <jdarnley> "diracvideo.org
[17:34:15 CET] <jdarnley> is a totally awesome idea still being worked on."
[17:35:41 CET] <kierank> jdarnley: then forget about reference frames and stuff
[17:35:46 CET] <kierank> just get hq profile working
[17:35:56 CET] <kierank> and backport the code to trimmed
[17:36:25 CET] <jdarnley> I plan to but I wanted to check how that old stuff is signalled in the bitstream.
[17:47:55 CET] <jdarnley> Thankfully the Internet Archive hasn't memory holed the website.  (yet)
[17:53:43 CET] <TD-Linux> too bad, they had a nice rdo overview
[17:59:55 CET] <jdarnley> I expected as much...
[18:00:21 CET] <jdarnley> is_reference(): return ((state[PARSE CODE]&0x0C) == 0x0C)
[18:00:49 CET] <jdarnley> is_fragment(): return ((state[parse_code]&0x0C) == 0x0C)
[18:03:45 CET] <kierank> jdarnley: yes, that's why trimmed exists basically
[18:04:02 CET] <kierank> you'd have to guess based on version number
[18:04:19 CET] <jdarnley> Yes.  I believe that is what the spec implies.
[18:04:36 CET] <jdarnley> If the stream inclused fragments then the major version shall be 3
[18:05:48 CET] <jdarnley> I would sort-of reverse that.  If the stream contains reference then the major version shall be less than 3
[18:13:55 CET] <atomnuker> I think I finally have a solution on how to include spirv binaries during compilation
[18:14:30 CET] <atomnuker> an assembler! incbin "shader.spv"
[18:14:56 CET] <wm4> just write a small script that converts it to hex and include it as byte array?
[18:16:22 CET] <atomnuker> don't know how to do it, I'd rather not use hexdump because who knows how many systems don't have it, and xxd isn't available unless you install vim (and I'd really not have ffmpeg depend on vim)
[18:16:39 CET] <atomnuker> to have some usable decoding times you need an assembler so might as well use that
[18:17:59 CET] <wm4> but assemblers are highly system dependent
[18:20:59 CET] <jkqxz> od is a standard Unix utility.  Given that we assume sed and things like that, it really must be there.
[18:25:50 CET] <BtbN> https://travis-ci.org/FFmpeg/FFmpeg-Coverity/builds/348320907 I honestly have no idea what's wrong with it. It just doesn't even start.
[18:26:40 CET] <atomnuker> what about on windows? do we require od there?
[18:30:16 CET] <jkqxz> We require sed there for configure, so why not?
[18:30:28 CET] <jkqxz> (We require sed there for cl2c.)
[18:31:22 CET] <jamrial> od seems to be present in my msys2 environment
[18:31:37 CET] <jamrial> so probably part of a core package
[18:32:17 CET] <atomnuker> we require unix utils even for msvc?
[18:32:24 CET] <jamrial> BtbN: that error is far from informative...
[18:32:38 CET] <jamrial> atomnuker: yes? the only supported way to compile msvc is using an environment like msys2
[18:32:44 CET] <jamrial> we don't ship an msvc project file
[18:33:01 CET] <atomnuker> welp, shows how much I know about that
[18:33:07 CET] <jamrial> how else do you think configure is run otherwise?
[18:33:40 CET] <BtbN> jamrial, it just exits immediately, after .7 seconds, with exit code 5.
[19:06:02 CET] <JEEB> more timeout options in microseconds \o/
[19:14:50 CET] <atomnuker> what's $< mean in bash?
[19:15:06 CET] <sfan5> isn't that a make thing?
[19:15:29 CET] <atomnuker> could be
[19:16:12 CET] <atomnuker> I really hope it means "a file path but with an extension different in the way you'd like from the original argument's extension"
[19:18:24 CET] <drv> $< is just the first input of a make rule (b in 'a: b c d')
[19:18:46 CET] <sfan5> a reference can be found here: https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html
[19:21:24 CET] <jya> does libavfilter has a filter to convert any channel layout to another ?
[19:22:08 CET] <kepstin> jya: not really a devel question. There are several filters in libavfilter that can do different things to channel layouts.
[19:22:34 CET] <jya> I want say convert 4.0 to stereo, or ambisonic (so 4.0) to stereo
[19:22:58 CET] <jya> I'm yet to find a comprehensive documentation on what's available :(
[19:23:02 CET] <atomnuker> oh wow it turns out cl2c will do just what I need it to do
[19:24:42 CET] <atomnuker> almost
[19:25:43 CET] <durandal_1707> jya: not yet possible, there is ambisonics decoder filter in making
[19:26:26 CET] <jya> durandal_1707: what about non-ambisonic, aformat needs to be the filter of choice, but it seems to be limited to a set of formats into another
[19:26:43 CET] <jya> s/needs/seems
[19:26:48 CET] <atomnuker> lswr can do that, there's a filter which wraps it
[19:27:02 CET] <atomnuker> aresample
[19:27:05 CET] <JEEB> there's AVFrame::channel_layout which takes a 64bit mask
[19:27:16 CET] <JEEB> pretty sure 4ch can be handled with it?
[19:28:00 CET] <jya> JEEB: if it did reordering the channels, would be even more useful... so I can feed directly say CoreAudio AudioUnit output
[19:28:11 CET] <wm4> I don't think ambisonic -> sane conversion is there yet?
[19:28:18 CET] <JEEB> no
[19:28:21 CET] <jya> VLC does it :)
[19:28:24 CET] <JEEB> he asked about non-ambisonics
[19:28:33 CET] <jya> vlc 3.0 that is
[19:28:42 CET] <JEEB> ambisonics needs "viewport" anyways
[19:28:51 CET] <JEEB> as in, where in the environment your ears are
[19:28:59 CET] <jya> but doing ambisonic is a bonus, not my priority right now
[19:29:19 CET] <wm4> I use two libswresample instances for generic reordering
[19:29:27 CET] <wm4> I'm not even sure why I needed two
[19:29:36 CET] <wm4> (one for normal conversion, one for final reordering)
[19:29:49 CET] <wm4> I'd sure like if it could do that all at once
[19:30:06 CET] <wm4> my conclusion is that reordering is probably done better directly in the audio output
[19:30:13 CET] <wm4> also, wait, coreaudio prefers non-interleaved audio
[19:30:17 CET] <wm4> which is trivial to reorder
[19:30:28 CET] <JEEB> yeh, just pointers
[19:30:32 CET] <wm4> the real pain is ALSA
[19:30:51 CET] <jya> only support pulse now
[19:31:21 CET] <jya> atomnuker: got a link for lswr?
[19:31:32 CET] <atomnuker> libswresample
[19:31:40 CET] <jya> ahhhhh
[20:02:55 CET] <atomnuker> I think I should use libshaderc
[20:36:27 CET] <durandal_1707> i think you should finish atrac9
[20:36:59 CET] <jamrial> wm4: for that matter, i can't reproduce all those trailing whitespaces you got in the updated fate test
[20:37:21 CET] <durandal_1707> haha
[20:52:46 CET] <wm4> jamrial: meaning?
[20:54:19 CET] <jamrial> https://pastebin.com/raw/kUJGsHeT that something may be wrong on your end
[20:57:58 CET] <wm4> odd
[21:00:31 CET] <wm4> what could be wrong? I've tried make distclean + rebuild, but it still has the whitespace changes
[21:01:16 CET] <BtbN> https://github.com/FFmpeg/FFmpeg/pull/279 what? Even if this was posted on a forum, I'd still have no clue.
[21:02:35 CET] <nevcairiel> nevermidn that guy, its an absolute idiot
[21:02:51 CET] <nevcairiel> he tried to report his odd issue in various places and noone understands him at all
[21:03:53 CET] <wm4> probably A/V desync due to using a raw aac file
[21:22:05 CET] <atomnuker> durandal_1707: yeah alright, I'll do some work on it this weekend
[21:22:45 CET] <durandal_1707> hurray!!
[21:34:20 CET] <gagandeep> kierank: are you available right now?
[22:07:27 CET] <gagandeep_> atomnuker: i think kierank is not replying right now, so can i discuss with you for a sec?
[22:20:55 CET] <wm4> gagandeep_: rule 1 on IRC: never ask to ask, just ask the question
[22:41:48 CET] <gagandeep_> wm4: ohhh..., thanks
[22:57:20 CET] <cone-146> ffmpeg 03Aurelien Jacobs 07master:61c972384d31: parseutils: add support for ms and us suffix for AV_OPT_TYPE_DURATION
[23:03:30 CET] <philipl> jkqxz: does any of the intel hardware do 12bit hevc yet? I'm about to push a change to say nvdec can do it. Should I add vaapi?
[23:05:20 CET] <gagandeep> kierank: are there more interlaced video samples encoded using Cineform, or do I need to manually encode for testing
[23:06:53 CET] <gagandeep> kierank: also , is adobe premiere pro the only editor with Cineform encoding
[23:13:06 CET] <jkqxz> philipl:  No.  There is no RExt in VAAPI at all.
[23:41:19 CET] <gagandeep_> kierank: where are the documentation for the CFHD param enum you have declared in cfhd.c
[23:49:41 CET] <gagandeep_> guys, i haven't heard from kierank in a while now and since i need to do the qualification tasks, i am having difficulties trying to go about them as i am not familiar with the standard libraries at ffmpeg and the many technical details of codecs
[23:51:00 CET] <JEEB> atomnuker: what were the subjective tests that put ffaac on the top if you remember off the top of your head?
[23:53:46 CET] <atomnuker> wall of noise, not solo piano music with 1 note per minute
[23:55:12 CET] <JEEB> d'uh
[23:55:26 CET] <JEEB> I just wanted a reference since the news entry talks about subjective tests being made
[23:55:30 CET] <JEEB> so I wondered if they got publicized
[23:55:40 CET] <JEEB> since someone mentioned how that news entry didn't link anywhere to prove it
[23:56:09 CET] <JEEB> which I do agree isn't perfect if it's trying to make its reader believe in that claim
[23:56:20 CET] <BtbN> atomnuker, btw., with the next OBS release the ffmpeg aac encoder will actually be used by pretty much every user. They dropped the horrible Windows-Encoders
[23:56:23 CET] <JEEB> I mean, I know that the AAC encoder is usable at 96kbps for the random broadcast clips
[23:56:44 CET] <BtbN> Only people who won't use it are the ones with iTunes installed, as it still prefers the Apple-Encoder that comes with it.
[23:56:53 CET] <atomnuker> BtbN: that's good news, finally
[23:56:54 CET] <JEEB> but if there actually were any proper subjective tests done
[23:57:13 CET] <JEEB> because kamedo2 stopped doing them in january, 2016
[23:57:16 CET] <JEEB> unfortunately
[23:57:20 CET] <BtbN> atomnuker, they also hardcoded it to the fast coder, as they're not using a master build of ffmpeg
[23:57:59 CET] <JEEB> and kamedo2's last test still shows up like this http://listening-test.coresv.net/img2/ffaac_fdk_compare_en.png
[23:58:23 CET] <JEEB> which is an old version and all
[23:58:48 CET] <JEEB> so yea, that is why I asked if there's any actual references to the claims in the news entry?
[23:58:52 CET] <BtbN> people usually stream at 128k, and I _never once_ notices an audio encoding artifact on Twitch
[23:59:15 CET] <JEEB> yea, actual artifacts are real rare nowadays
[23:59:20 CET] <JEEB> esp. at rates like that
[23:59:32 CET] <JEEB> I mean, I don't disagree that the internal encoder is quite usable
[23:59:45 CET] <BtbN> it's definitely better than the Windows encoder they used
[23:59:50 CET] <BtbN> with the random MASSIVE artifacts
[23:59:55 CET] <JEEB> to the contrary, I want to switch to it in certain places where something else is still utilized
[00:00:00 CET] --- Sat Mar  3 2018