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

[burek]

[00:51:00 CEST] <ac_slater_> hey all. This might not be the best place to ask but #ffmpeg is kinda dead today. Currently, I use `find_stream_info` on my clients to open RTSP and RTP streams. Does libavformat/codec provide a simple way to "pre-fill" some context(s) so that I dont have to use `find_stream_info`. I really only use ffmpeg/libavformat for demuxing, but it would be nice to pre-fill things
[00:52:26 CEST] <ac_slater_> oh dang, I just saw the topic. Disregard this question if it's too of topic
[00:53:37 CEST] <Compn> hehe
[00:53:53 CEST] <Compn> no idea
[00:53:58 CEST] <Compn> wait for someone that knows api
[00:57:28 CEST] <ac_slater_> find_stream_info is so crytic
[00:57:31 CEST] <ac_slater_> cryptic * 
[01:42:36 CEST] <cone-586> ffmpeg 03wm4 07master:74ea1167d91c: tls_gnutls: fix hang on disconnection
[01:42:37 CEST] <cone-586> ffmpeg 03Michael Niedermayer 07master:dd9400930a30: Merge commit '74ea1167d91ccb2e1f2943efa030f2c278b598be'
[01:50:47 CEST] <lglinskih> kierank: as I understand my test should open some test video, decode it and after that I should compare result-file of framecrc with some existing file. Is that right?
[01:51:06 CEST] <cone-586> ffmpeg 03Michael Niedermayer 07master:5ef578d03a55: avcodec/jpeg2000dec: Also include remaining length in "Block length" error message
[01:52:05 CEST] <kierank> lglinskih: yes some known framecrc
[01:52:06 CEST] <kierank> as in fate
[02:01:04 CEST] <lglinskih> And about framecrc: you told me that I should write my own, but I don't understand how should it differ from framecrcenc.c =/
[02:23:20 CEST] <lglinskih> kierank: And about framecrc: you told me that I should write my own, but I don't understand how should it differ from framecrcenc.c =/
[02:26:18 CEST] <kierank> it shouldnt' differ
[02:26:26 CEST] <kierank> but it's nice to have a totally independent test suite
[02:26:29 CEST] <kierank> it's not a big deal though
[02:44:04 CEST] <lglinskih> kierank: "totally independent" is about test suite for API?
[02:44:42 CEST] <kierank> it's nice to have a separate framecrc in the same way that it is nice to test decoders separately from ffmpeg.c
[02:44:55 CEST] <kierank> but in reality it's very unlikely that someone will break the framecrc code
[02:45:05 CEST] <lglinskih> =)
[02:45:26 CEST] <kierank> however it is likely that someone can break decoding from API but still works in ffmpeg.c
[02:48:18 CEST] <cone-586> ffmpeg 03Michael Niedermayer 07master:4bfdd967a6b2: avcodec/jpeg2000dec: Use <0 instead of != 0 for error checking
[02:48:19 CEST] <cone-586> ffmpeg 03Michael Niedermayer 07master:a58f1bcc4cbe: avcodec/jpeg2000dec: Skip SOP
[03:11:05 CEST] <cone-586> ffmpeg 03Michael Niedermayer 07master:5b0f55aab9d5: avcodec/jpeg2000dec: Check reslevelno in RPCL
[04:14:23 CEST] <kierank> michaelni: can you perhaps document that magic number?
[04:14:29 CEST] <kierank> and why you skip six
[05:55:47 CEST] <jamrial> kierank: apparently, FF91 = SoC marker. 0004 = lenght of marker. following two bytes = packet sequence number
[07:46:39 CEST] <ubitux> durandal_1707: first draft @ https://github.com/ubitux/FFmpeg/compare/selectivecolor
[07:46:53 CEST] <ubitux> i'll try to submit something this or next week
[10:34:49 CEST] <durandal_1707> news on the web page are still not updated
[12:35:38 CEST] <dockheas23> Hi, my name is George. I sent a mail to the mailing list last week mentioning that I'd like to try to learn about and make some contributions to the project. I think I may have found something that might be interesting to look into, and was wondering if I could ask a couple of questions about it?
[12:37:27 CEST] <dockheas23> I spent some time getting to grips with the testing system, and as part of that I think I may have found a bug in the flac encoding implementation.
[12:39:10 CEST] <dockheas23> Basically, I have a wav sample file that, when encoded and decoded, doesn't produce an exact match of the original, and decoding produces an "Invalid rice parameter" warning.
[12:41:14 CEST] <dockheas23> My first question is, should I raise this as a bug on trac?
[12:42:05 CEST] <dockheas23> And secondly, do you see any problem with me attempting to fix it?
[12:43:07 CEST] <durandal_1707> yes and no
[12:43:49 CEST] <durandal_1707> feel free to report and fix it
[12:43:52 CEST] <dockheas23> Great. Thank you!
[12:44:56 CEST] <cehoyos> dockheas23: Which version of FFmpeg did you test?
[12:45:21 CEST] <dockheas23> The latest commit on master (as of yesterday)
[12:45:36 CEST] <cehoyos> Could you point me to the wav file?
[12:45:43 CEST] <cehoyos> The issue definitely sounds important.
[12:45:53 CEST] <dockheas23> It also behaved the same on my Arch distribution's version.
[12:46:22 CEST] <dockheas23> It was a file I created myself, while messing around with some of the audio filters.
[12:46:29 CEST] <dockheas23> I can attach it to the bug report.
[12:46:56 CEST] <cehoyos> Please make it available (one way or other)!
[12:47:08 CEST] <dockheas23> Will do!
[13:15:18 CEST] <dockheas23> "trimmedchorus.wav" on ticket #4628 is the sample I've been working with.
[13:15:42 CEST] <cehoyos> Dockheas23: Please do not provide an excerpt of the console output, always provide the command line that allows to reproduce the issue together with the complete, uncut console output.
[13:16:31 CEST] <cehoyos> And generally, do not attach output files: There are many examples of tickets where this lead to immense confusion.
[13:22:19 CEST] <dockheas23> Ok, thanks. I'll add the console output to the ticket. Cannot see an option to remove that attachment, but I'll know next time!
[13:35:07 CEST] <cehoyos> Dockheas23: I have done the bisect: Will you look at the bug?
[13:40:21 CEST] <dockheas23> Yes, I'll give it a shot and, either way, I'll let you know how I'm getting on by the end of the day (c. 18:00 UTC+1).
[13:41:19 CEST] <cehoyos> Don't worry, the question was just if someone should send an email to Reimar right now.
[13:42:54 CEST] <cone-822> ffmpeg 03Michael Niedermayer 07master:9ba5fe7f3d9f: avcodec/jpeg2000dec: Remove redundant check
[13:42:54 CEST] <cone-822> ffmpeg 03Michael Niedermayer 07master:4ec14ce121df: avcodec/jpeg2000dec: Improve readability of SOP check
[13:43:30 CEST] <dockheas23> @cehoyes: Ok, will I email him?
[13:44:22 CEST] <cehoyos> Not if you can fix the issue...
[13:50:14 CEST] <cehoyos> michaelni: I tested file5.jp2 from the reference files and it decodes bitexact wrt jasper and (a version of) libopenjpeg but the image looks different (too dark) compared to the reference outpu tjp2_5.tif 
[13:50:22 CEST] <cehoyos> jasper shows the following warning:
[13:50:49 CEST] <cehoyos> ICC Profile CS 52474220 warning: inaccurate color
[13:51:23 CEST] <cehoyos> Is there a missing feature in FFmpeg (and the other j2k decoders) or is this impossible (or is the reference output wrong)?
[13:51:42 CEST] <cehoyos> impossible to get the same output as the reference tif image.
[13:53:53 CEST] <cehoyos> jasper shows the same warning for file7.jp2 which looks ugly with FFmpeg but since it is yuv420p and the tif reference (that looks not ugly this way) is rgb, so I guess it is difficult to get bitexact output.
[13:53:55 CEST] <wm4> does jasper apply icc profiles?
[13:54:02 CEST] <cehoyos> I guess not.
[13:54:17 CEST] <dockheas23> Ok, now I understand! Given some time I'm sure I can get to the bottom of it, but I cannot say just yet that I know exactly what's wrong. I was going to use it as an opportunity to get familiar with the code/algorithm. But, if you consider this to be an important bug that should be fixed asap, then it's probably best to send it to someone who already knows it well.
[13:54:20 CEST] <cehoyos> (It is bitexact with FFmpeg, not with the reference and it prints a warning)
[13:56:10 CEST] <cehoyos> dockheas23: Note that further tests with the flac encoder and decoder (I guess you could revert the offending patch locally) are very welcome!
[13:56:39 CEST] <cehoyos> Ideally, they should include a second decoding pass with flac: We have recently fixed such an issue but others may exist.
[13:57:00 CEST] <cehoyos> We have recently fixed an issue where FFmpeg could decode its own files but flac could not.
[14:00:38 CEST] <dockheas23> Ok, I can do that. Just to clarify, do you mean tests involving the Xiph flac implementation? And if so, do you mean incorporating them into the fate test suite?
[14:04:12 CEST] <cehoyos> No, no new tests for fate: But since you have done tests with flac already, I wanted to suggest something similar. This was assuming you used a script to find the issue you reported.
[14:04:38 CEST] <cehoyos> But since the offending patch cannot be easily reverted, my idea was probably not a good one.
[14:05:01 CEST] <dockheas23> Yeah, I just tried a revert there and it wasn't too pretty
[14:05:54 CEST] <cehoyos> I still don't know what parts of FFmpeg you have already worked with...
[14:06:52 CEST] <cehoyos> Or what parts you are particularly interested in and / or have some knowledge about the subject.
[14:21:04 CEST] <dockheas23> In terms of the code, I have not worked on any of it before. My idea was to begin by trying to write some tests to build up some knowledge about it, which was how I came across this bug. In terms of my interest, I have a general interest in media encoding, and container formats in particular, but not a whole lot of knowledge yet. I'd like to improve that.
[14:29:32 CEST] <kierank> you could work with ludmila on the api test suite
[14:34:59 CEST] <dockheas23> That sounds good.
[14:36:37 CEST] <dockheas23> How would I go about getting started on it?
[14:52:52 CEST] <kierank> dockheas23: erm
[14:52:57 CEST] <kierank> have a look at "make fate"
[14:53:17 CEST] <kierank> basically at the moment all the tests are based on ffmpeg.c
[14:53:24 CEST] <kierank> but that doesn't test API users 
[14:53:34 CEST] <kierank> and it happens sometimes that API users have bugs that aren't covered in ffmpeg.c
[15:01:35 CEST] <dockheas23> Ok, thanks. How about I drop ludmila an email about it?
[15:07:01 CEST] <kierank> yes and cc me in
[15:07:04 CEST] <kierank> kierank at obe.tv
[15:07:50 CEST] <dockheas23> Will do, thanks. Do you have an email for Ludmila?
[15:09:08 CEST] <kierank> lglinskih at gmail.com
[15:09:28 CEST] <dockheas23> Great. Thanks a lot!
[16:10:49 CEST] <Compn> >gstreamer bugs
[18:20:02 CEST] <BBB> Daemon404: poke
[18:20:06 CEST] <Daemon404> ?
[18:20:34 CEST] <BBB> I saw this one a while ago: http://www.mesclado.com/smpte-forum-2015-future-proofing-media-production-part-3/?lang=en
[18:20:51 CEST] <Daemon404> i assure you i do not think SMPTE is anything usefil
[18:20:56 CEST] <BBB> so youre quoted as saying hevc needs to improve, Im assuming you mean s/hevc/x265/, right? (or any encoder, for that matter)
[18:21:01 CEST] <Daemon404> yes
[18:21:10 CEST] <Daemon404> "quoted"
[18:21:13 CEST] <Daemon404> paraphrased.
[18:21:13 CEST] <BBB> can you define improve? is it just speed of encoding?
[18:21:21 CEST] <BBB> (and degradation of quality for improvement of speed)
[18:21:26 CEST] <BBB> or something else also?
[18:21:32 CEST] <nevcairiel> i find it funny that Daemon404 is somehow the SMTPE guy around here now =p
[18:21:43 CEST] <BBB> (Im just making sure I got your quote correct if I decide to quote your quote)
[18:21:49 CEST] <Daemon404> x265 placebo only ties or marginally beats x264 if at all
[18:21:55 CEST] <Daemon404> for an order of magnitude slower encoding
[18:22:01 CEST] <Daemon404> and its the best of a bad showing
[18:22:22 CEST] <Daemon404> nevcairiel, BBB's former coworker asked me to show up.
[18:22:24 CEST] <Daemon404> and they paid.
[18:22:58 CEST] <nevcairiel> BBB: from my own experience, if you try to compress visually lossless at decent bitrates, the differences between h264 and h265 are very slim, only if you start going down in bitrate and accept loss to some extent, h265 eventually gets better .. so personally, I think they could also do better in high quality scenarios
[18:23:16 CEST] <nevcairiel> s/h265/x265/
[18:23:19 CEST] <Daemon404> x265 is actually worse at transparent bitrates.
[18:23:25 CEST] <nevcairiel> and x265 is much slower in the process
[18:28:30 CEST] <BBB> ok will quote as such
[18:31:25 CEST] <cone-822> ffmpeg 03Michael Niedermayer 07master:021351f246b1: avcodec/mqcdec: set raw flag at the begin of ff_mqc_initdec()
[18:31:26 CEST] <cone-822> ffmpeg 03Michael Niedermayer 07master:96bbbebaf951: avcodec/jpeg2000dec: Fix Vertically causal context formation
[18:38:51 CEST] <cone-822> ffmpeg 03Andreas Cadhalpun 07master:fdc64a104410: h264: er: Copy from the previous reference only if compatible
[18:38:53 CEST] <cone-822> ffmpeg 03Andreas Cadhalpun 07master:dd6c8575dbc8: examples/demuxing_decoding: use properties from frame instead of video_dec_ctx
[19:25:19 CEST] <cone-822> ffmpeg 03Paul B Mahol 07master:d107413f1caf: doc/filters: add one more compand example found in the wild
[20:44:54 CEST] <wm4> ==5942== Use of uninitialised value of size 4
[20:44:55 CEST] <wm4> ==5942==    at 0x4A6E16E: av_crc (crc.c:370)
[20:44:55 CEST] <wm4> ==5942==    by 0x5C4F7CB: ff_crcA001_update (aviobuf.c:506)
[20:44:57 CEST] <wm4> huh
[20:45:12 CEST] <wm4> (from mp3_read_packet)
[21:04:50 CEST] <cone-822> ffmpeg 03Michael Niedermayer 07master:2819aeb0f3c2: avcodec/jpeg2000dec: Omit mqc reinit after the last pass
[21:10:42 CEST] <cone-822> ffmpeg 03James Zern 07master:8ce321f0aaa9: encoders.texi: update libvpx documentation
[21:29:58 CEST] <cone-822> ffmpeg 03Vittorio Giovara 07master:07b2db81d06e: riff: Add MNM4 FourCC as mpeg4
[21:29:59 CEST] <cone-822> ffmpeg 03Michael Niedermayer 07master:c5fc48fdfb76: Merge commit '07b2db81d06e1cd6b1718d3e2dd7a42e8bccf8c0'
[21:37:22 CEST] <cone-822> ffmpeg 03James Zern 07master:e6c71385f001: libvpxenc: cosmetics: reindent after 2c70436
[21:37:23 CEST] <cone-822> ffmpeg 03James Zern 07master:a829040c431a: libvpxenc: remove stray '\'s
[21:51:41 CEST] <cone-822> ffmpeg 03Luca Barbato 07master:24ad3ac6a3e2: nut: Drop doxygen markers
[21:51:42 CEST] <cone-822> ffmpeg 03Michael Niedermayer 07master:efcf8cfa48c8: Merge commit '24ad3ac6a3e20350214e6c3f7a931635f264ae07'
[22:10:32 CEST] <cone-822> ffmpeg 03Luca Barbato 07master:03ca6d70df19: x264: Factor out the reconfiguration code
[22:10:33 CEST] <cone-822> ffmpeg 03Michael Niedermayer 07master:4ed3a01d717f: Merge commit '03ca6d70df192125a772dadd01acfe3905aa653f'
[22:29:31 CEST] <cone-822> ffmpeg 03Luca Barbato 07master:9af7e8045e3e: lavc: Clarify the behaviour of dimension and format context fields
[22:29:32 CEST] <cone-822> ffmpeg 03Michael Niedermayer 07master:20526f2e2f58: Merge commit '9af7e8045e3e63ab39adedae9a7c11b1c410af26'
[22:40:31 CEST] <cone-822> ffmpeg 03Andreas Cadhalpun 07master:a4fbd55d6e03: h264: er: Copy from the previous reference only if compatible
[22:40:33 CEST] <cone-822> ffmpeg 03Michael Niedermayer 07master:12e36a3dfdc6: Merge commit 'a4fbd55d6e03eabdbecc3b7892ec09eb8062d066'
[23:08:27 CEST] <anoop_r> how to disable help in ffmpeg.exe
[23:13:52 CEST] <kierank> ahahaha
[23:16:39 CEST] <anoop_r> like ffmpeg -h shows command line help i want to disable it
[23:18:02 CEST] <cone-822> ffmpeg 03Paul B Mahol 07master:eb85060b84d8: avfilter/af_afade: add couple of more curves
[23:27:55 CEST] <cone-822> ffmpeg 03Michael Niedermayer 07master:fefe04259ae9: avcodec/jpeg2000dec: increase tile part limit to 32
[23:34:25 CEST] <anoop_r> how to disable help in ffmpeg.exe
[00:00:00 CEST] --- Tue Jun 16 2015