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

[burek]

[03:27:18 CEST] <cone-368> ffmpeg 03Michael Niedermayer 07master:e529fe763376: avcodec/get_bits: Make sure the input bitstream with padding can be addressed
[03:27:18 CEST] <cone-368> ffmpeg 03Michael Niedermayer 07master:eb60b9d3aaaa: avformat/mov: Move +1 in check to avoid hypothetical overflow in add_ctts_entry()
[03:27:18 CEST] <cone-368> ffmpeg 03Michael Niedermayer 07master:db772308941a: avcodec/mpeg4videodec: Use more specific error codes
[05:54:36 CEST] <cone-368> ffmpeg 03James Almer 07master:3eff98c92788: avformat/rtpenc_chain: use the proper function to free AVFormatContext
[08:59:13 CEST] <durandal_1707> kierank: eac3 or DD+ are there any real samples with > 5.1 layouts that are not test streams?
[10:13:04 CEST] <gagandeep> kierank: https://pastebin.com/Bgnd9KZn
[10:13:18 CEST] <gagandeep> this is the cfhd3.err i am getting on running fate
[10:13:36 CEST] <gagandeep> i don't think this an error stdout
[10:14:44 CEST] <gagandeep> https://pastebin.com/NvnRmb60
[10:14:53 CEST] <gagandeep> this is the cfhd3.diff
[10:18:50 CEST] <durandal_1707> gagandeep: learn to inspect visual difference with ffmpeg
[10:19:27 CEST] <gagandeep> durandal_1707: i mean in the cfhd3.err, i don't think it is an error stdout
[10:20:01 CEST] <gagandeep> so as carl has hinted me in mail, if my patch is breaking a fate test, then either the patch is to be fixed or fate test
[10:21:51 CEST] <durandal_1707> gagandeep: wtf, fate fails because there IS visual difference, you failed to spot
[10:23:03 CEST] <gagandeep> ok, so it is a visual difference based error, i get it
[10:23:29 CEST] <gagandeep> i will see what i can do
[10:23:49 CEST] <durandal_1707> gagandeep: probably patch is incomplete
[10:24:09 CEST] <durandal_1707> it check for one case, but by fixing it breaks another
[11:45:43 CEST] <klaxa> wowowowow, my uni really lost that form and now wants me to resubmit it, not even sure if i can get all the acceditations i need for that, lol
[11:45:45 CEST] <klaxa> gg wp
[12:54:50 CEST] <Compn> CounterPillow : big money
[12:55:00 CEST] <CounterPillow> Compn: ?
[12:55:12 CEST] <Compn> [08:24] <CounterPillow> Gonna need to get in the middle of this with some good internet comment etiquette
[12:55:33 CEST] <CounterPillow> Ah :D
[12:55:57 CEST] <Compn> sounds like something big money salvia would say
[12:56:12 CEST] <CounterPillow> yes
[13:02:46 CEST] <durandal_1707> Compn: from where you get transcript?
[13:13:40 CEST] <Compn> durandal_1707 : https://www.youtube.com/user/commentiquette/videos
[13:15:35 CEST] <durandal_1707> Compn: i ask, from where you got irc transcript
[13:15:49 CEST] <Compn> durandal_1707 : oh, i have a long buffer
[13:16:04 CEST] <Compn> and stable internet connection
[13:16:10 CEST] <Compn> aaaand power supply
[13:17:11 CEST] <Compn> err my dcc not working
[13:35:28 CEST] <durandal_1707> Compn: are you attempting to hack me?
[14:02:42 CEST] <durandal_1707> i dont understand how is eac3 supposed to be decoded if substream id is always 0
[14:03:05 CEST] <durandal_1707> an stream depends on previous frame
[14:07:27 CEST] <durandal_1707> how is you supposed to know there will be such dependent stream upfront?
[14:17:53 CEST] <klaxa> atomnuker: good news, i got the documents i need
[14:28:27 CEST] <nevcairiel> durandal_1707: you dont, thats the funny part
[14:28:42 CEST] <nevcairiel> how do you know a dts core is followed by a dts extension
[14:28:46 CEST] <nevcairiel> you just go look
[14:39:02 CEST] <gagandeep> kierank: for the fate test, will my patch that is fixing padding give error with one of the test files?
[14:40:02 CEST] <gagandeep> i believe the visual difference is the distortion originally present
[14:40:49 CEST] <durandal_1707> gagandeep: havent you read reply i gave you on ml?
[14:40:51 CEST] <Chloe> michaelni: I dont understand how this https://www.irccloud.com/pastebin/mZepxiIw/omgsoslow.c makes target_dec_fuzzer.c so much slower with the new API, could you elaborate on this and maybe share some statistics on actual impact?
[14:41:21 CEST] <durandal_1707> gagandeep: fate is broken with that patch applied
[14:41:26 CEST] <gagandeep> i am using blend difference on two raw output files from original ffmpeg and my patched ffmpeg
[14:41:54 CEST] <durandal_1707> differences are very subtle
[14:42:24 CEST] <gagandeep> yes and i am seeing the last 8 pixel distortion at the bottom
[14:42:41 CEST] <gagandeep> you said that fate is matching visual output
[14:43:12 CEST] <gagandeep> so if original output is wrong (the present distortion that is subtle and can't be seen just looking at file)
[14:43:43 CEST] <durandal_1707> gagandeep: fate decodes file and check if it is different from reference
[14:44:03 CEST] <nevcairiel> if you're fixing the decoder, maybe the reference just needs updating
[14:45:10 CEST] <gagandeep> referrence is also cfhd encoded
[14:45:19 CEST] <Chloe> nevcairiel: of course the new output actually needs to be correct though
[14:45:39 CEST] <gagandeep> chloe: what do you mean
[14:46:01 CEST] <gagandeep> https://imgur.com/a/WbLaz
[14:46:02 CEST] <JEEB> same as reference
[14:46:42 CEST] <Chloe> I mean if the output is different (but you expect it to be because you fixed/improved something) you still need to make sure that the output is verified to be correct
[14:47:28 CEST] <nevcairiel> not necessarily, if the previous output was wrong, then being "less wrong" because there might still be other bugs is still fine
[14:48:26 CEST] <gagandeep> chloe: if you know the last 8 pixel padding bug, the link that i have pasted is the one i am getting using blend diff on the refference with original ffmpeg and my patched version
[14:49:00 CEST] <gagandeep> from what i gather, the refference data will need to be checked by someone
[14:51:13 CEST] <Chloe> nevcairiel: all I'm saying is that you need to make sure that it is actually less wrong before you update the expected hash
[14:51:55 CEST] <gagandeep> chloe: you are correct
[14:52:21 CEST] <gagandeep> i have been just freaking out because fate was breaking the output
[14:53:26 CEST] <gagandeep> so how will that be done
[14:54:57 CEST] <durandal_1707> gagandeep: modify reference hash
[14:55:12 CEST] <gagandeep> the diff that i was getting, right?
[14:55:41 CEST] <durandal_1707> diff shows difference, no point in modifying it
[14:55:52 CEST] <durandal_1707> diff points to reference
[14:56:19 CEST] <gagandeep> yeah
[14:58:07 CEST] <durandal_1707> nevcairiel: i have local hack that decodes eac3 7.1 all frames, but in wrong order, and i do not understand how and where are extra channels supposed to be used
[14:58:45 CEST] <gagandeep> i believe kierank can modify the reference after personally checking the output
[14:59:49 CEST] <durandal_1707> gagandeep: you can too, and post patch
[15:00:06 CEST] <gagandeep> ok, i will need to find the file first
[15:01:56 CEST] <nevcairiel> durandal_1707: afaik you drop the side surround channels from the 5.1 and use the 4 extra channel for side+rear
[15:02:26 CEST] <nevcairiel> i think there is metadata that tells you this, though?
[15:02:32 CEST] <nevcairiel> been a few years since i looked into this
[15:07:37 CEST] <durandal_1707> nevcairiel: thing is channel map is 16bit, and it is always 1101000000000000, so what that means for 7.1 from 5.1 ? there is extra bit
[15:08:02 CEST] <durandal_1707> the specs are not clear to me
[15:08:59 CEST] <nevcairiel> that bitmask doesnt make any sense to what i see in the spec
[15:09:10 CEST] <nevcairiel> unless its maybe read with wrong endianness?
[15:11:28 CEST] <nevcairiel> or i'm reading it the wrong way around
[15:13:47 CEST] <atomnuker> klaxa: awesome, go and write some proposal (no one will read it but maybe some pencil pushers at google)
[15:13:55 CEST] <nevcairiel> section 3.8.2 in the spec seems to explain the behavior quite well to me
[15:15:24 CEST] <nevcairiel> if it refers to channels that already exist in the independent substream, replace them, otherwise add them
[15:15:34 CEST] <klaxa> atomnuker: i already wrote the proposal, carl-eugen sent me an email (with cc for michael and thilo borgmann) telling me i need a mentor and a qualification task, i replied that i can only confirm if i can even participate today and asked for more comments on the proposal
[15:15:52 CEST] <klaxa> ah, that email was on friday
[15:16:13 CEST] <klaxa> i also replied that you said you'd mentor me, maybe that was not clearly communicated?
[15:16:21 CEST] <nevcairiel> (it seems quite inefficient to code replacement channels, silly dolby)
[15:18:11 CEST] <durandal_1707> nevcairiel: yes, 3 channels are replaced, and what remains is 2 channels (ignoring LFE, which is coded differently)
[15:19:19 CEST] <nevcairiel> so probably replaces a bunch from the core, and adds 2 more rear surround channel
[15:19:23 CEST] <nevcairiel> sounds reasonable?
[15:21:44 CEST] <atomnuker> klaxa: ah, yes, I see it
[15:22:49 CEST] <atomnuker> klaxa: remove "This far no Qualification Task has been determined." and add some schedule below the about section, should be good then
[15:22:51 CEST] <klaxa> i just now submitted the pdf, it said to let the google docs thing open for comments, but if nobody really reads it and it is formality only i guess it should be good enough
[15:23:12 CEST] <atomnuker> I've marked myself as willing to mentor you on the interface
[15:23:12 CEST] <durandal_1707> nevcairiel: yes, its very ugly
[15:25:11 CEST] <klaxa> what would be some good points for the schedule? i think first my project needs to be integrated with libav* stuff given that i reimplemented some structs
[15:25:54 CEST] <Chloe> klaxa: whatcha doin?
[15:26:04 CEST] <klaxa> make ffserver great again
[15:26:52 CEST] <Chloe> Ah I saw your initial work on that, I wanted to look into it
[15:29:01 CEST] <Chloe> atomnuker,klaxa: idk how it works but Id be happy to answer any questions related to this as well
[15:29:02 CEST] <atomnuker> klaxa: no, we should think about integration really only after the very end
[15:29:12 CEST] <klaxa> oh, okay
[15:29:12 CEST] <atomnuker> and I don't think it should be
[15:29:33 CEST] <klaxa> hmm i looked at least at the segment.c structs and they already do what i did i think
[15:29:39 CEST] <klaxa> in libavformat
[15:30:48 CEST] <atomnuker> klaxa: as for the schedule, make something up per-week, that's what I've seen most students do
[15:31:49 CEST] <klaxa> ok sounds good
[15:47:00 CEST] <gagandeep> durandal_1707:should i send my proposal on ml
[15:52:19 CEST] <durandal_1707> gagandeep: no
[15:53:53 CEST] <gagandeep> ah, ok i see, on gsoc website i will submit a draft proposal
[17:52:29 CEST] <cone-049> ffmpeg 03James Almer 07master:3c245707bd48: avcodec/avdct: use the proper function to free AVCodecContext
[18:04:07 CEST] <durandal_1707> nevcairiel: the dependent substream is 4.0 - i expected 5.0
[18:13:52 CEST] <nevcairiel> durandal_1707: 4.0 is what I've seen, replacement side channel and new rear channel
[18:14:11 CEST] <nevcairiel> But it could be something else if it wanted to
[18:14:22 CEST] <JEEB> sr90: btw just ask your question here
[18:14:34 CEST] <JEEB> don't privately message me via e-mail or IRC
[18:14:52 CEST] <JEEB> you have much higher chances of getting help by asking here about adding a FATE test for the demuxer
[18:15:16 CEST] <JEEB> (if it affects the demuxed result then most likely you will want to poke something like `ffprobe -show_packets`)
[19:02:15 CEST] <durandal_1707> nevcairiel: how is one supposed to know that there is going to be dependent frame, parser splits frames instead
[19:05:07 CEST] <wm4> well make the parser not split frames, or make it stateful
[19:05:21 CEST] <wm4> are you trying to decode this garbage?
[19:09:09 CEST] <durandal_1707> yes, i have local hack, just need remapping channels and this crap parser fix
[19:13:35 CEST] <wm4> so does the decoder buffer two packets?
[19:13:40 CEST] <wm4> why is the parser involved?
[19:16:25 CEST] <durandal_1707> i think i found it
[19:40:01 CEST] <durandal_1707> finally, fixed parser
[19:44:33 CEST] <durandal_1707> but it broke normal files :)
[19:49:36 CEST] <durandal_1707> does eac3 always have dependent frames?
[19:50:55 CEST] <durandal_1707> guess not
[19:51:27 CEST] <wm4> no
[19:52:10 CEST] <wm4> keep in mind that demuxers randomly return merged or split packets too
[19:57:32 CEST] <durandal_1707> there is no single bit in first packet that tells that seconds ppacket depends on first one
[20:27:02 CEST] <wm4> durandal_1707: no, but there are such bits a bit later in the frame, obviously?
[21:04:12 CEST] <cone-295> ffmpeg 03Gyan Doshi 07master:cfe1a9d311de: avformat/segafilm - fix keyframe detection and set packet flags
[21:14:07 CEST] <michaelni> Chloe, not sure i understand what you asked. the fuzzer becomes bigger due to linking. It may become slower too but not sure who said so. The whole set of fuzzers (one for each codec thats XY gigabyte) need to be transfered over the net the way ossfuzz works IIRC
[21:15:55 CEST] <wm4> except they don't need to be done this way
[21:15:57 CEST] <Chloe> michaelni: I dont understand why would the size be any different? you still link to the library?
[21:16:44 CEST] <michaelni> Chloe, it links in every codec, it only linked in one codec before.
[21:17:56 CEST] <wm4> we had a lengthy discussion about it
[21:18:02 CEST] <jamrial> Chloe: linkers optimize unreferenced symbols out. the new static api always references every codec
[21:18:05 CEST] <Chloe> why cant you just link to the single codec? if you dont use any of the functions which use codec_list then they shouldnt get included right?
[21:18:37 CEST] <wm4> probably ffmpeg.c misery
[21:21:36 CEST] <Chloe> you dont need to call avcodec_register_all() or avcodec_register() you can use ff_whatever_decoder, the linker will optimise out the unused codecs and then it's even smaller than before
[21:21:41 CEST] <Chloe> michaelni: do I misunderstand?
[21:23:13 CEST] <michaelni> Chloe, maybe its possible. Someone has to try this to see if it works or if something pulls the rest in, it would be good if it works
[21:24:48 CEST] <michaelni> ive a headache ATM so i wont try this one today, theres enough already that i need to do 
[21:31:59 CEST] <Chloe> michaelni: the time it will take me to compile all the things required to test seems to be longer than you to give it a quick look tomorrow (or even the day after). But sure there's no need to do it today
[21:39:07 CEST] <atomnuker> I don't really care for the new api, I think the old one was fine
[21:39:31 CEST] <atomnuker> I kinda like the suggestion to make the state the user's responsibility
[21:39:41 CEST] <atomnuker> rather than some global state which requires locking
[21:42:16 CEST] <wm4> like nicolas' malloc list?
[21:54:28 CEST] <klaxa> atomnuker: if you have time could you check the schedule i propose and tell me if i'm over- or underestimating the time needed? i'm not too confident in my evaluation of the difficulty of the problems
[21:55:11 CEST] <atomnuker> wm4: malloc list?
[21:56:44 CEST] <wm4> returning a malloc'ed list of codecs
[22:06:29 CEST] <atomnuker> which grows if you add new codecs? I think that's okay, anything's better than linked lists of codecs
[22:07:45 CEST] <wm4> I really don't see a problem with the static list though
[22:09:05 CEST] <durandal_1707> nevcairiel: you said you have eac3+ samples to share? now is time because i got it working, just need to figure mapping of channels
[22:46:29 CEST] <durandal_1707> huh, there is also dolby ac4
[22:56:35 CEST] <atomnuker> wm4: I like the static list more, no global state needed, register functions, etc.
[22:58:35 CEST] <atomnuker> jamrial: after you apply the packet list patch to the matroska demuxer would it still be doing various packet copying?
[23:00:07 CEST] <nevcairiel> durandal_1707: I'll make a few samples from BluRay disc when I get home
[23:01:29 CEST] <jamrial> atomnuker: the data is never copied before or after, just the packet structure. and even after the patch, the packets are still being copied into something
[23:01:57 CEST] <jamrial> that something being linked avpacketlists instead of a constantly reallocated array of avpackets
[23:06:11 CEST] <atomnuker> I remember wm4 saying the native demuxer was somewhat inefficient, is this still the case?
[23:09:45 CEST] <wm4> huh
[23:10:20 CEST] <durandal_1707> matroska?
[23:17:07 CEST] <atomnuker> yeah
[00:00:00 CEST] --- Tue Mar 27 2018