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

[burek]

[00:08:11 CEST] <Daemon404> michaelni, i am going to change the codec par repo to have an issue tracker
[00:08:17 CEST] <Daemon404> can you file any new stuff there
[00:10:04 CEST] <michaelni> Daemon404, i can do "anything" that helps you :)
[00:10:23 CEST] <michaelni> well not anything ;) but alot
[00:10:44 CEST] <Daemon404> i moved the 3 from today to new issues there: https://github.com/dwbuiten/FFmpeg/issues
[00:11:05 CEST] <Daemon404> wm4, ubitux, nevcairiel, jamrial ^
[00:13:15 CEST] <Daemon404> hmm michaelni, i tested an unpatched version of ffmpeg that is at teh same revision as when i started the codedpar merge
[00:13:18 CEST] <Daemon404> and Starship_Troopers.vob just segfaults it
[00:13:22 CEST] <Daemon404> was there some recent fix
[00:18:39 CEST] <michaelni> hmm, thats odd, ive used that file alot for testing, i dont remember a segfault
[00:19:58 CEST] <jamrial> the opus regression is because it detects stereo instead of 7.1
[00:21:12 CEST] <nevcairiel> its probably another case of detecting stream first, filling in data later
[00:21:15 CEST] <nevcairiel> mpegts is annoying like that
[00:22:50 CEST] <michaelni> Daemon404, how can i make  Starship_Troopers.vob segfault ?
[00:30:39 CEST] <michaelni> Daemon404, good news, i just tested some basic rtp stuff and its still working, ill try to test more cases
[00:32:58 CEST] <Daemon404> nevcairiel, im going to need help on teh flv one
[00:33:06 CEST] <Daemon404> i didnt touch any of the flv code thus far
[00:33:41 CEST] <Daemon404> michaelni, nevermind, the segfaulty was my fault
[00:35:32 CEST] <Daemon404> wm4, or was it you who knows the flc stuff
[00:40:33 CEST] <wm4> nevcairiel seems to know most about it, but I can try to look at it tomorrow
[00:44:03 CEST] <Daemon404> ok i figured out the opus in ts sample
[00:45:42 CEST] <michaelni> rtmp seems also to still work, i have seen one parser codec id assertion in rtp, i think ill wait till issue #3 is fixed before creating a potential dulpciate 
[00:46:25 CEST] <Daemon404> michaelni, i am about to push a fix for #3
[00:46:29 CEST] <Daemon404> is it opus in ts too?
[00:47:13 CEST] <nevcairiel> what was wrong with opus? I would figure its mpegts filling in data late, but maybe its somethiung else?
[00:47:58 CEST] <michaelni> iam not sure if iam mixing issues up but  think i saw a missing extradata in one of the issues
[00:48:17 CEST] <Daemon404> nah
[00:48:19 CEST] <Daemon404> i pushed a fix
[00:48:25 CEST] <Daemon404> it was setting the opus extradata in read_packet
[00:48:28 CEST] <Daemon404> a mpegts.c does.
[00:48:36 CEST] <nevcairiel> so, like i said
[00:48:44 CEST] <nevcairiel> this piece of code is getting uglier by the minute
[00:48:52 CEST] <Daemon404> sure is
[00:48:55 CEST] <nevcairiel> imho, not acceptable
[00:49:02 CEST] <nevcairiel> should find a proper solution or dont do it
[00:49:03 CEST] <Daemon404> i dont see you suggesting anything
[00:49:42 CEST] <Daemon404> nor definign what proper is
[00:50:10 CEST] <nevcairiel> proper would be something that doesnt need random field additions for every other bug we find =p
[00:51:11 CEST] <nevcairiel> i assume opus is broken in libav?
[00:51:21 CEST] <Daemon404> i dont see how to avoid that other than modifying mpegts.c to also set internal avctx in addition to codecpar
[00:51:24 CEST] <Daemon404> which is not much better
[00:51:35 CEST] <Daemon404> and then hope no otehr format needs it
[00:51:46 CEST] <nevcairiel> hence, design failure, and needs an addition to the design to somehow do this
[00:52:04 CEST] <Daemon404> all youve said is: it's broken, i have no better ideas
[00:52:12 CEST] <Daemon404> solution is to what? hold of mege indefinitely?
[00:52:16 CEST] <Daemon404> off*
[00:53:18 CEST] <jamrial_> nevcairiel: sure is
[00:53:22 CEST] <jamrial_> detected as stereo
[00:53:27 CEST] <jamrial_> by avconv
[00:53:34 CEST] <nevcairiel> supposedly this merge cleans up code, well thats going down the drain fast, so if we can't fix that, might as well wait until we can, because for every problem we find there is 4 we didnt find
[00:54:15 CEST] <Daemon404> then why the fuck did i dump a shitload of hours int ogetting this done sooner rather than later
[00:54:18 CEST] <nevcairiel> one solution would be to add a field to allow a demuxer to say find_stream_info "i updated something, go re-start your probing and re-sync iinternal avctx"
[00:54:29 CEST] <nevcairiel> Daemon404: i told you that rushing this would not be a good idea
[00:54:30 CEST] <Daemon404> other than to make sure i dont have a metric fuckshit-ton of merges in backlog
[00:54:33 CEST] <Daemon404> (which noone will help with)
[00:55:35 CEST] <Daemon404> yes you said it wont be done fast, and proceeded to not make any progress at all for 2 weeks
[00:55:43 CEST] <Daemon404> so i stepped up to handle it
[00:56:30 CEST] <Daemon404> because i dont feel liek having 500 commit backlogs to merge
[00:59:31 CEST] <Daemon404> so if we're gonna hold off inddefinitely whiel buildign a hige backlog of merges noone will help me with, i am simpyl going to absolve myself and step down from helping with merges
[00:59:47 CEST] <jamrial_> does reporting bugs to libav usually get somewhere?
[00:59:56 CEST] <Daemon404> jamrial_, give it a few years
[01:00:00 CEST] <jamrial_> this is a general design problem from codecpar after all
[01:00:03 CEST] <jamrial_> ah well
[01:02:18 CEST] Action: michaelni is too dumb to use github
[01:02:24 CEST] <nevcairiel> could try to talk to elenril directly, maybe he cares
[01:04:47 CEST] <jamrial_> that'd be great
[01:08:10 CEST] <jamrial_> oh, lol
[01:08:30 CEST] <jamrial_> the sample is broken with avconv even before codecpar was implemented
[01:09:16 CEST] <wm4> jamrial_: of course
[01:09:20 CEST] <jamrial_> no wonder they didn't take this into consideration while designing codecpar :p
[01:09:34 CEST] <nevcairiel> well they still have the code to set the extradata
[01:09:38 CEST] <kierank> jamrial_: is this my fault perhaps?
[01:09:42 CEST] <wm4> many ffmpeg specific things are shitty hacks that make "something" work
[01:09:45 CEST] <kierank> since it's opus in ts
[01:09:48 CEST] <wm4> it's a common pattern
[01:10:02 CEST] <jamrial_> kierank: it's working in ffmpeg pre codecpar, so no idea
[01:10:18 CEST] <jamrial_> unless it was broken when you first wrote it then someone fixed it
[01:10:20 CEST] <wm4> (and also things which don't enter elenril's consideration, so no concept for them)
[01:10:41 CEST] <Daemon404> so what's the concensus
[01:10:48 CEST] <Daemon404> should be hold off and rethinkign design or what
[01:11:08 CEST] <jamrial_> does this only happen with mpegts?
[01:11:16 CEST] <wm4> many things are "late" updates to codec params, right
[01:11:24 CEST] <nevcairiel> for now, possible other formats as well
[01:11:44 CEST] <wm4> so, why not provide an internal function to update it "late"
[01:11:47 CEST] <kierank> it should in principle happen with ogg and opus as well
[01:12:03 CEST] <wm4> (this would also confine such late changes)
[01:16:36 CEST] <nevcairiel> i posted a sort of suggestion into https://github.com/dwbuiten/FFmpeg/commit/d40f238e79a8eb5515c6de8c14eb10612ea1b99e
[01:18:04 CEST] <Daemon404> nevcairiel, i did try callign avcodec_parameters_tocontext and it blew up some tests
[01:18:34 CEST] <Daemon404> namely latm
[01:19:17 CEST] <Daemon404> it might be due to the way i called it.
[01:19:23 CEST] <nevcairiel> well like I said, it should not be called all the time because that causes issues and overwrites data, but only when the demuxer specifically says it updated something, and then also doing it "right" by closing the probing decoder first
[01:19:38 CEST] <Daemon404> well ok
[01:19:46 CEST] <Daemon404> what demuxers can do this besides mpegts
[01:19:58 CEST] <Daemon404> and xmv if i revert that change
[01:20:02 CEST] <nevcairiel> not sure, but shouldnt be *that* many that have the noheader flag to read
[01:20:19 CEST] <Daemon404> that is assuming it had it set properly at all
[01:20:21 CEST] <Daemon404> look at wavdec
[01:20:49 CEST] <nevcairiel> well ok we can fix those as we find them then, but we have a somewhat clean approach for formats that mandate this kind of behavior
[01:21:14 CEST] <Daemon404> i dont think it is too much effort to implement and i am willing to do this tomorrow
[01:21:23 CEST] <Daemon404> but i would really, really liek some help with the otehr unrelated bus
[01:21:26 CEST] <Daemon404> bugs*
[01:21:36 CEST] <Daemon404> there's one flv one and one vob one
[01:21:41 CEST] <michaelni> ill fix issue4 i _think_ its a bug in the mjpeg decoder
[01:21:52 CEST] <Daemon404> michaelni, ok
[01:22:48 CEST] <Daemon404> i dont know wtf is up with the vob or flv bugs
[01:23:22 CEST] <Daemon404> (nor am i keen on digging in for 4 hours again in unfamiliar code)
[01:25:20 CEST] <Daemon404> all i know is that flv *unsets* NOHEADER for some reason, at some point, so the codec id is never updated
[01:25:27 CEST] <Daemon404> but if i remove that code i get a ton of h264 errors
[01:25:32 CEST] <Daemon404> thats as far as i got
[01:26:03 CEST] <michaelni> it unsets noheader to stop find_stream_info aka (i got all data you dont need to search for more streams) IIRC
[01:26:11 CEST] <nevcairiel> it unsets noheader when its done finding its streams
[01:26:17 CEST] <nevcairiel> what michaelni s aid
[01:26:21 CEST] <Daemon404> i see
[01:26:22 CEST] <Daemon404> ok
[01:26:46 CEST] <nevcairiel> parsers are entirely screwed up in this api model right now
[01:27:28 CEST] <Daemon404> other than closing/only setting once, the proposed new model is not hugely differenty
[01:28:53 CEST] <Daemon404> anyway, by the time it gits the check for NOEHADER< it is unset
[01:28:56 CEST] <Daemon404> and nothing gets copied
[01:29:33 CEST] <nevcairiel> well if you add the new proposed change for late changes, flv can set that flag and the code would update it
[01:29:48 CEST] <nevcairiel> wouldnt it
[01:30:08 CEST] <nevcairiel> I can also write that tomorrow, but right now its like  1:30am
[01:30:44 CEST] <Daemon404> well yea
[01:31:06 CEST] <michaelni> will push a fix to master for issue 4 soon (after testing)
[01:31:43 CEST] <Daemon404> michaelni, ok
[01:32:07 CEST] <Daemon404> nevcairiel, if you write it tomorrow, i will triage/fix any remaining bugs
[01:32:12 CEST] <Daemon404> but not both
[01:32:45 CEST] <Daemon404> im currently in GMT-5, so ill let you write it
[01:32:48 CEST] <Daemon404> as i will be asleep.
[01:38:00 CEST] <Daemon404> sorry... GMT-4. DST.
[01:45:22 CEST] <Daemon404> nevcairiel, i hacked togetehr a crappy version of your idea
[01:45:24 CEST] <Daemon404> and it fixed flv
[01:45:43 CEST] <Daemon404> but its not usable (it was a global constant)
[01:45:54 CEST] <Daemon404> so the one in #3 i mean.
[01:46:03 CEST] <Daemon404> so please do implement it tomorrow.
[01:46:28 CEST] <Daemon404> need to go out now, sleep well.
[01:46:40 CEST] <nevcairiel> about to head in as well
[01:47:08 CEST] <Daemon404> talk tomorrow
[01:47:19 CEST] <Daemon404> g'night
[01:53:06 CEST] <Daemon404> right. too much codecpar lately. beer time.
[01:53:10 CEST] Action: Daemon404 &
[01:55:53 CEST] <cone-393> ffmpeg 03Marios Titas 07master:c1f9734f977f: avfilter/src_movie: fix how we check for overflows with seek_point
[01:55:54 CEST] <cone-393> ffmpeg 03Michael Niedermayer 07master:de0bcea664c8: avcodec/mjpegdec: Do not permute quantization tables
[03:51:36 CEST] <cone-393> ffmpeg 03Derek Buitenhuis 07master:fcbdc44f4e0c: wavdec: Only set the codec ID in read_header
[03:51:37 CEST] <cone-393> ffmpeg 03Michael Niedermayer 07master:cf4d050b7231: avformat/wavdec: Remove direct s->pb->buffer access
[04:19:40 CEST] <cone-393> ffmpeg 03Martin Vignali 07master:4f682318fb80: fate/exr : add test for b44/b44a compression
[05:37:42 CEST] <Daemon404> for some reason i thought michaelni started actually sleeping... i must have been mistaken
[10:29:02 CEST] <nevcairiel> Daemon404: pushed the change, passes fate with assert-level=2 (sans the vp6a things that lack the sample still)
[11:15:54 CEST] <durandal_1707> Compn: do you have samples with fourcc TR20?
[12:14:51 CEST] <michaelni> nevcairiel, "avformat: allow demuxers to signal late stream changes" causes: https://github.com/dwbuiten/FFmpeg/issues/11
[12:41:45 CEST] <nevcairiel> michaelni: fixed
[13:08:46 CEST] <michaelni> nevcairiel, thx
[13:34:10 CEST] <Compn> durandal_1707 : 
[13:35:19 CEST] <Compn> durandal_1707 : looks like final fantasy 7 pc game used tr20 for its fmv
[13:35:26 CEST] <Compn> i dont know if we have any samples
[13:38:34 CEST] <Compn> durandal_1707 : https://samples.ffmpeg.org/V-codecs/TM20/
[13:38:45 CEST] Action: Compn wonders why he went to google instead of checking samples repo
[13:38:56 CEST] <durandal_1707> m is not r
[13:39:13 CEST] <Compn> oh woops
[13:41:09 CEST] <Compn> ask kostya, he wrote the wiki entry on it http://wiki.multimedia.cx/index.php?title=Duck_TrueMotion_2_Realtime
[13:43:23 CEST] <Compn> i could probably make a sample if i can find an installer
[13:47:29 CEST] <Compn> durandal_1707  : https://samples.ffmpeg.org/drivers32/!OLD/tr2032.dll is the binary codec for tr20, but looks decode only
[14:49:43 CEST] <wm4> michaelni: seriously, just start fixing all those issues yourself
[16:37:08 CEST] <wm4> where do we shuffle parser parameters to the codecpar?
[16:47:28 CEST] <nevcairiel> there really isnt a good place
[16:47:35 CEST] <nevcairiel> like i said, parsers dont fit the flow anymore
[16:49:38 CEST] Action: Daemon404 sees tons of new issues :(
[16:50:29 CEST] <wm4> nevcairiel: yeah, seems like we have a place now where we add hacks for parser updates
[16:51:04 CEST] <wm4> Daemon404: many michaelni reported ones seem just due to av_dump_format being dumb
[16:52:02 CEST] <Daemon404> i see at least two vob things
[16:52:33 CEST] <nevcairiel> no clue how the mpegps demuxer works internally
[16:52:38 CEST] <Daemon404> ill look
[16:52:39 CEST] <nevcairiel> maybe it needs the new update flag somewhere
[16:52:43 CEST] <Daemon404> whats up with this mkv thing?
[16:52:59 CEST] <nevcairiel> as i understand, it had a hack for such files before, and the hack broke?
[16:53:15 CEST] <Daemon404> i assume one of you located the hack then
[16:53:21 CEST] <wm4> I can look at it
[16:53:24 CEST] <wm4> I had fun with it before
[16:53:35 CEST] <wm4> it's a "let's fix a single sample with some hack" fix
[16:53:47 CEST] <wm4> and it has to do with timestamps
[16:53:59 CEST] <Daemon404> ok
[16:54:05 CEST] <Daemon404> i will poke vob right now then
[16:54:24 CEST] <Daemon404> although i assume closed captions in vob will be pain
[16:54:35 CEST] <Daemon404> (in an mpeg2 stream)
[16:54:37 CEST] <nevcairiel> the CC one is probably irrelevant
[16:54:40 CEST] <nevcairiel> its just display
[16:55:00 CEST] <nevcairiel> unless you want codecpar to have such a field to inform the user about the presence, ie. keeping the hack alive
[16:55:07 CEST] <Daemon404> ah ok
[16:55:15 CEST] <Daemon404> yeah i looked it and it was checkign avcyx->properties
[16:55:20 CEST] <Daemon404> but i didnt see it set anywhere in lavf
[16:55:26 CEST] <nevcairiel> its not
[16:55:32 CEST] <nevcairiel> its filled by the mpeg2 decoder during probing
[16:55:48 CEST] <wm4> Daemon404: av_dump-format creates a temporary avctx
[16:55:57 CEST] <Daemon404> ah...
[16:56:47 CEST] <Daemon404> the sample in the bug still has some ac3 issues
[16:56:52 CEST] <Daemon404> [ac3 @ 0x3743080] frame sync error
[16:56:57 CEST] <Daemon404> whatever that is
[16:56:59 CEST] <Daemon404> probably parsers
[16:57:30 CEST] <Daemon404> hmm yep
[16:57:35 CEST] <Daemon404> it needs to set the update falg
[16:57:37 CEST] <Daemon404> flag*
[16:59:16 CEST] <Daemon404> michaelni, since you asked, i added a way to mark issues unimportant
[16:59:28 CEST] <Daemon404> click add label -> unimportant
[17:01:57 CEST] <wm4> does anyone know how to select only 1 stream with ffprobe?
[17:02:44 CEST] <Daemon404> there's -select_stream or something iirc
[17:03:54 CEST] <Daemon404> oh good... i marked context neding update in vob and segfauly
[17:05:18 CEST] <Daemon404> oh. im just retarded. carry on.
[17:11:27 CEST] <cone-212> ffmpeg 03Martin Vignali 07master:d2ed3391fbfe: libavcodec/exr: fix PRX24 Float decompression
[17:11:27 CEST] <cone-212> ffmpeg 03Martin Vignali 07master:25a01c52b889: libavcodec/exr: add tile support
[17:12:46 CEST] <wm4> the mkv issue somehow has wrong timestamps in the first 6 packets or so
[17:13:01 CEST] <wm4> I bet it's a parser issue
[17:14:50 CEST] <Daemon404> wm4, there are no less than 3 issues open about ac3
[17:14:56 CEST] <Daemon404> theyre probably all the same issue
[17:17:11 CEST] <wm4> which ones?
[17:17:52 CEST] <Daemon404> https://github.com/dwbuiten/FFmpeg/issues/16 (ignore the cpations, look at the ac3 warnings)
[17:18:14 CEST] <nevcairiel> try setting frame_size from the parser
[17:18:16 CEST] <nevcairiel> or something
[17:18:26 CEST] <Daemon404> ok
[17:18:31 CEST] <Daemon404> https://github.com/dwbuiten/FFmpeg/issues/2
[17:18:37 CEST] <Daemon404> https://github.com/dwbuiten/FFmpeg/issues/8
[17:19:44 CEST] <Daemon404> nevcairiel, no dice, doesnt fix it
[17:20:09 CEST] <wm4> durandal_1707: you pushed code that can crash on unexpected input?
[17:21:07 CEST] <Daemon404> although i see a ton of stuff
[17:21:08 CEST] <durandal_1707> wm4: nope, I manually changed his code...
[17:21:31 CEST] <Daemon404> although i see a ton of stuff
[17:21:34 CEST] <Daemon404> woops
[17:21:39 CEST] <Daemon404> ... what the hell
[17:21:47 CEST] <Daemon404> the parser can update the codec id
[17:22:05 CEST] <Daemon404> because its used for multiple codecs (aac and ac3 and eac3)
[17:22:33 CEST] <wm4> how wonderful
[17:22:41 CEST] <nevcairiel> it can, but it doesnt really matter, as the decoder can handle both without problems
[17:22:53 CEST] <Daemon404> it lso updates channel layout and count
[17:22:56 CEST] <Daemon404> which currently isnt copied
[17:23:22 CEST] <nevcairiel> the decoder should be able to determine that without the parser either way
[17:23:52 CEST] <Daemon404> you would think so
[17:23:54 CEST] <Daemon404> but you would be wrong
[17:24:03 CEST] <Daemon404> copying those fixes those warnings/errors
[17:30:50 CEST] <Daemon404> wm4, it did not fix mkv
[17:30:55 CEST] <Daemon404> that seems to be separate
[17:40:01 CEST] <wm4> it has something to do with making up timestamps, I think
[17:40:22 CEST] <wm4> which is broken probably during find_stream_info
[17:42:14 CEST] <Daemon404> i see
[17:49:14 CEST] Action: Daemon404 installs libxvid to test
[17:51:54 CEST] <Daemon404> wm4, i assume you know where the offending code is
[17:52:05 CEST] <wm4> I have no idea what's going on
[17:52:13 CEST] <Daemon404> oh.
[17:57:08 CEST] <cone-212> ffmpeg 03Michael Niedermayer 07master:06c4ed0c0e34: avformat/wavdec: fix typo with len
[18:00:58 CEST] <wm4> or rather, I have no idea why this ever worked
[18:01:40 CEST] <Daemon404> lol i see
[18:02:06 CEST] <Daemon404> only two non-dump-related things left are this xvid thign im looking into and mkv, then
[18:02:50 CEST] <jfmcarreira> heyy guys 
[18:02:59 CEST] <jfmcarreira> are the application for GSoC closed?
[18:04:30 CEST] <kierank> yes
[18:05:07 CEST] <Daemon404> hey kierank do you know the teletext code?
[18:05:27 CEST] <wm4> hm shaping up to by my own fault
[18:05:33 CEST] <Daemon404> wm4, lol?
[18:05:54 CEST] <jfmcarreira> kierank: is it possible to still contribute to some of the task?
[18:06:18 CEST] <Daemon404> jfmcarreira, it's always possible to contribute, but you wont be paid by google, since yo uarent in gsoc
[18:06:40 CEST] <jfmcarreira> Daemon404: yeah that makes sense
[18:06:48 CEST] <kierank> Daemon404: no but I can help with teletext in general
[18:07:03 CEST] <jfmcarreira> there are some very interesting projects for me: the FFv1 and H.264 MVC  decoder
[18:07:37 CEST] <Daemon404> kierank, im just trying to find where the teletex width and height are set
[18:07:55 CEST] <Daemon404> context: https://github.com/dwbuiten/FFmpeg/issues/15
[18:08:05 CEST] <Daemon404> it might just be dump.c being crap, though
[18:08:17 CEST] <kierank> meaningless number afaik
[18:08:22 CEST] <kierank> it changes depending on the width of the data
[18:08:42 CEST] <nevcairiel> probably determined by the decoder
[18:08:47 CEST] <nevcairiel> now figure out why its no longer decoded
[18:09:24 CEST] <Daemon404> i love the two schools of taught
[18:09:30 CEST] <Daemon404> "it's meaningless" vs " better fix it"
[18:10:02 CEST] <kierank> it sets avctx->width and height to the maximum it's going to be
[18:10:09 CEST] <kierank> but then per frame it sets it to the actual 
[18:10:29 CEST] <Daemon404> kierank, i see
[18:10:33 CEST] <Daemon404> i get what you mean.
[18:10:44 CEST] <wm4> Daemon404: fixed the mkv thing
[18:10:52 CEST] <Daemon404> cool
[18:11:00 CEST] <Daemon404> ive found whats going wrong with the libxvid one
[18:11:30 CEST] <wm4> (quite questionable: the frame_size check, which I readded, disables sub-packet timestamps for the first block...)
[18:11:37 CEST] <Daemon404> (also in the last 2 years ive learned far too much about mov/mp4 for my own liking... such that it all makes sense to me in movenc.c)
[18:12:31 CEST] <wm4> I'm sorry
[18:13:11 CEST] <Daemon404> it looks like vos_len is being written wrong in the esds box
[18:13:39 CEST] <Daemon404> trk->vos_len  = par->extradata_size;
[18:13:45 CEST] <Daemon404> yep.
[18:14:51 CEST] <Daemon404> it's global extradata related
[18:15:04 CEST] <Daemon404> encode_frame is setting the global extradata
[18:15:15 CEST] <Daemon404> im guessing that isnt copied to codecpar
[18:16:55 CEST] <nevcairiel> setting it where?
[18:17:08 CEST] <Daemon404> libxvid.c sets it in encode_frame
[18:17:11 CEST] <Daemon404> after encoding every keyframe
[18:17:21 CEST] <Daemon404> (its only used once in movenc.c obviously)
[18:17:54 CEST] <Daemon404> er, it ses it on the first keyframe.
[18:18:10 CEST] <nevcairiel> same problem as in demuxers, i guess, producing extradata after init is not supported
[18:18:28 CEST] <nevcairiel> in this case, its practically unfixable
[18:18:31 CEST] <Daemon404> libx264 and libx265 both set it in _init
[18:18:33 CEST] <Daemon404> which is proper
[18:18:53 CEST] <nevcairiel> unless with a bunch of mov-specific hacks
[18:18:57 CEST] <nevcairiel> that just happen to work because
[18:19:09 CEST] <Daemon404> lol well
[18:19:30 CEST] <Daemon404> libxvid.c literally checks:
[18:19:30 CEST] <Daemon404>     int quicktime_format;          /**< Are we in a QT-based format? */
[18:20:00 CEST] <nevcairiel> its controlled by AV_CODEC_FLAG_GLOBAL_HEADER
[18:20:00 CEST] <Daemon404> which is set during init based off GLOBAL_HEADER
[18:20:02 CEST] <nevcairiel> like the others
[18:20:03 CEST] <Daemon404> yes
[18:20:09 CEST] <nevcairiel> but it needs to generate the header earlier
[18:20:15 CEST] <nevcairiel> otherwise it might be screwed
[18:20:25 CEST] <Daemon404> i think the lib can
[18:20:29 CEST] <Daemon404> but i may be wrong
[18:20:32 CEST] <Daemon404> the api is pretty shitty
[18:21:10 CEST] <nevcairiel> most of the demux shit we could fix because there is find_stream_info that runs the demuxer and decoder for a few frames to gather info
[18:21:15 CEST] <nevcairiel> but in encoding, there is no such thing
[18:21:35 CEST] <nevcairiel> its either present right away, or not at all
[18:21:40 CEST] <Daemon404> the only reason it works for mov is because the header is written at the end of the file
[18:21:44 CEST] <Daemon404> it *happens* to work
[18:22:06 CEST] <nevcairiel> yeah, except that now at the beginning the codecpar is created from the avctx just once
[18:22:28 CEST] <nevcairiel> no matter how late mov reads it
[18:24:26 CEST] <Daemon404> https://ffmpeg.org/pipermail/ffmpeg-devel/2012-April/122894.html
[18:24:35 CEST] <Daemon404> it looks like nicholas attempted to fix this once
[18:26:22 CEST] <Daemon404> it looks like it never went anywhere
[18:27:07 CEST] <Daemon404> in fact that is the first google result for the API...
[18:28:59 CEST] <wm4> Daemon404: anything else I could briefly look into?
[18:29:25 CEST] <Daemon404> teletext
[18:30:23 CEST] <wm4> I bet this is also a display issue
[18:30:37 CEST] <wm4> I'll make sure whether it is
[18:33:47 CEST] <wm4> even on master I get:
[18:33:48 CEST] <wm4>     Stream #0:2[0x240](eng): Subtitle: dvb_teletext ([6][0][0][0] / 0x0006), 492x250
[18:33:48 CEST] <wm4>     Stream #0:6[0x247](eng): Subtitle: dvb_teletext ([6][0][0][0] / 0x0006)
[18:33:56 CEST] <wm4> err that's 2.8, but still
[18:39:28 CEST] <wm4> is .ts really fixed?
[18:41:00 CEST] <wm4> uh, this might depend on whether you have compiled with libzvbi
[18:41:11 CEST] <JEEB> o_O
[18:46:50 CEST] <michaelni> codecpar: libavformat/xmv.c:        if (avio_read(pb, data, 4) != 4) { printf("WUT\n"); 
[18:49:02 CEST] <wm4> michaelni: removed that
[18:49:20 CEST] <michaelni> thx
[18:50:03 CEST] <rcombs> wut
[18:51:22 CEST] <nevcairiel> code should wut more
[18:51:26 CEST] <Daemon404> lol shit
[18:51:33 CEST] <Daemon404> sorry, i left in a debug printf
[18:51:47 CEST] <nevcairiel> didnt we have some evil crap somewhere to make printf error
[18:51:53 CEST] <nevcairiel> or was that removed
[18:51:54 CEST] <Daemon404> that got removed
[18:53:05 CEST] <Daemon404> cool... fixed libxvid.c
[18:53:15 CEST] <Daemon404> will send patch to ML
[18:57:34 CEST] <rcombs> Daemon404: *points at av_log*
[18:58:17 CEST] <Daemon404> rcombs, i am not going to debug with avlog
[18:58:23 CEST] <Daemon404> its like 10x the typing
[18:58:41 CEST] <nevcairiel> av_log(0,0, "message") isnt that long =p
[18:59:22 CEST] <Daemon404> ;p
[18:59:35 CEST] Action: Compn wonders how many people use 'yadif' now vs other filters
[19:00:16 CEST] <rcombs> PMS uses yadif
[19:00:41 CEST] <jamrial> i'm going to guess yadif is still used the most because why switch?
[19:01:22 CEST] <Daemon404> wm4, can you look at pulse... i dont think nev or i even have somethign capable of testing it
[19:02:19 CEST] <wm4> what's wrong with pulse? didn't it get converted?
[19:02:39 CEST] <Daemon404> michael just filed a bug
[19:05:30 CEST] <cone-212> ffmpeg 03Hendrik Leppkes 07master:6518cbc52a8c: lavc/utils: Introduce ff_bprint_to_codecpar_extradata for avformat
[19:15:27 CEST] <Daemon404> hmmm
[19:15:34 CEST] <Daemon404> seems avg_frame_rate is not copied over when doing -c opy?
[19:15:38 CEST] <Daemon404> -c copy*
[19:18:12 CEST] <Daemon404> ok i see what to do...
[19:18:13 CEST] <Daemon404> barf
[19:22:33 CEST] <cone-212> ffmpeg 03Paul B Mahol 07master:76466ab214ef: avformat/brstm: lower magic number, fixes decoding of some files
[19:34:33 CEST] <durandal_1707> how many unresolved codecpar issues remain?
[20:04:01 CEST] <cone-212> ffmpeg 03Claudio Freire 07master:bad41d372422: AAC encoder: fix initialization of minsf
[20:22:29 CEST] <Daemon404> durandal_1707, as of right now: all related to dump.c, none of which are breaking files afaik
[20:22:36 CEST] <Daemon404> also wm4 nevcairiel ^
[20:24:23 CEST] <wm4> CLOSED WONTFIX
[20:24:49 CEST] <Daemon404> there's one at least i think merits a look
[20:24:52 CEST] <Daemon404> https://github.com/dwbuiten/FFmpeg/issues/9
[20:25:51 CEST] <nevcairiel> i didnt find where it sets that on a cursory look
[20:28:40 CEST] <Daemon404> -    if (st->sample_aspect_ratio.num && // default
[20:28:40 CEST] <Daemon404> -        av_cmp_q(st->sample_aspect_ratio, st->codec->sample_aspect_ratio)) {
[20:28:43 CEST] <Daemon404> +    if (st->sample_aspect_ratio.num) {
[20:28:43 CEST] <Daemon404> related?
[20:28:45 CEST] <Daemon404> in dump.c
[20:28:51 CEST] <cone-212> ffmpeg 03Claudio Freire 07master:52562503d524: AAC encoder: new regression test
[20:29:02 CEST] <nevcairiel> so you think its just dump.c doing that?
[20:29:21 CEST] <nevcairiel> if anything it should compare codecpar AR instead of just removing the compare
[20:29:45 CEST] <Daemon404> let me check if that is it
[20:29:49 CEST] <Daemon404> and add it back if so
[20:29:51 CEST] <Daemon404> with par
[20:30:13 CEST] <Daemon404> (btw found via : git diff b044dd37445d50420fa6929a43de7733fa93bee3^..HEAD | grep st->sample_aspect)
[20:35:09 CEST] <Guest50893> Hi Guys
[20:35:45 CEST] <Guest50893> Any one has a working SCTE 35 decoder?
[20:39:14 CEST] <Daemon404> hmm
[20:39:15 CEST] <Daemon404> michaelni, ping
[20:39:35 CEST] <Daemon404> mpeg2_field_encoding.ts from FATE doesnt match what you filed in the bug
[20:40:14 CEST] <Daemon404> OH, its output dump
[20:40:50 CEST] <Daemon404> ok
[20:40:54 CEST] <Daemon404> nevcairiel, adding back that check with codecpar fixes the double AR issue. pushed it.
[20:48:15 CEST] <Daemon404> ok... no other regressions left at the moment except some dump.c stuff which seems pretty iffy
[20:48:55 CEST] <jamrial> time to rebase and see it explode? :p
[20:50:01 CEST] <Daemon404> jamrial, depends
[20:50:10 CEST] <Daemon404> i want wanna start that and then michael files 90 more bugs midway
[20:52:06 CEST] <Daemon404> jamrial, the merge diff is 1.4mb
[20:52:10 CEST] <Daemon404> the size of a goddam floppy
[20:55:24 CEST] <Daemon404> hmm
[20:55:32 CEST] <Daemon404> looks like rebaseing was pretty painless
[20:55:37 CEST] <Daemon404> only a few conflicts
[20:56:07 CEST] <Daemon404> nevcairiel, is there other stuff you want to break out and send to the ML separately before i rebase
[20:56:34 CEST] <nevcairiel> i didnt see an ything obvious
[20:56:44 CEST] <Daemon404> is that a go-ahead? :)
[20:56:55 CEST] <wm4> do it
[20:57:20 CEST] <Daemon404> even if there are more bugs... its a step closer to master.
[20:57:52 CEST] <nevcairiel> go-ahead for what
[20:58:08 CEST] <Daemon404> rebasing / squashing onto master
[20:58:10 CEST] <Daemon404> in a branch
[20:58:43 CEST] <durandal_1707> Push upstream
[20:59:39 CEST] <jamrial> i'd say yes, any further testing should be done post rebase
[20:59:57 CEST] <Daemon404> cool
[20:59:59 CEST] <jamrial> the branch is like 300 commits behind master
[21:00:02 CEST] <Daemon404> yea
[21:04:48 CEST] <nevcairiel> sure, can start reviewing as well t hen
[21:06:25 CEST] <Daemon404> nevcairiel, i was planning on squashing it into the merge commit, but im open to other methods
[21:16:30 CEST] <Daemon404> thanks for review michaelni, will update once im done rebasing
[21:23:31 CEST] <Daemon404> wm4, looks like more matroska hacks were added recently
[21:23:39 CEST] <wm4> lol
[21:23:48 CEST] <Daemon404>         if (codec->bits_per_raw_sample)
[21:23:48 CEST] <Daemon404>             bit_depth = codec->bits_per_raw_sample;
[21:23:48 CEST] <Daemon404>         else
[21:23:48 CEST] <Daemon404>             bit_depth = av_get_bytes_per_sample(codec->sample_fmt) << 3;
[21:23:54 CEST] <wm4> oh that
[21:24:08 CEST] <Daemon404> not sure how to fis that conflict
[21:24:43 CEST] <wm4> nevcairiel did that
[21:24:47 CEST] <wm4> it's of course for FLAC
[21:25:03 CEST] <wm4> but codec params has only bits_per_codec_sample right?
[21:25:12 CEST] <Daemon404> coded
[21:25:12 CEST] <Daemon404> but yes
[21:25:37 CEST] <wm4> let me check the ML
[21:26:38 CEST] <wm4> I wish I had a better mail client
[21:26:56 CEST] <nevcairiel> its just annoying that we dont have a 24-bit sample format, it makes carrying around bitdepth mandatory
[21:27:05 CEST] <fritsch> :-)
[21:27:11 CEST] <Daemon404> nevcairiel, yes
[21:27:12 CEST] <Daemon404> also
[21:27:13 CEST] <Daemon404> mkv_write_video_color exists now
[21:27:21 CEST] <Daemon404> which for somer eason uses codec context AND side data>
[21:27:22 CEST] <Daemon404> wtf?
[21:27:46 CEST] <Daemon404> it's also unofficial / not spec
[21:28:20 CEST] <nevcairiel> the color info it wants should be in codecpar
[21:28:23 CEST] <Daemon404> ah ok it can use codecpar
[21:28:28 CEST] <Daemon404> for some reason i thought par ddint have it
[21:29:01 CEST] <wm4> me too
[21:29:04 CEST] <nevcairiel> i dont know why that guy pushed for these patches already being included before the spec was actually finally
[21:29:14 CEST] <nevcairiel> even if its under a experimental flag
[21:30:18 CEST] <Daemon404> me neither
[21:30:31 CEST] <Daemon404> ok matroskadec conflicts done except for the raw_sample stuff
[21:30:34 CEST] <Daemon404> what do?
[21:31:06 CEST] <wm4> this was the ticket it was supposed to solve https://trac.ffmpeg.org/ticket/5332
[21:32:26 CEST] <Daemon404> lovely
[21:32:59 CEST] <wm4> maybe bits_per_codec_sample can be used?
[21:33:22 CEST] <wm4> isn't that what we want anyway (but I have no clue)
[21:45:38 CEST] <Daemon404> ok
[21:45:42 CEST] <Daemon404> that is the last remaining conflict now nevcairiel 
[21:45:46 CEST] <Daemon404> not sure what to do
[21:57:22 CEST] <Daemon404> nevcairiel, no ideas?
[22:03:51 CEST] <jamrial> Daemon404: reading bits_per_raw_sample from st->internal->avctx is not possible? or it is, but too hacky?
[22:04:18 CEST] <nevcairiel> muxers dont have any values in there
[22:04:48 CEST] <nevcairiel> and no, no ideas, bits_per_coded might work
[22:05:32 CEST] <wm4> nevcairiel: it probably will for flac, but I'm worried about it writing nonsense for other cases
[22:05:50 CEST] <wm4> jamrial: it's broken due to the API
[22:06:06 CEST] <wm4> so either bits_per_coded works, or codecpar needs to be extended
[22:09:10 CEST] <Daemon404> what exactly is the difference between bits_per_coded and bits_per_raw
[22:11:23 CEST] <Daemon404> wm4, if(flac)? i dunno. seems shitty.
[22:11:32 CEST] <Daemon404> i currently just commented that bit out so i could run fate
[22:15:09 CEST] <wm4> good question
[22:15:36 CEST] <Daemon404> running fate right now, then i will push the rebased branch
[22:15:43 CEST] <Daemon404> with a list of any failures
[22:19:00 CEST] <Daemon404> only 1 failure
[22:25:14 CEST] <Daemon404> seems tests/ref/fate/rv20-1239 fails
[22:25:26 CEST] <Daemon404> starts at 1 now instead of 0
[22:27:32 CEST] <Daemon404> nevcairiel, wm4, michaelni, ubitux - https://github.com/dwbuiten/FFmpeg/tree/codecpar_rebase
[22:29:12 CEST] <ubitux> oh nice
[22:29:17 CEST] <ubitux> i'm sorry i wasn't of very much help
[22:29:34 CEST] <Daemon404> theres one new fate failure from a test michaelni added on friday
[22:30:21 CEST] <ubitux> when is the push due? (or said differently: how long do we have for the review?)
[22:30:52 CEST] <Daemon404> michaelni suggested 48h with no breaking regressions before push
[22:30:58 CEST] <ubitux> (Daemon404: nit: you used my old mail i'm not watching anymore :P)
[22:31:12 CEST] <Daemon404> ubitux, sure ill ammend it when i next squash
[22:34:21 CEST] <wm4> <Daemon404> michaelni suggested 48h with no breaking regressions before push <- so never?
[22:34:40 CEST] <wm4> I suggest we suggest something else
[22:37:39 CEST] <Daemon404> heh
[22:37:46 CEST] <Daemon404> up to you guys
[22:38:19 CEST] <Daemon404> i would like it sooner rather than later of course
[22:48:21 CEST] <Daemon404> ughhhhh
[22:48:25 CEST] <Daemon404> wm4, i think this is lowres
[22:48:38 CEST] <Daemon404> michaelni, that rv20 sample is lowres right?
[22:49:26 CEST] <Daemon404> +fate-rv20-1239: CMD = framecrc -flags +bitexact -idct simple -lowres 1 -i $(TARGET_SAMPLES)/real/G2_with_SVT_320_240.rm
[22:49:29 CEST] <Daemon404> yep
[22:49:34 CEST] <Daemon404> nevcairiel, too ^
[22:51:47 CEST] <Daemon404> ubitux, this answers your question btw 
[22:52:19 CEST] <ubitux> it was also because of lowres in dv, i'm just wondering where in the code
[22:54:41 CEST] <jamrial> are fate-vp6a and fate-vp6a-skip_alpha really going to be declared "fixed" by changing the sample from flv to mov?
[22:55:03 CEST] <Daemon404> jamrial, the problem is in ffmpeg.c
[22:55:06 CEST] <Daemon404> it uses the api wrong
[22:55:25 CEST] <wm4> not "wrong", just in a less than ideal way
[22:55:43 CEST] <wm4> which happens to make it very hard to actually test what the test is supposed to test
[22:56:02 CEST] <Daemon404> mostly it was coincidence it worked before
[22:56:06 CEST] <Daemon404> afaict
[22:56:44 CEST] <wm4> yeah, basically
[22:57:56 CEST] <Daemon404> ubitux, i dont know
[22:58:15 CEST] <Daemon404> ls
[22:58:17 CEST] <Daemon404> woops
[23:05:11 CEST] <Daemon404> so the only outstanding issue: lowres
[23:07:02 CEST] <Daemon404> ubitux, look in rv10_decode_init
[23:07:10 CEST] <Daemon404> maybe you can shed some light
[23:07:38 CEST] <wm4> isn't it because the demuxer will export the reduced resolution
[23:07:46 CEST] <wm4> which makes the decoder fail init
[23:07:48 CEST] <wm4> i.e. dumb shit
[23:08:08 CEST] <Daemon404> i dont understand lowres very well
[23:08:13 CEST] <Daemon404> in fact i was in favour or removing it
[23:08:15 CEST] <Daemon404> o*
[23:08:16 CEST] <Daemon404> of*
[23:08:34 CEST] <BBB> I dont see why a demuxer would care at all about lowres being enabled or not
[23:08:50 CEST] <BBB> just like a muxer should typically not care about crf vs. vbr
[23:09:09 CEST] <BBB> (except broken microsoft formats that store vbr in the stream header)
[23:09:14 CEST] <BBB> (bitrate)
[23:09:22 CEST] <Daemon404> wm4, i dont see lowres checked anywhere
[23:09:24 CEST] <Daemon404> in lavf
[23:09:34 CEST] <Daemon404> or is it some find_stream_info crap again
[23:09:39 CEST] <wm4> maybe
[23:09:59 CEST] <wm4> BBB: well I don't know the details either
[23:10:12 CEST] <wm4> BBB: but if it's the demuxer... the demuxer can open a decoder
[23:10:16 CEST] <wm4> to detect stream infos
[23:10:34 CEST] <wm4> so if lowres is somehow passed down to the decoder
[23:10:56 CEST] <wm4> and AFAIK git master avoids this by passing coded_width instead, which is not changed by lowres?
[23:11:07 CEST] <wm4> anyway I'm off
[23:11:10 CEST] <Daemon404> cya
[23:11:55 CEST] <Daemon404> well people are gonna have to agree on some solution
[23:12:07 CEST] <Daemon404> merge waiting on lowres is just depressing
[23:12:30 CEST] <Compn> lowres is useful in some cases :P
[23:12:36 CEST] Action: Compn runs
[23:12:39 CEST] <Daemon404> michaelni's patch on the ML fixes it, but i know people dont like it
[23:12:43 CEST] <JEEB> very limited by now though
[23:12:46 CEST] <Daemon404> so... :psyduck:
[23:12:51 CEST] <Compn> it would be great for 4k
[23:12:59 CEST] <JEEB> since most low-power devices have HW decoders
[23:13:11 CEST] <JEEB> and those formats used for high-res/high frame rate content usually dont support lowres
[23:13:12 CEST] <Daemon404> no codec people use for 4k has lowres support
[23:13:17 CEST] <Daemon404> unless you want MPEG-2 4k
[23:14:10 CEST] <BBB> find_stream_info needs to be fixed to not apply lowres twice then
[23:14:14 CEST] <BBB> I mean this is all so basic
[23:14:24 CEST] <BBB> you guys are applying hacks to hacks to hack your hack around hacks that are hacky and broken
[23:14:27 CEST] <BBB> dont do that
[23:14:49 CEST] <BBB> why do you think people hate lowres?
[23:14:58 CEST] <BBB> dont make that sentiment worse
[23:15:27 CEST] <Compn> stop the rumor mill ?
[23:15:55 CEST] <michaelni> unless iam missing something its easy to fix lowres if you are willing to break API/ABI if you want to keep API its hacky
[23:18:03 CEST] <michaelni> the thing is API "requires" the demuxer to give width/height in AVCodecContext dependant on lowres, it was the decoders presentation width/height 
[23:19:14 CEST] <michaelni> and with that things get hacky, either you have a 2nd set of width & height as in my patch or you become creative how to hack around that
[23:21:17 CEST] <michaelni> IMHO the 2nd set is not that bad as one would be coded and one displayed (aka crop) and crop can be stored in the demuxer layer
[23:22:37 CEST] <michaelni> anyway iam happy about any other solution as well
[23:23:24 CEST] Action: Daemon404 has no opinion or idea to fix 
[23:25:03 CEST] <Daemon404> it's the only breakage (discovered) left in codecpar atm though
[23:25:06 CEST] <Daemon404> so me = sad
[23:25:46 CEST] <durandal_1707> why, lowers shouldn't change w/h
[23:25:56 CEST] <durandal_1707> seems fishy
[23:26:09 CEST] <durandal_1707> It's just decoder option
[23:26:12 CEST] <Daemon404> it's been explained above
[23:26:29 CEST] <jamrial> disable the test, push upstream, wait for people that actually use lowres to complain if they exist :p
[23:26:47 CEST] <Daemon404> those people are Compn, michaelni, and ami_stuff, maybe carl
[23:26:53 CEST] <Daemon404> for non-dev users... who knows
[23:27:04 CEST] <durandal_1707> break lowered api its hacky anyway
[23:27:16 CEST] <durandal_1707> lowres*
[23:27:25 CEST] <Daemon404> yeah im sure that will go over well
[23:27:35 CEST] <Daemon404> and is not at all controversial or likely to cause glames
[23:28:50 CEST] <Daemon404> flames*
[23:38:42 CEST] <Daemon404> michaelni, assuming nothing fundementally broken pops up (and lowres gets fixed), tentatively i want to push the merge some time this week
[23:58:00 CEST] <michaelni> Daemon404, this week (that is within the next 7 days) sounds realistic/doable to me
[23:58:11 CEST] <Daemon404> yes, to me too
[23:58:27 CEST] <Daemon404> i would prefer before the end of friday, personally though
[23:58:36 CEST] <Daemon404> since i am flying back to europe friday night
[23:58:41 CEST] <Daemon404> and saturday will be jetlagged
[00:00:00 CEST] --- Mon Apr  4 2016