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

[burek]

[02:54:39 CET] <atomnuker> what's the point of audio_frame_queue?
[02:54:59 CET] <atomnuker> seems to only keep track of samples used for the current frame and just warns if you use less
[03:24:54 CET] <rcombs> atomnuker: manages timestamps in output frames for codecs with delay
[03:25:17 CET] <rcombs> or, well, packets
[07:56:26 CET] <la> http://oortr.com/ZjllYz
[10:05:36 CET] <cone-952> ffmpeg 03Paul B Mahol 07master:50f4b64c543d: avfilter/vf_waveform: set color range for output frames
[11:24:13 CET] <cone-952> ffmpeg 03Michael Niedermayer 07master:7916f04b89d4: ffplay: Remove "&& 0" from already disabled debug code
[11:32:28 CET] <kurosu> TheRyuu, could you provide your opinion on a breakage from a patch of yours: http://mplayerhq.hu/pipermail/ffmpeg-devel/2016-March/191195.html ? Thanks.
[14:41:19 CET] <ubitux> 5 FIXME in lavf/dv.c meh
[14:57:58 CET] <Daemon404> wait today is Sunday, wtf
[14:59:52 CET] <J_Darnley> Yes it is.
[15:00:06 CET] <Compn> palm sunday
[15:00:09 CET] <Compn> next week is easter
[15:00:16 CET] <Compn> stupid holidays.
[15:08:29 CET] <Daemon404> i thought yesterday was sunday.... man sickness threw me right off
[15:08:37 CET] <Daemon404> s/man/man,/
[15:11:44 CET] <J_Darnley> Being sick will do that
[15:18:09 CET] <Compn> Daemon404 : its ok, i was hoping today was monday as well.
[16:25:34 CET] <Daemon404> ubitux, have you started poking codecpar
[16:26:15 CET] <ubitux> yes
[16:26:19 CET] <ubitux> i'm "playing" with dv
[16:26:21 CET] <Daemon404> ok
[16:26:29 CET] <Daemon404> so you picked one of the most annoying onces
[16:26:44 CET] <ubitux> well i did merge it last time but wasn't satisfied with the outcome
[16:26:50 CET] <Daemon404> ok
[16:26:58 CET] <ubitux> if the last patch i sent is accepted it should be fine
[16:27:06 CET] <Daemon404> michael ok'd it i think
[16:27:07 CET] <ubitux> i can work on some other area now
[16:27:11 CET] <ubitux> yes, the first one
[16:27:14 CET] <ubitux> i sent another one
[16:27:54 CET] <Daemon404> looks reasonable.
[16:28:07 CET] <Daemon404> just waiting for dist-upgarde to finish and im starting to poke stuff
[16:28:24 CET] Action: Daemon404 has merge-guilt
[16:28:29 CET] <Daemon404> wanna get it done now...
[16:28:51 CET] <ubitux> any idea what i should look at now?
[16:29:01 CET] <Daemon404> nevcairiel would know best what to prioritize
[16:29:17 CET] <Daemon404> movenc is causing a lot of fate failues
[16:29:18 CET] <Daemon404> so maybe that
[16:31:50 CET] <ubitux> i feel like this is a trap
[16:32:05 CET] <ubitux> but i guess all the remaining issues are trap
[16:32:10 CET] <Daemon404> pretty much
[16:32:15 CET] <Daemon404> except some monkey work
[16:32:18 CET] <Daemon404> like porting lib*c
[16:32:43 CET] <Daemon404> i was going to look into the nut failures
[16:32:46 CET] <Daemon404> wrt ffprobe
[16:33:52 CET] <ubitux> i'll start fixing the cc issue
[16:34:05 CET] <ubitux> (fate-sub-cc)
[16:34:14 CET] <Daemon404> theres something timebasey in microdvdenc too
[16:34:17 CET] <Daemon404> isnt that a subtitle format
[16:34:19 CET] <Daemon404> or am i misrememberong
[16:38:15 CET] <Daemon404> oh there's a bumch of avfilter stuff that accesses ->codec it seems.
[16:42:04 CET] Action: Daemon404 builds multiple ffmpeg's to compare fate output
[16:42:17 CET] <Daemon404> is there a tool less crappy than vsbindiff yet for binary diffing in cli?
[16:43:17 CET] <ubitux> xxd and vimdiff
[16:43:30 CET] <Daemon404> that doesnt work very well when size changes ubitux 
[16:43:42 CET] <ubitux> :(
[16:46:20 CET] <ubitux> mmh i guess the cc issue is also related to lavfi
[16:46:34 CET] <Daemon404> figures
[16:46:45 CET] <Daemon404> im starting to go through fate tests with vbindiff atm
[16:46:51 CET] <Daemon404> ill update any hashes where it makes sense
[16:46:55 CET] <Daemon404> fix muxers elsewhere
[16:52:07 CET] <Daemon404> looks like lavf-mkv changed one DURATION tag due to use of stream timebase instead of codec timebase
[16:52:17 CET] <Daemon404> im thinking that ought to be a hash update.
[16:56:13 CET] <Daemon404> ubitux, mark any stuff fixed on the pad btw
[16:56:38 CET] <ubitux> ok
[16:57:16 CET] <Daemon404> ... lol fate refs with merge conflicts
[17:02:37 CET] <ubitux> i suppose we're not going to add the timebase to codecpar?
[17:04:41 CET] <Daemon404> i argue it still makes no sense to have a "codec" timebase.
[17:04:50 CET] <Daemon404> bframes/delay will likely be added though
[17:05:13 CET] <Daemon404> ubitux, at least a few of these lavf fate tests write identical files but fail with lavfi errors
[17:05:14 CET] <ubitux> so we need to update every decoder using it?
[17:05:21 CET] <Daemon404> yes thats how this works
[17:05:38 CET] <ubitux> so that "lavf" commit/merge is also going to include all kind of changes to lavc?
[17:05:56 CET] <Daemon404> ubitux, no
[17:06:12 CET] <Daemon404> this is only for things using the codec time_base in stream->codec
[17:06:23 CET] <Daemon404> which should be using the stream timebase IMO
[17:06:52 CET] <ubitux> the thing is, apparently in lavc/ccaption_dec, codec time_base is 0/1
[17:07:03 CET] <ubitux> so it breaks the timing
[17:07:12 CET] <ubitux> how to proceed here?
[17:07:18 CET] <Daemon404> you need to be a bit clearered
[17:07:20 CET] <Daemon404> why did it break now
[17:07:25 CET] <Daemon404> because it was not set in lavf?
[17:07:32 CET] <Daemon404> was it using it as some shitty way to pass stream timebase?
[17:07:46 CET] <ubitux> well, i'd like to know if it's wrong for the codec to actually access it
[17:07:56 CET] <ubitux> or if the issue is because it's not set
[17:08:14 CET] <Daemon404> why would anything but lavc decoder set a codec timebase
[17:08:28 CET] <Daemon404> it sounds like the issue youre seeing is that teh codec tb is no longer set in lavf
[17:08:35 CET] <Daemon404> which sounds all sorts of wrong
[17:11:21 CET] <Daemon404> hmmm where is wm4 or nevcairiel when you need them
[17:16:00 CET] <nevcairiel> the question is where did it get the value before
[17:18:34 CET] <nevcairiel> and why did lavf need to set it
[17:18:55 CET] <nevcairiel> if there is a real need for the codec timebase, we can always re-introduce it with proper documentation and reasoning
[17:19:51 CET] <Daemon404> nevcairiel, i had a different question actually =p
[17:20:08 CET] <Daemon404> trying to figure out api-h264 failure
[17:20:22 CET] <Daemon404> pkt->duration went from all 48000 to all 0
[17:20:30 CET] <Daemon404> didnt find much in rawdec
[17:20:47 CET] <nevcairiel> i was going to say has_b_frames, but thats fate-h264-conf, not api-h264
[17:21:14 CET] <Daemon404> yeah this is unrelated to bframes.
[17:21:39 CET] <nevcairiel> i wondered about the lack of duration there
[17:21:43 CET] <nevcairiel> not sure how its determined
[17:21:50 CET] <nevcairiel> what does api-h264 use as a source file?
[17:21:58 CET] <Daemon404> h264-conformance/SVA_NL2_E.264
[17:22:01 CET] <Daemon404> it's an elementary stream
[17:22:23 CET] <nevcairiel> so maybe its being silly and just basing this off of the codec timebase which it lost?
[17:22:30 CET] <Daemon404> yeah but *where*
[17:22:37 CET] <nevcairiel> utils.c probably
[17:22:37 CET] <nevcairiel> :D
[17:22:39 CET] <Daemon404> D:
[17:23:37 CET] <nevcairiel> actually it uses the stream timebase
[17:23:38 CET] <Daemon404> i mean it looks correct for a sample stream
[17:23:40 CET] <Daemon404> it works out to 25 fps
[17:23:51 CET] <Daemon404> is this parser related?
[17:24:02 CET] <Daemon404> i dunno how it got that info or where from before
[17:24:07 CET] <Daemon404> elementary stream stuff in lavf is "special"
[17:24:35 CET] <nevcairiel> not sure right now, and i need to run grab dinner
[17:24:41 CET] <Daemon404> k
[17:24:59 CET] <nevcairiel> but pkt->duration isnt set in all that many places
[17:25:19 CET] <nevcairiel> you could poke in ff_compute_frame_duration
[17:25:33 CET] <Daemon404> ok
[17:25:54 CET] <nevcairiel> not sure what i did to that in  codecpar
[17:26:01 CET] <nevcairiel> maybe it needs to use the internal avctx or something
[17:27:13 CET] <Daemon404> interestingly, ffmpeg cli shows it as 25 fps, correctly
[17:28:45 CET] Action: Daemon404 stares at set_codec_from_probe_data in awe
[17:35:18 CET] <ubitux> Daemon404: yes, the time_base in st->codec->time_base is not set anymore, so when ffmpeg decodes with a copy of that codec context, shit breaks
[17:35:37 CET] <ubitux> ccaption_dec expect that field to be set
[17:36:55 CET] <ubitux> (there is all kind of time "adjustment" wrt sub->{pts,end_display_time})
[17:38:29 CET] <Daemon404> i got that
[17:38:38 CET] <Daemon404> but i am askign where it is expecting it to be set *from*
[17:38:43 CET] <Daemon404> where does that value come from that ccaptiondec uses
[17:38:51 CET] <Daemon404> thats kind of a fundemental question
[17:42:10 CET] <Daemon404> ok... solved the pkt duration failures
[17:42:27 CET] <Daemon404> seems ffmpeg changed ff_compute_frame_duration to ignore avg_frame_rate entirely at some point
[17:42:31 CET] <Daemon404> wtf?
[17:42:44 CET] <Daemon404> (in favour of r_frame_rate, with no fallback to avg)
[17:47:17 CET] <Daemon404> anyway... fixed
[17:47:21 CET] <ubitux> ok found it
[17:47:27 CET] <ubitux> avformat_new_stream()
[17:47:29 CET] <ubitux>         /* default pts setting is MPEG-like */
[17:47:31 CET] <ubitux>         avpriv_set_pts_info(st, 33, 1, 90000);
[17:47:33 CET] <ubitux> :-°
[17:47:46 CET] <ubitux> i guess i'll hardcode 1/90000 in ccaption_dec then
[17:48:45 CET] <JEEB> :D
[17:49:04 CET] <Daemon404> ubitux, do we not have a constant for mpeg timebase
[17:49:28 CET] <ubitux> can't find any
[17:49:35 CET] <ubitux> libavformat/hls.c:#define MPEG_TIME_BASE 90000
[17:49:37 CET] <ubitux> just this one
[17:49:37 CET] <Daemon404> lol
[17:49:50 CET] <ubitux> probably not the best place...
[17:50:13 CET] <Daemon404> its used in a lot of places, but eh... out of scope here
[17:50:17 CET] <Daemon404> ignore me.
[17:51:06 CET] <ubitux> any idea where the stream time base is copied to the stream codec timebase?
[17:52:45 CET] <Daemon404> i'd grep but FATE is bogging down my machine
[17:52:53 CET] <Daemon404> opening a new terminal is effort
[17:54:37 CET] <ubitux> i wonder if it's really ok to hardcode mpeg timebase into ccaption decoder though
[17:55:00 CET] <Daemon404> can ccaption be in anything but mpegts?
[17:55:29 CET] <ubitux> mov etc
[17:55:35 CET] <ubitux> wtv
[17:55:37 CET] <kierank> can be in anything
[17:56:12 CET] <JEEB> if it's the in-AVC stuff then indeed
[17:57:24 CET] <Daemon404> does the spec say what timebase it's in?
[17:58:13 CET] <kierank> it's cfr
[17:58:23 CET] <kierank> so it has a bunch of supported framerates
[17:59:30 CET] <Daemon404> kierank, so it's based on the framerate coded in the h264 bitstream?
[17:59:35 CET] <Daemon404> (aka not container)
[17:59:51 CET] <kierank> iirc there's a framerate code in the closed caption data
[17:59:57 CET] <ubitux> the subtitles decoders are supposed to output subtitles pts in AV_TIME_BASE_Q (and start/end time in ms)
[18:00:06 CET] <kierank> LOL
[18:00:06 CET] <ubitux> so lavc actually needs to know the stream time base
[18:00:11 CET] <kierank> what a fail
[18:00:16 CET] <kierank> milliseconds...
[18:00:27 CET] <kierank> when will OSS learn milliseconds are a shit timebase
[18:00:40 CET] <ubitux> AVSubtitle is one of the very old struct
[18:00:46 CET] <Daemon404> wait
[18:00:47 CET] <ubitux> i never changed since the beginning
[18:00:55 CET] <Daemon404> if there is a framerate code in the caption data
[18:01:00 CET] <Daemon404> why do we need the stream timebase
[18:01:09 CET] <Daemon404> just for start_time adjustment?
[18:01:41 CET] <kierank> there might not be a framerate code I forget
[18:01:50 CET] <Daemon404> also AV_TIME_BASE_Q is not ms
[18:01:51 CET] <Daemon404> it is us
[18:01:56 CET] <Daemon404> iirc.
[18:02:05 CET] <kierank> again useless timebase
[18:02:05 CET] <ubitux> most (all other?) subtitles decoders do the scaling from the stream timebase to AV_TIME_BASE_Q and ms into lavc/utils
[18:02:15 CET] <ubitux> by using the avctx->time_base copied from the stream timebase
[18:02:33 CET] Action: kierank stops trolling
[18:02:35 CET] <ubitux> but ccaption_dec does it inside the decoder because there is some delay thing involved
[18:03:01 CET] <Daemon404> wut
[18:03:05 CET] <ubitux> the fundamental issue lies into AVSubtitle actually requiring to know the stream timebase to rescale the timings
[18:03:14 CET] <ubitux> to AV_TIME_BASE_Q and ms
[18:03:21 CET] <Daemon404> this sounds pretty... derp
[18:03:30 CET] <ubitux> yes?
[18:03:42 CET] <ubitux> so what do we do? :)
[18:04:25 CET] <Daemon404> i dont get why ccaption ahs to do it in the decoder due to delay
[18:05:49 CET] <ubitux> it's not really important since every subtitles decoder also has that issue, but deported to lavc/utils
[18:06:04 CET] <ubitux> if lavc/utils can do it, ccaption dec could as well
[18:06:04 CET] <Daemon404> shouldnt it be easy to 'fix' right now then
[18:06:10 CET] <ubitux> how?
[18:06:17 CET] <Daemon404> unless you mean utils also has to be fixed
[18:06:19 CET] <ubitux> how do you fix that without changing the api?
[18:07:01 CET] <ubitux> should i quickly introduce a way to decode into AVFrames? :P
[18:11:53 CET] <Daemon404> ubitux, how did libav manage it?
[18:12:13 CET] <ubitux> do they have subtitles decoders? 
[18:12:18 CET] <Daemon404> i thought so, maybe not
[18:12:32 CET] <Daemon404> yes
[18:12:33 CET] <ubitux> they have a few where it doesn't really matter probably
[18:12:44 CET] <ubitux> does it still work for them?
[18:12:51 CET] <Daemon404> i assume so
[18:13:16 CET] <ubitux> they have fate tests?
[18:13:30 CET] <Daemon404> i'd need to check
[18:13:55 CET] <Daemon404> so if im understanding corectly, subtitles are using codec->time_base as a way to access the stream timebase?
[18:13:56 CET] <ubitux> if there is no rescaling in lavc/utils then i highly doubt it works
[18:14:03 CET] <ubitux> yes
[18:14:23 CET] <ubitux> because the timing into the decoded subtitles need to be rescaled
[18:14:38 CET] <Daemon404> right...
[18:14:39 CET] <ubitux> contrary to AVFrame.pts/duration
[18:14:47 CET] <Daemon404> this seems like it should not be lavc's job... but where we are
[18:14:49 CET] Action: Daemon404 thinks
[18:15:13 CET] <ubitux> i can start working on the new api to decode into AVFrame if you want
[18:15:19 CET] <ubitux> but i don't want this to block codecpar
[18:15:33 CET] <ubitux> so we can keep that time base copy temporarly
[18:15:43 CET] <ubitux> and we'll be able to drop it when the decoded subtitles holder is sane
[18:16:10 CET] <Daemon404> one option is to pass as packet side data
[18:16:13 CET] <Daemon404> but thats pretty derp too
[18:17:34 CET] <Daemon404> michaelni, ping, i need some help with a commit you made
[18:20:58 CET] <JEEB> michaelni: I think the language code thing might break FATE as well if it's hash-based, since it adds a value to the manifest XML
[18:21:43 CET] <JEEB> although I'm not sure if the ISMV test writes the XML manifest
[18:21:56 CET] <Daemon404> nevcairiel, you too ping.
[18:25:53 CET] Action: Daemon404 stabs confusing chnages made inside merge commits
[18:26:04 CET] <ubitux> Daemon404: so basically in libav, i'd say (by looking at the code) that AVSubtitle.pts is simply... not set.
[18:26:15 CET] <ubitux> except maybe sometimes copied from avpkt but not rescaled
[18:26:39 CET] <ubitux> and wrt to start/stop display time, the few decoders they have just hardcode the time bases
[18:27:18 CET] <Daemon404> i see
[18:30:34 CET] <ubitux> anyway, i'm starting to work on the new avsubtitles holder for now
[18:30:54 CET] <ubitux> if you want to fix the sub in codecpar, you will have to keep a codec timebase around
[18:31:03 CET] <ubitux> with deprecation flags around if you want but still..
[18:31:46 CET] <Daemon404> ill see what wm4 and nevcairiel say
[18:48:39 CET] <Daemon404> i see whats causing a bunch of these lavfi failures for audio
[18:49:02 CET] <nevcairiel> probably nut
[18:49:06 CET] <Daemon404> nope.
[18:49:10 CET] <Daemon404> has_codec_parameters
[18:49:17 CET] <Daemon404> it's checking a bunch of fields in internal->avctx
[18:49:45 CET] <nevcairiel> isnt that what it should check after decoding
[18:50:05 CET] <Daemon404> for adpcm_swf in flv, it's saying it has no sample_Rate
[18:50:50 CET] <Daemon404> [adpcm_swf @ 0x2bb9760] Invalid number of channels
[18:50:50 CET] <Daemon404> [flv @ 0x2bb8240] Could not find codec parameters for stream 0 (Audio: adpcm_swf, 0 channels): unspecified sample rate
[18:50:53 CET] <Daemon404> Consider increasing the value for the 'analyzeduration' and 'probesize' options
[18:51:02 CET] <Daemon404> not present pre-codecpar
[18:51:20 CET] <nevcairiel> swf demux may just be broken
[18:51:38 CET] <Daemon404> ah
[18:51:41 CET] <nevcairiel> or flv or whichever
[18:52:12 CET] <Daemon404> [voc @ 0x27c5620] Could not find codec parameters for stream 0 (Audio: pcm_u8, 0 channels): unspecified sample rate
[18:52:15 CET] <Daemon404> Consider increasing the value for the 'analyzeduration' and 'probesize' options
[18:52:18 CET] <Daemon404> same for voc
[18:52:26 CET] <nevcairiel> i think thats vocs fault
[18:52:38 CET] <nevcairiel> there was something libav changed in there
[18:52:42 CET] <nevcairiel> probably flv as well
[18:52:50 CET] <Daemon404> ?
[18:52:51 CET] <Daemon404> it's .voc
[18:53:10 CET] <nevcairiel> something like only creating streams when all info is known, instead of blindly creating them and filling in info later
[18:54:17 CET] <nevcairiel> the problem is that "filling in later" then fills that into codecpar, but find_stream_info checks internal avctx and doesnt sync changes from codecpar again (afaik)
[18:54:36 CET] <nevcairiel> at least thats what i remember
[18:54:41 CET] <nevcairiel> anyway bbl
[18:54:46 CET] <Daemon404> i cant wrap my head around how to fix it
[18:55:00 CET] <nevcairiel> <nevcairiel> something like only creating streams when all info is known, instead of blindly creating them and filling in info later
[18:55:01 CET] <nevcairiel> :)
[18:55:06 CET] <nevcairiel> delaying AVStream creation
[18:55:13 CET] <nevcairiel> and setting the noheader flag
[18:55:26 CET] Action: Daemon404 is not qualified to this probably
[18:56:17 CET] <nevcairiel> like I said yesterday, libav had various random patches for months that prepared for this api change by correcting demux behavior and whatnot
[18:56:41 CET] <nevcairiel> one shouldnt presume to get this done anytime soon
[18:56:47 CET] <Daemon404> heh
[18:57:21 CET] <Daemon404> well i'd rather make smll advances
[18:57:26 CET] <Daemon404> than let it sit untouched for a week
[18:57:28 CET] <Daemon404> like we just have
[18:57:39 CET] Action: Daemon404 doesnt want a huge merge backlog
[18:57:58 CET] <nevcairiel> considering incremental is not really possible, that cant be helped much
[18:58:57 CET] <Daemon404> heh
[18:59:20 CET] <Daemon404> what do you suggest then
[18:59:24 CET] <Daemon404> (also how long did tep1 take?)
[18:59:38 CET] <nevcairiel> honestly tep1 was simpler in comparison
[18:59:53 CET] <nevcairiel> much less random behavior changes
[19:01:08 CET] <Daemon404> sure...
[19:01:20 CET] <Daemon404> but it seems everyone kinda just... stopped
[19:02:07 CET] <ubitux> tep1 was done in a a week
[19:04:48 CET] <Daemon404> quite frankly im out of my depth here
[19:04:58 CET] <Daemon404> :/
[19:09:49 CET] <kurosu> what is the big benefit of this codecpar stuff ?
[19:10:31 CET] <Daemon404> kurosu, it's cleanup. everythign we have run into was never right to begin with.
[19:10:46 CET] <Daemon404> afaict
[19:11:12 CET] <Daemon404> ffmpeg just happens to have significantly more sketchy hacks.
[19:20:09 CET] <michaelni> Daemon404, pong, what commit of mine ? what question ?
[19:24:24 CET] <michaelni> JEEB, IIRC only 3/3 failed fate, also if theres something easy testable we dont test, more fate tests would be very welcome (by me at least)
[19:24:55 CET] <JEEB> ok, so the ISMV test doesn't write the XML manifest
[19:25:19 CET] <JEEB> -movflags isml enables that
[19:26:38 CET] <Daemon404> michaelni, why can we not use r_frame_rate in ff_compute_frame_duration if there is a parser context present
[19:26:46 CET] <Daemon404> i tried to git blame, but it dates back to some merge
[19:29:51 CET] <cone-095> ffmpeg 03Clément BSsch 07master:35ba5c424bbe: lavf/dv: do not check for c->sys
[19:29:52 CET] <cone-095> ffmpeg 03Clément BSsch 07master:6c0cf11f38f3: lavf/dv: reindent after previous commit
[19:29:53 CET] <cone-095> ffmpeg 03Clément BSsch 07master:8284a4ba11e2: lavf/dv: use c->sys->frame_size in dv_frame_offset()
[19:33:31 CET] <michaelni> r_frame_rate is a guess, based on timestamps at the file start or set by the demuxer if it has some definite knowledge. If a parser is available it can extract exact frame durations in for example the mpeg1/2 cases. with telecine stuff durations can change midstream, this would be reflected in the parser set repeat_pict but r_frame_rate would stay the same for the lifetime of the stream
[19:35:40 CET] <Daemon404> why is avg_frame_rate never attempted to be used?
[19:35:50 CET] <Daemon404> but stuff like time_base and codec->framerate is
[19:36:06 CET] <Daemon404> sometimes avg is set, but r_ is not and vice versa
[19:38:27 CET] <michaelni> iam not 100% sure but i think the problem with avg is that it can result in too large frame durations so that suddenly when a new timestamp comes in it could be in the past which can be problematic. so i _think_ underestimating duration is better. Btw when is r_frame_rate ot set but avg set ?
[19:39:07 CET] <Daemon404> michaelni, im working on the codecpar merge, and e.g. rawdec no longer can set the codec timebase
[19:39:18 CET] <Daemon404> so it can set r_frame_rate, which wont get used for h264 elementary streams
[19:39:23 CET] <Daemon404> because there is a parser open
[19:39:30 CET] <Daemon404> and avg_frame_rate will be ignore
[19:39:32 CET] <Daemon404> d
[19:39:55 CET] <Daemon404> the result of allowing people to set the framerate for "raw" elementary streams...
[19:41:32 CET] <JEEB> I don't even remember if that works correctly nowadays
[19:41:57 CET] <JEEB> I usually do an initial import into ISOBMFF by L-SMASH's muxer, and then remux with ffmpeg if required
[19:44:17 CET] <Daemon404> hmm
[19:45:22 CET] <Daemon404> nevcairiel, well i found out why movenc is derpy... oh lord.
[19:45:30 CET] <JEEB> > movenc
[19:45:41 CET] <nevcairiel> i think wm4 ported movenv, he already said its probably fubar
[19:45:46 CET] <nevcairiel> movenc*
[19:45:50 CET] <Daemon404> the problem is not in movenc
[19:45:59 CET] <Daemon404> it's in mux.c
[19:46:30 CET] <Daemon404> movenc calls mov hinting calls rtp_chain calls rtp's write_header which fails in init_pts, which doesnt exist in ffmpeg but we kept for ... reasons?
[19:46:40 CET] <Daemon404> which multiplies stream num by codec den
[19:46:56 CET] <Daemon404> and i tried fixing that, but now i get some differences on SOME muxes stts atoms.
[19:47:13 CET] <Daemon404> it's a lovecraftian horror show
[19:48:56 CET] <Daemon404> packet info all matches though
[19:50:06 CET] <Daemon404> aha... found it i think
[19:50:10 CET] <Daemon404> fiel atom is not being written.
[19:53:28 CET] <Daemon404> got it... mayeb mov is fixed now
[19:55:55 CET] <Daemon404> or not.
[19:59:13 CET] Action: Daemon404 stops for the dya
[20:25:42 CET] <Daemon404> nevcairiel, wm4, ubitux, etc - let me know if you have a plan on how to proceed.
[20:25:59 CET] <Daemon404> short of flailing randomly for weeks.
[20:26:22 CET] <nevcairiel> make fate pass, review all changes
[20:26:42 CET] <Daemon404> like 90% of fate failure is the same 2-3 problems
[20:26:50 CET] <Daemon404> one of which, at least, is way over my head
[20:26:56 CET] <Daemon404> i made some headway - not much.
[20:28:37 CET] <Daemon404> we could try to work on a few bits a day each, but that doesnt seem to be how it has gone
[20:29:14 CET] <nevcairiel> i got tired of talking to myself about the open questions of the issues, so i just did some more productive work =p
[20:30:11 CET] <Daemon404> well im around now that im no longer projectile vomiting.
[20:30:20 CET] <Daemon404> wm4 is omnipresent (except for today)
[20:32:22 CET] <Daemon404> do you want to start hackign at it again this week with me?
[20:32:36 CET] <nevcairiel> not really, pretty busy and going to my parents over easter
[20:33:09 CET] <Daemon404> eh ok
[20:33:20 CET] <Daemon404> (so am i, hence free time)
[20:33:52 CET] <Daemon404> when's a good time to pick it up again then
[20:33:56 CET] <Daemon404> and i will make myself available.
[20:34:23 CET] <cone-095> ffmpeg 03Marton Balint 07master:48a96383faa0: tests/gapless: add gapless aac tests
[20:34:24 CET] <cone-095> ffmpeg 03Marton Balint 07master:25f707694cd3: avformat/utils: increase detected start_time with skip_samples
[20:34:25 CET] <cone-095> ffmpeg 03Marton Balint 07master:65efcaeb8467: avformat/mov: read start_pad from edit list start time if codec is aac
[20:39:16 CET] <michaelni> ive posted a patch that adds a test for the -framerate option. if someone wants something to test changes to related code
[20:47:24 CET] <wm4> Daemon404: I'm trying to avoid doing stuff on weekends
[20:49:17 CET] <Daemon404> tahts fine
[20:49:30 CET] <Daemon404> poke me during the week then
[21:00:36 CET] <Daemon404> ohhhh make fate-lavf-mov passes
[21:00:38 CET] <Daemon404> \o/
[21:01:16 CET] <JEEB> 'grats
[21:06:17 CET] <nevcairiel> Daemon404: AVCodecContext *mux_enc = ost->st->codecpar;
[21:06:39 CET] <nevcairiel> also, dont change ffmpeg.c yet, it needs to work with the old api using new libavformat
[21:08:13 CET] <Daemon404> ill revert it
[21:08:23 CET] <Daemon404> almost all the mov failures now are missing fiel atom
[21:08:47 CET] <Daemon404> which is because field_order isnt being passed correctly
[21:08:49 CET] <Daemon404> afaict
[21:10:10 CET] <Daemon404> ive been updating the etherpad as i go.
[21:10:32 CET] <nevcairiel> field_order doesnt map to some avctx field?
[21:10:50 CET] <Daemon404> yes.... field_order
[21:11:04 CET] <Daemon404> maybe it's not being copied somewhere
[21:11:20 CET] <cone-095> ffmpeg 03Paul B Mahol 07master:8f66a2da3809: avfilter/vf_vectorscope: always flip output vertically
[21:11:50 CET] <Daemon404> 1/g 53
[21:31:25 CET] <J_Darnley> That's a little verbose
[22:06:46 CET] <yashpatel> michaelni: I'm working on the qualification task of  'FFv1 P frame support' which was to improve compression ration of existing algorithm. I've one problem in understanding the current thing. As we vary GOP from command line, why is it affecting the compression ration, isn't the current implementation is only for I-frames which make GOP=1 by default.
[22:07:27 CET] <yashpatel> michaelni: The results I'm getting in experiments by varying the GOP are very slightly different, there isn't much difference in the values
[22:21:46 CET] <Loriker> Has anyone attended the "Chemnitzer Linuxtage" in Germany?
[22:32:35 CET] <Daemon404> ohhh i think i fixed nut
[22:32:53 CET] <BBB_> and the whole world rejoiced
[22:34:44 CET] <Daemon404> things i hate: ff_put_v
[22:35:21 CET] <nevcairiel> vlc codes arent that special
[22:35:42 CET] <Daemon404> nevcairiel, it makes tracking what is written a pita
[22:35:51 CET] <Daemon404> i ended up having to use Beyond Compare to compare output files
[22:35:54 CET] <Daemon404> due to changed sizes
[22:37:12 CET] <Daemon404> daemon404 at bbvm:~/dev/f/codecpar$ make fate-lavf-nut
[22:37:12 CET] <Daemon404> TEST    lavf-nut
[22:37:12 CET] <Daemon404> daemon404 at bbvm:~/dev/f/codecpar$
[22:37:13 CET] <Daemon404> \o/
[22:37:25 CET] <nevcairiel> do all the lavfi things pass now?
[22:37:52 CET] <Daemon404> all the ones i tested just now do
[22:38:11 CET] <Daemon404> ffprone only has oen diff now
[22:38:12 CET] <Daemon404> -            "codec_time_base": "1/51200",
[22:38:12 CET] <Daemon404> +            "codec_time_base": "0/1",
[22:41:08 CET] <Daemon404> just some one with avdevice fails afaict
[22:50:31 CET] <Daemon404> yep they all pass now. pad updated.
[23:06:08 CET] <michaelni> yashpatel, non key I frames can reuse the range coder / vlc coder statistics so larger GOP compresses better
[00:00:00 CET] --- Mon Mar 21 2016