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

[burek]

[00:15:05 CET] <atomnuker> jkqxz: btw have you noticed that chroma planes in vaapi yuv420p are incorrect?
[00:15:46 CET] <atomnuker> if you scale_vaapi=format=yuv420p,hwmap to opencl, unsharp_opencl, hwdownload,format=yuv420p you get U in V and the opposite
[00:16:24 CET] <atomnuker> the same thing happens in vulkan too btw, though I can just swizzle the planes and make them correct
[00:48:13 CET] <jkqxz> Because it's YV12 somewhere?  Hmm.
[00:48:25 CET] <jkqxz> I hadn't noticed that, but I can believe it.
[01:29:16 CET] <mistym> Anything else for me to check to fix "cur_dts is invalid", beyond setting the dts on the AVPackets during read_packet?
[01:32:20 CET] <JEEB> that IIRC comes from ffmpeg.c
[01:32:34 CET] <JEEB> -vsync vfr -copyts might come in handy, maybe
[01:32:40 CET] <JEEB> or -vsync passthrough
[01:33:00 CET] <JEEB> I would possibly recommend making a simple API client that demuxes and muxes and check if you get the issue with it)
[01:48:29 CET] <mkavidas> Hi, I am a student who is currently taking a course optimization and portability (for aarch64 using assembly). Our final project is that we find an open source project to optimize. I was thinking that FFmpeg would be a good fit for this. That being said, I am a little lost and don't know where to start... Basically I am looking for a function that will make a significant improvement if optimized and one that is not already heav
[01:48:39 CET] <mkavidas> if anyone has any recommendations I would highly appreciate it! 
[01:52:28 CET] <atomnuker> wanna do some aac/opus aarch64 simd?
[01:53:58 CET] <atomnuker> ff_mdct15_postreindex() was kinda simple but it did speed decoding up nicely
[01:54:40 CET] <atomnuker> check out libavcodec/mdct15.c and libavcodec/x86/mdct15.asm
[02:01:05 CET] <Chloe> michaelni: can you look at the issue described in '[PATCH v2 1/2] lav*, tests: remove several register_all() calls' instead of mulling over the single line patch which can be looked at easily later?
[02:01:15 CET] <mistym> JEEB: Unfortunately no luck with those options! Thanks though
[02:01:15 CET] <mistym> I already know that it works when decoding, just not when directly copying the stream.
[02:12:33 CET] <atomnuker> do you set frame_size?
[02:12:40 CET] <atomnuker> correctly?
[02:19:48 CET] <mkavidas> Thank you atomnuker! A few questions (sorry in advanced if they are a little stupid)... ff_mdct15_postreindex() do? Is there already an aarch64 equivolent? 
[02:19:59 CET] <mkavidas> what does ff_**
[02:27:46 CET] <Chloe> mkavidas: libavcodec/mdct15.c:postrotate_c() is what ff_mdct15_postreindex does. And there is not an aarch64 equivalent. Try using `git grep` to find how code fits together.
[02:29:17 CET] <mkavidas> oh I see. Thanks Chloe
[02:34:52 CET] <michaelni> Chloe, iam not sure why you like to replace the register system in the first place. But i probably need to fix the size issue the already pushed changes cause to the fuzzer. If i would work on adding more similar API changes to the other libs that would be shooting myself in the foot as it would mean more linking issues in any future extension of the fuzzer that someone will need to fix or add hacks to workaround
[02:38:15 CET] <Chloe> michaelni: 1) no linked lists means no need to 'register' components as they are always 'registered' 2) removal of 'register' APIs allow actual registration APIs to be added 3) new APIs allow lavd to be separated from lavf 4) why is a fuzzer stopping code from being improved?
[02:38:51 CET] <michaelni> Chloe, this sounds backward
[02:39:04 CET] <Chloe> michaelni: what does?
[02:39:05 CET] <michaelni> the fuzzer doesnt stop improvment
[02:39:53 CET] <michaelni> the new code is ehm IMHO not so good and the fuzzer is negativly impacted by that
[02:40:03 CET] <Chloe> you just said the fuzzer was one of the issues with changing APIs? did I misunderstand, what relevance does the fuzzer have?
[02:40:26 CET] <michaelni> security has relevance
[02:40:38 CET] <michaelni> security is related to fuzzing
[02:40:52 CET] <michaelni> so fuzzing has relevance
[02:42:04 CET] <Chloe> michaelni: 'the new code is ehm IMHO not so good' well it sure would have been nice if it got reviews in the weeks it was on the ML, but all it got was bikeshedding. But hey, we can only move forward now (or I'm sure you could still revert the new APIs fairly easily).
[02:43:20 CET] <michaelni> not all the issues where realized IIRC during review. 
[02:44:16 CET] <Chloe> michaelni: do you understand the current issue at hand though? 'finding options works on some behaviour with iterating AVClasses which would no longer work due to devices not being formats'
[02:45:07 CET] <Chloe> we have pretty much two options here: backtrack and absorb lavd into lavf, or continue to separate lavd and add a struct AVDevice (unless you know of any other options).
[02:45:54 CET] <Chloe> though you could get away with just a new AVClass for lavd (without a struct AVDevice)
[02:47:22 CET] <michaelni> i didnt really think about it so no, i dont fully understand it but lavf and lavd are not really sepearte libs with seperate API in key areas.  The 2 libs are split uncleanly
[02:49:59 CET] <michaelni> Fixing this unclean split in some way is certainly very desireable but this looks rather big and complex work
[02:50:21 CET] <michaelni> if it was easy we would have the 2 libs split better currently or not split
[02:56:04 CET] <michaelni> Chloe, about fixing the issue, if seperate AVClasses fix it that sounds like a minimalistic and clean solution though i dont fully underszand the issue
[02:56:55 CET] <Chloe> michaelni: yes it is big and complex, but we have to start somewhere and *not* doing it in the new iteration APIs would put the coffin in any work towards that
[03:03:16 CET] <michaelni> Chloe, if the changes keep growing in magnitude and complexity that this API change needs then the whole should possibly be done in a seperate branch and only merged once its done, that is if this expands into some library seperation redesign. doing this in git master could leave us with an increasingly broken codebase
[03:05:04 CET] <Chloe> michaelni: the avclass change is the only one which is absolutely needed for the API to be 'stable'.
[03:05:58 CET] <Chloe> And by 'stable', I mean it will work in the current state of lavf and lavd being sort-of not really separate libraries, but they will be more separate than they were before
[03:06:28 CET] <atomnuker> I think lavd and lavf should be merged, lavd is kinda limited in that it can only output avframes but lavf can do both
[03:07:00 CET] <atomnuker> (the fact it can only output frames led to avpkt in avframe codec which is kinda meh)
[03:07:39 CET] <Chloe> atomnuker: I think so too
[03:07:58 CET] <Chloe> if we were to merge lavd into lavf then it allows lavd to be rewritten from scratch without all the legacy
[03:08:19 CET] <Chloe> and cleans up a lot of the mess which came from lavd being not split properly in the first place
[03:08:27 CET] <jamrial> this sounds like a discussion for the mailing list, nor for irc on a sunday night
[03:12:33 CET] <michaelni> atomnuker, Chloe i too tend toward that lavd/lavf should not be seperate but jamrial is also right, in fact i should be afk and in bed already :)
[03:13:31 CET] <Chloe> michaelni: in their current state, they should not be separate. I think eventually, once lavd is actually a different library they could be.
[03:13:55 CET] <michaelni> yes
[03:14:15 CET] <Chloe> jamrial: i dont know how you'd start this conversation on the ML, this has actually been somewhat constructive
[03:14:57 CET] <mistym> atomnuker: Looks like I wasn't setting AVPacket::size, but setting it doesn't seem to have 
[03:16:40 CET] <mistym> Sorry, I realize I'm just kind of knocking back all suggestions, I'm just totally confused here.
[03:16:51 CET] <jamrial> Chloe: mention the current implementation state of the new api, the existing drawbacks, the expected/visible benefits, and present the different options to move forward, even the one that means rolling back the whole thing
[03:17:23 CET] <atomnuker> mistym: is  pkt_dts set?
[03:17:45 CET] <mistym> atomnuker: AVPacket::dts? Or a field in a different struct?
[03:23:36 CET] <tmm1> can someone help me understand why pts/dts is missing in some mpegts dvb video packets: https://paste.ee/p/Tc0q9
[03:39:39 CET] <atomnuker> mistym: guess I confused avpkg with avframe, its nearly 03:00 here
[03:40:02 CET] <mistym> atomnuker: No worries
[04:00:35 CET] <Chloe> jamrial: ok, I sent some thoughts on the matter to the ML.
[04:56:49 CET] <cone-798> ffmpeg 03Yingming Fan 07master:e5b4cd4c4a9c: checkasm/hevc_idct : update test bit depth from 8 9 and 10 to 8 10 and 12
[10:24:21 CET] <gagandeep> kierank: have you seen the filter yet?
[10:26:05 CET] <durandal_1707> gagandeep: probably cant comment because you sent patch against previous patch, which is bad idea
[10:27:25 CET] <gagandeep> durandal_1707: i am not talking about my written filter, i am asking keirank to himself confirm in the cineform sdk that the implementation for interlaced
[10:27:37 CET] <gagandeep> i have coded is on a right track
[10:28:41 CET] <gagandeep> we were not able to reach on a decision the other day as to which filter was used for horizontal transform because the file with it is unable to be opened in github
[10:30:35 CET] <gagandeep> i had pasted the code that i had traced in pastbin for his review
[10:39:12 CET] <gagandeep> durandal_1707: if i am to resubmit the patch for interlaced (correctly this time), how will that be reviewed?
[10:49:14 CET] <kierank> gagandeep: just replace the horizontal filter with haar
[10:49:25 CET] <kierank> You are confusing yourself here
[10:50:46 CET] <gagandeep> i tried that and it didn't work
[10:51:54 CET] <gagandeep> i am not randomly guessing here, the horizontal filter used in sdk is the same one as you have written
[10:52:14 CET] <kierank> Yes and you replace it with haar for interlaced
[10:52:45 CET] <kierank> But your previous patches changes a ton of other stuff
[10:53:44 CET] <gagandeep> kierank:pm?
[10:53:54 CET] <kierank> Please discuss in channel
[10:55:38 CET] <gagandeep> k, https://pastebin.com/epAxmdZ6 please take a look at this, it is the same filter used in the function we say for decoding to yuv
[10:56:35 CET] <gagandeep> again, using testCFHD file provided in the cineform-sdk i have traced it to this using printf
[10:57:37 CET] <gagandeep> i have also turned off the intrinsics and it work without them
[11:01:16 CET] <kierank> I don't see how this is related to interlaced but ok
[11:02:08 CET] <gagandeep> it is related because this is the function that is executed for interlaced final inverse transform for horizontal
[11:05:02 CET] <gagandeep> THE function we were discussing the day before yesterday (transformInverseFrameToYUV) is under the block of !progressive
[11:06:26 CET] <kierank> they may be doing it in a different order
[11:06:51 CET] <gagandeep> means?
[11:07:41 CET] <gagandeep> because the sdk is based on threaded decoding, i can't follow it through the decoding of the 3rd and 2nd levels
[11:07:57 CET] <gagandeep> though this function is for the last level
[11:08:13 CET] <kierank> either they use different naming rules for horizontal or vertical or they do two horizontal then a vertical
[11:15:36 CET] <gagandeep> i don't know if this matters, but somehow they call a function twice which constructs the lowpass band for next level
[11:15:51 CET] <gagandeep> with a different scale variable, 
[11:16:46 CET] <gagandeep> but to trace why they do that i will need to disable threading completely and remove the threading files from make
[11:17:09 CET] <gagandeep> other wise compilation errors pop up
[11:17:21 CET] <kierank> you can't define _INTERLACED_WORKER_THREADS 0
[11:17:23 CET] <kierank> ?
[11:17:51 CET] <gagandeep> the files which have threading functions and stuff somehow give the compile errors after doing that
[11:17:59 CET] <kierank> ok
[11:19:20 CET] <gagandeep> also they are doing all the dequantization seperately from these functions so i won't be able to see any issues with it
[11:19:30 CET] <gagandeep> like you have done,
[11:19:35 CET] <thardin> https://github.com/google/knusperli  pretty neat
[11:19:44 CET] <thardin> The goal of Knusperli is to reduce blocking artifacts in decoded JPEG images, by interpreting quantized DCT coefficients in the image data as an interval, rather than a fixed value, and choosing the value from that interval that minimizes discontinuities at block boundaries
[11:21:21 CET] <kierank> gagandeep: where do they loop through the levels?
[11:21:45 CET] <gagandeep> for wavelet or codebook?
[11:22:28 CET] <kierank> wavelet
[11:22:50 CET] <kierank> codebook is irrelevant
[11:23:00 CET] <gagandeep> the levels of wavelet are sent to threads, and the functions stop execution till those levels are reconstructed
[11:23:45 CET] <gagandeep> i have found the function used for them, but how they do it is behind threads
[11:24:02 CET] <kierank> because it's not clear if haar is used for all levels or just final level
[11:24:51 CET] <kierank> got to go now
[11:24:59 CET] <gagandeep> ok
[14:24:06 CET] <durandal_1707> gagandeep: the patch you posted, still have: cosmetic changes, 2 functional different changes
[14:55:15 CET] <Chloe> thardin: hey thats pretty nice, had anyone done it before?
[14:58:58 CET] <thardin> no idea. there's some other jpeg hacks too, like making use of clipping to get better contrast on black/white images
[14:59:13 CET] <thardin> that's on the encoder side
[15:09:42 CET] <gagandeep> durandal_1707: yeah, i forgot about the cosmetic change that i wanted to add and sent it with the patch, sorry, i will properly differentiate them this time
[15:11:38 CET] <gagandeep> kinda dizzy at this point with regards to interlace bug ;( and also looking at the alpha bug in cfhd now
[16:14:16 CET] <durandal_1707> what about extractchannels filter?
[16:18:14 CET] <gagandeep_> durandal_1707: were you asking me?
[16:19:46 CET] <durandal_1707> gagandeep_: no, i asked everyone, didn't notice I'm interrupting some conversation
[16:21:37 CET] <gagandeep_> no, not at all :)
[17:00:44 CET] <durandal_1707> gagandeep_: you have still not managed to encode with testcfhd?
[18:59:58 CET] <Chloe> wm4: 'It sounds absurd.' what's absurd is that lavd exists like it does, but nothing we can do about that except move forward.
[19:00:59 CET] <Chloe> Testing the AVClass currently, the lavd AVClass depends on lavf, but the whole library still does so I think it's a non-issue
[19:04:18 CET] <JEEB> yea, lavd and lavf are so closely knit together
[19:05:24 CET] <Chloe> this change sets some of the groundwork for lavd to have it's APIs swapped out
[19:44:45 CET] <tmm1> this seems like a mpegts demuxer bug right? every other video packet is missing pts/dts/pos: https://paste.ubuntu.com/p/M3Qdv498ZD/
[19:46:57 CET] <JEEB> not 100% sure, but I remember some timestamps not being there as being "normal", although the demuxer should take care of that
[19:48:28 CET] <JEEB> might want to take a look at it with https://sourceforge.net/projects/dvbinspector/files/?source=navbar or so
[19:48:44 CET] <JEEB> that's the thing I poke mpeg-ts files with when I feel like there's monkey business going on
[19:49:04 CET] <JEEB> (and yes, it's a java thing)
[19:49:28 CET] <tmm1> thanks. i was trying tsinfo and dvbsnoop but not getting very far
[20:03:47 CET] <JEEB> tmm1: under the tree tab, under PIDs -> 301 -> transport packets
[20:03:58 CET] <JEEB> if you consider packets that have (payload start)
[20:04:37 CET] <JEEB> at least the first three all have pts and dts
[20:05:16 CET] <JEEB> the other things with adaptation field seem to have PCR there
[20:06:47 CET] <nevcairiel> my guess: its paff h264 with both fields packed together, the parser splits them, hence only "half" have a pts
[20:06:59 CET] <nevcairiel> hints: only every second packet also has the mpegts streamid sidedata
[20:07:07 CET] <JEEB> yea
[20:07:16 CET] <JEEB> quite possibly field pics indeed
[20:13:59 CET] <tmm1> yea its definitely interlaced h264 that's showing this only, and this same has video packets with duration 0.02 vs 0.04 in other h264 feeds that dont' have the issue
[20:14:29 CET] <JEEB> it's a MBAFF/PAFF issue
[20:14:41 CET] <JEEB> rather than interlacism in general
[20:14:58 CET] <tmm1> so is the splitting happening in the mpegts demuxer or elsewhere?
[20:15:07 CET] <JEEB> parser
[20:15:09 CET] <JEEB> most likely
[20:15:28 CET] <JEEB> mpegvideo_parser
[20:16:22 CET] <JEEB> or uuh, wait no
[20:16:26 CET] <JEEB> that's mpeg1/2
[20:16:35 CET] <JEEB> but you hopefully get the general gist ^^;
[20:16:55 CET] <JEEB> the H.264 parser is making the separate field pictures be separate packets
[20:17:18 CET] <JEEB> and it doesn't give the other one any info since it expects them both to be used for a single output picture
[20:17:27 CET] <tmm1> ok that makes sense
[20:17:50 CET] <tmm1> the issue i'm seeing is that when i try to feed these packets into mediacodec's decoder, it expects a pts on each packet
[20:18:26 CET] <nevcairiel> a decoder that relies on pts is doomed to fail
[20:18:28 CET] <nevcairiel> just sayin'
[20:27:37 CET] <tmm1> hmm if i'm using -show_packets i thought that meant only lavf was being used, since it's at the AVPacket level. are those still being fed into the lavc h264 parser?
[20:28:06 CET] <nevcairiel> parsing happens before packets exit lavf
[20:28:42 CET] <JEEB> yea
[20:28:44 CET] <tmm1> wow i had no idea
[20:29:00 CET] <JEEB> so in the demuxer you ask for parsing for this format
[20:29:09 CET] <JEEB> and then it will insert a parser after the demuxer gives it a packet
[20:29:20 CET] <JEEB> which then separately can separate packets from the data you've read
[20:29:23 CET] <nevcairiel> mpegts generally always asks for parsing, since on a basic level it has no reliable packetizing
[20:29:27 CET] <JEEB> yes
[20:29:35 CET] <JEEB> just wanted to note the basic idea
[20:30:01 CET] <nevcairiel> (even though if your stream uses packet unit start indicators properly, you can have proper packet boundaries, but thats just not reliable)
[20:32:41 CET] <tmm1> got it
[20:32:48 CET] <tmm1> i guess that's why there's a mpegtsraw demuxer as well
[20:33:01 CET] <JEEB> oh, I never got that one :D
[20:33:03 CET] <nevcairiel> not sure what thats really for
[20:33:08 CET] <nevcairiel> its not really explained
[20:33:08 CET] <JEEB> yea,
[20:33:24 CET] <tmm1> the lavc parsers don't deal with AVPackets do i guess there's glue code in lavf that takes the mpegts packets, feeds them through the parser and generates new packets from the data
[20:33:24 CET] <JEEB> it never gets used and I didn't really get what it didn't/did do
[20:33:52 CET] <JEEB> tmm1: the mpeg-ts packet parsing goes in the demuxer
[20:33:58 CET] <JEEB> so you've demuxed some data out of the container
[20:34:03 CET] <JEEB> then you return that as an AVPacket
[20:34:16 CET] <JEEB> and the glue then parses your returned contents for valid "frames" of content
[20:34:23 CET] <JEEB> which then will be returned one by one
[20:36:33 CET] <Chloe> atomnuker: I've sent the 'implementation of option one' to the ML which essentially completes the API with the new dummy AVClass.
[20:36:33 CET] <tmm1> ok i see it now, parse_packet() takes the pkt and generates out_pkts
[20:36:48 CET] <JEEB> yup
[20:36:57 CET] <JEEB> it even works with AAC in PCM
[20:37:03 CET] <JEEB> except your timestamps are fucked, of course
[20:37:09 CET] <Chloe> atomnuker: it allows the lavd API to be redesigned at a later date
[20:39:30 CET] <atomnuker> cool
[21:44:36 CET] <tmm1> don't think i described that quite right, but i figured i would log it since i got lost in lavf/utils.c trying to fix it myself
[21:49:39 CET] <durandal_1707> tmm1: isnt issue in parser, so looking in utils is futile?
[21:57:06 CET] <nevcairiel> Don't really expect any quick fixes, parsers aren't really setup to make up timestamps
[21:58:59 CET] <kierank> parsers should use the framerate in the codec but the vfr lovers will cry like babies
[22:00:39 CET] <atomnuker> welp, nowadays you can blame webcam manufacturers for outputting vfr so you can't help not implementing it
[22:01:24 CET] <atomnuker> though if an encoder's RC system is decent it could handle vfr better than constant fps video
[23:03:39 CET] <Chloe> Is the GSoC application thing over?
[23:04:12 CET] <atomnuker> no
[23:04:36 CET] <nevcairiel> it hasnt even started really
[23:04:47 CET] <nevcairiel> oh wait, misread
[23:04:58 CET] <nevcairiel> lost the line in the table
[23:05:05 CET] <nevcairiel> still goes until march 27
[23:30:37 CET] <Chloe> Does every project only have one mentor? Do any projects need another one?
[23:34:13 CET] <jdarnley> If no specific project needs one you can always volunteer as a common backup mentor.
[23:34:25 CET] <jdarnley> or volunteer to mentor someone who gets creative.
[00:00:00 CET] --- Tue Mar 20 2018