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

Thu Jul 2 02:05:02 CEST 2015

[00:00:00 CEST] <lglinskih_> kierank, wm4: comparing crcs of a frames will work, right? I can make manually few reference files.
[00:00:29 CEST] <wm4> nevcairiel: posts gsoc http patches
[00:00:34 CEST] <nevcairiel> oh a gsoc guy
[00:00:41 CEST] <llogan> ^ klaxa 
[00:00:42 CEST] <nevcairiel> he did post them using send-email on the devel mail once before
[00:00:47 CEST] <wm4> lglinskih_: yeah, I guess so
[00:01:00 CEST] <kierank> lglinskih_: yes but it's not really clear how you would know whether the seeking worked to begin with
[00:01:28 CEST] <klaxa> wm4: sorry, i was told i can either send them with git-send-email or as attached git format-patch patches
[00:01:46 CEST] <wm4> klaxa: I think it makes it pretty hard to read and review them
[00:01:48 CEST] <klaxa> i don't know how to reply to emails with git send-email, is there an easy way to do that?
[00:01:56 CEST] <wm4> klaxa: and git send-email should be more convenient to you too
[00:02:02 CEST] <wm4> ah
[00:02:03 CEST] <klaxa> i would very much like to do it like that
[00:02:30 CEST] <wm4> you can use --in-reply-to= and the id of the mail you want to reply - dunno if there's a more convenient way
[00:02:56 CEST] <nevcairiel> yeah replying with a fixed up patch is a bit inconvenient, but shrug
[00:03:10 CEST] <klaxa> where do i get the id from? unfortunately i'm using the gmail webclient
[00:03:15 CEST] <wm4> making a new thread is fine too, as long as you don't post 10 per day
[00:03:35 CEST] <nevcairiel> id is in the headers, look at show original or something in the gmail web
[00:03:58 CEST] <klaxa> okay, i will try that in the future, thanks for telling me!
[00:05:38 CEST] <lglinskih_> kierank: I'm sorry, I don't understand(
[00:06:04 CEST] <kierank> lglinskih_: For example if the seeking produced a green frame (i.e broken) you wouldn't be able to tell with a crc
[00:06:15 CEST] <kierank> but it's not a big problem right now
[00:06:47 CEST] <nevcairiel> (note that broken frames in ffmpeg are mostly gray)
[00:07:03 CEST] <wm4> lglinskih_: what we might want to do is comparing the same frames produced after different seeks
[00:07:28 CEST] <wm4> actually, we definitely want to do this
[00:09:06 CEST] <lglinskih_> kierank, wm4: I can start with calculation crcs of all frames in file without seeking. And after that reopen file and make a lot of different seeking=)
[00:09:18 CEST] <kierank> yes good idea 
[00:10:40 CEST] <wm4> yep, great idea
[00:11:27 CEST] <lglinskih_> thx ^_^
[00:35:28 CEST] <cone-342> ffmpeg 03Andreas Cadhalpun 07master:32a5b631267e: pthread_frame: forward error codes when flushing
[00:35:29 CEST] <cone-342> ffmpeg 03Andreas Cadhalpun 07master:cd64ead8d96b: ffmpeg: exit_on_error if decoding a packet failed
[00:35:30 CEST] <cone-342> ffmpeg 03Andreas Cadhalpun 07master:bd0f14123fd8: ffmpeg: only count got_output/errors in decode_error_stat
[01:01:47 CEST] <cone-342> ffmpeg 03rogerdpack 07master:4ebb43f19c41: ffmpeg: windows: respond to logoff and ctrl+break messages as well
[02:35:07 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:79a98294da6c: avcodec/aacsbr: check that the element type matches before applying SBR
[02:35:08 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:2e13a45b1a9a: avcodec/aacsbr: Assert that bs_num_env is positive
[02:39:47 CEST] <Compn> carl : think we should close this? http://trac.ffmpeg.org/ticket/1870
[03:12:21 CEST] <Compn> http://trac.ffmpeg.org/ticket/3352 this one still a problem ?
[03:14:18 CEST] <cone-342> ffmpeg 03Martin Storsjö 07master:e2bd03a14a4e: fate: Avoid unnecessary pixel format conversions
[03:14:19 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:3974889614e0: Merge commit 'e2bd03a14a4e3366df0b1ee8e284a97165be1f3c'
[03:20:57 CEST] <Compn> carl : maybe close this one as theres only one or two samples?, http://trac.ffmpeg.org/ticket/3077
[03:36:32 CEST] <cone-342> ffmpeg 03Kostya Shishkov 07master:08c2d8f0aa67: Go2Meeting decoder
[03:36:33 CEST] <cone-342> ffmpeg 03Diego Biurrun 07master:4d1229dabf7a: g2meet: Add FATE tests for all three G2M variants
[03:36:34 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:68939f7682de: Merge commit '08c2d8f0aa679c2f060721d1d0d4f33d2ae32368'
[03:36:35 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:9e93e544dc2e: Merge commit '4d1229dabf7a7e3b6a7b326afd79102256c3b008'
[03:49:59 CEST] <cone-342> ffmpeg 03Vittorio Giovara 07master:3f872c9bfa8e: lavc: Add missing API guard to dtg_active_format option
[03:50:00 CEST] <cone-342> ffmpeg 03Vittorio Giovara 07master:0f87f9b4fcee: lavd: Add library identifier
[03:50:01 CEST] <cone-342> ffmpeg 03Vittorio Giovara 07master:0d449c81b3dd: lavfi: Add library identifier
[03:50:02 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:16dd0426e568: Merge commit '3f872c9bfa8ee1032058cfa48068b5a73ef27b5e'
[03:50:03 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:818ff7ff5a19: Merge commit '0f87f9b4fceee854f09da2d1ef329245196775f8'
[03:50:04 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:9c010ba66800: Merge commit '0d449c81b3dd25835ae6ac849cdd150f35b9c5c6'
[04:05:55 CEST] <cone-342> ffmpeg 03Vittorio Giovara 07master:df22e30172b0: dump: Use the correct abs() version
[04:05:56 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:a8e137a32286: Merge commit 'df22e30172b09cda4d6f7d4f43508284be65848a'
[04:13:19 CEST] <cone-342> ffmpeg 03Vittorio Giovara 07master:2eef75fd7e1a: mov: Adjust variable types to fix format warnings
[04:13:20 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:35c8dda5c2db: Merge commit '2eef75fd7e1ac96ab9ca63bb4523078c908bc9b1'
[04:22:57 CEST] <chocoladedevelop> I'm using c# with ffmpeg and pipes and i'm pushing frames and create in real time compressed mp4 video file.
[04:23:08 CEST] <chocoladedevelop> The problem is that after few seconds the ffmpeg.exe memory usage is raising to over 1GB of memory and the hard disk raise up to over 53MB/s
[04:23:17 CEST] <chocoladedevelop> Is that a known problem ?
[04:23:22 CEST] <cone-342> ffmpeg 03Vittorio Giovara 07master:a1e2caa93e4f: mov: Log format rather than fourcc in stsd in trace mode
[04:23:23 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:55a04a5d7a90: Merge commit 'a1e2caa93e4f8102666a21222f01b74838b6497f'
[04:25:12 CEST] <chocoladedevelop> I posted my code in csharp in the ffmpeg forum here: http://ffmpeg.gusari.org/viewtopic.php?f=11&t=2204 and also here: http://stackoverflow.com/questions/31149752/why-when-using-ffmpeg-to-create-video-file-in-real-time-the-ffmpeg-exe-take-over
[04:37:12 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:dec728888f88: avcodec/elsdec: Remove EOVERFLOW
[04:48:47 CEST] <Compn> chocoladedevelop : sounds like bug
[04:48:58 CEST] <Compn> memleak somewhere ?
[05:11:33 CEST] <chocoladedevelop> BUG IN FFMPEG.EXE OR IN MY CSHARO CODE ?
[05:11:39 CEST] <chocoladedevelop> oops sorry for caps
[05:11:53 CEST] <chocoladedevelop> csharo = csharp
[05:12:50 CEST] <chocoladedevelop> cant figure out i didn't find in my code any mem leak. Maybe someone can look at the links i provided to see my code.
[05:23:46 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:8750aef3d65c: ffmpeg_opt: Fix forcing fourccs
[10:04:55 CEST] <wm4> so the libswresample docs claim that e.g. lfe_mix_level is in db
[10:05:14 CEST] <wm4> but it actually seems to be linear?
[12:02:00 CEST] <wm4> sometimes I feel like michaelni intentionally adds this kind of code http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/utils.c;h=0b765ed0defb0d41de87b77c16a1e97c2eccf8c9;hb=HEAD#l39 to give Libav a point that there is insane code in FFmpeg that isn't in Libav
[12:02:06 CEST] <wm4> or maybe I'm just becoming paranoid
[12:03:06 CEST] <wm4> j-b: so when will you fork ffmpeg
[12:08:45 CEST] <ubitux> i'm pretty sure it helps triggering real case issue
[12:08:53 CEST] <ubitux> typically while doing merges
[12:09:15 CEST] <wm4> bullshit argument
[12:09:29 CEST] <ubitux> ?
[12:09:52 CEST] <wm4> there are so many potential ABI issues that could happen, and you test one of the least important/easiest to detect ones
[12:09:53 CEST] <ubitux> also any contributor trying to insert a pix fmt in the middle or something
[12:10:10 CEST] <wm4> also source code shouldn't contain safeguards for stuff that could happen due to merges
[12:10:14 CEST] <wm4> ...
[12:10:21 CEST] <wm4> BULLSHIT
[12:10:54 CEST] <wm4> why doesn't it check whether you add a field to AVCodecContext?
[12:11:01 CEST] <j-b> wm4: depends. Do you join, if I do?
[12:11:03 CEST] <wm4> why doesn't it check whether a function changes its signature?
[12:11:35 CEST] <wm4> j-b: sure I would, but most likely I wouldn't be able to spend much effort to do all the work that it'll require
[12:12:06 CEST] <ubitux> are these safeguard causing any problem to you?
[12:14:38 CEST] <wm4> ubitux: yes
[12:15:57 CEST] <wm4> many why is there suddenly a huge patch set against the old ASF demuxer by someone I've never seen before
[12:16:24 CEST] <wm4> how does anyone in here manage not to go mental?
[12:16:47 CEST] <nevcairiel> you get annoyed because some weirdo posts a patch set?
[12:17:01 CEST] <nevcairiel> looks like the majority is for the muxer though
[12:17:17 CEST] <nevcairiel> and 90% of the patch is unrelated crap changes
[12:17:29 CEST] <wm4> oh, it's mainly a ASF muxing thing
[12:19:19 CEST] <wm4> maybe software development is a too stressful endeavor for me and I should just become a gardener or something
[13:08:58 CEST] <Compn> wm4 : gardening is pretty stressful, i have a groundhog that is eating everything in my garden. all of my sunflowers!
[13:09:32 CEST] <wm4> unlike with software developers, you can just kill the groundhog
[13:11:00 CEST] <Compn> aww but hes so cute and fuzzy wuzzy :(
[13:11:09 CEST] <Compn> also whoever this asf patch guy is hes using msys git...
[13:11:25 CEST] <Compn> a vindows users.
[13:11:26 CEST] <Compn> -s
[13:40:02 CEST] <durandal_170> michaelni: I triggered assert in nutdec line 1331
[13:42:45 CEST] <durandal_170> I used cat to concatenate 2 nuts with single raw yuvs
[13:43:37 CEST] <michaelni> durandal_170, how can i reproduce ?
[13:46:19 CEST] <durandal_170> you must use cat and pipe
[13:47:22 CEST] <durandal_170> cat 1st.nut 2nd.nut ¦ ffplay -
[13:48:31 CEST] <durandal_170> and its line 1301
[13:51:17 CEST] <michaelni> tried random rawvideo in nut but seems not triggering te assert
[13:53:34 CEST] <durandal_170> did you used pipe and cat with ffplay?
[13:56:38 CEST] <durandal_1707> michaelni: ffmpeg -f lavfi -i testsrc -pix_fmt yuv420p -c:v rawvideo -frames 1 /tmp/1.nut
[13:56:42 CEST] <durandal_1707> michaelni: ffmpeg -f lavfi -i testsrc -pix_fmt yuv420p -c:v rawvideo -frames 1 /tmp/2.nut
[13:57:05 CEST] <durandal_1707> michaelni: cat /tmp/1.nut /tmp/2.nut | ffplay -
[13:57:14 CEST] <durandal_1707> michaelni: seek back with left arrow
[13:58:02 CEST] <michaelni> durandal_170, thanks
[14:03:01 CEST] <cbsrobot_> durandal_170: still looking for new filters to implement? see http://shenidam.org/
[14:09:38 CEST] <Compn> auto sync ?
[14:12:23 CEST] <cbsrobot_> yeah - similar to pluraleyes
[14:38:16 CEST] <cone-302> ffmpeg 03Michael Niedermayer 07master:2f8c81637c47: avformat/matroskadec: Fix undefined shift in read_sint()
[14:38:17 CEST] <cone-302> ffmpeg 03Michael Niedermayer 07master:56fd4705c049: avcodec/motion_est_template: Fix undefined shifts in CHECK_MV_DIR()
[14:38:18 CEST] <cone-302> ffmpeg 03Michael Niedermayer 07master:0ea099ad3e6d: avcodec/mpegvideo_enc: fix undefined shifts in ff_dct_quantize_c()
[14:38:19 CEST] <cone-302> ffmpeg 03Michael Niedermayer 07master:4eee685a212a: avcodec/motion_est: Fix undefined shifts in cmp_inline()
[14:38:20 CEST] <cone-302> ffmpeg 03Michael Niedermayer 07master:60ec3007e69c: avformat/nutdec: Check ff_gen_search() for failure
[14:38:34 CEST] <michaelni> durandal_170, fixed
[14:55:59 CEST] <cone-302> ffmpeg 03Vadim Belov 07master:db64af639559: avformat/concatdec: copy stream metadata when using concat
[15:12:12 CEST] <cone-302> ffmpeg 03wm4 07master:f91126643a91: lavu: add an API function to return the FFmpeg version string
[15:53:48 CEST] <cone-302> ffmpeg 03Michael Niedermayer 07master:ac78014f0b1f: avcodec/motion_est: Fix some undefined shifts
[15:53:49 CEST] <cone-302> ffmpeg 03Michael Niedermayer 07master:53fd70579bc2: avcodec/h264_mvpred: Fix undefined shifts in MAP_F2F
[17:04:27 CEST] <durandal_170> stop bloating lavu
[17:29:09 CEST] <Zeranoe> Holy cow FFmpeg struggles to play this https://dl.dropboxusercontent.com/u/30310240/flourish.mid 
[17:34:52 CEST] <wm4> well that's a midi file?
[17:39:43 CEST] <Compn> yeah midi
[17:41:37 CEST] <j-b> WTF is Extended ASF functionality
[17:41:43 CEST] <Compn> lol
[17:42:02 CEST] <philipl> "We extended the functionality. Pray we don't extend it again."
[17:42:14 CEST] <j-b> why does it require 3 new headers file?
[17:43:28 CEST] <Compn> there must be millions of weird patches for ffmpeg floating out there
[17:48:42 CEST] <Compn> wonder if the virtualdub asf demuxer was any good
[17:48:52 CEST] <Compn> or if that was asf muxer only ? mhm
[17:50:19 CEST] <Compn> curious why people didnt adopt jp2k instead of ffv1 :P
[17:50:43 CEST] <Compn> nice to see open source ffv1 take over though
[18:05:04 CEST] <cone-394> ffmpeg 03Shivraj Patil 07master:2eb28e889d9c: avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for mpegvideo functions
[18:05:17 CEST] <rcombs> is Benoit Fouet around on IRC?
[18:06:48 CEST] <rcombs> Zeranoe: AFAIK it doesn't play at all? I'm not aware of ffmpeg having a MIDI demuxer or decoder
[18:07:11 CEST] <Zeranoe> rcombs: it tried, and sounded quite interesting to say the least
[18:07:38 CEST] <rcombs> I also tried, and just got AVERROR_INVALIDDATA
[18:08:14 CEST] <Zeranoe> rcombs: with a recent build?
[18:08:53 CEST] Action: rcombs git pull
[18:10:31 CEST] <nevcairiel> decoding  MIDI is annoying, as you need a synth bank
[18:10:39 CEST] <c_14> Probably libmodplug?
[18:10:51 CEST] <nevcairiel> oh yeah we have a library that can do it
[18:12:20 CEST] <nevcairiel> not sure what kind of formats it supports however
[18:13:20 CEST] <jamrial> somebody sent a huge patch for the old asf demuxer
[18:13:29 CEST] <jamrial> no end in sight for this whole debate, haha
[18:13:58 CEST] <nevcairiel> that huge patch is full of crap as well
[18:17:03 CEST] <nevcairiel> he also doesnt specify at all what it does
[18:19:09 CEST] <rcombs> it enhances the support, duh
[18:30:11 CEST] <philipl> who wouldn't want enhanced support?
[18:38:10 CEST] <Daemon404> [17:13] < jamrial> somebody sent a huge patch for the old asf demuxer <-- and i dont even know what it does
[18:38:15 CEST] <Daemon404> "extend asf"
[18:38:17 CEST] <Daemon404> yeah ok..
[18:38:24 CEST] <Daemon404> (too lazy to read. probably metadata)
[18:38:25 CEST] <rcombs> oh, "extends"
[18:39:00 CEST] <nevcairiel> i immediately went "wat, this patch is broken" when i saw what it all changed, without even wondering what its supposed to do
[18:56:41 CEST] <cone-394> ffmpeg 03John Adlum 07master:089a818bd3cd: avcodec/pthread_frame: Correcting typo of "occurred"
[18:56:42 CEST] <cone-394> ffmpeg 03John Adlum 07master:28206b75e81c: avformat/asfdec_f: Correct skip to key code
[18:56:43 CEST] <cone-394> ffmpeg 03John Adlum 07master:811008b8eeaa: avformat/asfdec_f: Assert that packet positions match in asf_read_pts()
[19:09:15 CEST] <cone-394> ffmpeg 03Janne Grunau 07master:007e27d363ba: avcodec: add missing CODEC_CAP_DR1 to codecs using get_buffer()
[19:09:16 CEST] <cone-394> ffmpeg 03Michael Niedermayer 07master:9cf95654ac90: Merge commit '007e27d363ba7d994019dc897dc9c39071bb204a'
[19:17:52 CEST] <cone-394> ffmpeg 03Janne Grunau 07master:4ccccd6c40a6: g2meet: use an unsigned type for the djb hash
[19:17:53 CEST] <cone-394> ffmpeg 03Janne Grunau 07master:9eec23b8a7fd: g2meet: use av_ceil_log2 instead of a custom function
[19:17:54 CEST] <cone-394> ffmpeg 03Michael Niedermayer 07master:92c858ae667a: Merge commit '4ccccd6c40a6d0ce85e96a6e37f558236e2a6a75'
[19:17:55 CEST] <cone-394> ffmpeg 03Michael Niedermayer 07master:6205143bb3fe: Merge commit '9eec23b8a7fd0f91827bbc3ed0792c39a8cc9a8a'
[19:20:17 CEST] <cone-394> ffmpeg 03Paul B Mahol 07master:be35b8b9a9fb: avfilter/vf_extractplanes: support more pixel formats
[19:20:18 CEST] <cone-394> ffmpeg 03Paul B Mahol 07master:fc40cdbf4904: avfilter/vf_extractplanes: rename misleading variable
[19:20:19 CEST] <cone-394> ffmpeg 03Paul B Mahol 07master:17e6d7b4008f: avfilter/vf_extractplanes: use faster path for input formats with only one component
[19:36:40 CEST] <BBB> durandal_170: ?
[19:37:00 CEST] <BBB> oh the version string
[19:37:04 CEST] <BBB> thats a few bytes
[19:38:13 CEST] <durandal_170> but each time need to recompile whole tree
[19:43:39 CEST] <BBB> get a faster computer :-p
[19:43:50 CEST] <BBB> (ok I admit I get annoyed every time that happens)
[19:43:55 CEST] <BBB> (so I just end up updating less often)
[19:46:57 CEST] <cone-394> ffmpeg 03Janne Grunau 07master:f91fe24e9bd6: g2meet: force simple idct for identical results over all fate configs
[19:46:57 CEST] <cone-394> ffmpeg 03Michael Niedermayer 07master:5142963b7d93: Merge commit 'f91fe24e9bd6912c29bbb03d8afe878e045f9721'
[19:52:59 CEST] <wm4> michaelni: Libav wants av_version_info() instead of avutil_version_info(); would you agree to delete the old new symbol and replace it with the one with the new name?
[19:53:47 CEST] <lglinskih_> Is pkt.pts a good parameter as a timestamp to seek with avformat_seek_file?
[19:54:44 CEST] <cone-394> ffmpeg 03Michael Niedermayer 07master:4e0819310e2d: elsdec: Replace EOVERFLOW with INVALIDDATA
[19:54:45 CEST] <cone-394> ffmpeg 03Michael Niedermayer 07master:f8e038f9a07d: Merge commit '4e0819310e2d2eff60be2d6df28335f0739712b9'
[19:56:12 CEST] <wm4> lglinskih_: that's not really clear
[19:56:24 CEST] <wm4> in most situations, it probably is
[19:56:53 CEST] <michaelni> it might make sense to add similar functions to the other libs, user apps might want to know if they are grossly mismatching each other
[19:57:12 CEST] <wm4> michaelni: no, they can use the integer version number functions
[19:58:51 CEST] <michaelni> honestly i think the name as it is is better as it really described the revission from which avutil is build not neccessarily the one from all or the other libs but i dont really care much if you prefer to rename it
[20:00:00 CEST] <wm4> then we'll rename
[20:10:32 CEST] <lglinskih_> wm4: when I set min_ts and max_ts like this avformat_seek_file(fmt_ctx, str_index, pts, pts, pts, AVSEEK_FLAG_ANY) it seeks to a frame with bigger pts. 
[20:10:39 CEST] <lglinskih_> is it normal?
[20:11:34 CEST] <wm4> probably
[20:11:39 CEST] <wm4> note that there are 2 seek APIs
[20:11:46 CEST] <iive> what does av_version_info()  return?
[20:11:50 CEST] <wm4> and I think avformat_seek_file() is the worse one
[20:12:41 CEST] <lglinskih_> but its value is out of the interval!
[20:12:46 CEST] <iive> imho, such function should return the release number. e.g. (ffmpeg) 2.7.1 
[20:13:05 CEST] <jamrial> iive: it does when you build any of the release branches afaik
[20:14:01 CEST] <iive> then what does avutil_* one returns? the same or api version?
[20:15:11 CEST] <nevcairiel> wm4: internally the APIs work mostly the same way, they just have different semantic
[20:15:32 CEST] <nevcairiel> the new seeking methods were never implemented
[20:16:19 CEST] <jamrial> iive: actually there's only one, and it's avutil_version_info
[20:17:26 CEST] <iive> does it return the same info release/git_hash?
[20:19:16 CEST] <jamrial> it returns what i said above. for example n2.7.1 when you compile the tagged release, n2.7.1-x-g****** when you compile newer commits from the same release branch, N-xxxxx-g****** for master branch
[20:20:08 CEST] <durandal_170> do we have reviewers? 
[20:20:14 CEST] <jamrial> see the stuff under "rev" in http://fate.ffmpeg.org/, that's supposedly what it will return
[20:20:15 CEST] <lglinskih_> wm4: do you mean I should use av_seek_frame? 
[20:58:38 CEST] <cone-394> ffmpeg 03Michael Niedermayer 07master:ce81e47c911f: avcodec/mss2: Fix integer overflow
[20:58:39 CEST] <cone-394> ffmpeg 03Michael Niedermayer 07master:06a0d5ef5ce3: avcodec/h264dsp_template: Fix undefined shifts
[21:11:21 CEST] <durandal_170> working on libswscale can be fun
[21:39:31 CEST] <anoop_r> does ffmpeg encodes audio and video simultaniously
[21:39:47 CEST] <BBB> in the same process? yes
[21:41:39 CEST] <anoop_r> so while encoding some media files ffmpeg takes more time even if all frames are encoded
[21:41:43 CEST] <anoop_r> why
[21:45:26 CEST] <BBB> I dont understand the question
[21:45:44 CEST] <BBB> when you compare something (more time), you need to say what youre comparing to what (what takes more time to encode than what)
[21:46:52 CEST] <anoop_r> suppose the sample media have 300 frames
[21:47:39 CEST] <anoop_r> the progress shows frame=300 but i have to wait for at least 10 or 20 seconds to complete the process
[21:49:00 CEST] <BBB> its the input frame counter
[21:49:12 CEST] <BBB> so imagine that I have an encoder that queues frames internally
[21:49:15 CEST] <BBB> if I input 300 frames
[21:49:18 CEST] <BBB> theyre not all done yet
[21:49:24 CEST] <BBB> ffmpeg doesnt know this
[21:49:33 CEST] <anoop_r> it's not the progress bar
[21:49:35 CEST] <BBB> what are you encoding?
[21:49:49 CEST] <BBB> Im not talking about ffmpegs queue, Im taking about the encoder queue
[21:49:54 CEST] <BBB> encoders typically have an internal delay
[21:49:58 CEST] <BBB> this is for rate control purposes etc.
[21:50:07 CEST] <BBB> its quite common
[21:50:16 CEST] <anoop_r> i am using x265
[21:50:27 CEST] <BBB> and so even if ffmpeg gave the encoder 300 frames, the encoder is still processing some of these 300 frames internally
[21:50:41 CEST] <anoop_r> ok
[21:50:46 CEST] <BBB> so its expected
[21:50:53 CEST] <anoop_r> anyway to show real progress
[22:02:26 CEST] <cone-394> ffmpeg 03Rodger Combs 07master:c190fdf65de8: lavu: Makefile: skip atomic.c if native atomics are available
[22:04:20 CEST] <cone-394> ffmpeg 03Paul B Mahol 07master:5165c600ebea: avformat/rtmpproto: increase hardcoded url/path lengths
[22:36:08 CEST] <philipl> BtbN: blarghly argle.
[22:36:45 CEST] <philipl> the nvenc 444p mode takes packed 444, and ffmpeg doesn't have a packed 444p as far as I can tell. Will need to pack it as part of the copy. :-(
[22:37:26 CEST] <JEEBsv> ouch
[22:38:05 CEST] <JEEBsv> btw, can you set colorimetry info for the output stream?
[22:38:14 CEST] <JEEBsv> or is it hardcoded to BT.709/YCbCr?
[22:38:31 CEST] <durandal_170> I can add packed 444...
[22:39:08 CEST] <JEEBsv> because if you can set the BGR colorimetry you can actually encode RGB with the 4:4:4 mode
[22:39:26 CEST] <philipl> JEEBsv: that would be cute. I'm not sure, but I *think* so.
[22:40:04 CEST] <philipl> https://github.com/jp9000/OBS/blob/master/ObsNvenc/inc/nvEncodeAPI.h#L1009
[22:40:07 CEST] <JEEBsv> well, of course you could just override those parameter set values in output in case of hardcoding
[22:40:26 CEST] <JEEBsv> needs some parameter set parsing magic, but should be doable
[22:40:39 CEST] <philipl> durandal_170: It would seem a reasonable format to support.
[22:40:47 CEST] <philipl> I'm surprised it hasn't come up before.
[22:41:25 CEST] <Daemon404> nothing uses it
[22:41:26 CEST] <BBB> is packed 444p just like rgb24?
[22:41:36 CEST] <BBB> yuvyuvyuvyuvyuv...?
[22:41:43 CEST] <philipl> BBB: Yes.
[22:41:50 CEST] <BBB> I thought we had that...
[22:42:01 CEST] <philipl> I'd have thought so too but it's not the pixfmt list.
[22:42:28 CEST] <BBB> I guess not
[22:42:33 CEST] <BBB> surprising
[22:42:41 CEST] <Daemon404> it's not, because nothing practical uses it.
[22:43:03 CEST] <philipl> And yet here we are :-)
[22:44:04 CEST] <JEEBsv> it really sounds like it was meant for RGB :D
[22:44:34 CEST] <philipl> I could tell it accept RGB on our side and see what silliness results...
[22:44:34 CEST] <wm4> wouldn't packing it as 32 bit be better?
[22:44:53 CEST] <philipl> NV_ENC_BUFFER_FORMAT_YUV444_PL          = 0x1000, /**< Planar YUV [YUV separate bytes per pixel] allocated as serial 2D buffer. */
[22:44:59 CEST] <philipl> Hang on.
[22:45:04 CEST] <philipl> That's confusing.
[22:45:30 CEST] <philipl> That's a contradictory comment.
[22:45:33 CEST] <Daemon404> no it isnt
[22:45:39 CEST] <Daemon404> it means it's in a contiguous buffer
[22:45:46 CEST] <philipl> They call it planar
[22:45:48 CEST] <Daemon404> all Y, then all U, then all V.
[22:45:52 CEST] <Daemon404> in one 2d buffer.
[22:45:53 CEST] <philipl> but describe it as packed.
[22:46:05 CEST] <Daemon404> where is it described as packed
[22:46:06 CEST] <philipl> NV_ENC_BUFFER_FORMAT_YV12_PL            = 0x10,   /**< Planar YUV [YUV separate planes] allocated as serial 2D buffer. */
[22:46:18 CEST] <philipl> NV_ENC_BUFFER_FORMAT_IYUV_PL            = 0x100,  /**< Packed YUV [YUV separate bytes per pixel] allocated as serial 2D buffer. */
[22:46:40 CEST] <philipl> So now I don't know what they mean.
[22:46:52 CEST] <Daemon404> uh
[22:46:55 CEST] <Daemon404> IYUV is planar as well.
[22:47:17 CEST] <Daemon404> IYUV is like YV12, but with the two chroma planes switched.
[22:47:34 CEST] <philipl> Which is what I thought.
[22:47:40 CEST] <philipl> So I guess I have no idea what these comments mean.
[22:47:41 CEST] <nevcairiel> so iyuv == yuv420p
[22:48:01 CEST] <philipl> I do know that right now I just get solid green assuming it's planar.
[22:48:09 CEST] <philipl> (for black frames)
[22:49:27 CEST] <philipl> Ah, who knows.
[22:50:40 CEST] <BBB> Daemon404: thats avi/iyuv, you dont know if thats what they meant here
[22:50:47 CEST] <BBB> they might just be trolling/confusing
[22:51:27 CEST] <Daemon404> note the _PL.
[22:52:14 CEST] <durandal_170> yea
[22:52:37 CEST] <Daemon404> i feel like its just nvidia being shoddy
[22:52:42 CEST] <BBB> see, if only we all commented our code and clearly named our variables like this
[22:52:54 CEST] <BBB> we would be flametrolling for the rest of our lives
[22:53:49 CEST] <philipl> No doubt.
[22:53:55 CEST] <philipl> And the 'documentation' is just as awesome.
[22:54:05 CEST] <Daemon404> ... that is the documentation
[22:54:10 CEST] <Daemon404> i am looking at nvidia's pdf
[22:54:18 CEST] <Daemon404> the comment is a copypaste of that/
[22:54:34 CEST] <BBB> oh so its like googles webm spec
[22:54:37 CEST] <BBB> oops
[22:54:38 CEST] Action: BBB runs
[22:55:08 CEST] <Daemon404> BBB, i was straight up told my one of the managers that the rason for no spec is that it makes it easier for people to sue over patents.
[22:55:17 CEST] <Daemon404> reason*
[22:56:24 CEST] <jamrial> isn't webm just "take matroska, remove 4/5 of its optional elements and limit it to a handful of codecs"?
[22:56:45 CEST] <Daemon404> well i meant vpN
[22:56:49 CEST] <Daemon404> s/N/X?
[22:56:52 CEST] <Daemon404> fff typos.
[22:57:52 CEST] <BBB> jamrial: I meant vpx, yes
[22:58:31 CEST] <philipl> Ah, got it.
[22:58:35 CEST] <jamrial> ah
[22:58:37 CEST] <philipl> You have to separately set the chroma format.
[22:59:00 CEST] <philipl> It will happily store high444pp and mark the chroma as 4:2:0.
[22:59:08 CEST] <philipl> I got valid output. How cute.
[22:59:25 CEST] <philipl> So yes, it's planar.
[22:59:36 CEST] <philipl> Thanks, nvidia comments!
[23:01:15 CEST] <cone-394> ffmpeg 03Michael Niedermayer 07master:52c5521877aa: ffmpeg_opt: Favor streams that had packets
[23:01:16 CEST] <cone-394> ffmpeg 03Michael Niedermayer 07master:838c5f3df7e9: avformat/utils: Redesign scoring in av_find_default_stream_index()
[23:39:23 CEST] <philipl> lossless 444p appears to work. but still need to verify frame correctness.
[23:45:06 CEST] <BtbN> philipl, according to some forum posts on the OBS forums, turning on lossless mode with nv12 input seems to work, but produce dodgy output
[23:45:23 CEST] <BtbN> To my understanding, it shouldn't work at all
[23:57:48 CEST] <Compn> lol wm4 wants to drop winxp?
[23:57:50 CEST] <Compn> you fool!
[23:58:02 CEST] <Compn> worded differently, i disagree.
[23:58:26 CEST] <wm4> look how much I care
[23:59:20 CEST] <Compn> i'd have pity for your users if they werent all weeaboos and audiophiles
[23:59:28 CEST] <kierank> I also disagree
[23:59:33 CEST] <kierank> winxp is still good
[23:59:37 CEST] <kierank> and used in many corporate environments
[00:00:00 CEST] --- Thu Jul  2 2015