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

[burek]

[00:09] <michaelni> kierank, tested, works, pushed
[00:10] <cone-192> ffmpeg.git 03Kieran Kunhya 07master:b546023b9319: swscale: fix yuv2yuvX_8 assembly on x86
[00:14] <kierank> thx
[01:03] <cone-192> ffmpeg.git 03Luca Barbato 07master:e3e317e0c015: lavc: Compact the side-data passthrough
[01:03] <cone-192> ffmpeg.git 03Michael Niedermayer 07master:0960cc4cc60f: Merge commit 'e3e317e0c015b164b6c2eb8913e393216d78de23'
[01:25] <cone-192> ffmpeg.git 03Tristan Matthews 07master:a1a259881fa7: v4l2: Use av_strerror
[01:25] <cone-192> ffmpeg.git 03Michael Niedermayer 07master:d99653c9e444: Merge commit 'a1a259881fa7b23e2ffc0c2a43d4923fe42d0478'
[01:40] <jfmcarreira> heyyy guys
[01:40] <jfmcarreira> how can i get the raw video information after using av_read_packet and av_decode?
[01:43] <cone-192> ffmpeg.git 03Luca Barbato 07master:09f25533a564: v4l2: Preserve errno values
[01:43] <cone-192> ffmpeg.git 03Michael Niedermayer 07master:715ccc2bc479: Merge commit '09f25533a564eab743f258d168697a11122914c4'
[02:51] <cone-192> ffmpeg.git 03Martin Storsjö 07master:b44a242c3dfa: libfdk-aacdec: Support building with the latest version of fdk-aac
[03:00] <cone-192> ffmpeg.git 03Michael Niedermayer 07master:9889b29ff4b0: avcodec/utils: make sidedata remapping table static const
[03:01] <cone-192> ffmpeg.git 03Michael Niedermayer 07master:f6a8c77afb86: avcodec/utils: Fix warning: comparison between enum foo and enum bar [-Wenum-compare]
[04:18] <cone-192> ffmpeg.git 03Arwa Arif 07master:19d0949d31b0: lavfi: add xbr filter xBR
[04:18] <cone-192> ffmpeg.git 03Michael Niedermayer 07master:064a23766923: avfilter/vf_xbr: Uppercase first letter of context type for consistency
[06:21] <ubitux> so xbr was pushed without the reference to the ticket, and without test?
[06:22] <ubitux> it could get various macro cleanup too
[06:22] <ubitux> but oh well..
[06:23] <ubitux> the @file is also not up-to-date
[06:23] <ubitux> since x3 and x4 are now present.
[06:25] <cone-192> ffmpeg.git 03Clément BSsch 07master:ae65a84517cf: Changelog: explicit that xBR scaler is implemented as a filter
[06:30] <cone-192> ffmpeg.git 03Clément BSsch 07master:fc0a91e3cdf5: avfilter/xbr: consistent use of @see
[06:30] <cone-192> ffmpeg.git 03Clément BSsch 07master:548a5f7ef619: avfilter/xbr: fix TODO entry
[06:33] <cone-192> ffmpeg.git 03Clément BSsch 07master:937ebb843579: avfilter/xbr: fix filter description field
[06:34] <cone-192> ffmpeg.git 03Clément BSsch 07master:30466cac9d59: avfilter/xbr: drop yet another x2 reference
[06:38] <cone-192> ffmpeg.git 03Clément BSsch 07master:ff9b21776b8d: doc/filters: explicit and complete xBR documentation
[10:57] <relaxed> there's something about Mary ^^
[11:11] <cehoyos> Indeed
[11:14] <cehoyos> It seems deleting tickets puzzles fflogger
[11:15] <ubitux> it breaks the rss stream somehow
[11:15] <ubitux> i suppose
[11:18] <cehoyos> ubitux: Is ticket 3491 still reproducible?
[11:20] <ubitux> cehoyos: try it and tell me :)
[11:20] <ubitux> it might be fixed
[11:27] <cehoyos> I saw he sent this patch: https://ffmpeg.org/pipermail/ffmpeg-devel/2014-April/157159.html
[11:27] <cehoyos> Didn't you commit the change as part of a larger patch?
[11:29] <nevcairiel> that code is no longer in master
[11:29] <cehoyos> That's what I mean, yes.
[11:30] <nevcairiel> also, the codec ids ASS and SSA don't mean what the patch implies they mean
[11:30] <nevcairiel> they are both for ASS subtitles, just different internal representation
[11:30] <ubitux> yeah that code is not present anymore
[11:30] <ubitux> and if you look below the ifdefery
[11:30] <ubitux> it fallbacks on what he wants
[11:30] <nevcairiel> _SSA is not used at all anymore now, in any case
[11:31] <nevcairiel> (the codec id)
[11:31] <ubitux> if have a local branch dropping it
[11:31] <wm4> what about the avi thing?
[11:31] <ubitux> in which i removed all the timestamp scaling in lavc go away
[11:31] <ubitux> wm4: it works actually
[11:32] <ubitux> (iirc)
[11:32] <ubitux> because it seems it actually creates a buffer like if it was an independant file or something like this
[11:32] <ubitux> i need to check again
[11:33] <ubitux> well anyway... i'll figure that out later
[11:33] <cehoyos> nevcairiel: Did you see my comment about -scan_all_pmts?
[11:33] <ubitux> we should probably make a helper to untangle this instead of a decoder
[11:36] <cehoyos> Bye, gtg
[11:38] <cone-155> ffmpeg.git 03Timothy Gu 07master:e1ee0521a698: tests: Fix test name for pixfmts tests
[11:38] <cone-155> ffmpeg.git 03Michael Niedermayer 07master:a7d451c1dd75: Merge remote-tracking branch 'github/master'
[11:47] <cone-155> ffmpeg.git 03Martin Storsjö 07master:28396d17ff1c: libfdk-aacdec: Support building with the latest version of fdk-aac
[11:49] <cone-155> ffmpeg.git 03Michael Niedermayer 07master:a602f88e2dea: Merge commit '28396d17ff1c1493b78d6eece484ffc27ed86d0d'
[11:58] <ubitux> saste: i'd like to rework the macro mess in xbr if you don't mind
[11:58] <ubitux> but i want the fate patch to get applied first
[11:58] <saste> ubitux, sure
[11:58] <saste> ubitux, makes sense
[11:58] <cone-155> ffmpeg.git 03Stefano Sabatini 07master:73f74f6b166a: lavfi/xbr: apply misc cosmetical fixes
[11:59] <ubitux> we need to factor out the LUT code btw
[12:05] <wm4> michaelni: why exactly was cea3a63ba3d89d8403eef008f7a7c54d645cff70 needed?
[12:08] <wm4> michaelni: if get_pool() fails, doesn't that mean simply no buffer was available?
[12:11] <j-b> michaelni: http://people.videolan.org/~jb/tmp/update
[12:13] <michaelni> j-b, thanks, ubitux theres the hook if you want to update it, else ill try and post a patch
[12:22] <michaelni> wm4, if get_pool() is run by 2 threads at the same time one of them will "always" fail no matter how many buffers are available
[12:25] <wm4> but get_pool has a retry-loop
[12:26] <wm4> hmm
[12:26] <wm4> holy shit... so get_pool removes the entire buffer list?
[12:26] <wm4> and readds it later?
[12:26] <nevcairiel> it takes it to modify it, since its lock-free, afaik
[12:27] <wm4> that's much worse than using a mutex
[12:30] <nevcairiel> yeah this whole lock-free approach is super complex, i never saw the real benefit
[12:31] <wm4> don't malloc/free acquire global libc locks anyway? you can't change the refcount without allocation
[14:26] <ubitux> michaelni: i won't patch it, too much pain to test
[14:58] <michaelni> ubitux, posted a patch, please review, ill wait a bit for reviews before i mail it to root at vlc
[14:58] <ubitux> michaelni: i was looking at it, but why didn't you drop the other .mak entries?
[14:58] <ubitux> > common.mak|library.mak|subdir.mak
[15:00] <michaelni> they cover more cases, like commonumak or subdirkmak i think, i think if they are removed that could/should be seperate
[15:02] <ubitux> well they're obviously specific *.mak patterns, and you add a generic case
[15:02] <ubitux> but well, whatever
[15:03] <michaelni> also i wanted to keep the change minimal as i didnt setup a full test environment, just tested the command outside a hook
[15:04] <michaelni> but, if you want to write a better patch, iam not against that at all
[15:06] <ubitux> i don't care much
[15:06] <ubitux> as long as i can push my fate patch... :P
[15:06] <ubitux> oh.. ifo parsing incoming in ffmpeg... nice.
[15:14] <wm4> yay another shitty hack
[15:15] <ubitux> ?
[15:15] <ubitux> what do you propose?
[15:15] <ubitux> Nicolas suggests a -ifo_file option, which is what i agree with
[15:18] <wm4> dvdread support?
[15:23] <ubitux> wm4: yeah... right
[16:23] <ubitux> stupid question of the day: can't we hide data in the mov/mp4 stsz table?
[16:23] <ubitux> (with a boxsize > sample_count*4)
[16:24] <Compn> michaelni : should we put git hooks in ffmpeg-web repo ?
[16:25] <Compn> i dont think it has to be connected , just so people can send patches
[17:31] <ubitux> is anyone working on edit lists?
[17:32] <ubitux> (in mov/mp4)
[17:34] <Compn> i am guessing not
[17:35] <Compn> ask on ml for better guesses
[18:03] <cone-378> ffmpeg.git 03Michael Niedermayer 07master:e981de81fea7: avcodec/lagarith: fix chroma plane width & height
[18:42] <jfmcarreira> heyy guys
[18:42] <jfmcarreira> how is data organized inside an AVFrame?
[18:43] <rcombs> see the Doxygen page for that struct?
[18:44] <jfmcarreira> rcombs: i already looked at it
[18:45] <rcombs> what's unclear?
[18:45] <jfmcarreira> rcombs: i am wondering how pixels are inside the data parameter
[18:45] <rcombs> that depends on the pixel format
[18:45] <jfmcarreira> rcombs: each pointer is one component right?
[18:45] <rcombs> see the documentation on individual pixel formats
[18:45] <J_Darnley> No
[18:45] <J_Darnley> RGB
[18:45] <J_Darnley> packed YUV
[18:46] <wm4> jfmcarreira: look at pixfmts.h
[18:46] <wm4> err, pixfmt.h
[18:46] <rcombs> some are planar, some are packed; some have 1 byte per sample, some have 2 (or maybe more, I'm not sure)
[18:46] <wm4> jfmcarreira: AVFrame.format is one of AV_PIX_FMT_... (for video)
[18:46] <jfmcarreira> wm4: i know the pel formats. but i am trying to read a file using libavformat and i am not being able to copy the pixels right from the AVFrame
[18:47] <jfmcarreira> i used av_image_copy
[18:47] <wm4> copy where?
[18:47] <jfmcarreira> and for progressive formats like yuv420p it worked
[18:47] <jfmcarreira> wm4: i am creating a video playuver. and i need to copy the pixels to my class
[18:48] <wm4> read the source code of av_image_copy
[18:48] <wm4> I think it's relatively readable
[18:48] <jfmcarreira> ok
[18:48] <wm4> basically you need to know how planes and linesizes work
[18:49] <jfmcarreira> because i need then or in separate pointer (one for each component) or in the raw format it is on the bitstream
[18:50] <jfmcarreira> wm4: but linesizes are only used to copy specific lines
[18:51] <wm4> well, that's how data is organized
[18:51] <jfmcarreira> i want it whole. i was using mem cpy from the beginning of avframe->data[ch] using the number of pixels ( normally width * height) 
[18:52] <jfmcarreira> but that might change depending on the pixel fmt
[18:52] <wm4> that's wrong
[18:52] <wm4> and there is not necessarily one plane per component
[18:52] <rcombs> stride may not equal width
[18:52] <wm4> that too
[18:52] <jfmcarreira> rcombs: i see :)
[18:55] <jfmcarreira> it is working for yuv420p a planar format
[18:55] <jfmcarreira> but not for yuyv422 for example
[18:55] <rcombs> it'll stop working if your width != stride
[18:56] <J_Darnley> yuyv is packed.
[18:57] <jfmcarreira> so why different pointers in AVFrame? that what i am wondering
[18:58] <wm4> because that's more efficient/simpler for planar formats
[18:58] <jfmcarreira> i know yuyv422 is packed but it is also packed inside an AVFrame?
[18:58] <J_Darnley> Of course.  Otherwise it would yuv442p
[18:59] <jfmcarreira> but the only different there is in the bitstream not representation
[19:00] <jfmcarreira> so ffmpeg does not have a way of representing all the YUV formats in one common way?
[19:00] <J_Darnley> AVFrame
[19:00] <iive> jfmcarreira: there is no common way.
[19:00] <rcombs> no, because they're _different formats_
[19:00] <J_Darnley> if you need a specific format use swscale
[19:01] <jfmcarreira> nope. i want the original pixels. my software supports different pel formats
[19:01] <iive> what is pel?
[19:01] <rcombs> a typo of pixel
[19:01] <iive> palette?
[19:01] <jfmcarreira> so is there any way of getting the pixels from the AVFrame in raw format like they would be in a bitstream?
[19:01] <wm4> jfmcarreira: libavcodec always outputs the most "original" format it supports
[19:02] <wm4> "bitstream"
[19:02] <wm4> wtf does this even mean
[19:02] <jfmcarreira> wm4: what you mean by most "original"
[19:02] <wm4> you can get the original undecoded data as AVPacket
[19:02] <jfmcarreira> wm4: i meant in the file
[19:03] <iive> are you reading raw images with libavformat?
[19:05] <iive> oh, pel as in halfpel, qpel
[19:09] <jfmcarreira> live i am reading raw and other filetypes like avi or bmp or png
[19:10] <jfmcarreira> iive: and after demuxing using the ffmpeg and decoding the frames i need to copy the pixel information to a struct i know in my software
[20:25] <lukaszmluki> git rejects commits that not ends with new line, even for files in tests/ref/fate/, is it bug or is it intended. I see there files that not ends with \n
[20:26] <lukaszmluki> I meant commits with files that not ends with new line
[20:35] <cone-378> ffmpeg.git 03Michael Niedermayer 07master:7656c4c6e66f: avcodec/utvideodec: fix assumtation that slice_height >= 1
[20:47] <michaelni> lukaszmluki, see http://people.videolan.org/~jb/tmp/update if you want to fix it
[20:53] <lukaszmluki> OK, I will try
[21:01] <ubitux> is there a problem with forcing this \n?
[21:01] <ubitux> i think even git warns about it by default
[21:17] <lukaszmluki> it is not a problem, but you need a dummy printf("\n") in c file to produce that new line
[21:17] <cone-378> ffmpeg.git 03Thilo Borgmann 07master:48c29883fcb2: lavd/avfoundation: Use internal av_strtok instead of std lib strtok
[21:31] <lukaszmluki> egrep -v '/$|^tests\/ref\/|\.diff$|\.patch$' in  check_ending_newline should fix it
[21:31] <lukaszmluki> i dont mind adding this new line, but probably updates for existing files will be rejected too
[21:54] <cone-378> ffmpeg.git 03Jon Morley 07master:8c28a39c2c38: options_table.h: min value for colorspace is 0 (AVCOL_SPC_RGB)
[22:18] <kierank> is there any opposite to punpcklbw m1, m0, [zero]?
[22:22] <nevcairiel> packuswb?
[22:31] <kierank> yes it seems so
[22:55] <jamrial> kierank: your patch doesn't apply cleanly
[22:55] <kierank> of course it doesn't
[22:56] <kierank> cf "This file is part of Libav."
[22:56] <kierank> dunno why it's diverged so much though
[22:57] <kierank> oh it's libavfilter
[22:57] <kierank> of course
[22:58] <kierank> that's quite different
[22:58] <ubitux> what was the thing about tinterlace vs interlace already?
[22:58] <ubitux> licenses?
[22:58] <ubitux> features?
[22:59] <jamrial> both seem to be gpl
[23:00] <kierank> random junk in tinterlace it seems
[23:08] <kierank> jamrial: ah didn't know about pavgb
[23:10] <ubitux> kierank: isn't it easy to add slice threading as well?
[23:12] <kierank> probably yes but i've never done that before
[23:14] <ubitux> does it help to have [pw_1] in a reg?
[23:14] <kierank> pavgb is better
[23:14] <kierank> i wasn't aware of that
[23:14] <kierank> well i assume it's better
[23:14] <ubitux> ah right
[23:15] <kierank> oh wait pavgb does a >> 1
[23:15] <ubitux> iirc it rounds
[23:16] <ubitux> ah mmh forgeet
[23:16] <ubitux> forget it*
[23:25] <kurosu> you might use ssse3's pmadduswb with proper coeffs, doing the unpack and sum in one step
[23:25] <kurosu> well, not exactly
[23:26] <kurosu> bah, there are 3 elements in the sum, probably not going to help
[23:49] <cone-378> ffmpeg.git 03Michael Niedermayer 07master:5dcb99033df1: avcodec/wmaprodec: Fix integer overflow in sfb_offsets initialization
[00:00] --- Tue Nov 11 2014