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

[burek]

[00:01] <BBB> it allows you to run strings binary | grep license:
[02:36] <cone-436> ffmpeg.git 03Michael Niedermayer 07master:7620d48f2eab: avformat/network: Check for av_malloc* failures in ff_tls_init()
[06:17] <cone-982> ffmpeg.git 03Rong Yan 07master:fc35df893175: avcodec/ppc/idctdsp.c: POWER LE support in idct_add_altivec()
[08:58] <rcombs> ^ thoughts pls
[14:26] <cone-982> ffmpeg.git 03Michael Niedermayer 07master:ed91c8651a87: avformat/mov: simplify pasp value before setting SAR
[14:27] <wm4> man that tta stuff is weird
[14:28] <wm4> and it interacts with the ffmpeg index stuff, which is even more weird
[15:15] <cone-982> ffmpeg.git 03Michael Niedermayer 07master:63186ac5f12e: avutil/mem: replace remaining void **/*** casts by memcpy()
[15:34] <cone-982> ffmpeg.git 03Matt Oliver 07master:22504396fe24: avformat/mpegtsenc: Fix build with msvc
[15:35] <Daemon404> void ***.... scary
[15:37] <nevcairiel> the indirection is strong in this one
[16:16] <jfmcarreira> heyy guys
[16:16] <jfmcarreira> there is any error concealment support in ffmpeg video decoders? is this a interesting topic for ffmpeg developers?
[16:17] <cone-982> ffmpeg.git 03wm4 07master:6a0cd529a351: avformat/tta: fix crash with corrupted files
[16:21] <iive> jfmcarreira: check libavcodec/error_resilience.c
[16:24] <compn> jfmcarreira : yes, lots of ecc c
[16:24] <compn> or whatever its called
[16:24] <compn> :)
[16:24] <jfmcarreira> iive: compn: i was just looking at the code
[16:25] <jfmcarreira> i am doing reasearch in error concealment and error resilience and I was curious if it would any interest in ffmpeg libs
[16:28] <michaelni> jfmcarreira, sure, all improvments to error concealment are welcome
[16:30] <jfmcarreira> michaelni: the problem is understand how dat is stored in the ffmpeg libs. i noticed that h264 decoder is using the concealment functions. I am quite familiar with the HEVC and H264 decoder but only the reference software
[16:55] <jfmcarreira> i was just trying to build ffmpeg and i am getting this error make: *** No rule to make target 'libavcodec/tpel_template.c', needed by 'libavcodec/h264qpel.o'.  Stop.
[16:56] <nevcairiel> i dont think that file has existed for a long time, did you have a old checkout you just updated or so? if so, do a make distclean or even better a git clean -xdf
[16:58] <jfmcarreira> nevcairiel: make distclean might help
[16:58] <jfmcarreira> thanks
[17:23] <compn> jfmcarreira : like michaelni says, we are always interested in error concealment and contiuning to decode on broken files. just remember on irc we are on at different times, and you can always ask on the ffmpeg-devel mailing list about adding error concealment , you may find more people reply on the ml than on irc. (we are not all on both communication methods)
[17:28] <jfmcarreira> compn: yeah thanks. I will take a look into the concealment code.  it was interesting for me to add it to HEVC code 
[17:29] <jfmcarreira> i mean the ffmpeg implementation of the hevc codec
[18:03] <ubitux> http://b.pkh.me/kdtree-try1.png http://b.pkh.me/kdtree-try2.png http://b.pkh.me/kdtree-try3.png ...
[18:03] <ubitux> tree starting to get reasonable... slowly..
[18:04] <ubitux> still shitty though
[18:22] <ubitux> http://b.pkh.me/kdtree-try4.png mmh
[18:57] <wm4> I love that there's a ffio_read_varlen() function, which uses a specific variable length encoding
[18:57] <wm4> and which is used by nutdec.c and mpc8.c
[18:57] <wm4> and nothing else
[19:01] <cone-982> ffmpeg.git 03Liviu Oniciuc 07master:b37858eae186: avformat/img2dec: remove the non-negative number requirement for start_number option
[19:04] <michaelni> wm4, yes that function should be named differently
[19:04] <michaelni> or be made more generic
[19:26] <akira4> ubitux: update patch http://pastebin.com/4VQiqsRV.
[20:18] <wm4> is AV_PIX_FMT_RGB32 the right pixel format, if the alpha channel seems to contain garbage?
[20:18] <wm4> should the decoder zero-out the alpha and use RGB0?
[20:18] <wm4> I have a camtasia sample that basically has randomly 0xFF or 0x00 as alpha
[20:19] <wm4> as rectangular regions
[20:37] <ubitux> akira4: 1. use sub.srt or something instead of video.mkv in the examples
[20:37] <ubitux> akira4: 2. use AV_LOG_ERROR instead of 0 for av_log()
[20:39] <ubitux> akira4: 3. actually, instead of these av_log, do ret = AVERROR(ENOMEM); goto end
[20:41] <ubitux> akira4: 4. fix your style, it's still off (space after if/while, { on the same line)
[20:41] <ubitux> akira4: rest LGTM
[20:41] <ubitux> you can submit the patch with these modification directly to the mailing list
[20:42] <akira4> okay. Thanks.
[20:46] <akira4> ubitux: do I need to make an entry in the Changelog?
[20:49] <ubitux> akira4: up to you
[20:52] <kurosu> jamrial, the avx2 fix is x264's sandbox. Not sure what it implies, but that's probably several steps towards merge in x264
[20:52] <kurosu> as for the indentation, ok
[20:54] <kurosu> not sure if it's worth sending a new one, but it looks final (your suggested improvements would be in another patch I guess)
[20:54] <mraulet> hi kurosu thanks for fixing it
[20:55] <mraulet> jamrial sse4 and avx2 are more or less same performance
[20:55] <mraulet> on 8bits
[20:55] <mraulet> 10bits gives us huge improvements
[20:56] <mraulet> but we dont have those cross lane issues
[20:58] <jamrial> is it worth adding the 8bit one, then?
[21:00] <mraulet> I havent benchmarked them solely
[21:01] <kurosu> the issue is also that the sizes are so much varying that you often need to split them a bit to notice things
[21:02] <mraulet> I have improvements on hv (intrinsics version) but the choice that have been chosen by P Lepere mixing hv doesnt allow an easy avx2 implementation 
[21:02] <kurosu> iirc, mc intrinsics are on par with yasm for larger blocks, slower for smaller ones
[21:02] <kurosu> that avx2 implementation seems to have made epel_hv 16-wide possible in sse4
[21:02] <mraulet> seperating h and v would be simpler to implement and give 5% improvements decoding time on basketballdrive qp27
[21:03] <mraulet> it works for e but not for q :-)
[21:03] <kurosu> I have integrated the relevant changes but they wait in another patch
[21:03] <mraulet> ok
[21:03] <mraulet> let me try
[21:04] <kurosu> btw is your comment about hv being done in a single step, without an intermediate buffer? if yes, indeed it was a bit unusual
[21:05] <kurosu> of course bidir in hevc triples the amount of code, but vp9's mc asm is so much more compact ...
[21:05] <mraulet> intrinsics version has this intermediate buffer
[21:05] <mraulet> the asm implementation does not have it
[21:06] <mraulet> it is computing h and v on the fly
[21:07] <kurosu> the actual big stuff to do is port idcts, but that's a huge amount of work even translating it, let alone improving it
[21:07] <mraulet> oh yes
[21:07] <kurosu> it's an important piece, but I really don't want to touch it
[21:08] <mraulet> didnt want to do it again
[21:08] <mraulet> I did some refactoring on the intrinsic functions and it is a nightmare 
[21:08] <mraulet> you have to deal with the size of the code to have something efficient
[21:09] <kurosu> the worst is that the most complex ones (16x16 and 32x32) are likely the more useful ones
[21:09] <mraulet> it has huge effects on the performance
[21:09] <mraulet> not sure they are more used
[21:09] <mraulet> but as they are bigger ^^ they use more time
[21:10] <kurosu> yeah, my point
[21:11] <kurosu> actually, iirc, it is 16x16 above all else, 32x32 and 8x8 frequency depends on content/resolution
[21:11] <mraulet> michaelni: if jamrial or kurosu are willing to lead the development of the hevc decoder I dont care&
[21:11] <mraulet> I am supposed to not touch him to much now
[21:12] <mraulet> *him > it 
[21:12] <kierank> mraulet: hehe
[21:12] <kurosu> I don't want to lead nor really be active
[21:12] <mraulet> oops I am not supposed ^^
[21:12] <kurosu> on its development
[21:13] <jamrial> same, not interested. i'm just trying to port some of the missing asm
[21:13] <mraulet> but you already are
[21:13] <jamrial> and i don't know its inner workings enough to lead any kind of development
[21:13] <kurosu> but there are like 2 or 3 ffmpeg devs interested in it, so it's easy being among the most active
[21:14] <jamrial> why are you not supposed to touch it much, btw?
[21:14] <mraulet> working for a company now
[21:14] <mraulet> kurosu can mention it :)
[21:14] <kurosu> people can look at your linkedin page, too ;)
[21:15] <mraulet> they can for sure
[21:15] <kierank> not an evil company so it's ok :)
[21:15] <mraulet> kierank! :-)
[21:18] <mraulet> kierank: before leaving I have some evil work to do :-) I need to fix interlace, I already have something more or less working but I need some feedback when it is a bottom field first > do I need to store this bottom field first with an offset?
[21:19] <kurosu> what a nice parting gift
[21:19] <nevcairiel> i thought giving  the seperate fields out of the decoder was actually a fun effect
[21:20] <kierank> I think in ffmpeg the first line is always the top field
[21:20] <nevcairiel> hm i wonder how i can get the hwaccel to combine those fields
[21:20] <kierank> but i might be wrong
[21:20] <nevcairiel> kierank: its correct
[21:20] <mraulet> ok
[21:20] <nevcairiel> they are always in proper spatial order
[21:20] <mraulet> so I do have something then
[21:21] <nevcairiel> you would offset it by one line i guess, yeah
[21:21] <mraulet> nevcariel I combine them when I output the frame, I copy the second field
[21:21] <nevcairiel> ew
[21:21] <mraulet> they are not always in the same order
[21:21] <nevcairiel> cant you just decode into the same frame, and adjust the stride/linesize to always skip one line?
[21:22] <nevcairiel> that way it may not break apart terribly for hwaccels either
[21:23] <mraulet> I did want it to intrusive
[21:23] <mraulet> and 4K wont deal with interlace so& a copy should be okay
[21:24] <nevcairiel> but i cant copy hwaccel frames :(
[21:24] <kurosu> nevcairiel, do you mean you can't mimic the behaviour mraulet wants to have for the software decoder ?
[21:25] <nevcairiel> right
[21:25] <kurosu> (or at a large cost)
[21:25] <kurosu> just pointing that out, as I wasn't sure he thought of that
[21:25] <kurosu> different behaviours for different decoders of the same format = not good
[21:25] <nevcairiel> the only way a hwaccel would potentially deal with this is if it decodes both fields directly into the same frame
[21:26] <nevcairiel> which a sw decoder can also do without too much harm with some linesize magic
[21:28] <kurosu> how is interlacing indicated? sei messages and something else? because I wonder how h/w decoders deal with this (output separate fields or?)
[21:29] <mraulet> sei message only
[21:30] <kurosu> gotta go, goodnight
[21:32] <nevcairiel> i'm not sure if the hwaccel defines support for this kind of interlaced mode at all, maybe they do expect single fields to be send to the renderer
[21:37] <mraulet> what kind of information do you have as output?
[21:39] <mraulet> the output is already POC ordered?
[21:39] <nevcairiel> its directly integrated in the ffmpeg hevc decoder, it does the re-ordering, the hwaccel just replaces the actual slice decoding
[21:41] <mraulet> so you are decoding the SEI and the slice header in sw so you can easily combine the output
[21:41] <nevcairiel> but the output is opaque hardware surfaces :)
[21:41] <mraulet> ah
[21:42] <mraulet> if you dont send sei to the hwaccel then it wont combine anything
[21:43] <nevcairiel> cant send that, it only takes slice data, or a struct with parsed out properties from sps/pps/vps and some slice header data
[21:43] <nevcairiel> i dont suppose the sps/pps/vps indicate somewhere if its interlaced, just so that I could know to maybe not use hwaccel on this clip?
[21:44] <mraulet> vps can have this information but it is optional
[21:44] <mraulet> and you dont know which field comes first with the vps
[21:44] <nevcairiel> well the individual field output isnt too bad, built-in bob deinterlace right there
[21:45] <nevcairiel> :D
[21:45] <wm4> except when it's done with progressive video...
[21:45] <wm4> like vdpau gl interop does
[21:46] <mraulet> I will extract the interlace code from openhevc and lets see what todo with it
[22:02] <cone-276> ffmpeg.git 03Diego Biurrun 07master:75439bb31b3a: siff: K&R formatting cosmetics
[22:02] <cone-276> ffmpeg.git 03Michael Niedermayer 07master:46a16ca15a68: Merge commit '75439bb31b3ab76f9a4d30c5de4ff9f407ec8128'
[22:14] <cone-276> ffmpeg.git 03Diego Biurrun 07master:27b99d929fe3: siff: Return more meaningful error values
[22:14] <cone-276> ffmpeg.git 03Michael Niedermayer 07master:deeba777ad0a: Merge commit '27b99d929fe3440b4bba8e5d970c2802f274f328'
[22:22] <jamrial> mode change 100644 => 100755 libavformat/img2dec.c
[22:22] <jamrial> mode change 100644 => 100755 libavformat/utils.c
[22:22] <jamrial> i assume this wasn't intended, right?
[22:23] <jamrial> commit b37858eae186ff84afd38cf3e845ba6e037e6397
[22:26] <cone-276> ffmpeg.git 03Hendrik Leppkes 07master:e3528d2a7bf2: mov: Implement parsing of the "HandlerName" from the MP4 HDLR atom
[22:26] <cone-276> ffmpeg.git 03Michael Niedermayer 07master:a83e0639c0ce: Merge commit 'e3528d2a7bf29ba148d7ac1678552ce0089cd14f'
[22:27] <nevcairiel> why do both the sps and pps in the hevc decoder have a scaling_list member, but only one of them is filled? :(
[22:28] <michaelni> jamrial, fixed, thx
[22:28] <cone-276> ffmpeg.git 03Michael Niedermayer 07master:e005dc621ab9: avformat: fix mode of img2dec.c and utils.c
[22:30] <nevcairiel> hm, am i reading this right? the scaling list can be either in the pps or the sps? what wizardry is this
[22:32] <kierank> yes
[22:32] <kierank> in some of the fancier profiles it can be easier
[22:35] <nevcairiel> weird
[22:35] <kierank> not sure why
[22:35] <kierank> either*
[22:35] <nevcairiel> what is that useful for? do you refresh the pps more often than the sps or something?
[22:35] <kierank> some encoders write a pps with every frame
[22:35] <kierank> so i guess it allows per frame scaling list
[22:36] <cone-276> ffmpeg.git 03Carl Eugen Hoyos 07master:67e9f3907d6d: isom: Decode Prores 4444 XQ with the existing Prores decoder
[22:36] <cone-276> ffmpeg.git 03Michael Niedermayer 07master:94337f8c2dd9: Merge commit '67e9f3907d6d438a413df72d72c1339a0c11a290'
[22:40] <fixxxermet> Could anyone fill me in on the status of ffserver?  Is it still being maintained?
[22:41] <JEEB> yes, barely'ish
[22:41] <nevcairiel> well there we go, more complete patch
[22:43] <fixxxermet> heh.
[22:43] <fixxxermet> Any details JEEB?  I've read a efw forum posts where people recommend not using it.
[22:43] <fixxxermet> I'm considering integrating ffserver as a core component of zoneminder and I guess I'm wondering if that is a good idea at this point
[22:43] <fixxxermet> I'd rip most of our own streaming code out and use what you guys have
[22:44] <JEEB> fixxxermet, it gets a patch every now and then but generally it's only usable if you know how it works
[22:44] <JEEB> a lot of stuff is supported by ffmpeg itself
[22:44] <JEEB> the command line tool that is
[22:44] <JEEB> so the need to actually use ffserver is limited to very specific scenarios
[22:44] <fixxxermet> The 1 feed to 2 streams feature is really, really fantastic...  But you're right, ffmpeg can do that
[22:45] <fixxxermet> Well, I think it can anyway
[22:45] <JEEB> yes, as far as I know it can :P
[22:45] <fixxxermet> So in which cases do you see ffserver making sense?
[22:46] <JEEB> a) if you know how to use it and b) something that ffmpeg itself can't do
[22:46] <JEEB> I haven't used ffserver enough to know anything regarding the latter :P
[22:46] <fixxxermet> heh, good answers.
[22:50] <cone-276> ffmpeg.git 03Michael Niedermayer 07master:6f7a32839d1b: svq1enc: correctly handle memory error and allocations
[22:50] <cone-276> ffmpeg.git 03Michael Niedermayer 07master:acfb4ede2f6b: Merge commit '6f7a32839d1b913be8170e91c3ac9816b314da21'
[23:10] <cone-276> ffmpeg.git 03Carl Eugen Hoyos 07release/2.5:763e6ecf8336: lavc/aarch64: Do not use the neon horizontal chroma loop filter for H.264 4:2:2. (cherry picked from commit 4faea46bd906b3897018736208123aa36c3f45d5)
[23:21] <cone-276> ffmpeg.git 03Luca Barbato 07master:9b8c8a9395c8: svq1dec: Validate the stages value strictly
[23:21] <cone-276> ffmpeg.git 03Michael Niedermayer 07master:cba3a46e936c: Merge commit '9b8c8a9395c849639aea0f6b5300e991e93c3a73'
[23:21] <cone-276> ffmpeg.git 03Michael Niedermayer 07master:741b56fceece: avcodec/svq1dec: Add assert to ensure "stages >= 0"
[23:46] <cone-276> ffmpeg.git 03Luca Barbato 07master:a6653787a4b1: libopencv: Check kernel_str life cycle
[23:46] <cone-276> ffmpeg.git 03Michael Niedermayer 07master:1dc1c4e7a82e: Merge commit 'a6653787a4b1e89170ff7962312dd110769c83a3'
[23:56] <cone-276> ffmpeg.git 03Vittorio Giovara 07master:ec524ed12aa1: tta: Fix framepos and start_offset types
[23:56] <cone-276> ffmpeg.git 03Michael Niedermayer 07master:bd12634d6b83: Merge commit 'ec524ed12aa1aeb37125203f1adf5aa10dfcb0de'
[00:00] --- Wed Feb  4 2015