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

[burek]

[00:56] <llogan> ubitux: for Photoshop CS6 the curves file is .acv, not .asv as shown in the docs, but i'm unsure if asv is valid too
[01:19] <cone-455> ffmpeg.git 03Michael Niedermayer 07master:999ee28124f3: avcodec/utils: dont depend on the channel layout in unrefcount_frame()
[01:19] <cone-455> ffmpeg.git 03Michael Niedermayer 07master:4c1b4ae1baf7: avcodec/libutvideodec: use av_frame_move_ref()
[01:19] <cone-455> ffmpeg.git 03Michael Niedermayer 07master:7102083a26f7: avcodec/libutvideodec: free coded_frame with av_frame_free() instead if av_free*
[01:19] <cone-455> ffmpeg.git 03Michael Niedermayer 07master:985c5f226af3: avcodec/utils: check that extended data has been set correctly instead of forcing it in avcodec_decode_video2()
[01:51] <cone-455> ffmpeg.git 03Diego Biurrun 07master:c869fcdeac3b: configure: Move toolchain dependency declarations to a more appropriate place
[01:52] <cone-455> ffmpeg.git 03Michael Niedermayer 07master:1311ae8eeeb9: Merge commit 'c869fcdeac3b7cd71a852b928902daadeca55685'
[02:03] <cone-455> ffmpeg.git 03Diego Biurrun 07master:275651646651: configure: Split host and target libc detection
[02:03] <cone-455> ffmpeg.git 03Michael Niedermayer 07master:2836ef688b4e: Merge remote-tracking branch 'qatar/master'
[02:28] <clever> anybody on that knows the details of how a codec decoder works?
[02:28] <clever> i'm trying to figure out when av_frame_get_buffer is called and why the buffer isnt the right size
[03:24] <cone-455> ffmpeg.git 03Michael Niedermayer 07master:2bdda9a15c04: avcodec/ffv1enc: fix use of uninitalized variable in choose_rct_params()
[03:24] <cone-455> ffmpeg.git 03Michael Niedermayer 07master:0e575c24d62a: ffv1.4: use 2 coefficients for calculating the Y plane in the RCT
[04:20] <cone-455> ffmpeg.git 03Michael Niedermayer 07master:8e5a2989a387: avcodec/libvpx: set CODEC_CAP_EXPERIMENTAL correctly instead of testing at codec open time
[07:16] <anshul> I was looking for parameter ost->sync_opts (struct outputstream)
[07:17] <anshul> int64_t sync_opts;       /* output frame counter, could be changed to some true timestamp */ // FIXME look at frame_number
[07:17] <anshul> can any one explain what does that fix mean, what is the significance of that variable
[07:22] <Compn> anshul : i think it means look at frame_number function and see whats wrong
[07:23] <anshul> frame_number is an variable
[07:24] <anshul> does it mean use frame number instead of int64_t sync_opts;
[07:59] <anshul> in ffmpeg.c function do_video_out in switch statement between case VSYNC_VSCFR and VSYNC_CFR the break is missing or break is not placed due to some ovious reason
[08:00] <anshul> if there is any reason to place the break, can any one tell me, because if I place break, the frame drop problem that I am facing is removed
[08:00] <anshul> if there is any reason to not place the break, can any one tell me, because if I place break, the frame drop problem that I am facing is removed
[08:27] <j-b> 'morning
[09:22] <mark4o> https://github.com/cisco/openh264
[11:02] <{V}> mark4o, "decoder features [..] Single thread for all slices" strange "feature"
[11:16] <mark4o> ...they never claimed they were all *good* features  :P
[11:21] <plepere> hey, just to make sure : if I declare an asm function with 6 arguments, the arguments go in r0, r1, r2, r3, r4 and r5, leaving me with the other 10 registers to play with freely ?
[11:25] <anshul> ohh my machine is fate idle
[11:25] <anshul> depend on your hardware, and how much register it have
[11:26] <anshul> mark4o depend on your hardware, and how much register it have
[11:35] <pengvado> plepere: yes
[12:13] <cone-882> ffmpeg.git 03Diego Biurrun 07master:1a5fdf9519d7: configure: Move log2 dependency declaration to a place it takes effect
[12:13] <cone-882> ffmpeg.git 03Michael Niedermayer 07master:f8d8d2e235f6: Merge remote-tracking branch 'qatar/master'
[14:13] <BBB> ubitux: have an almost working version of idct16x16 (see github if you want to review), am tracing probably a final mismatch ATM
[14:13] <ubitux> you're awesome :)
[14:14] <ubitux> i'm still strugling with the lpf :p
[14:14] <BBB> it's not finished yet :-/ until all mismatches are gone
[14:14] <BBB> anyway
[14:14] <BBB> I'll get there, gotta run to work now
[14:14] <ubitux> i'm also trying to limit myself to 8 reg
[14:14] <BBB> maybe tonight
[14:14] <BBB> oh...
[14:14] <BBB> that's hard :)
[14:14] <BBB> but goodluck!
[14:14] <ubitux> a 16reg version will allow various optim already :p
[14:14] <ubitux> yeah i'll probably change my mind hehe
[14:17] <BBB> up to you ofc
[14:17] <BBB> do what you feel is best
[14:17] <BBB> bbl :)
[14:18] <ubitux> i would have expected something larger
[14:18] <ubitux> it looks nice
[14:43] <nevcairiel> stupid 32-bit, i wish it would go away
[14:43] <nevcairiel> but especially on windows its hard to throw it out because of compat with old things
[14:55] <cone-882> ffmpeg.git 03Michael Niedermayer 07master:8477e63d3c23: sonic: use M_SQRT2 Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[14:55] <cone-882> ffmpeg.git 03Michael Niedermayer 07master:ec4d761c745d: avcodec/sonic: fix memleaks
[15:51] <j-b> <3 smarter 
[16:21] <cone-402> ffmpeg.git 03Michael Niedermayer 07master:4c32629b8259: avcodec/sonic: move version to the context
[16:21] <cone-402> ffmpeg.git 03Michael Niedermayer 07master:c61daa68e4f1: avcodec/sonic: add larger version and minor_version fields with version >= 2
[16:21] <cone-402> ffmpeg.git 03Michael Niedermayer 07master:6026a5ad4f13: sonic: Switch to rangecoder
[16:26] <smarter> michaelni: some of your commits contain things like "Fixes: CIDXXXX", what is that?
[16:26] <ubitux> coverity id
[16:26] <ubitux> (scan.coverity.com)
[16:27] <smarter> are the CIDXXX publicly available?
[16:27] <ubitux> i think you need an account
[16:30] <michaelni> smarter, i can give you an account, just need an email address
[16:37] <michaelni> smarter, is the @ubuntu address ok or should i use another ?
[16:38] <cone-402> ffmpeg.git 03Guillaume Martres 07master:679a6377e494: hevc: avoid some unnecessary differences with libav
[16:38] <cone-402> ffmpeg.git 03Guillaume Martres 07master:f90281ca97d4: hevc: Correctly set time_base
[16:43] <smarter> michaelni: sure
[16:44] <ubitux> is it ok to seek when a packet is not completely decoded?
[16:45] <michaelni> smarter, invite sent, if you get no mail in the next hour?, check your spam folder
[16:48] <Paranoialmaniac> ubitux: if it's not ok, we can't do gradual decoder refresh
[16:59] <ubitux> Paranoialmaniac: mmh?
[16:59] <ubitux> i just wonder if i'm supposed to send a null/0 packet before seeking or something
[16:59] <nevcairiel> why
[17:00] <ubitux> or if i can just reset my altered tmp packet
[17:00] <nevcairiel> seeking flushes the decoder, which should discard that
[17:00] <nevcairiel> if it does not, then the decoder is buggy
[17:00] <ubitux> ok, perfect then
[17:00] <ubitux> thx
[17:01] <Paranoialmaniac> oh, your case is before seek. sorry
[17:03] <Paranoialmaniac> ubitux: if you can't trust flush_buffer(), just reopen the decoder :P though this is an user side opinion
[17:04] <ubitux> oh i'm fine trusting it
[17:05] <ubitux> i was just trying to make some kind of seek fuzzer test
[17:05] <ubitux> and i was wondering if i could put it anywhere in the the decoding loop
[18:59] <cone-402> ffmpeg.git 03Michael Niedermayer 07master:7fa9f7ef1c2f: dvdsub_parse_extradata: fix memleak
[18:59] <cone-402> ffmpeg.git 03Michael Niedermayer 07master:3af9d8269ea2: avcodec/g2meet: check the return code of ff_set_dimensions()
[20:28] <saste> what's special about the native AAC encoder? ^
[20:29] <nevcairiel> it produces a native raw aac stream
[20:29] <nevcairiel> while the others can produce adts
[20:29] <nevcairiel> is all
[20:29] <nevcairiel> just set global_header? :p
[20:30] <saste> nevcairiel, yes, but what encoder should be considered to have a "correct" behavior?
[20:30] <nevcairiel> neither is wrong or correct
[20:30] <saste> well at least is confusing
[20:30] <saste> i'm tempted to close the ticket indeed...
[20:31] <saste> but probably we should document the behavior of the native encoder
[20:31] <saste> what's good raw AAC for?
[20:31] <nevcairiel> usually for muxing in mp4
[20:31] <nevcairiel> while adts is for TS
[20:40] <saste> nevcairiel, so basically there are three distinct bitstream formats for AAC
[20:40] <llogan> odd how mailman allowed those flipmailer emails in -devel...
[20:40] <nevcairiel> technically yes, but the LATM format has its own codec id because its really even more special
[20:41] <saste> raw AAC, ADTS (for MPEG-TS), and ASC for MP4/MOV output
[20:41] <nevcairiel> oh right
[20:41] <nevcairiel> 4 then with LATM
[20:42] <nevcairiel> i probably wouldnt really make a difference between raw and ASC though
[20:42] <saste> nevcairiel, i wonder if it would make sense to add an option to select the correct output, rather than having to mess with generic codec flags and bitstream filters
[20:42] <saste> native AAC will default to raw, unless flags +global_header is set
[20:43] <nevcairiel> the other encoder libs that have the capability simply use the global_header flag to produce raw+extradata, and adts otherwise
[20:43] <nevcairiel> iirc.
[20:43] <saste> in that case the output will be in ADTS format, and you need to add the aac_adtstoasc to mux to MP4
[20:44] <saste> and the MPEGTS muxer will complain in case of raw with no extradata
[20:44] <saste> tricky...
[20:44] <nevcairiel> raw with no extradata is a kinda bad format anyway
[20:45] <nevcairiel> native aac enc seems to always produce raw+extradata
[20:45] <nevcairiel> which would make it ASC
[21:49] <saste> michaelni: what to do with the infamous  "Application provided invalid, non monotonically increasing dts to muxer in stream 0"?
[21:49] <saste> it is a deal breaker for a lot of streaming cases
[21:49] <saste> why is ffmpeg so picky about DTS timestamps? How to fix them?
[21:53] <michaelni> saste, dts cant go backward (unless theres a timestamp discontinuity)
[21:55] <michaelni> why is timestamp from the past fed in the muxer ?
[21:57] <michaelni> non monotone dts are like if you ask the code to decode packet N at time 5sec and after that packet N+1 at 2sec that is 3 sec before
[22:01] <saste> michaelni, they are usually from external sources
[22:03] <michaelni> so there some "external" source that contains invalid timestamps, and you want to mux that into ?
[22:04] <michaelni> or does that external source support timestamp discontinuities and its not marked correctly ?
[22:05] <michaelni> or its marked and does allow discontinuites and the discontinuity code fails ?
[22:08] <Compn> saste : michael wants to fix them. do you want ffmpeg to ignore timestamps, make up its own timestamps, or read some spec and fix some de/muxer to implement timestamp properly
[22:10] <wm4> michaelni: if I feed the decoder two null packets (i.e. data=null,size=null) after resetting the decoder, it crashes, and it seems to be a regression
[22:10] <wm4> michaelni: is that a bug, or is it allowed to crash if feeding it a null packet even after getting no frame?
[22:10] <wm4> michaelni: the decoder in question was h264
[22:11] <clever> ive run into some problems with the frame.data[0] pointer, it doesnt seem to be large enough to hold a full video frame
[22:11] <clever> i'm trying to figure out how large the buffer truely is, and how much data i should be copying into it
[22:11] <Daemon404> data[0] doesnt hold a frame
[22:11] <Daemon404> it holds *one plane* of that frame
[22:12] <clever> so i need to take the YUV data, split the 3 planes appart, and put them into [0] [1] and [2]?
[22:12] <wm4> I think there are libavutil functions to calculate this stuff, but it's a bit awkward to use
[22:12] <michaelni> wm4, allowed or not, it would be better if it didnt crash, can i reproduce this easily somehow ?
[22:12] <wm4> clever: what does the decoder output?
[22:12] <clever> wm4: a ~3mb blob of data, which is currently set to YUV420Planar
[22:13] <Daemon404> clever, you should really RTFM
[22:13] <clever> and a width/height value for the pixel size
[22:13] <wm4> michaelni: not sure...
[22:13] <Daemon404> this is all documented
[22:13] <clever> *looks*
[22:13] <clever> which document in doc/ ?
[22:13] <Daemon404> it is generated doc
[22:14] <Daemon404> http://ffmpeg.org/doxygen/trunk/structAVFrame.html
[22:14] <clever> i had read the comments on that in the .h file, it explains every pixel format except yuv420
[22:15] <Daemon404> it explains how planar formats are handled
[22:15] <Daemon404> and yuv420p is planar
[22:15] <Daemon404> (and marked as such)
[22:15] <clever> that would explain why populating [0] only adjusted the brightness of the green image
[22:15] <clever> and why it segfaults if i copy 3mb into [0]
[22:16] <clever> the only part i'm missing what percentage of the buffer goes into [0] [1] and [2], how much is y, u, and v
[22:16] <Daemon404> ...
[22:17] <Daemon404> thats not even ffmpeg specific
[22:17] <Daemon404> thats in teh definition of 4:2:0 chroma subsampling
[22:17] <Compn> Daemon404 : did you see what clever is trying to do ? :)
[22:17] <Daemon404> (which, shockingly, is what yuv420 is)
[22:17] <Daemon404> some rpi crap 
[22:17] <clever> yeah, but 4 2 0 doesnt look like bit sizes, wouldnt that leave 0 bits for v?
[22:17] <Daemon404> it is the CHROMA SUBSAMPLING
[22:18] <clever> and the buffer size vs pixel size says 1.5 bytes per pixel
[22:18] <Daemon404> http://en.wikipedia.org/wiki/Chroma_subsampling#4:2:0
[22:18] <Daemon404> go read.
[22:18] <wm4> michaelni: oh well, trying to create a reproducable test case, I can't reproduce it anymore
[22:19] <clever> *reads*
[22:20] <Daemon404> also you need to copy line-by-line
[22:20] <Daemon404> you cant just shove teh whoel buffer in there
[22:21] <Daemon404> i think there's a function that exists to do this already
[22:21] <clever> the gpu does have 4 different YUV420 outputs, planar, packedplanar, semiplanar, and packedsemiplanar
[22:22] <JEEB> in general from GPU decoders you get NV12
[22:22] <Daemon404> if you can get planar
[22:22] <Daemon404> then get planar
[22:22] <wm4> semiplanar could be nv12...
[22:23] <clever> i do seem to be getting planar data, i just need to copy it into the data arrays in the frame now
[22:23] <saste> Compn, >read some spec and fix some de/muxer to implement timestamp properly
[22:23] <saste> no, do you?
[22:24] <wm4> michaelni: ok, this hack should make ffplay crash after some seconds of playing h264: http://sprunge.us/XbYY
[22:25] <Compn> saste : well which streaming is giving the error, and which spec to read ?
[22:25] <Compn> or 4th option, just remove the warning message and make users happy
[22:25] <michaelni> saste, i was trying to understand what you are doing to get the dts error
[22:26] <iive> clever: yuv420 is 12bit, it have 8 bits of Y sample, 8/4 bits for U and 8/4 bits for V.
[22:27] <clever> so the Y plane should just be width*height bytes in size
[22:27] <Daemon404> clever, you cant copy on one go
[22:27] <Daemon404> stride matters
[22:27] <clever> and the gpu says that the stride is the same as the width in this case
[22:27] <clever> but that may varry from file to file
[22:27] <wm4> god I hate it when people talk about "bits per pixels" with planar, subsampled yuv formats
[22:28] <wm4> it really doesn't help understanding and just confuses everyone
[22:28] <Daemon404> clever, avframe does not have width == stride
[22:28] <Daemon404> necessarily
[22:28] <Daemon404> http://pastebin.com/AK0RLBH4
[22:28] <Daemon404> something like this
[22:28] <clever> ah, the ffmpeg buffer may not be compatible
[22:28] <clever> is it valid to alter linesize[0] ?
[22:28] <clever> just to inform ffmpeg of the data format i already have
[22:28] <Daemon404> no
[22:28] <Daemon404> linesize is given to you
[22:29] <Daemon404> assuming ffmpeg allocs it for you
[22:29] <wm4> you could setup an AVFrame to point to your own buffer
[22:29] <Daemon404> you can yes
[22:29] <wm4> then setting linesize might be reasonable
[22:29] <clever> that would reduce the memcpy's going all over the place
[22:29] <Daemon404> but better make damn sure that its safe to do so
[22:29] <Daemon404> from the lib
[22:29] <wm4> but considering all the insane requirements on AVFrame data, it's probably better not to
[22:30] <Daemon404> wm4, it also cripples DR
[22:30] <clever> the omx lib will only modify the buffer when you call fillthisbuffer, which i run inside the end_frame function
[22:30] <Daemon404> clever, i would still copy it
[22:30] <clever> so it would depend on if ffmpeg calls end_frame while its using the old frame
[22:30] <clever> and if i double buffer it
[22:30] <Daemon404> for use with direct render in ffmpeg
[22:30] <wm4> copying to just make it work would probably be better at first
[22:30] <clever> yeah, let me implent the copy first
[22:32] <clever> hmmm, but i dont have 3 planes on the input size, just a single buffer with all the data
[22:33] <Daemon404> this is why you read their docs
[22:33] <Daemon404> (unless theyre shit and dont define anything)
[22:33] <clever> the docs are ~800 pages, they define a lot of things
[22:35] <clever> nope, no obvious part explaining where each plane starts in the buffer
[22:36] <Daemon404> where are these docs
[22:36] <clever> http://www.khronos.org/registry/omxil/specs/OpenMAX_IL_1_1_2_Specification.pdf
[22:37] <clever> just spotted a paragraph explaining that you cant put 2 planes in the same buffer, but nothing explaining which plane its giving, or why the buffer i have is width*height*12 bits in size
[22:38] <Daemon404> are you given a stride anywhere
[22:38] <clever> yeah, in the same area i'm given the width and height
[22:39] <Daemon404> i would think it is:
[22:39] <Daemon404> Y - starts at 0
[22:39] <Daemon404> U - starts at height * stride
[22:39] <clever> and v is just double that?
[22:39] <Daemon404> V - starts at U + (height / 2) + stride
[22:40] <clever> ah
[22:40] <nevcairiel> stride / 2 usually
[22:40] <Daemon404> er
[22:40] <Daemon404> woops
[22:40] <Daemon404> typo
[22:40] <Daemon404> V - starts at U + (height / 2 * stride)
[22:40] <Daemon404> nevcairiel, eh no
[22:40] <Daemon404> you should have 3 strides
[22:40] <Daemon404> not 1
[22:40] <nevcairiel> many apis i have seen just give you one stride or pitch or whatever, and assume you know how to handle the pixel format in question
[22:41] <clever> decoder->stride = portdef.format.image.nStride;
[22:41] <clever> this only has a single field in the struct
[22:41] <nevcairiel> but if they give you more then one stride, great
[22:41] <Daemon404> nevcairiel, kind of defeats the point of a stride for chrom planes
[22:41] <Daemon404> for alignment purposes anyway
[22:41] <nevcairiel> that depends what the main stride is aligned on
[22:41] <nevcairiel> :)
[22:41] <Daemon404> true
[22:42] <Daemon404> i guess V = U + ((height / 2) * (stride / 2)) maybe
[22:42] <Daemon404> but that seems pretty braindead.
[22:42] <Daemon404> (especaially undoc'd)
[22:43] <clever> your example increments the src pointer by stride after each line, what if i just keep that pointer between planes?
[22:43] <clever> and keep incrementing it by that much every time?
[22:43] <Daemon404> you need to increment by stride / 2 probably for chroma
[22:44] <clever> ah, thats simple enough to fix
[22:44] <Daemon404> buf += stride >> !!p; <-- too ricer? 
[22:44] Action: Daemon404 runs in shame
[22:44] <clever> lol
[22:45] <clever> how about my insanely complex compile env!
[22:45] <clever> i couldnt get a perfectly matching cross compiler, so i just run the entire rpi os inside qemu-userspace
[22:45] <clever> so now i have a ~200mhz dual core arm with 3gig of ram
[22:46] <clever> instead of a 700mhz single core arm with 128mb ram
[22:46] <clever> cpu wise, its about equal to the raspberrypi, but its not going into swap hell and i'm less likely to unplug it by mistake mid-compile
[23:59] <cone-808> ffmpeg.git 03Michael Niedermayer 07master:e23b18321fb5: avcodec/hnm4video: change width/height to int
[23:59] <cone-808> ffmpeg.git 03Michael Niedermayer 07master:d9339ab55373: avcodec/h264: fix code that blindly dereferences NULL DPB
[00:00] --- Wed Dec 11 2013