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

[burek]

[00:03:17 CEST] <cone-652> ffmpeg 03Pavel Koshevoy 07master:edb4ba5bd4e7: Revert "lavfi/atempo: avoid false triggering an assertion failure"
[00:03:18 CEST] <cone-652> ffmpeg 03Pavel Koshevoy 07master:25b5096400b2: lavfi/atempo: Avoid false triggering an assertion failure
[00:17:11 CEST] <peloverde> BBB: I'm not attending VDD this year. The timing is too tough with my new job. I'll probably come next year. I will be at demuxed though. 
[00:18:02 CEST] <kierank> oh you left vp9 team
[00:19:36 CEST] <peloverde> I'm at twitch.tv now
[00:21:06 CEST] <kierank> ah nice, they need the help i think
[00:21:45 CEST] <BtbN> the worst parts that need work are web stuff though
[00:22:21 CEST] <kierank> BtbN: https://blog.twitch.tv/segment-based-rate-control-of-video-encoder-for-live-abr-streaming-1da5e60a2ec1
[00:22:26 CEST] <kierank> that blog post was very very wtf
[00:22:36 CEST] <kierank> let's hold a competition to implement x264's default ratecontrol
[00:25:58 CEST] <BtbN> I'm experiencing how great that works on my PS4 every time I watch something
[00:26:10 CEST] <BtbN> every time it switches quality it jumps backwards in time by a few seconds
[00:56:41 CEST] <Compn> peloverde : is twitch going to take over youtube y/n ? :P
[01:21:53 CEST] <iive> Compn: I thought that twitch is mostly about live streaming. Are there archives of past content?
[02:31:45 CEST] <cone-652> ffmpeg 03Steven Liu 07master:ef7fe81b8554: flvdec: Check the avio_seek return value after reading a  metadata packet
[02:33:57 CEST] <BBB> kierank: it sounds very much like lets have a 100s of poor grad students fight over who gets a free slice of pizza tomrrow to fix issues our engineers dont know how to fix
[02:34:14 CEST] <BBB> kierank: why dont they hire a few PhD students? theyd be delighted to eat real food for a few months
[02:34:21 CEST] <BBB> (and be paid well in the process)
[02:48:32 CEST] <atomnuker> what good would a phd do, they'd still need years to get the skills needed to do a good job
[03:20:54 CEST] <iive> about that twitch blog. It seems they do not understand what VBV is for. It is kind of absurd to claim that you can have VBV of unlimited size and then turn it off.
[03:22:52 CEST] <iive> well, it smooths bitrate with trading it for latency, and that variable misses completely from their task.
[03:26:45 CEST] <jamrial> oh nice, clang fixed the mjpeg miscompiling bug
[03:28:11 CEST] <jamrial> nevcairiel: can you test "[PATCH 2/2] avformat/fitsenc: fill header line with spaces"?
[03:47:49 CEST] <atomnuker> and yet a 6 day old gcc snapshot still can't compile the kernel
[03:49:43 CEST] <cone-652> ffmpeg 03Paras Chadha 07master:b07faf39ed10: avcodec/fitsdec: write output to frame directly
[03:50:20 CEST] <jamrial> atomnuker: sounds crazy, that'd be tagged as a blocker bug
[03:50:23 CEST] <jamrial> was it reported?
[03:50:59 CEST] <atomnuker> must have been
[03:52:40 CEST] <atomnuker> yep, its been reported and people are complaining
[03:54:31 CEST] <jamrial> bug #?
[03:54:50 CEST] <cone-652> ffmpeg 03James Almer 07master:cf42f316c525: fate: fix fate-lavf-fits dependencies
[03:58:12 CEST] <atomnuker> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81318
[04:01:27 CEST] <jamrial> "Any prospect of getting this fixed? I haven't been able to build Linux for ~a month now because of this."
[04:01:46 CEST] <jamrial> have you considered not using a mid development build?
[04:03:07 CEST] <jamrial> gcc trunk is not meant for production during stage 1
[04:04:03 CEST] <atomnuker> yep, that's what I'm using to compile the kernel
[04:04:31 CEST] <atomnuker> there was a period of around 2 years during which I used gcc trunk and I can't recall it ever failing to compile the kernel
[04:04:42 CEST] <atomnuker> which ended I guess around a few months ago
[04:06:20 CEST] <jamrial> gcc trunk fails to compile ffmpeg once a year or so during stage 1
[04:06:23 CEST] <jamrial> if we're lucky, because of an ICE (like it happened a montha go)
[04:07:09 CEST] <jamrial> if we're not, because of miscompilation of a module, which are a pain to report with test case and all
[05:24:16 CEST] <Compn> https://www.amazon.com/MECOOL-Latest-Android-7-1-1-Amlogic/dp/B073Z7X7KV/
[05:25:01 CEST] <Compn> vp9 box haha
[05:30:48 CEST] <atomnuker> probably requires kernel 3.10 and custom proprietary closed source kernel modules
[05:36:49 CEST] <jamrial> Compn: that's just standard feature of mali 450
[05:37:06 CEST] <jamrial> weird that they mention vp9 instead of hevc for such a product, though
[05:38:43 CEST] <Compn> hevc is listed later :)
[05:38:59 CEST] <Compn> but yeah
[05:39:02 CEST] <Compn> who knows
[05:39:15 CEST] <Compn> youtube uses vp9 , i wonder if that means more vp9 content than hevc...
[05:40:43 CEST] <jamrial> vp9 10bit hdr content on youtube is minimal afaik
[05:42:03 CEST] <jamrial> but then, hevc 10bit hdr is probably limited to smartv demos, unless enough blu ray UHD movies using it are already out
[05:43:20 CEST] <jamrial> oh nice, guardians of the galaxy vol 2 has a blu ray uhd release. I need to see how that looks
[05:44:09 CEST] <Compn> i prefer valerian :)
[05:44:29 CEST] Action: Compn watches far far too many films
[05:45:09 CEST] <jamrial> haven't seen that yet
[05:45:32 CEST] <Compn> its not as good as 5th element , but its the closest thing
[05:45:44 CEST] <jamrial> in any case, gotg vol 2 blu ray 4k: "Resolution: 2160p (upscaled from 2K master)"
[05:45:46 CEST] <jamrial> lol
[05:45:58 CEST] <Compn> heh
[05:46:23 CEST] <Compn> think they filmed it at 2k originally ?
[05:46:24 CEST] <Compn> hmm
[05:46:30 CEST] <Compn> i think probably not
[05:46:40 CEST] <Compn> 8k no doubt
[05:47:10 CEST] <jamrial> why would they have a 2k master then?
[05:47:20 CEST] <Compn> because they lie to you, of course
[05:47:38 CEST] <Compn> Digital Intermediate (2K) (master format) 
[05:47:38 CEST] <Compn> Dolby Vision 
[05:47:38 CEST] <Compn> Redcode RAW (8K) (source format)
[05:47:43 CEST] <Compn> raw 8k , i figured :)
[05:48:25 CEST] <Compn> probably their editing rigs are setup for 2k intermediate
[05:48:40 CEST] <Compn> how come we dont have any redcode people in the group ?
[05:48:48 CEST] <Compn> j-b : you should invite red people to vdd
[05:51:04 CEST] <jamrial> it would seem that disney, fox and warner are all using dolby truehd/atmos for their blu ray 4k releases
[05:51:20 CEST] <Compn> whats this arri raw format
[05:51:29 CEST] <Compn> bayer 12bit
[05:51:44 CEST] <jamrial> guess dts-x wasn't a good alternative to atmos for them
[05:52:42 CEST] <jamrial> watch everyone move to dolby now that we finally got a dts-ma decoder, heh
[05:53:19 CEST] <jamrial> not that it matters since we have a truehd decoder as well, and no way to handle atmos/dts-x anyway
[05:55:06 CEST] <Compn> i would like to get decoders for all professional formats :D
[05:56:20 CEST] <jamrial> oh shit, Labyrinth blu ray 4k
[06:08:44 CEST] <rcombs> jamrial: Your Name got a "4K HDR" BD release, but it was upscaled from a BT709 1920x1080 RGB master
[06:09:26 CEST] <jamrial> not surprising, i guess
[06:09:32 CEST] <rcombs> apparently the BD authoring people took the edited master and re-color-graded it
[06:10:24 CEST] <rcombs> also the scale looks CTEC
[06:10:28 CEST] <rcombs> erm, QTEC
[06:16:43 CEST] <Compn> i have no idea why bluray pressings are color corrected and denoised
[06:16:55 CEST] <Compn> i guess... screw you and the film colors you remembered :)
[10:10:33 CEST] <wbs> stevenliu: when cherrypicking patches from libav, I would appreciate if you'd keep the author line intact in git, especially if the patch doesn't need to do much modifications
[10:11:02 CEST] <wbs> just referenceing the commit hash of the cherrypicked patch does little to inform the reader of who was the original author of it
[10:12:25 CEST] <nevcairiel> it was even posted on the ML with the author line kind-of still there, but then pushed without it
[10:12:47 CEST] <wbs> yeah
[10:21:06 CEST] <stevenliu> keep the author info when commit? 
[10:21:36 CEST] <stevenliu> ok, do i need revert the commit this time?
[10:22:52 CEST] <stevenliu> wbs: ?
[10:23:32 CEST] <wbs> no, but keep it mind next time
[10:24:00 CEST] <stevenliu> Ok, Sorry for that.
[10:24:16 CEST] <wbs> git has got the author field; if you take a commit, try using "git cherry-pick" initially, and it will keep the original author name and commit message intact. if the patch doesn't fit perfectly you might need to do some fixing of conflicts
[10:24:18 CEST] <stevenliu> i just think keep the commit id from libav, too simple, sorry.
[10:24:40 CEST] <nevcairiel> isnt even more work to get rid of the original author, git itself usually keeps it
[10:24:56 CEST] <wbs> if you manually apply the changes and do a new commit, you can do "git commit --author="John Doe <foo at baz>" to record it, or "git commit -c <hash of original commit>" to keep the metadata
[10:25:22 CEST] <stevenliu> i usually use patch -p1 < xxxx.patch ;git commit -a 
[10:25:41 CEST] <stevenliu> and if need modify the author, git commit --author "";
[10:25:49 CEST] <stevenliu> ......
[10:25:58 CEST] <nevcairiel> you should learn about cherry-pick then :)
[10:26:05 CEST] <wbs> absolutely
[10:26:10 CEST] <stevenliu> mhmm, ok,haha
[10:26:30 CEST] <nevcairiel> it also resolves some simple conflicts for you
[10:27:30 CEST] <stevenliu> i will try to use git cherry-pick :D
[11:01:19 CEST] <ubitux> ideally, we would be doing merges instead
[11:01:34 CEST] <ubitux> still no one to deal with that dash stuff?
[11:15:20 CEST] <mateo`> can't we just skip thoses dash patches ?
[11:15:46 CEST] <mateo`> I mean for now, until someone cares
[11:18:01 CEST] <ubitux> we should revert our stuff and apply the new one
[11:18:30 CEST] <ubitux> i'm just way too tired/lazy/busy to try to figure out what's they're really all about and test them
[11:18:58 CEST] <ubitux> btw, ETA: 530+ commits
[11:19:13 CEST] <ubitux> what happened to the bitstream thing?
[11:19:16 CEST] <CoreX> jesus christ..
[11:25:35 CEST] <durandal_1707> ubitux: foo86 said it is asserting for some scenario
[11:29:10 CEST] <ubitux> the dash thing? in its current state or post patch?
[12:41:01 CEST] <cone-790> ffmpeg 03Timo Rothenpieler 07master:a56d0497cbab: avcodec/nvenc: migrate to new encode API
[12:41:02 CEST] <cone-790> ffmpeg 03Timo Rothenpieler 07master:d0961d30692a: avcodec/nvenc: sanitize variable names
[13:30:03 CEST] <cone-790> ffmpeg 03Tobias Rapp 07master:912b6af26e0d: ffprobe: use consistent string for unspecified color_range value
[13:32:21 CEST] <stevenliu> mateo`:  you mean dashdec?
[14:03:21 CEST] <BBB> gh0st__: do you have an update for the execute3 patch?
[14:19:41 CEST] <gh0st__> BBB: I'll upload it in an hour or so, I have to make some tests.
[14:19:45 CEST] <BBB> ok
[15:03:22 CEST] <BBB> shall I oick up the msa vp9 optimizations in my push also? anyone against them?
[15:03:38 CEST] <BBB> I really cant review them because -enoclue, but Im happy to merge them
[15:04:09 CEST] <durandal_1707> have you tested it?
[15:05:15 CEST] <BBB> nope
[15:12:43 CEST] <durandal_1707> does it introduce security risks?
[15:15:35 CEST] <BBB> dunno
[15:16:57 CEST] <durandal_1707> is it libav cherry pick?
[15:18:19 CEST] <BBB> no
[15:20:08 CEST] <cone-790> ffmpeg 03Michael Niedermayer 07master:913feb6263e0: avformat/gdv: Make FixedSize static
[15:20:09 CEST] <cone-790> ffmpeg 03Michael Niedermayer 07master:9cb4eb772839: avformat/mov: Fix DoS in read_tfra()
[15:20:10 CEST] <cone-790> ffmpeg 03Michael Niedermayer 07master:afc9c683ed9d: avformat/asfdec: Fix DoS in asf_build_simple_index()
[15:20:21 CEST] <durandal_1707> you may still apply it if its tested by at least one person
[15:41:21 CEST] <BtbN> that amf implementation that guy did is horrible
[15:41:36 CEST] <BtbN> There is now more actual code in compat than in the rest of ffmpeg
[15:41:47 CEST] <wm4> I was just looking slightly at it, and that compat thing stood out, yes
[15:42:08 CEST] <BtbN> That SDK should be an external dependency
[15:42:15 CEST] <BtbN> but it's nice that it's MIT licensed
[16:54:20 CEST] <cone-790> ffmpeg 03Paul B Mahol 07master:e1524de4546b: avfilter/vf_zoompan: fix specific corner case when no frame was ever requested from input
[17:34:17 CEST] <durandal_170> anyone want retro star field source?
[20:59:30 CEST] <BBB> hm, SlicethreadContext is also exposed in the header now
[21:00:19 CEST] <BBB> gh0st__: WDYT if we move thread_execute3 to be non-static instead of thread_execute, and then re-move ThreadContext back privately into the .c file?
[21:00:36 CEST] <BBB> gh0st__: and then rename it to ff_slice_thread_execute_with_mainfunc() or so
[21:00:55 CEST] <BBB> gh0st__: I think thats a better idea, Im not the biggest fan of exposing SliceThreadContext into the .h file
[21:01:06 CEST] <BBB> (even if its not exported, someone will eventually abuse it)
[21:01:17 CEST] <gh0st__> BBB: okay, let's do that way.
[21:01:37 CEST] <BBB> sorry for going in circles here, I just didnt realize wed need the struct ...
[21:02:50 CEST] <atomnuker> tbh I'd rather not have 3 slice threading functions too
[21:03:02 CEST] <gh0st__> I wasn't sure myself until the end if SliceThreadContext needed to be moved to .h
[21:03:09 CEST] <atomnuker> since API users would need to fill in all 3 with their own implementation
[21:07:27 CEST] <BBB> atomnuker: feel free to suggest alternatives in the ML thread
[21:07:50 CEST] <BBB> atomnuker: or get rid of the old one (execute1)
[21:10:24 CEST] <gh0st__> BBB: I am starting to think that we don't even touch the existing threading API, because it should be clearly modified only for vp9 at the moment. 
[21:10:36 CEST] <BBB> right, thats what we do now, right?
[21:10:40 CEST] <BBB> so thats fine
[21:11:02 CEST] <gh0st__> Well, yes, kind of. )
[21:12:33 CEST] <jya> I don't have access to the mp4 ISO spec right now, is there something in the metadata specifying the average frame rate of a video?
[21:14:29 CEST] <JEEB> you can get that from the composition timestamps and durations
[21:14:44 CEST] <JEEB> http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
[21:14:49 CEST] <JEEB> also, just search 14496-12 in this :P
[21:15:07 CEST] <JEEB> that's the ISOBMFF spec
[21:16:44 CEST] <jya> JEEB: yeah, but I don't want to demux the content yet.. I only have the moof to work with
[21:27:47 CEST] <gh0st__> BBB: Huh, I wanted to see how libav maybe had done the same thing, but their pthread_slice is different.
[21:28:10 CEST] <BBB> yeah
[21:28:16 CEST] <BBB> ffmpeg/libav split off too long ago
[21:28:19 CEST] <BBB> the two have diverged too far
[21:28:26 CEST] <BBB> I wouldnt waste too much time looking how they did things
[21:53:34 CEST] <Compnn> is this 18if anime any good ?
[21:54:38 CEST] <durandal_1707> Compnn: wut
[21:54:53 CEST] <Compnn> durandal_1707 : new anime of crazytown
[21:55:38 CEST] <durandal_1707> its for 18 years and higher, you are too young
[22:06:29 CEST] <Compnn> durandal_1707 : i just thought it had an interesting cover. dunno what its about. kinda looks terrible from what i'm watching it right now
[22:35:27 CEST] <gh0st__> BBB: check this out https://pastebin.com/UPD8imYV
[22:35:52 CEST] <gh0st__> Is this what meant?
[22:36:02 CEST] <BBB> perfect
[22:36:03 CEST] <BBB> thnx
[22:55:02 CEST] <BBB> gh0st__: michael is right that the pthread_slice patch should come first, and the vp9 patch second
[22:55:39 CEST] <gh0st__> BBB: oops, my mistake.
[22:55:54 CEST] <BBB> its ok, it happens
[22:56:13 CEST] <BBB> you also need to submit a new vp9 patch since the way it calls into the pthread_slice api changed slightly, right?
[22:56:24 CEST] <BBB> (I know its like a 1- or 2-line change, but still...)
[22:59:28 CEST] <gh0st__> yeah sure
[23:00:08 CEST] <gh0st__> Oh, god, I wanted to send that patch v8 patch for tile threading, but instead I sent garbage.
[23:00:58 CEST] <gh0st__> Well, it's a patch, but not a full one./
[23:32:41 CEST] <J_Darnley> WTF?  Who's been renaming things in the blend filter?
[23:36:45 CEST] Action: J_Darnley swears a whole lot
[23:38:33 CEST] <BBB> michaelni: I think you need to first apply [PATCHv2 2/2] avcodec/pthread_slice: add ff_slice_thread_execute_with_mainfunc(), and then [PATCH 1/2] avcodec/vp9: Add tile threading support [v8]
[23:38:43 CEST] <BBB> michaelni: its very confusing, but that should work
[23:46:44 CEST] <J_Darnley> WTF is going on here?  Why isn't this lossless?
[23:46:57 CEST] <J_Darnley> Who has been dicking with master?
[23:48:01 CEST] <kierank> J_Darnley: dirac master?
[23:48:11 CEST] <J_Darnley> No, ffmpeg master.
[23:48:29 CEST] <kierank> ffmpeg master encoding dirac?
[23:48:42 CEST] <J_Darnley> yes, either the encoder or decoder
[23:50:14 CEST] <J_Darnley> Well I see a few silly changes from fuzzing.
[23:50:29 CEST] <J_Darnley> But nothing else
[23:50:36 CEST] Action: J_Darnley checks out an old master
[00:00:00 CEST] --- Fri Sep  8 2017