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

[burek]

[00:17:15 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:e0db41316a94: avfilter/drawutils: Fix format validity check in ff_draw_init()
[01:04:55 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:df037fe107cc: avcodec/smvjpegdec: assert that the pixel format that has been set by our decoder is valid
[01:57:54 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:a75d22445ecb: ffprobe: check av_asprintf() for failure
[02:21:59 CEST] <cone-728> ffmpeg 03Michael Niedermayer 07master:b8ba2d3915b3: examples/decoding_encoding: Use the AVFrame width/height for processing images after decoding
[02:40:46 CEST] <cone-728> ffmpeg 03Shivraj Patil 07master:178ba1fd03c8: avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for AVC qpel functions
[05:06:35 CEST] <philipl> Awesome. The nvidia example hevc decoder has the same problem actually displaying the frames correctly. Their vdpau implementation is fundamentally broken right now.
[08:11:11 CEST] <cehoyos> philipl: Didn't they tell you that it works fine for them?
[11:31:33 CEST] <cone-077> ffmpeg 03Carl Eugen Hoyos 07master:3323c5f353af: Remove a few occurences of "long long" from the libraries.
[13:36:44 CEST] Action: ubitux just came accross https://www.youtube.com/watch?v=hqMh47lYHlc
[13:46:14 CEST] <Compn> for some reason framebuffer playback was popular with mplayer users
[13:48:04 CEST] <ubitux> https://github.com/saitoha/libsixel
[13:48:09 CEST] <ubitux> it's fun
[13:53:40 CEST] <JEEBsv> Compn: mpv got a DRM vo btw
[13:53:47 CEST] <JEEBsv> so it can be done in an even more perverted way now
[13:54:19 CEST] <JEEBsv> https://github.com/mpv-player/mpv/pull/1811
[14:03:16 CEST] <Compn> no hw accel
[14:03:17 CEST] <Compn> lol
[14:03:30 CEST] <Compn> i guess cvidix is not still an option :P
[14:03:58 CEST] <JEEBsv> not sure if hw accel support for vo_drm was added
[14:04:42 CEST] <wm4> what does hwaccel mean in this context
[14:04:58 CEST] <Compn> overlay
[14:05:07 CEST] <Compn> not full-cpu
[14:05:28 CEST] <Compn> hw scaling i guess at least? ;P
[14:06:28 CEST] <wm4> if you want that you need to use real graphic APIs
[14:06:43 CEST] Action: Compn misses -vo vesa
[14:06:57 CEST] <JEEBsv> wm4: yeah - which is what is said there at the end of the PR
[14:07:12 CEST] <JEEBsv> "... but it will need libegl and almost surely libgbm that come with their own (remarkable) chain of dependencies..."
[14:07:49 CEST] <JEEBsv> and as far as I've seen while overlays can be fast (no idea if they still are on current hardware), you have so little control on them that their usage for video rendering at this point is pretty moot
[14:08:09 CEST] <JEEBsv> shit-in shit-out kind of thing
[14:08:21 CEST] <wm4> anyway, I maintain there's almost no reason not to use xorg or wayland instead
[14:08:33 CEST] <Compn> i agree with wm4
[14:08:36 CEST] <wm4> both of these can be pretty light
[14:08:38 CEST] <JEEBsv> agreed
[14:08:51 CEST] <wm4> (even if xorg is all kinds of nightmares)
[14:09:18 CEST] <JEEBsv> seeing mpv under weston doing smooth playback was a nice experience back in my Tizen days
[14:09:21 CEST] <JEEBsv> :3
[14:09:30 CEST] <wm4> are these days over?
[14:10:27 CEST] <JEEBsv> mostly, I no longer work for a company developing any profile and the Samsung middleware is crapola
[14:11:06 CEST] <JEEBsv> it was fun getting mpv to start in any sane way with the samsung app framework
[14:11:15 CEST] <JEEBsv> because it passes parameters as arguments (!)
[14:11:28 CEST] <JEEBsv> and you cannot pass any custom arguments that aren't coded in their retarded scheme
[14:12:26 CEST] <JEEBsv> so the best way to work around that is to have a shell script which the app framework launches, which ignores any parameters and just launches mpv with exec with argv[0] set to the shell script's name
[14:13:10 CEST] <JEEBsv> because seemingly argv[0] is what the app framework uses to decide what application is launched...
[14:20:49 CEST] <cone-077> ffmpeg 03Michael Niedermayer 07master:86efe83177cd: avcodec/jpeg2000dec: Fix x/y step TODO for CPRL
[14:20:50 CEST] <cone-077> ffmpeg 03Michael Niedermayer 07master:7c244349fc14: avcodec/jpeg2000dec: Factorize component out of CPRL loop
[14:20:51 CEST] <cone-077> ffmpeg 03Michael Niedermayer 07master:0a3eb0422a75: avcodec/jpeg2000dec: try to correct tile location in CPRL code
[14:20:52 CEST] <cone-077> ffmpeg 03Michael Niedermayer 07master:eb1beb9e1c13: avcodec/jpeg2000dec: Try to fix remaining DCinema hardcoded TODOs in CPRL
[14:20:53 CEST] <cone-077> ffmpeg 03Michael Niedermayer 07master:c3517c377e1f: avcodec/jpeg2000dec: Support PCRL
[14:24:32 CEST] <BtbN> michaelni, refering to your response to the vf_colorkey filter, i'm not sure i understand what you mean by supporting any input and output format? Also, how do i indicate that the input and output link have to match in format?
[14:25:27 CEST] <wm4> I think he means lavfi format negotation is fucked
[14:28:05 CEST] <michaelni> wm4, no
[14:29:01 CEST] <michaelni> BtbN, see ff_set_common_formats() and filters using it
[14:29:13 CEST] <BtbN> ok, thanks
[14:29:41 CEST] <michaelni> BtbN, i have to leave, will read the log and reply later if you have more questions
[14:29:54 CEST] <BtbN> that keyword should be enough to find examples
[14:30:08 CEST] <michaelni> ok, good :)
[18:28:34 CEST] <jamrial> nevcairiel: there you have, two patches that make jpeg2000 a little bit faster :p
[18:29:21 CEST] <nevcairiel> ah thats probably based on the patches i was thinking about
[18:29:47 CEST] <nevcairiel> wonder if 2k dcinema works in realtime
[18:30:00 CEST] <nevcairiel> a big bottleneck is probably the xyz->rgb conversion
[18:31:21 CEST] <jamrial> not realtime as far as i could test
[18:32:07 CEST] <jamrial> and yes, the first patch (the ict one) was adapted from the intrinsics written by that guy
[18:45:24 CEST] <philipl> nevcairiel: Finally found my ST RPS problem after comparing with the nvidia example decoder.
[18:45:54 CEST] <philipl> They need the sliceheader's st rps size to be calculated even if an SPS rps is being used.
[18:46:11 CEST] <philipl> I just posted a diff
[18:50:22 CEST] <philipl> BtbN: Think we can just unconditionally turn YV12 on for nvenc, or do you think it needs to be smarter?
[18:54:18 CEST] <nevcairiel> philipl: sounds like a patch i never submitted
[18:54:42 CEST] <nevcairiel> ah no, thats something else
[18:54:44 CEST] <nevcairiel> but odd
[18:54:56 CEST] <nevcairiel> i mean, there is no syntax element in the header, is there
[18:55:00 CEST] <nevcairiel> with the flag being 0
[18:55:04 CEST] <nevcairiel> or 1 in this case
[18:55:07 CEST] <nevcairiel> weird inverted flag
[18:55:08 CEST] <philipl> There is the sps rps idx instead
[18:55:16 CEST] <philipl> Turns out they need to skip over that.
[18:55:24 CEST] <philipl> So basically it's whatever bits are in that if/else block
[18:55:48 CEST] <nevcairiel> odd
[18:55:59 CEST] <philipl> They don't parse it in either case - so they need to know how far to skip ahead in the bitstream
[18:56:22 CEST] <philipl> It's not properly documented in the header.
[18:56:48 CEST] <philipl> I've still got other conformance failures, but their example decoder fails too (in different ways by the look of things) so no help there :-P
[18:57:02 CEST] <nevcairiel> in dxva2 at least, s->sps->nb_st_rps is communicated in the struct anyway, so they can compute the size for the else block from that
[18:57:05 CEST] <nevcairiel> maybe thats why it doesnt need it
[18:57:49 CEST] <philipl> That's also communicated in the vdpau struct, but I guess they don't use it.
[18:58:40 CEST] <nevcairiel> the dxva2 spec was pretty explicit at least, set it to 0 if the flag is 1
[18:58:56 CEST] <BtbN> philipl, it should be fine. People using nvenc propably do know what they are doing.
[18:59:16 CEST] <nevcairiel> you would think so
[18:59:28 CEST] <nevcairiel> a lot of clueless people read "hardware encoding? I want in on that!"
[18:59:30 CEST] <nevcairiel> and there you go
[19:00:37 CEST] <nevcairiel> I dont suppose VDPAU has a explicit written spec?
[19:00:54 CEST] <nevcairiel> I mean this is pretty clear
[19:00:55 CEST] <nevcairiel> When the short_term_ref_pic_set_sps_flag in the slice header is equal to 0, wNumBitsForShortTermRPSInSlice shall be equal to the number of bits used in short_term_ref_pic_set( ) syntax structure that is directly included in the slice headers of the current picture. When the value of short_term_ref_pic_set_sps_flag in the slice header is equal to 1, wNumBitsForShortTermRPSInSlice shall be set to 0 by the host decoder and 
[19:00:55 CEST] <nevcairiel> accelerators shall ignore its value.
[19:01:19 CEST] <philipl> It has API docs, and each field it wants is documented.
[19:01:25 CEST] <philipl> In this case, the doc is wrong.
[19:01:30 CEST] <nevcairiel> or the driver
[19:01:41 CEST] <nevcairiel> it could calculate the else case from the other field i mentioned
[19:01:45 CEST] <philipl> As an overall API, it seems sane - AMD are moving over to it successfully.
[19:02:11 CEST] <philipl> Yeah, the implementation can do what it wants. The API actually asks for more information than is absolutely needed to provide implementation flexibility.
[19:02:27 CEST] <philipl> Of course that's a problem if you get a field wrong and your testing implementation doesn't use it but another does.
[19:03:44 CEST] <nevcairiel> Anyway, I have another patch for the rps stuff, but fate doesnt need it
[19:03:48 CEST] <nevcairiel> should submit it to the ML
[19:04:03 CEST] <nevcairiel> http://git.1f0.de/gitweb?p=ffmpeg.git;a=patch;h=1cd9f8878dfd2893311d680022074f00b4314f6b;js=1
[19:09:04 CEST] <philipl> If you need it, I'm sure I need it.
[19:09:07 CEST] <philipl> What's the symptom?
[19:09:40 CEST] <nevcairiel> weird image flashing
[19:09:43 CEST] <nevcairiel> its hard to describe
[19:09:56 CEST] <nevcairiel> but like I said fate didnt suffer
[19:10:06 CEST] <philipl> Hmm. So none of the conformance samples trigger it?
[19:10:07 CEST] <philipl> Odd.
[19:18:04 CEST] <nevcairiel> I believe it was in this clip: http://trailers.divx.com/hevc/Sintel_4k_27qp_24fps_1aud_9subs.mkv
[19:21:38 CEST] <wm4> lol this ogv issue
[19:22:02 CEST] <wm4> time for some trolling
[19:33:28 CEST] <philipl> nevcairiel: Looks great here with your fix.
[19:33:31 CEST] <philipl> So it's definitely needed.
[19:33:41 CEST] <nevcairiel> yeah, i should send it
[19:33:57 CEST] <nevcairiel> been meaning to reword it a bit and sent it off, but you know how lazyness goes
[19:34:02 CEST] <philipl> yeah
[19:34:28 CEST] <wm4> philipl: great as in it works correctly?
[19:38:57 CEST] <philipl> wm4: It looks like it's correct - which is hard to tell with the nvidia interleaving fiasco at play
[19:39:32 CEST] <wm4> interleaving fiasco?
[19:40:24 CEST] <philipl> You missed all my ranting?
[19:40:48 CEST] <philipl> So, they write their decoded frames progressively into a buffer that is always interpreted as two fields one below the other.
[19:41:17 CEST] <philipl> So, the common vdpau code will treat it as two fields and interleave the top and bottom half when putting it on the screen or doing read-back.
[19:41:43 CEST] <philipl> To make matters worse, there's an alignment dead-space between the two fields so you lose content and can't put the frame back together manually even if you try
[19:41:56 CEST] <philipl> Basically, it's not actually usable right now. They need to fix the driver.
[19:42:06 CEST] <wm4> ah
[19:42:23 CEST] <wm4> vdpau's GL interop represents frames this way
[19:42:30 CEST] <wm4> but not the functions for reading/writing raw YUV data
[19:42:38 CEST] <gouessej> Hi
[19:42:47 CEST] <philipl> Which functions? If i use get_bits on the frame, it comes back interleaved.
[19:43:21 CEST] <gouessej> Sorry for the dummy question. I've succeeded in building ffmpeg but I get this error message when converting a MP4 video into OGV: Encoder (codec theora) not found for output stream #0:0
[19:43:55 CEST] <gouessej> What should I do to compile ffmpeg with this missing codec?
[19:44:32 CEST] <gouessej> I'm trying to reproduce the bug 4613 on the very latest version of ffmpeg
[19:44:57 CEST] <philipl> gouessej: you need to build with libtheora
[19:44:59 CEST] <wm4> philipl: VdpVideoSurfaceGetBitsYCbCr should IMO return progressive data
[19:45:16 CEST] <philipl> wm4: In my opinion, it *should* as well, but it definitely doesn't.
[19:45:32 CEST] <philipl> Returns the same interleaved crap as the presentation functions do.
[19:46:04 CEST] <nevcairiel> if hevc behaves different than any other codec, then hevc is obviously broken in the driver
[19:46:05 CEST] <philipl> For h.264, even for progressive content, the decoder still splits it into fields for storage.
[19:46:17 CEST] <philipl> nevcairiel: Yes, it behaves differently and is obviously broken in the driver.
[19:46:25 CEST] <wm4> philipl: did you try the same code with h264?
[19:46:35 CEST] <philipl> As I observed last night, even their example decoder is broken in this way, despite them saying it worked.
[19:46:53 CEST] <philipl> wm4: Yes, for h264, the frames are read back correctly.
[19:46:54 CEST] <nevcairiel> they may have used an internal driver build or something
[19:47:11 CEST] <philipl> I asked multiple times about that and never got a straight answer. Oddly.
[19:47:23 CEST] <philipl> Anyway, at least we can now argue about the same application code
[19:49:23 CEST] <philipl> nevcairiel: I take it back. The clip looks ok without your change.
[19:49:32 CEST] <philipl> (and ok with it)
[19:49:40 CEST] <nevcairiel> how odd
[19:49:46 CEST] <nevcairiel> i should test without again
[19:49:52 CEST] <nevcairiel> ie ffmpeg cli
[19:50:11 CEST] <philipl> Staring at png sequences is getting boring :-)
[19:50:36 CEST] <nevcairiel> i usually just transcode with ffmpeg cli into h264 or something
[19:55:14 CEST] <philipl> I've still got other problems to fix. Everything's much better now but there are still glitches.
[19:55:17 CEST] <philipl> fun times.
[20:05:40 CEST] <nevcairiel> one fate test fails unexplainably for me, something DELTAQ something
[20:05:51 CEST] <nevcairiel> the others that fail are just hwaccel being hwaccel
[20:05:56 CEST] <nevcairiel> insanely high sizes, or cropping
[20:08:22 CEST] <philipl> It's good to know.
[20:09:01 CEST] <nevcairiel> at some point i should try to get this setup as an actual fate box
[20:09:11 CEST] <nevcairiel> but no spare gtx 960 to keep in a system where this wouldnt annoy me :P
[20:09:28 CEST] <wm4> once cropping becomes part of the API, it should be easy to do that with hwaccel
[20:10:27 CEST] <nevcairiel> i wonder if i can add a check in the ffmpeg_dxva2 code to silently fail if size exceeds hw capability
[20:10:35 CEST] <nevcairiel> right now it makes noise and fails the test
[20:11:28 CEST] <gouessej> philipl: Thanks. I wonder whether the bug 4613 doesn't come from libtheora. Does anybody have access to VLC 2.2.1? I failed to build it.
[20:11:48 CEST] <nevcairiel> but i think thats how ffmpeg.c handles hwaccels, if the codec sets a hwaccel pixfmt, then ffmpeg.c expects the hwaccel to work
[20:42:21 CEST] <cone-077> ffmpeg 03Clément BSsch 07master:324cf0645d6a: avcodec/ass_split: check ASSSplitContext alloc
[20:43:42 CEST] <cone-077> ffmpeg 03Andreas Cadhalpun 07master:45babb01217f: configure: only disable VSX for !ppc64el
[20:52:09 CEST] <cone-077> ffmpeg 03Clément BSsch 07master:a056636c8131: avfilter/geq: assert on pixel format descriptor
[20:52:10 CEST] <cone-077> ffmpeg 03Clément BSsch 07master:897805286913: avfilter/lut3d: assert on pixel format descriptor
[21:02:07 CEST] <ubitux> http://mziccard.me/2015/06/12/beats-detection-algorithms-2/
[21:02:11 CEST] <ubitux> still no one to implement that?
[21:02:51 CEST] <ubitux> that makes me think there is still this arbitrary FIR filter in my todo list...
[21:03:03 CEST] <ubitux> i haven't been very productive lately...
[21:06:20 CEST] <rcombs> >not a filter that detects overpriced headphones
[21:26:48 CEST] <Daan> Hey there! I wanna use FFMpeg in my C# application, how can I integrate it so that I can use it to execute a FFMpeg command? Thank you in advance!
[21:32:40 CEST] <Compn> i saw there was an ffmpeg csharp project
[21:32:46 CEST] <Compn> that probably what you want to use
[21:34:14 CEST] <Daan> Okay, where can I find it? :)
[21:37:40 CEST] <wm4> why is there a codec called "Brute Force & Ignorance"
[21:37:49 CEST] <wm4> (AV_CODEC_ID_BFI)
[21:39:20 CEST] <Compn> Daan : for c# in .net? https://github.com/hudl/HudlFfmpeg
[21:39:43 CEST] <Compn> Daan : or this http://sourceforge.net/projects/sharpffmpeg/
[21:41:02 CEST] <Daan> Compn : thank you very much! I'll try it!
[21:41:18 CEST] <Compn> Daan : or this http://sourceforge.net/projects/ffms2wrapper/
[21:41:26 CEST] <Compn> i'm really not sure which one is best , theres a bunch of them around
[21:42:01 CEST] <Daan> Compn : thank you! I'll try it!
[21:44:32 CEST] <BtbN> You don't usualy execute ffmpeg commands though
[21:45:00 CEST] <BtbN> If you use ffmpeg via api, you interface with the libav* libraries, which have their own api
[21:46:12 CEST] <JEEBsv> wtf
[21:46:18 CEST] <JEEBsv> why did someone make a wrapper around ffms2
[21:46:31 CEST] <JEEBsv> that was supposed to be an abstraction arond lavf-lavc to make it simple
[21:46:42 CEST] <cone-077> ffmpeg 03Michael Niedermayer 07master:a98d4d520750: avfilter/drawutils: Assert av_pix_fmt_desc_get() return value in ff_fill_line_with_color()
[21:47:04 CEST] <JEEBsv> oh, a derpy C# wrapper
[21:47:19 CEST] <Compn> all c# is derpy ? :P
[21:47:44 CEST] <Compn> BtbN : probably just wants to make c# frontend to ffmpeg
[21:48:05 CEST] <JEEBsv> uhh, http://sourceforge.net/p/ffms2wrapper/code/HEAD/tree/FFMS2%20Wrapper%20VideoSource.cs
[21:48:21 CEST] <JEEBsv> I might almost just say that one could just use ffms2 if the wrapper ends up being so short
[21:54:35 CEST] <cone-077> ffmpeg 03James Almer 07master:7912a6830d3a: avcodec/jpeg200dsp: add ff_ict_float_{sse,avx}
[21:54:36 CEST] <cone-077> ffmpeg 03James Almer 07master:9f815bc2c294: avcodec/jpeg200dsp: add ff_rct_int_{sse2,avx2}
[22:47:41 CEST] <cone-077> ffmpeg 03James Almer 07master:4aebaed0e17b: avformat/singlejpeg: fix standalone compilation
[00:00:00 CEST] --- Sun Jun 14 2015