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

[burek]

[00:03:06 CEST] <Daemon404> stupid valgrind
[00:03:10 CEST] <Daemon404> telling me utils.c is not helpful
[00:03:13 CEST] <Daemon404> WHICH utils.c
[00:03:55 CEST] <Daemon404> not sure why it doesnt show full by default
[00:03:58 CEST] <Daemon404> or at least relative
[00:11:02 CEST] <Angus> Is there a header for this .c file? https://www.ffmpeg.org/doxygen/2.8/ffmpeg__vdpau_8c_source.html
[00:19:28 CEST] <Daemon404> its not part of the library
[00:19:34 CEST] <Daemon404> it us a utility
[00:19:35 CEST] <Daemon404> is*
[00:25:17 CEST] <Daemon404> fixed ffserver
[00:25:23 CEST] <Daemon404> well. "fixed" as it can be.
[01:11:28 CEST] <michaelni> Its getting hard to find issues in codecpar, i think its getting close to being ok once the ones reported are fixed or marked unimportant, i still might find one or another but dont expect alot more unless you want me to report every case where a output file changes by a byte somewhere
[01:12:14 CEST] <nevcairiel> only if you think the new output is "worse"
[01:19:04 CEST] <nevcairiel> but dont worry, we'll break more when we update ffmpeg.c to actually use the new api instead of the legacy code
[01:20:04 CEST] <Daemon404> yes but that will be separate
[01:27:20 CEST] <Daemon404> nevcairiel, "For autobsf to work this would need a check_bitstream function to actually insert a bsf when needed."
[01:27:23 CEST] <Daemon404> i do have one
[01:27:29 CEST] <nevcairiel> the patch didnt show anything
[01:27:38 CEST] <Daemon404> yeah i force pushed an update
[01:27:39 CEST] <Daemon404> sorry
[01:27:59 CEST] <Daemon404> ive also tested it and it owrks
[01:28:03 CEST] <Daemon404> works* 
[01:28:05 CEST] <Daemon404> and all of fate passes
[01:28:09 CEST] <nevcairiel> i looked at the latest branch, there is no such thing
[01:28:12 CEST] <nevcairiel> or where did you hide it in
[01:28:33 CEST] <Daemon404> ... well i DID have one
[01:28:39 CEST] <Daemon404> i must have reset --hard
[01:28:39 CEST] <Daemon404> shit
[01:28:44 CEST] <Daemon404> at least it was incredibly easy
[01:28:48 CEST] <Daemon404> ill re-push it
[01:28:51 CEST] <Daemon404> as a ne commit
[01:28:53 CEST] <Daemon404> new*
[01:28:53 CEST] <nevcairiel> yeah those functions are trivial
[01:28:59 CEST] <nevcairiel> for adts aac anyway
[01:29:43 CEST] <Daemon404> oh good a 2nd ffserver segfault
[01:29:48 CEST] <Daemon404> wanna bet its internal stuff nto allocated right?
[01:29:57 CEST] <nevcairiel> probably
[01:30:19 CEST] <Daemon404> i resent having to fix ffserver btw
[01:30:27 CEST] <Daemon404> i should have to fix users of internal shit
[01:31:10 CEST] <Daemon404> hmm
[01:31:15 CEST] <Daemon404> i figured out the acc bug kinda
[01:31:19 CEST] <Daemon404> ugh
[01:31:40 CEST] <Daemon404> av_get_audio_frame_duration2 is returning different results than av_get_audio_frame_duration for earlier frames
[01:31:46 CEST] <Daemon404> probably before codecpar is updated from decoding
[01:32:41 CEST] <nevcairiel> maybe parser needs to set one more property
[01:32:53 CEST] <Daemon404> its not the parser
[01:32:59 CEST] <Daemon404> aac parser doesnt set anything 
[01:33:06 CEST] <Daemon404> theres a big if != AAC in te parser
[01:33:07 CEST] <nevcairiel> doesnt?
[01:33:09 CEST] <nevcairiel> oh well
[01:33:18 CEST] <JEEB> lol
[01:33:44 CEST] <Daemon404> funily enough it says adts headers cant be trusted as teh reason for that
[01:33:51 CEST] <Daemon404> but theyre correct for this file and would have make it work
[01:34:19 CEST] <JEEB> the usual :P trusting file breaks broken stuff so let's not do that
[01:34:27 CEST] <nevcairiel> if you dont trust the adts headers, what other information do you use?
[01:34:29 CEST] <nevcairiel> there is none
[01:34:33 CEST] <nevcairiel> you need config data for aac
[01:34:37 CEST] <JEEB> and that
[01:34:46 CEST] <Daemon404> i dont know where it gets this info from
[01:35:11 CEST] <Daemon404> see: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/aac_ac3_parser.c#L82
[01:35:30 CEST] <Daemon404> but im thinking it might be stuff liek block_align
[01:35:38 CEST] <Daemon404> im slowly printf comparing all the attributes
[01:35:59 CEST] <nevcairiel> well ok, HE might overwrite the adts values when it applies  SBR
[01:36:05 CEST] <JEEB> oh, is this the HE-AAC thing where sample rate can be /2 etc
[01:36:14 CEST] <JEEB> and yeah, it updates it on the fly
[01:36:18 CEST] <JEEB> as it gets decoded
[01:40:17 CEST] <nevcairiel> similar to how i made the dca parser stop setting the sample rate, since it only knew about the core and none of the extensions
[01:41:54 CEST] <Shiz> Daemon404: remove all header parsing, replace it by heuristics
[01:41:56 CEST] <Shiz> even the resolution
[01:42:00 CEST] <Shiz> just heuristicize it all
[01:42:09 CEST] <Daemon404>      case AVMEDIA_TYPE_AUDIO:
[01:42:09 CEST] <Daemon404> +        avcodec_parameters_from_context(st->codecpar, st->internal->avctx);
[01:42:12 CEST] <Daemon404>          frame_size = av_get_audio_frame_duration2(st->codecpar, pkt->size);
[01:42:15 CEST] <Daemon404> this fixes it
[01:42:16 CEST] <Daemon404> nevcairiel will slap me
[01:42:19 CEST] <Daemon404> but lol
[01:42:22 CEST] <nevcairiel> where is this?
[01:42:30 CEST] <Daemon404> ff_compute_frame_duration
[01:43:16 CEST] <nevcairiel> doing it everytime seems evil t hough
[01:43:24 CEST] <Daemon404> i have no idea what to check for though
[01:43:28 CEST] <Daemon404> it's just stuff being updated
[01:43:34 CEST] <Daemon404> as frames decode
[01:44:02 CEST] <Daemon404> i could check for teh one specific thing that changes and updated... but eh...
[01:44:05 CEST] <Daemon404> seems just as bad
[01:44:13 CEST] <nevcairiel> we have a avctx version of that function, do we not? if (st->internal->avctx_inited
[01:44:16 CEST] <nevcairiel> argh
[01:44:33 CEST] <Daemon404> er
[01:44:36 CEST] <Daemon404> cannot parse
[01:44:41 CEST] <Daemon404> explain more
[01:44:44 CEST] <nevcairiel> nevermind everything after the ?
[01:45:05 CEST] <Daemon404> teh duration2 func you mean?
[01:45:14 CEST] <nevcairiel> yes
[01:45:25 CEST] <Daemon404> yes but i am pretty sure it is deprecated now
[01:45:30 CEST] <nevcairiel> doesnt seem to be
[01:45:45 CEST] <Daemon404> oh ho
[01:45:46 CEST] <Daemon404> no it isnt
[01:45:50 CEST] <Daemon404> and yeah i already tested it
[01:45:52 CEST] <Daemon404> it fixes it
[01:46:12 CEST] <nevcairiel> in that case, if (st->internal->avctx_inited) duration = av_get_audio_frame_duration(st->internal->avctx, ...); else ... = av_get_audio_frame_duration2(st->codecpar, pkt->size);
[01:46:19 CEST] <Daemon404> lets try.
[01:46:20 CEST] <nevcairiel> slightly ugly but not that bad
[01:46:49 CEST] <nevcairiel> while avctx_inited is set the decoder is running on it
[01:47:01 CEST] <nevcairiel> once its unset,  codecpar was sync'ed to the new info
[01:47:43 CEST] <Daemon404> ah
[01:48:01 CEST] <Daemon404> yes
[01:48:02 CEST] <Daemon404> that works
[01:48:13 CEST] <nevcairiel> still ugly, but what can you do
[01:48:19 CEST] <nevcairiel> the "active" context changes =p
[01:48:38 CEST] <Daemon404> yeah
[01:49:01 CEST] <Daemon404> running fate and ill push
[01:49:02 CEST] <nevcairiel> ideally it should probably fill this info when it actually reads these packets for delivery to the user
[01:49:11 CEST] <nevcairiel> ie. after find_stream_info finished
[01:49:17 CEST] <nevcairiel> but the dataflow here is a bit wonky
[01:49:35 CEST] <Daemon404> dwbuiten/FFmpeg] Starship_Troopers.vob doesnt show subtitles anymore (#28)
[01:49:36 CEST] <Daemon404> igh
[01:49:44 CEST] <Daemon404> this file again
[01:49:57 CEST] <nevcairiel> i dont think that file had a subtitle track?
[01:50:06 CEST] <Daemon404> it does
[01:50:31 CEST] <nevcairiel> let me guess, ffplay/ffmpeg is dumb and uses the CC properties flag to setup closed caption decoding, which is now unavailable?
[01:50:42 CEST] <Daemon404> thats the file where dump.c stopped printing Closed Captions
[01:50:50 CEST] <Daemon404> dunno
[01:50:51 CEST] <nevcairiel> thats not a subtitle track though =p
[01:52:09 CEST] <Daemon404>     Stream #0:5[0x20]: Subtitle: dvd_subtitle
[01:52:09 CEST] <Daemon404>     Stream #0:6[0x22]: Subtitle: dvd_subtitle
[01:52:13 CEST] <Daemon404> i see these in git master
[01:52:19 CEST] <nevcairiel> it changed?
[01:52:34 CEST] <Daemon404> nope
[01:52:39 CEST] <Daemon404> theyre there in codecpar too
[01:52:55 CEST] <nevcairiel> but no worky, i assume
[01:52:55 CEST] <Daemon404> [mpeg @ 0x21a0240] Could not find codec parameters for stream 5 (Audio: ac3, 48000 Hz, 5.1(side), fltp, 384 kb/s): unknown codec
[01:52:59 CEST] <Daemon404> Consider increasing the value for the 'analyzeduration' and 'probesize' options
[01:53:02 CEST] <Daemon404> [mpeg @ 0x21a0240] Could not find codec parameters for stream 6 (Audio: ac3, 48000 Hz, 5.1(side), fltp, 384 kb/s): unknown codec
[01:53:05 CEST] <Daemon404> Consider increasing the value for the 'analyzeduration' and 'probesize' options
[01:53:08 CEST] <Daemon404> these are there though
[01:53:08 CEST] <nevcairiel> it thinks they are ac3 now?
[01:53:10 CEST] <Daemon404> not in master
[01:53:12 CEST] <Daemon404> i have NFC
[01:53:36 CEST] <Daemon404> oh shit
[01:53:45 CEST] <Daemon404> that audio duration change make pmp-demux match the old ref
[01:53:48 CEST] <Daemon404> go figure.
[01:53:50 CEST] <nevcairiel> lol
[01:53:55 CEST] <nevcairiel> yay for that
[01:54:56 CEST] <nevcairiel> these messages are definitely odd, it thinks they are ac3 first but then goes ahead to show them as dvd subs
[01:55:05 CEST] <nevcairiel> i wonder if there isnt something that needs the update context flag
[01:55:36 CEST] <Daemon404> yeah not sure
[01:56:14 CEST] <Daemon404>     st->request_probe     = request_probe;
[01:56:22 CEST] <Daemon404> this is the api for probing via packets right?
[01:56:26 CEST] <nevcairiel> yes
[01:56:36 CEST] <nevcairiel> i made that set the flag though when it probes
[01:56:44 CEST] <Daemon404> i see
[02:00:46 CEST] <Daemon404> im not gonna dig into that tonight
[02:00:54 CEST] <nevcairiel> its probably related to that ac3 error messages somehow
[02:00:58 CEST] <Daemon404> yeah i know
[02:01:19 CEST] <Daemon404> fixing the 2nd ffserver BS bug
[02:01:23 CEST] <Daemon404> then thats itfor me tonight
[02:01:33 CEST] <Daemon404> do you have time to poke a few things tomorrow before i wake up?
[02:02:00 CEST] <nevcairiel> that depends how my work inbox looks when i wake up
[02:02:17 CEST] <Daemon404> lol k
[02:03:31 CEST] <nevcairiel> i will look at the vob ac3 thing, will see what else i can dig into
[02:04:11 CEST] <nevcairiel> it sounds like some stupid mistake somewhere since it shows the info of a previous track
[02:04:13 CEST] <nevcairiel> but who knows
[02:05:15 CEST] <nevcairiel> well ok the error was a stupid mistake
[02:05:26 CEST] <nevcairiel> but now it shows the actual error =p
[02:05:41 CEST] <Daemon404> ;p
[02:05:47 CEST] <Daemon404> ok
[02:05:55 CEST] <nevcairiel> [mpeg @ 02640ec0] Could not find codec parameters for stream 5 (Unknown: none): unknown codec
[02:05:57 CEST] <nevcairiel> yay?
[02:06:33 CEST] <Daemon404> wut?
[02:06:36 CEST] <Daemon404> context?
[02:06:54 CEST] <nevcairiel> thats what happens if i fix the logging of the error
[02:07:00 CEST] <Daemon404> o
[02:07:15 CEST] <Daemon404> anyway... i gotta run off
[02:07:19 CEST] <Daemon404> ttyl
[02:07:24 CEST] <Daemon404> (and go to bed)
[02:09:58 CEST] <rcombs> incomplete codecpar probably shouldn't cause outright failures in ffmpeg.c
[02:15:30 CEST] <nevcairiel> i fixed the errors, but i dont have ffplay setup to test if i get subs
[02:15:31 CEST] <nevcairiel> oh well
[02:15:48 CEST] <nevcairiel> actually i lied the errors came back
[02:15:51 CEST] <nevcairiel> what did i break now
[02:20:46 CEST] <nevcairiel> now i made it go away
[02:29:48 CEST] <nevcairiel> Daemon404: fate-movenc seems broken, that one is your speciality =p
[02:30:43 CEST] <nevcairiel> (probably from init/write_header)
[02:32:40 CEST] <nevcairiel> also can someone upload the new sample for vp6a already? that fate failure is annoying :)
[05:29:33 CEST] <Daemon404> oh good
[07:22:24 CEST] <Timothy_Gu> Hmm http://fatebeta.ffmpeg.org/report/x86_32-linux-gnu-gcc-4.8-tg/20160404024105#failed_tests
[09:00:42 CEST] <durandal_170> I gonna push musx/dat4
[09:03:50 CEST] <cone-268> ffmpeg 03Claudio Freire 07master:7d49abdf4750: AAC encoder: fix filling of wi.clipping array
[09:31:14 CEST] <j-b> 'morning
[11:02:48 CEST] <nevcairiel> github is no fun when its half broken
[11:05:11 CEST] <JEEB> nevcairiel: yeqah
[11:05:18 CEST] <JEEB> at least the git part in general seems to be more stable
[11:05:24 CEST] <thardin> what did they do now?
[11:05:32 CEST] <JEEB> their web side is pretty bad right now
[11:05:33 CEST] <nevcairiel> its just being slow as fuck because down
[11:05:44 CEST] <thardin> good thing git is this decentralized thing then
[11:05:54 CEST] <nevcairiel> i'm trying to use the issue tracker though
[11:06:21 CEST] <JEEB> yeah, that gets really aggravating. esp. with the new "loading bar"
[11:06:33 CEST] <thardin> just gitlab
[11:11:55 CEST] <nevcairiel> interesting though, I did push to github but the UI doesnt show those commits :D
[11:13:16 CEST] <nevcairiel> ah they showed up
[11:19:53 CEST] <fritsch> github currently has a minor outtage
[11:20:07 CEST] <nevcairiel> i got a unicorn error page earlier, thats not minor to me
[11:20:20 CEST] <wm4> for github it is lol
[11:20:59 CEST] <nevcairiel> actually github it self calls it a major outtage
[11:21:07 CEST] <nevcairiel> https://status.github.com/messages
[11:21:11 CEST] <nevcairiel> although seems to be coming back now
[11:29:36 CEST] <cone-268> ffmpeg 03Paul B Mahol 07master:8a4c3f525831: avcodec: add adpcm dat4 decoder
[11:29:37 CEST] <cone-268> ffmpeg 03Paul B Mahol 07master:56a3a3f01ca5: avformat: add musx demuxer
[12:30:23 CEST] <cone-268> ffmpeg 03Clément BSsch 07master:040598218f48: sws/aarch64: restore ff_hscale_8_to_15_neon()
[13:33:11 CEST] <wm4> hm, current codecpar_rebase doesn't pass fate?
[13:36:28 CEST] <nevcairiel> lowres of course
[13:36:35 CEST] <nevcairiel> also the vp6a sample still isnt uploaded anywhere
[13:36:36 CEST] <wm4> fate-movenc
[13:44:29 CEST] <nevcairiel> oh yeah that got broken last night
[13:47:32 CEST] <ubitux> the guy forked openjpeg without changing the library name?
[13:47:37 CEST] <ubitux> reminds me of a story
[13:48:04 CEST] <ubitux> nasty to also change the license at the same time
[13:48:06 CEST] <ubitux> iiuc
[13:53:02 CEST] <nevcairiel> well he changed the project name, but changing the library name itself would of course require getting people to support his shit instead of being a drop-in replacement =p
[13:59:17 CEST] <ubitux> i suggest to refuse that patch then
[14:03:10 CEST] <JEEB> not sure if my opinion is worth anything, but just by the fact that we don't generally allow new licenses (knowingly) and due to what a clusterfuck the guy's license is I'm also against merging support for his fork
[14:14:27 CEST] <durandal_170> guy is buzzinesman obviously
[14:39:39 CEST] <wm4> what the heck faa2930f191099621e03c55cca32662467d3cc15
[14:39:56 CEST] <wm4> ever since that AV_PKT_DATA_NEW_EXTRADATA is ignored
[14:40:00 CEST] <wm4> in the aac decoder
[15:25:21 CEST] <wm4> how hard would it be to make ffmpeg.c act on the decoder output (first AVFrame), instead of the demuxer info? the codecpar API change even mandates this to a degree
[15:37:38 CEST] <wm4> wow
[15:37:50 CEST] <wm4> lowres is not only failing because the codec parameters are messed up
[15:38:01 CEST] <wm4> it's also failing because lowres is not set on the decoder context?
[15:38:33 CEST] <wm4> or maybe I'm just dumb
[15:39:22 CEST] <wm4> yeah, the latter
[15:51:17 CEST] <av500> what is lowres?
[15:51:31 CEST] <wm4> an extremely shitty feature that only 1 dev cares about
[15:51:32 CEST] <av500> I'm only with the project since 2003, so I might not remember...
[15:51:43 CEST] <wm4> decoding video at half res
[15:51:59 CEST] <av500> for interlaced?
[15:52:03 CEST] <wm4> no
[15:52:16 CEST] <nevcairiel> typically formats which somehow tend to support that, like jpeg
[15:54:07 CEST] <wm4> the feature alone is pretty harmless (probably), but the influence it has on other code sucks
[15:55:05 CEST] <durandal_170> and exr and j2k
[15:55:50 CEST] <durandal_170> it should be moved to private option
[16:00:11 CEST] <wm4> nevcairiel: acceptable? http://sprunge.us/JhAh
[16:00:15 CEST] <wm4> it's a bit fragile
[16:01:24 CEST] <nevcairiel> if the container w/h are not set, or invalid, codecpar will end up wrong
[16:02:01 CEST] <wm4> I don't see how lowres could work if they're not set
[16:02:19 CEST] <nevcairiel> the codec might produce them?
[16:03:01 CEST] <kierank> av500: using dc coefficients to produce a lowres version
[16:03:15 CEST] <kierank> kinda like progressive jpeg
[16:03:30 CEST] <wm4> nevcairiel: it's at the end of avformat_find_stream_info(), so if it doesn't produce them, when will it ever
[16:04:08 CEST] <nevcairiel> you are telling it not to update codecpar w/h from the avctx
[16:04:15 CEST] <nevcairiel> so if the container didnt set any, then codecpar will be empty
[16:04:47 CEST] <nevcairiel> or if the container set wrong dimensions, they will remain wrong
[16:04:47 CEST] <wm4> so should I check for st->internal->avctx_inited?
[16:05:47 CEST] <nevcairiel> your entire approach still has the potential to change codecpar when lowres is set, which is what we're trying to avoid
[16:06:39 CEST] <wm4> when? if the parser does?
[16:07:02 CEST] <nevcairiel> [16:04:08] <nevcairiel> you are telling it not to update codecpar w/h from the avctx
[16:07:02 CEST] <nevcairiel> [16:04:15] <nevcairiel> so if the container didnt set any, then codecpar will be empty
[16:07:02 CEST] <nevcairiel> [16:04:47] <nevcairiel> or if the container set wrong dimensions, they will remain wrong
[16:14:04 CEST] <nevcairiel> doesnt mpeg2 support lowres? if you use that from mpegts with lowres decoding, codecpar probably ends up without w/h
[16:16:14 CEST] <wm4> works with ffplay and from mpeg-ps
[16:17:31 CEST] <nevcairiel> that doesnt use codecpar tho
[16:21:20 CEST] <wm4> oh, right, lowres must also be passed to find_stream_info
[16:21:51 CEST] <wm4> michaelni: what other programs use this lowres API?
[16:22:33 CEST] <ubitux> api user that need a fast first pass analysis i guess
[16:23:01 CEST] <ubitux> actually not even api
[16:23:08 CEST] <ubitux> (if supported)
[16:39:40 CEST] <Daemon404> nevcairiel, im just going to move the autobsf mov stuff to a diff branch
[16:39:49 CEST] <Daemon404> its not needed for codecpar, but id still like to submit it after
[16:40:03 CEST] <nevcairiel> i guess
[16:40:14 CEST] <Daemon404> im pretty sure i know the issue
[16:40:17 CEST] <nevcairiel> take both commits then for simplicity
[16:40:20 CEST] <Daemon404> yes
[16:40:30 CEST] <Daemon404> both = both to movenc, i assume
[16:40:41 CEST] <nevcairiel> yes the init split and the check_bitstream
[16:40:50 CEST] <Daemon404> they should be one commit anyway
[16:41:26 CEST] <Daemon404> how's lowres going (i havent read backlog0
[16:49:15 CEST] <wm4> Daemon404: I tried a hack, nevcairiel said it's too fragile
[16:49:21 CEST] <wm4> patch http://sprunge.us/JhAh
[16:49:40 CEST] <wm4> the problem is that these can be overwritten later anyway in whatever situations
[16:50:05 CEST] <darkapex> Is it fine if two people work on the same qualification task for different programs (gsoc and outreachy)?
[16:50:29 CEST] <Daemon404> wm4, right
[16:50:37 CEST] <Daemon404> also i love that a different ugly hack i aded is the ine patch context
[16:50:41 CEST] <Daemon404> makes me all warm and fuzzy inside
[16:53:12 CEST] <wm4> the thing I regret is that we have to live with those for 2 years
[16:53:23 CEST] <wm4> (apparently)
[16:53:27 CEST] <kierank> darkapex: yes
[16:53:55 CEST] <Daemon404> wm4, we've lived with worse, for longer
[16:54:01 CEST] <Daemon404> it starst with ff and ends with server
[16:54:27 CEST] <ubitux> michaelni: i'm doing `ffmpeg -f lavfi -i testsrc2=s=5472x3648 -frames:v 1 -y /tmp/test.jpg` then `./ffmpeg -i /tmp/test.jpg -vf scale=512x512 -y /tmp/out.jpg`; in the second command both yuv2yuvX_sse3 AND yuv2planeX_8_c are called
[16:54:28 CEST] <nevcairiel> everything around here starts with ff
[16:54:33 CEST] <ubitux> any idea why?
[16:55:01 CEST] <Daemon404> nevcairiel, except swscale
[16:55:04 CEST] <Daemon404> and swr
[16:55:13 CEST] <Daemon404> wait av != ff
[16:55:14 CEST] <Daemon404> brb coffee
[16:55:18 CEST] <ubitux> michaelni: the "timeline" looks something like http://sprunge.us/URVg
[16:55:21 CEST] <ubitux> i'm a bit lost
[17:00:35 CEST] <durandal_170> when meeting?
[17:00:52 CEST] <durandal_170> I want to vote?
[17:16:32 CEST] <ubitux> michaelni: basically, it appears to call ff_sws_init_output_funcs() without calling ff_sws_init_swscale_x86() afterwards like the first time
[17:16:59 CEST] <cone-268> ffmpeg 03Derek Buitenhuis 07master:fdd7a594c3e9: libxvid: Create extradata in init using a dummy frame
[17:17:47 CEST] <ubitux>             /* hmm looks like we can't use MMX here without overwriting
[17:17:49 CEST] <ubitux>              * this array's tail */
[17:17:54 CEST] <ubitux> i guess it comes from this, meh.
[17:21:50 CEST] <Daemon404> wm4, i dont have any better ideas for lowres
[17:26:39 CEST] <ubitux> michaelni: ah, my bad, apparently it's just for a small part of the image
[17:40:01 CEST] <Daemon404> michaelni, can you upload the new vp6a test to the fate rsync servers
[17:52:47 CEST] <Daemon404> time to look at ogm... lol
[17:53:03 CEST] <Daemon404> without even looking at the file, i know it is anime.
[17:55:13 CEST] <Plorkyeran_> is there any non-anime ogm?
[17:55:25 CEST] <Daemon404> good point
[17:56:34 CEST] <gnafu> I think I tried to rip a non-anime DVD to OGM once a very long time ago.
[17:56:49 CEST] <gnafu> In my younger, more impressionable days.
[17:56:51 CEST] <Daemon404> oh
[17:57:01 CEST] <Daemon404> i have some futurama OGMs somewhere
[17:57:05 CEST] <Daemon404> ... from an anime release group.
[17:57:17 CEST] <gnafu> And there it is.
[17:58:47 CEST] <Daemon404> the borken file in question was indeed anime
[17:58:49 CEST] <Daemon404> tenchi muyo.
[18:00:40 CEST] <Daemon404>     Stream #0:1(English): Audio: vorbis, 48000 Hz, stereo, fltp, 4294967 kb/s
[18:00:43 CEST] <Daemon404>     Stream #0:2(Japanese): Audio: vorbis, 48000 Hz, stereo, fltp, 4294967 kb/s
[18:00:46 CEST] <Daemon404> somehow i dont think this bitarte is correct
[18:00:51 CEST] <Daemon404> this is with git master too
[18:19:37 CEST] <Shiz> Daemon404: lies and slader
[18:19:41 CEST] <Shiz> there's VN OGMs too
[18:28:48 CEST] <kierank> LAVFI TROLL UPCOMING
[18:29:00 CEST] <kierank> so vf_blackdetect? how does one use it?
[18:29:05 CEST] <kierank> it just prints to the cli
[18:29:07 CEST] <kierank> totally useless
[18:29:15 CEST] <nevcairiel> most of those detect filters just do that
[18:29:21 CEST] <nevcairiel> with any luck it may set metadata
[18:29:34 CEST] <wm4> the "proper" way to do that is to set AVFrame.metadata or something
[18:29:48 CEST] <kierank> well I want to write a stuck frame filter
[18:33:20 CEST] <nevcairiel> Daemon404: technically the seek-test tool tests both seek modes, backwards and forwards, only one of those is supposed to end up before the seek point
[18:33:40 CEST] <Daemon404> i see
[18:33:57 CEST] <nevcairiel> not that it matters much
[18:34:07 CEST] <Daemon404> if i print the info, before that one seek, info is garbage
[18:34:10 CEST] <Daemon404> since the file is broken
[18:34:45 CEST] <Daemon404> i.e. it may rely on a *different* stream getting updated to seek based on that stream
[18:34:52 CEST] <Daemon404> (i could be reading it wrong)
[18:35:04 CEST] <Daemon404> im still inclined to say "i dont care about changes on this kind of broken file"
[18:38:12 CEST] <Daemon404> who else besides michaelni has access to upload fate files/
[18:38:41 CEST] <nevcairiel> i do
[18:38:53 CEST] <Daemon404> o 
[18:39:02 CEST] <Daemon404> i have a copy of the new ref if you wanna upload it
[18:39:21 CEST] <nevcairiel> link me the file and where to, and i will
[18:41:47 CEST] <Daemon404> http://chromashift.org/300x180-Scr-f8-056alpha.mov
[18:41:57 CEST] <Daemon404> goes in the flash-vp6 dir
[18:44:59 CEST] <nevcairiel> shiuld be there
[18:45:02 CEST] <nevcairiel> should*
[18:45:07 CEST] <Daemon404> yep
[18:45:09 CEST] <Daemon404> sync'd it
[18:45:18 CEST] <Daemon404> so did we give up on lowres toay?
[18:45:19 CEST] <Daemon404> today*
[18:47:14 CEST] <wm4> my patch could probably be extended so that it works, in whatever situation it'd break now
[18:47:42 CEST] <Daemon404> i see
[18:49:20 CEST] <wm4> my patch is pretty fragile, but I haven't seen any api usage/sample to break it yet
[18:49:54 CEST] <nevcairiel> because we dont have anything that uses codecpar
[18:50:20 CEST] <wm4> I tried with my own code
[18:50:31 CEST] <wm4> but it doesn't pass parameters to av_find_stream_info
[18:50:38 CEST] <wm4> so, probably pointless
[18:57:44 CEST] <wm4> [ac3 @ 0x7b9a40] The maximum value for lowres supported by the decoder is 0
[18:58:09 CEST] <nevcairiel> use -vlowres =p
[19:21:10 CEST] <wm4> hm even if I pass lowres to av_find_stream_info I can't break it
[19:21:19 CEST] <wm4> of course that means nothing in general
[19:22:07 CEST] <nevcairiel> just try with ffplay and print codecpar at the end to verify its actually filled properly, on a container which doesnt provide container level infos and needs the decoder to fill some in
[19:22:31 CEST] <nevcairiel> or even worse, a container that provides the wrong container level info =p
[19:22:45 CEST] <nevcairiel> it sounds to me like it would end up with empty w/h
[19:22:51 CEST] <nevcairiel> (or retain the wrong one)
[19:24:38 CEST] <wm4> ok, breaks with mpeg2, so I'll try to fix this case
[19:24:59 CEST] <wm4> it retains the original res, but unfortunately also on the avstream.codec
[19:27:55 CEST] <nevcairiel> does a lowres decoder export the lowres factor so we could un-lowres?
[19:28:41 CEST] <wm4> we can't un-lowres because of rounding
[19:28:45 CEST] <wm4> but yes it does
[19:37:03 CEST] <wm4> lol
[19:37:10 CEST] <wm4> the mpg2 case is broken in git master?
[19:37:16 CEST] <Daemon404> it is?
[19:37:19 CEST] <Daemon404> lol
[19:37:23 CEST] <wm4> let me double-check
[19:37:33 CEST] <wm4> err, ffmpeg 2.8
[19:37:37 CEST] <wm4> but shouldn't matter much
[19:37:57 CEST] <wm4> Input stream #0:0 frame changed from size:720x576 fmt:yuv420p to size:180x144 fmt:yuv420p
[19:38:00 CEST] <wm4> with ffmpeg 2.8
[19:38:01 CEST] <wm4> lol
[19:38:13 CEST] <wm4> michaelni: can you confirm this?
[20:16:06 CEST] <Daemon404> is that agpl thign STILL going?
[20:16:28 CEST] <RiCON> the guy is still going*
[20:16:34 CEST] <Daemon404> hah
[20:16:36 CEST] <michaelni> wm4, it seems you are correct, mpeg2 lowres doesnt fully work
[20:17:58 CEST] <wm4> k
[20:19:11 CEST] <michaelni> it works with ffplay it doesnt work with ffmpeg
[20:20:56 CEST] <wm4> because ffmpeg.c is stupid
[20:21:15 CEST] <wm4> but according to you that's the API anyway, and it's broken in gi master
[20:21:17 CEST] <wm4> *git
[20:36:56 CEST] <michaelni> the API is sadly defined by how its used and ffmpeg.c uses it that way
[20:43:48 CEST] <wm4> nevcairiel: so should I push my current patch?
[23:06:44 CEST] <sb_> Is there a way to configure the build so that all headers are included?
[23:19:08 CEST] <michaelni> about the "hardware assist H264 video encoding for the Raspberry Pi" patch, i intend to apply this in a few days if theres no clear objection. I will of course not apply if someone clearly states that he is against
[23:19:30 CEST] <michaelni> just saying here too so its not missed in the thread
[23:23:58 CEST] <wm4> miI'm still against it
[23:24:19 CEST] <wm4> s/mi/michaelni:/
[23:24:32 CEST] <JEEB> I guess MMAL is better than OMX?
[23:27:20 CEST] <michaelni> wm4, you spoke of a lowres patch above, where can i find that? (for testing & review)
[23:35:22 CEST] <wm4> michaelni: http://sprunge.us/JhAh
[00:00:00 CEST] --- Wed Apr  6 2016