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

[burek]

[00:00] <cone-574> ffmpeg.git 03Paul B Mahol 07master:6347824d5310: lavfi/showwaves: fix floating exception with >8 channels
[00:00] <cone-574> ffmpeg.git 03Paul B Mahol 07master:e9678631f16b: lavfi/trim: fix sample copy for >8 channels
[00:00] <cone-574> ffmpeg.git 03Paul B Mahol 07master:729709b8904c: lavfi/asetnsamples: unbreak for >8 channels
[00:06] <cone-574> ffmpeg.git 03Paul B Mahol 07master:099dfcaa0eef: lavfi/ashowinfo: unbreak for >8 channels
[00:09] <durandal_1707> hmm why is stereo3d failing on big endian?
[00:25] <cone-574> ffmpeg.git 03Paul B Mahol 07master:f486d7e924ff: lavfi/silencedetect: unbreak for unknown channel layouts
[00:29] <durandal_1707> michaelni: are we want  to be ABI compatible with Libav lavu ?
[00:34] <michaelni> when possible, yes
[00:35] <durandal_1707> its not possible at all
[00:40] <michaelni> where is the problem?
[00:42] <durandal_1707> sizeof(AVFrame)
[00:43] <durandal_1707> so no, nonsense combinations of different versions on ffmpeg/libav lavf/lavc/lavu can not work
[00:44] <michaelni> sizeof(AVFrame) cannot be used outside the lib defining that struct which is lavu, that has othing to do with ABI compat to the fork
[00:45] <michaelni> we add fields to AVFrame ourselfs
[00:45] <michaelni> and we need t be compatible to our previous ABI over such changes
[00:46] <durandal_1707> i was not talking about our own ABI....
[00:47] <durandal_1707> Do you really think that our lavu and their lavc combination should be supported?
[00:48] <michaelni> i dont care much about that, but all our libs together should work with applications build against the forks headers
[01:03] <wm4> michaelni: I guess the lack of any reply means libswscale won't get changes wrt. chroma placement ever?
[01:03] <michaelni> wm4, ill look into it
[01:04] <wm4> michaelni: thanks
[01:04] Action: durandal_1707 open bug reports all the time
[01:07] <kierank> wm4: where is this chroma placement discussion
[01:07] Action: kierank wrote his own chroma placement scaler
[01:08] <wm4> kierank: nowhere, a user of my negligible project asked about it
[01:08] <wm4> apparently videophiles think chroma placement is the most important thing ever
[01:08] <kierank> it is quite important for interlaced video
[01:09] <kierank> admittedly i ignored it for ages
[01:10] <wm4> interlaced, I see
[01:10] <kierank> http://renomath.org/video/linux/interlace/cinelerra.html
[01:47] <cone-574> ffmpeg.git 03Paul B Mahol 07master:fc6ca3731638: lavfi/aecho: fix invalid free
[03:49] <cone-574> ffmpeg.git 03Michael Niedermayer 07master:d5f5e5166216: swscale: move format handling to its own function
[03:49] <cone-574> ffmpeg.git 03Michael Niedermayer 07master:0fc11e7bad71: swscale: make handle_formats() safe to be called multiple times
[03:49] <cone-574> ffmpeg.git 03Michael Niedermayer 07master:c75dde607440: swscale: call handle_format() from the functions that need it
[05:36] <wm4> michaelni: wow, that was fast!
[05:50] <wm4> I wonder why the chroma position is not just specified like the constants in avcodec.h?
[05:50] <wm4> it looks like this still requires the user to do some significant (pixel format specific) work to get it right
[06:01] <michaelni> a different system could be used to specify them, but it should be kept flexible
[06:01] <michaelni> the system in avcodec.h looks like it isnt able to handle some cases
[06:03] Action: michaelni falls asleep
[11:51] <cone-116> ffmpeg.git 03Nicolas Bertrand 07master:886e1b36f504: jpeg2000: Remove unused passes array in Jpeg200Cblk structure
[11:51] <cone-116> ffmpeg.git 03Michael Niedermayer 07master:b24e8f566d0c: Merge commit '886e1b36f5044d3ceccbb01f64619acaf288fb7c'
[12:09] <cone-116> ffmpeg.git 03Martin Storsjö 07master:68e57cde68f3: ac3dec: Increment channel pointers only once per channel
[12:10] <cone-116> ffmpeg.git 03Michael Niedermayer 07master:198e10b55cc9: Merge commit '68e57cde68f3da4c557ca15491fda74d1ea6321e'
[12:17] <cone-116> ffmpeg.git 03Martin Storsjö 07master:031be5b41b54: ac3dec: Consistently use AC3_BLOCK_SIZE and sizeof
[12:17] <cone-116> ffmpeg.git 03Michael Niedermayer 07master:ac20ba35e37d: Merge commit '031be5b41b54c3b666f31d83fe3ad41c194af8c5'
[12:40] <cone-116> ffmpeg.git 03Luca Barbato 07master:8435bca087c0: indeo4: Do not access missing reference MV
[12:40] <cone-116> ffmpeg.git 03Michael Niedermayer 07master:54623619373d: Merge commit '8435bca087c0e79385763c51de009fd89390b6a5'
[12:48] <cone-116> ffmpeg.git 03Luca Barbato 07master:6255ccf7d51c: indeo4: Check the quantization matrix index
[12:48] <cone-116> ffmpeg.git 03Michael Niedermayer 07master:8c0bb195220d: Merge commit '6255ccf7d51c82ab79bf0cd47a921f572dda4489'
[13:22] <cone-116> ffmpeg.git 03Luca Barbato 07master:cd78e934c246: indeo4: Validate scantable dimension
[13:22] <cone-116> ffmpeg.git 03Michael Niedermayer 07master:ccb422a69728: Merge commit 'cd78e934c246d1b2510f8fba0abfe40bb75795f6'
[14:19] <cone-116> ffmpeg.git 03Luca Barbato 07master:dc79685195a4: indeo: Bound-check before applying transform
[14:19] <cone-116> ffmpeg.git 03Michael Niedermayer 07master:a8e5fac1fb3f: Merge remote-tracking branch 'qatar/master'
[15:59] <wm4> a user has been pasting this to me, said it happens on freebsd but not on linux using the same ffmpeg version and the same input file, any idea what this could mean? http://sprunge.us/HRLW
[16:02] <cone-116> ffmpeg.git 03Michael Niedermayer 07master:76d0a6656bbf: indeo: print errors if transform and block size mismatch
[16:02] <cone-116> ffmpeg.git 03Michael Niedermayer 07master:febbddbdd5b2: indeo4: print an error message if ref_mb is needed but unavailable
[16:12] <cone-116> ffmpeg.git 03Stefano Sabatini 07master:ab5f5816253a: doc/bitstream_filters: amend name of some bitstream filters
[16:26] <Compn> wm4 : ask him to paste larger thing
[16:26] <Compn> or submit input file
[16:27] <Compn> wm4 : could be mixed mode h264 and theres problem , maybe thread problem ? what ver ffmpeg/libavcodec ?
[16:43] <michaelni> wm4 are you working on passing yuv type from decoder to filter ? (if not i might take a look at it)
[16:43] <wm4> michaelni: no... I suspect format negotiation in lavfi will be a major mess, and ubitux expressed some concerns about that too
[16:44] <wm4> michaelni: but if you do it, IMO the same should be done for chroma location
[16:44] <michaelni> yes i know
[16:44] <michaelni> iam still a bit unsure how to specify the chroma location best
[16:44] <michaelni> the enum looks insufficient though
[16:45] <wm4> AVChromaLocation?
[16:45] <michaelni> also i dont plan to do anything with format negotiaion just passing the info thrugh for now
[16:46] <michaelni> yes AVChromaLocation looks insufficient
[16:46] <wm4> AFAIR ubitux was arguing that the jpeg pixel formats make sure that filters which do not support different range are properly negotiated
[16:47] <wm4> in which cases is the enum not enough?
[16:47] <michaelni> consider croping and updating the chroma position or yuv 410
[16:48] <michaelni> or a single field of a interlaced frame
[16:48] <wm4> so what would you argue for? shift values for x/y like in your swscale patch?
[16:49] <michaelni> iam not sure but the shft values should be generic enough to handle all these cases
[16:50] <michaelni> or rather allow them to be handled if someone implements the logic in the crop, ... filters
[18:29] <cone-116> ffmpeg.git 03Paul B Mahol 07master:80c644593223: lavfi: port perspective filter from libmpcodecs
[18:29] <cone-116> ffmpeg.git 03Paul B Mahol 07master:ed448efe619d: lavfi/mp: remove mp=perspective
[20:05] <cone-116> ffmpeg.git 03Paul B Mahol 07master:d5598c0963d8: lavfi/drawutils: set subsampling for rgb too
[21:52] <durandal_1707> michaelni: why all stereo3d tests are failing?
[21:54] <durandal_1707> its probably because of 420->444
[22:12] <cone-116> ffmpeg.git 03Michael Niedermayer 07master:17b98c1abded: fate: fix stereo3d
[22:13] <durandal_1707> well i was going to add subsampled support to stereo3d ....
[22:40] <cone-116> ffmpeg.git 03James Almer 07master:04b9836274f3: oggparsevorbis: Support official chapter extension
[22:41] <wm4> michaelni: would it be ok to cancel the genpts loop in libavformat/utils.c after a certain number of retries?
[22:56] <michaelni> the problem is the "certain number"
[22:57] <michaelni> we could just pick something arbitrary or let the user choose
[22:58] <michaelni> or pick something so large it is unlikely to be too small
[23:04] <wm4> michaelni: well, as I understand, genpts will make sense only as long as there are possible references between the frames
[23:05] <michaelni> yes, you could have a P frame and a billion B frames following it that refer to it in theory, even i mpeg1
[23:08] <wm4> but wouldn't it stop as soon as a recovery point is reached? (or whatever that is called)
[23:19] <michaelni> keyframes or recovery points would stop it eventually yes
[23:19] <michaelni> if there are any keyframes or recovery points later that is
[23:35] <BBB> oh someone is doing yuv type?
[23:35] <BBB> _O_
[23:35] <BBB> finally
[23:57] <cone-116> ffmpeg.git 03Paul B Mahol 07master:85a22099a7ba: lavfi/stereo3d: subsampled yuv support for non-anaglyph outputs
[00:00] --- Mon Jul 15 2013