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

[burek]

[00:40] <cone-383> ffmpeg.git 03Diego Biurrun 07master:67a7695c1425: avfilter: Remove unused variable from ff_get_video_buffer()
[00:41] <cone-383> ffmpeg.git 03Michael Niedermayer 07master:5a22877e9d19: Merge commit '67a7695c142561fe60f21adffe89c133385d37c9'
[00:52] <kurosu__> BBB / michaelni: I'm for pushing "Re: [FFmpeg-devel] [PATCH] x86: hevc: adding transform_add"
[00:52] <kurosu__> another reason being that it is not the most important part of the idct
[01:21] <BBB> kurosu__: can you explain why not?
[01:23] <kurosu__> BBB: if I'm not mistaken, transform_add is not the idct
[01:23] <kurosu__> it's just hevc's add clamped or whatever
[01:23] <kurosu__> I think this might needed for range extensions where there is an inter-component residual prediction
[01:24] <kurosu__> so you have to really idct to produce residuals
[01:24] <kurosu__> and not just do idct+add clamped in one step
[01:26] <BBB> oh, I see, its not the idct
[01:26] <BBB> so its not the interesting part
[01:26] <BBB> ok
[01:26] <kurosu__> yeah
[01:28] <BBB> right, ok, michaelni: patch ok
[01:28] <BBB> Im not sure Id do that in separate functions but ok I wont complain until I write it myself
[01:29] <kurosu__> and I present you our first broken hevc stream with somewhat widespread
[01:29] <kurosu__> ticket #3872
[01:29] <BBB> rofl
[01:29] <BBB> well that was to be expected
[01:30] <kurosu__> seems to be that: http://kickass.to/michael-jackson-hevc-x265-1080p-eng-t9386565.html
[01:30] <kurosu__> i'm not completely sure, but the SPS looks truncated
[01:30] <kurosu__> might be a bug in the multiplexing tool (mkvtoolnix 7.1) apparently
[01:33] <jamrial> it's probably what kurosu said. transform_dc_add got split into idct_dc and transform_add when the rext stuff was merged
[01:37] <cone-383> ffmpeg.git 03Pierre Edouard Lepere 07master:a6af4bf64dae: x86: hevc: adding transform_add
[02:36] <cone-383> ffmpeg.git 03James Almer 07master:9f498f4e6fa0: x86/hevc_res_add: fix register count in hevc_transform_add{16,32}_10_avx2
[10:19] <kurosu__> for whoever read and/or noted my comment on hevc+sps truncation, at least it's not an obvious mkvtoolnix 7.1's fault: other hevc streams get properly muxed without truncation
[10:56] <nevcairiel> i'm slightly confused, why do the 10-bit versions of hevc_transform_add32 use way less registers than the 8-bit versions
[10:58] <nevcairiel> and more importantly, i dont even see where it uses them :D
[10:59] <nevcairiel> oh, i'm blind, i see
[10:59] <nevcairiel> still not sure why
[11:19] <ubitux> /home/ux/fate/ffmpeg/libavformat/rtmppkt.c:269:4: error: implicit declaration of function $if [-Werror=implicit-function-declaration]
[11:19] <ubitux> wtf is lcov doing
[11:24] <plepere> nevcairiel, 
[11:25] <plepere> the transform add in 8 bit adds a 8bit and a 16bit int
[11:25] <plepere> so there's a need to split the 16bit to 2 8 bits
[11:25] <plepere> while in 10bit, it's 16bit + 16bit.
[11:27] <J_Darnley> What?  It does a high and low byte?
[11:32] <henry0312> wm4, ubitux: https://gist.github.com/henry0312/b0feccedd5b9fd2e636b
[11:32] <henry0312> sorry it took so long.
[11:34] <henry0312> btw, what does '1 +'  at the line 57 in the above diff mean/do?
[11:35] Action: henry0312 goes afk.
[11:37] <henry0312> < henry0312> btw, what does '1 +'  at the line 57 in the above diff mean/do?  <-- I want to know why adding + 1.
[11:48] <kurosu> how can one recompile some files by eg adding -DDEBUG=1 to cflags ?
[11:48] <kurosu> I saw specifying that in CFLAGS didn't help
[11:49] <kurosu> I'm split between adding additional environment vars, adding new rule or something else
[11:50] <nevcairiel> I assume for all files is not what you would like
[11:50] <kurosu> no, and editing config.mak would force recompiling?
[11:51] <nevcairiel> dont think it would force it, I've had that as a problem before that it didn't pick up changes in the makefiles, only in the actual files
[11:51] <kurosu> oh ok
[11:51] <kurosu> it's just that it easy to forget it
[11:51] <kurosu> *is easy to forget about it
[11:51] <kurosu> and have it applied to a lot more files than expected
[11:52] <nevcairiel> yeah..enabling dlog for everything makes it spam so much stuff
[12:15] <J_Darnley> kurosu: if you're not familiar with it, you should look at the -W option for make which tells make to assume the file given is new
[12:18] <kurosu> ok that would do what my rm kind of does + rebuild whatever target I want
[12:39] <cone-166> ffmpeg.git 03Stefano Sabatini 07master:cb0524f7a02f: lavfi/apad: fix if_( style
[15:04] <ubitux> michaelni: "get rid of floats i init code"  "in init code"
[15:06] <ubitux> lol bottom posting apple mail; it works, except the signature stays on top
[15:07] <nevcairiel> lol
[15:08] <Daemon404> apple mail is horrible 
[15:08] <Daemon404> it cant even display threads
[15:09] <Daemon404> it flattens all thread
[15:09] <Daemon404> s
[15:09] <Daemon404> other mail clients are starting to copy it to... and it leads to 10-bazillion-mail-deep nested replies
[15:09] <Daemon404> that are hard as shit to follow
[15:09] <nevcairiel> hey, even outlook can display threads, somewhat!
[15:09] <Daemon404> yeah
[15:10] <nevcairiel> if youre top posting you at least dont have to scroll past billions of deeply nested mails to find the new stuff, huh
[15:10] <Daemon404> i generally trim bottom or interlaved replies
[15:11] <Daemon404> to only contain relevant quotes
[15:11] <Daemon404> most clients make it easy
[15:11] <nevcairiel> i do that too when its getting too excessive, but some people never do it
[15:11] <Daemon404> >>>>>>>>>>>>>>>>>> return 0;
[15:15] Action: michaelni doesnt understand why with something as old as email still the most basic things like threading are handled correctly in some implementations
[15:15] <Daemon404> michaelni, apple mail made a conciosu decision
[15:15] <Daemon404> it's marketed as a feature
[15:15] <Daemon404> "IM-like email replies"
[15:15] <nevcairiel> also known as "dumb email replies"
[15:16] <Daemon404> http://www.postbox-inc.com/
[15:16] <nevcairiel> but yeah, many clients where this doesnt work are intentionally dumbed down
[15:16] <Daemon404> scroll down to "conversation view"
[15:16] <Daemon404> and cringe.
[15:16] <Daemon404> this is literally the onyl view you can use.
[15:17] <Daemon404> aside from no grouping at all
[15:19] <cone-166> ffmpeg.git 03Michael Niedermayer 07master:7caacc50aed5: avcodec/hevc_ps: do cleanup in case of unsupported bit depth
[16:49] <alexfu> what does avpicture_fill do excatly? i'm trying to figure out it's purpose in the code I have.
[16:56] <cone-166> ffmpeg.git 03Michael Niedermayer 07master:05dd5368a927: avformat/nutdec: always initialize event_flags
[18:07] <wm4> henry0312: I don't know ts, but it's part of the public API and documented as having the value+1
[18:08] <wm4> henry0312: maybe it's done so that 0 means "unknown"
[18:08] <wm4> henry0312: you shouldn't change it, even if it's probably stupid
[18:34] <cone-166> ffmpeg.git 03Michael Niedermayer 07master:207609554981: avformat/asfdec: Check av_new_packet()s return code
[18:55] <cone-166> ffmpeg.git 03Michael Niedermayer 07master:a5cbff22b203: avfilter/avf_showspectrum: fix colums typo
[19:23] <henry0312> <+wm4> henry0312: you shouldn't change it, even if it's probably stupid <-- ok!
[19:23] <henry0312> I just read https://www.ffmpeg.org/doxygen/trunk/structAVStream.html
[19:30] <henry0312> wm4: updated https://gist.github.com/henry0312/b0feccedd5b9fd2e636b (also you can see the diff at https://gist.github.com/henry0312/b0feccedd5b9fd2e636b/revisions)
[19:33] <wm4> henry0312: at least to me this looks fine, maybe wait for a comment by kierank 
[19:33] <wm4> then post the patch to the mailing list
[19:34] <henry0312> I wonder MKBETAG('A','R','I','A') and MKBETAG('A','R','I','C') may not be good....
[19:34] <henry0312> hm
[19:34] <henry0312> ok!
[19:34] <wm4> I wonder whether you need to add the new codec IDs to doc/APIchanges
[19:34] <kierank> probably ok as long as it doesn't clash with dvb
[19:34] <wm4> also why are there 2 codec IDs?
[19:35] <JEEB> extracting the text probably isn't going to be too hard, but rendering it will be a whole separate affair :s
[19:36] <wm4> I thought the library does this
[19:36] <wm4> unless there are people who insist the decoder should be NIH'ed
[19:36] <JEEB> orly?
[19:37] <JEEB> I didn't know there was a capable enough renderer for the format
[19:37] <wm4> outputting the result will still be messy though
[19:37] <henry0312> I asked the author of aribb24 to create some documents,
[19:37] <henry0312> and he created, https://github.com/nkoriyama/aribb24/wiki
[19:37] <henry0312> he put SampleCodes and TestData
[19:37] <JEEB> lol, not mentioning which part of ARIB B-24
[19:38] <JEEB> I mean, that thing now has like two or three parts
[19:38] <JEEB> I don't remember any more which was related :/
[19:39] <henry0312> <+wm4> also why are there 2 codec IDs?  <-- please see https://github.com/nkoriyama/aribb24/blob/master/src/aribb24/decoder.h#L65
[19:39] <henry0312> there are arib_initialize_decoder_a_profile and arib_initialize_decoder_c_profile
[19:40] <henry0312> <+kierank> probably ok as long as it doesn't clash with dvb  <-- I'll check.
[19:44] <henry0312> JEEB: yeah, actually we have to read more documents. c.f. https://github.com/nkoriyama/vlc-aribsub/wiki/Aribsubspecification
[20:04] <ubitux> heh
[20:04] <ubitux> i guess pkg-config would have helped here..
[20:06] <henry0312> kierank: sorry, how do I test with DVB?
[20:06] <JEEB> basically check the DVB specs for the defined IDs, I guess?
[20:07] <henry0312> hmm
[20:11] <kierank> henry0312: is there an unambiguous way of checking for a japanese mpegts?
[20:13] <henry0312> kierank: umm.... I don't know.
[20:13] <henry0312> JEEB: do you know?
[20:13] <henry0312> kierank: but ffprobe outpus is the same with mediainfo, which supports ARIB subtitles, i guess.
[20:14] <wm4> if there are clashes (I don't know if there are), mediainfo could have heuristics to resolve them
[20:14] <wm4> or mediainfo could wrongly assume that it's a japanese ts
[20:15] <kierank> henry0312: probably just submit it
[20:15] <wm4> yeah, just submit it
[20:15] <henry0312> ok :D
[20:15] <henry0312> I'll submit.
[20:20] <henry0312> but it's about time to sleep..., so I'll submit it after getting up.
[20:37] <ubitux> wm4: btw, what about utf-16?
[20:37] <ubitux> :-°
[20:37] <wm4> that's actually not much work
[20:38] <ubitux> :)
[20:41] <nevcairiel> Didn't an argument with Nicolas stand in the way of utf16 the last time
[20:43] <ubitux> i think wm4 stand in the way of generic charset detect project from nicolas instead, iirc
[20:44] <wm4> nicolas wanted to implement generic charset detection, on the demuxer level
[20:44] <wm4> but it was bad because it tried to deal with 8 bit legacy charsets
[20:44] <wm4> where it's not always possible to find a good or correct match
[20:45] <iive> there is enca librarby, but imho it haven't gotten much development since its creation. (I could be wrong).
[20:45] <cone-166> ffmpeg.git 03Lou Logan 07master:d2163f5e2836: doc/ffmpeg: fix metadata language example
[20:45] <wm4> iive: enca is pretty bad
[20:45] <wm4> in fact most/all charset detectors are
[20:46] <iive> at lest supporting BOM should be easy.
[20:46] <ubitux> iive: actually, not really&
[20:46] <ubitux> it's hard to make such abstraction properly
[20:46] <wm4> BOM is pretty easy and that's what my patch did
[20:46] <ubitux> it's not about the detection itself but the integration within ffmpeg
[20:47] <wm4> of course it's assuming that the BOM is 100% reliable and sufficient
[20:47] <wm4> but then, most UTF-16 files are made by microsoft tools...
[21:21] <alexfu> what's required to open a network stream?
[21:22] <ubitux> a network connection
[21:23] <alexfu> ubitux: besides that. I get an IO error. is it somethign that should just "work"?
[21:23] <ubitux> i can't guess the problem with so much information
[21:24] <ubitux> btw, you should probably ask #ffmpeg, unless you're actually writing code for ffmpeg
[21:24] <alexfu> ubitux: yes, i am asking in the context of writing ffmpeg code in C
[21:25] <ubitux> this is not *for* ffmpeg, this is *with* ffmpeg
[21:25] <ubitux> it's not really a channel for api usage
[21:25] <Mavrik> on the other hand this is pretty much the only channel with people that know how api works in depth :)
[21:29] <alexfu> ubitux: so... the #ffmpeg channel is not for ffmpeg users?
[21:31] <llogan> #ffmpeg-devel is for FFmpeg development. #ffmpeg is for user support.
[21:31] <kurosu> for development of FFmpeg, even?
[21:32] <kurosu> user = user of the libav libraries
[21:32] <kurosu> like the mailing lists
[21:35] <wm4> Mavrik: yes, but I think ubitux feels like his questions are way too basic
[21:36] <ubitux> i was just being an dick, don't mind me
[21:36] <ubitux> -n
[21:42] <Mavrik> wm4, hmm, yes, that might be an issue :)
[21:50] <ubitux> would anyone be interested in having an advanced pkg config customization in the configure?
[21:50] <ubitux> like, being able to staticly link only one (pkg-config detected) library?
[21:50] <ubitux> typically what we can do with autotools
[21:52] <Compn> im sure someone is interested
[21:53] <alexfu> wow... i'm an idiot... forgot to specify internet permissions for my app.
[21:53] <ubitux> told you you needed a network connection...
[21:53] <ubitux> ;)
[21:56] <cone-166> ffmpeg.git 03James Almer 07master:76a99d467fff: x86/hecv_res_add: add ff_hevc_transform_add{8,16,32}_8_avx
[21:57] <wm4> http://coverage.ffmpeg.org/
[21:57] <wm4> lol only 17% for libswscale?
[21:57] <ubitux> x86
[21:57] <ubitux> i thought i disabled the asm actually
[21:58] <ubitux> i'm actually running the tests with CPUFLAGS=none
[22:25] <cone-166> ffmpeg.git 03Clément BSsch 07master:f2f6d45dbd17: avfilter/showwaves: add "cline" mode (centered line)
[22:25] <cone-166> ffmpeg.git 03Clément BSsch 07master:ba29746feb54: avfilter/showwaves: split out draw sample code
[22:25] <cone-166> ffmpeg.git 03Clément BSsch 07master:e35fb5add45c: avfilter/showwaves: add split_channels option
[22:27] <ubitux> ./ffplay -f lavfi "amovie=$HOME/samples/test.flac,asplit=2[out0][w];[w]showwaves=mode=cline:split_channels=1:s=640x480[out1]"
[22:28] <ubitux> not exactly crazy but well... :)
[22:28] <ubitux> note: i'm working on extracting the whole song in a single frame
[22:30] <cone-166> ffmpeg.git 03Clément BSsch 07master:5abcc8e1a0e2: doc/filters: fix cline option name recently added
[22:32] <cone-166> ffmpeg.git 03Clément BSsch 07master:e298b2f5d6db: avfilter/showwaves: align const mode values (cosmetics)
[22:32] <j-b> VDD registration is almost over
[22:33] <llogan> i wish i could have gone. always wanted to visit that area.
[22:34] <ubitux> michaelni: no comment on codecview? (more than half of the code in it is yours)
[22:55] <michaelni> ubitux, comment added
[22:57] <ubitux> ah cool, thanks for the sample
[22:58] <ubitux> michaelni: inserting the filter in ffmpeg won't solve the problem for ffplay
[22:58] <ubitux> the code is still kept anyway, the warning should be enough for the time being
[23:20] <ubitux> mmh i think i messed up something with the mv exports
[23:21] <ubitux> since the coordinates can be outside the frame
[23:21] <ubitux> i need to make the src[xy] and dst[xy] signed
[23:30] <wm4> why would you even put effort into keeping the command line compatible for this
[23:32] <ubitux> wm4: https://encrypted.google.com/search?hl=en&q=vismv
[23:32] <ubitux> it's probably used somehow a bit
[23:32] <ubitux> but the deprecation process should be fine
[23:33] <wm4> most of these are ffmpeg ml posts...
[23:33] <ubitux> it's probably not used for anything critical so yeah it's fine to deprecate it
[23:33] <ubitux> i don't think a compat layer is necessary
[00:00] --- Thu Aug 21 2014