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

[burek]

[00:37] <kierank> 10:05 PM <"Daemon404> >making the user manually call emms
[00:37] <kierank> I disagree
[00:37] <kierank> as long as it's documented then it's ok
[00:37] <kierank> (assuming the speed difference is not negliglbe)
[00:40] <jamrial> making emms_c() public makes no sense. there's an intrinsic for that in every c library
[00:41] <jamrial> emms_c() in fact calls that intrinsic if there's no inline asm support
[02:27] <cone-268> ffmpeg.git 03John Stebbins 07master:998c9f15d1ca: idct: remove call to ff_idctdsp_init from ff_MPV_common_init
[02:27] <cone-268> ffmpeg.git 03Michael Niedermayer 07master:2fd87a3d7895: Merge commit '998c9f15d1ca8c7489775ebcca51623b915988f1'
[02:42] <cone-268> ffmpeg.git 03John Stebbins 07master:b869eea7ea8f: h263dec: Fix order of initialization
[02:42] <cone-268> ffmpeg.git 03Michael Niedermayer 07master:012062cfd51f: Merge commit 'b869eea7ea8f5d8331fcd6355f848bb6a6e06b14'
[03:10] <cone-268> ffmpeg.git 03John Stebbins 07master:552bc42df487: h261dec: Fix order of initialization
[03:10] <cone-268> ffmpeg.git 03Michael Niedermayer 07master:595c63357cdc: Merge commit '552bc42df48784ae3ce0d499ece5b33f3cc7576a'
[03:10] <cone-268> ffmpeg.git 03Michael Niedermayer 07master:6c1ee1a11446: avcodec/h261dec: Fix context initialization sequence
[05:51] <cone-268> ffmpeg.git 03Christophe Gisquet 07master:33fefdb44992: ffmpeg: fix streamcopy with side data
[05:51] <cone-268> ffmpeg.git 03Michael Niedermayer 07master:d3a22491c736: ffmpeg: remove 32 channel limit from audio_channels_map
[07:52] <ubitux> wm4: yes, the bump adopted the new behaviour
[08:03] <ubitux> i'll probably mention it in the behaviour changes section in the release notes
[08:15] <nevcairiel> It changed codec Id right?
[08:15] <ubitux> yes
[08:15] <nevcairiel> Then I hopefully handle that already
[10:38] <durandal_1707> why is now important to have signed off patches???
[10:46] <nevcairiel> i never understood why you would sign-off your own patches specifically, obviously you signed it off, since you're the author :D
[12:29] <cone-574> ffmpeg.git 03Diego Biurrun 07master:7ccb847f0f1f: http: Reduce scope of a variable in parse_content_encoding()
[12:30] <cone-574> ffmpeg.git 03Michael Niedermayer 07master:1e81b185ae72: Merge commit '7ccb847f0f1f28199fa254847b91b6e50fb92832'
[12:38] <cone-574> ffmpeg.git 03Diego Biurrun 07master:6baeadd11083: w32pthreads: Mark functions in compatibility wrapper as av_unused
[12:38] <cone-574> ffmpeg.git 03Michael Niedermayer 07master:6afd726b7b27: Merge commit '6baeadd11083774ebd823dd5e1a744c2150a3bfc'
[12:45] <cone-574> ffmpeg.git 03Diego Biurrun 07master:7c371754fbc0: atomic_win32: Drop unnecessary atomic.h #include
[12:45] <cone-574> ffmpeg.git 03Michael Niedermayer 07master:edd0dc854d45: Merge commit '7c371754fbc0dcc23bd00278b147f8095ccc5625'
[14:48] <ubitux> http://www.iquilezles.org/blog/?p=2892
[14:49] <J_Darnley> Interesting.
[14:49] Action: J_Darnley goes to find a calculator
[14:50] <J_Darnley> Wow it does work
[14:50] <ubitux> this guy drives me crazy every time
[14:51] <ubitux> (https://www.shadertoy.com/view/ldXXDj)
[15:09] <kierank> 48khz ftw
[15:39] <henry0312> hello, developers.
[15:39] <henry0312> please see http://git.videolan.org/gitweb.cgi/vlc.git/?a=commit;h=97c02be6f591c0f3ef936780c03d3928044e5d49.
[15:40] <henry0312> I'd love to make ffmpeg support ARIB subtitles, which are defined in http://www.arib.or.jp/english/html/overview/doc/6-STD-B24v5_2-1p3-E1.pdf
[15:40] <wm4> ubitux: ^
[15:40] <henry0312> and the vlc commit use https://github.com/nkoriyama/aribb24
[15:41] <nevcairiel> ffmpeg doesn't really do external subtitle rendering libs
[15:41] <wm4> nevcairiel: like libass?
[15:41] <nevcairiel> its certainly not part of any subtitle decoder, and its lavfi integration is questinonable
[15:41] <nevcairiel> -n
[15:42] <ubitux> i saw mention of PNG in the specs and thus closed the pdf in fear
[15:42] <wm4> so do you not believe this belongs into libavcodec?
[15:42] <ubitux> just re-opened it and saw GIF
[15:43] <ubitux> that's actually probably unrelated to the subs
[15:44] <henry0312> hm
[15:44] <ubitux> henry0312: do you wish to add native support or through an external lib?
[15:46] <henry0312> ubitux: I want to use aribb24 (https://github.com/nkoriyama/aribb24) if possible. Can I do this?
[15:47] <ubitux> i guess, even though a native support is often preferred
[15:48] <henry0312> The problem of adding native support is that I don't know much about ARIB STD-B24...
[15:49] <wm4> I don't see a single reason why we should NIH something this complicated and obscure
[15:49] <nevcairiel> ubitux: how would you ever add an external subtitle decoder? make it output bitmaps and pretend its a bitmap subtitle format? :d
[15:50] <ubitux> nevcairiel: yes?
[15:50] <nevcairiel> but it would be the first time, we never did that before, afaik
[15:50] <nevcairiel> all other text things just massage the output to look like ass
[15:51] <ubitux> i assumed it wasn't text subtitles but bitmaps
[15:51] <ubitux> maybe that's more like teletext
[15:52] <ubitux> wm4: ffmpeg isn't a lib web, it's supposed to provide decoders for audio, video and subtitles natively&
[15:53] <nevcairiel> anyway, here, run in fear:
[15:53] <nevcairiel> STD B24 specification is derived from an early draft of XHTML 1.0 strict, which it extends and alters. Some subset of CSS 1 and 2 is supported, as well as ECMAScript.
[15:53] <ubitux> aaaah
[15:53] <nevcairiel> it has the interesting name of Broadcast Markup Language
[15:53] Action: ubitux will stay away from this
[15:54] <J_Darnley> WTF?  javascript in subtitles?
[15:54] <nevcairiel> its probably meant to be more than subtitles to some degree
[15:54] <ubitux> henry0312: we typically have support for libzvbi, so it's probably possible to have support for that aribb24
[15:56] <henry0312> hum
[15:57] <henry0312> ubitux: so, first, do I have to understand libavformat/mpegts.c?
[15:57] <ubitux> i have no idea
[15:58] <wm4> henry0312: you need to find out whether mpegts can already extract the raw captions
[15:58] <ubitux> look at what aribb24 takes in input and what it outputs
[15:59] <henry0312> wm4: i see.
[15:59] <henry0312> ubitux: i see.
[16:03] <ubitux> the decoder doesn't actually look like much work
[16:05] <ubitux> but you actually have some png shit in it
[16:12] <wm4> does the arib lib take care of the png?
[16:12] <wm4> how did vlc implement this?
[16:16] <Daemon404> probably as usual
[16:16] <Daemon404> adding more deps
[16:16] <henry0312> I think aribb24 gets subtitles as text.
[16:16] <henry0312> http://git.videolan.org/gitweb.cgi/vlc.git/?p=vlc.git;a=blob;f=modules/codec/arib/aribsub.c;h=a23d71400d7700d8398bbb88b09ff04fc6c9cc09;hb=97c02be6f591c0f3ef936780c03d3928044e5d49#l164
[16:17] <henry0312> and see around l.239
[16:19] <wm4> looks like the arib lib does all the hard work
[16:19] <henry0312> yes.
[16:22] <ubitux> arib lib has a libpng dep
[16:26] <henry0312> wm4: so I think, if we can extract correct packets in ffmpeg, we could support it
[16:26] <henry0312> yes, the lib need libpng.
[16:26] <wm4> there's another problem: what does the lib output at all? and can the ffmpeg API handle it?
[16:36] <henry0312> what does the lib output at all? <= I think we have to run arib_decode_buffer (https://github.com/nkoriyama/aribb24/blob/master/src/aribb24/decoder.h#L71-73)
[16:36] <henry0312> can the ffmpeg API handle it? <=  I don't know, yet.
[16:37] <wm4> is the arib API documented somewhere?
[16:38] <henry0312> no, it doesn't have any documents.
[16:38] <henry0312> but the author is Japanese, so I could contact him.
[16:39] <wm4> it's not clear at all what all these fields mean
[16:39] <wm4> I'd guess p_start and p_end point to UTF-8 text?
[16:39] <wm4> but it also must be able to export bitmaps...
[16:41] <ubitux> if they can be png, then they will need to be downscaled to 256 colors iirc
[16:42] <ubitux> which brings the discussion about the current limitation of AVSubtitles graphics
[16:42] <wm4> just add a pixelformat field?
[16:43] <ubitux> what will be the difference between and AVFrame and a bitmap AVSubtitles?
[16:43] <ubitux> AVSubtitles will be a collection of AVFrames?
[16:43] <ubitux> AVFrame *rects[]?
[16:45] <wm4> x, y, nb_colors, type, text, ass, flags
[16:47] <ubitux> mmh yeah, x/y
[16:52] <wm4> and all the other fields
[16:53] <ubitux> for bitmap subs none of the other matters for rects
[16:53] <wm4> with paletted ones, it's especially annoying that you don't know whether sub rects share the palette
[16:53] <wm4> because if they do, some renderers might be much simpler
[17:57] <henry0312> Hum... probably, I have to read the spec to understand aribb24 and think how to render, how to use in ffmpeg and something.
[17:58] <henry0312> wm4, ubitux: I'll talk with you again later, thanks!
[18:01] <henry0312> wm4: btw, ffmpeg doesn't seem to recognize ARIB subtitles for now (btw, though MediaInfo can recognize them)
[18:09] <wm4> henry0312: it's probably the matter of adding a codec id
[18:15] <henry0312> should I add add a codec id for them to `static const StreamType ISO_types[]`?
[18:16] <wm4> probably, I don't know which is the correct place (there are many codec id arrays in mpegts.c...)
[18:17] <henry0312> yeah. I'll try.
[18:19] <kierank> henry0312: what kind of identifier does it have
[18:19] <kierank> there are many ways of signaling packets in mpegts
[19:18] <henry0312> kierank: as far as I see his patch for vlc's demuxer for ts, http://privatepaste.com/cf68d77f7f, I think the stream_type is 0x06
[19:19] <henry0312> (also you can get the same patch from https://onedrive.live.com/?cid=2dab0d8d07fa4ebf&id=2DAB0D8D07FA4EBF%21856)
[19:20] <wm4> the second links is the worst way to post a patch I've ever seen
[19:22] <henry0312> it's OneDriver of the author of aribb24 
[19:22] <henry0312> *OneDrive
[19:24] <wm4> then the worst way of hosting code
[19:25] <ubitux> just after sharing it in a docx document
[19:26] <JEEB> hey, that's at least xml in a zip
[19:26] <JEEB> rather ye olde doc
[19:26] <JEEB> which is binary
[19:27] <henry0312> (I also wonder why he doesn't use gist or something to host codes)
[19:27] <wm4> seems like he has a github repo
[19:27] <wm4> so that's ok
[19:30] <kierank> wm4: there was one guy that sent an html diff
[19:31] <wm4> the open scene graph project doesn't even accept patches, you just to post full files in a zip attachment
[19:31] <wm4> s/just/must
[19:33] <ubitux> osg is really insane yeah
[19:35] <ubitux> "Do not send diffs or copy and paste extracts in emails, these will be simply disgarded, as they are too unreliable for review and merging."
[19:36] <JEEB> lolwut
[19:36] <ubitux> http://www.openscenegraph.org/index.php/support/faq#HowcanIcontributetotheOpenSceneGraph
[19:36] <wm4> I looked at the ML, they really do this
[19:36] <ubitux> "
[19:36] <ubitux> "Patches or email copy and paste submissions are not accepted and will be ignored until full files are submitted. "
[19:37] <henry0312> lol
[19:38] <ubitux> random funny stuff:
[19:38] <ubitux> https://github.com/openscenegraph/osg/blob/master/configure
[19:38] <ubitux> https://github.com/openscenegraph/osg/commit/5e904fd62ce7402c53a377133a64b7d209b0d994
[19:39] <wm4> wat
[19:39] <ubitux> anyway, i'm actually really surprised it hasn't been forked yet
[19:39] <wm4> it has a fork count of 130
[19:39] <wm4> (lol github)
[19:40] <ubitux> personnal trees
[19:40] <wm4> yeah, the "lol" is for the fact that github blurs the line between actual fork and personal trees
[19:41] <nevcairiel> Technically that's called a fork in git lingo
[19:42] <ubitux> "howto make project management worse than on a doom9 forum thread"
[19:44] <ubitux> https://github.com/openscenegraph/osg/blob/master/CMakeModules/FindFFmpeg.cmake
[19:44] <ubitux> this makes me really sad
[19:44] <ubitux> but i guess that's more related to the cmake insanity
[19:45] <wm4> ubitux: ugh that's pretty bad
[19:45] <J_Darnley> Is that typical use of cmake?
[19:45] <ubitux> that's actually pretty typical yes
[19:45] <ubitux> there are about 5k lines of cmake finders in that directory
[19:45] <ubitux> trying all the most stupid possible paths
[19:45] <ubitux> and expect it to find the libs there
[19:46] <ubitux> there is even a FindZLIB
[19:47] <ubitux> https://github.com/openscenegraph/osg/blob/master/CMakeModules/FindOpenThreads.cmake#L83
[19:47] <ubitux> what about this one?
[19:48] <wm4> just wth is that
[19:48] <ubitux> :)
[19:49] <ubitux> there are a lot of other things in this project you don't want to see
[19:50] <ubitux> i initially though i was going to update the ffmpeg stack so it can work with recent versions
[19:50] <ubitux> but do you really think i'll be able to submit changes?
[19:51] <ubitux> i submit a 4-lines patches a while ago (with both inline diff and the file as attachement in the mail) for something random
[19:51] <ubitux> i'm not sure if that's ever going to make it
[19:58] <cone-14> ffmpeg.git 03Diego Biurrun 07master:a6a27fede94e: vfwcap: Replace deprecated av_destruct_packet() by av_free_packet()
[19:58] <cone-14> ffmpeg.git 03Michael Niedermayer 07master:3eba0a91905f: Merge commit 'a6a27fede94efe48aad1dcc9d5e000d2de71c7b2'
[19:58] <cone-14> ffmpeg.git 03Andrey Myznikov 07master:609d5db8035c: Fix packet_buffer memory leak in avformat_free_context
[19:58] <cone-14> ffmpeg.git 03Michael Niedermayer 07master:9c712d0b1608: vformat/utils: call flush_packet_queue() from avformat_free_context()
[19:59] <ubitux> https://github.com/openscenegraph/osg/blob/master/src/osgDB/ImagePager.cpp#L281 how to deal with threading issues
[19:59] <ubitux> a bit more unstable without the #if 0 ;)
[19:59] <wm4> starting threads from a ctor is not sane
[20:00] <wm4> OpenThreads::Thread::YieldCurrentThread();
[20:00] <wm4> oh ho
[20:00] <wm4> who needs condition vars?
[20:01] <ubitux> anyway, the project is something like 500.000 lines of code, it's still a mystery how this can be manageable
[20:12] <henry0312> wm4: https://gist.github.com/henry0312/dce50d7abdac2cad04a7
[20:13] <henry0312> I added codec id.
[20:13] <kierank> i am not 100% sure that is correct
[20:13] <kierank> but will need to check
[20:13] <henry0312> thanks!
[20:14] <wm4> henry0312: you also need to change a bunch of other places when adding a new codecid
[20:14] <wm4> at least an entry to libavcodec/codec_desc.c needs to be added
[20:14] <henry0312> ok.
[20:15] <henry0312> btw, if you (also including other developers) need a sample, let me know.
[20:24] <cone-14> ffmpeg.git 03Diego Biurrun 07master:835f798c7d20: mpegvideo: cosmetics: Lowercase ugly uppercase MPV_ function name prefixes
[20:24] <cone-14> ffmpeg.git 03Michael Niedermayer 07master:c1df467d73ee: Merge commit '835f798c7d20bca89eb4f3593846251ad0d84e4b'
[20:27] <JEEB> lol, I still have the herp.ts that was the test file for spiegel's ARIB captions thingy
[20:29] <henry0312> :D
[20:30] <JEEB> Start time                     : UTC 2011-04-15 01:45:57
[20:30] <JEEB> not old at all by now :V
[20:30] <ubitux> henry0312: please add a MKBETAG() if you're adding a codec id
[20:31] <JEEB> goddamnit visual studio
[20:31] <JEEB> > dot-ts
[20:31] <JEEB> > typescript
[20:31] <JEEB> thank you for hijacking my extension
[20:32] <wm4> henry0312: there's a sample FTP
[20:32] <wm4> uh what was it
[20:32] <wm4> there's this, but last time it didn't work: http://upload.ffmpeg.org/upload/
[20:33] <wm4> also not quite appropriate for ffmpeg, because it wants a VLC version...
[20:33] <henry0312> :e avcode.h
[20:33] <henry0312> ops, wrong window
[20:33] <cone-14> ffmpeg.git 03Diego Biurrun 07master:efd26bedec9a: build: Add explanatory comments to (optimization) blocks in the Makefiles
[20:33] <cone-14> ffmpeg.git 03Michael Niedermayer 07master:3bb22973518c: Merge commit 'efd26bedec9a345a5960dbfcbaec888418f2d4e6'
[20:34] <JEEB> ahaha
[20:34] <JEEB> chiba tv umineko OP
[20:34] <JEEB> this awesome rainbowing
[20:34] <JEEB> no idea why I kept this shit
[20:34] <henry0312> ubitux: can I set a tag I like?
[20:35] Action: JEEB is having fun looking through *.ts files on his drives
[20:35] <wm4> henry0312: yeah, these tags are pretty random (IMO a stupid practice)
[20:35] <henry0312> ok.
[20:35] <JEEB> oh, this was 2009
[20:35] <wm4> just make sure it doesn't collide with anything
[20:35] <JEEB> lörs lärä
[20:36] <ubitux> henry0312: yes, but MKBETAG('A','R','I','B') is more likely to be accepted than MKBETAG('H','N','R','Y')
[20:36] <henry0312> ok! :D
[20:37] <JEEB> man, I'm happy we don't have this kind of shit on Japanese DTV any more
[20:45] <ubitux> saste: ping
[20:45] <saste> ubitux, pong
[20:45] <ubitux> saste: what was the plan for option clashes?
[20:46] <alexfu> is there documentation on the code somewhere? kind of like a javadoc 
[20:46] <saste> ubitux, nothing was done I think
[20:46] <saste> my idea was to use some sort of namespace
[20:46] <ubitux> alexfu: http://ffmpeg.org/documentation.html look for doxygen
[20:47] <ubitux> saste: ok, because we currently have a clash between a decoder and a protocol
[20:47] <alexfu> ubitux: thanks
[20:47] <saste> ubitux, what in particular?
[20:47] <ubitux> saste: -password, tta/icecast
[20:47] <saste> anyway such conflicts are nasty but can be avoided using a prefix in the option
[20:49] <alexfu> if resizing a video results in something like this: http://i.imgur.com/fjk25eo.png -- what does that usually indicate?
[20:49] <ubitux> wrong linesize step?
[20:49] <wm4> alexfu: wrong stride
[20:50] <wm4> also called linesize
[20:51] <wm4> what you need to be careful about is that there can be padding between the end of the last pixel of a line, and the start of the first pixel of the next line
[20:52] <alexfu> wm4: maybe i'm missing something, but how can scaling effect that?
[20:54] <ubitux> saste: changing the option name can be done; icecast is recent but is present in the fork so changing the option name means incompatibility. OTOH tta is more ancient and ffmpeg exclusive, but chaning the option name is more problematic then from a compat PoV
[20:54] <ubitux> that's why i was wondering if another way wasn't possible
[20:55] <wm4> alexfu: the scaler needs it to access the pixels
[21:09] <ubitux> michaelni: it seems the issue can simply be fixed by doing the same as 8a1714ad85dd5defdf1fb2baba9ababebfa47d01 for encoding
[21:10] <cone-14> ffmpeg.git 03Gabriel Dume 07master:f929ab0569ff: cosmetics: Write NULL pointer equality checks more compactly
[21:10] <cone-14> ffmpeg.git 03Michael Niedermayer 07master:fb33bff990a8: Merge commit 'f929ab0569ff31ed5a59b0b0adb7ce09df3fca39'
[21:25] <alexfu> wm4: so when that happens, does that mean the linsize is too small?
[21:27] <wm4> it means different parts of the code didn't use the same linesize, which probably means some code didn't pass it along correctly
[21:36] <JEEB> ah, nice. found a sample that has colors, positioning... let's see if we get pictures too
[21:45] <JEEB> ok, pictures too :D
[21:54] <cone-14> ffmpeg.git 03Gabriel Dume 07master:4b1f5e5090ab: cosmetics: Write NULL pointer inequality checks more compactly
[21:54] <cone-14> ffmpeg.git 03Michael Niedermayer 07master:60dbed606767: Merge commit '4b1f5e5090abed6c618c8ba380cd7d28d140f867'
[21:55] <wm4> JEEB: so you found The EVIL?
[21:58] <JEEB> https://dl.dropboxusercontent.com/u/175558/screenshots/tvtest_caption_gaiji.png too bad I don't have this around any more. Liked the TV symbol
[21:58] <alexfu> anyone mind taking a lookg @ this? https://gist.github.com/alexfu/7702fbf7d9617266d99d .. when resizing the video, i get incorrect linesizes but I cant figure out why from the code.
[22:03] <JEEB> oh right, goddamnit
[22:03] <JEEB> ruby text
[22:05] <JEEB> funky
[22:05] <JEEB> another sample I opened has those
[22:05] <JEEB> time to cut something
[22:08] <JEEB> wish I could see the byte-wise position of frames :|
[22:21] <wm4> JEEB: AVPacket has a pos field or so, is that what you want?
[22:22] <JEEB> could be useful, although I'm right now already almost finished with cutting the sample
[22:22] <wm4> alexfu: don't use avpicture_, and especially not with AVFrame... that's 100% broken
[22:22] <wm4> where do people get the idea to alias AVPicture with AVFrame
[22:22] <wm4> must be from old tutorials when it was still valid...
[22:22] <wm4> jesus fuck
[22:23] <JEEB> lol
[22:25] <wm4> alexfu: I think your problem is memcpy(windowBuffer.bits, buffer,  width * height * 4);
[22:25] <wm4> this assumes linesize == width * 4
[22:25] <wm4> but it doesn't have to be
[22:25] <alexfu> wm4: ah, ok
[22:25] <JEEB> dd if=201307130225000103-KéÜ
[22:25] <JEEB> dd for the win
[22:28] <JEEB> http://fushizen.eu/samples/arib_captions_colors_positioning_ruby_subpics.ts
[22:28] <JEEB> enjoy
[22:29] <wm4> I'll come back to it once henry0312 gets further
[22:29] <JEEB> I wonder how well VLC handles it
[22:29] <JEEB> j-b, do the current nightlies have support for ARIB captions already?
[22:38] <j-b> JEEB: no
[22:38] <JEEB> aww
[22:40] <wm4> everyone wants ARIB captions!
[22:40] <j-b> really?
[22:41] <Compnn> i remember a lot of requests for ARIB support
[22:42] <j-b> like 2?
[22:43] <Compnn> http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2009-October/062725.html
[22:43] <Compnn> someone spent the time to include it in mplayer :P
[22:44] <JEEB> yeah, I remember there being some derpy patch around
[22:44] <JEEB> also there's spiegel's parser
[22:44] <wm4> Compnn: I wonder why that patch was not accepted
[22:45] <Compnn> it wasnt ? ...  probably needs to be resent
[22:45] <j-b> because to support ARIB, there are many tweaks to do
[22:45] <kierank> http://www.arib.or.jp/english/html/overview/img/arib_std-b24v4.0_e.pdf
[22:45] <kierank> I thought this was the spec
[22:45] <kierank> it's the TABLE OF CONTENTS for the spec...
[22:46] <j-b> non-standard iconv conversion, unstandard TS muxing, support of rubys-and-quarter-pixels
[22:46] <wm4> kierank: oh god, and it's 40 pages
[22:46] <JEEB> B-24 consists of like 3 books now
[22:46] <JEEB> even the Japanese lulz at it
[22:47] <JEEB> "I used to have this printed as a single booklet"
[22:47] <j-b> JEEB: so, it's in the VLC NB
[22:47] <j-b> JEEB: but, you need to compile your own, to get the decoder. :)
[22:47] <j-b> JEEB: the code is merged, mostly
[22:47] <JEEB> ok
[22:48] <j-b> but the Win32 NB does not have the arib24 .so
[22:50] <cone-14> ffmpeg.git 03Michael Niedermayer 07master:81a663f49edd: Drop remaining unneeded != NULL
[22:52] <j-b> JEEB: what OS are you on?
[22:53] <JEEB> j-b, win
[23:36] <J_Darnley> jamrial: thanks your your comment on my XOP patch, I had completely forgotten that they are "legacy SSE instructions"
[23:36] <J_Darnley> I didn't mean that you should register for an account just to make that comment though.
[23:48] <jamrial> J_Darnley: they are not "legacy sse". They use the avx VEX coding scheme
[23:49] <jamrial> it's just that vpmacsdd can't read from unaligned memory just like pmulld can't
[23:50] <jamrial> so you need to use movdqu, be it sse4 or xop
[23:52] <jamrial> J_Darnley: same thing with your avx2 patch
[23:56] <cone-14> ffmpeg.git 03Clément BSsch 07master:11aab8d6cb3b: ffmpeg: look for encoding options in both avcodec and avformat
[00:00] --- Sat Aug 16 2014