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

[burek]

[00:41:43 CEST] <rcombs> nevcairiel: so, my current route is:
[00:42:09 CEST] <rcombs> - make ASC the canonical bitstream format for AAC, and have the parser convert to it
[00:42:47 CEST] <rcombs> - make the AAC decoder handle the case where the extradata isn't available on codec init, but is available when the first packet is sent (the parser runs on the first packet between these two)
[00:43:21 CEST] <rcombs> - deprecated the aac_adtstoasc BSF and make it print a warning telling the user it's no longer necessary
[00:48:28 CEST] <rcombs> passes FATE
[00:54:23 CEST] <rcombs> https://gist.github.com/310646411402baa7e068 <-- RFC, to be split into a number of commits
[02:45:46 CEST] <cone-978> ffmpeg 03Ronald S. Bultje 07master:350e9c6765f0: vp9: fix loopfilter test code to address Hendrik's comments.
[02:45:47 CEST] <cone-978> ffmpeg 03Ronald S. Bultje 07master:74e4948235bc: hevc: fix wpp threading deadlock.
[03:51:12 CEST] <rcombs> there, have a patch series
[03:51:18 CEST] <rcombs> I'm out of control
[03:53:28 CEST] <jamrial> will you do the same for latm? :p
[03:53:52 CEST] <jamrial> also, you could add the usual deprecation removal schedule to the bsf
[03:55:57 CEST] <rcombs> jamrial: sounds sensible, I should figure out how all that's supposed to work
[03:56:19 CEST] <rcombs> where's latm seen in practice?
[03:57:02 CEST] <jamrial> i've seen it used in mpeg-ts
[03:57:55 CEST] <rcombs> chuck me a sample and maybe I'll do it
[03:59:18 CEST] <jamrial> ok, i'll see if i can find one
[04:10:25 CEST] <jamrial> rcombs: seems you can create .latm files with ffmpeg. either pass asc aac and let our muxer do the encapsulation, or use libfdk-aac with -latm 1
[04:11:01 CEST] <rcombs> yeah, aware; was hoping to see a real-world sample though
[04:15:21 CEST] <jamrial> rcombs: https://trac.ffmpeg.org/ticket/4576#comment:5
[04:15:49 CEST] <rcombs> ahh, perfect
[04:16:36 CEST] <rcombs> wow, stupidly big files
[04:16:53 CEST] <jamrial> no idea if the globo one is sane
[04:18:12 CEST] <jamrial> or at least some of the aac tracks seem to not play nice with ffmpeg
[04:25:58 CEST] <rcombs> yuck, it really dislikes those
[04:49:24 CEST] <philipl> fritsch: I have a patch to compile xbmc against ffmpeg master. I should send a pull request?
[05:55:07 CEST] <zylthinking> Hi, I met a crash in h264 decode
[05:56:34 CEST] <zylthinking> It truns out in decode_postinit, where at the line h->cur_pic_ptr->f.pict_type = h->pict_type;  h->cur_pic_ptr seems to be NULL
[05:57:06 CEST] <zylthinking> http://sprunge.us/DSWd
[06:01:23 CEST] <jamrial> zylthinking: could you open a ticket about this in https://trac.ffmpeg.org/?
[06:01:34 CEST] <zylthinking> OK
[07:56:14 CEST] <fritsch> philipl: in fact we patched that out a long time ago
[07:57:00 CEST] <fritsch> philipl: cause of gentoo and arch packages thought it was a good idea to compile against whatever libav version they just liked to have ... after compilation they made no tests at all and users came and complained
[08:04:48 CEST] <nevcairiel> rcombs: ADTS has a bunch of advantages, converting to ASC at all times is not good
[08:04:58 CEST] <nevcairiel> ie for example changing stream properties on the fly
[08:12:33 CEST] <fritsch> philipl: or did you have a patch to fix kodi vs ffmpeg master without breaking backwards compatibility? If that would be the case - we were very thankful having it
[11:07:46 CEST] <cone-052> ffmpeg 03Jean Delvare 07master:d9c72e0d24d3: Update my email address
[13:00:27 CEST] <saste> durandal_1707, do you read ffmpeg-mentors? can I have a short description of your gsoc task results?
[13:00:46 CEST] <saste> philipl, same with you
[13:57:49 CEST] <rcombs> nevcairiel: re: ADTS, what advantages does it have as an internal bitstream format, other than the ability to change stream properties on the fly (which I could probably handle using AV_PKT_DATA_NEW_EXTRADATA or similar)
[13:58:16 CEST] <nevcairiel> I oppose breaking a perfectly fine bitstream format by introducing a new mechanism every player has to handle in the future then
[14:02:00 CEST] <rcombs> OK, so then we need to figure out how to solve the matroska issue, and preferably stop making the user manually add a bsf
[14:02:22 CEST] <rcombs> (and preferably without it being another ffmpeg.c hack)
[14:03:08 CEST] <nevcairiel> I would actually just fix it in ffmpeg.c, and not as a hack, but as a generic thing, somehow allow the bsf to generate extradata before the actual muxing process starts
[14:03:59 CEST] <nevcairiel> the problem is a ffmpeg.c limitation, not a API limitation
[14:10:35 CEST] <rcombs> there's an API limitation in that muxers have no way of communicating which bitstream filters are required, nor a (non-hacky) way to get a packet to generate extradata from before writing their header (if they want to do the transformation internally)
[14:26:21 CEST] <rcombs> maybe add a function to the AVOutputFormat struct, to which the application should pass packets until it stops returning EAGAIN, for each stream, before calling write_header?
[14:27:00 CEST] <rcombs> (to let the muxer generate any necessary extradata)
[14:27:19 CEST] <nevcairiel> why cant you let the BSF do that
[14:27:26 CEST] <nevcairiel> thats its job
[14:27:35 CEST] <rcombs> still needs a way to signal that the BSF is even necessary
[14:27:51 CEST] <nevcairiel> fix one thing at a time
[14:27:53 CEST] <nevcairiel> makes for easier lives
[14:27:54 CEST] <rcombs> (other than stderr)
[14:29:30 CEST] <nevcairiel> Thats something you could put on the output format, a map of codec id -> bsf that may be needed
[14:29:36 CEST] <nevcairiel> or maybe a fucntion to ask it
[14:30:01 CEST] <rcombs> that's another thing I was considering
[14:30:19 CEST] <rcombs> but I still don't see why that should be the calling application's job to handle
[14:30:33 CEST] <nevcairiel> because we say so
[14:30:36 CEST] <rcombs> just more required boilerplate
[14:31:15 CEST] <rcombs> along with all the other stuff that makes me say the vast majority of ffmpeg.c should be moved into a library
[14:31:35 CEST] <wm4> like what?
[14:32:06 CEST] <nevcairiel> your approach would duplicate codec specific handling in every muxer that needs it
[14:32:13 CEST] <nevcairiel> mine would have it one central place
[14:32:20 CEST] <nevcairiel> +in
[14:32:48 CEST] <rcombs> could that place be in lavf/utils?
[14:33:56 CEST] <rcombs> erm, libavformat/mux.c
[14:36:58 CEST] <nevcairiel> if its decently reusable sure why not
[14:39:51 CEST] <rcombs> so, AVOutputFormat exposes a function or other map from codec id -> bsf
[14:40:07 CEST] <rcombs> mux.c executes said bsf on each packet
[14:41:04 CEST] <wm4> so like the parser when demuxing
[14:41:14 CEST] <rcombs> and, lavf gets a new function the application passes packets to until it doesn't return EAGAIN before write_header to generate needed extradata
[14:41:30 CEST] <rcombs> sound good?
[14:41:50 CEST] <nevcairiel> that still leaves the question of buffering these packets
[14:42:02 CEST] <nevcairiel> ideally inside that API somewhere
[14:43:37 CEST] <nevcairiel> so two APIs might be nice, ie av_foo_write_preroll for the initial, and something that wraps the muxing function after, i guess
[14:43:56 CEST] <nevcairiel> and first call to the muxing function writes all the buffered packets into the container
[14:43:58 CEST] <nevcairiel> or something
[14:44:14 CEST] <rcombs> hmmmm
[14:44:49 CEST] <rcombs> that works assuming the bsfs don't need more than 1 frame worth of data to generate the extradata, which I think is a valid assumption for all the real cases
[14:45:01 CEST] <nevcairiel> you could buffer more
[14:45:04 CEST] <rcombs> &and assuming the streams all start at the same time
[14:45:06 CEST] <nevcairiel> AVPackets are refcounted now
[14:45:09 CEST] <rcombs> else interleaving issues
[15:24:55 CEST] <Daemon404> durandal_1707, i sent some comments from the zimg author on your patch
[15:24:59 CEST] <Daemon404> but i replied to thr wrong version
[15:25:04 CEST] <Daemon404> just making sure you see them
[15:26:20 CEST] Action: wm4 wonders why the author of zimg can't do that
[15:26:55 CEST] <Daemon404> he's more 'anonymous' than even you, am4
[15:26:57 CEST] <Daemon404> wm4*
[15:27:05 CEST] <nevcairiel> heh
[15:27:07 CEST] <Daemon404> ive never even seen him use email
[15:27:10 CEST] <Daemon404> only irc
[15:32:31 CEST] <nevcairiel> he doesnt even have a name
[15:32:37 CEST] <nevcairiel> its just "zimg_author"? :P
[15:33:02 CEST] <wm4> that's not his nick
[15:33:05 CEST] <Daemon404> i dunno his real name, and he changes his irc nick fairly often
[15:33:14 CEST] <Daemon404> it wouldnt even be useful to use his irc nick, probably.
[15:33:29 CEST] <Daemon404> maybe he lurks in here under a diff nick, i dunno.
[15:36:05 CEST] <JEEB> AFAIK all of his proxies are banned by freenode
[15:36:18 CEST] <JEEB> I think he was on #mplayer years ago
[15:36:21 CEST] <Daemon404> didnt know he uses proxies
[15:36:24 CEST] <Daemon404> but... it fits him.
[15:37:54 CEST] <J_Darnley> He's hiding behind 7 proxies?
[15:40:35 CEST] <Daemon404> beats me
[15:44:28 CEST] <Gramner> BBB: did you make it through the train exit at the airport?
[15:44:37 CEST] <BBB> same way you got in :-p
[15:44:43 CEST] <Gramner> haha
[15:44:54 CEST] <BBB> ;)
[15:45:01 CEST] <BBB> it seems like everyone does it
[15:45:05 CEST] <BBB> Im only trying to blend in, right?
[15:45:37 CEST] <Gramner> yes, it's a culture exchange thingy
[15:46:42 CEST] <BBB> so Daemon404, I had hoped to sit down with you for a few minutes in the bar one of those nights to discuss some stuff& when are you next in ny?
[15:47:23 CEST] <Daemon404> oct 4 -> 17
[15:47:34 CEST] <BBB> Im stealing you one of these nights, ok?
[15:47:38 CEST] <BBB> or maybe lunch
[15:47:40 CEST] <Daemon404> sure
[15:47:50 CEST] <Daemon404> also the bar in paris sucked anyway ;)
[15:48:34 CEST] <BBB> the sun restaurant was ok
[15:48:43 CEST] <Daemon404> l'Industrie wasn't
[15:48:46 CEST] <BBB> tons of discussion happened
[15:48:52 CEST] <BBB> right, industrie was a little uncomfie
[15:48:54 CEST] <BBB> but ohwell
[15:49:26 CEST] <Daemon404> aye
[15:50:25 CEST] <BBB> so what was jb asking for again exactly from us in the email to send to him?
[15:50:38 CEST] <BBB> I feel even those that werent there should know and I also dont want to forget some part in mine
[15:50:59 CEST] <j-b> I will remail you the info for the homework anyway
[15:51:15 CEST] <BBB> awh thank you dear boss
[15:51:18 CEST] <j-b> because some people left before the end, and they believe they can skip the homework
[15:51:29 CEST] <BBB> oh right
[15:51:38 CEST] <j-b> like Lydia and Thierry who believed they were excused from sending the homework
[15:51:55 CEST] <Daemon404> BBB, i think in this case, 'headmaster' makes more sense than boss
[15:51:57 CEST] <j-b> "You are in the room -> you send homework"
[15:52:04 CEST] Action: Nightrose pokes j-b :D
[15:52:05 CEST] <j-b> head-asshole works too
[15:52:23 CEST] <j-b> ah, it reminds me of asking @ on the other channel
[15:52:27 CEST] <wm4> homework? lol
[15:52:47 CEST] <BBB> wm4: I believe even people outside the room can send in their version
[15:52:51 CEST] <j-b> wm4: you think you can skip it?
[15:52:52 CEST] <BBB> if theyre devs
[15:52:52 CEST] <Gramner> yes, linear algebra homework
[15:53:06 CEST] <j-b> wm4: I'm going to come and see you.
[15:53:14 CEST] <BBB> you have to solve a particular equation, its not too hard
[15:53:21 CEST] <wm4> eh
[15:53:24 CEST] <BBB> but the variables are very troubling
[15:53:27 CEST] <nevcairiel> the french are invading germany now?
[15:54:00 CEST] <j-b> yes
[15:54:09 CEST] <BBB> only one french
[15:54:13 CEST] <BBB> so a french, not the french
[15:54:17 CEST] <nevcairiel> heh
[15:54:18 CEST] <BBB> although he is the frenchman
[15:54:35 CEST] <BBB> j-b napoleon
[15:57:33 CEST] Action: BBB goes write more checkasm stuff
[15:57:43 CEST] <Gramner> \o/
[15:59:03 CEST] <durandal_1707> Daemon404: I fixed that matrix stuff in latest version, gonna also move graph calling code to increase performance
[16:00:01 CEST] <BBB> Gramner: I like it, I think it works pretty well, just had to get used to it
[16:00:14 CEST] <BBB> Gramner: I still dont udnerstand how to bench only a subset of funcitons
[16:00:16 CEST] <BBB> but Ill learn
[16:00:37 CEST] <Gramner> --bench=<prefix> benchs all functions starting with <prefix>
[16:00:43 CEST] <cone-052> ffmpeg 03Kyle Swanson 07master:a9509ad3f0e1: avfilter: add tremolo filter
[16:01:00 CEST] <Gramner> should ideally be a real regex I guess, "patches welcome"
[16:03:30 CEST] <BBB> thats ok, tnx
[16:03:39 CEST] <durandal_1707> Daemon404: on what channel he is?
[16:03:46 CEST] <BBB> and prefix is then matched against the string in check_func right?
[16:03:55 CEST] <Gramner> yeah, exactly
[16:04:16 CEST] <BBB> cool
[16:22:01 CEST] <Daemon404> durandal_1707, semi-"underground" channel on an anime network
[16:22:10 CEST] <Daemon404> i will ping him to see if he will poke his head out...
[16:22:24 CEST] <nevcairiel> sounds like a library not worth supporting imho :P
[16:22:36 CEST] <nevcairiel> paranoid devs have a habbit of disappearing
[16:23:02 CEST] <Daemon404> not always
[16:23:09 CEST] <Daemon404> i mean, you just described half of the ffmpeg devs
[16:23:17 CEST] <ubitux> does anyone have any metrics or eventually general feedback about thor aside from the self advertising comparison with HM?
[16:23:37 CEST] <Daemon404> ubitux, he said to look for the IETF mail iirc
[16:23:40 CEST] <Daemon404> where they compare to x265
[16:23:43 CEST] <nevcairiel> so you are saying watching that particular video might be a waste of my time?
[16:23:52 CEST] <Daemon404> nevcairiel, it introduces the codec concepts
[16:23:59 CEST] <Daemon404> if you care about those, then watch
[16:24:09 CEST] <nevcairiel> is the answer "half hevc"?
[16:24:10 CEST] <ubitux> Daemon404: i'm guessing you didn't?
[16:24:39 CEST] <Daemon404> i didnt look, no
[16:24:42 CEST] <ubitux> i'm surprised they have no legal problem given how similar it looks to hevc & vp9
[16:24:54 CEST] <Daemon404> because they only use bits of hevc which cisco owns.
[16:25:27 CEST] <ubitux> they own a lot then :p
[16:25:53 CEST] <ubitux> transforms, block sizes, overall identical architecture, ... 
[16:25:58 CEST] <ubitux> well ianal
[16:26:09 CEST] <wm4> what if cisco turns into a patent troll?
[16:26:43 CEST] <Daemon404> i dont think you can patent a block size...
[16:27:12 CEST] <wm4> you can patent colors
[16:27:17 CEST] <wm4> (solid colors)
[16:34:02 CEST] <fritsch> wm4: yeah ... some patent magenta ...
[16:34:29 CEST] <fritsch> RAL-4010 to be more exact
[16:34:45 CEST] <fritsch> but that's most likely US only, in germany it's called color trademark or some thing
[16:36:18 CEST] <J_Darnley> Oh, like Apple's patent on a rounded rectangle
[16:36:38 CEST] <J_Darnley> ... or was that actually a trademark case?
[16:41:05 CEST] <wm4> do you think the h264_mp4toannexb_bsf should take care of moving a PPS to the correct access unit, if the PPS is in the packet before the IDR picture slice? or should this be considered a muxer bug?
[16:45:13 CEST] <philipl> fritsch: they ship something so old that AVPixelFormat and AV_PIX_FMT_* don't exist?
[16:45:36 CEST] <fritsch> philipl: nope, we ship 2.8.0 :-)
[16:45:45 CEST] <philipl> fritsch: The arch and gentoo problem I mean.
[16:45:57 CEST] <philipl> I know you ship 2.8.0. In that context, the patch is backward compatible.
[16:46:06 CEST] <fritsch> basically this was from a time where libav older ffmpeg versions had issues with the way we used vdpau
[16:46:20 CEST] <fritsch> so starting videos segfaulted right away
[16:46:25 CEST] <fritsch> second issues was with the resampler
[16:46:26 CEST] <philipl> Oh. So, my patch just renames some things.
[16:46:32 CEST] <philipl> There's no other compatibility issue.
[16:46:43 CEST] <fritsch> we used some options to set resampler quality
[16:46:46 CEST] <fritsch> those were gone in their builds
[16:46:51 CEST] <fritsch> and evil stuff happened
[16:47:02 CEST] <fritsch> and we ship ~ 10 patches that are specific to kodi
[16:47:09 CEST] <fritsch> and not suited for general ffmpeg
[16:47:12 CEST] <fritsch> since many years
[16:47:17 CEST] <philipl> This is a patch for xbmc master so that it can compile against ffmpeg master.
[16:47:33 CEST] <fritsch> philipl: very welcome, yes
[16:47:43 CEST] <philipl> Ok. I'll send a pull request in a bit.
[16:47:44 CEST] <fritsch> i have seen we use some coded_frame structs
[16:47:53 CEST] <fritsch> that are deprecated also
[16:48:03 CEST] <philipl> but not removed at this stage.
[16:48:07 CEST] <fritsch> ah okay
[16:48:08 CEST] <durandal_1707> Daemon404: is he gonna just rename header or also change abi in 3th header
[16:48:13 CEST] <Daemon404> i dont know
[16:48:17 CEST] <fritsch> philipl: oki, thx much
[16:48:22 CEST] <philipl> saste: I'll try and do that today.
[16:48:29 CEST] <saste> philipl, thanks
[16:48:34 CEST] <fritsch> when 2.8.x stays working all fine
[16:48:40 CEST] <philipl> fritsch: great.
[16:49:12 CEST] <Daemon404> durandal_1707, 1 sec he just showed up online
[16:49:52 CEST] <fritsch> philipl: btw. is there a well documented way on howto remove coded_frame deprecated api usage?
[16:50:01 CEST] <fritsch> cause we use it at some positions quite heavily
[16:51:25 CEST] <BBB> ubitux: the coding is much less efficient
[16:51:38 CEST] <BBB> ubitux: dont forget, cisco wanted cavlc
[16:51:42 CEST] <BBB> ubitux: everyone else didn't
[16:51:49 CEST] <wm4> fritsch: there are replacements, possibly look at apichanges.txt
[16:51:49 CEST] <Daemon404> fritsch, * @deprecated use the quality factor packet side data instead
[16:51:51 CEST] <BBB> ubitux: so this seems like their cavlc proposal which didnt make it into hevc
[16:52:00 CEST] <wm4> err, that's just APIchanges
[16:52:15 CEST] <Plorkyeran> that's what he said in the talk, yeah
[16:52:18 CEST] <Daemon404> wm4, its from the header
[16:52:19 CEST] <fritsch> wm4: Daemon404 thx will have a look
[16:52:23 CEST] <Daemon404> durandal_1707,  https://github.com/sekrit-twc/zimg/issues/26
[16:52:43 CEST] <Daemon404> he opened a thread for discussion and questions on zimg for you...
[16:52:52 CEST] <Daemon404> because he has no public email
[16:52:53 CEST] <Daemon404> (lol)
[16:53:41 CEST] <fritsch> wm4: Daemon404 yeah it was coded_width and coded_height
[16:53:44 CEST] <fritsch> we use heavily
[16:53:57 CEST] <fritsch> cause we don't actually have AVCodecParseContext
[16:53:59 CEST] <fritsch> in our given code
[16:54:05 CEST] <wm4> what do you need it for?
[16:55:47 CEST] <fritsch> wm4: https://github.com/xbmc/xbmc/blob/master/xbmc/cores/dvdplayer/DVDCodecs/Video/DVDVideoCodecFFmpeg.cpp#L288
[16:55:50 CEST] <fritsch> see the comment also
[16:56:04 CEST] <ubitux> BBB: ok
[16:56:21 CEST] <Daemon404> fritsch, that means next to nothing...
[16:56:27 CEST] <Daemon404> may as well put // fix bug
[16:56:31 CEST] <ubitux> BBB: cavlc is one of the entropy encoding in low h264 profile right?
[16:56:33 CEST] <fritsch> https://github.com/xbmc/xbmc/blob/master/xbmc/cores/dvdplayer/DVDCodecs/Video/VAAPI.cpp#L523 <- here
[16:56:36 CEST] <fritsch> that's more needed
[16:56:40 CEST] <fritsch> to get our surface dimensions
[16:56:44 CEST] <nevcairiel> coded_width is not coded_frame, entirely unrelated
[16:56:50 CEST] <fritsch> yeah
[16:56:55 CEST] <fritsch> i had the wrong thing in mind, sorry
[16:57:00 CEST] <wm4> what nevcairiel said
[16:57:05 CEST] <nevcairiel> coded_frame was really only used for encoders
[16:57:17 CEST] <fritsch> we have this in our ffmpegencoder in cdrip
[16:57:46 CEST] <fritsch> https://github.com/xbmc/xbmc/blob/master/xbmc/cdrip/EncoderFFmpeg.cpp#L319 <- yeah here
[16:57:51 CEST] <fritsch> but that's only two positions
[16:58:05 CEST] <nevcairiel> the pkt includes the timestamp
[16:58:05 CEST] <fritsch> the coded_width and coded_height we use in every DVDCodec implementation
[16:58:15 CEST] <nevcairiel> easy enough to replace
[16:58:32 CEST] <nevcairiel> or well in this particular instance, just remove
[16:58:33 CEST] <nevcairiel> i guess
[16:58:34 CEST] <nevcairiel> :D
[16:59:07 CEST] <fritsch> for the decoders ... we need it to determine the surface widths we allocate
[16:59:22 CEST] <fritsch> (not talking about coded_frame) again
[16:59:22 CEST] <nevcairiel> thats pretty normal usage
[16:59:30 CEST] <nevcairiel> i use it all the time as well, and its not going away
[16:59:49 CEST] <fritsch> wait
[16:59:52 CEST] <wm4> ubitux: are you ok with those dvdsub fixes?
[17:00:03 CEST] <nevcairiel> only coded_frame is going away
[17:00:07 CEST] <fritsch> coded_width and coded_height is also deprecated or I completely miss that
[17:00:10 CEST] <fritsch> okay
[17:00:21 CEST] <BBB> ubitux: yes
[17:00:37 CEST] <ubitux> wm4: i thought they were all reviewed and/or applied already?
[17:00:38 CEST] <BBB> ubitux: the one everyone complains about and nobody uses because it compresses like crap but makes each decoder twice as complex
[17:00:42 CEST] <ubitux> wm4: which did i miss?
[17:00:42 CEST] <BBB> ubitux: same as interlacing/mbaff
[17:01:04 CEST] <ubitux> BBB: i though the purpose of thor was low complexity, at least initially
[17:01:22 CEST] <ubitux> but ok
[17:01:25 CEST] <wm4> ubitux: strange failures with mplayer encoded dvd vobsubs, see "[PATCH 1/2] avcodec/dvdsub: fix partial packet assembly" and the following patch
[17:01:26 CEST] <nevcairiel> isnt cavlc simpler than cabac
[17:01:33 CEST] <Daemon404> of course it is
[17:01:36 CEST] <wm4> also I'm just going to push that HLS patch
[17:01:37 CEST] <Daemon404> vlcs vs aricoder
[17:02:35 CEST] <ubitux> wm4: you checked that this partial messup was not because of a bug in the vobsub demuxer, right?
[17:02:50 CEST] <ubitux> i never had a specs about this, i don't know how it works
[17:03:44 CEST] <Daemon404> what you dont want to order a physical copy of the dvd specs under nda?
[17:03:48 CEST] <Daemon404> (digital is not available iirc)
[17:04:10 CEST] <wm4> ubitux: mplayer's vobsub demuxer encounters the same broken packet, but works it around
[17:04:15 CEST] <wm4> couldn't find out what the heck vlc does
[17:04:17 CEST] <ubitux> Daemon404: i can't believe this is still under nda
[17:04:37 CEST] <ubitux> wm4: yeah, and same for mencoder i guess :D
[17:04:39 CEST] <nevcairiel> for some reason dvds are one of the best kept secrets in multimedia
[17:04:56 CEST] <ubitux> nevcairiel: it's really insane :(
[17:05:17 CEST] <wm4> well, if someone wants to debug why mencoder writes a broken file, I can point you to the user
[17:07:31 CEST] <ubitux> wm4: i don't think i can review this patch properly, so you can try to believe in yourself
[17:07:58 CEST] <ubitux> but i'd check if it's not the vobsub demuxer messing up something
[17:08:04 CEST] <ubitux> it's using the mpeg parsing code
[17:08:20 CEST] <ubitux> which might randomly parse stuff because of weird heuristics
[17:08:22 CEST] <wm4> I have no idea about this code though
[17:08:34 CEST] <ubitux> (and me failing to "reassemble" them properly)
[17:08:40 CEST] <wm4> mplayer has its completely own vobsubs-specific code for this, and gets the same result
[17:08:54 CEST] <ubitux> you mean packet wise?
[17:08:57 CEST] <wm4> yeah
[17:09:02 CEST] <ubitux> ok
[17:09:21 CEST] <ubitux> and it has its own dvd sub decoder too right?
[17:09:25 CEST] <wm4> maybe I should try to get a HDDVD (or whatever it's called) sample somewhere
[17:09:28 CEST] <wm4> yes
[17:09:30 CEST] <wm4> of course
[17:09:32 CEST] <nevcairiel> you want one?
[17:09:37 CEST] <wm4> nevcairiel: sure
[17:14:21 CEST] <nevcairiel> its HD  so its kinda on the big side  (150MB or so), http://files.1f0.de/samples/PEVOB_1.EVO
[17:14:42 CEST] <wm4> thanks
[17:16:22 CEST] <Daemon404> 150 isnt big
[17:16:32 CEST] <nevcairiel> people like small samples
[17:16:36 CEST] <wm4> I got a 13GB sample file from someone today
[17:16:54 CEST] <nevcairiel> but at least i dont have to use some chinese file hosting service with 10kb/s bandwidth
[17:17:23 CEST] <Daemon404> please download these 178 rar parts, with a mandatory 2 hour wait between downloads on this host
[17:22:53 CEST] <TimNich> I was offered a set of reference samples recently. However the cost was high as it included the 30T NAS they came on...
[17:23:27 CEST] <Daemon404> were these 4k dpx or something
[17:23:40 CEST] <nevcairiel> lol
[17:23:57 CEST] <TimNich> Probably, I cant remember now.
[17:24:24 CEST] <Daemon404> could be exr too i guess
[17:24:34 CEST] <Daemon404> or tiff. or ... tga.
[17:24:37 CEST] <TimNich> Yes they were 4k colour reference samples.
[17:25:03 CEST] <TimNich> ISTR they were in various formats
[17:25:10 CEST] <Daemon404> oh.
[17:26:17 CEST] <TimNich> My boss wouldnt buy it, luterally.
[17:26:55 CEST] <Daemon404> he would prefer a magic black box that outputs the images, im sure
[17:27:00 CEST] <Daemon404> preferably via sdi
[17:28:28 CEST] <TimNich> Well he is a colorist by training so no. (and he doesnt like hybrid log gamma)
[17:29:03 CEST] <wm4> so, who invented this DCP crap
[17:30:00 CEST] <durandal_1707> michaelni: why are you manually pushing stuff to ffmpeg github repo?
[17:30:23 CEST] <philipl> fritsch: https://github.com/xbmc/xbmc/pull/8112
[17:37:29 CEST] <J_Darnley> Should I add new ffmpeg option to the end of the options table?
[17:38:46 CEST] <BBB> I dont think order has any abi relevance
[17:38:58 CEST] <BBB> so anywhere if it fits should be ok
[17:41:47 CEST] <cone-052> ffmpeg 03wm4 07master:26eb2940079d: avformat/hls: fix some cases of HLS streams which require cookies
[17:41:48 CEST] <cone-052> ffmpeg 03wm4 07master:f874e2728b09: avcodec/dvdsub: fix partial packet assembly
[17:41:49 CEST] <cone-052> ffmpeg 03wm4 07master:9aab22223908: avcodec/dvdsubdec: reject some broken packets
[17:41:50 CEST] <cone-052> ffmpeg 03wm4 07master:e859a3c864d5: avcodec/dvdsubdec: don't use a NULL log context
[17:46:28 CEST] <fritsch> philipl: thx very much - let's see what jenkins tells us
[17:49:37 CEST] Action: TimNich remembers it was the EBU Test Sequences that cost an arm and a leg
[17:57:53 CEST] <durandal_1707> huh, enable-x86simd is not currently implemented
[17:58:16 CEST] <durandal_1707> this make it unusable
[17:59:08 CEST] <Daemon404> because it is temporarily disabled
[17:59:11 CEST] <Daemon404> during the api rework
[17:59:24 CEST] <wm4> this code is in heavy development
[17:59:39 CEST] <wm4> he just got it work at all, or something
[18:02:35 CEST] <durandal_1707> ah
[18:07:37 CEST] <durandal_1707> what is this fmtconv ?
[18:07:49 CEST] <wm4> something older and slower (also C++)
[18:08:08 CEST] <wm4> apparently the only mirror got deleted
[18:08:22 CEST] <wm4> you still can get the .zip source drops from doom9 I guess
[18:13:54 CEST] <wm4> https://github.com/EleonoreMizo/fmtconv
[18:14:07 CEST] <wm4> apparently this is even official
[18:14:12 CEST] <JEEB> yeah
[18:14:15 CEST] <durandal_1707> but this is vs only
[18:17:23 CEST] <Daemon404> yes
[18:38:18 CEST] <fritsch> philipl: yeah, fernet is currently rewriting the video player and this work should be finished in some days ... so in order he does not have to rebase everything I will keep it open and send a PR to your repo, that you can squash when it is in
[19:16:40 CEST] <J_Darnley> And there's my first patch in a long time.
[19:27:09 CEST] <BBB> writing an itxfm test is harder than it seems :/
[19:27:17 CEST] <BBB> but at least its correct now
[19:42:27 CEST] <j-b> m
[20:47:56 CEST] <philipl> fritsch: sure. No problem.
[21:02:15 CEST] <cone-071> ffmpeg 03Andreas Cadhalpun 07master:f9f0b4c08e7d: hls: only seek if there is an offset
[21:46:13 CEST] <cone-071> ffmpeg 03Michael Niedermayer 07master:31623e9d1ea9: avcodec/mpegvideo_enc: Avoid fine lambda steps in VBV retry code when RD is not in use
[22:41:38 CEST] <durandal_1707> colors of BBB talk are messed up
[22:44:29 CEST] <BBB> ?
[22:44:51 CEST] <nevcairiel> the camera seems to generally have some weird problems
[22:49:56 CEST] <RiCON> other than breaking sound in the intro and a jumpcut in atomnuker's near the end it was ok
[22:51:06 CEST] <Gramner> they changed the memory card in the camera in the middle of one talk, probably that for your last point
[22:51:44 CEST] <atomnuker> you mean someone actually saw the entire talk? Even I can't stand my own voice
[22:51:58 CEST] <nevcairiel> there is a weird scrolling brightness effect, i especially noticed in the x265 video
[22:52:04 CEST] <Gramner> nobody can stand their own voice
[22:53:32 CEST] <kierank> atomnuker: your talk was probably the best one
[22:53:44 CEST] <kierank> (sorry BBB et al)
[22:53:51 CEST] <nevcairiel> and you pronounced my nick correctly, thats a bonus
[22:54:15 CEST] <Gramner> the spice talk was clearly the best ;)
[22:54:22 CEST] <BBB> I agree
[22:54:25 CEST] <BBB> spice++
[22:54:43 CEST] <nevcairiel> whats a spice talk
[22:54:45 CEST] <BBB> sorry atomnuker
[22:54:53 CEST] <RiCON> BBB's was the easier to follow
[22:54:56 CEST] <RiCON> as a non-coder
[22:55:12 CEST] <Gramner> the spice talk was so top secret that it wasn't uploaded to youtube
[22:55:39 CEST] <BBB> RiCON: right, but for some people that makes it less interesting since they want to see more algorithmic stuff
[22:55:47 CEST] <atomnuker> I concur, spice was the best, taste wasn't bad
[22:56:00 CEST] <BBB> RiCON: nextt time maybe Ill add some algorithmic or coding stuff on whats going on
[22:56:08 CEST] <BBB> but first I should write a blog post
[22:57:25 CEST] <Gramner> wathing algorithmic videos is nice, I'm just generally too lazy to read other peoples algorithmic code to understand what's going on
[22:58:33 CEST] <BBB> omg Gramner you say that while being the main maintainer left on x264 :D
[22:59:30 CEST] <Gramner> bugmaster gets the honor of dealing with most of the algorithms
[23:04:03 CEST] <Gramner> there aren't many algorithmic changes in x264 nowadays though except vbv stuff
[23:04:49 CEST] <Plorkyeran> spice was the best beer I had all weekend
[23:05:06 CEST] <Plorkyeran> (not that the other beer I had was very good)
[23:06:58 CEST] <Gramner> I'd probably buy some of it it there's a somewhat reasonable cost and shipping method, if nothing else just to boost my chances of winning the ongoing office nerd contest
[23:13:33 CEST] <cone-071> ffmpeg 03Paul B Mahol 07master:ed4257de2d74: avfilter: add agate filter
[23:47:36 CEST] <Gramner> BBB: a floating-point hadamard transform huh. that's not something you see every day in code related to video coding
[23:50:58 CEST] <Daemon404> hes gone
[23:51:02 CEST] <Daemon404> and ... context?
[23:52:22 CEST] <Gramner> ah i see. context is that his vp9 itxfm checkasm patch uses floating-point code for testing integer code, which is interesting
[23:54:58 CEST] <cone-071> ffmpeg 03Michael Niedermayer 07master:118b1ba43bfa: avfilter/hermite: fix "libavfilter/hermite.h:19:15: error: no previous prototype for hermite_interpolation"
[23:54:59 CEST] <cone-071> ffmpeg 03Ganesh Ajjanagadde 07master:4f90818ea12e: avcodec/x86/rv40dsp_init: silence -Wunused-variable on --disable-mmx
[23:55:00 CEST] <cone-071> ffmpeg 03Ganesh Ajjanagadde 07master:0544c95fd6d0: avcodec/x86/mpegaudiodsp: silence -Wunused-variable on --disable-mmx
[23:55:49 CEST] <nevcairiel> in before it breaks fate on a few system because float
[00:00:00 CEST] --- Wed Sep 23 2015