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

[burek]

[01:48:49 CET] <J_Darnley> ld: final link failed: No space left on device -- shit
[01:50:20 CET] <J_Darnley> I really should move off this tine 10G partition
[01:53:08 CET] <llogan> why so small?
[01:53:30 CET] <J_Darnley> It was a linux dual-boot partition many years ago
[01:53:55 CET] <J_Darnley> sandwiched between some others
[01:54:09 CET] <J_Darnley> then it gor repurposed into my cygwin drive
[01:54:12 CET] <J_Darnley> *got
[01:59:51 CET] <llogan> did we apply to Outreachy? Deadline was Nov 2. I completely forgot about it then left town for a while.
[02:02:46 CET] <llogan> now i'm confused. that's the deadline for students.
[02:10:21 CET] <beastd> J_Darnley: You got SChannel stuff working in cygwin? Something went wrong with the headers here.
[02:11:03 CET] <J_Darnley> uh what?  no, I don't think I'm working on that
[07:19:47 CET] <satinder> Hi guys I have two external devices : camera /dev/video0 and external audio hw:TW68SoundCard,0,1, when I playing /dev/video0 directly that is very good playing, audio is also playing good directly from hw:TW68SoundCard,0,1 . but when i want make a compressed file I mean capture video in h.264 and audio in mp3 then that file is playing too much fast . please any one can help me. my command is follo
[07:19:48 CET] <satinder> wing :  ffmpeg -i /dev/video0 -f alsa -ac 1 -i hw:TW68SoundCard,0,1 -vcodec libx264 -acodec mp2 -f mpegts video_audio.ts .please help any one
[12:42:50 CET] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.7:3300005351e7: avcodec/jpeg2000dec: Check for duplicate SIZ marker
[12:42:51 CET] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.7:63465f00707c: avcodec/utils: Better check for channels in av_get_audio_frame_duration()
[12:42:52 CET] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.7:b996cde19323: avcodec/ivi: Check image dimensions
[12:42:53 CET] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.7:ec1f59150d24: avcodec/flashsv: Check size before updating it
[12:42:54 CET] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.7:d61c3d1fca62: avcodec/dpx: Move need_align to act per line
[12:42:55 CET] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.7:196be9284a8d: avcodec/error_resilience: avoid accessing previous or next frames tables beyond height
[12:42:56 CET] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.7:08940cd54596: avcodec/dxtory: Fix input size check in dxtory_decode_v1_420()
[12:42:57 CET] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.7:588a7769c7ad: avcodec/dxtory: Fix input size check in dxtory_decode_v1_410()
[12:42:58 CET] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.7:acba2a36b3ce: avcodec/takdec: Skip last p2 sample (which is unused)
[12:42:59 CET] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.7:10398038239b: avcodec/smacker: Check that the data size is a multiple of a sample vector
[12:43:00 CET] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.7:082bdba4e715: avcodec/wmaprodec: Check for overread in decode_packet()
[12:43:01 CET] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.7:d972df307aaa: avcodec/jpeg2000: Use av_image_check_size() in ff_jpeg2000_init_component()
[12:43:02 CET] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.7:a9c73b13c117: avcodec/jpeg2000: Check comp coords to be within the supported size
[12:43:03 CET] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.7:2deaccfe670e: avcodec/jpeg2000dec: Check SIZ dimensions to be within the supported range
[12:43:04 CET] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.7:ca43c6e1f53a: avcodec/jpeg2000dec: Fix potential integer overflow with tile dimensions
[12:43:05 CET] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.7:0ecde4557068: avformat/utils: Do not init parser if probing is unfinished
[12:43:06 CET] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.7:aa9dadccacc8: avformat/matroskadec: Check subtitle stream before dereferencing
[12:52:28 CET] <saste> wm4: are you fine with the ffprobe patch, or do you want me to change it?
[12:57:10 CET] <wm4> saste: I'm fine with it
[12:57:21 CET] <saste> wm4, thanks
[12:57:30 CET] <saste> will also send patches to fix examples
[13:07:02 CET] <cone-223> ffmpeg 03Paul B Mahol 07master:35bbc1955a58: avformat: add IVR demuxer
[13:19:30 CET] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.7:bc3d86cddb80: Update versions for 2.7.3
[14:13:49 CET] <Daemon404> nevcairiel, mind LGTMing that movenc-test [atch
[14:13:51 CET] <Daemon404> ?
[14:24:45 CET] <Daemon404> (or anyone)
[14:32:33 CET] <wm4> I could reply "probably ok"
[14:38:33 CET] <Daemon404> wm4, i see what you did there
[16:13:03 CET] <cone-223> ffmpeg 03Bryan Huh 07master:0be48dd9bb6e: avformat/dashenc: Add framerate to dash manifest
[16:13:04 CET] <cone-223> ffmpeg 03Michael Niedermayer 07master:3a4d8281c64b: avformat/genh: Fix tools/probetest failure
[16:48:17 CET] <nevcairiel> neat, visual studio officially supports debugging through gdb now
[16:53:35 CET] <Daemon404> nevcairiel, oh?
[16:53:39 CET] <Daemon404> for x86 too?
[16:53:41 CET] <Daemon404> or just arm
[16:55:41 CET] <nevcairiel> any gdb
[16:55:43 CET] <nevcairiel> local or through ssh
[16:55:55 CET] <nevcairiel> it just interfaces with gdb
[16:56:02 CET] <nevcairiel> it doesnt care what build the binary
[16:56:15 CET] <Daemon404> oic
[16:59:41 CET] <kierank> is it possible in git to merge only certain libs
[16:59:46 CET] <kierank> i.e merge all of lavc, lavf but not sws
[17:00:21 CET] <nevcairiel> you mean commits to those, or merge how?
[17:01:26 CET] <kierank> yes only merge commits to certain directories
[17:01:33 CET] <nevcairiel> no
[17:01:56 CET] <nevcairiel> you could just not merge the content of thins you dont like
[17:02:10 CET] <nevcairiel> maybe even automate that somehow
[17:04:24 CET] <nevcairiel> but if you want to use merges instead of say cherry-picks, you have to merge every commit
[17:04:29 CET] <JEEB> kierank: you could try doing https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt
[17:04:41 CET] <JEEB> or wait, no
[17:04:43 CET] <JEEB> that's the other way :/
[17:06:11 CET] <durandal_1707> split libs
[17:19:26 CET] <wm4> nevcairiel: so in dxva native mode, does the entire video chain below the decoder really only reference only at most 4 surfaces?
[17:19:45 CET] <nevcairiel> that depends on what the renderer does
[17:20:23 CET] <wm4> I'm looking at your CDecDXVA2::GetBufferCount(), which seems to allocate 20 surfaces for h264
[17:20:40 CET] <ubitux> the scale of yuv2rgb coeff and offset is driving me completely crazy :(
[17:20:47 CET] <wm4> I'm wondering how to handle this myself, as recreating the decoder on underrun doesn't seem like a good idea
[17:25:13 CET] <nevcairiel> it asks the renderer about its requirements and adds that to the number somewhere
[17:26:00 CET] <nevcairiel> although renderers usually dont request any
[17:26:05 CET] <nevcairiel> probably copy it internally
[17:38:10 CET] <cone-223> ffmpeg 03Derek Buitenhuis 07master:e73a4d849161: movenc-test: Pad the packet data start with 0s
[17:44:04 CET] <cone-223> ffmpeg 03Martin Storsjö 07master:bef3b1f59f03: movenc: Allow setting start_dts/start_cts before writing actual packets
[17:44:05 CET] <cone-223> ffmpeg 03Martin Storsjö 07master:1d62ee38894a: movenc: Add a unit test for signaling of the track start times
[17:44:06 CET] <cone-223> ffmpeg 03Derek Buitenhuis 07master:3e0daf071688: Merge commit 'bef3b1f59f036aba4a5fe599b2480f6bd9e6b280'
[17:44:07 CET] <cone-223> ffmpeg 03Derek Buitenhuis 07master:bdcf2b6af64b: Merge commit '1d62ee38894afb696674db78cee8f8d89204a8fe'
[17:44:22 CET] <Daemon404> finally
[17:47:41 CET] <cone-223> ffmpeg 03Paul B Mahol 07master:5f2c8315b3c1: thp: set duration for audio stream too
[17:47:42 CET] <cone-223> ffmpeg 03Derek Buitenhuis 07master:518742bc21f7: Merge commit '5f2c8315b3c1b28da0386fddb118ad6a0ed77a0c'
[17:48:03 CET] Action: Daemon404 leaves the rest to nevcairiel 
[17:48:04 CET] Action: Daemon404 runs
[17:48:53 CET] <nevcairiel> merging most patches is pretty trivial anyway
[17:50:16 CET] <Daemon404> yeah but now there's a backlog ;)
[20:08:38 CET] <cone-223> ffmpeg 03Martin Storsjö 07release/2.7:cf115791daf4: rtmpcrypt: Do the xtea decryption in little endian mode
[20:08:39 CET] <cone-223> ffmpeg 03Michael Niedermayer 07release/2.7:93f3752b970c: Changelog: update for 2.7.3
[20:53:45 CET] <ubitux> so we just wrote some asm in sws to handle the "0" flavors of rgb in addition ton the "a" ones (rgb0 bgr0 ...)
[20:53:56 CET] <ubitux> but apparently sws has no understanding of the 0 variant
[20:54:11 CET] <ubitux> (it's basically shared with the alpha ones)
[20:54:18 CET] <ubitux> should we drop them?
[20:55:07 CET] <J_Darnley> Drop what?  The pixel format definitions?
[20:55:36 CET] <ubitux> the asm code we added that handle it
[20:56:08 CET] <ubitux> https://github.com/ubitux/FFmpeg/commit/1531619af3ccc3cfab0eabba8f1d736a414bc901#diff-35c852210bb6f077831616bae41469a8R153
[20:56:11 CET] <ubitux> basically this
[20:56:15 CET] <J_Darnley> Don't just junk it
[20:56:37 CET] <ubitux> we can simplify by dropping it but well
[20:56:54 CET] <ubitux> is sws ever going to support the 0 variants everywhere?
[20:57:20 CET] <ubitux> that is support it as 0 being equal to 0 and not "undefined"
[20:58:50 CET] <J_Darnley> If the code cannot be used at the moment, I suggest:
[20:59:40 CET] <J_Darnley> Don't commit it.  Add a comment saying that it exists.
[21:03:13 CET] <ubitux> well, the branch is going to disappear
[21:03:24 CET] <ubitux> are you suggesting to commit it as dead code?
[21:03:30 CET] <ubitux> it's not that hard to re-add it but well
[21:03:44 CET] <J_Darnley> No.  I was suggesting the exact opposite
[21:03:53 CET] <J_Darnley> Don't commit dead code
[21:03:54 CET] <ubitux> it won't "exist" for long
[21:04:02 CET] <ubitux> right, ok
[21:04:12 CET] <ubitux> well, it looks like living code ;)
[21:04:19 CET] <ubitux> it will just never be triggered
[21:04:34 CET] <ubitux> because dst pixel format will never be a 0-flavour
[21:04:44 CET] <ubitux> (sws maps 0-flavor to a-flavor)
[21:04:54 CET] <ubitux> (but as soon as it stops, it will be triggered :P)
[21:05:15 CET] <J_Darnley> If you're going to delete the branch then cherry pick the commit(s) to a new one and leave it hanging
[21:05:33 CET] <ubitux> yeah yeah we'll just trash that, doesn't really matter
[21:07:05 CET] <ubitux> btw, it's fun to see that every yuv2rgb coeff is in the same unit between c and x86, but the offset has a completely different one
[21:07:09 CET] <ubitux> it's very confusing
[21:07:13 CET] <wm4> <ubitux> (sws maps 0-flavor to a-flavor) <- probably a hack to support them at once
[21:07:25 CET] <ubitux> yep sure
[21:07:33 CET] <wm4> doesn't sws also have an option to blend alpha?
[21:07:38 CET] <ubitux> since 0-flavors are defined as "undefined" for the 0... 
[21:07:41 CET] <wm4> that should not be run with the 0 formats
[21:07:44 CET] <wm4> yeah
[21:08:09 CET] <wm4> and if you convert rgb0 ro rgba, the a needs to be written with all bits set, rather than copy
[21:10:36 CET] <ubitux> btw, many undefined behaviour in sws/yuv2rgb.c:ff_yuv2rgb_c_init_tables
[21:10:51 CET] <ubitux> left shift should be replaced with mult
[21:10:57 CET] <J_Darnley> Stick Ganesh on it!
[21:11:03 CET] <ubitux> :)
[21:11:25 CET] <ubitux> nv12 not being full range also annoys me :(
[21:11:33 CET] <ubitux> well, whatever
[21:11:35 CET] <wm4> nv12 can be ether
[21:11:37 CET] <wm4> *either
[21:12:11 CET] <ubitux> yes, but when you do testsrc2,format=nv12,format=rgba why isn't it fullrange?
[21:12:20 CET] <ubitux> i mean, by default
[21:12:27 CET] <ubitux> am i missing sth obvious?
[21:12:33 CET] <wm4> because yuv formats are usually not full range by default?
[21:12:46 CET] <wm4> and because testsrc2 flags it as half range (probably, didn't check)
[21:12:54 CET] <ubitux> i thought only the J ones aren't supposed to be full range
[21:12:59 CET] <wm4> OTOH, libavfilter doesn't support range flags anyway
[21:13:08 CET] <wm4> despite plans to extend libavfilter with demuxing etc.
[21:13:11 CET] <ubitux> (J ones and grays)
[21:13:32 CET] <wm4> other way around, J are an old hack to flag formats full range
[21:13:46 CET] <ubitux> oh.
[21:14:16 CET] <ubitux> damn, so i got it all wrong then ok
[21:14:20 CET] <wm4> using AVColorRange is the "new" way to mark them
[21:15:10 CET] <wm4> there's also half-range RGB (consumer shit hardware takes it), but I think libswscale refuses to acknowledge its existence
[21:15:56 CET] <BtbN> limited-range? Or is half-range an actual thing?
[21:21:51 CET] <JEEB> similar to limited range YCbCr in values
[21:22:16 CET] <JEEB> some funky devices actually want their RGB input in limited range, even :/
[21:22:24 CET] <Daemon404> wut
[21:22:24 CET] <wm4> yes
[21:22:28 CET] <wm4> like shitty consumer projectors
[21:22:34 CET] <JEEB> yup
[21:22:36 CET] <wm4> could be user configuration error too
[21:24:43 CET] <J_Darnley> Image data you can send using 7-bit ascii chars!
[21:25:34 CET] <ubitux> xface master race
[21:26:08 CET] <Daemon404> pnm master race
[21:48:13 CET] <J_Darnley> :)  I have wasted all y time today trying to build a cross-compiler I will use exactly once.
[21:48:30 CET] <JEEB> not packaged on your distro?
[21:48:45 CET] <JEEB> although I think used my ARM toolchains about as much :)
[21:49:54 CET] <J_Darnley> No.  Cygwin isn't a very common target
[21:50:28 CET] <JEEB> ah
[21:50:36 CET] <JEEB> so *nix->cygwin?
[21:50:39 CET] <JEEB> interesting need :)
[21:51:23 CET] <J_Darnley> Yes, that's what I was planning.
[22:22:52 CET] <cone-223> ffmpeg 03Michael Niedermayer 07master:fc91eeab0b3c: avutil/mem: Add av_fast_mallocz()
[22:22:53 CET] <cone-223> ffmpeg 03Michael Niedermayer 07master:6f37226b687f: avcodec/h264_slice: Clear top_borders on allocation
[23:26:58 CET] <J_Darnley> g++: internal compiler error: Killed (program cc1plus) -- Good job!
[23:45:31 CET] <kierank> BBB: did 30 million runs of vp9 fuzzing, 1 crash but doesn't seem reproducable. have to use the machine for something else now
[23:45:48 CET] <BBB> any valgrind/asan output for the file?
[23:45:57 CET] <BBB> or do you want to share it?
[23:46:01 CET] <BBB> (and thanks!!!!!)
[23:56:07 CET] <cone-223> ffmpeg 03Andreas Cadhalpun 07master:047bf82c181c: mxfdec: check edit_rate also for physical_track
[23:59:08 CET] <kierank> BBB: will do but internet being slow
[23:59:11 CET] <kierank> might have to upload at work
[23:59:16 CET] <BBB> ok, ty!
[00:00:00 CET] --- Thu Nov 19 2015