Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

June 2016

1 participants
60 discussions

ffmpeg-devel.log.20160629
by burek 30 Jun '16

30 Jun '16

[00:34:03 CEST] <cone-872> ffmpeg 03Michael Niedermayer 07master:8a3221cc67a5: avformat/mov: Check sample size [02:19:49 CEST] <Illya> ubitux: test atrac1-1 seems broken, I set my demuxer's probe to always return 1, and then ran `make fate-atrac1-1` which failed because it was picking it up as libopenmpt, but when I set it to return always 0 it passes (as expected because it wouldnt be recognised as libopenmpt). Considering that with a confidence of 1% it still chooses libopenmpt, I dont think this is my fault. What's your take on this? [02:23:13 CEST] <nevcairiel> you should probably add a cut-off when you return 0, low probe scores on all sorts of random files are a plague that cause all sorts of issues [02:23:56 CEST] <nevcairiel> we already have a few formats that cause misdetections, better not add new ones [02:38:25 CEST] <Illya> heh. This probe function is giving atrac1-1 70% confidence before I filter it. that seems very broken [02:49:09 CEST] <durandal_1707> Illya: atrac probe could be made better? [02:55:04 CEST] <Illya> durandal_1707: I was thinking that, I'll look into it tomorrow. I've notified the libopenmpt guys, and given them some samples just now. [04:50:22 CEST] <MelchiorGaspar> https://trac.ffmpeg.org/ticket/4478 [09:40:13 CEST] <cbsrobot> ubitux: do you still have that link to that "video analysis page" you posted here recently ? [09:44:47 CEST] <cbsrobot> ah found it ... [10:05:40 CEST] <ubitux> any suggestion on how i could create a file with various fucked up start time with ffmpeg? [10:58:59 CEST] <cone-963> ffmpeg 03Matthieu Bouron 07master:db0af7250a27: lavc/mediacodecdec_h264: add missing NAL headers to SPS/PPS buffers [11:01:40 CEST] <cone-963> ffmpeg 03Clément BSsch 07release/3.1:25f0ea9ece79: lavc/pnm_parser: disable parsing for text based PNMs [11:01:41 CEST] <cone-963> ffmpeg 03Matthieu Bouron 07release/3.1:8fd56690774b: lavc/mediacodecdec_h264: add missing NAL headers to SPS/PPS buffers [11:04:25 CEST] <BtbN> hm, this "ABI breakage" could be easily fixed, but then it would break stuff built against 3.1.0, if 3.1.1 comes out [11:04:55 CEST] <nevcairiel> i dont care about apps that use private api/abi :p [11:05:39 CEST] <cone-963> ffmpeg 03Vittorio Giovara 07master:c3ed259e4fef: fate: Move Canopus decoder tests to a separate file [11:05:40 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:dd1b1e32238b: Merge commit 'c3ed259e4fef64a1af4f6537be545fba47491aa9' [11:05:55 CEST] <BtbN> Where is it documented that those fields are private? I can't see it from the header. [11:06:52 CEST] <nevcairiel> * All fields below this line are not part of the public API. They [11:06:52 CEST] <nevcairiel> * may not be used outside of libavfilter and can be changed and [11:06:52 CEST] <nevcairiel> * removed at will. [11:07:38 CEST] <cone-963> ffmpeg 03Paul B Mahol 07master:6e2ad28cf764: aic: add frame threading support [11:07:38 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:ee7d01e81a7f: Merge commit '6e2ad28cf76461b02d85ad178087ba0c628b8d9d' [11:07:52 CEST] <BtbN> That's confusing enough for even ffplay to fail at it. [11:08:25 CEST] <nevcairiel> like I said yesterday, ffplay and ffmpeg arent known for their API/ABI cleanlyness [11:08:29 CEST] <BtbN> My idea for this would be: As it's not public ABI, move the field again, to the end of the struct. So existing debian and stuff can update without too much breakage. And then fix ffplay. [11:09:46 CEST] <cone-963> ffmpeg 03Paul B Mahol 07master:2a48a75a6f50: sgirledec: simplify, no need to use reget buffer [11:09:47 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:1994a73a6ba4: Merge commit '2a48a75a6f508121b96b0732a9fe03a46303f579' [11:17:59 CEST] <cone-963> ffmpeg 03Diego Biurrun 07master:b7f98659f21d: Remove unnecessary get_bits.h #includes [11:18:00 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:9b35242370be: Merge commit 'b7f98659f21dce438c33b512e25fd64b8d07c347' [11:19:56 CEST] <cone-963> ffmpeg 03Diego Biurrun 07master:09c4e5c5988c: indeo2: Drop disabled big-endian ir2_codes table [11:19:57 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:543142990b6f: Merge commit '09c4e5c5988c0037d108c5fc2a137d9ad488f7f4' [11:21:57 CEST] <BtbN> nevcairiel, are the fields in AVFilterContext also non-public? [11:21:59 CEST] <andrey_turkin> libav merge queue is nearing next h264 wave [11:22:19 CEST] <nevcairiel> BtbN: all changes in that commit are in non-public areas [11:22:28 CEST] <BtbN> That's not from that commit though [11:23:22 CEST] <BtbN> I'm looking at git diff n3.0.2..HEAD libavfilter/avfilter.h https://gist.github.com/BtbN/79571efbc0e822b98ae48e1347f0f4eb [11:23:53 CEST] <BtbN> vs. https://gist.github.com/e2fdebdb7f52cd8670bd1404fdd3abef [11:24:19 CEST] <BtbN> later one is how it currently is in ffmpeg, first one is how it would have avoided the problems [11:27:53 CEST] <nevcairiel> the change to avfiltercontext might be problematic as those fields are note delcared private, although with their lack of docs in general probably not used much [11:28:06 CEST] <nevcairiel> the change to avfilterlink is just apps being bad and using things they shouldnt [11:37:02 CEST] <cone-963> ffmpeg 03Diego Biurrun 07master:b668662939de: get_bits: Move BITSTREAM_READER_LE definition before all relevant #includes [11:37:02 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:ae753dbd0de4: Merge commit 'b668662939de3a02454cfc9ba3e6d10b87527a40' [11:37:57 CEST] <ubitux> any idea why the merge in 59c6509 is "silly"? [11:38:05 CEST] <ubitux> s/merge/assert/ [11:38:45 CEST] <nevcairiel> probably because it compares a bunch of compile time constants? [11:39:44 CEST] <nevcairiel> and MIN_CACHE_BITS as part of the old bitstream reader is probably scheduled for removal [11:40:49 CEST] <nevcairiel> at least i assume thats where the define come sfrom [11:40:56 CEST] <ubitux> ok [11:41:17 CEST] <ubitux> i wouldn't call this "silly" but whatever, i'll merge it [11:42:30 CEST] <cone-963> ffmpeg 03Diego Biurrun 07master:59c6509d9f02: mss2: Drop a silly assert [11:42:31 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:f755aa5ebdb8: lavc: move 2 more BITSTREAM_READER_LE definitions [11:42:32 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:9afa64dfdffd: Merge commit '59c6509d9f0236acbc317198eab76dab8320bced' [11:44:02 CEST] <cone-963> ffmpeg 03Diego Biurrun 07master:6d8fd614ff95: vorbis: Kill some pointless debug code [11:44:03 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:f8beca6f1081: Merge commit '6d8fd614ff957af242efcd8a6a0619874382f3a4' [11:45:16 CEST] <cone-963> ffmpeg 03Diego Biurrun 07master:85b8403c6fd1: svq1enc: Drop unused GetBitContext context member [11:45:17 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:c7253353f8f1: Merge commit '85b8403c6fd11e1c570caa970c7f435ac5f9583e' [11:46:11 CEST] <cone-963> ffmpeg 03Diego Biurrun 07master:42dc21432363: mpc: Drop unused GetBitContext context member [11:46:12 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:0501305e38ad: Merge commit '42dc214323637464759354912e18b2bee1884dd1' [11:49:27 CEST] <cone-963> ffmpeg 03Diego Biurrun 07master:81f769fa129e: gsm: Move requant_tab table to the gsm tables file [11:49:28 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:daedfa72541c: Merge commit '81f769fa129edc51c28285649c2df6da717e718f' [11:51:25 CEST] <cone-963> ffmpeg 03Diego Biurrun 07master:6ac52f05a6fc: dvbsub_parser: Add missing mem.h #include [11:51:26 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:bf7d01621917: Merge commit '6ac52f05a6fcadb84972c9557b28c67a416f866b' [11:55:30 CEST] <cone-963> ffmpeg 03Diego Biurrun 07master:197ae68e7878: Drop unnecessary unary.h #includes [11:55:31 CEST] <cone-963> ffmpeg 03Diego Biurrun 07master:4f81f8dba735: Drop unnecessary golomb.h #includes [11:55:32 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:4b9574b275c2: Merge commit '197ae68e78784524a7ccf97a3c301092715305d3' [11:55:33 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:bef74ef36705: Merge commit '4f81f8dba735c212efae077c4fec8ad4fe53b352' [12:00:04 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:2e4a7bd553ec: h264: drop unused H264Context.gb [12:00:05 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:fc0eafb7f8b2: Merge commit '2e4a7bd553ec7c805b4a3b90733405a14ba69072' [12:00:51 CEST] <ubitux> alright, i'm at the new h264 wave [12:01:02 CEST] <ubitux> which begins with vaapi stuff [12:01:10 CEST] <ubitux> hopefully i can test those... [12:01:12 CEST] <nevcairiel> BtbN: looking at the ABI diffs linked yesterday, the AVFilterContext appears to be the only one that is truely wrong according to your documentation and usage, if you want to send a patch to the ML to move it we can properly discuss it there [12:01:32 CEST] <BtbN> did exactly that one minute ago [12:01:38 CEST] <nevcairiel> ah [12:01:54 CEST] <nevcairiel> ubitux: the vaapi encoder is basically identical to libav i think, so you could just merge them [12:02:08 CEST] <nevcairiel> (its also unrelated to the h264 set as such) [12:03:26 CEST] <ubitux> ah indeed [12:03:39 CEST] <ubitux> no conflict, compiles [12:04:47 CEST] <nevcairiel> if you have any troubles with the vaapi encoder i'm sure jkqxz will also be happy to answer any questions [12:05:10 CEST] <cone-963> ffmpeg 03Mark Thompson 07master:081961f819c0: vaapi_h264: Add support for VUI parameters [12:05:11 CEST] <cone-963> ffmpeg 03Mark Thompson 07master:19d7667a8149: vaapi_encode: Add support for writing arbitrary additional packed headers [12:05:12 CEST] <cone-963> ffmpeg 03Mark Thompson 07master:48e2967cd50c: vaapi_h264: Add support for SEI messages [12:05:13 CEST] <cone-963> ffmpeg 03Mark Thompson 07master:02fa1ad9266f: vaapi_h264: Add source version identifier as unregistered SEI [12:05:14 CEST] <cone-963> ffmpeg 03Mark Thompson 07master:2940e196c5e4: vaapi_h265: cu_qp_delta should not be used in constant-QP mode [12:05:15 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:3e71e34333c7: Merge commit '081961f819c0b16c7a860d7da7d39f1fd91bd2f0' [12:05:16 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:19fe328f12f6: Merge commit '19d7667a81499d4357ec8e0851701e17c238e584' [12:05:17 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:cc3de390b724: Merge commit '48e2967cd50c2e1a2a539fd697d20ead2c5c4cc8' [12:05:18 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:4b90413cb26e: Merge commit '02fa1ad9266f9b1ea11565ac2f93f45853e351e8' [12:05:19 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:6c841e03ceba: Merge commit '2940e196c5e439d9869f8c02a49a318d0847453c' [12:05:57 CEST] <ubitux> now at the wave. [12:11:57 CEST] <jkqxz> He would :) But yes, the code has had no opportunity to diverge (and I will try to keep it that way). [12:53:39 CEST] <ubitux> michaelni: could you test "[PATCH] lavc/h264_slice: move au_pps_id and current_sps_id assignment earlier" with the security relevant samples? [12:54:18 CEST] <BtbN> Any in-progress merges right now, or am free to push without causing more work? [12:55:22 CEST] <BtbN> ubitux, ^ i guess [12:57:21 CEST] <ubitux> it's ok, go ahead [12:57:35 CEST] <ubitux> i'm blocked currently because of my latest patch [12:58:17 CEST] <cone-963> ffmpeg 03Timo Rothenpieler 07master:1bd9fb6de59b: ffplay: Fix usage of private lavfi API [12:58:18 CEST] <cone-963> ffmpeg 03Timo Rothenpieler 07master:1eb43af1a0e5: lavfi: Move new field to the end of AVFilterLink [13:14:33 CEST] <cone-963> ffmpeg 03Timo Rothenpieler 07release/3.1:cd427a9d07e8: ffplay: Fix usage of private lavfi API [13:14:34 CEST] <cone-963> ffmpeg 03Timo Rothenpieler 07release/3.1:0a6d7602308e: lavfi: Move new field to the end of AVFilterLink [14:02:40 CEST] <ubitux> michaelni: thanks :) [14:25:22 CEST] <BtbN> how do I read the "git show" of a merge commit? What do the two columns of + and - mean? [14:26:12 CEST] <BtbN> git show 8688d3a has https://bpaste.net/show/8eab46d16574 and I'm quite sure the fields after hw_device_ctx existed before that? [14:28:29 CEST] <ubitux> yes that's why they are on the 2nd column of addition [14:28:39 CEST] <ubitux> that is, diff from the 2nd parent (libav) [14:29:28 CEST] <BtbN> ah, so this ABI break occured because the later fields didn't exist in libav, and it was merged in front of them? [14:30:18 CEST] <BtbN> Yeah, looks like it [14:30:19 CEST] <ubitux> git diff 8688d3a~1..8688d3a [14:30:53 CEST] <ubitux> yes it was added on top of our fields [14:31:04 CEST] <ubitux> which are private so it shouldn't have been a problem [14:31:08 CEST] <ubitux> but in practice it is :p [14:31:13 CEST] <BtbN> They are private? [14:31:27 CEST] <ubitux> yes [14:31:37 CEST] <BtbN> The ones in AVFilterLink are marked as such, but the ones in AVFilterContext? [14:32:41 CEST] <ubitux> mmh indeed not in AVFilterContext [14:33:18 CEST] <BtbN> Funny enough moving the fields that are marked as private was what caused stuff to break. [14:33:31 CEST] <BtbN> Nothing seems to be using the fields in the Context [14:33:35 CEST] <BtbN> nothing external [14:34:21 CEST] <BtbN> Moving it to the end now would break stuff though, namely all the ff* tools. So I'm not sure what to do about it. [14:48:17 CEST] <mateo`> Someone knows where the h264 decoder adjust its width/height in case of interlaced pictures ? [14:49:48 CEST] <JEEB> I think it just outputs two images interleaved or something? [14:49:55 CEST] <JEEB> only the hevc decoder actually outputs separate ones [14:50:07 CEST] <JEEB> and then I think not a lot of stuff is able to habla that :D [14:51:03 CEST] <mateo`> I was not able to find where the avctx->width is adjusted in that case (not that I've searched a lot though) [14:52:17 CEST] <cone-963> ffmpeg 03Michael Niedermayer 07master:e6e8750e9432: avcodec/h264: Remove current_sps_id [14:52:18 CEST] <cone-963> ffmpeg 03Michael Niedermayer 07master:0c50f6905fb3: avcodec/h264: Remove au_pps_id [14:52:29 CEST] <ubitux> \o/ [14:52:41 CEST] <ubitux> thanks :) [15:02:03 CEST] <mateo`> got it ( h->mb_height = sps->mb_height * (2 - sps->frame_mbs_only_flag); [15:02:05 CEST] <mateo`> ) [15:02:17 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:d06e4d8aab9c: h264: start splitting decode_slice_header() [15:02:19 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:77a1e2c5f8f8: h264: move direct mode inits out of h264_slice_header_parse() [15:02:19 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:b93c0aed79f7: h264: drop an outdated comment [15:02:20 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:c54e2740e1f4: Merge commit 'd06e4d8aab9c679b6aea2591d2a9b382df9e5f74' [15:02:22 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:3c5a3882f988: Merge commit '77a1e2c5f8f8250dfacff24b993eb473260ed13e' [15:02:23 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:7f607120d997: Merge commit 'b93c0aed79f7f942e0dec26e53c147f297ce2ff6' [15:05:46 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:b16e9b9ac9db: h264: move initialising the explicit pred weight table for MBAFF [15:05:47 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:d7a245168844: Merge commit 'b16e9b9ac9db449cae2242767dd3c3fc309357c4' [15:23:38 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:7b50d60442af: h264: call ff_h264_fill_mbaff_ref_list() when constructing the normal ref list [15:23:39 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:527a57932765: Merge commit '7b50d60442af8d9527e9da46818011fe15a5265a' [15:32:12 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:fa5705907919: h264: move initialising the implicit pred weight table for MBAFF [15:32:13 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:cdecb39fca81: Merge commit 'fa57059079190242517701120cfdccad93c866da' [15:44:26 CEST] <michaelni> ubitux, this crashes: ./ffmpeg -skip_frame nokey -i /ld/michael/videos/h264_intra_first.ts -an -f null - [15:45:42 CEST] <ubitux> where can i find this sample? [15:48:08 CEST] <ubitux> (maybe related to a833ff6?) [15:50:11 CEST] <michaelni> ubitux, sample uploaded to fatesamples and patch for fate test posted, iam an idiot i had this test locally and thought its redundant [15:58:16 CEST] <Illya> where is the atrac probe? [15:59:57 CEST] <ubitux> michaelni: ok something went wrong in the first merge (c54e2740) [16:04:24 CEST] <ubitux> [ps]ps may actually be mismatching h->ps.[ps]ps [16:09:27 CEST] <ubitux> oh ok i get it [16:11:31 CEST] <ubitux> michaelni: http://sprunge.us/bDTP [16:11:37 CEST] <ubitux> can you try this with your fate test? [16:12:57 CEST] <nevcairiel> oh right it returns those silly threading error codes still [16:14:06 CEST] <ubitux> yeah [16:14:10 CEST] <ubitux> and they are positive [16:20:17 CEST] <michaelni> the new fate seems passing [16:20:33 CEST] <ubitux> yeah just tried and it works [16:20:46 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:a2901472fe18: lavc/h264_slice: properly forward positive "error" code [16:25:41 CEST] Action: ubitux annoyed by ff_h264_decode_ref_pic_list_reordering() not having a const h264 context [16:26:25 CEST] <ubitux> oh wait that could be fied [16:26:28 CEST] <ubitux> fixed [16:51:36 CEST] <cone-963> ffmpeg 03Michael Niedermayer 07master:89cccfc905f7: fate/h264: add test for skip-nointra and skip-nokey [17:07:28 CEST] <ubitux> question on ff_h264_decode_ref_pic_list_reordering() in h264_refs.c [17:07:38 CEST] <ubitux> abs_diff_pic_num is read with get_ue_golomb_long() [17:08:00 CEST] <ubitux> while the same value is read as get_ue_golomb() (pic_id, second case) [17:08:18 CEST] <ubitux> in the next merge this reading is decoupled from here [17:08:26 CEST] <ubitux> and the reading of the value is unified [17:08:37 CEST] <ubitux> should i: 1) use get_ue_golomb_long() to read all values [17:08:55 CEST] <ubitux> 2) conditionnal read depending on the op (modification_of_pic_nums_idc) [17:08:58 CEST] <ubitux> ? [17:09:16 CEST] <nevcairiel> the long variant is slightly lower but allows for higher max values, our codebase has switched a bunch of them to _long presumably because they can be higher then the normal variant allows [17:09:19 CEST] <nevcairiel> so just use long imho [17:09:19 CEST] <ubitux> (libav doesn't make a difference because they're using get_ue_golomb()) [17:09:30 CEST] <ubitux> (and we made the change in c51c08e0e70c186971385bdbb225f69edd4e3375) [17:10:03 CEST] <ubitux> nevcairiel: ok, won't affect speed© ? [17:10:41 CEST] <nevcairiel> marginally [17:11:04 CEST] <nevcairiel> compared with another branch to split it, probably not worth uglifying the code for [17:11:12 CEST] <ubitux> btw, it's stored as uint8_t in libav [17:12:28 CEST] <Illya> durandal_1707: where can I find the atrac probe? [17:17:15 CEST] <ubitux> it's not that clear in the specs what are the ranges [17:18:11 CEST] <nevcairiel> well we already know that one value thats being read needs it, so i really wouldnt bother adding another if and whatnot there to save one cycle of execution time in a function executed at most once per slice or something [17:19:40 CEST] <ubitux> i'm concerned about the storage for the value now [17:19:46 CEST] <ubitux> libav uses u8 [17:19:58 CEST] <ubitux> i'm tempted to use at least u32 since we use the _long() version [17:20:02 CEST] <ubitux> and maybe larger [17:20:13 CEST] <nevcairiel> we used u32 before and it worked, so stick to that imho [17:20:52 CEST] <ubitux> ah, _long is for u32 ok [17:21:00 CEST] <durandal_1707> Illya: oma demuxer? [17:21:50 CEST] <Illya> Ah, well I got a reply from the libopenmpt guys, they said they've fixed it now. I'm gonna ask them to release a version so that we can support that as the minimum [17:36:15 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:ed9a20ebe4a8: h264: split reading the ref list modifications and actually building the ref list [17:36:15 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:2aff557c6acb: Merge commit 'ed9a20ebe4a89de119ea97bdccf688ece8c6648c' into merge-libav-new [17:42:33 CEST] <jkqxz> abs_diff_pic_num can be up to MaxPicNum, so 2 * MaxFrameNum, so 2 ^ (log2_max_frame_num_minus4 + 4). log2_max_frame_num_minus4 is constrained to [0,12], so the max is 2^17. [17:43:16 CEST] <ubitux> so much more than 255 :p [17:43:29 CEST] <ubitux> i'd love such a sample [17:43:41 CEST] <jkqxz> In practice it will never be higher than max_num_ref_frames (i.e. 16), though, because noone is going to keep moving short term pictures around to do that. [17:44:45 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:0bad25430035: h264: move initing the implicit pred weight table out of h264_slice_header_parse() [17:44:46 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:6dd996c7c815: h264: move building the reference list out of h264_slice_header_parse() [17:44:47 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:3b95452ca8bb: Merge commit '0bad254300356005af4aef00a706bf2e8eee96bc' [17:44:48 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:9ab6f01839e3: Merge commit '6dd996c7c81575a1e4969987ab175a6df7beab3d' [17:45:13 CEST] <jkqxz> (That is, if the difference is that big, you would have put it in the long-term list instead.) [18:03:30 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:4cec43a9eeb5: h264: move calculating the POC out of h264_slice_header_parse() [18:03:31 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:4890b0851c5e: Merge commit '4cec43a9eeb58eb9e581a2d9d25f78e5bfbb0960' [18:04:37 CEST] <ubitux> going home, i'll continue the merge in about an hour [18:04:55 CEST] <ubitux> 114 commits left [18:25:31 CEST] <JEEB> gg [18:40:07 CEST] <cone-963> ffmpeg 03Timo Rothenpieler 07master:1a75145559d3: lavfi: Move new field to the end of AVFilterContext [19:02:55 CEST] <cone-963> ffmpeg 03Timo Rothenpieler 07release/3.1:1fdf54946244: lavfi: Move new field to the end of AVFilterContext [19:05:48 CEST] <jamrial> michaelni: wouldn't it be a good idea to release 3.1.1 asap to make sure distros update to that instead of 3.1? [19:06:10 CEST] <jamrial> Arch (the fastest distro to update packages) hasn't done it yet, for example [19:07:38 CEST] <BtbN> Someone should also check if other ABI breaks sneaked in. Couldn't find any other altered structs with stuff added in the middle so far though. [19:07:49 CEST] <jamrial> funny enough, the one change that apparently broke everything is the one that was never supposed to be public api [19:08:04 CEST] <jamrial> so library users are at fault for abusing the api :P [19:08:20 CEST] <andrey_turkin_> jamrial: Gentoo is faster... [19:08:25 CEST] <michaelni> are there any other regressions we should fix before releasing ? [19:08:43 CEST] <JEEB> andrey_turkin_: > gentoo > not taking ages to get something to being the default version of something [19:08:51 CEST] <jamrial> andrey_turkin: not as stable [19:09:02 CEST] <ubitux> the pnm regression fix was backported by mateo` [19:09:03 CEST] <jamrial> they update packages fast but leave them masked [19:09:06 CEST] <ubitux> i don't know any other [19:09:16 CEST] <andrey_turkin_> agreed on that.. [19:11:18 CEST] <jamrial> IMO, if it wasn't for the AVFilterContext public abi break (which apparently has no real effect since nothing accessed the affected fields) i would have left the AVFilterLink stuff intact [19:11:41 CEST] <nevcairiel> broken software is broken [19:11:44 CEST] <jamrial> it was a good chance to let library users know they are really not supposed to directly access fields marked as "do not access directly" [19:11:50 CEST] <jamrial> and fix their code [19:11:56 CEST] <BtbN> That mark is quite easy to miss though [19:12:19 CEST] <BtbN> Isn't it possible to hide those fields, via an internal-only define or something? [19:12:30 CEST] <BtbN> Or would changing the struct size break external stuff? [19:13:14 CEST] <nevcairiel> should just move them to an internal struct [19:13:16 CEST] <jamrial> if a five lines long warning about private fields is not enough, then what? a big 10 lines long, all caps, exclamation mark filled warning? [19:13:55 CEST] <ubitux> having a x->internal field instead of "fields below are private" would probably be appropriate yes [19:14:04 CEST] <ubitux> or maybe we should just prefix these fields by "_"? [19:14:27 CEST] <andrey_turkin_> is there some __attribute__((cant_touch_this)), similar to deprecated? [19:15:34 CEST] <jamrial> what ubitux is a good idea. we do that for other structs [19:15:45 CEST] <Illya> andrey_turkin: I believe it's called __attribute__((hammer_time)) [19:16:12 CEST] <andrey_turkin_> probably not in clang yet [19:17:34 CEST] <andrey_turkin_> #define INTERNAL(x) _x to use on field names in public headers? Ugly but it will get the point across [19:18:13 CEST] <nevcairiel> should just move them to AVFilterLinkInternal like many other structs do [19:18:34 CEST] <nevcairiel> no need to invent new fancy ways [19:18:53 CEST] <ubitux> "AV"? FF and internal header [19:19:11 CEST] <nevcairiel> the internal things are all called like that [19:19:15 CEST] <nevcairiel> $structInternal [19:19:28 CEST] <nevcairiel> but its struct definition is not public [19:39:06 CEST] <cone-963> ffmpeg 03Petru Rares Sincraian 07master:2b1995e3eeb3: fate: add test for asetnsamples [19:46:38 CEST] <atomnuker> jamrial: any tips on how to save 2 registers on the signed_rect asm to make it run on 32 bits? [19:50:44 CEST] <jamrial> use the reg you were using for height (r6 i think), and handle the height value directly from stack, since you can use arithmetic instructions with a memory operand [19:51:40 CEST] <jamrial> look at the m and mp suffixes in x86inc, DECLARE_REG macro [19:58:48 CEST] <michaelni> jamrial, for 3.1.1 https://trac.ffmpeg.org/ticket/5676 and https://trac.ffmpeg.org/ticket/5678 and maybe https://trac.ffmpeg.org/ticket/5671 should be fixed first i think [20:03:35 CEST] <nevcairiel> 5676 is fixerd by the things jamrial refers to [20:03:57 CEST] <nevcairiel> the dvd ticket lacks any information to reproduce it [20:04:44 CEST] <michaelni> the last comment in 5676 says "release/3.1 is still broken" [20:04:47 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:7ab5d577a9af: h264: move initializing the slice start out of h264_slice_header_parse() [20:04:48 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:c28aecc56ace: Merge commit '7ab5d577a9affe3397c08b032f983f9bf7101865' [20:05:33 CEST] <nevcairiel> both these tickets lack any useful information then [20:09:09 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:39ab2ea53121: h264: rename mmco_index to nb_mmco [20:09:10 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:57d30fde9ea8: Merge commit '39ab2ea53121b9976a619cd545fbd3464b908696' [20:37:10 CEST] <jamrial> i think i found why mpv still fails [20:37:32 CEST] <jamrial> "mp_chmap_from_channels(&lavc_chmap, avframe->channels);" in audio/audio.c [20:37:43 CEST] <jamrial> avframe->channels should not be accessed directly [20:37:56 CEST] <jamrial> commit 1a708780f3d4b431996d118df4e448b4f2a7942e changed its position [20:48:54 CEST] <jamrial> https://github.com/mpv-player/mpv/issues/3295 [20:57:21 CEST] <jamrial> since we dropped compatibility with libav, we should probably just allow direct access to fields like these from avframe next time we bump major [21:00:47 CEST] <jamrial> well, wm4 closed and locked the above ticket... [21:03:59 CEST] <nevcairiel> enocare then [21:05:02 CEST] <nevcairiel> he doesnt even recognize that his code is the one being dumb, but what can you do [21:05:21 CEST] <jamrial> he recognized it in a following comment, but still said he didn't care [21:05:58 CEST] <jamrial> i wondered why wm4 hasn't joined this channel for weeks now. guess i know why now... [21:06:40 CEST] <nevcairiel> he is butthurt for some reason again [21:08:59 CEST] <jamrial> i'm going to guess it's the whole circus from a month ago [21:09:08 CEST] <jamrial> he's probably fed up for a while, and i don't blame him [21:09:58 CEST] <jamrial> still doesn't justify keeping a bug in his code, though [21:22:48 CEST] <jamrial> yep, kodi as well :p [21:24:29 CEST] <jamrial> i'll probably kill all this get/set crap for fields in public headers as soon as we bump major. the ones that exist because of libav compat [21:30:24 CEST] <nevcairiel> might be nice to keep the functions, but some re-ordering and removing comments might be nice [21:30:47 CEST] <fritsch> yeah, he reacted quite strange [21:30:58 CEST] <fritsch> we (kodi) are happy to get such reports and like to fix these [21:31:28 CEST] <jamrial> the functions should remain but deprecated for two years as usual, yeah [21:31:40 CEST] <jamrial> fritsch: thanks [21:31:50 CEST] <fritsch> so i now "fix" those methods in and in 2 years I remove them again? :-) [21:32:00 CEST] <fritsch> if you can do a short grep and just point me the issues I will fix thme [21:32:10 CEST] <fritsch> though it's quite hard for downstream to use these correctly [21:32:16 CEST] <nevcairiel> if you dont care about running with any other version then the one you built with, you can also keep it as is [21:32:29 CEST] <fritsch> we don't care - yes [21:32:31 CEST] <fritsch> but ... [21:32:34 CEST] <fritsch> arch, gentoo [21:32:35 CEST] <fritsch> debian [21:32:41 CEST] <nevcairiel> tell them to suck it :p [21:32:41 CEST] <fritsch> debian-multimedia [21:32:43 CEST] <fritsch> will bug you [21:32:50 CEST] <fritsch> as you see on current trac [21:33:01 CEST] <fritsch> that's what we don't want - so we need to use the api correctly [21:34:39 CEST] <fritsch> jamrial: so in case you stumble on something do not hessitate to add these here: https://github.com/xbmc/xbmc/pull/10043 [21:35:22 CEST] <fritsch> fernet did not want to fix these, cause we linked against ffmpeg statically in the first place, to not have support every single distro building against ffmpeg 3 years old, libav from tomorrow and so on [21:36:09 CEST] <nevcairiel> you should see firefox that ship binaries that are supposed to be compatible with every ffmpeg on this planet [21:36:13 CEST] <nevcairiel> their wrapper is pure madness [21:36:36 CEST] <fritsch> nope, that's not what we want [21:36:37 CEST] <JEEB> and then they use C++ templates to switch [21:37:05 CEST] <fritsch> we try to base on latest stable as good as it works and that must be enough [22:56:37 CEST] <michaelni> nevcairiel, do you want to take over release management ? [22:57:39 CEST] <ubitux> https://github.com/mpv-player/mpv/issues/3295 we lost someone it seems [23:01:07 CEST] <nevcairiel> michaelni: no, but that doesnt prevent me from having an oppinion either way [23:02:14 CEST] <michaelni> nevcairiel, i would like to fix the issue so distributions can just use 3.1 and not have everything randomly break [23:02:32 CEST] <nevcairiel> I want app developers to notice their usage is wrong and fix it, its not our bug [23:02:55 CEST] <michaelni> nevcairiel, we already lost wm4 and mpv IIUC [23:03:04 CEST] <jamrial> really, the only actual abi break was the avfiltercontext one and that's already fixed [23:03:29 CEST] <ubitux> mpv will break everytime there is a need for getters btw [23:03:29 CEST] <nevcairiel> we have a separation between public and private fields in a bunch of contexts for a reason [23:03:41 CEST] <nevcairiel> and we have added new public fields above the private marker before [23:03:45 CEST] <nevcairiel> so its not a new "problem" [23:03:46 CEST] <ubitux> (because wm4 is very reluctant to use them) [23:03:50 CEST] <nevcairiel> for some reason it matters this time tho [23:03:56 CEST] <jamrial> and no, mpv still works. their readme now states that they will not bother with issues regarding private fields anymore [23:04:39 CEST] <nevcairiel> private fields should ideally be moved into a $structInternal context instead of this separation [23:04:48 CEST] <nevcairiel> so no project uses fields that break [23:04:54 CEST] <ubitux> i'm against adding more getters/setters; we don't need abi compat with libav anymore [23:05:02 CEST] <ubitux> we have to be careful with private/public things [23:05:24 CEST] <michaelni> can we bump major of all libs ? [23:05:26 CEST] <ubitux> and maybe the internal field is the way to go to actually prevent users (and ourselves) from fucking up everything [23:05:43 CEST] <ubitux> i think libav plans to bump [23:05:46 CEST] <nevcairiel> so whats different in 3.1 that warrants this entire discussion, when previous releases have added new public fields and changing the offset of private fields? [23:06:02 CEST] <rcombs> move all private fields to internal structs; bump major versions [23:06:09 CEST] <rcombs> sounds good [23:06:19 CEST] <ubitux> and deprecate getters [23:06:22 CEST] <ubitux> +setters [23:06:30 CEST] <michaelni> you misunderstand [23:06:42 CEST] <michaelni> can we bump major in 3.1 ? [23:06:49 CEST] <nevcairiel> 3.1 is released already [23:06:54 CEST] <michaelni> 3.1.1 [23:07:15 CEST] <nevcairiel> just make it 3.2 and forget 3.1 ever existed then [23:07:32 CEST] Action: rcombs shrugs [23:07:39 CEST] <michaelni> can we remove the recommandition of people upgrading to 3.1 ? [23:07:40 CEST] <ubitux> if you bump major, also bump major of the main ffmpeg version (4.0) [23:08:03 CEST] <rcombs> oh boy, are we becoming Chrome [23:08:11 CEST] <ubitux> and maybe make a proper release notes and not do it in a hurry again [23:08:15 CEST] <jamrial> michaelni: yeah, that's a good start (remove recommendation) [23:08:17 CEST] <ubitux> to prevent mess like this [23:08:23 CEST] <rcombs> (what does the main ffmpeg major version even mean) [23:08:24 CEST] <michaelni> jamrial, ill send a patch [23:09:08 CEST] <jamrial> It will be a mess if we bump major in a branch. if it comes to it, we should bump major in master, make private fields public as needed, deprecate accessors as needed, and release 3.2 [23:09:26 CEST] <jamrial> but really, the one abi break was in libavfilter. everything else is misuse by librayr users... [23:09:45 CEST] <nevcairiel> <nevcairiel> so whats different in 3.1 that warrants this entire discussion, when previous releases have added new public fields and changing the offset of private fields? [23:09:48 CEST] <nevcairiel> ^^ still wondering about that [23:09:54 CEST] <rcombs> what broke with mpv anyway [23:10:04 CEST] <jamrial> they accessed a private field in avstream [23:10:05 CEST] <ubitux> access to .channels [23:10:19 CEST] <nevcairiel> jamrial: avfilterlink i think [23:10:20 CEST] <jamrial> when we added a new public one above it, offset changed for the private fields [23:10:29 CEST] <nevcairiel> or avstream as well? [23:10:37 CEST] <ubitux> we had a getter but they didn't want to use it iiuc [23:10:38 CEST] <jamrial> mpv? just avstream afaik [23:10:51 CEST] <jamrial> avfilterlink was ffplay only it seems [23:11:00 CEST] <rcombs> oh, AVFrame::channels? [23:11:00 CEST] <nevcairiel> ah no mpv uses avframe [23:11:08 CEST] <jamrial> yeah, frame [23:11:10 CEST] <jamrial> my bad [23:11:18 CEST] <jamrial> ugh, sorry. mixing names [23:11:29 CEST] <nevcairiel> those getters should probably go away, but in the documented 3.0/3.1 ABI the change is still "ok" [23:11:31 CEST] <jamrial> mpv was api misuse from their part. not an abi break [23:11:54 CEST] <nevcairiel> back when we still wanted libav compat, this would've been the only way [23:12:04 CEST] <rcombs> why is that semi-private anyway [23:12:05 CEST] <jamrial> AVFilterContext was broken and already fixed [23:12:16 CEST] <nevcairiel> rcombs: remnant from libav-compat [23:12:30 CEST] <jamrial> AVFilterLink was never broken, but we moved a private field around just to make it easier for those applications misusing the api [23:12:34 CEST] <nevcairiel> because we had to reserve the right to add new fields below the line where libav fields existed [23:12:42 CEST] <michaelni> "<jamrial> but really, the one abi break was in libavfilter. everything else is misuse by librayr users..." <-- the misuse is in our code and i would like to fix that [23:12:58 CEST] <nevcairiel> the avfilter misuse was fixed in ffplay [23:13:23 CEST] <jamrial> michaelni: you mean the avstream fields by ffmpeg, ffprobe, src_movie and tools/uncoded_frame? [23:13:29 CEST] <michaelni> jamrial, yes [23:13:57 CEST] <michaelni> it may be not a major thing as fate didnt crash but it itches me i want t fix this [23:14:24 CEST] <nevcairiel> What I would like to see for some future release is getting rid of all those private fields in public contexts (moving them into *Internal contexts) and getting rid of the accessors that only exist for libav compat (after deprecation of course), that way all fields they see in a header can be treated equally [23:14:39 CEST] <michaelni> nevcairiel, +1 [23:14:48 CEST] <michaelni> i dont know why we forgot this [23:16:15 CEST] <ubitux> can we target this for 4.0 in 3 months? [23:16:22 CEST] <jamrial> we didn't forget. private fields are old, be it because of libav compat or just because when the struct was designed nobody thought about an *internal field [23:17:04 CEST] <michaelni> we should have moved our intended to be public fields in the public area before 3.0 [23:17:21 CEST] <jamrial> but yeah, next major bump should clean all this private crap to instead use new opaque *internal fields containing everything [23:31:27 CEST] <anticw> re: mpegts i see the continuity counter as either 0 or 1, i expected to see increasing then wrapping values; is this related to #2828 ? [23:31:47 CEST] <anticw> https://trac.ffmpeg.org/ticket/2828 (sorry, thought meebe doing #<n> would have a bot give the URL) [23:32:36 CEST] <BBB> whats going on? [23:32:57 CEST] <BBB> michaelni: I have the feeling youre overreacting [23:33:57 CEST] <jamrial> BBB: we found out AVFilterContext abi was broken (already fixed), then that at least two library users are misusing the avframe api, and then that ffmpeg and ffprobe is also misusing the avstream api [23:34:28 CEST] <BBB> I can see that, but why is michael suggesting we remove the recommendation to upgrade to 3.1? [23:34:43 CEST] <BBB> that seems & a little much? [23:35:06 CEST] <jamrial> ffmpeg/ffprobe compiled with 3.0 but run using 3.1 libraries can crash because of said avstream misuse [23:35:22 CEST] <BBB> but that is highly unlikely to happen [23:35:28 CEST] <nevcairiel> my main question could not be answered yet: we've added public fields before the marker in previous releases, why is 3.1 a problem nw? [23:35:36 CEST] <BBB> on normal systems, an upgrade of libav*.so also upgrades ffmpeg/ffprobe [23:35:40 CEST] <nevcairiel> now* [23:35:54 CEST] <BBB> (not to mention that these are bugs in ffmpeg/ffprobe) [23:36:33 CEST] <nevcairiel> of course the ultimate goal should be to get of this entire concept so such probelms are impossible [23:37:01 CEST] <nevcairiel> but it requires at least a couple days of working that out and testing and reviewing -- and still breaks the API/ABI of those that (mis-)used those fields [23:37:51 CEST] <BBB> we should recommend that people upgrade to 3.1 tools-and-libs-at-the-same-time [23:38:13 CEST] <nevcairiel> that should always be a recommendation regardless of what we do :) [23:38:31 CEST] <jamrial> either that or removing the recommendation altogheter is much better than adding accessors that will be there for, at the very least, two years before we can remove them, yeah [23:39:57 CEST] <andrey_turkin_> anticw: do you mean you see continuity counter errors in single mpegts file? [23:40:14 CEST] <jamrial> nevcairiel: regarding that question, i guess previous cases of adding public fields above private markers never broke ffmpeg/ffprobe/ffplay because they were used properly, or not at all [23:40:17 CEST] <BBB> so practically, we had struct { /* public */ a; /* private */ b; } [23:40:19 CEST] <jamrial> whereas this time it happened [23:40:24 CEST] <BBB> and a libav merge pulled in a c in between [23:40:29 CEST] <BBB> and something accessed b directly [23:40:31 CEST] <nevcairiel> pretty much [23:40:36 CEST] <BBB> where something is ffplay/ffmpeg/mpv/etc., right? [23:40:48 CEST] <michaelni> yes [23:40:48 CEST] <jamrial> yeah [23:40:51 CEST] <BBB> so can we release a 3.1.1 that moves c to after b? [23:40:56 CEST] <jamrial> no [23:40:58 CEST] <jamrial> because c is public [23:41:05 CEST] <BBB> ah... [23:41:05 CEST] <BBB> ok [23:41:08 CEST] <anticw> andrey_turkin_: no errors, just reading the wikipedia page (sorry) i expected to see the values increase to 15 then wrap [23:41:14 CEST] <BBB> yeah so then youre screwed :) [23:41:19 CEST] <BBB> you need to fix tools to not access b [23:41:23 CEST] <BBB> or move b to be public [23:41:31 CEST] <michaelni> there are several b [23:41:37 CEST] <anticw> andrey_turkin_: so nothing wrong just unexpected values or more likely perhaps my lack of understanding [23:41:42 CEST] <BBB> I would probably move b (or a set of b) to be public then [23:42:07 CEST] <nevcairiel> that was one suggestion, but it still leaves those apps broken until they recompile [23:42:12 CEST] <BBB> (if they are deemed worthy to be public) [23:42:17 CEST] <BBB> nevcairiel: indeed [23:42:19 CEST] <andrey_turkin_> anticw: you know they are per-PID? Do you see CC values repeating in single PID? [23:42:24 CEST] <BBB> nevcairiel: I dont think that can be prevented [23:42:30 CEST] <jamrial> there's probably no solution that doesn't require recompilation [23:42:35 CEST] <BBB> right [23:43:42 CEST] <nevcairiel> which leaves us with a few choices, do that quick and dirty and put it into 3.1.1, or do it thoroughly and do a 3.2 as soon as we deem feasible, with a major bump [23:43:52 CEST] <nevcairiel> (or both) [23:43:54 CEST] <jamrial> I vote the latter [23:44:33 CEST] <jamrial> ffmpeg/ffprobe compiled with 3.0 but run with 3.1 is an use case so niche that's not worth making a mess of fields or adding accessor functions [23:45:24 CEST] <BBB> I agree with what jamrial says [23:45:28 CEST] <nevcairiel> mpv and kodi seem both affected to different degrees, but at least kodi seems open to fixing those abi misuse issues in their code, and both projects really dont officially support running with a mis-matched library anyway [23:45:46 CEST] <jamrial> and i agree with BBB, instead of removing the recommendation, just make it clear that tools and libraries should ideally be updated at the same time and not mixed [23:45:51 CEST] <anticw> andrey_turkin_: as best as i can tell for a given pid they are repeating [23:45:56 CEST] <jamrial> because, even though it's supported, shit happens [23:46:00 CEST] <BBB> there is an issue that we need to address, which is what do we do about future libav merges that break our upgrades [23:46:11 CEST] <BBB> because shit happened and shit will happen again [23:46:21 CEST] <andrey_turkin_> anticw: can you provide a sample for me to lok at? [23:46:27 CEST] <ubitux> we don't support libav abi compat anymore so it's not a problem [23:46:27 CEST] <nevcairiel> BBB: since we dont care about compat with them, we just have to be careful to put new members at the bottom [23:46:44 CEST] <nevcairiel> bugs will happen, but public struct merges should just be reviewed very carefully [23:46:45 CEST] <jamrial> and outside of the avfiltercontext merge, nothing else broke api/abi [23:46:48 CEST] <BBB> what if they add new public members and we find ffplay was accessing another private member directly? [23:46:54 CEST] <ubitux> having the internal field in all the struct will prevent doing such mistake in the future [23:46:57 CEST] <BBB> just dont care until it happens? [23:47:03 CEST] <BBB> and hope for the best? [23:47:09 CEST] <nevcairiel> BBB: the plan is to get rid of the private fields in public structs and move them into an opaque internal struct [23:47:11 CEST] <BBB> (Im fine with that, we should jst be explicit about it) [23:47:18 CEST] <BBB> nevcairiel: that would be sweet [23:47:22 CEST] <jamrial> make sure to not write patches for ffplay/ffmpeg/ffprobe using private fields is a good start... [23:47:49 CEST] <BBB> ok I think we have a solution then [23:47:51 CEST] <anticw> andrey_turkin_: i can later yes (it's rtsp->mpegts from a security camera so i need to make sure it's pointed at something like a blank wall) [23:48:02 CEST] <nevcairiel> BBB: in that process, we'll at the very least find out which fields are accessed "wrongly", and can then decide to promote them to public or the app had no business using it either way [23:48:14 CEST] <michaelni> jamrial, can you post a patch that changes thre recomandition to all libs/tools or changes the release notes ? [23:48:17 CEST] <BBB> michaelni: so I think the web recommendation should go but the recommendation should also be to not use ffmpeg/ffprobe 3.0 with libavcodec/* 3.1 because of a bug in the old tools [23:48:33 CEST] <BBB> nevcairiel: yes, agreed [23:48:53 CEST] <andrey_turkin_> anticw: you can chop first 16 kbs of the file or so; should be enough to see what's going on [23:50:17 CEST] <jamrial> michaelni: alright [23:50:35 CEST] <jamrial> michaelni: what's the web repository? [23:50:48 CEST] <michaelni> thx, i think it will need fewer iterations without me being the author ;) [23:50:58 CEST] <ubitux> https://git.ffmpeg.org/ffmpeg-web [23:52:01 CEST] <anticw> andrey_turkin_: yeah, can do, it's not hard to see, diag output at http://f00f.org/tmp/mpegts-pid-contcount.txt means it shows up very early on and exists in most pkts so 16k will be plenty [23:52:20 CEST] <jamrial> michaelni: not really, my english often sucks :p [23:52:25 CEST] <jamrial> ubitux: thanks [23:54:41 CEST] <BBB> michaelni: I dont think your authorship is the issue, although you do tend to have some consistently recurring typos :-p [23:55:22 CEST] <BBB> brb [00:00:00 CEST] --- Thu Jun 30 2016

1 0

ffmpeg.log.20160629
by burek 30 Jun '16

30 Jun '16

[00:31:27 CEST] <jancoow> furq: do you know how to eventually stream a rtmp over http? [00:34:10 CEST] <furq> https://github.com/arut/nginx-rtmp-module/wiki/Directives#hls [00:35:06 CEST] <furq> hls isn't much good for security camera footage though because it has high latency [00:37:06 CEST] <jancoow> on what latency are we talking about [00:37:56 CEST] <furq> it depends on the video gop size [00:38:03 CEST] <furq> at least several seconds though [00:38:54 CEST] <furq> you could probably get it below five seconds if this is on a lan [00:39:03 CEST] <jancoow> that's fine! [00:39:13 CEST] <jancoow> 5-10 secons is fine [00:39:53 CEST] <jancoow> what does hls_fragment mean? [00:40:09 CEST] <jancoow> sample time or something? [00:41:07 CEST] <furq> right [00:41:27 CEST] <furq> that has to be a multiple of the video gop size, though (or else it'll just be ignored) [00:41:32 CEST] <furq> segments have to start on an idr frame [00:42:02 CEST] <jancoow> 5 seconds should be fine then i think; then would the latency be around 5-10 seconds i guess? [00:42:21 CEST] <furq> probably more like 10-20 [00:42:43 CEST] <furq> you should be able to use very short gops (1-2 seconds) on a lan [00:43:13 CEST] <furq> hls latency is at least one full segment, but in practice more like 2-3 segments [00:45:12 CEST] <jancoow> i will try some different values! :) [00:45:22 CEST] <jancoow> do you suggest writing to ram? [00:46:22 CEST] <furq> i can't say i've tried it [00:46:25 CEST] <furq> it couldn't hurt though [00:46:45 CEST] <jancoow> writing to /tmp is on ram so [00:46:51 CEST] <furq> yeah i just realised that i do in fact do that [00:46:56 CEST] <furq> and that this vps does have a tmpfs on /tmp [00:47:14 CEST] <jancoow> cool! [00:47:28 CEST] <furq> i probably shouldn't do that considering this vps only has 256mb [00:48:13 CEST] <jancoow> lololo [00:48:16 CEST] <jancoow> that isn't much [00:48:38 CEST] <furq> it's enough for an irc client and a quakeworld server [00:52:12 CEST] <jancoow> if it sufficiente the needs its fine [00:52:38 CEST] <tmm1> is there a way to copy side data (like A53_CC) when transcoding mpeg2 -> h264 [00:53:37 CEST] <jancoow> only getting forbidden 403 everytime when going to host/hsl [00:53:42 CEST] <jancoow> :/ [01:00:19 CEST] <jancoow> any idea why furq ? [01:00:24 CEST] <jancoow> has to be something with permissions [01:02:00 CEST] <c_14> tmm1: libx264 has an a53cc option. -a53cc 1 [01:19:02 CEST] <jancoow> furq: any idea if it's possible to do a http live stream? [01:19:14 CEST] <jancoow> within the browser [01:19:20 CEST] <jancoow> because that would be awesome :D [01:23:45 CEST] <furq> not with nginx-rtmp [01:23:54 CEST] <furq> http streaming is flaky and unreliable anyway [01:24:03 CEST] <furq> your best bet is probably to just use flash [01:24:34 CEST] <jancoow> would be funny to just display slow 1fps vids on my home automatic website [01:45:55 CEST] <DelphiWorld> sup everyone [01:46:05 CEST] <DelphiWorld> anyone using FFMpeg with quickSync? [01:46:59 CEST] <jancoow> well many many thanks furq for helping me [01:47:08 CEST] <jancoow> i think i can make this perfect for me :) [01:47:15 CEST] <jancoow> gn everyone [01:51:57 CEST] Action: DelphiWorld need FFMpeg with quicksync but zeroSucsess... [01:53:12 CEST] <kepstin> with intel's hardware encoder? I've gotten that working on linux with ffmpeg 3.1 and the vaapi driver [01:53:42 CEST] <DelphiWorld> kepstin: should you help me please ? [01:53:58 CEST] Action: DelphiWorld started to fetch ffmpeg's DEPS in ubuntu 16.04 [01:56:15 CEST] <DelphiWorld> kepstin: could you give me the FFMpeg source git repo? [01:56:27 CEST] <kepstin> DelphiWorld: ... [01:56:48 CEST] <kepstin> it's linked right on the downloads page. [01:59:50 CEST] <DelphiWorld> Kei_N: do i need intel dev studio or media studio or something? [02:00:00 CEST] <kepstin> when you're installing the deps on ubuntu, make sure you get the 'intel-vaapi-driver' and 'libva-dev' packages, then it's just a matter of building ffmpeg; I think i'll autodetect, but you can use --enable-vaapi [02:03:24 CEST] <DelphiWorld> kepstin, intel-vaapi-driver not found [02:04:12 CEST] <DelphiWorld> i could see i965-va-driver [02:05:57 CEST] <kepstin> oh, yeah, that's the right one [02:06:03 CEST] <DelphiWorld> :-P [02:06:38 CEST] Action: DelphiWorld would give kepstin a iceCream if he get the qsv codec to work... ;) [02:08:02 CEST] <DelphiWorld> restarting my pc... [02:15:48 CEST] <thebombzen> does anyone here know how to probe the duration of a GIF image correctly? [02:16:13 CEST] <thebombzen> setting -probesize and -analyzeduration each to 2147483647 didn't work [02:17:48 CEST] <DelphiWorld> kepstin, surprisingly i965-va-driver was allready there ;) [02:18:19 CEST] <thebombzen> I was unable to probe with either ffmepg -i or with ffprobe -show_streams [02:18:32 CEST] <thebombzen> it just says duration N/A no matter what [02:18:36 CEST] <kepstin> DelphiWorld: as far as actually using the thing, the libav docs are the best reference atm: https://wiki.libav.org/Hardware/vaapi [02:18:56 CEST] <DelphiWorld> kepstin, should i need libmfx? [02:19:01 CEST] <kepstin> DelphiWorld: nope [02:19:08 CEST] <DelphiWorld> strange. [02:19:20 CEST] <DelphiWorld> official ffmpeg hw encoding saying libmfx is required [02:28:59 CEST] <kepstin> the current version of ffmpeg has two different ways to encode using the intel qsv. One is via libmfx, and it's a pain to set up, the other is with vaapi, which is a fair bit easier imo [02:29:26 CEST] <kepstin> all the stuff for the vaapi encoder is readily available in linux distros [02:29:38 CEST] <DelphiWorld> kepstin: but it's a bit complex to use [02:29:44 CEST] <DelphiWorld> upload & download ... complicated [02:29:57 CEST] <DelphiWorld> why i dont just use the "h264_qsv" encoder? [02:30:33 CEST] <kepstin> well, i can't help you with that :) it needs you to install that intel media sdk thing manually, and I've never gotten it to work. [02:30:58 CEST] Action: DelphiWorld hope the FFMpeg dev make it easyer ... [02:31:02 CEST] <DelphiWorld> i realy hope to get it to work [02:31:32 CEST] <c_14> Well, you have to patch the kernel [02:31:35 CEST] <c_14> so... [02:31:40 CEST] <c_14> (last time I checked) [02:31:45 CEST] <kepstin> for vaapi? you don't [02:31:46 CEST] <DelphiWorld> c_14: so kernel patch required ? [02:31:52 CEST] <kepstin> dunno about the intel media sdk stuff. [02:31:53 CEST] <c_14> for qsv [02:32:06 CEST] <DelphiWorld> c_14: give any instruction ? [02:32:15 CEST] <c_14> Never gotten it to work either. [02:32:24 CEST] <DelphiWorld> sadly [02:32:54 CEST] <DelphiWorld> c_14: https://github.com/lu-zero/mfx_dispatch [02:33:18 CEST] <c_14> That'll let you build it [02:33:21 CEST] <c_14> Never got it working though [02:33:26 CEST] <kepstin> Of course, even though I've gotten vaapi to work, I haven't really had any use for it; the encoder is fast, but so is libx264... [02:33:28 CEST] <c_14> Well, I got it to build. [02:33:50 CEST] <kepstin> if you're encoding videos and your cpu is busy doing something else it might be worthwhile [02:33:58 CEST] <DelphiWorld> but qsv should be faster, and LESS CPU usage no? [02:34:10 CEST] <kepstin> qsv and vaapi use the same hardware encoder chip [02:34:15 CEST] <kepstin> they should be pretty comparable [02:34:22 CEST] <vandemar> isn't qsv dependent on proprietary intel libs? [02:34:28 CEST] <DelphiWorld> kepstin: the vaapi usage is a bit complex [02:34:34 CEST] <kepstin> DelphiWorld: not really... [02:34:52 CEST] <kepstin> and if you're doing it regularly you're probably using a script anyways :/ [02:35:06 CEST] <DelphiWorld> :P [02:37:14 CEST] Action: DelphiWorld is building [02:40:43 CEST] <DelphiWorld> autoreconfing libmfx [03:51:20 CEST] <DelphiWorld> yo [03:51:26 CEST] <DelphiWorld> c_14, see this issue: https://trac.ffmpeg.org/ticket/4831 [03:51:31 CEST] <DelphiWorld> not fixed i think [04:23:02 CEST] <thebombzen> I think my question got drowned out by another conversation so I'll ask again just to be safe: [04:23:15 CEST] <thebombzen> I cannot find the duration of GIF file with ffprobe or ffmpeg -i. the duration is "N/A" [04:23:34 CEST] <thebombzen> setting -analyzeduration and -probesize to 2^31-1 didn't help. Any suggestions? [04:24:19 CEST] <thebombzen> (that is, for some reason the duration is still N/A when I use ffmpeg -probesize 2147483647 -analyzeduration 2147483647 -i input.gif [04:25:43 CEST] <pzich> do you need to do it with ffmpeg? it looks like `identify` from imagemagick or `exiftool` can do it: http://www.imagemagick.org/discourse-server/viewtopic.php?t=23276#p97676 [05:45:47 CEST] <thebombzen> pzich: well I'm writing a program that's supposed to analyze a generic video file with ffprobe -show_streams [05:46:03 CEST] <thebombzen> I want it to work if I give it an animate GIF in addition to say, an mkv [05:46:42 CEST] <c_14> thebombzen: you can check packet=pts_time,duration_time then grab the last packet outputted [05:46:55 CEST] <c_14> add duration_time to pts_time and you'll have the duration of the video [05:48:56 CEST] <thebombzen> c_14: you're going to have to elaborate on that one. I don't see duration_time or pts_time in either -show_streams or -show_format [05:49:43 CEST] <c_14> I think it's show_packets? Just use -show_entries packet=pts_time,duration_time [05:49:50 CEST] <c_14> that way you don't also dump all the other info [05:52:24 CEST] <thebombzen> c_14: thanks, that seems to do the trick [05:53:07 CEST] <thebombzen> however c_14 it appears to be somewhat inefficient for a long video [05:53:28 CEST] <thebombzen> as in a regular video file. as in it spits out a LOT of packets. is there a way to make it faster? [05:53:41 CEST] <c_14> sure, it'll have to decode the whole video [05:54:38 CEST] <c_14> If you know about how long the video is at least, you can use read_intervals to skip decoding part of it [05:54:40 CEST] <c_14> but that's about it [05:58:11 CEST] <thebombzen> I think I'm going to use a two-step thing [05:58:14 CEST] <thebombzen> first it'll check format.duration [05:58:25 CEST] <thebombzen> with -show_format. and then it'll check -show_packets only if that fails. [05:58:30 CEST] <kepstin> thebombzen: keep in mind that gif files often (usually) loop, and thus have infinite duration :) [05:58:39 CEST] <thebombzen> no they don't [05:58:47 CEST] <kepstin> I suppose you could use '-ignore_loop 1' [05:58:56 CEST] <kepstin> (demuxer option on the gif demuxer) [05:59:07 CEST] <kepstin> oh, actually, that's on by default [05:59:08 CEST] <kepstin> nvm [05:59:19 CEST] <thebombzen> you can loop a gif with -loop -1 in ffplay [05:59:32 CEST] <thebombzen> or with --loop-file=inf [05:59:34 CEST] <thebombzen> in mpv [08:31:49 CEST] <cowai_> Is there a way I can make this into only one command? I am trying to make type 2 DV in AVI. "ffmpeg -i input-target pal-dv -filter:v "setfield=1, fieldorder=bff" -aspect 16:9 -y /host/media/v/dvtest.dv && ffmpeg -i /host/media/v/dvtest.dv -c copy -tag:v dvsd -y /host/media/v/dvtest.avi" [08:40:40 CEST] <relaxed> you're transcoding dv to dv? [08:43:51 CEST] <relaxed> why is this needed? [08:58:57 CEST] <cowai_> because there is something called type 1 DV and type 2 [08:59:09 CEST] <cowai_> there is no transcoding though, only -c copy [08:59:30 CEST] <cowai_> simply adding -tag:v dvsd to the first command doesnt help. [09:00:16 CEST] <cowai_> ffmpeg does not make a compliant DV AVI file if I simply have an avi extension and add the "dvsd" tag. [09:00:50 CEST] <cowai_> notes on the problem here: http://en.flossmanuals.net/open-video-workbook/hands-on-transcoding-files-w… [09:01:06 CEST] <relaxed> hmm, I think the use of -filter:v means there's transcoding going on. [09:05:02 CEST] <relaxed> try this for a 10 second sample output, ffmpeg -i input -t 10 -c copy -flags +ildct+ilme -top 0 output.avi [09:05:20 CEST] <relaxed> (add your -tag:v) [09:09:41 CEST] <cowai_> ah, the first commands input is not dv [09:09:50 CEST] <cowai_> that is a decklink card. [09:12:50 CEST] <relaxed> ffmpeg -i input -target pal-dv -filter:v "setfield=1, fieldorder=bff" -aspect 16:9 -tag:v dvsd output.avi [09:15:46 CEST] <hero100> how to probe max_bit_rate of video stream in mov container with ffprobe? [09:16:19 CEST] <relaxed> -target might try to force the output format to dv, if that's the case add "-f avi" before the output [09:32:48 CEST] <cowai_> relaxed: if I force avi with "-f avi" the settings from -target is destroyed [09:33:02 CEST] <cowai_> it then tried to have default codec for avi [09:33:11 CEST] <cowai_> mp3 lame and mpeg4 [09:33:55 CEST] <relaxed> can I see a pastebin.com of the command and console output? [09:34:35 CEST] <cowai_> hold on, I trying without -f avi [09:35:06 CEST] <cowai_> I am producing dv for a weird playout, so even when everything looks ok in mediainfo/gspot, it doesnt work. [09:37:11 CEST] <cowai_> relaxed: the files that is produced with "ffmpeg -i input -target pal-dv -filter:v "setfield=1, fieldorder=bff" -aspect 16:9 -tag:v dvsd output.avi" [09:37:11 CEST] <cowai_> cannot be opened in avidemux. [09:38:34 CEST] <cowai_> But if I use "ffmpeg -i output.avi -c copy output_fixed.avi", avidemux opens them immediatly [09:39:33 CEST] <cowai_> there is lots of notes on the web on how to make ffmpeg produce dv avi files, and all of consists of using -c copy a second time. [09:39:36 CEST] <cowai_> No idea why. [09:46:36 CEST] <relaxed> try this, ffmpeg -i decklink-input -t 10 -filter:v "scale=720:576, setdar=dar=16/9, setfield=1, fieldorder=bff" -r 25 -c:v dvvideo -c:a pcm_s16le -tag:v dvsd output.avi [09:49:26 CEST] <cowai_> This command doesnt give the commercial name of "dvcpro" [09:49:39 CEST] <cowai_> which the sample file I have here, has. [09:50:08 CEST] <cowai_> But I will send it that as well to the mcr. [09:50:12 CEST] <cowai_> Thanks [09:51:00 CEST] <cowai_> hold on, it gives me a file with 4 tracks. [09:51:12 CEST] <cowai_> Stream #0:1 -> #0:0 (rawvideo (native) -> dvvideo (native)) [09:51:12 CEST] <cowai_> Stream #0:0 -> #0:1 (pcm_s16le (native) -> pcm_s16le (native)) [09:51:12 CEST] <cowai_> Stream #0:1 -> #1:0 (rawvideo (native) -> mpeg4 (native)) [09:51:12 CEST] <cowai_> Stream #0:0 -> #1:1 (pcm_s16le (native) -> mp3 (libmp3lame)) [09:52:47 CEST] <BtbN> that looks like you have two outputs. [09:53:17 CEST] <cowai_> I dont [09:53:42 CEST] <cowai_> "-t 30 -pix_fmt yuv420p -s 720x576 -c:v dvvideo -c:a pcm_s16le -filter:v "tinterlace=5:1, fieldorder=bff" -aspect 16:9 -tag:v dvsd" this gives me only two tracks [09:54:35 CEST] <BtbN> Well, you have #0 and #1 there. That usually means you have two outputs. [09:54:37 CEST] <cowai_> but doesnt entirely match the attributes in mediainfo like target pal-dv and a second command to copy it to avi. [09:55:16 CEST] <cowai_> nput #0, decklink, from 'DeckLink Mini Recorder@13': [09:55:16 CEST] <cowai_> Duration: N/A, start: 0.000000, bitrate: 1536 kb/s [09:55:16 CEST] <cowai_> Stream #0:0: Audio: pcm_s16le, 48000 Hz, 2 channels, s16, 1536 kb/s [09:55:16 CEST] <cowai_> Stream #0:1: Video: rawvideo (UYVY / 0x59565955), uyvy422, 1280x720, -8 kb/s, 50 tbr, 1000k tbn, 50 tbc [09:56:02 CEST] <BtbN> That's the Input stream. Also, don't flood the channel with pastes, use a pastebin. [09:57:54 CEST] <cowai_> ah, [09:58:08 CEST] <cowai_> I actually had two outputs, silly me. [09:58:23 CEST] <cowai_> yes I will use pastebin next time, sorry [09:59:09 CEST] <relaxed> the fourcc for dvcpro is "dvpp" [09:59:32 CEST] <relaxed> so use -tag:v dvpp [10:00:52 CEST] <cowai_> dvpp is only for hd as I recall [10:01:48 CEST] <cowai_> it says its incompatible with the codec [10:02:40 CEST] <relaxed> ok [10:04:22 CEST] <relaxed> you're right, it's dvsd [10:05:21 CEST] <cowai_> I sent 10 dv files produced by ffmpeg with different options to the playout guys and only the one where I used -c copy a second time worked. [10:38:21 CEST] <relaxed> cowai_: can you pastebin the output from "ffmpeg -i input.avi" on a file that works? [10:47:47 CEST] <cowai_> relaxed: http://pastebin.com/wLdvbZ6z , there is nothing special here. Lots of files have exactly the same info but does not work in the playout in question. [10:51:20 CEST] <relaxed> well, the 4/3 DAR is different [10:55:28 CEST] <MadWasp> How can i check if the video index is at the start or the end of my mp4 file? Id like to see if the videos i encoded are streamable [10:58:43 CEST] <cowai_> yes [10:59:40 CEST] <cowai_> I have two files that works. one 16/9 DAR and one wrongly tagged as 4/3 which actually is 16/9. [10:59:50 CEST] <cowai_> So it shouldnt matter. [12:39:44 CEST] <Schwarzbaer> Hi. Is there a way to change the filter graph without restarting ffmpeg / ffserver? [12:42:49 CEST] <Schwarzbaer> An application that'd come to mind would be a mosaic mixer that changes the mosaic pattern each time an input connects. [13:00:54 CEST] <BtbN> no [13:01:13 CEST] <BtbN> you can send commands to filters, but changing the entire graph is not supported [13:40:20 CEST] <jancoow> furq: mm.. i just think nginx-rtmp is not the best solution [13:48:29 CEST] <BtbN> There aren't a lot of alternatives available to it. [13:48:34 CEST] <BtbN> And it works quite well. [13:49:50 CEST] <jancoow> i was looking at zoneminder now [13:50:42 CEST] <BtbN> That looks like something entirely diffrent. [13:50:55 CEST] <jancoow> is it? [13:51:12 CEST] <BtbN> That's some surverilance software from the looks of their website. [13:51:27 CEST] <jancoow> and where was i looking for? :) [13:51:49 CEST] <BtbN> No idea, you only talked about nginx-rtmp without any context. [13:52:13 CEST] <jancoow> was talking to furq expeccialy becuase i talked to him yesterday about it, but i repeat my question: [13:52:32 CEST] <jancoow> Hay there; I'm just asking a general question. I also talked to someone here a while ago, but have some other questions. I'm working on a surveilance system in my house. Because of my home automatic system there is already 1 raspberry pi in each room. What i want to achieve is to connect a (cheap) usb webcam to each raspberry. Each raspberry has to do live transcoding to a file mp4 or avi file format or something. [13:52:34 CEST] <jancoow> Then i want to stream / save this video on my local fileserver (so a general file stream over samba for example). Eventually i want to stream to my browser, but that will be handled on the server. What do you guys think? Is this possible? Is it possible to use the raspberry pi gpu to do the live encoding? [14:25:10 CEST] <jancoow> silence <.< [14:25:24 CEST] <ChocolateArmpits> Wel lthat depends if the gpu has a hardware encoder [14:25:35 CEST] <ChocolateArmpits> and not just decoder [14:26:14 CEST] <jancoow> well in the mean time i figured out that it has one, but only works with the raspicam [14:27:49 CEST] <jancoow> just looking for a good server side solution [14:27:53 CEST] <jancoow> with http stream [14:31:16 CEST] <Fyr> can FFMPEG mux H265 into MP4 container? [14:33:16 CEST] <ChocolateArmpits> Fyr: yes [14:50:42 CEST] <Fyr> ChocolateArmpits, can FFMPEG mux SRT subtitles into MP4 container? [14:52:45 CEST] <JEEB> it can convert them to the format of timed text that ISOBMFF can handle, yes [14:52:54 CEST] <JEEB> I think it's called mov_timed_text or whatever [14:53:20 CEST] <Fyr> mp4 supports 3GPP timed text and MPEG4 timed text. [15:02:22 CEST] <JEEB> I think they're the same thing [15:02:56 CEST] <JEEB> unless my memory derps at me. and since the format originated from MOV it's called like that for hysterical raisins [15:03:11 CEST] <JEEB> so if you -i lulz.srt and output .mp4 it should get converted to mov_text or whatever [15:34:00 CEST] <Eduard_Munteanu> Hi. Is there some codec which can be decoded fast enough without hw acceleration for HD (720p) videos, without a lot of CPU usage? [15:34:34 CEST] <Eduard_Munteanu> I mean, a reasonably good one. Raw files don't really count because I/O is the bottleneck then. [15:41:46 CEST] <Fyr> divX? [15:55:37 CEST] <Spring> hey, does anyone know what the deal is with the missing 'sharpness' option? [15:55:39 CEST] <Spring> http://wiki.webmproject.org/ffmpeg [15:56:01 CEST] <Spring> This lists it as being available for VPx yet when I go to encode it says the option doesn't exist [16:12:26 CEST] <Danimal> I'm trying to figure out the difference between -framerate and -r. if I use -framerate on the gdigrab input, and -r on the output, the rates don't line up, and I get duped frames. if I use -r on both input and output, after 7.5 hours or so my rtbuffer fills up and my audio becomes unintelligible. [16:38:24 CEST] <kepstin> Danimal: ok, so -r is a funny option [16:38:47 CEST] <kepstin> if used as an input option, it causes the timestamps on the source to be *ignored*, and it rewrites them as constant fps [16:39:08 CEST] <kepstin> this will obviously cause desync if the rate isn't exactly right (and with gdigrab, it never will be) [16:39:42 CEST] <kepstin> as an output option, it's identical to adding '-vf fps=[...]', which means it duplicates, drops, and retimes frames to be constant fps [16:40:03 CEST] <kepstin> the '-framerate' input option on gdigrab is what actually sets the rate at which frames are captured live [16:40:23 CEST] <kepstin> the way it works, is gdigrab grabs a frame, sleeps until it is supposed to get the next frame, repeat. [16:40:59 CEST] <kepstin> this is obviously a bit inexact, so the result is variable framerate video (and gdigrab is kinda slow, too, so it might not be able to keep up with the requested framerate) [16:41:34 CEST] <kepstin> so: If you are OK with variable framerate video, use "-framerate" on input and no "-r" anywhere. [16:42:06 CEST] <kepstin> if you need constant framerate video, use "-framerate" on input and "-r" (or "-vf fps") on output, and accept that there'll be some duplicated/droppped/retimed frames. [16:43:10 CEST] <kepstin> Danimal: hope that helps explain things :) [17:11:49 CEST] <Spring> errm, anyone know of builds that support both VPx and the new dynaudnorm filter? [17:12:23 CEST] <Spring> been using these http://ffmpeg.zeranoe.com/builds/ but apparently they lack the dynamic normalizer filter [17:14:58 CEST] <Spring> https://ffmpeg.org/ffmpeg-filters.html#dynaudnorm [19:03:04 CEST] <gem606> does ffmpeg support the compression of a 64-bit h264 format into a 32-bit h264? [19:03:45 CEST] <BtbN> What's 64 and 32 bit h264? [19:04:05 CEST] <DHE> h264 isn't CPU architecture-specific if that's what you mean [19:04:14 CEST] <BtbN> do you mean 10/12bit vs. 8bit? [19:08:38 CEST] <hyponic> I am willing to pay to whoever can make FFMPEG change teletext subtitles to dvbsubtitles while transcoding a live stream. [19:22:20 CEST] <jancoow> teletext subtitles [19:22:25 CEST] <jancoow> do people still use these? [19:24:20 CEST] <DHE> is that the same as the ATSC subtitles? [19:24:26 CEST] <hyponic> jancoow yeah.. there are some streams that still use that. [19:26:15 CEST] <gem606> I'm referring to cpu which is probably unrelated to the conversion [19:34:01 CEST] <strongcoffee> is there an ffmpeg frontend that supports 2 pass encoding (via a checkbox) and doesn't suck? [19:34:14 CEST] <strongcoffee> I must have tried half a dozen and they all lack something [19:34:50 CEST] <strongcoffee> just need something that supports direct command line options, input/output, and a 2 pass checkbox [19:35:09 CEST] <strongcoffee> it's frustrating how hard this is to find [19:43:47 CEST] <ChocolateArmpits> Why not just use the CLI? [19:44:04 CEST] <ChocolateArmpits> I mean you need exactly what's there already [19:44:08 CEST] <strongcoffee> ChocolateArmpits, I need 2 pass to be automated for users [19:44:16 CEST] <ChocolateArmpits> You can write a script for that [19:44:29 CEST] <ChocolateArmpits> Is an application mandatory? [19:44:59 CEST] <strongcoffee> needs to be something that is simple for the user, essentially [19:45:29 CEST] <ChocolateArmpits> Scripts seem easy, drag and drop [19:45:45 CEST] <strongcoffee> ChocolateArmpits, you mean a batch script? [19:45:58 CEST] <ChocolateArmpits> Yeah, if you're on Windows [19:46:04 CEST] <ChocolateArmpits> Can be Powershell too [19:46:35 CEST] <strongcoffee> didn't realize batch scripts support D&D [19:46:56 CEST] <ChocolateArmpits> Oh you can try this http://winff.org/html_new/ [19:47:08 CEST] <ChocolateArmpits> The documentation says it has a 2pass checkbox [19:47:20 CEST] <ChocolateArmpits> >2Pass check box will run Ffmpeg twice on the [19:47:21 CEST] <ChocolateArmpits> same video [19:47:41 CEST] <strongcoffee> from a quick search seems like there's one caveat with batch scripts in they don't support special characters in the path, from a stackoverflow [19:47:48 CEST] <strongcoffee> but that's not too bad [19:48:27 CEST] <strongcoffee> this one is nice but the dev refuses a 2 pass option because 'it makes no difference' https://sourceforge.net/projects/ffmpegyag/ [19:48:30 CEST] <strongcoffee> UGHH [19:48:51 CEST] <strongcoffee> they even previously had a checkbox but it was removed. Just why. [19:49:06 CEST] <strongcoffee> I've done comparisons and 2 pass is vastly better quality [19:49:09 CEST] <ChocolateArmpits> strongcoffee: ceck my link [19:49:12 CEST] <ChocolateArmpits> check [19:50:17 CEST] <strongcoffee> ChocolateArmpits, yeah saw that. Might give it a whirl. Nice thing about the one I just linked is the live timecode A-B cropping. [19:50:26 CEST] <strongcoffee> which almost none have [19:53:36 CEST] <jancoow> Hay there; need to stream a webcam with ffserver [19:53:59 CEST] <jancoow> Ffserver part is all setup, but ffmpeg giving me errors with v4l2 https://jancokock.me/f/72597 [19:55:29 CEST] <jancoow> it says [video4linux2,v4l2 @ 0x55944f66da60] Cannot find a proper format for codec 'none' (id 0), pixel format 'none' (id -1) [19:55:52 CEST] <jancoow> when running ffmpeg -f video4linux2 -r 2 -s 352x288 -i /dev/video0 http://localhost:8090/feed1.ffm [20:09:21 CEST] <UnDeRsOuL> hello, I have ffmpeg in OS X (10.5.5) compiled by brew. I wanted to know how can I list all colorspace/pixel format soported by avfoundation [20:09:49 CEST] <UnDeRsOuL> get an output like this https://bugs.chromium.org/p/chromium/issues/detail?id=346634 [20:13:39 CEST] <strongcoffee> hold on, why am I reading that people saying 'dont use CRF 2 pass'? I've used it and the difference is obvious [20:14:08 CEST] <furq> obvious compared to what [20:14:15 CEST] <strongcoffee> CRF vs CRF 2 pass [20:16:32 CEST] <furq> are you saying 2-pass crf gives a better result at the same filesize [20:16:56 CEST] <furq> with x264 [20:17:09 CEST] <strongcoffee> furq, at a smaller filesize actually, yes. No, using VP9 encoding. [20:17:13 CEST] <furq> oh [20:17:22 CEST] <furq> christ knows what libvpx does then [20:17:31 CEST] <furq> it's definitely not true for x264 [20:17:53 CEST] <strongcoffee> well, the difference is night and day using -crf 8 with 2 passes in ffmpeg [20:18:02 CEST] <strongcoffee> vs not [20:18:15 CEST] <furq> are people saying to not use 2-pass crf specifically with vp9 [20:18:40 CEST] <furq> it might just be received wisdom because that traditionally has no effect other than wasting time [20:18:45 CEST] <strongcoffee> no, but all the online results are filled with 'CRF vs 2-pass' and '2 pass is unncessary with CRF' [20:19:36 CEST] <strongcoffee> so CRF must behave differently with vpx [20:19:39 CEST] <strongcoffee> or something [20:19:59 CEST] <furq> it should be true of anything, but i guess libvpx just has shitty ratecontrol [20:20:19 CEST] <furq> i've not really used it enough to say for sure [20:26:54 CEST] <strongcoffee> I will say though, vpx encoding takes FOR...EV...ER. Always has. Wish it was faster. [20:26:59 CEST] <strongcoffee> h.264 just flies by like it ain't no thing [20:35:00 CEST] <Mac101> hi, was wondering if someone could help me with the stereo3d filter, im using "mpv -vf stereo3d=sbsr:sbsl" on a media pc plugged into a 3dtv. The glasses/tv combo i have doesnt let me switch left/right. The mpv line work for some 3d sbs mkv files but not others? [20:35:19 CEST] <Mac101> instead it reverts to mono output? [21:08:23 CEST] <Mac101> hi, anyone? right now im stuck with wearing upside down glasses :/ [21:27:07 CEST] <Mac101> o.o [21:32:02 CEST] <basisbit> Mac101, this is IRC. wait a few hours for an nswer.. [21:35:22 CEST] <ozette> i have a .mp4 of 500mb, can i chop the video up in parts of for example 50kb with ffmpeg? [21:35:45 CEST] <ozette> or for example 30 seconds each [21:46:19 CEST] <ChocolateArmpits> ozette: use segmenter [21:47:45 CEST] <ozette> ChocolateArmpits: sounds promising, i will have a look, thanks [21:48:31 CEST] <ozette> i heard ffmpeg also has a segment option [21:49:33 CEST] <furq> ozette: https://www.ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_… [21:51:27 CEST] <blue_misfit> hey guys, what is ffmpeg doing when I supply it with a single track of audio containing 8 channels (5.1+2.0) and -map 0:a:0 -ac 2 [21:51:42 CEST] <blue_misfit> is it intelligently grabbing the 2.0 or is it somehow downmixing everything to 2ch? [21:52:00 CEST] <ozette> furq: i happened to stumble on this page just as you linked it to me, thanks :) [21:53:25 CEST] <furq> blue_misfit: i assume it's downmixing [21:53:33 CEST] <furq> if you want to be sure then use the pan filter [21:54:09 CEST] <blue_misfit> thanks [21:54:38 CEST] <furq> -af "pan=stereo|c0=c7|c1=c8" [21:54:50 CEST] <furq> er [21:54:54 CEST] <furq> -af "pan=stereo|c0=c6|c1=c7" [21:55:12 CEST] <blue_misfit> what about -map_channel 0.1.6 -map_channel 0.1.7 -c:a pcm_s16le [21:56:18 CEST] <furq> that should work too [21:56:35 CEST] <blue_misfit> cool, many thanks @furq [22:11:34 CEST] <Mac101> hmm [22:26:16 CEST] <c_14> Mac101: are you sure the input is sbsr? [22:26:52 CEST] <Mac101> hi [22:27:22 CEST] <Mac101> i have tried sbsr:sbsl & sbsl:sbsr [22:27:39 CEST] <Mac101> it falls back to mono on some files [22:27:52 CEST] <Mac101> its odd some work fine [22:28:00 CEST] <c_14> Does it log anything? [22:29:16 CEST] <Mac101> [ffmpeg/video] mjpeg: ignoring invalid SAR: 0/0 [22:29:32 CEST] <Mac101> comes up in yellow on files that dont play right [22:29:53 CEST] <c_14> That only pops up on files that don't play right? [22:30:02 CEST] <c_14> What does the video look like without the filter? [22:30:11 CEST] <Mac101> that dont play correctly* [22:30:31 CEST] <Mac101> on all my 3d mkvs half half side by side [22:30:48 CEST] <Mac101> when the swap doesnt work it merges the images [22:32:01 CEST] <Mac101> i can paste full outputs online or provide samples [22:32:15 CEST] <c_14> Yeah, maybe a short sample would help [22:32:15 CEST] <Mac101> if anyone is willing to take a look [23:07:46 CEST] <strongcoffee> is there a way of applying no scaling using -vf scale= ? [23:07:55 CEST] <strongcoffee> apart from not using it [23:08:06 CEST] <strongcoffee> can the value be left blank? [23:08:37 CEST] <c_14> strongcoffee: -vf scale=iw:ih [23:09:00 CEST] <c_14> It should probably no-op in that case, don't know if it actually does though [23:09:22 CEST] <Bray90820_> Is there a way to convert MKV files to MP4 without loosing video quality [23:09:32 CEST] <c_14> bray90820: -c copy [23:09:46 CEST] <Mac101> thank you c_14! [23:10:42 CEST] <Bray90820> ffmpeg "video.mkv" -c copy -c:a copy "video.mp4"? [23:10:49 CEST] <Bray90820> I am also passing through the audio [23:10:57 CEST] <Bray90820> c_14: [23:11:08 CEST] <c_14> -c copy will apply to all streams, no need to explicitly mention -c:a copy [23:11:39 CEST] <Bray90820> -c:a copy is for the audio is it nor? [23:11:46 CEST] <Bray90820> *Not [23:12:15 CEST] <c_14> yes, but -c copy already applies to all streams (video, audio, subtitle) so there's no explicit need to also copy the audio streams since it's done implicitly [23:19:24 CEST] <Bray90820> c_14: I might be missing something here what about ffmpeg -i "video.mkv" -c:a copy "video.mp4" if the -c copy applies to everything or is the A doing only the audio? [23:20:19 CEST] <c_14> the :a specifies all the audio streams, :v would be all the video streams, :s all the subtitle streams etc [23:20:39 CEST] <c_14> https://ffmpeg.org/ffmpeg.html#Stream-specifiers-1 [23:22:03 CEST] <Bray90820> c_14: last question would the syntax be"ffmpeg -c "video.mkv" "video.mp4"? [23:22:16 CEST] <c_14> no [23:22:21 CEST] <c_14> ffmpeg -i video.mkv -c copy video.mp4 [23:23:23 CEST] <Bray90820> Aaahhh thanks [23:23:40 CEST] <Bray90820> Just to check that will keep 100% video quality? [23:23:47 CEST] <c_14> yes [23:24:35 CEST] <Bray90820> Thanks [23:25:06 CEST] <Bray90820> what about? ffmpeg -i "video.mkv" -c:a copy "video.mp4" [23:25:25 CEST] <c_14> that will copy the audio and reencode the video [23:25:36 CEST] <Bray90820> I see [23:25:41 CEST] <Bray90820> Thanks that helps alot [23:25:47 CEST] <Bray90820> Now to go test it out [23:26:56 CEST] <ChocolateArmpits> Is there any place I can find interlaced sd ntsc video samples ? [23:27:09 CEST] <ChocolateArmpits> xiph media has everything in progressive only [23:27:15 CEST] <c_14> ChocolateArmpits: try samples.ffmpeg.org [23:27:50 CEST] <anticw> when using mpegts, derives by using ffmpeg to convert rtsp into mpegts ... i'm pulling the pkts apart and looking at the pids, i see 0, 17, 256, 257 and 4096 [23:28:12 CEST] <ChocolateArmpits> c_14: oh cool didn't know of that [23:28:20 CEST] <anticw> googling tells me 256 and 257 are video and audio respectively (untested), curious what 17 and 4096 are [23:29:39 CEST] <Bray90820> c_14: [mp4 @ 0x7fc8ab00d000] pts has no value [23:29:48 CEST] <Bray90820> I get that error when I don't reencode [23:30:19 CEST] <c_14> error or warning? [23:30:45 CEST] <Bray90820> Uh not syre [23:30:49 CEST] <c_14> error means the encoding aborts [23:30:57 CEST] <Bray90820> Warning then [23:31:11 CEST] <c_14> ignore it, the input video is slightly messed up but it should be fine [23:31:48 CEST] <Bray90820> The input is a really weird VOB file so yes it is messed up [00:00:00 CEST] --- Thu Jun 30 2016

1 0

ffmpeg-devel.log.20160628
by burek 29 Jun '16

29 Jun '16

[00:00:57 CEST] <nevcairiel> fritsch: the reason why using the stream->codec was bad is that it was used by too many things for different purposes .. the parser in avformat uses it, the decoder on your end uses it .. and those two parse/decode different frames from different points in the bitstream, so you end up with an inconsistent state [00:01:12 CEST] <nevcairiel> fritsch: so its much cleaner for you to just get codec parameters from avformat and manage your own codec context [00:06:35 CEST] <nevcairiel> (which is really only like 3 more calls, two creation and one deletion) [02:31:08 CEST] <cone-414> ffmpeg 03Michael Niedermayer 07master:0a72b6988997: MAINTAINERS: remove 2.4 as 3.1 was released [02:31:08 CEST] <cone-414> ffmpeg 03Aman Gupta 07master:4448f16ef51b: avcodec/ccaption_dec: implement tab offset commands [02:34:18 CEST] <ubitux> michaelni: for (int i = 0; i < lo - 0x20; i++) { [02:38:21 CEST] <cone-414> ffmpeg 03Michael Niedermayer 07master:6cc4c422265a: avcodec/ccaption_dec: Fix mixed declaration and statement. [02:38:26 CEST] <michaelni> ubitux, fixed [03:25:35 CEST] <cone-414> ffmpeg 03Michael Niedermayer 07master:c0cb53cd1f91: avdevice/decklink_common: Replace rare spelling of Succesfully by 500 times more common one [04:57:30 CEST] <rcombs> atomnuker: playing this file results in lavc asking me to upload a sample, so here ya go (if you're interested): http://eraser.de-ge.so/dl/bs11_aac_switch.ts [04:58:06 CEST] <rcombs> "Remapped id too large" and some other things (some of which are likely a result of the file being badly trimmed) [05:27:59 CEST] <andrey_turkin_> pfelt: as I noted before you do need to fix decklink decoder. Ensure data going into queue_put is properly reference counted. [05:30:18 CEST] <andrey_turkin_> basically replace av_init_packet&manual setting of pkt.data/size with av_packet_from_data [05:41:08 CEST] <pfelt> andrey_turkin: this in ref to my email to the list? [05:41:17 CEST] <andrey_turkin_> yes [05:41:42 CEST] <pfelt> ah. if you'd said that before i completely missed it [05:45:27 CEST] <pfelt> andrey_turkin: ok. so it looks like i can get rid of something like 4 lines and replace it with av_packet_from_data() [05:45:46 CEST] <pfelt> (init call, data, size (which is two lines in code)) [05:46:15 CEST] <pfelt> and i see there are multiple calls to init i'll have to replace [05:50:28 CEST] <andrey_turkin_> also don't forget to unref if queue_put fails [06:13:54 CEST] <pfelt> andrey_turkin: if it does succeed, the pkt gets unref'd somewhere else deeper in libav*, if i'm following right [06:19:56 CEST] <andrey_turkin_> right. queue_get or queue_flush or whatever will take care of that [06:21:50 CEST] <pfelt> sadly i can code it up tonight, but not test it. [07:42:46 CEST] <j-b> 'morning [07:47:46 CEST] <kierank> i need an intern, is it kosher to mention this on ffmpeg-devel [08:37:08 CEST] <fritsch> nevcairiel: that's what I did - thx to andrey_turkin_ that told me [08:38:00 CEST] <fritsch> andrey_turkin_ nevcairiel I got another question though, the old api returend the number of bytes from the pkt used to e.g. decode to a frame. Is this the same as when you call: av_frame_get_pkt_size(m_pFrame1); after the receive_frame call? [08:38:30 CEST] <nevcairiel> the new api always consume entire packets [08:38:33 CEST] <nevcairiel> +s [08:38:46 CEST] <nevcairiel> it says so in the docs. :) [08:39:27 CEST] <fritsch> okay, so the it always return pkt->size? [08:39:34 CEST] <fritsch> so, one can assume that [08:40:04 CEST] <fritsch> err, one can assume that send_packet always eats the whole avpkt [08:40:06 CEST] <fritsch> good [08:40:28 CEST] <nevcairiel> you may need to call receive several times after send so the entire packet is consumed [08:40:33 CEST] <nevcairiel> but the api docs should explain that [08:40:54 CEST] <nevcairiel> you get EAGAIN when the other of the function pair needs to be called first [08:42:07 CEST] <fritsch> http://paste.ubuntu.com/18013162/ [08:42:17 CEST] <fritsch> okay [08:43:29 CEST] <nevcairiel> thats really the entire reason why we have a new api, to allow a m:n relationship between input and output [08:44:14 CEST] <fritsch> okay, I got it [08:44:19 CEST] <fritsch> will handle the EAGAIN directly [08:44:22 CEST] <fritsch> for send and receive [09:23:58 CEST] <durandal_1707> kierank: take me [09:24:41 CEST] <kierank> I think you are too expensive for us ;) [09:27:50 CEST] Action: durandal_1707 thinks atomnuker is starving [10:20:59 CEST] <mateo`> ubitux, nevcairiel: are you currently working on the next merge ? [10:43:36 CEST] <nevcairiel> not me, i'm trying to fix some fate failure [10:45:25 CEST] <ubitux> mateo`: i'm not [11:18:44 CEST] <michaelni> ubitux, there are some inaccuracies on coverage.ffmpeg.org like (av_file_map is marked as not exeuted but it should be from libavutil/tests/file.c also unmap is executed ...) [11:20:23 CEST] <michaelni> i can only guess blindly that the compiler inlined it and then lost track what actually got executed [11:29:45 CEST] <atomnuker> rcombs: I'll look into it when I get the chance to, but it might be just a cut/corrupt bitstream [12:15:03 CEST] <ubitux> michaelni: dunno& [12:15:09 CEST] <ubitux> nevcairiel: http://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195483.html did you see that? [12:15:21 CEST] <ubitux> (related to the VS problem) [12:15:55 CEST] <mateo`> 0cd5e281df3f69c1ed8f2a72a5bcbf9691e1b5d5 introduced a regression on some devices (which requires the nal headers to be present in the pps/sps), I'll send a fix asap (and will backport to the 3.1 branch) [12:21:01 CEST] <nevcairiel> ubitux: so pnmdec is maybe just buggy as f' ? :) [13:11:46 CEST] <andrey_turkin> nevcairiel: mind posting objdump of pnmdec.o on gist or something? [13:17:25 CEST] <nevcairiel> andrey_turkin: http://pastebin.com/3hmk87ck .. not thats its very readable :) [13:21:07 CEST] <andrey_turkin> no relocations there. yes, not that readable ) [13:34:06 CEST] <andrey_turkin> not that optimized [13:43:34 CEST] <andrey_turkin> nothing obviously wrong that I can see around init_put_bits. and I expected better optimization than that [13:45:50 CEST] <nevcairiel> well it is pretty generic code [13:46:24 CEST] <nevcairiel> init_put_bits seems to be inlined, and my guess is that it screws that up then [13:46:34 CEST] <andrey_turkin> doen't look that way [13:46:47 CEST] <nevcairiel> there is no reference to it calling init put buts [13:47:02 CEST] <andrey_turkin> it is inlined but I don't see any obvious errors there [13:48:09 CEST] <nevcairiel> well i dont know where the actual issue is in the asm, a single code change like that can change the entire optimization as it needs another register and things [16:25:09 CEST] <pfelt> andrey_turkin: per your suggestion, i replaced all the av_init_packet() calls with av_packet_from_data() and removed manual sets to both AVPacket::size and AVPacket::data and it segfaults now [16:28:57 CEST] <nevcairiel> you still need av_init_packet i think [16:29:22 CEST] <nevcairiel> av_packet_from_data only replaces setting data/size [16:34:21 CEST] <pfelt> grumble [16:34:52 CEST] <pfelt> i can try adding them [16:40:03 CEST] <pfelt> nevcairiel: it still faults for me [16:40:13 CEST] <pfelt> different place though, i'm trying to figure out why [16:41:36 CEST] <BBB> is this still decklink? [16:41:49 CEST] <BBB> dont we have a decklink module maintainer that can do that? [16:44:28 CEST] <pfelt> i'm in decklink yeah. i submitted a couple of patches last night and got some pointer that i was doing it wrong [16:45:33 CEST] <pfelt> which oddly don't happen when i don't use av_packet_from_data() and then unref in a couple of places [16:47:36 CEST] <nevcairiel> packet from data makes a refcounted packet, so the data needs to be owned by you since ownership transvers to the packet [16:52:04 CEST] <pfelt> well, i'll leave that change to a future fix. it still works in the old non-ref counted model. it needs to be changed, but i'm thinking now isn't the right time. [17:18:25 CEST] <andrey_turkin_> ah, damn it. sorry pfelt I totally misled you. Looks like there is no existing function to just clone data into new packet. So probably best way to tackle this is to use av_new_packet and memcpy [17:19:13 CEST] <pfelt> we'll revisit that once i finish up a couple of other things. there seems to be a lot of work here [18:39:35 CEST] <ubitux> michaelni: if you're interested; http://sprunge.us/KfXB [19:32:07 CEST] <fritsch> now I got it - marillat is the debian-multimedia author, though his kodi packages are unsupported by us - as we never know what he currently bumps into them. So if he says: kodi is broken - that's worth not worth much for now. [19:59:11 CEST] <ubitux> fritsch: i hope the issue is not because we introduced an abi issue between 3.0 and 3.1 [19:59:49 CEST] <ubitux> because in such case, that's indeed a mistake from us [20:00:11 CEST] <ubitux> i wouldn't be surprised at all if that was the case [20:01:24 CEST] <Compn> didnt we have a kodi dev ? [20:01:28 CEST] <Compn> to test our releases ? [20:03:44 CEST] <ubitux> it's not related to kodi afaict from the very first sentence [20:17:31 CEST] <fritsch> ubitux: he replied [20:17:34 CEST] <fritsch> ubitux: see what he did [20:17:49 CEST] <fritsch> he bumped from ffmpeg 3.0.2 to 3.1 and did not rebuild kodi against it [20:17:54 CEST] <fritsch> and soname was bumped [20:18:03 CEST] <fritsch> so I don't know why he expects it to work [20:18:16 CEST] <fritsch> Compn: ffmpeg 3.1 is fine with kodi (including the deprecated api) [20:18:28 CEST] <fritsch> we just found one regression for now concerning dvd menus but are on it [20:18:55 CEST] <ubitux> there should be no abi breakage on minor bumps [20:19:04 CEST] <jamrial> fritsch: 3.1 has the same major version for all libraries as 3.0 [20:19:07 CEST] <ubitux> so why would it be a problem? [20:19:23 CEST] <fritsch> wasn't there a bump cause of the dxva hevc-10 bit addition? [20:19:30 CEST] <ubitux> major? [20:19:53 CEST] <fritsch> now as you ask me - I am not sure anymore, but thought from 56 to 57 or something [20:20:00 CEST] <ubitux> http://ffmpeg.org/download.html is see no major versions mismatch between 3.0.x and 3.1.x [20:20:16 CEST] <fritsch> okay [20:20:22 CEST] <fritsch> so - it should work [20:21:16 CEST] <jamrial> lavf mp3dec got only five commits since february (3.0 release date) [20:23:14 CEST] <fritsch> such things we (kodi) don't catch as our official builds are all static [20:24:22 CEST] <jamrial> codecpar conversion, some change to the probe function and 1c9215e5 which is the only notable change to header parsing [20:25:06 CEST] <ubitux> what happened to upstream-tracker.org? [20:25:34 CEST] <fritsch> jamrial: if he rebuilds against 3.1 - all is fine for him [20:26:06 CEST] <fritsch> so I don't think there is a problem in mp3 parsing [20:50:32 CEST] <jamrial> ubitux: http://upstream.rosalinux.ru/ they aren't running checks anymore [21:02:17 CEST] <fritsch> jamrial: https://dav.saraev.ca/pub/compat_reports/libavcodec.so.57/3.0.2_to_3.1/comp… [21:02:57 CEST] <fritsch> and here is the rest: https://dav.saraev.ca/pub/compat_reports/ [21:03:25 CEST] <fritsch> https://dav.saraev.ca/pub/compat_reports/libavformat.so.57/3.0.2_to_3.1/com… [21:04:14 CEST] <nevcairiel> a bunch of our structs include "private" fields by convention, documented as such in the header, those reports dont know about that [21:04:22 CEST] <fritsch> okay [21:04:27 CEST] <fritsch> just trying to help [21:04:27 CEST] <nevcairiel> and flag changes in that areas as problematic [21:04:37 CEST] <fritsch> no finger pointing [21:04:57 CEST] <fritsch> still wondering what breaks for marillat [21:24:58 CEST] <fritsch> from what I see though - the AVCodec struct was broken [21:25:42 CEST] <fritsch> AV_PIX_FMT_NB has been changed from 337 to 341 [21:25:54 CEST] <nevcairiel> NB elements are never part of the public ABI [21:26:14 CEST] <nevcairiel> it just means we got 4 new pixfmts [22:00:28 CEST] <fritsch> seems carl tracked it down to 10424024a16a7646169b9c9008c5f7b77cbc2211 [22:07:36 CEST] <nevcairiel> all context changes in that are documented private [22:08:05 CEST] <jamrial> yet it the problem can be reproduced with ffplay [22:09:30 CEST] <nevcairiel> ffplay and ffmpeg arent the best examples of clean public-only api usage :d [22:13:09 CEST] <ubitux> in the merge, the hw_frames_ctx is not added at the end [22:13:15 CEST] <ubitux> of AVFilterLink [22:13:20 CEST] <nevcairiel> its added in the area marked private though [22:13:28 CEST] <jamrial> doens't matter, it's below the private mark [22:13:29 CEST] <nevcairiel> so it should be fine [23:22:35 CEST] <cone-872> ffmpeg 03Martin Vignali 07master:2bdb26b4eeec: fate/webp : add test for lossy compression. [00:00:00 CEST] --- Wed Jun 29 2016

1 0

ffmpeg.log.20160628
by burek 29 Jun '16

29 Jun '16

[00:56:18 CEST] <blue_misfit> hey guys - I'm dealing with handling input files with a single video track and 7-8 audio tracks [00:56:52 CEST] <blue_misfit> sometimes the video is on track 0 and audio is on 1-7 or 1-8. Sometimes the video is on track 7 or 8 and the audio is on 1-6 or 1-7 [00:57:23 CEST] <blue_misfit> I need to grab one specific track. can I tell ffmpeg "Grab audio track 7" [00:57:30 CEST] <blue_misfit> regardless of the position of the video track? [00:57:54 CEST] <furq> -map 0:a:6 [00:58:36 CEST] <blue_misfit> got it [00:58:37 CEST] <blue_misfit> thank you so much [00:59:55 CEST] <blue_misfit> works perfectly :D [01:12:50 CEST] <hyponic> I am willing to pay to whoever can make FFMPEG change teletext subtitles to dvbsubtitles while transcoding a live stream. [03:29:23 CEST] <Bray90820> Can someone tell me what these errors mean? [03:29:23 CEST] <Bray90820> http://pastebin.com/raw/mjBFuX7A [03:29:56 CEST] <c_14> ffmpeg doesn't like your input [03:30:15 CEST] <c_14> Do you have some sort of video player that plays the file? [03:30:21 CEST] <Bray90820> Yes but why? [03:30:24 CEST] <c_14> If yes, it's a bug in FFmpeg. If no, the file is broken. [03:30:32 CEST] <c_14> What player? [03:30:42 CEST] <Bray90820> VLC plays it just fine [03:30:54 CEST] <c_14> then it might be a regression or fixed in a newer version [03:31:05 CEST] <Bray90820> And all the other MKV files from that disc work just fine with ffmpeg [03:31:20 CEST] <c_14> oh [03:31:23 CEST] <c_14> wait [03:31:27 CEST] <c_14> I see what happened [03:31:47 CEST] <c_14> Did you run that command before? [03:31:59 CEST] <Bray90820> On other files yes [03:32:06 CEST] <c_14> on that file? [03:32:06 CEST] <Bray90820> I have converted many other files [03:32:14 CEST] <Bray90820> I have not ran it on that file [03:32:20 CEST] <c_14> Because that will overwrite that file breaking it [03:32:29 CEST] <kepstin> Bray90820: your input and output filenames are the same in that command, you overwrote the file as it was being read. [03:33:11 CEST] <c_14> kepstin: it should have prompted whether to overwrite or not [03:33:15 CEST] <Bray90820> Well there we go that was dumb [03:33:27 CEST] <Bray90820> Why didn't it prompt me tho? [03:33:45 CEST] <c_14> If he ran it before and said y it would be broken. Otherwise it should still be fine. he didn't use -y [03:34:00 CEST] <c_14> Bray90820: can you still play that file with vlc? [03:34:02 CEST] <kepstin> well, it didn't prompt this time because it failed to open the input, and didn't even get around to starting output [03:34:21 CEST] <c_14> which is why I asked if he'd run it before. But he said he hadn't [03:34:29 CEST] <Bray90820> I can play the MKV version from pre conversion but the MP4 file was not playable [03:34:45 CEST] <c_14> then you probably overwrote the mp4 [03:34:48 CEST] <Bray90820> I am currently reconverting the MKV file to see if it was a typo that I made [03:34:50 CEST] <c_14> If you still have the mkv restart from that [03:35:46 CEST] <Bray90820> Yep currently doing so [03:37:47 CEST] <Bray90820> I am also getting another error with a few other files [03:37:48 CEST] <Bray90820> http://pastebin.com/raw/t0PakWhz [03:38:11 CEST] <c_14> The Past duration thing? [03:38:18 CEST] <c_14> that's not an error [03:38:19 CEST] <c_14> just ignore it [03:38:33 CEST] <c_14> ah, no [03:38:37 CEST] <c_14> codec frame size not set [03:38:50 CEST] <Bray90820> What should I do? [03:39:09 CEST] <c_14> No clue, it doesn't look fatal so you can probably ignore it. [03:39:27 CEST] <Bray90820> I'll try to ignore it and see what happens [03:40:23 CEST] <Bray90820> Even tho it is happening every few seconds on that file [03:58:03 CEST] <Bray90820> Yea I reconverted the file and now it's playable [04:40:02 CEST] <sseann> Does anyone know if I can use the prebuilt binary 'arm64/testing(stretch)' on a raspbian jessie system? [04:40:32 CEST] <furq> is it an rpi 3 [04:40:39 CEST] <sseann> 1 modelb+ [04:40:44 CEST] <furq> no, then [04:40:58 CEST] <sseann> do I have to compile it myself in this case? [04:41:08 CEST] <furq> the pi 1 is armv6, which isn't covered by any debian packages [04:41:30 CEST] <sseann> thank you furq [04:42:28 CEST] <furq> i imagine there's a raspbian-compatible repo with ffmpeg somewhere [04:42:46 CEST] <furq> i only have an rpi2 though so i just run debian armhf on it [04:44:24 CEST] <sseann> furq: is armhf (ARMv7) similar to arm64? [04:44:37 CEST] <furq> arm64/aarch64 is armv8 [04:44:40 CEST] <furq> armv7 is 32-bit [05:58:52 CEST] <Bray90820> Uh explain this one to me frame=87880 fps= 75 q=29.0 size= 381382kB time=00:48:52.28 bitrate=1065.5kbits/ [05:58:59 CEST] <Bray90820> the video is less than 42 minutes long [06:05:54 CEST] <c_14> same command as earlier? [06:32:49 CEST] <Bray90820> c_14: Different video file but yes "ffmpeg -i "The Long Long Trailer.VOB" -c:a copy "The Long Long Trailer.mp4" [06:33:57 CEST] <c_14> maybe the timestamps are funky? [06:34:11 CEST] <Bray90820> Is there a way to check the time stamp [06:34:46 CEST] <Bray90820> *timestamp [06:35:06 CEST] <c_14> ffprobe -show_entries packet=pts_time should do it I think [06:36:30 CEST] <Bray90820> Put the video file after that command? [06:36:39 CEST] <c_14> ye [06:36:46 CEST] <Bray90820> Lets find out [06:39:54 CEST] <Bray90820> c_14: http://pastebin.com/raw/HeF6QXAv [06:43:52 CEST] <c_14> eh, you'll probably have to add -count_frames [06:45:33 CEST] <Bray90820> Will that give the time or the amount of frames [06:45:57 CEST] <c_14> that's mainly just to make ffprobe read the whole file [06:46:00 CEST] <c_14> It usually only reads part of it [06:46:38 CEST] <Bray90820> ffprobe -show_entries packet=pts_time -count_frames "video.VOB" [06:46:42 CEST] <Bray90820> Like that? [06:48:28 CEST] <c_14> yeah, though it looks like it should do it correctly without that as well (on the video I'm testing on though) [06:48:36 CEST] <c_14> ah, I think your paste might have gotten cut off [06:48:46 CEST] <c_14> The last packet in your paste doesn't have the closing element [06:48:53 CEST] <c_14> Which is why it only goes to 33 minutes [06:49:00 CEST] <Bray90820> Yes the paste was cut off I didn't wanna take the time to copy it all [06:49:39 CEST] <c_14> you just need the last part [06:50:10 CEST] <Bray90820> Is the command suppose to stop on it's own or do I need to manually stop it? [06:50:19 CEST] <c_14> That'll give you the last pts which should be (pretty close) to the duration [06:50:23 CEST] <c_14> It stops on its own [06:50:26 CEST] <Bray90820> Ok [06:50:35 CEST] <Bray90820> So what command should I run? [06:51:29 CEST] <c_14> ffprobe -show_entries packet=pts_time,duration_time -select_streams v file [06:51:46 CEST] <c_14> that will also give you the duration of the last frame and make it so it only outputs for the video frames [06:57:32 CEST] <Bray90820> c_14: Uh the paste is to big for pastbin [06:57:41 CEST] <c_14> just look at the last few lines [06:59:36 CEST] <Bray90820> c_14: http://pastebin.com/raw/mjTCiwCN [07:01:57 CEST] <c_14> So the last frame with a timestamp is at 41 minutes, but there's a bunch of frames without timestamps, though those might be the dvd_nav_packets (not sure if those count as a video stream) [07:02:22 CEST] <c_14> It might be because of those that the time= is off? [07:02:36 CEST] <Bray90820> maybe e idk but the video file is 41:43 [07:03:54 CEST] <Bray90820> Is it not possible to copy it correctly? [07:07:12 CEST] <c_14> Is the output video actually longer than it should be or is ffmpeg just reporting the wrong time? [07:09:04 CEST] <Bray90820> It is longer [07:10:02 CEST] <c_14> hmm [07:10:06 CEST] <c_14> sounds like it's probably a bug [07:12:53 CEST] <Bray90820> It might me a really screwed up VOB file actually because I put in the DVD and the DVD is longer than 41:43 [07:16:52 CEST] <Bray90820> I am gonna just say the VOB is f***ed because the MP4 is the length of the DVD [09:21:07 CEST] <vandemar> does 10 bit instead of 8 bit encoding (8-bit source) compress noticeably in x265 like it does with x264? A test suggests it doesn't (10bit x265 got larger), but is it supposed to? [09:23:43 CEST] <u0083> ffmpeg -i 264.mp4 -c:a copy -c:s copy -c:v libx265 -preset veryslow -x265-params lossless=1 265.mp4 [09:24:35 CEST] <u0083> i used these params to convert h.264 file to h.265 and supposed output file will smaller than input file [09:25:14 CEST] <u0083> but output file is bigger. of: 1.2G if:600M [09:25:40 CEST] <u0083> anything wrong with my params? [09:25:46 CEST] <vandemar> because you're telling it to encode losslessly. you almost never want to do that. [09:26:29 CEST] <u0083> @vandemar you mean if my input file is not lossless file i shouldn't use `lossless=1`? [09:26:53 CEST] <vandemar> doesn't matter what your input is, if you encode losslessly expect very high bitrate [09:28:20 CEST] <u0083> @vandemar if i try to keep same quality with input file, is there a common params i can use or i have to adjust params due to different input file? [09:29:09 CEST] <vandemar> what do you mean "same quality"? same *visual* quality, approxmimately? I don't know what the standard is for x265. For x264 it's roughly crf=18, so for x265, somewhere between 18 and 23? [09:31:52 CEST] <u0083> @vandemar approximate visual quality. so I think I should use crf to control output. [09:32:18 CEST] <u0083> ffmpeg -i 264.mp4 -c:a copy -c:s copy -c:v libx265 -preset veryslow -x265-params crf=22 265.mp4 [09:32:56 CEST] <u0083> maybe like this, I will have a test. If I am wrong, please let me know [09:35:21 CEST] <vandemar> is the 264.mp4 the original? Encode from the original if possible, not from the x264 encoding [09:37:50 CEST] <u0083> @vandemar i don't have original file. why i do this is try to keep approximate visual quality and save the storage. [11:36:56 CEST] <yagiza> Hello! [11:37:57 CEST] <yagiza> I have some strange problem with g.722 encoding. [11:38:28 CEST] <yagiza> Using FFMpeg libraries for RTP streaming. [11:41:00 CEST] <yagiza> When g.726 encoding is used, no matter which bitrate I specify, it always writes G722-0 in SDP. [11:41:55 CEST] <yagiza> Instead of writing G726-32 for 32000bps or G726-40 for 40000bps. [11:42:21 CEST] <yagiza> When using ffmpeg.exe it's all right. [11:43:23 CEST] <yagiza> I experience problem only when encoding and streaming, using my code. [11:44:21 CEST] <yagiza> I specify bitrate by setting AVCodecContext::bit_rate field. [11:44:32 CEST] <yagiza> What am I doing wrong. [11:44:39 CEST] <yagiza> ? [11:45:24 CEST] <yagiza> Everywhere, where I wrote "g.722" or "G722" read "g.726/G726" [12:00:56 CEST] <c_14> Can you check what bits_per_coded_sample is set to on the AVCodecContext? [12:04:44 CEST] <c_14> It should always clip to at least 2 though [12:04:47 CEST] <c_14> hmm [12:06:17 CEST] <c_14> btw, what version of ffmpeg is this with? [12:09:50 CEST] <c_14> If it's post codecpar (which I believe landed in 3.1) it could be because sdp.c uses codecpar but you're not setting the bitrate there [12:10:23 CEST] <yagiza> c_14, which call should set bits_per_coded_sample field? [12:10:45 CEST] <c_14> The g726 init function handles that [12:11:13 CEST] <yagiza> c_14, yes, I found that already. But when init function of a codec is called? [12:13:38 CEST] <yagiza> c_14, I need it initialized before actual encoding started. 'Cause I use av_sdp_create() to pre-calculate RTP payload types. [12:17:16 CEST] <c_14> It should be initialized after open2 [12:17:21 CEST] <c_14> avcodec_open2 [12:19:02 CEST] <yagiza> c_14, but I don't use that call. [12:19:38 CEST] <c_14> You're using something that calls avctx->codec->init [12:20:08 CEST] <yagiza> c_14, is it avformat_new_stream()? [12:24:20 CEST] <c_14> nah, should be after that [12:40:40 CEST] <yagiza> c_14, hmmm... don't see. [13:11:58 CEST] <Joshua__> Hello. Someone what to exaplain how to convert only the audio track of a video? I want the audio to be ac3 [13:14:28 CEST] <Joshua1> This is the audio: [13:14:29 CEST] <Joshua1> Stream #0:1(ger): Audio: dts (DTS-HD MA), 96000 Hz, 7.1, s32p (24 bit) [13:32:17 CEST] <c_14> Joshua1: ffmpeg -i video -c:v copy -c:a ac3 out.mkv [14:14:44 CEST] <cowai_> anyone know why the scan order attribute is changed on a AVI DV file by simply doing ffmpeg -i dvfile.avi -c copy dvfile2.avi ? [14:15:10 CEST] <cowai_> mediainfo reports the scan type to be interlaced on dvfile.avi, but progressive on dvfile2.avi [14:15:51 CEST] <cowai_> if I take dvfile2.avi into avidemux and simply save it again (without reencoding) it is reported to be interlaced in mediainfo again. [14:15:59 CEST] <cowai_> so there is something ffmpeg does that removes it. [14:17:31 CEST] <cowai_> I have tried both ffmbc and ffmpeg 2.8/3.0 [16:17:49 CEST] <Conder_> hello, parameters -vcodec and -c:v are the same? [16:27:08 CEST] <cowai_> Conder_: yes [17:15:22 CEST] <matwey> Hello. I have to inputs: x11grab video and audio receiving from rtp. I would like the audio and the video be put into the single output stream (say theora or x264). I would like to implement the following rule for syncronisation. Video always goes at the constant framerate, if there is no audio (rtp connection is broken, for instance) then the silence should be encoded instead. Could you please point me which audio/video filter shoul [18:44:17 CEST] <ChocolateArmpits> I have a UDP input and sometimes it stops and then continues after a few seconds. Is there a way to output black frames instead of outputting nothing during those moments ? [18:58:28 CEST] <Conder> hello, with what x265 CRF i should reencode MPEG-4 visual (xvid) video for no visual quality lossless? [19:01:03 CEST] <Conder> *no loss of visual quality :D [19:01:22 CEST] <__jack__> Conder: try 20-23 or something [19:03:47 CEST] <Conder> ty [19:10:50 CEST] <soulshock> is it possible to tell ffmpeg to read all necessary input data from the source file into memory, before starting transcoding? I want to run multiple instances of ffmpeg on the same file and I want to prevent a lot of seeking in the source file [19:12:01 CEST] <DHE> that's what your OS cache is for [19:12:26 CEST] <DHE> it's better served anyway since they can share it rather than all munching up your RAM in several copies of ffmpeg [19:12:42 CEST] <furq> why not run one ffmpeg instance with multiple outputs [19:12:46 CEST] <DHE> also there is a third option. it may be possbile to make ffmpeg [19:12:48 CEST] <DHE> do exactly that [19:12:51 CEST] <furq> hi [19:13:59 CEST] <soulshock> because I'm trying to make ffmpeg run in parallel to use 20-50 instances at the same time and thus speed up overall transcoding time [19:14:16 CEST] <soulshock> each encoding part of the video and then stitching it together after [19:14:48 CEST] <furq> are you using a codec that can't use multiple threads or something [19:15:11 CEST] <soulshock> no it's for x264. but the idea is that 50 machines can transcode 1 hour a lot faster than 1 machine can transcode 1 hour [19:16:13 CEST] <soulshock> this would be for a system for a broadcast company, so we have a lot of transcoding every day. between 100 and 200 hours of source material a day [19:16:29 CEST] <furq> if you're splitting it across machines then what's the point of caching the input file [19:17:14 CEST] <soulshock> each machine would cache it so the source disk doesn't have to perform excessive seeking [19:17:28 CEST] <soulshock> or rather, would cache the part they need. say they would cache 1 minute of the source [19:19:03 CEST] <DHE> 100 and 200 files a day? why not just run each file on a distinct system? [19:20:26 CEST] <soulshock> because this would provide us with the option to scale: add more ffmpeg instances = faster throughput [19:20:58 CEST] <soulshock> faster throughput for the same amount of material [19:22:32 CEST] <furq> well i don't really have a better solution than copying the source onto a tmpfs [19:22:49 CEST] <furq> i hope your storage box has plenty of ram [19:23:39 CEST] <soulshock> heh yeah we discussed storing in memory. though sometimes the source material is 50gb [19:23:47 CEST] <soulshock> it's XDCAM HD 422 at 60 mbit/s [19:24:03 CEST] <furq> copying chunks to a tmpfs on the encoding system is probably a better idea [19:26:33 CEST] <soulshock> I though about that. you mean "ffmpeg -i source.mxf -c copy -t 60 chunk.mxf" e.g.? [19:27:20 CEST] <furq> -i foo -c copy -t 60 1.2.3.4:/tmp/chunk.mxf -ss 60 -t 120 1.2.3.5:/tmp/chunk.mxf [19:27:21 CEST] <furq> etc [19:27:34 CEST] <furq> i'm not sure if that would be frame accurate though [19:28:34 CEST] <furq> er [19:28:39 CEST] <furq> -i foo -c copy -t 60 1.2.3.4:/tmp/chunk.mxf -c copy -ss 60 -t 120 1.2.3.5:/tmp/chunk.mxf [19:29:14 CEST] <soulshock> yeah [19:30:28 CEST] <soulshock> that's worth a shot. should allow the storage to be able to perform adequately [19:32:07 CEST] <soulshock> cheers [19:44:53 CEST] <TenLeftFingers> I'm trying to set up a live stream to DailyMotion with the command (testing with an mp4 for now, but need a webcam eventually): ffmpeg -i ~/ana-pasg.mp4 -vf -re -acodec copy -ar 22050 -vcodec h264 -f flv rtmp://publish.dailymotion.com/publish-dm [19:45:15 CEST] <TenLeftFingers> but get the error "RTMP_ReadPacket, failed to read RTMP packet header" [19:46:54 CEST] <Chocola4> TenLeftFingers: first your -vf command is empty, second -re is an input option, not an output [19:47:29 CEST] <Chocola4> Also there is no "h264" encoder, you probably meant x264 [19:51:31 CEST] <ChocolateArmpits> the error probably happens because the way you formatted your output ffmpeg thinks it's input [20:04:21 CEST] <TenLeftFingers> ChocolateArmpits: thanks, I'll go back through the man page. [20:05:11 CEST] <ChocolateArmpits> TenLeftFingers: I think you can fix your command like this fmpeg -re -i ~/ana-pasg.mp4 -acodec aac -ar 22050 -vcodec x264 -f flv rtmp://publish.dailymotion.com/publish-dm [20:05:31 CEST] <ChocolateArmpits> also you can't resample audio without transcoding it [20:06:00 CEST] <ChocolateArmpits> hmmm x264 supposed to be libx264 [20:06:08 CEST] <ChocolateArmpits> excuse me [20:06:46 CEST] <TenLeftFingers> Yeah, it seems this command isn't a good base to start from. [20:06:58 CEST] <TenLeftFingers> Even changing those still gives errors [20:08:09 CEST] <ChocolateArmpits> any in particular? [20:13:26 CEST] <TenLeftFingers> Unable to find a suitable output format for '22050' [20:13:26 CEST] <TenLeftFingers> 22050: Invalid argument [20:13:38 CEST] <TenLeftFingers> Unable to find a suitable output format for '22050' [20:13:54 CEST] <ChocolateArmpits> Can you paste your command line ? [20:13:59 CEST] <TenLeftFingers> sure [20:14:15 CEST] <TenLeftFingers> ffmpeg -i ~/ana-pasg.mp4 -vf -ar 22050 -vcodec libx264 -f flv rtmp://publish.dailymotion.com/publish-dm [20:14:26 CEST] <ChocolateArmpits> you need to remove -vf [20:14:38 CEST] <ChocolateArmpits> -vf is meant for video filters, but you don't specify any [20:14:47 CEST] <ChocolateArmpits> after it [20:15:08 CEST] <ChocolateArmpits> so ffmpeg ends up thinking that -ar is the argument to -vf and 22050 is the output [20:15:12 CEST] <TenLeftFingers> Okay, so removing -vf I see: RTMP_ReadPacket, failed to read RTMP packet header [20:15:13 CEST] <TenLeftFingers> rtmp://publish.dailymotion.com/publish-dm: Unknown error occurred [20:15:45 CEST] <ChocolateArmpits> I'm pretty sure it needs a key of sorts [20:16:14 CEST] <ChocolateArmpits> did you use it in your command? [20:16:28 CEST] <TenLeftFingers> There is a "Stream Name" ascii string provided by DailyMotion - that could be it. I was wondering what it's role was. [20:16:58 CEST] <kepstin> in most cases, you just add it as a filename on the end of the rtmp url [20:17:03 CEST] <ChocolateArmpits> that looks like one https://dailymotionpartners.zendesk.com/hc/fr/article_attachments/200456612… [20:17:12 CEST] <ChocolateArmpits> just don't share it as it's your personal key lol [20:17:19 CEST] <TenLeftFingers> :) thanks [20:17:24 CEST] <TenLeftFingers> Ill try taht [20:17:25 CEST] <TenLeftFingers> *that [20:17:36 CEST] <ChocolateArmpits> just add a slash after the link [20:17:41 CEST] <ChocolateArmpits> and before the key [20:18:00 CEST] <TenLeftFingers> yep [20:18:35 CEST] <TenLeftFingers> Great, I'm getting 'proper' output on the terminal :) [20:19:01 CEST] <ChocolateArmpits> cheers, you can continue configuring it then to tune the quality [20:19:42 CEST] <TenLeftFingers> And I see the output on DailyMotion! Amazing, thank you so much :) Can I just swap the mp4 for /dev/video0 to get the webcam? [20:21:34 CEST] <ChocolateArmpits> Don't have much idea about that, sorry [20:22:03 CEST] <TenLeftFingers> Yes, it is that simple! [20:22:48 CEST] <shincodex> someone write a better article of compiling this garbage poopsicle for windows [20:22:52 CEST] <shincodex> than on the wiki [20:22:58 CEST] <shincodex> im bleeding my eyeballs out making it work [20:23:11 CEST] <shincodex> ffmpegw32exit [20:52:26 CEST] <_MyStartx_> guys exist a version of ffmpeg for android? [20:57:55 CEST] <kepstin> _MyStartx_: ffmpeg should compile just fine for android, I'd expect there's many android apps using the libraries. [21:00:04 CEST] <_MyStartx_> portable version of ffmoeg should wotk on routed sndroid? [21:00:33 CEST] <furq> if you mean http://johnvansickle.com/ffmpeg/ then no [21:00:35 CEST] <furq> it depends on glibc [21:04:19 CEST] <_MyStartx_> yes ....I understand. .that's it [21:29:20 CEST] <Spring> each binary of ffmpeg has to be manually compiled doesn't it? [21:29:40 CEST] <Spring> in order to update it that is [21:34:42 CEST] <DHE> well, there's no official binary builds. but linux distros and 3rd parties offer them [21:38:50 CEST] <shincodex> I think i did it [21:38:55 CEST] <shincodex> i gained 8 billion xp points [21:39:00 CEST] <shincodex> using mingw [21:39:11 CEST] <shincodex> now to sell guides [21:39:19 CEST] <shincodex> hue hue hue hue [21:57:56 CEST] <shincodex> i compile all of them at once with ffmpeg make file as statics [21:58:11 CEST] <shincodex> then compile them as one dll to rule them all with a class to control the nonsense [21:58:52 CEST] <shincodex> Windows - Make operating systems great again. [21:59:14 CEST] <furq> he seems nice [22:10:02 CEST] <jancoow> Hay there; I'm just asking a general question. I also talked to someone here a while ago, but have some other questions. I'm working on a surveilance system in my house. Because of my home automatic system there is already 1 raspberry pi in each room. What i want to achieve is to connect a (cheap) usb webcam to each raspberry. Each raspberry has to do live transcoding to a file mp4 or avi file format or something. Then i want to stream / save this v [22:10:26 CEST] <furq> jancoow: that cut off after "save this v" [22:10:43 CEST] <jancoow> the reason i wanna use the raspberry pi gpu is to pull of some load from the fileserver because it gonna be 10 - 20 video streams. If it has to be streamed raw over ethernet and live decoded on the server on the same time it asks some bandwith and gpu power [22:10:54 CEST] <jancoow> oh damn.. [22:11:28 CEST] <jancoow> I'm sorry but i gonna repeat the question (please don't mark this as spam) :) [22:11:34 CEST] <jancoow> Hay there; I'm just asking a general question. I also talked to someone here a while ago, but have some other questions. I'm working on a surveilance system in my house. Because of my home automatic system there is already 1 raspberry pi in each room. What i want to achieve is to connect a (cheap) usb webcam to each raspberry. Each raspberry has to do live transcoding to a file mp4 or avi file format or something. [22:11:38 CEST] <jancoow> Then i want to stream / save this video on my local fileserver (so a general file stream over samba for example). Eventually i want to stream to my browser, but that will be handled on the server. What do you guys think? Is this possible? Is it possible to use the raspberry pi gpu to do the live encoding? [22:11:59 CEST] <furq> the rpi has an onboard h.264 encoder, but it's not particularly great, and ffmpeg can't use it [22:12:22 CEST] <furq> although iirc there's some popular webcam capture tool for the rpi which will just output h.264 [22:13:05 CEST] <jancoow> okay mm i though ffmpeg could use it. Do you know which tool can use it? [22:13:25 CEST] <jancoow> does this mean that the cpu of the raspberry pi stays quite low on usage? [22:13:34 CEST] <furq> raspivid [22:13:36 CEST] <jancoow> And do you maybe know if the webcam matters? ;p [22:13:38 CEST] <furq> and yeah it's a hardware encoder [22:14:18 CEST] <furq> last time someone asked this i think my suggestion was raspivid piped to ffmpeg streaming to nginx-rtmp on the main server [22:15:26 CEST] <jancoow> then it was probably me you was talking with :) [22:15:34 CEST] <jancoow> because someone here suggested me to use nginx-rtmp [22:16:00 CEST] <jancoow> a little bit my bad that i didn't save the chat log proparly; did a reinstall of my system so log files where lost :/ [22:17:03 CEST] <jancoow> furq: so you suggest to use ffmpeg to stream towards nginx-rtmp? Why do you prefer this instead of a samba share or something (so a normal file stream) [22:17:43 CEST] <furq> you mentioned streaming it to a browser [22:18:29 CEST] <jancoow> that's true!. But i also want to save video logs for a week or so [22:18:42 CEST] <furq> you can do that with nginx-rtmp [22:18:56 CEST] <jancoow> that's cool! [22:19:11 CEST] <furq> https://github.com/arut/nginx-rtmp-module/wiki/Directives#record [22:19:20 CEST] <jancoow> i was just looking at that :) [22:19:34 CEST] <jancoow> well i will first start with raspivid, check if that works [23:04:43 CEST] <jancoow> furq: uhwm,,, i've been trying but after asking in #raspberrypi they say raspivid is only for raspicamera [23:04:47 CEST] <jancoow> not for usb camera's [23:49:43 CEST] <Sashmo_> does anyone have experiance with selecting programs from a multi program source via UDP? If I make the signal a single program, there is no errors, but if I take the multiple program feed, I get constant errors in the output, can anyone point out what I might be doing wrong? http://pastebin.com/BwvAGBfq [23:50:14 CEST] <Sashmo_> lots of h264 decoder errors, but the same signal as a spts has no problem, its only when its a mpts I get issues [23:51:19 CEST] <sangy> Hi, does anyone know if ffmpeg has rtmp(e) support already? [23:51:33 CEST] <jancoow> i'm currently working on rtmp [23:51:35 CEST] <furq> yes it does [23:51:37 CEST] <jancoow> and it does [23:51:39 CEST] <jancoow> ^ [23:51:40 CEST] <jancoow> :) [23:51:48 CEST] <furq> it's had it through librtmp for ages but it has native support now [23:52:12 CEST] <sangy> nice! [23:52:46 CEST] <sangy> so, does it take any special flags upon ./configure to enable rtmp? or will it figure things out by itself? [23:52:58 CEST] <furq> it's enabled automatically [23:53:06 CEST] <furq> you need one of gcrypt, gmp or gnutls for rtmpe support [23:53:51 CEST] <furq> er, gcrypt or gmp [23:54:13 CEST] <sangy> nice! Thanks! [23:54:24 CEST] <sangy> (and thanks for the awesome work in ffmpeg :) ) [00:00:00 CEST] --- Wed Jun 29 2016

1 0

ffmpeg-devel.log.20160627
by burek 28 Jun '16

28 Jun '16

[02:18:32 CEST] <cone-970> ffmpeg 03Marton Balint 07master:b18d6c58000b: avdevice/decklink: fix mingw portability [02:24:57 CEST] <cone-970> ffmpeg 03Marton Balint 07n3.1:HEAD: avdevice/decklink: fix mingw portability [05:24:20 CEST] <cone-970> ffmpeg 03Marton Balint 07n3.2-dev:HEAD: avdevice/decklink: fix mingw portability [10:31:29 CEST] <saste> hey, anybody interested in reviewing my "lavf: add textdata virtual demuxer and demuxer" patch? [10:38:51 CEST] <mateo`> nevcairiel: are you working on the next libav merge 1e9c5bf ? [10:39:23 CEST] <nevcairiel> not right now [10:39:47 CEST] <mateo`> can I pick it ? [10:40:00 CEST] <nevcairiel> sure [10:40:26 CEST] <nevcairiel> i wont have time until tonight anyway, and maybe not even then [10:45:53 CEST] <cone-802> ffmpeg 03Paul B Mahol 07master:d693392886b8: avformat/mov: parse rtmd track timecode [11:41:39 CEST] <mateo`> I'm having so much fun ... never used so much the space key. [11:42:03 CEST] <ubitux> mateo` the new space master [12:30:00 CEST] <mateo`> ubitux aka the const master ... [12:30:11 CEST] <ubitux> ;) [17:25:28 CEST] <cone-802> ffmpeg 03Diego Biurrun 07master:1e9c5bf4c136: asm: FF_-prefix internal macros used in inline assembly [17:25:29 CEST] <cone-802> ffmpeg 03Matthieu Bouron 07master:39d6d3618d48: Merge commit '1e9c5bf4c136fe9e010cc8a7e7270bba0d1bf45e' [17:25:30 CEST] <cone-802> ffmpeg 03Matthieu Bouron 07master:9eb3da2f9942: asm: FF_-prefix internal macros used in inline assembly [17:39:56 CEST] <cone-802> ffmpeg 03Diego Biurrun 07master:5b1b495c8d21: build: Print a message when generating version scripts [17:39:57 CEST] <cone-802> ffmpeg 03Matthieu Bouron 07master:0fd76d77d60a: Merge commit '5b1b495c8d21600eac694d50f428654a3125e217' [17:41:44 CEST] <fritsch> as it is a deprecation question and I am currently porting to 3.1 I got a non user question (at least I hope so) [17:41:49 CEST] <fritsch> how to access: codec_ctx = stream->codec; [17:41:55 CEST] <fritsch> without running into a deprecation warning [17:42:05 CEST] <fritsch> _all_ examples for 3.1 use it like that [17:42:23 CEST] <fritsch> therefore I wonder what the right way nowadays to do it [17:42:31 CEST] <fritsch> http://ffmpeg.org/doxygen/trunk/transcoding_8c-example.html#a12 [17:46:04 CEST] <cone-802> ffmpeg 03Rick Kern 07master:d9561718135a: Changelog: Add VideoToolbox encoder entry for 3.1 [17:47:07 CEST] <cone-802> ffmpeg 03Rick Kern 07release/3.1:36fcb8cc559a: Changelog: Add VideoToolbox encoder entry for 3.1 [18:01:45 CEST] <andrey_turkin_> examples really should be updated to the latest API [18:03:22 CEST] <cone-802> ffmpeg 03Diego Biurrun 07master:535a742c2695: build: Change structure of the linker version script templates [18:03:23 CEST] <cone-802> ffmpeg 03Matthieu Bouron 07master:0acc170aad99: Merge commit '535a742c2695a9e0c586b50d7fa76e318232ff24' [18:04:21 CEST] <cone-802> ffmpeg 03Clément BSsch 07master:c5566f0a944e: lavc/pnm_parser: disable parsing for text based PNMs [18:11:48 CEST] <BBB> does anyone know if I can use the concat filter in some way to concat the first N frames of a set of video files together? [18:12:22 CEST] <BBB> like, Im wondering if I can do something along the lines of ffmpeg -vframes N -i fileA -vframes N -i fileB [..] -filter_complex concat[..] [output] [18:29:04 CEST] <tomonori> hello, can someone tell how to make ffmpeg to processing frame parallel? currently, I have written a filter that could remove watermark dynamically, but it's too slow, it process frame one by one. Is there any way to make it processing frame parallel? thanks [18:31:58 CEST] <BtbN> no [18:32:37 CEST] <BtbN> filters in ffmpeg are only threaded per-frame, with each thread processing a portion of the same frame. [18:38:22 CEST] <tomonori> if so, can you tell where is the source code that ffmpeg to invoke filter functions? I want to create some threads to preprocessing, I think this can reduce some time in filters [18:46:37 CEST] <iive> BBB: should be possible, the filter just needs each file to start at 0 timestamp [18:47:52 CEST] <BtbN> you can't just filter multiple frames in parallel that way. Filters can depend on processing frames in order. [18:50:36 CEST] <iive> he can buffer frames and unload them done, can't he? [18:52:19 CEST] <iive> tomonori: maybe you should try some SIMD to speed up things first. byte access is the slowest thing there is. [18:53:52 CEST] <tomonori> my filter is very slowly, so that ffmpeg can process 5 frame per second, the reason is I called a 3rd library to analysis the frame. this analysis will takes about 200ms, so I want to using multi-thread to analysis every frame. [18:57:06 CEST] <iive> opencv also supports threading and simd [18:57:16 CEST] <ubitux> BBB: yes; [0]trim=...[f0trimed]; [1]trim=...[f1trimed]; [f1trimed][f2trimed] concat=... ? [18:58:54 CEST] <BBB> thats what Im doing now, it seems kind of convoluted but I guess its ok [18:59:04 CEST] <ubitux> tomonori: BtbN: lavfi has slice threading though [18:59:07 CEST] <BBB> (Im using select=lt(n,..) instead of trim=..) [18:59:13 CEST] <BBB> thats the same thing right? [18:59:24 CEST] <ubitux> mmh with the select filter you might actually decode the whole file [18:59:39 CEST] <BBB> oh right [18:59:39 CEST] <BBB> ok [18:59:43 CEST] <BBB> let me change that [18:59:43 CEST] <BtbN> ubitux, isn't that what I said? Or how does it work? [18:59:44 CEST] <BBB> tnx [19:00:03 CEST] <ubitux> BtbN: right, i misread [19:01:47 CEST] <ubitux> BBB: you can have the filtergraph in a file, with line breaks etc [19:01:59 CEST] <ubitux> if it's getting too convuloted [19:12:09 CEST] <tomonori> how can I get the AVFormatContext from filter? [19:13:51 CEST] <nevcairiel> you cannot [19:15:38 CEST] <tomonori> I need using av_seek_frame() to preprocessing every frame by using multi-threads [19:19:44 CEST] <ubitux> you won't get frame threading in your filter unless you add frame threading support to libavfilter [19:40:47 CEST] <cone-802> ffmpeg 03Diego Biurrun 07master:c5fd4b50610f: build: Simplify postprocessing of linker version script files [19:40:48 CEST] <cone-802> ffmpeg 03Clément BSsch 07master:da7c918e80ed: Merge commit 'c5fd4b50610f62cbb3baa4f4108139363128dea1' [19:48:43 CEST] <cone-802> ffmpeg 03Diego Biurrun 07master:b2d5d6a7f20a: build: Only enable symbol reduction if the compiler does proper DCE [19:48:44 CEST] <cone-802> ffmpeg 03Clément BSsch 07master:85a52a77ce87: Merge commit 'b2d5d6a7f20a255a5f3c9bf539cc507afd909ce5' [19:55:07 CEST] <cone-802> ffmpeg 03Denis Charmet 07master:38f99017e69b: vp9: Return the correct size when decoding a superframe [19:55:08 CEST] <cone-802> ffmpeg 03Clément BSsch 07master:e6d0acd4383d: Merge commit '38f99017e69bd25e88be87117237c29727c25635' [20:01:15 CEST] <pfelt> afternoon all. i'm looking at the decklink stuff and trying to clean up a little more of the code and am having an issue finding where some deprecated functionality went. the decklink module is trying to read AVCodecContext::coded_frame in order to set the frame interlacing. docs say to use quality factor side channel, but interlacing is in the AVFrame. is there an easy way to track down how to go from a AVStream to an AVFrame? [20:11:39 CEST] <cone-802> ffmpeg 03Vittorio Giovara 07master:20a8c78ce0a5: avconv: Do not copy extradata if source buffer is empty [20:11:40 CEST] <cone-802> ffmpeg 03Clément BSsch 07master:8b4d6cc809c2: Merge commit '20a8c78ce0a5baf37f6a94e2d1e57e186b6f4b54' [21:02:26 CEST] <BBB> ubitux: thanks, it looks like its working now [21:03:11 CEST] <BBB> pfelt: coded_frame was internal stuff so its basically gone [21:03:23 CEST] <BBB> pfelt: anything that was exposed in coded_frame should probably not be exposed at all [21:17:33 CEST] <pfelt> BBB: makes sense, but for somereason libavdevice/decklink thought it needed to set interlaced and the field ordering on the frame. is that just not needed at all anymore? [21:18:08 CEST] <BBB> I couldnt possibly imagine why you would set that on coded_frame [21:18:18 CEST] <BBB> in a decoder or demuxer, you set it on AVFrame [21:18:27 CEST] <BBB> in an encoder, the input sets it so the output doesnt need to do anything [21:19:09 CEST] <omerjerk> Hey, How do I write testing code for my patch? Michael mentioned about some "fuzzing" yesterday. [21:19:19 CEST] <BBB> omerjerk: google zuff [21:19:35 CEST] <pfelt> bbb: ok. i'll remove this whole block then [21:19:55 CEST] <BBB> pfelt: what is the output from declink? [21:19:58 CEST] <BBB> is it an AVFrame? [21:20:00 CEST] <BBB> or something else? [21:21:33 CEST] <BBB> its AVPacket [21:21:55 CEST] <pfelt> the code will pull the data from the DL api and drop it into a AVPacket [21:22:14 CEST] <pfelt> (i'm cleaning up ff_decklink_read_packet() [21:22:45 CEST] <BBB> it seems to me that for raw frame data, it should reference a AVFrame that is wrapped in a AVPacket [21:22:55 CEST] <BBB> if that makes any sense [21:23:02 CEST] <BBB> and then the avframe would contain the relevant fields [21:23:11 CEST] <BBB> anything else seems like a total hack to me [21:23:39 CEST] <pfelt> so, you're thinking i should do something along these lines (pseudo code here) AVPacket::AVFrame::interlaced_frame [21:24:31 CEST] <pfelt> ah, but i don't see a good way to go from AVPacket to AVFrame either [21:25:08 CEST] <andrey_turkin_> there is some codec involved, yes? s302m or something? [21:25:41 CEST] <pfelt> andrey_turkin: that for us? [21:25:49 CEST] <andrey_turkin_> yes [21:26:11 CEST] <pfelt> DL pulls in rawvideo. i'm not sure of any codec other than taht [21:26:52 CEST] <andrey_turkin_> ok, anyway, there is always a codec. So interlaced state might be corresponder through codecparams [21:27:02 CEST] <nevcairiel> we have a wrapped_avframe pseudo codec for raw devices like that, which encapsulates an AVFrame in AVPacket [21:27:50 CEST] <pfelt> ugh. so do we need to look at moving the whole DL code over to this? [21:27:52 CEST] <andrey_turkin_> for decklink it seems either v210 or rawvideo (depending on bitness) [21:28:41 CEST] <andrey_turkin_> width/height is already passed through for rawvideo this way [21:30:55 CEST] <andrey_turkin_> it seems to me that this is cleanest way to do this. wrapped_avframe is not used here anyway [21:31:11 CEST] <pfelt> i'm not following you andrey_turkin [21:33:23 CEST] <pfelt> i don't actually see where it sets height [21:33:23 CEST] <andrey_turkin_> ok, so decklink device is actually a demuxer, right? It will setup avformat context for itself, it will output packets which have to be decoded. And it will claim they are to be decoded using say v210. And also that encoded frames are codecpar->width and codecpar->height [21:34:33 CEST] <andrey_turkin_> here: https://github.com/FFmpeg/FFmpeg/blob/master/libavdevice/decklink_dec.cpp#L… [21:34:37 CEST] <pfelt> ok. yeah. we set that all up in read_header() [21:34:46 CEST] <pfelt> yep [21:35:13 CEST] <pfelt> but it doesn't set AVFrame::width [21:35:17 CEST] <andrey_turkin_> neither v210 nor rawvideo ever see avframes going in from decklink, they operate solely on data in avpacket based on metadata passed throught to them [21:35:48 CEST] <pfelt> ok. i follow that [21:36:09 CEST] <andrey_turkin_> so now in decklink there is a "horrid hack" where it snoops into decoder and sets some fields [21:36:17 CEST] <pfelt> but at some point in the past, and i've no idea if it's still needed, the original writer thought they needed to set AVFrame::interlaced_frame [21:36:27 CEST] <pfelt> (that's the hack right) [21:36:28 CEST] <pfelt> ? [21:37:09 CEST] <andrey_turkin_> that's a hack if I ever saw one [21:37:27 CEST] <BBB> pfelt: if interlacing is in coded_params, thats obviously fine also, yes, but I dont know exactly wht goes where [21:37:40 CEST] <andrey_turkin_> I assume there wasn't a way to communicate field ordering, or just writer didn't found one [21:37:41 CEST] <BBB> pfelt: ask nevcariel or one of the libav guys that did the actual coded_params (e.g. anton) [21:39:21 CEST] <pfelt> BBB: you mean codecpar ? [21:39:28 CEST] <BBB> yes [21:39:28 CEST] <BBB> sorry [21:39:35 CEST] <pfelt> ah. kk. had me worried there :D [21:39:40 CEST] <andrey_turkin_> there is field_order now. [21:40:24 CEST] <pfelt> yeah. i saw that and thought maybe setting that [21:40:49 CEST] <andrey_turkin_> so you can set proper field order there and also fix codecs to use it [21:40:50 CEST] <pfelt> there is no bool for interlaced_frame though, so i guess if it's set to TT it's assumed interlaced? [21:40:55 CEST] <andrey_turkin_> TT or BB [21:41:30 CEST] <andrey_turkin_> interlaced_frame=0 => PROGRESSIVE; interlaced_frame=1&top_field_first=1 => TT; interlaced_frame=1&top_field_first=0 -> BB [21:41:53 CEST] <BBB> pfelt: sorry for being unclear, Im a little woolie-headed today [21:41:59 CEST] <BBB> wooly-headed? [21:42:01 CEST] <BBB> brb [21:44:04 CEST] <andrey_turkin_> ah, and both codecs already know how to use this field. That should be it then [21:46:47 CEST] <pfelt> ok. so when i set bmd_field_dominance i should be able to find and set the codecpar for interlaced to the right value [21:46:52 CEST] <pfelt> and then not do it per frame [21:46:56 CEST] <andrey_turkin_> right [21:47:55 CEST] <pfelt> or i guess better would be whe is set up the stream [21:47:57 CEST] <pfelt> but same idea [21:48:24 CEST] <andrey_turkin_> that's what I meant, right. same place where it sets other metadata [21:48:38 CEST] <fritsch> I am in the process of transitioning kodi to ffmpeg 3.1 and fixing all the deprecated warnings and wanted to know how to avoid using codec as AVCodecContext in that method: https://github.com/fritsch/xbmc/commit/4935c8ccb314d22636596f59e9b11d25c99f… [21:49:23 CEST] <fritsch> creating a new context, allocating it, copying all the parameters from codcpars and afterwards destryoing the ctx can't be what the new api wants us to do, right? [21:49:29 CEST] <andrey_turkin_> fritsch: iirc you are supposed to loop receive_frame [21:49:39 CEST] <fritsch> that's not my question [21:49:54 CEST] <fritsch> it works as is - EAGAIN is handled separately [21:50:02 CEST] <andrey_turkin_> I don't think it is what it wants you to do [21:50:05 CEST] <fritsch> it's just about: m_fctx->streams[0]->codec [21:50:42 CEST] <fritsch> accessing codec produces a depracated warning and I wanted to know how this is meant to be done [21:50:50 CEST] <fritsch> as all the ffmpeg examples use this ->codec [21:51:20 CEST] <andrey_turkin_> right. So now at setup time you don't use streams->codec. You allocate your own context, you copy parameters from codecpar and use that context to decode video [21:51:32 CEST] <andrey_turkin_> or maybe it is that you meant [21:51:57 CEST] <fritsch> so that's really the way to go [21:52:28 CEST] <andrey_turkin_> for me it made things more clean. Less dependencies between avformat and avcodec [21:52:48 CEST] <fritsch> https://github.com/fritsch/xbmc/blob/4935c8ccb314d22636596f59e9b11d25c99f99… [21:53:00 CEST] <fritsch> for me, it does not - as the AVCodecContext is created not by me [21:53:35 CEST] <pfelt> ok. next question. av_dup_packet() that used to take just one paramater (a pkt), what exactly was that function supposed to do? [21:54:27 CEST] <andrey_turkin_> I think it copied the data from its argument [21:54:41 CEST] <fritsch> https://www.ffmpeg.org/doxygen/2.7/group__lavc__packet.html#ga04c83bc8a6859… <- pfelt [21:55:45 CEST] <fritsch> i think the source is the "best" documentation for av_dup_packet https://www.ffmpeg.org/doxygen/2.7/avpacket_8c_source.html#l00248 [21:55:48 CEST] <andrey_turkin_> ah, right. It was to make "proper" avpacket from non-refcounted ones. [21:56:02 CEST] <fritsch> andrey_turkin_: do I overlook something concerning my AVCodecContext? [21:56:15 CEST] <andrey_turkin_> what do you mean? [21:56:27 CEST] <fritsch> see: https://github.com/fritsch/xbmc/blob/4935c8ccb314d22636596f59e9b11d25c99f99… [21:56:52 CEST] <pfelt> fritsch: uh& yeah, but where did it copy to? [21:57:02 CEST] <pfelt> that function takes a single argument and returns an int [21:57:08 CEST] <andrey_turkin_> pfelt: into the same packet [21:57:18 CEST] Action: pfelt is lost. that doesn't seem useful [21:58:28 CEST] <andrey_turkin_> well, given you have packet with no reference (so data is somewhere elsa in static buffer) and you want to preserve its data. You give it to av_dup_packet and it does memory allocation and copies data. So you are left with packet with same data but now memory for that data is owned by packet [21:58:57 CEST] <fritsch> that's a very good explanation for that dup_packet [21:59:27 CEST] <andrey_turkin_> fritsch: that line is fine. using codec context from avformat is deprecated [22:00:35 CEST] <fritsch> yeah, see the line after it [22:00:39 CEST] <fritsch> how would you solve that? [22:00:57 CEST] <fritsch> create an own AVCodecContext and copy all the codecpars from the stream? [22:01:03 CEST] <andrey_turkin_> exactly that [22:01:07 CEST] <fritsch> and then destroy this temp context? [22:01:14 CEST] <fritsch> that seems a whole lot overhead [22:01:21 CEST] <andrey_turkin_> no, don't touch format context at all [22:01:43 CEST] <pfelt> andrey_turkin: ok. so the fix for av_dup_packet(&pkt) is av_packet_ref(&pkt, &pkt) [22:02:20 CEST] <andrey_turkin_> better fix is to use referenced packets from the start [22:02:36 CEST] <andrey_turkin_> packet_ref won't do the right thing in this case I think [22:03:58 CEST] <andrey_turkin_> actually, is there any decoder which doesn't output referenced packets? [22:05:43 CEST] <pfelt> i'm sure that rewriting decklink to do all referenced packets would be a good place to end [22:05:45 CEST] <andrey_turkin_> pfelt: I think av_dup_packet calls are not needed anymore [22:08:49 CEST] <andrey_turkin_> actually in decklink something has to be fixed for that. Instead of init_packet and setting its data field, use av_packet_from_data [22:09:10 CEST] <fritsch> andrey_turkin_: http://sprunge.us/dBQF <- this really is the truth? [22:09:55 CEST] <fritsch> as it compiles, but does not work - I think not :-) [22:10:07 CEST] <andrey_turkin_> I think so. and you need to preserve codec_ctx. [22:10:28 CEST] <andrey_turkin_> and also copy timebase from context iirc [22:11:49 CEST] <andrey_turkin_> you can check libav examples. They are updated to use codec params [22:12:05 CEST] <fritsch> I will - you got a link by chance? [22:12:17 CEST] <fritsch> though - I find this overlay complicated, resource hungry and so on [22:12:19 CEST] <andrey_turkin_> https://github.com/libav/libav/blob/master/doc/examples/transcode_aac.c e.g. [22:12:52 CEST] <andrey_turkin_> it is much better from architecture point of view. Much less linkage between muxer/demuxer and coder/decoder [22:14:09 CEST] <fritsch> mmh, that looks exactly like the code I just wrote [22:14:21 CEST] <fritsch> then I need to find out why it does not work :-) [22:14:46 CEST] <andrey_turkin_> for me main issue when converting was using wrong timebases everywhere [22:15:30 CEST] <andrey_turkin_> assumptions which were true became false so I had some fun time fixing timestamps throughout the transcoding chain [22:15:51 CEST] <pfelt> andrey_turkin: i removed the call, recompiled, and am running it. it seems to be outputting the data to sdi right, so you may be right [22:16:52 CEST] <andrey_turkin_> you don't need to fix packets on encoder side (where they come from the users). Something has to be done on decoder side though [22:31:38 CEST] <fritsch> andrey_turkin_: thx - it worked :-) [22:31:55 CEST] <fritsch> it needed a bit for me to see my error [22:33:05 CEST] <andrey_turkin_> great [22:33:23 CEST] <fritsch> one needs to use this ctx to do the decoding later on [22:33:29 CEST] <fritsch> obviously [22:33:40 CEST] <andrey_turkin_> yeah [00:00:00 CEST] --- Tue Jun 28 2016

1 0

ffmpeg.log.20160627
by burek 28 Jun '16

28 Jun '16

[04:25:36 CEST] <Bray90820> Can someone help me here I seem to be getting some errors [04:25:36 CEST] <Bray90820> http://pastebin.com/W2GDHGs7 [04:26:46 CEST] <furq> [mp4 @ 0x7fbd0a01c600] Could not find tag for codec wmav2 in stream #1, codec not currently supported in container [04:26:50 CEST] <furq> what's not clear about this error [04:31:12 CEST] <Bray90820> Honestly I have no idea [04:33:25 CEST] <furq> you can't mux wma audio into an mp4 [04:33:35 CEST] <furq> use a different container (mkv) or reencode the audio to aac [05:01:43 CEST] <Bray90820> furq: Could passthrough the video and convert the audio to something else? [05:32:21 CEST] <Bray90820> I am also getting another error repeatedly [05:32:25 CEST] <Bray90820> Past duration 0.731682 too large [06:31:26 CEST] <thebombzen> Bray90820: yes [06:31:35 CEST] <thebombzen> use -c:v copy to copy the input video [06:37:55 CEST] <Bray90820> theholyduck: prob not but could I use --c:v to do a direct copy to mp4 like without loosing quality [06:40:35 CEST] <Bray90820> Sorry wrong ping [07:18:28 CEST] Action: theholyduck SLAPS Bray90820 [07:38:33 CEST] <Bray90820> Haha [10:49:39 CEST] <totokaka> I have 160 png images with size 47616x26880. Can I use ffmpeg to create a timelapse from a cropped area of them? [10:50:23 CEST] <totokaka> If I try just the standard way, I get this error: [png @ 0xa5f6a0] [IMGUTILS @ 0x7fff397bc5d0] Picture size 47616x26880 is invalid [11:01:18 CEST] <jkqxz> totokaka: ffmpeg doesn't like images which have more than INT_MAX/8 pixels (i.e. 16kx16k) because of possible integer overflow issues. [11:01:31 CEST] <BtbN> totokaka, you realize that a single image easily eats 3GB of ram? [11:01:59 CEST] <totokaka> I'm rendering on a 12 core VPS with 48GB RAM [11:02:10 CEST] <totokaka> jkqxz, Does that mean I'm completely out of luck? [11:03:21 CEST] <totokaka> I though I maybe could get ffmpeg to crop and scale the images on the input side [11:04:02 CEST] <jkqxz> You might be able to get it to work by cutting each image into 4 or 6 pieces with some other tool? Really ffmpeg is not made to deal with images of this size, so I don't really know. [11:04:48 CEST] <totokaka> Well, the images are already built up of small tiles. I have used another script to paste them [11:05:24 CEST] <totokaka> So I do have a ton of really small tiles that build up the bigger images. [11:32:48 CEST] <CaptainPrice> I am trying to make a graphical visualizer with ffmpeg. I know the basics of signal processing. Im guessing the height of bars can be calculated using Fourier Transform [11:33:14 CEST] <CaptainPrice> Can anybody actually help me with a simple tutorial on how to achieve this using API of ffmpeg ? [11:34:16 CEST] <durandal_1707> CaptainPrice: see showspectrum/showfreqs filter source code [11:37:42 CEST] <CaptainPrice> durandal_1707: Is it a part of avfilter ? [15:28:47 CEST] <P4Titan> Hello all. I changed the output bit rate of the transcode_aac.c example to 32000 and the output file it produces fails [15:29:34 CEST] <orgasmix> Hi. Converting from flac to aiff: how to select PCM format? `ffmpeg -i source.flac -c:a pcm_s32le -f aiff out.aiff` yields `Could not write header [...] Operation not permitted`. Leaving the codec option out defaults to 16-bit. [15:43:26 CEST] <DHE> is 32 bit supported in the file format? [15:47:45 CEST] <orgasmix> Converting to wav also fails with -f pcm_s24le and pcm_s32le [15:48:40 CEST] <orgasmix> A non-empty file gets created but ffmpeg cannot -i it back and VLC will think it's mp3-64k [16:01:27 CEST] <durandal_1707> orgasmix: be variant [16:04:29 CEST] <orgasmix> tried too. I could extract the raw PCM but couldn't mux it as neither wav not aiff using s[24|32][le|be]. ableton did it for me though, into aiff, and `ffmpeg -i that_file_from_ableton.aiff` says `Audio: pcm_s24be, 48000 Hz, 2 channels, s32 (24 bit), 2304 kb/s`. [16:09:59 CEST] <orgasmix> nvm ffmpeg does. `-c:a pcm_s24be out.aiff` does the thing. says "s32 (24 bit)" and vlc says 32 bit per sample also, but the file takes up less size than with pcm_s32be. no idea why. thanks for your attention [16:13:45 CEST] <durandal_1707> That's normal, its how it is decoded [16:42:31 CEST] <fritsch> with the new send / receive api and other deprectations with 3.1 I wonder where to get the AVCodecContext from if this is deprecated: avcodec_send_packet(m_fctx->streams[0]->codec, &pkt); [16:42:44 CEST] <fritsch> e.g. accessing m_fctx->streams[0]->codec [17:04:29 CEST] <Psi-Jack> Is it possible, using ffmpeg, to convert flac media to m4a media, with more thorough metadata conversion? Right now, it seems to get like bare minimums, but not very comprehensive. Generally only enough to get a rough match with musicbrainz to be able to manually fix the rest of it. [17:15:34 CEST] <m3gab0y> anyone up for a challenge? [17:24:56 CEST] <sza> Hello, having trouble with ffmpeg and will be glad if someone can help me. [17:25:18 CEST] <sza> I'm trying to convert .png files into a video file. [17:25:38 CEST] <sza> the files are located under the same directory and their names are 1.png, 2.png and so on [17:26:03 CEST] <sza> I'm trying to use ffmpeg with the following command [17:26:04 CEST] <sza> ffmpeg -framerate 1/5 -i %d.png -c:v libx264 -r 30 -pix_fmt yuv420p out.mp4 [17:26:13 CEST] <sza> The error I get is: [17:26:23 CEST] <sza> Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [17:26:31 CEST] <sza> What am I doing wrong? [17:27:24 CEST] <furq> sza: there should be an actual error above that [17:28:36 CEST] <sza> http://pastebin.com/9kwN6DFs [17:28:44 CEST] <sza> This is the entire output [17:28:49 CEST] <furq> [libx264 @ 0x2eb1700] width not divisible by 2 (757x600) [17:29:30 CEST] <furq> add -vf scale=758:600 or something [17:30:10 CEST] <sza> why should it be divisible by 2? [17:30:19 CEST] <furq> because you're using yuv420p [17:30:27 CEST] <sza> Thank you very much, I'm trying it [17:31:07 CEST] <furq> you can use yuv444p if you don't want to have to resize it, but a lot of players won't play the video back [17:31:33 CEST] <sza> Just need to play it over vimeo. do you think it'll work? [17:31:40 CEST] <furq> vimeo will reencode it anyway [17:32:12 CEST] <sza> Thank you very much! [17:32:19 CEST] <sza> I really appreciate it. [17:33:13 CEST] <sza> The output file plays it very slow. How can I make it faster? [17:33:31 CEST] <furq> change -framerate to something faster than 0.2 [17:34:17 CEST] <sza> Faster means larger number? [17:34:32 CEST] <furq> yes [17:34:44 CEST] <sza> Thank you [17:35:03 CEST] <sza> again :) [20:04:44 CEST] <pgorley> in the tool ffmpeg, when hwaccel_retrieve_data is called, does it mean that the frame is finished being decoded? [20:08:46 CEST] <Psi-Jack> Hmmm [20:09:12 CEST] <Psi-Jack> Is it possible, using ffmpeg, to convert flac media to m4a media, with more thorough metadata conversion? Right now, it seems to get like bare minimums, but not very comprehensive. Generally only enough to get a rough match with musicbrainz to be able to manually fix the rest of it. [20:09:37 CEST] <Psi-Jack> I would LIKE to have it copy the musicbrainz fields over from vorbis (flac) to AAC (m4a), but it's only doing part of it. [20:10:19 CEST] <kepstin> the musicbrainz fields in particular are kinda tricky, because you need to know the mapping in each format - it's different for each one [20:10:33 CEST] <kepstin> i'd suggest just retagging the file with picard after transcoding [20:11:45 CEST] <Psi-Jack> I've been doing that, but it's error prone, because from the origin format, flac, to the m4a format, picard often time picks the wrong actual metadata selection. :) [20:13:04 CEST] <kepstin> hmm, right, the flac and m4a formats are different enough that ffmpeg's probably not copying the recording mbid field that it would need to do an exact match [20:14:23 CEST] <kepstin> if you could use opus or vorbis instead, that would solve your issue; the tags in those are compatible with flac so it should just all copy over ;) [20:15:02 CEST] <furq> why can't everything just use vorbis comments [20:15:14 CEST] <Psi-Jack> Heh, here here! [20:15:41 CEST] <kepstin> Psi-Jack: btw, if you're curious, https://picard.musicbrainz.org/docs/mappings/ shows what the different musicbrainz tags have to be converted to [20:15:43 CEST] <Psi-Jack> m4a, though, has it's own dynamic format. [20:15:49 CEST] <kepstin> I dunno if ffmpeg even knows how to write some of those [20:16:18 CEST] <furq> yeah mp4 metadata is scarcely better than id3v2 [20:16:29 CEST] <furq> which is of course the gold standard of metadata [20:16:36 CEST] <Psi-Jack> Yeah, vorbis uses musicbrainz_albumid I believe, and m4a uses "musicbrainz album id" with spaces. [20:16:59 CEST] <Psi-Jack> furq: yeah, but still better. Hell, ANYTHING is better than id3 in every itteration of it thus far. [20:17:04 CEST] <kepstin> "----:com.apple.iTunes:MusicBrainz Track Id" is the important one [20:17:10 CEST] <kepstin> well, that and release id [20:17:39 CEST] <furq> maybe mutagen will do it if you don't mind running a separate command [20:17:49 CEST] <furq> i seem to remember it handling at least some mb tags [20:18:11 CEST] <kepstin> mutagen on its own handles some, yeah. You might be able to use it to pull out the tags on the original file, and write them to the dest file? [20:18:25 CEST] <furq> that's what i do when i batch convert [20:18:35 CEST] <furq> although i don't batch convert with ffmpeg because it doesn't write mp3 xing headers [20:19:05 CEST] <Psi-Jack> furq: Hmmm. How are you batch converting? I've been writing my library management scripts to do as much automated as possible, and so far, besides this one issue of metadata itself, it works great. [20:19:06 CEST] <kepstin> i think i saw a patch for xing headers floating around the ML recently? would be nice to have that :/ [20:19:26 CEST] <Psi-Jack> Oh. You don't use ffmpeg. i only convert FLAC->m4a. :) [20:19:28 CEST] <furq> Psi-Jack: lame and then a mutagen script [20:19:47 CEST] <Psi-Jack> And I use ffmpeg's libfdk_aac [20:19:51 CEST] <kepstin> hmm. picard code has a *lot* of special handling for mp4/m4a; i'm not sure how much will be converted by mutagen alone [20:21:00 CEST] <furq> i'd check but i've never run it on stuff tagged by picard [20:21:30 CEST] Action: kepstin should check, but he never encodes to aac [20:21:36 CEST] <furq> that too [20:21:52 CEST] <Psi-Jack> hehe [20:21:55 CEST] <furq> although if it can handle the id3 mappings it ought to be able to figure out the m4a ones [20:22:10 CEST] <furq> assuming you use mp3 and not opus [20:22:54 CEST] <Psi-Jack> As a media format, I absolutely despise mp3. Quality of m4a is much much better anyway, for a smaller size. [20:23:15 CEST] <Psi-Jack> And my iDevices and iTunes support. ;) [20:23:37 CEST] <kepstin> well, back when I used an iPod, I ran rockbox on it. Supported opus just fine ;) [20:23:39 CEST] <furq> i only use mp3 for distributing to other people [20:23:52 CEST] <furq> my mp3 player is full of vorbis, but i'd probably use opus these days [20:23:54 CEST] <kepstin> anyways, https://github.com/quodlibet/mutagen/blob/master/mutagen/easymp4.py#L246 - looks like they do have the core musicbrainz tags in the easymp4 wrapper, so you should be good [20:25:04 CEST] <kepstin> if you want *everything*, you'd have to retag in picard, but it preserves enough that picard can just look up the correct album right away without guessing. [20:29:43 CEST] <Psi-Jack> My entire library was originally ripped into ogg vorbis. Now since a hurricane took out my entire library I've taken to maintaining a lossless (flac), format alongside the format I actually need to use. ;) [20:30:16 CEST] <kepstin> yeah, I do the same. I encode both formats at the same time, and tag them separately. [20:30:17 CEST] <furq> yeah disk space is cheap [20:30:33 CEST] <furq> i only bother encoding if it's going on a portable device or something [20:30:53 CEST] <Psi-Jack> I maintain both, so my tools helps synchronize everything. :) [20:32:20 CEST] <Psi-Jack> I rip a new album to flac, run picard on it, merge it into my library, then use my tools to convert it to m4a, bring that m4a into my iTunes for Match, then I can access that song from anywhere, then my m4a's get merged into their own library, which Subsonic provides, because when I travel overseas, itunes match may not be available, sadly. [20:33:03 CEST] Action: kepstin just puts his entire music collection in lossy formats on an sd card in his phone. [20:33:19 CEST] <Psi-Jack> Heh. [20:33:34 CEST] <furq> i just have it all on google play music [20:33:42 CEST] <kepstin> nice that sandisk has that one 200gb card so everything actually fits :/ [20:33:56 CEST] <Psi-Jack> I have my phone download most of the time, since I get, with the Match service, AAC 256kbit, directly from Apple or their "Cloud" depending on if the match matched or uploaded. [20:34:16 CEST] <kepstin> streaming/cloud stuff kinda sucks in canada, since all our cell phone data plans are expensive and capped :/ [20:35:01 CEST] <furq> generally if i don't have wifi then i'm on a train or something [20:35:12 CEST] <furq> so my sd card is full of tv shows [20:36:45 CEST] <furq> you'd think google would be happy to store 128k opus for users who know they can play it back, but nope [20:36:50 CEST] <furq> it's all 320k cbr mp3 [20:37:46 CEST] <furq> not that i'm complaining about unlimited storage for my music of questionable provenance [20:43:55 CEST] <Psi-Jack> kepstin: Yeah, mine's unlimited, even when I go to Japan, it's still unlimited data. [20:46:56 CEST] <kepstin> Psi-Jack: in case you just need a simple tool to copy tags in your workflow, https://gist.github.com/kepstin/2c23f3ecc0a60f188273931527de5c12 should work from flac (or indeed any format using vorbistags) to aac [20:47:21 CEST] <Psi-Jack> VEry nice. [20:47:28 CEST] <Psi-Jack> I will check this out and see if it'll work for me. [20:47:55 CEST] <Psi-Jack> And, thank you! :) [20:48:21 CEST] <furq> #! /usr/bin/env python3 [20:48:22 CEST] <furq> pls [20:51:43 CEST] <kepstin> if you insist :/ [20:55:12 CEST] <c_14> What about those 2 historical unixes that had env in /bin? [20:55:44 CEST] <kepstin> if you manage to get python3 running on them, you already know how to fix the issue. [20:58:57 CEST] <Psi-Jack> But that's not the issue. :)LOL [21:00:38 CEST] <c_14> If you can't find enough problems in your life, sometimes you just have to make more. ;p [21:05:54 CEST] <Psi-Jack> Heh, I should probably rewrite my library management scripts in python. Right now they're pure bash. ;) [21:12:59 CEST] <Psi-Jack> Ooh, and python-mutagen is fairly current in EPEL for EL7. :) [21:16:00 CEST] <Psi-Jack> But, of course, not Python 3.x [21:17:39 CEST] <furq> it should work fine with python 2 [21:17:53 CEST] <furq> just get rid of the parens in print [21:18:07 CEST] <Psi-Jack> It didn't, because of line 9. :) [21:18:12 CEST] <furq> ^ [21:18:14 CEST] <Psi-Jack> Or that yes. hehe [21:19:33 CEST] <kepstin> oh, just remove that ',file=...' bit I think, and it'll just print to stdout instead of err? [21:19:42 CEST] <Psi-Jack> Correct. [21:19:42 CEST] Action: kepstin doesn't do much python2 stuff now :/ [21:20:20 CEST] <Psi-Jack> print "Usage: {} src.flac dest.m4a".format(sys.argv[0]) , syntax error pointing at that " after m4a. grrr. [21:20:57 CEST] <furq> replace {} with %s [21:21:08 CEST] <furq> i think. i try my best to avoid python [21:21:43 CEST] <Psi-Jack> {} is almost right, but {0} is correct for 2. [21:21:51 CEST] <Psi-Jack> {} works too. [21:22:00 CEST] <furq> oh yeah it's python with its ten million ways of doing string formatting [21:22:06 CEST] <Psi-Jack> heh [21:22:35 CEST] <kepstin> I rewrote https://gist.github.com/kepstin/2c23f3ecc0a60f188273931527de5c12 in python2 for you, and even tested it. [21:23:07 CEST] <Psi-Jack> Heh that works too, %s, with % format method. [21:23:08 CEST] <kepstin> oh, dropped the /usr/bin/env thing, oh well [21:25:09 CEST] <Psi-Jack> So wierd... [21:25:30 CEST] <Psi-Jack> So I changed it on my side, that still didn't work. Used the exact code you just gisted, worked. *shakes fist* [21:25:54 CEST] <Psi-Jack> Oh, because I forgot to change python3 to python2 [21:26:15 CEST] <Psi-Jack> EPEL apparently has python 3.4. Heh [21:26:37 CEST] <kepstin> yeah, i guess they just don't have the mutagen libraries for python3? [21:26:46 CEST] <Psi-Jack> Nope. [21:26:53 CEST] <Psi-Jack> And apparently no pip for it either. :/ [21:27:05 CEST] <Psi-Jack> Oh wait, there it is. [21:27:11 CEST] <Psi-Jack> python3-pip, not python34-pip [21:27:17 CEST] <furq> it should work fine with python 2 anyway [21:27:23 CEST] <Psi-Jack> Yep. [21:27:39 CEST] <Psi-Jack> I still write for python 2, but need to eventually upgrade my knowledge to 3. [21:27:54 CEST] <Psi-Jack> but, maintain 2 obviously since even EL7 still has python 2 [21:28:17 CEST] <kepstin> I kinda like how the native asyncio stuff (added in 3.3, i think?) works. [21:30:01 CEST] <Psi-Jack> Heh [21:30:21 CEST] <Psi-Jack> And if I re-write my library management stuff in python, I can probably extract metadata information faster. [21:30:31 CEST] <Psi-Jack> Right now, I'm extracting it using ffprobe and sed looping. [22:03:48 CEST] <imperio_> hi, I followed instructions here: https://launchpad.net/~mc3man/+archive/ubuntu/trusty-media to add ppa [22:03:59 CEST] <imperio_> however, it says it cannot find the address [22:04:02 CEST] <imperio_> is it normal? [22:05:05 CEST] <imperio_> my goal was to try to get 3.1 packages directly for travis [23:29:32 CEST] <imperio_> to make it simple: how could I install ffmpeg 3.x on travis without building it please? [23:32:40 CEST] <furq> imperio_: http://johnvansickle.com/ffmpeg/ [23:34:06 CEST] <imperio_> furq: Thanks [23:34:21 CEST] <imperio_> however I have questions: it is compiled as static lib, right? [23:34:24 CEST] <imperio_> (.a?) [23:37:57 CEST] <imperio_> furq: ah sorry, you just provide the executable, I'm only interested in libavcodec, libavutil and libavformat :-/ [23:38:05 CEST] <imperio_> I should have precised [23:38:40 CEST] <imperio_> but you have a libav link! [23:38:44 CEST] <imperio_> yay \o/ [23:40:16 CEST] <imperio_> arf, doesn't provide what I'm looking for [23:40:19 CEST] <imperio_> too bad :-/ [23:40:28 CEST] <imperio_> well, I'll just provide the one I have I guess [23:45:40 CEST] <DHE> does your distribution already provide something like ffmpeg-dev ? [23:46:31 CEST] <furq> i assume it's an old ubuntu [23:46:52 CEST] <DHE> travis is the buildbot thing, right? [23:47:17 CEST] <furq> something like that [23:47:50 CEST] <furq> apparently it's locked to 12.04, so that's no use [23:49:30 CEST] <llogan> imperio_: why can't you compile it? [23:49:56 CEST] <imperio_> llogan: the goal is to provide it into the new mozilla browser engine [23:50:15 CEST] <imperio_> their build process is already huge enough [23:50:55 CEST] <imperio_> so i can totally compile it, but I don't want to [23:56:15 CEST] <imperio_> btw, why the 3.x packages are only available on yakkety? [23:56:19 CEST] <imperio_> that seems strange [23:56:43 CEST] <furq> you'd have to ask the ubuntu packagers [23:56:50 CEST] <imperio_> damn [23:56:51 CEST] <furq> once they're done chasing the ball around the yard [23:56:56 CEST] <imperio_> XD [23:57:06 CEST] <imperio_> I thought I had to fight only with debian ones [23:57:23 CEST] <imperio_> this is a damn curse [23:57:46 CEST] <imperio_> I just thought: if i repackage ffmpeg myself, that would do the trick! [00:00:00 CEST] --- Tue Jun 28 2016

1 0

ffmpeg-devel.log.20160626
by burek 27 Jun '16

27 Jun '16

[00:14:28 CEST] <DSM_> michaelni: why unref infmts be a problem? http://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195444.html [00:15:11 CEST] <DSM_> i thought, it should be fixed before release [00:16:54 CEST] <michaelni> DSM_, there are 2 calls to ff_formats_ref(), if the first succeeds and the 2nd fails i think you would have a double free if you unref the first too [00:22:34 CEST] <cone-423> ffmpeg 03Michael Niedermayer 07master:fdd8aac7e12e: avfilter/src_movie: Add option to remove timestamp discontinuities [01:07:14 CEST] <cone-423> ffmpeg 03Michael Niedermayer 07master:9981b70da50f: avcodec/h264_sei: Do not skip subsequent SEIs on errors potentially caused by missing parameter sets. [01:07:14 CEST] <cone-423> ffmpeg 03Michael Niedermayer 07master:f1dabc958e09: avfilter/dualinput: Add support to skip initial unpaired frames [02:52:10 CEST] <DSM_> michaelni: why unref infmts be a problem? http://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195444.html [02:53:52 CEST] <michaelni> <michaelni> DSM_, there are 2 calls to ff_formats_ref(), if the first succeeds and the 2nd fails i think you would have a double free if you unref the first too [02:54:20 CEST] Action: michaelni hopes DSM_ doesn get disconnected before reading it this time :) [02:56:08 CEST] <DSM_> :D [03:07:31 CEST] <cone-423> ffmpeg 03Michael Niedermayer 07master:8baa1d220987: avfilter/vf_paletteuse: enable skip_initial_unpaired [03:07:32 CEST] <cone-423> ffmpeg 03Michael Niedermayer 07master:7b92fe8d3faa: doc/APIchanges: Fill in and correct more stuff [03:31:50 CEST] <cone-423> ffmpeg 03Michael Niedermayer 07master:074fdf4d12b0: doc/APIchanges: Add FFmpeg 3.1 cut marker [03:32:52 CEST] <cone-423> ffmpeg 03Michael Niedermayer 07release/3.1:HEAD: doc/APIchanges: Add FFmpeg 3.1 cut marker [04:03:51 CEST] <cone-423> ffmpeg 03Michael Niedermayer 07release/3.1:e5d434b84040: tests/checkasm/checkasm: Disable checkasm_check_pixblockdsp for ppc64be [04:03:51 CEST] <cone-423> ffmpeg 03Michael Niedermayer 07release/3.1:182cfe4832d8: release notes (based on release/3.0) [04:19:09 CEST] <cone-423> ffmpeg 03Michael Niedermayer 07release/3.0:fbdf5ca763f0: tests/checkasm/checkasm: Disable checkasm_check_pixblockdsp for ppc64be [09:34:18 CEST] <nevcairiel> disabling checkasm on some platform and only in releases sounds wrong, if anything the asm thats broken should be turned off <.< [10:26:16 CEST] <michaelni> nevcairiel, fate passes except checkasm, also looking at the checkasm doesnt it test get/diff pixels with unaligned input ? these are documented in libavcodec/pixblockdsp.h as requiring alignment [10:28:52 CEST] <cone-970> ffmpeg 03Paul B Mahol 07master:8fb92ea7e2a6: avcodec: add YUY2 Lossless Codec decoder [13:11:08 CEST] <cone-970> ffmpeg 03Michael Niedermayer 07release/3.1:b2a74dd629c1: Set version to 3.1 [14:03:38 CEST] <ubitux> i wonder how to solve the problem with subtitles who have timing obtained at decoding process [14:03:46 CEST] <ubitux> (hello dvdsubs) [14:04:05 CEST] <ubitux> and xsub [14:08:02 CEST] <cone-970> ffmpeg 03Anton Khirnov 07master:35c858066840: avconv: stop using AVStream.codec [14:08:03 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:b8945c4e2a1b: Merge commit '35c858066840352d6d43385bbc728467c5150974' [14:09:34 CEST] <cone-970> ffmpeg 03Diego Biurrun 07master:e2a3df1a4640: avconv: Use more precise deprecation ifdefs [14:09:35 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:4531981a9b20: Merge commit 'e2a3df1a464091075040a81ffc419fa21a8a5fd8' [14:13:47 CEST] <cone-970> ffmpeg 03Diego Biurrun 07master:e45a638f50cc: dump: Drop unused variable [14:13:48 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:b23d4e52fd24: Merge commit 'e45a638f50cc1dbeb87b9792e68f57e77fc0c3b5' [14:22:50 CEST] <cone-970> ffmpeg 03Diego Biurrun 07master:52567e819866: get_bits: Drop some TRACE-level debug code [14:22:51 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:e2836397f11c: Merge commit '52567e8198669a1e7493c75771613f87a90466c3' [14:32:25 CEST] <cone-970> ffmpeg 03Luca Barbato 07master:74b1bf632f12: mp3: Make the extrasize explicit [14:32:27 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:314e6086315d: Merge commit '74b1bf632f125a795e66e5fd0a060b9c7c55b7a3' [14:32:50 CEST] <cone-970> ffmpeg 03Anton Khirnov 07master:14634429b915: lavf: update muxing doxy [14:32:50 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:97bdb94341ae: Merge commit '14634429b915333f3612eaf41db3954222dc4aaf' [14:37:02 CEST] <cone-970> ffmpeg 03Anton Khirnov 07master:5f30ac27795f: lavc: deprecate avcodec_copy_context() [14:37:03 CEST] <cone-970> ffmpeg 03Anton Khirnov 07master:04fc8e24a091: lavc: deprecate avcodec_get_context_defaults3() [14:37:04 CEST] <cone-970> ffmpeg 03Anton Khirnov 07master:2ef6dab0a79a: lavc: document that avcodec_close() should not be used [14:37:05 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:6988cf2969d7: Merge commit '5f30ac27795f9f98043e8582ccaad8813104adc4' [14:37:06 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:69c38d64d745: Merge commit '04fc8e24a091ed1d77d7a3c0cbcfe60baec19a9f' [14:37:07 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:f9a186c59b4c: Merge commit '2ef6dab0a79a9852a92ed80b07f9e32a37530d9e' [14:40:41 CEST] <cone-970> ffmpeg 03Anton Khirnov 07master:ac84e618df47: avfiltergraph: check the query_formats() return value [14:40:42 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:7c6ae9ca0489: Merge commit 'ac84e618df4765ba751327497994066d0931e6a8' [14:49:29 CEST] <cone-970> ffmpeg 03Francois Cartegnie 07master:ad61da054bd8: jpeg2000: Fix profile define values [14:49:30 CEST] <cone-970> ffmpeg 03Diego Biurrun 07master:e47b8bbf0b54: avcodec: Bump micro version after changing public JPEG 2000 defines [14:49:31 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:46ff31d39c2e: Merge commit 'ad61da054bd8c74a5d5b38d80846228fc6147108' [14:49:32 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:b95534bb674a: Merge commit 'e47b8bbf0b54599d44b9330eb4d68cdde4f6d298' [14:51:51 CEST] <cone-970> ffmpeg 03Martin Storsjö 07master:3fdffc032e8e: rtsp: Use avcodec_descriptor_get instead of avcodec_find_decoder [14:51:52 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:f972653ec198: Merge commit '3fdffc032e8ea5676bc0c2551b900c0dc887835b' [15:01:58 CEST] <cone-970> ffmpeg 03Diego Biurrun 07master:07377fb55790: fate: More fine-grained dependencies for voice codec tests [15:01:59 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:093e06f2d687: Merge commit '07377fb557909015338b4c215b87b9c73ea577ad' [15:06:57 CEST] <cone-970> ffmpeg 03Diego Biurrun 07master:7ca4fdc046a9: fate: More fine-grained dependencies for demuxer tests [15:06:58 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:324f0fbff124: Merge commit '7ca4fdc046a945949866bb6fc550e3cab1fc8c00' [15:12:59 CEST] <ubitux> do we have xsub in sth else than avi? [15:15:46 CEST] <cone-970> ffmpeg 03Diego Biurrun 07master:4024b566d664: golomb: Give svq3_get_se_golomb()/svq3_get_ue_golomb() better names [15:15:47 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:b20fe650ef85: Merge commit '4024b566d664a4b161d677554be52f32e7ad4236' [15:21:29 CEST] <cone-970> ffmpeg 03Andrey Turkin 07master:24b5cff01bba: lavc: handle hw_frames_ctx where necessary [15:21:30 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:2c1d0f871f6a: Merge commit '24b5cff01bbac4e08acfd6d19c499e880988f520' [15:23:36 CEST] <cone-970> ffmpeg 03Anton Khirnov 07master:1c9e8616c535: hwcontext: add a function for opening devices [15:23:37 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:481f320aa388: Merge commit '1c9e8616c535ef496e7ee8a5cbc5e9e972a6977d' [15:26:10 CEST] <nevcairiel> i cant really test most of these, but since they are new functions that apply cleanly, its going to be alright, isnt it :D [15:26:17 CEST] <cone-970> ffmpeg 03Anton Khirnov 07master:38392b2af815: hwcontext_vdpau: implement device creation [15:26:18 CEST] <cone-970> ffmpeg 03Anton Khirnov 07master:2e219b491bcc: hwcontext_cuda: implement device creation [15:26:19 CEST] <cone-970> ffmpeg 03Anton Khirnov 07master:8e70385a8ed0: hwcontext_dxva2: implement device creation [15:26:20 CEST] <cone-970> ffmpeg 03Anton Khirnov 07master:b8bf9194af60: hwcontext_vaapi: implement device creation [15:26:21 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:613ac3bf82cb: Merge commit '38392b2af815898b8716826c4e29d95c04fb2647' [15:26:22 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:c5a0c16850fc: Merge commit '2e219b491bcc0845248345fdad31231b081e06d1' [15:26:23 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:162370b47320: Merge commit '8e70385a8ed06f96f1e9e35cf7b6788a5c56eded' [15:26:25 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:ed5d03ff6f90: Merge commit 'b8bf9194af602cf3a4bcd19a5e278e3d6d69f8fa' [15:30:50 CEST] <cone-970> ffmpeg 03Anton Khirnov 07master:f72db3f2f3a8: avconv_vdpau: use the hwcontext device creation API [15:30:51 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:844256740d27: Merge commit 'f72db3f2f3a8c83a4f5dede8fa03434b2bf676c6' [15:36:05 CEST] <cone-970> ffmpeg 03Anton Khirnov 07master:18c506e9e6e8: avconv_dxva2: use the hwcontext device creation API [15:36:06 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:85da4f92580d: Merge commit '18c506e9e6e8df8b1d496d093077b8240ea68c28' [15:36:07 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:06a0e184359b: hwcontext_dxva2: Use GetDesktopWindow instead of GetShellWindow [15:36:34 CEST] <cone-970> ffmpeg 03Anton Khirnov 07master:9f7590f4e497: avconv_vaapi: use the hwcontext device creation API [15:36:35 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:4e6f2dbcd3ca: Merge commit '9f7590f4e497c12693247d7f935a20d7773a64dd' [15:39:35 CEST] <cone-970> ffmpeg 03Anton Khirnov 07master:80fb19bc234a: avconv: fix a check for av_bsf_get_by_name() return value [15:39:36 CEST] <cone-970> ffmpeg 03Anton Khirnov 07master:fe7b21c8f148: avconv: fix parsing bitstream filters [15:39:37 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:c9ee36e60ffb: Merge commit '80fb19bc234a3f2350d891adf39f3738a8e4849f' [15:39:38 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:7fe7cdca3665: Merge commit 'fe7b21c8f148493c6fbceb7f887a77531dd1ae0e' [15:41:53 CEST] <cone-970> ffmpeg 03Anton Khirnov 07master:f5c43884190b: FATE: drop the audio stream from the dxtory test [15:41:53 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:cd52ec2337ae: Merge commit 'f5c43884190be094749acfba104e3eab98d8ff1e' [15:43:25 CEST] <cone-970> ffmpeg 03Diego Biurrun 07master:6641819feedb: build: Ignore generated mapfile and remove it on distclean [15:43:26 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:5a9134f5f142: Merge commit '6641819feedb086ebba3d2be89b8d33980f367e1' [15:44:58 CEST] <cone-970> ffmpeg 03Mark Thompson 07master:2bfa067d0b63: vaapi_encode: Check config attributes before creating config [15:44:59 CEST] <cone-970> ffmpeg 03Mark Thompson 07master:b51c7c6b8a5b: vaapi_h264: Fix frame_num after non-reference frames [15:45:00 CEST] <cone-970> ffmpeg 03Mark Thompson 07master:a86aa16088ad: vaapi_h264: Add trivial support for low-power encoding [15:45:01 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:18b1b8be6a2a: Merge commit '2bfa067d0b636e7b2004fb0ad5a53d0d48c6de32' [15:45:02 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:d3327b7eda97: Merge commit 'b51c7c6b8a5b35cfd06cb9655f9ec4c9f0ddd81b' [15:45:03 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:f2a3798ea459: Merge commit 'a86aa16088ad7f22a8918d71adb8c040d6033d84' [15:47:13 CEST] <cone-970> ffmpeg 03Luca Barbato 07master:5264e7ba217b: ac3: Check the array bound before dereferencing [15:47:14 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:5e418fd63a29: Merge commit '5264e7ba217b3c0ceae813917134e1ab52573141' [15:53:15 CEST] <cone-970> ffmpeg 03Diego Biurrun 07master:dc40a70c5755: Drop unnecessary libavutil/x86/asm.h #includes [15:53:16 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07master:c142dc203e25: Merge commit 'dc40a70c5755bccfb1a1349639943e1f408bea50' [15:54:36 CEST] <ubitux> oh the timings in xsub are in the packets because there is only constant frame rate support in avi? [15:54:49 CEST] <ubitux> meh. [15:54:51 CEST] <nevcairiel> yes avi is strictly cfr [15:54:57 CEST] <nevcairiel> codecs hack around that in various odd ways [15:55:10 CEST] <nevcairiel> some video codecs have 0-packets to emulate some sort of vfr [15:55:33 CEST] <ubitux> not a surprise there isn't much subtitles codecs in avi [15:55:57 CEST] <nevcairiel> avi is very limited format, for some reason its just been hacked up to support all sorts of crazy crap [15:56:28 CEST] <nevcairiel> they also have this special way to store subtitles in one big blob with in-band timings and let the demuxer just figure it out [15:56:58 CEST] <ubitux> yeah that's what happened with the ssa file in the avi? [15:57:21 CEST] <nevcairiel> i've seen it with ass and srt, i think [15:57:27 CEST] <nevcairiel> but i dont really see any other crazy subtitle formats [15:57:32 CEST] <nevcairiel> so that may not be limited to those [15:58:13 CEST] <ubitux> we have an issue with xsub currently in avi [15:58:28 CEST] <ubitux> they are muxed with a 0/0 timescale [15:58:32 CEST] <nevcairiel> i honestly dont even know what that is [15:58:39 CEST] <ubitux> so we fallback on a 1/25 [15:59:00 CEST] <ubitux> (so subtitles get demuxed approximately as pts = 1, 2, 3, ... ) [15:59:18 CEST] <ubitux> and then the decoder set the start/end time [15:59:30 CEST] <ubitux> but it means we have a drift because the pts should be 0 [16:00:01 CEST] <ubitux> nevcairiel: it's the divx bitmap subtitles [16:00:30 CEST] <ubitux> it's the only format along with dvdsub to use this start/end display time in the decoded AVSubtitle [16:00:37 CEST] <nevcairiel> i see [16:20:07 CEST] <jamrial> nevcairiel: i think 1c9e8616c535ef496e7ee8a5cbc5e9e972a6977d will break ABI for 3.2 seeing we cut 3.1 with this api but without this addition [16:20:56 CEST] <jamrial> mmh, no wait, the struct is in the internal header [16:21:01 CEST] <nevcairiel> its only a new function [16:21:35 CEST] <jamrial> yeah, i was worried about the changes to the struct, but it's internal [16:21:40 CEST] <jamrial> nevermind then [16:30:26 CEST] <nevcairiel> it would've been nice nevertheless to get the new api in 3.1, but what can you do [16:34:47 CEST] <BtbN> it isn't release yet? So can't you push it to the 3.1 branch? [17:16:03 CEST] <jamrial> nevcairiel: what btbn said, we can still backport that commit or any other until the release is tagged [17:53:11 CEST] <jamrial> michaelni: since you're doing the release, would you agree to include the latest merge batch from master into 3.1? [17:53:26 CEST] <jamrial> or are you already in the middle of testing/packaging? [17:54:28 CEST] <jamrial> cherry picking the above api alone would make the supposed branch cut point innacurate (there was a jpeg2k change before it), so i'm not sure that'd be a good idea [18:07:14 CEST] <michaelni> jamrial, feel free to include the commits ill make the release in a few hours [18:07:32 CEST] <michaelni> still wanted to fix a libopenjpeg issue i saw [18:11:07 CEST] <cone-970> ffmpeg 03Michael Niedermayer 07master:e9394ca63dab: avcodec/libopenjpegenc: Set numresolutions by default to a value that is not too large [18:20:41 CEST] <michaelni> btw i get on master "libavutil/hwcontext_vdpau.c:447:0: warning: "GET_CALLBACK" redefined [enabled by default]" [18:21:34 CEST] <nevcairiel> does it tell you where the first one is? [18:22:11 CEST] <nevcairiel> oh i see [18:23:32 CEST] <nevcairiel> those two are identical, so either get rid of one or undef it after its use, i guess [18:24:13 CEST] <nevcairiel> hm, almost identical [18:30:07 CEST] <michaelni> jamrial, nevcairiel ill make the release from release/3.1 probably in 4-5 hours if you want to add or change anything in release/3.1. Of course if you need more time i can also wait and make the release tomorrow [18:30:40 CEST] <jamrial> michaelni: https://github.com/jamrial/FFmpeg/commits/release/3.1 https://github.com/jamrial/FFmpeg/commits/master is this ok? i essentially updated the marker in master and merged everything into 3.1 [18:46:05 CEST] <michaelni> jamrial, iam testing this a bit will reply once iam done [19:20:10 CEST] <cone-970> ffmpeg 03Marton Balint 07master:340cea9f22c1: avdevice/decklink_dec: fix bitrate calculations [19:20:11 CEST] <cone-970> ffmpeg 03Marton Balint 07master:1fc85d8511fb: avdevice/decklink: factorize cleanup function to common code [19:20:12 CEST] <cone-970> ffmpeg 03Marton Balint 07master:4ce0a77ec80f: avdevice/decklink: remove unused itermode iterators [19:20:13 CEST] <cone-970> ffmpeg 03Marton Balint 07master:38d75fe90696: avdevice/decklink: factorize device finder function [19:20:14 CEST] <cone-970> ffmpeg 03Marton Balint 07master:e22760aafd30: avdevice/decklink: always free decklink resources on error [19:20:15 CEST] <cone-970> ffmpeg 03Marton Balint 07master:8f9fa49bd8bf: avdevice/decklink: add support for setting duplex mode [19:20:16 CEST] <cone-970> ffmpeg 03Marton Balint 07master:da89c6e37cf2: avdevice/decklink: add support for audio and video input selection [19:20:17 CEST] <cone-970> ffmpeg 03Marton Balint 07master:cf0a05668b99: avdevice/decklink: add support for setting input packet timestamp source [19:20:52 CEST] <michaelni> jamrial, seems to still work [19:20:59 CEST] <JEEB> so, uh, anyone know where some HLG test content can be grabbed? [19:21:24 CEST] <JEEB> it was just implemented in mpv's opengl renderer and it'd be nice to get some actual test content for it [19:58:50 CEST] <cone-970> ffmpeg 03James Almer 07master:069fd69662a1: Update FFmpeg 3.1 cut marker [19:59:25 CEST] <jamrial> ugh, hook declined for the 3.1 branch [19:59:53 CEST] <jamrial> it could have aborted the whole push in that case [20:00:10 CEST] <jamrial> "remote: -Deny- ERROR: update contains a merge." [20:02:13 CEST] <nevcairiel> you need to add a Merged-by line [20:03:29 CEST] <jamrial> nevcairiel: ok, let me try again [20:03:52 CEST] <jamrial> i any case marton's push above kinda made things a bit more complex [20:04:26 CEST] <nevcairiel> not really [20:04:41 CEST] <nevcairiel> you dont need to re-do the merge, just amend the log message [20:24:00 CEST] <cone-970> ffmpeg 03Anton Khirnov 07release/3.1:35c858066840: avconv: stop using AVStream.codec [20:24:01 CEST] <cone-970> ffmpeg 03Diego Biurrun 07release/3.1:e2a3df1a4640: avconv: Use more precise deprecation ifdefs [20:24:02 CEST] <cone-970> ffmpeg 03Diego Biurrun 07release/3.1:e45a638f50cc: dump: Drop unused variable [20:24:03 CEST] <cone-970> ffmpeg 03Diego Biurrun 07release/3.1:52567e819866: get_bits: Drop some TRACE-level debug code [20:24:04 CEST] <cone-970> ffmpeg 03Luca Barbato 07release/3.1:74b1bf632f12: mp3: Make the extrasize explicit [20:24:05 CEST] <cone-970> ffmpeg 03Anton Khirnov 07release/3.1:14634429b915: lavf: update muxing doxy [20:24:06 CEST] <cone-970> ffmpeg 03Anton Khirnov 07release/3.1:5f30ac27795f: lavc: deprecate avcodec_copy_context() [20:24:07 CEST] <cone-970> ffmpeg 03Anton Khirnov 07release/3.1:04fc8e24a091: lavc: deprecate avcodec_get_context_defaults3() [20:24:08 CEST] <cone-970> ffmpeg 03Anton Khirnov 07release/3.1:2ef6dab0a79a: lavc: document that avcodec_close() should not be used [20:24:09 CEST] <cone-970> ffmpeg 03Anton Khirnov 07release/3.1:ac84e618df47: avfiltergraph: check the query_formats() return value [20:24:10 CEST] <cone-970> ffmpeg 03Francois Cartegnie 07release/3.1:ad61da054bd8: jpeg2000: Fix profile define values [20:24:11 CEST] <cone-970> ffmpeg 03Diego Biurrun 07release/3.1:e47b8bbf0b54: avcodec: Bump micro version after changing public JPEG 2000 defines [20:24:12 CEST] <cone-970> ffmpeg 03Martin Storsjö 07release/3.1:3fdffc032e8e: rtsp: Use avcodec_descriptor_get instead of avcodec_find_decoder [20:24:13 CEST] <cone-970> ffmpeg 03Diego Biurrun 07release/3.1:07377fb55790: fate: More fine-grained dependencies for voice codec tests [20:24:14 CEST] <cone-970> ffmpeg 03Diego Biurrun 07release/3.1:7ca4fdc046a9: fate: More fine-grained dependencies for demuxer tests [20:24:15 CEST] <cone-970> ffmpeg 03Diego Biurrun 07release/3.1:4024b566d664: golomb: Give svq3_get_se_golomb()/svq3_get_ue_golomb() better names [20:24:16 CEST] <cone-970> ffmpeg 03Andrey Turkin 07release/3.1:24b5cff01bba: lavc: handle hw_frames_ctx where necessary [20:24:17 CEST] <cone-970> ffmpeg 03Anton Khirnov 07release/3.1:1c9e8616c535: hwcontext: add a function for opening devices [20:24:18 CEST] <cone-970> ffmpeg 03Anton Khirnov 07release/3.1:38392b2af815: hwcontext_vdpau: implement device creation [20:24:19 CEST] <cone-970> ffmpeg 03Anton Khirnov 07release/3.1:2e219b491bcc: hwcontext_cuda: implement device creation [20:24:20 CEST] <cone-970> ffmpeg 03Anton Khirnov 07release/3.1:8e70385a8ed0: hwcontext_dxva2: implement device creation [20:24:21 CEST] <cone-970> ffmpeg 03Anton Khirnov 07release/3.1:b8bf9194af60: hwcontext_vaapi: implement device creation [20:24:22 CEST] <cone-970> ffmpeg 03Anton Khirnov 07release/3.1:f72db3f2f3a8: avconv_vdpau: use the hwcontext device creation API [20:24:23 CEST] <cone-970> ffmpeg 03Anton Khirnov 07release/3.1:18c506e9e6e8: avconv_dxva2: use the hwcontext device creation API [20:24:24 CEST] <cone-970> ffmpeg 03Anton Khirnov 07release/3.1:9f7590f4e497: avconv_vaapi: use the hwcontext device creation API [20:24:25 CEST] <cone-970> ffmpeg 03Anton Khirnov 07release/3.1:80fb19bc234a: avconv: fix a check for av_bsf_get_by_name() return value [20:24:26 CEST] <cone-970> ffmpeg 03Anton Khirnov 07release/3.1:fe7b21c8f148: avconv: fix parsing bitstream filters [20:24:27 CEST] <cone-970> ffmpeg 03Anton Khirnov 07release/3.1:f5c43884190b: FATE: drop the audio stream from the dxtory test [20:24:28 CEST] <cone-970> ffmpeg 03Diego Biurrun 07release/3.1:6641819feedb: build: Ignore generated mapfile and remove it on distclean [20:24:29 CEST] <cone-970> ffmpeg 03Mark Thompson 07release/3.1:2bfa067d0b63: vaapi_encode: Check config attributes before creating config [20:24:30 CEST] <cone-970> ffmpeg 03Mark Thompson 07release/3.1:b51c7c6b8a5b: vaapi_h264: Fix frame_num after non-reference frames [20:24:31 CEST] <cone-970> ffmpeg 03Mark Thompson 07release/3.1:a86aa16088ad: vaapi_h264: Add trivial support for low-power encoding [20:24:32 CEST] <cone-970> ffmpeg 03Luca Barbato 07release/3.1:5264e7ba217b: ac3: Check the array bound before dereferencing [20:24:33 CEST] <cone-970> ffmpeg 03Diego Biurrun 07release/3.1:dc40a70c5755: Drop unnecessary libavutil/x86/asm.h #includes [20:24:34 CEST] <cone-970> ffmpeg 03Paul B Mahol 07release/3.1:8fb92ea7e2a6: avcodec: add YUY2 Lossless Codec decoder [20:24:35 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:b8945c4e2a1b: Merge commit '35c858066840352d6d43385bbc728467c5150974' [20:24:36 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:4531981a9b20: Merge commit 'e2a3df1a464091075040a81ffc419fa21a8a5fd8' [20:24:37 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:b23d4e52fd24: Merge commit 'e45a638f50cc1dbeb87b9792e68f57e77fc0c3b5' [20:24:38 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:e2836397f11c: Merge commit '52567e8198669a1e7493c75771613f87a90466c3' [20:24:39 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:314e6086315d: Merge commit '74b1bf632f125a795e66e5fd0a060b9c7c55b7a3' [20:24:40 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:97bdb94341ae: Merge commit '14634429b915333f3612eaf41db3954222dc4aaf' [20:24:41 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:6988cf2969d7: Merge commit '5f30ac27795f9f98043e8582ccaad8813104adc4' [20:24:42 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:69c38d64d745: Merge commit '04fc8e24a091ed1d77d7a3c0cbcfe60baec19a9f' [20:24:43 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:f9a186c59b4c: Merge commit '2ef6dab0a79a9852a92ed80b07f9e32a37530d9e' [20:24:44 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:7c6ae9ca0489: Merge commit 'ac84e618df4765ba751327497994066d0931e6a8' [20:24:45 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:46ff31d39c2e: Merge commit 'ad61da054bd8c74a5d5b38d80846228fc6147108' [20:24:46 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:b95534bb674a: Merge commit 'e47b8bbf0b54599d44b9330eb4d68cdde4f6d298' [20:24:47 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:f972653ec198: Merge commit '3fdffc032e8ea5676bc0c2551b900c0dc887835b' [20:24:48 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:093e06f2d687: Merge commit '07377fb557909015338b4c215b87b9c73ea577ad' [20:24:49 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:324f0fbff124: Merge commit '7ca4fdc046a945949866bb6fc550e3cab1fc8c00' [20:24:50 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:b20fe650ef85: Merge commit '4024b566d664a4b161d677554be52f32e7ad4236' [20:24:51 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:2c1d0f871f6a: Merge commit '24b5cff01bbac4e08acfd6d19c499e880988f520' [20:24:52 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:481f320aa388: Merge commit '1c9e8616c535ef496e7ee8a5cbc5e9e972a6977d' [20:24:53 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:613ac3bf82cb: Merge commit '38392b2af815898b8716826c4e29d95c04fb2647' [20:24:54 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:c5a0c16850fc: Merge commit '2e219b491bcc0845248345fdad31231b081e06d1' [20:24:55 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:162370b47320: Merge commit '8e70385a8ed06f96f1e9e35cf7b6788a5c56eded' [20:24:57 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:ed5d03ff6f90: Merge commit 'b8bf9194af602cf3a4bcd19a5e278e3d6d69f8fa' [20:24:57 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:844256740d27: Merge commit 'f72db3f2f3a8c83a4f5dede8fa03434b2bf676c6' [20:24:58 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:85da4f92580d: Merge commit '18c506e9e6e8df8b1d496d093077b8240ea68c28' [20:24:59 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:06a0e184359b: hwcontext_dxva2: Use GetDesktopWindow instead of GetShellWindow [20:25:00 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:4e6f2dbcd3ca: Merge commit '9f7590f4e497c12693247d7f935a20d7773a64dd' [20:25:01 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:c9ee36e60ffb: Merge commit '80fb19bc234a3f2350d891adf39f3738a8e4849f' [20:25:02 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:7fe7cdca3665: Merge commit 'fe7b21c8f148493c6fbceb7f887a77531dd1ae0e' [20:25:03 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:cd52ec2337ae: Merge commit 'f5c43884190be094749acfba104e3eab98d8ff1e' [20:25:04 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:5a9134f5f142: Merge commit '6641819feedb086ebba3d2be89b8d33980f367e1' [20:25:05 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:18b1b8be6a2a: Merge commit '2bfa067d0b636e7b2004fb0ad5a53d0d48c6de32' [20:25:06 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:d3327b7eda97: Merge commit 'b51c7c6b8a5b35cfd06cb9655f9ec4c9f0ddd81b' [20:25:07 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:f2a3798ea459: Merge commit 'a86aa16088ad7f22a8918d71adb8c040d6033d84' [20:25:08 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:5e418fd63a29: Merge commit '5264e7ba217b3c0ceae813917134e1ab52573141' [20:25:09 CEST] <cone-970> ffmpeg 03Hendrik Leppkes 07release/3.1:c142dc203e25: Merge commit 'dc40a70c5755bccfb1a1349639943e1f408bea50' [20:25:10 CEST] <cone-970> ffmpeg 03Michael Niedermayer 07release/3.1:e9394ca63dab: avcodec/libopenjpegenc: Set numresolutions by default to a value that is not too large [20:25:11 CEST] <cone-970> ffmpeg 03James Almer 07release/3.1:104c357b6a3e: Merge branch 'master' into release/3.1 [20:25:12 CEST] <cone-970> ffmpeg 03James Almer 07release/3.1:970f2ad966c2: Update FFmpeg 3.1 cut marker [20:25:58 CEST] <jamrial> sorry for the spam [20:31:27 CEST] <cone-970> ffmpeg 03James Almer 07master:c6f2d1a21f80: changelog: fix entry order [20:31:29 CEST] <cone-970> ffmpeg 03James Almer 07release/3.1:cf09348b9e03: changelog: fix entry order [20:48:30 CEST] <andrey_turkin_> a lot of merges done in a day. great job! [21:15:18 CEST] <cone-970> ffmpeg 03Martin Vignali 07master:971ee09d32a4: fate/exr : add tests for file with half and float channels [21:15:19 CEST] <cone-970> ffmpeg 03Martin Vignali 07master:bd2cec7021a0: fate/webp : add test for webp lossless decoding (rgb and rgba) [21:30:57 CEST] <atomnuker> nevcairiel: was it C89->C99 converters that had trouble with for (int loops? [21:33:15 CEST] <atomnuker> (or was it ancient broken MSVC compilers which shouldn't have been used to compile C in the first place) [21:33:18 CEST] <rcombs> (you mean C89->C99?) [21:33:29 CEST] <rcombs> (erm) [21:33:31 CEST] <atomnuker> yes [21:33:33 CEST] <rcombs> (C99->C89) [21:40:17 CEST] <kierank> for( int is not c89 that was the problem in the past [21:41:09 CEST] <rcombs> does anyone care about C99->C89 or ancient MSVCs anymore [21:41:36 CEST] <JEEB> 2013 u2 and 2015 should now handle c99 well enough [21:41:51 CEST] <JEEB> I'm not sure if we should try to maintain the older stuff with the conversion app [21:42:07 CEST] <rcombs> sounds not worth it [21:42:39 CEST] <rcombs> (is there any sane reason to be using a MSVC older than 2013?) [21:42:57 CEST] <JEEB> nope, since even the XP aimers can use 2013 [21:42:58 CEST] <rcombs> ("building on WinXP" doesn't count as sane) [21:43:05 CEST] <jamrial> 2012 still compiles with that tool and passes most fate tests [21:43:47 CEST] <jamrial> and i think someone fixed a compilation error with 2010 not too long ago, so that also works, again with the tool [21:44:12 CEST] <atomnuker> so no reason to keep not using for (int loops anymore? brb writing email [21:44:19 CEST] <jamrial> 2013 is the minimum to get fate to fully pass anyway [21:45:47 CEST] <jamrial> atomnuker: at this point it's done mainly for cosmetic reasons i guess [21:45:50 CEST] <jamrial> constitency with the rest of the codebase [21:52:56 CEST] <nevcairiel> breaking existing support for compilers, especially if they are tested by fate as well, is not something we should do for some silly cosmetic like moving the int [21:53:11 CEST] <nevcairiel> (i dont know if thats something that breaks it, fwiw) [21:53:31 CEST] <atomnuker> we have fate tests for those, don't we [21:53:47 CEST] <atomnuker> if they get tripped we can always change them, it's a silly cosmetic tweak after all [21:53:55 CEST] <nevcairiel> git master is not for experiementing with things :p [21:54:44 CEST] <atomnuker> not an experiment if you know what you're doing [21:55:03 CEST] <atomnuker> we can't live in the past forever you know [21:55:12 CEST] <nevcairiel> if you knew what you were doing, you wouldnt need fate to confirm if it breaks :) [21:56:41 CEST] <atomnuker> but what if the compiler's broken and doesn't know 1 << 1 + 1 != (1 << 1) + 1 [22:00:29 CEST] <andrey_turkin_> I don't think there is much reason to worry about MSVC < 2013. Main force to use particular MSVC version (apart from licensing) would be to link with some binary libraries, and most of the vendors provide at least 2013 compatible binaries these days. [22:00:58 CEST] <nevcairiel> the main point is that we dont decide to drop support for a compiler version on a whim like this [22:00:58 CEST] <rcombs> does that even matter when it's a C lib [22:01:18 CEST] <nevcairiel> especially for silly cosmetics [22:02:11 CEST] <andrey_turkin_> if only thing to keep older MSVC happy is to not use declarations in for loop - then maybe [22:02:20 CEST] <andrey_turkin_> is it the only thing? [22:03:57 CEST] <andrey_turkin_> I actually tried to build ffmpeg with MSVC 2010 some time ago - it was a giant pain to build and then some pain to use [22:05:26 CEST] <andrey_turkin_> it's actually seemed easier to build it with mingw crosscompilation (and now then cv2pdb tool works better, you can even get some debugging information for cross-compiled ffmpeg) [22:05:53 CEST] <nevcairiel> vs2012 seems to be fine with for (int i = ...) btw [22:05:58 CEST] <nevcairiel> must have been some other crazy compiler [22:06:14 CEST] <wbs> nevcairiel: no, c99toc89 has _rudimentary_ support for int declarations there [22:06:39 CEST] <wbs> like, it works for trivial cases. not tested much, not intended to be used [22:06:44 CEST] <nevcairiel> i see [22:06:57 CEST] <andrey_turkin_> there was some compiler which bleeded declaration outside of scope. Maybe that was the problem [22:07:32 CEST] <wbs> yes, there are such warnings/errors for gcc and/or clang, which are turned on intentionally to catch these issues, since the policy is to not use them [22:08:01 CEST] <wbs> other than that, I really agree with nevcairiel. since all the code builds just fine right now, I dont see the hurry to drop something that works, unless you have a compelling case [22:08:19 CEST] <wbs> every time you drop support for something like that, you rob a perfectly working setup from somebody [22:08:28 CEST] <JEEB> true [22:08:33 CEST] <wbs> forcing them to do extra boring upgrade work instead of something productive [22:08:52 CEST] <wbs> and every time you do such an upgrade dance, you need to upgrade X and Y and Z, just because somebody said "I don't think you should be using that" [22:09:13 CEST] <JEEB> the problem of course is if nobody is really checking it. if we have FATE setups then that's fine of course [22:09:31 CEST] <JEEB> then we can't really say we support it in any way [22:09:50 CEST] <JEEB> that said as I noted, we do have some FATE boxes for those compilers [22:10:30 CEST] <atomnuker> fine, but if I catch any of you defending that in 5 years I'll bring a gallon of dr pepper and forcibly make you drink that [22:10:59 CEST] <atomnuker> no one should be using 25+ year old compilers [22:11:35 CEST] <wbs> if there's no technical reason in 5 years why you shouldn't be able to use MSVC 2010, I'd still use the same argument [22:11:45 CEST] <wbs> "zomg old, I don't think you should use it" is not a valid argument [22:11:47 CEST] <rcombs> atomnuker: is that supposed to be a threat or a promise [22:12:02 CEST] <wbs> (people shouldn't say what others should or should not use) [22:12:13 CEST] <wbs> if there's a decent reason why one can't support it any longer, fine [22:12:14 CEST] <rcombs> wbs: forces developers to keep old compatibility layers in place [22:12:18 CEST] <atomnuker> ^^!! [22:13:16 CEST] <wbs> rcombs: sure. the c99conv setup stuff in configure, which afaik is the only thing you could drop, hasn't required any maintainance yet in the 4 years in the codebase [22:13:39 CEST] <atomnuker> if things get really bad I'll say "no one MUST use X right now" [22:13:48 CEST] <atomnuker> which isn't the same as saying they shouldn't [22:13:58 CEST] <wbs> c99conv itself isn't maintained much though, so if one runs into issues with it that myself or someone else can't be arsed to fix, then sure [22:14:08 CEST] <wbs> (I've done a few minor fixes on it so far) [22:14:15 CEST] <jamrial> atomnuker: every other trac ticket has some user with something like gcc 4.2 or older on some obscure arch that replies "it works, we won't be changing the compiler" when asked to upgrade [22:14:23 CEST] <jamrial> some people love their ancient setups :p [22:14:33 CEST] <atomnuker> it will break some day [22:14:54 CEST] <atomnuker> 4.2 isn't that ancient [22:15:04 CEST] <jamrial> ten years old by now [22:15:05 CEST] <wbs> gcc 4.2 is way way way more ancient than MSVC 2010 [22:15:08 CEST] <atomnuker> we still have a 12 year old gcc version on fate right now [22:15:21 CEST] <fritsch> does ffmpeg still run on windows xp? [22:15:22 CEST] <atomnuker> gcc 2 or gcc 3, can't remember [22:15:29 CEST] <atomnuker> yeah it does [22:15:32 CEST] <fritsch> hehe [22:15:45 CEST] <fritsch> and you like to fix newest compiler bugs on ancient windows xp? [22:15:52 CEST] <atomnuker> why shouldn't it, it's just tossing number around, not asking the kernel if there's a sound blaster installed [22:16:03 CEST] <nevcairiel> there arent really that many features that would force a update to a newer windows [22:16:13 CEST] <rcombs> hmm, I was going to point out threads and atomics [22:16:21 CEST] <andrey_turkin_> using c11 <- not going to happen ever unless there is c11toc89? [22:16:24 CEST] <fritsch> yeah, i was also after threads and atomics [22:16:27 CEST] <rcombs> but apparently MSVC still doesn't support those in C [22:16:34 CEST] <nevcairiel> we needed an emulation for pthread_once at one point, but that was really not that complicated [22:16:36 CEST] <rcombs> 5 years later [22:16:46 CEST] <fritsch> kodi has it until today [22:16:58 CEST] <rcombs> why is MSVC so bad [22:17:09 CEST] <nevcairiel> MS just doesnt care about C, they are a C++ shop [22:17:16 CEST] <andrey_turkin_> looks like their (valuable) customers don't care about c99 [22:17:18 CEST] <nevcairiel> not that new C features are really that good [22:17:27 CEST] <nevcairiel> the "modern" C features have awkward syntax [22:17:31 CEST] <nevcairiel> like it wants to be C++ but cant [22:17:37 CEST] <atomnuker> wut? [22:17:40 CEST] <atomnuker> which features? [22:17:44 CEST] <rcombs> well C threads are useless if you already have pthreads [22:17:52 CEST] <rcombs> just, MSVC doesn't because ?????? [22:18:01 CEST] <nevcairiel> pthreads is not C :p [22:18:03 CEST] <iive> will there ever be templetes for C ? [22:18:14 CEST] <jamrial> fritsch: i think you can get ffmpeg working on windows 98 if you compile using and old mingw build [22:18:23 CEST] <rcombs> so they added threads to C and I'm like "oh hey maybe MSVC will have standard threading now" [22:18:24 CEST] <rcombs> nope [22:18:42 CEST] <JEEB> win9x has djgpp [22:18:47 CEST] <JEEB> or well, dos/win9x [22:19:13 CEST] <nevcairiel> rcombs: thats C11 either way, noone comes even close to claiming msvc supports that [22:19:45 CEST] <nevcairiel> atomnuker: those C11 things like _Generic, just looks weird for C [22:19:56 CEST] <rcombs> nevcairiel: I'm just -_- because what was the point of adding it if it doesn't do anything pthreads don't and isn't supported on anything that didn't already have pthreads [22:20:32 CEST] <nevcairiel> C threads are useless either way, the standardization comes decades too late to matter [22:20:37 CEST] <atomnuker> nevcairiel: generics are basically a preprocessor macro - if variable is float use this bit of code, else... [22:20:46 CEST] <nevcairiel> atomnuker: i know what they are, thats not the point [22:20:53 CEST] <nevcairiel> i find the look stupid in C [22:20:56 CEST] <nevcairiel> they* [22:21:02 CEST] <rcombs> nevcairiel: they would've been useful if MSVC had added support [22:21:15 CEST] <andrey_turkin_> frankly it would make more sense to switch to c++11 than to c11 though [22:21:31 CEST] Action: andrey_turkin_ ducks [22:21:35 CEST] <rcombs> then you could switch code to use C threads instead of pthreads and have support everywhere [with modern compilers] [22:21:44 CEST] <atomnuker> but yeah, they're kinda weird, but that's what they could do to make it macro-like I suppose [22:22:32 CEST] <andrey_turkin_> I think they had to call them these strange names just to make sure it doesn't conflict with already existing names. Basically everyone already has "Thread" in their namespace, right? ) [22:22:36 CEST] <atomnuker> anything else (that they haven't removed yet because they realized in C1X+1 it's a bad feature) [22:23:15 CEST] <nevcairiel> the entire naming scheme is odd with _Identifier scheme, but it probably really is for silly reasons like conflict avoidance [22:23:36 CEST] <rcombs> the user should never have to deal with _Stuff, though [22:23:39 CEST] <andrey_turkin_> iirc that's the reserved portion of namespace so they had to [22:23:52 CEST] <rcombs> since the headers will map normal names to them when included [22:27:32 CEST] <rcombs> like how `<tgmath.h>` does most of the things you'd want to do with _Generic [22:28:30 CEST] <nevcairiel> its an awkward way to implement overloading :p [22:28:59 CEST] <rcombs> yeah, well, C [22:29:25 CEST] <rcombs> _Generic is unusual in not having a macro; I guess because it's macro-like itself [22:31:33 CEST] <RiCON> marton balint around here? [22:59:28 CEST] <Compn> RiCON : i dont see him in this irc chan [23:09:05 CEST] <RiCON> --enable-decklink building seems broken, i'll bisect before creating the ticket [23:13:01 CEST] <rkern> RiCON, does the error have something to do with c++11? [23:15:46 CEST] <RiCON> not sure? https://i.fsbn.eu/cUtp.txt [23:17:06 CEST] <nevcairiel> rkern: nah he doesnt build on osx [23:23:31 CEST] <RiCON> 8f9fa49 is the first bad commit [23:28:06 CEST] <cone-970> ffmpeg 03Rick Kern 07master:729d82abae2f: configure: use c++98 for c++ files [23:34:28 CEST] <RiCON> also fails with -std=c++98 btw [23:40:08 CEST] <cone-970> ffmpeg 03Rick Kern 07release/3.1:18ce5a4d1b3f: configure: use c++98 for c++ files [00:00:00 CEST] --- Mon Jun 27 2016

1 0

ffmpeg.log.20160626
by burek 27 Jun '16

27 Jun '16

[00:20:35 CEST] <jasom> I'm getting a lot of audio skipping with a corresponding "exponent-out-of-range" error message with AC3s from two of my dvds; they play fine in a dvd player. Any ideas what I can do? [00:23:25 CEST] <BtbN> Open a bug and upload a sample. [00:23:54 CEST] <imperio_> hi [00:24:14 CEST] <imperio_> I've been trying to build dynamic libraries but only get static ones [00:24:36 CEST] <c_14> --enable-shared ? [00:24:41 CEST] <imperio_> I looked into the docs but wasn't able to find how to run "make install" and make it actually builds dynamic libraries [00:24:51 CEST] <imperio_> c_14: to configure or to make? [00:24:56 CEST] <c_14> configure [00:25:08 CEST] <imperio_> I try then, thanks! [00:32:22 CEST] <imperio_> c_14: all good, thanks again for your help! :) [01:15:36 CEST] <imperio_> just by curiosity, does someone know if there are official bindings for ffmpeg libraries? [01:17:25 CEST] <c_14> The only official thing is the C bindings [01:18:55 CEST] <imperio_> hum ok [01:18:58 CEST] <imperio_> too bad [01:19:23 CEST] <imperio_> I'm trying to use it in rust and it's quite complicated due to my lack of knowledge of ffmpeg [01:19:43 CEST] <c_14> most languages have a way to interface with C libraries [01:20:48 CEST] <imperio_> that's not the problem here [01:20:55 CEST] <imperio_> I already bound gtk into rust [01:21:25 CEST] <imperio_> the problem is really that I find ffmpeg really hard to use for the moment ^^' [01:21:37 CEST] <furq> you could maybe look at PyAV [01:21:49 CEST] <furq> those are the only unabandoned language bindings i know of, although they're not complete [01:22:00 CEST] <imperio_> so there is one [01:22:04 CEST] <imperio_> good to know [01:22:10 CEST] <c_14> There is no "official" binding [01:22:15 CEST] <c_14> There may be unofficial third-party bindings [01:22:30 CEST] <imperio_> ok ok [01:22:40 CEST] <imperio_> that's a shame, those libraries look wonderful [02:00:35 CEST] <trewq> Hi, Wanted to see what options we on getting sliding texts live the ones on this video: [02:00:53 CEST] <trewq> https://www.youtube.com/watch?v=XWMwl3Y32YU [02:01:19 CEST] <trewq> I see two options, one is using the drawtext filter, but it may get complicated with formatting [02:02:07 CEST] <trewq> the second option is to have the text done in a drawing program, create a clip with the sliding text and then overlay in on the main video [02:02:10 CEST] <trewq> thoughts [02:02:12 CEST] <trewq> ? [02:05:54 CEST] <imperio_> I'm facing a strange issue: when I call avformat_open_input, it seems it does almost nothing [02:06:10 CEST] <imperio_> the only field with a value in AVFormatContext is filename [02:06:17 CEST] <imperio_> all other fields are equal to 0 [02:06:24 CEST] <imperio_> someone has an idea of what's wrong? [02:07:22 CEST] <imperio_> https://github.com/GuillaumeGomez/video-metadata-rs/blob/master/ffi/info.c [02:07:24 CEST] <imperio_> here's the code [02:07:32 CEST] <imperio_> (quite short) [02:07:48 CEST] <imperio_> the call is here: https://github.com/GuillaumeGomez/video-metadata-rs/blob/master/ffi/info.c#… [02:10:20 CEST] <c_14> trewq: you can also create ass subtitles and overlay them [03:57:19 CEST] <MichaelTiebesl> goodmorning, can somebody help me with ffmpeg? [03:57:32 CEST] <MichaelTiebesl> i used before soundconverter on linux for that [03:59:39 CEST] <c_14> what exactly do you need help with? [04:00:38 CEST] <MichaelTiebesl> c_14:im a linux user, i want mp3 to oggg with 44100khz and 320 as default in ogg [04:00:59 CEST] <c_14> ffmpeg -i mp3 -ar 44100 -b:a 320k out.ogg [04:01:03 CEST] <c_14> vorbis or opus? [04:01:09 CEST] <MichaelTiebesl> vorbis [04:01:17 CEST] <c_14> then that should be fine [04:01:19 CEST] <MichaelTiebesl> im reading thishttp://ffmpeg.org/ffmpeg-all.html#Video-and-Audio-file-format-conversion [04:03:50 CEST] <MichaelTiebesl> c_14 thanks a lot [04:03:58 CEST] <MichaelTiebesl> it is working [05:49:37 CEST] <Bray90820> What do these errors mean? [05:49:39 CEST] <Bray90820> http://pastebin.com/raw/uBzaC8VH [06:35:36 CEST] <HSKW> hello i've compiled on my debian with the guide https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu, but when i start ffmpeg i receive this error: [06:35:43 CEST] <HSKW> ffmpeg: error while loading shared libraries: libx264.so.132: cannot open shared object file: No such file or directory [06:35:56 CEST] <HSKW> how i can fix it? [07:28:21 CEST] <yagiza> Hello! [07:29:20 CEST] <yagiza> Do any1 know, where can I find a list of RTP format specific (private) options? [09:22:52 CEST] <Fyr> hey, guys, what -tune option would you recommend for libx265 if the video was filtered with a denoiser/sharpener? [09:25:53 CEST] <Fyr> some thin object, like hairs look a little bit weird, dissolved, too bright objects, like light from doorway in dark room, have halos. [09:28:55 CEST] <starstuff> Hello, I have an .mp4 file that just plays a .wav sound. I want to add a looking .gif to the .mp4 file, how would I do that? [09:29:18 CEST] <Fyr> add a cover art? [09:29:24 CEST] <starstuff> looking = looping [09:29:49 CEST] <starstuff> basically, I want the wav to play once and the gif to loop over and over. [09:30:56 CEST] <starstuff> Fyr: was that to me? [09:31:09 CEST] <Fyr> it was. [09:31:26 CEST] <starstuff> would you mind helping me with the command to do that? [09:34:01 CEST] <Fyr> starstuff, [09:34:01 CEST] <Fyr> $ ffmpeg -f gif -i input.gif -c:v libx264 -i audio.mp4 -c:a copy output.mp4 [09:36:31 CEST] <starstuff> Fyr: Thx. What is the libx264? [09:36:51 CEST] <Fyr> the video encoder for MP4 container [09:37:16 CEST] <starstuff> I get an error: Unknown decoder 'libx264' [09:37:20 CEST] <Fyr> I think, you may even skip that option since FFMPEG will add it automagically. [09:37:24 CEST] <starstuff> but that's odd because I was able to make an .mp4 before. [09:37:38 CEST] <Fyr> starstuff, try without this option. [09:38:00 CEST] <starstuff> ffmpeg -f gif -i input.gif -c:v -i audio.mp4 -c:a copy output.mp4 [09:38:04 CEST] <starstuff> like that? ^^ [09:38:37 CEST] <Fyr> starstuff, ommit -c:v libx264 completely. [09:39:35 CEST] <starstuff> okay no errors, but when I play the file, it opens up and the video is all black. the sound plays correctly. [09:39:53 CEST] <starstuff> what could that be? [09:42:41 CEST] <Fyr> starstuff, try this: [09:42:42 CEST] <Fyr> ffmpeg -f gif -i input.gif -pix_fmt yuv420p -c:a copy -y output.mp4 [09:44:24 CEST] <starstuff> Fyr: Yes that works to create the gif video. I'd like it to play the sound file also at the same time. And the gif should loop also. [09:45:28 CEST] <Fyr> the only way I think up right now - is to concatenate the videos into one. =))))) [09:45:33 CEST] <EugenA> I'm reading here https://trac.ffmpeg.org/wiki/StreamingGuide : FFmpeg supports splitting files (using "-f segment" for the output, see segment muxer) into time based chunks, useful for HTTP live streaming style file output. [09:45:45 CEST] <Fyr> the gurus here may suggest a better way. [09:46:39 CEST] <EugenA> will -f segment help me to solve problem with growing files? [09:54:59 CEST] <starstuff> Hmm okay. Maybe someone will know how to turn a .gif into a looping video file. [09:55:12 CEST] <Fyr> concatenation [09:55:17 CEST] <Fyr> ((= [09:55:41 CEST] <Fyr> starstuff, are on Linux? [09:55:45 CEST] <starstuff> Yes. [09:55:49 CEST] <Fyr> cool [09:55:58 CEST] <starstuff> Yeah, I know what the word means. Adding something onto the end of something else. [09:56:06 CEST] <starstuff> Just don't know how to make that work with ffmpeg [10:01:06 CEST] <Fyr> starstuff, [10:01:06 CEST] <Fyr> ffmpeg -f concat -i the_list.txt -c:v copy -an output2.mp4 [10:01:06 CEST] <Fyr> ffmpeg -i output2.mp4 -i output.mp4 -map 0:0 -c:v copy -map 0:1 -c:a copy -shortest final_output.mp4 [10:01:21 CEST] <Fyr> starstuff, the_list.txt: http://pastebin.com/36fvd1dg [10:03:18 CEST] <starstuff> Fyr: Are those two commands meant to be taken one after the other? [10:11:02 CEST] <starstuff> Fyr: On the final command, got this error: Stream map '0:1' matches no streams. To ignore this, add a trailing '?' to the map. [10:18:49 CEST] <starstuff> Fyr: Know how to fix that error maybe? [10:23:47 CEST] <Fyr> starstuff, right, use -map 1:1 instead [10:24:00 CEST] <Fyr> =) [10:24:22 CEST] <starstuff> Stream map '1:1' matches no streams. To ignore this, add a trailing '?' to the map. [10:24:35 CEST] <starstuff> Fyr: ^ [10:24:53 CEST] <starstuff> this is the command that gives the above error: ffmpeg -i output2.mp4 -i output.mp4 -map 0:0 -c:v copy -map 1:1 -c:a copy -shortest final_output.mp4 [10:25:25 CEST] <Fyr> ok, use [10:25:25 CEST] <Fyr> ffmpeg -i output2.mp4 -i input_audio.mp4 -map 0:0 -c:v copy -map 1:0 -c:a copy -shortest final_output.mp4 [10:25:25 CEST] <Fyr> instead of the second command. [10:26:11 CEST] <starstuff> input_audio.mp4: No such file or directory [10:26:32 CEST] <Fyr> starstuff, I meant the audio file. [10:26:52 CEST] <Fyr> you said, you have a WAV inside of an MP4 container. [10:27:56 CEST] <starstuff> Fyr: That works perfectly, except for one thing. The video doesn't loop [10:28:11 CEST] <Fyr> wrong [10:28:16 CEST] <Fyr> I must must loop. [10:28:28 CEST] <Fyr> it must be repeated ten times. [10:28:48 CEST] <Fyr> as set here: http://pastebin.com/36fvd1dg [10:28:57 CEST] <starstuff> Yea, it repeats ten times I mean, but it doesn't keep going forever like a normal .gif woulud [10:30:24 CEST] <Fyr> starstuff, then repeat it 60 times. [10:30:29 CEST] <starstuff> Could it be made recursive? I mean, for the last iteration to go back to the first? [10:30:32 CEST] <starstuff> haha [10:30:34 CEST] <starstuff> okay :) [10:30:34 CEST] <Fyr> no [10:30:43 CEST] <Fyr> it can't be recursive. [10:31:01 CEST] <starstuff> hmm really? [10:36:03 CEST] <starstuff> Fyr: when I run the first command, the video repeats itself however many times I specify in the_list.txt. But then after running the second command on it, after the audio finishes playing, the gif stops immediately. [10:36:30 CEST] <Fyr> starstuff, it's because of -shortestr option. [10:36:50 CEST] <Fyr> FFMPEG stops the video when that audio ends. [10:37:04 CEST] <starstuff> so remove -shortest? [10:37:12 CEST] <Fyr> wait [10:38:09 CEST] <Fyr> starstuff, use this instead: [10:38:09 CEST] <Fyr> ffmpeg -f concat -i the_list.txt -c:v copy -c:a copy final_output.mp4 [10:38:20 CEST] <Fyr> and forget about the second command. [10:39:22 CEST] <starstuff> okay, that last command makes the video play the gif animation as many times as I specified in the_list.txt. [10:39:24 CEST] <starstuff> but no sound [10:40:31 CEST] <Fyr> if the files listed in the_list.txt do not contain sound, the output file won't either. [10:40:54 CEST] <Fyr> the files in the list should have it. [10:42:17 CEST] <starstuff> Fyr: The file in the list is 'output.mp4' and it is the original gif animation converted to video. It just plays once. I need to add the sound file to it. [10:42:35 CEST] <Fyr> oh [10:42:41 CEST] <Fyr> sorry, I gotta go. [10:42:52 CEST] <starstuff> thanks for the help! [10:43:05 CEST] Action: Fyr unpacking furniture from IKEA [10:44:54 CEST] <starstuff> Anyone know how to add .wav to an .mp4 file? [10:47:20 CEST] <Guest85227> mp4 container doesnt support wav [10:50:36 CEST] <starstuff> does it support mp3? [10:51:21 CEST] <starstuff> would this work? ffmpeg -i output.mp4 -i coins.mp3 -c copy -map 0:0 -map 1:0 output.mp4 [10:51:47 CEST] <starstuff> I just want to add the sound to the already existing mp4 video [10:52:36 CEST] <starstuff> when I try that command and then play output.mp4, the video is gone and all I hear is the sound. [10:56:53 CEST] <starstuff> I tried this command also with the same result (the sound is added to the mp4 but the video becomes black): ffmpeg -i output.mp4 -i coins.mp3 -codec copy output.mp4 [10:57:51 CEST] <JEEB> mpeg-1 layer 3 fits mp4 just fine so it's either your ffmpeg or the playback f'ing it up [10:58:08 CEST] <JEEB> *fits into [10:58:44 CEST] <starstuff> I'm just using the default gnome video player app [10:59:52 CEST] <relaxed> the best players in linux are mpv or vlc [11:00:07 CEST] <starstuff> hmm I looked at the properties of the output.mp4 and it has no video stream. [11:01:13 CEST] <starstuff> somehow I'm not adding the audio stream to this .mp4 properly. [11:01:33 CEST] <relaxed> pastebin.com ffmpeg's command and console output for propper support [11:02:58 CEST] <starstuff> relaxed: Thx. Here it is: http://pastebin.com/9aMTPfSu [11:04:00 CEST] <relaxed> does ffplay play it correctly? [11:04:39 CEST] <starstuff> yes [11:04:51 CEST] <starstuff> I guess totem has a bug? [11:05:09 CEST] <relaxed> the bug is you're using totem [11:05:31 CEST] <starstuff> meh. I like to use gnome-desktop [11:05:34 CEST] <starstuff> :) [11:06:45 CEST] <relaxed> you can run mpv or vlc while using gnome- the former is recomended [11:06:51 CEST] <starstuff> okay, I'm making progress, but the last step has a problem still. I'll pastebin it. [11:07:07 CEST] <relaxed> +m [11:07:56 CEST] <starstuff> http://pastebin.com/1kWA48GQ [11:09:17 CEST] <starstuff> and basically, final_output.mp4 isn't doing what I want it to do. It's repeating the video portion the specified number of times in thelist.txt, but each repeat of the video portion is also repeating the audio. I just want the audio to play once, while the video repeats itself. [11:10:29 CEST] <relaxed> you'll probably have to concat a silent audio track along with the mp3 [11:11:24 CEST] <starstuff> dang. [11:11:39 CEST] <starstuff> any suggestions on how to go about doing that? [11:12:30 CEST] <starstuff> I have a silent.mp3 file [11:12:44 CEST] <starstuff> I'm not sure how to construct the ffmpeg command to do what I want though [11:13:16 CEST] <relaxed> loop the video to your heart's desire, then add the audio track last [11:14:13 CEST] <starstuff> hm, no idea how to do that [11:18:41 CEST] <starstuff> by the way, when I made the original video, it seems to have lost some quality from .gif I was using. Is there a way to alter the quality settings for the video? [11:20:15 CEST] <EugenA> what is "dc1394 v.2 A/V grab" ? [11:20:33 CEST] <EugenA> it is one of devices, i can capture from [11:20:48 CEST] <EugenA> is it firewire? [11:24:45 CEST] <relaxed> yes, dc1394 is firewire [11:25:29 CEST] <relaxed> starstuff: transcoding incurs loss of quality [11:26:02 CEST] <relaxed> to improve it see https://trac.ffmpeg.org/wiki/Encode/H.264 [11:28:02 CEST] <EugenA> I have Blackmagic Intensity Pro 4K card. ffmpeg can capture from this card, do I need to recompile ffmpeg with decklink support? [11:30:22 CEST] <relaxed> yes [11:31:09 CEST] <EugenA> how can I check it it is really needed? [11:31:32 CEST] <relaxed> well, decklink support is not enabled by default [11:31:54 CEST] <EugenA> maybe it it already enabled in my distro [11:32:20 CEST] <relaxed> ffmpeg -h formats 2>&1| grep -i deck [11:32:55 CEST] <EugenA> nothing [11:33:27 CEST] <relaxed> I think it's non-free, so it won't be shipped with your distro's build [11:35:23 CEST] <relaxed> hmm, maybe it's not [11:36:06 CEST] <relaxed> anyway, if you don't see "--enable-decklink" in ffmpeg's output then it's not [11:37:58 CEST] <EugenA> well, I'll try to build ffmpeg [11:41:06 CEST] <EugenA> relaxed: the problem I have - I need to encode growing files. Video is being recorded with blackmagic software, I need to encode and broadcast it to youtube [11:41:50 CEST] <EugenA> it seems I cannot work with growing files with ffmpeg... But if ffmpeg would capture, than I could also broadcast it without problems [12:06:27 CEST] <haasn> Is there a status quo on breaking widevine? [12:42:27 CEST] <kpr_> hi, how to i install ffmpeg with x265 on osx el captitan, is there a detailed guide? [12:43:28 CEST] <JEEB> if you use homebrew there should be a less or more bad formula for it and libx265 encoding is probably going to be an option that you can enable [12:46:24 CEST] <kpr_> ok [12:54:44 CEST] <EugenA> relaxed: compiled, now if I run ./ffmpeg -h formats 2>&1| grep -i deck I get: [12:54:53 CEST] <EugenA> configuration: --enable-decklink --extra-cflags=-I/home/operator/Downloads/ffmpeg-3.0.2/include/ --extra-ldflags=-ldl --extra-libs=-ldl --enable-shared --disable-static [12:55:04 CEST] <EugenA> that's all [13:09:32 CEST] <yagiza> Is there iLBC encoding specialist around? [13:16:50 CEST] <kpr_> thanks JEEB [13:39:03 CEST] <relaxed> EugenA: https://www.ffmpeg.org/ffmpeg-devices.html#decklink [13:50:42 CEST] <styler2go> Hi, i am trying to stream my webcam content with v4l2 to a rtmp destnation but i get the error: rtmp://192.168.0.104:1935/cam1: Input/output error. any idea? http://pastebin.com/V1tNEwqZ [13:53:23 CEST] <BtbN> rtmp usually has two path segments. [13:56:03 CEST] <styler2go> I am not sure what you mean, but the url is correct [13:56:47 CEST] <BtbN> I have never seen an rtmp url that's not rtmp://server/appname/streamname [13:56:58 CEST] <styler2go> It's my local rtmp server [13:57:09 CEST] <BtbN> What software is it? nginx? [13:57:13 CEST] <styler2go> yes [13:57:22 CEST] <BtbN> nginx-rtmp also uses that scheme [13:57:31 CEST] <styler2go> https://obsproject.com/forum/resources/how-to-set-up-your-own-private-rtmp-… [13:57:33 CEST] <BtbN> cam1 is the appname, you still have to append a streamname [13:57:38 CEST] <styler2go> Server: rtmp://<your server ip>/live [13:57:58 CEST] <BtbN> I very much guess "rtmp://192.168.0.104:1935/cam1/mystream" will just work. [13:58:07 CEST] <styler2go> i'll try it [13:58:20 CEST] <styler2go> rtmp://192.168.0.104:1935/cam1/test: Input/output error [13:58:41 CEST] <BtbN> then increase the loglevel and both your server and ffmpeg and see what exactly is failing [13:59:02 CEST] <styler2go> how do i increase the log level on ffmpeg? [13:59:12 CEST] <BtbN> -v verbose/debug/trace [14:01:20 CEST] <styler2go> http://pastebin.com/5nhrvt0v that's the -v trace shortly before it dies [14:10:52 CEST] <imperio_> hi [14:11:02 CEST] <imperio_> I'm still stuck on my current issue: https://github.com/GuillaumeGomez/video-metadata-rs/blob/master/ffi/info.c#… [14:11:30 CEST] <imperio_> avformat_open_input returns "invalid date found when processing input" [14:11:55 CEST] <imperio_> I wrote my code from ffmprobe (which works correctly with the same file) [14:12:11 CEST] <imperio_> did I forgot to initialize something somewhere? [14:46:07 CEST] <furq> imperio_: are you calling av_register_all [14:46:23 CEST] <imperio_> no [14:46:40 CEST] <imperio_> I should? [14:46:46 CEST] <furq> https://www.ffmpeg.org/doxygen/3.0/group__lavf__core.html#ga917265caec45ef5… [14:47:02 CEST] <imperio_> oh [14:47:09 CEST] <imperio_> well, thanks! :) [15:03:26 CEST] <imperio_> furq: working perfectly, thanks a lot! [17:53:47 CEST] <jumoog> hi its possible to pay for a requested feature? [17:55:19 CEST] <JEEB> yes, although usually this is done between a developer and the paying party [17:55:56 CEST] <JEEB> and then the feature is contributed into upstream so you don't have to maintain it yourself (unless it's a feature that is not found to be good to be upstreamed as-is by the FFmpeg developers) [17:58:23 CEST] <jumoog> i want feature to merge videos together based on the audio.. Adobe call this Multi-camera auto-sync [17:58:54 CEST] <jumoog> i currently use a python script :P [17:59:39 CEST] <JEEB> define it well enough and note the request around the ffmpeg-devel ML [17:59:59 CEST] <JEEB> sounds like something that would go upstream if implemented correctly [18:07:39 CEST] <tombert> this might be more of a libav question, but maybe someone here can help me; if I wanted to, from C, split a video file into something like 5 minute chunks (so a 12 minute video would have two five-minute chunks and one two-minute chunks), how would I go about doing that? [18:12:19 CEST] <JEEB> look at the PTS and in case of doing it on the not decoded stream level only do it during IRAPs [18:12:27 CEST] <JEEB> (Intra Random Access Pictures) [18:12:46 CEST] <JEEB> also make sure that your outputs have the necessary extradata in one way or another to initialize the decoder [18:13:08 CEST] <JEEB> also both FFmpeg and Libav projects provide the libav* libraries so this is the correct place [19:47:41 CEST] <HSKW> hi [19:51:18 CEST] <Fjorgynn> Hello world [19:52:31 CEST] <klaxa> world says hi [19:59:00 CEST] <HSKW> i've a problem to use ffmpeg with exec command on nginx... if i launch command on shell all ok [20:38:20 CEST] <LigH> Hi. [20:39:37 CEST] <LigH> Does ffmpeg support output bitdepth selection in libx265 at all? I tested -x265-params {output-depth=10|D=10|profile=main10}; neither was recognized. [20:40:01 CEST] <furq> -pix_fmt yuv420p10le [20:40:13 CEST] <LigH> May the libx265 internal parameter have a completely different name to the x265 CLI parameter? [20:40:54 CEST] <LigH> ŽSo the only way to select the bitdepth is indirectly via the input format? [20:41:23 CEST] <furq> the output format [20:41:32 CEST] <furq> i don't know if it's the only way but i'm pretty sure it works [20:41:41 CEST] <LigH> Okay... I will try. [20:43:35 CEST] <LigH> Interesting. [20:43:55 CEST] <LigH> Without pix_fmt, libx265 reports 8bit+10bit+12bit in my build. [20:44:08 CEST] <LigH> Adding your parameter, it only reports 10bit. [20:44:50 CEST] <LigH> It selects Main 10 profile, that appears to be correct for this case. [20:47:35 CEST] <LigH> Thanks, bye [00:00:00 CEST] --- Mon Jun 27 2016

1 0

ffmpeg-devel.log.20160625
by burek 26 Jun '16

26 Jun '16

[03:10:37 CEST] <cone-481> ffmpeg 03Michael Niedermayer 07master:46a60fe184cf: avformat: Fix ff_interleaved_peek() [03:51:52 CEST] <cone-481> ffmpeg 03Jing Yu 07master:311a953c7608: avcodec/ppc: fix broken build when compiling libavcodec with LLVM on PPC backend [04:01:37 CEST] <cone-481> ffmpeg 03Rick Kern 07master:8db203a9dd73: lavd/decklink: Fix compile issue on OS X [04:56:29 CEST] <jamrial_> rcombs: could you apply patch 1 and 2 of your autobsf patchset to fix the memleak for the 3.1 release? [04:57:02 CEST] <jamrial_> the rest can go in at a latter time, as they are or with changes [04:57:12 CEST] <jamrial_> but the memleak should be fixed for the release [04:59:53 CEST] <rcombs> I was just rebasing that set [05:00:30 CEST] <Illya> ubitux: sorry, haven't gotten round to updating my patch. I will be able to do it the day after tomorrow. (life's been very busy) [05:12:19 CEST] <jamrial_> rcombs: thanks [05:18:48 CEST] <rcombs> ah, there was an MPEGTS muxer change so I need to tweak fate [10:30:55 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:1e9b79b2dbc3: movenc: mark astronomical_body const string as static [10:42:42 CEST] <ubitux> so we have a nvenc encoder [10:42:55 CEST] <ubitux> but we also have a nvenc_h264 and nvenc_hevc encoder [10:43:05 CEST] <ubitux> (which are btw inconsistent names) [10:43:10 CEST] <ubitux> is this correct? [10:43:51 CEST] <ubitux> oh nvenc is an alias for nvenc_h264, ok... great... [10:44:10 CEST] <ubitux> can we please deprecate all of this and make it consistent? [10:49:04 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:0d95d88fbd1a: lavc: revert the Makefile part of 330177b [10:49:05 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:b45348130a60: Merge commit '0d95d88fbd1aeadafb8b0b1bfb880bf21b33132c' [11:08:29 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:5e2203448ab4: configure: improve the help text for external libraries [11:08:30 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:680ec710ec4b: Merge commit '5e2203448ab4cc8ea1d933b87f1b39b009201044' [11:24:03 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:c0f4c7db9fea: configure: move the hardware accel libs' entries in the help text [11:24:03 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:7bf52e12d4a1: Merge commit 'c0f4c7db9fea1c07d290a298b8db858b7ceed96d' [11:32:32 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:85ce9636e42d: configure: move the hardware accel libs' entries in the configure output [11:32:33 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:63ac806ccb75: Merge commit '85ce9636e42dbda06b7d0af76a528a64b113fb3a' [11:45:27 CEST] <cone-423> ffmpeg 03Derek Buitenhuis 07master:d68fb1475856: mjpegdec: Properly fail on malloc failure [11:45:28 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:2ab823d4a6ef: Merge commit 'd68fb1475856cf93199e2bc4eee3063902c35df7' [11:46:42 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:65dc7ca4c8e7: Add release notes for 12. [11:46:43 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:c7babd50de24: Merge commit '65dc7ca4c8e7e56362626a5d31e563e80108f104' [11:56:20 CEST] <ubitux> mmh [11:56:32 CEST] <ubitux> i can't push a merge containing several commits? [11:56:39 CEST] <nevcairiel> sure can [11:57:05 CEST] <ubitux> remote: -Deny- ERROR: update contains a merge. [11:57:09 CEST] <ubitux> maybe i missed something [11:57:13 CEST] <nevcairiel> did you include the Merged-by line? [11:57:15 CEST] <nevcairiel> thats required [11:58:30 CEST] <ubitux> oh that's what i missed [11:58:32 CEST] <ubitux> thanks [11:59:19 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:e42b9bc8945f: nvenc: fix the rc option definitions [11:59:20 CEST] <cone-423> ffmpeg 03Timo Rothenpieler 07master:795329dd4c5d: nvenc: Generate AUD NAL units for better compatiblity [11:59:21 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:9427d92f40d4: nvenc: add support for lossless encoding [11:59:22 CEST] <cone-423> ffmpeg 03Timo Rothenpieler 07master:a1e215ea0157: nvenc: Delay frame output to increase encoding speed [11:59:23 CEST] <cone-423> ffmpeg 03Timo Rothenpieler 07master:cea1fb854c26: nvenc: Generate bufferingPeriod/pictureTiming SEI [11:59:24 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:a1df7865039b: nvenc: only write the VUI signal type fields if they are set [11:59:25 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:2156c4c30097: nvenc: write the VUI signal properties for HEVC [11:59:26 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:f11ec8cee72f: nvenc: only support HW frames when CUDA is enabled [11:59:27 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:6f58b4dc477e: nvenc: drop the hard dependency on CUDA [11:59:28 CEST] <cone-423> ffmpeg 03Timo Rothenpieler 07master:09522a303db0: configure: Don't require nonfree for nvenc [11:59:29 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:9375c9746010: nvenc: list the major contributors in the copyright header [11:59:30 CEST] <cone-423> ffmpeg 03Philip Langdale 07master:10545f84b834: nvenc: De-compensate aspect ratio compensation of DVD-like content. [11:59:31 CEST] <cone-423> ffmpeg 03Anton Khirnov 07master:3399a26d3f57: nvenc: allow setting the number of slices [11:59:32 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:e13134c730bd: Merge commit '3399a26d3f57d462e839c0ee51223ae9aca20852' [12:00:11 CEST] <ubitux> an extra check would be welcome, as well as fixing the nvenc aliases [12:00:46 CEST] <ubitux> ok, anyone to continue the merge now? [12:00:50 CEST] <ubitux> i'd like to take a pause [12:01:08 CEST] <ubitux> next one is annoying though [12:01:36 CEST] <ubitux> ETA: ~150 commits left to merge [12:11:02 CEST] <nevcairiel> the next commit might not be mergeable since our ffmpeg wasnt migrated to codecpar yet [12:11:12 CEST] <nevcairiel> which should probably happen at some point [12:17:43 CEST] <ubitux> another commit we nooped? [13:12:46 CEST] <nevcairiel> well it wasnt realistic to merge it since they diverge way too much, so it was decided that it should rather be re-implemented separately instead of somehow hacking that into the merge [13:13:57 CEST] <ubitux> and it wasn't done :( [13:28:05 CEST] <ubitux> i guess i should add it to the merge-libav.txt [13:28:17 CEST] <ubitux> nevcairiel: anything else you know we need to add btw? [13:35:51 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:11ee8a450499: ffmpeg: do not use deprecated AVSubtitleRect.pict [13:42:02 CEST] <nevcairiel> ubitux: you can probably abstract that point and make it "all cli tools", but yeah [13:42:57 CEST] <nevcairiel> dont think we skipped big things otherwise [13:44:04 CEST] <ubitux> any reason we haven't updated the bitstream api usage too? [13:44:13 CEST] <nevcairiel> noone did it [13:44:14 CEST] <nevcairiel> :D [13:44:45 CEST] <nevcairiel> bsf migration is probably easy though [13:45:16 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:8ca78d0fefa0: lavf/utils: fix const warning at a find_decoder() call [13:45:17 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:dfd0c0f981c5: lavc/neontest: fix constness in arm/aarch64 avcodec_open2() wrappers [13:45:47 CEST] <ubitux> we probably want to do the bsf mig before codecpar [13:46:00 CEST] <nevcairiel> should finally merge rcombs bsf patchset as well [13:46:48 CEST] <ubitux> still not merged? [13:46:54 CEST] <ubitux> rcombs please apply your patches :(( [13:47:14 CEST] <ubitux> pretty sure you have a local stack of srt and ass patches too :( [13:51:38 CEST] <nevcairiel> he was talking about rebasing it yesterday [14:34:48 CEST] <ubitux> http://sprunge.us/HFXF mmh. [14:40:47 CEST] <cone-423> ffmpeg 03David Murmann 07master:0296b4b8d899: avformat/movenc: add option to use keys/mdta atoms for metadata [14:55:42 CEST] Action: ubitux trying to figure out the purpose of avctx->subtitle_header [14:55:56 CEST] <ubitux> why isn't it in extradata& [15:01:22 CEST] <nevcairiel> if you dont know, noone will :D [15:14:48 CEST] <ubitux> so it's the subtitle header in ass; and encoders uses the extradata to communicate to the muxer their own form of header/extradata [15:15:24 CEST] <ubitux> (encoders receive data in ass, with the ass header in that subtitle_header) [15:15:58 CEST] <ubitux> i suppose we don't have such problematic with audio or video because the raw forms don't have the need for headers [15:16:43 CEST] <ubitux> so the $1M question [15:16:51 CEST] <ubitux> should we add subtitle_header to codecpar? [15:17:15 CEST] <nevcairiel> doesnt seem to be lacking or needed right now [15:17:17 CEST] <nevcairiel> or is it? [15:17:41 CEST] <ubitux> will be needed for users who wish to use the codecpar api [15:17:52 CEST] <nevcairiel> what for? [15:17:57 CEST] <nevcairiel> shouldnt the main extradata be plenty? [15:18:11 CEST] <ubitux> it doesn't contain the ass header [15:18:22 CEST] <ubitux> (maybe it should?) [15:18:34 CEST] <nevcairiel> so either of those headers is useless [15:18:39 CEST] <nevcairiel> and we shouldnt need two [15:20:37 CEST] <ubitux> let's say you have a subtitle text encoder receiving decoded ASS data [15:20:46 CEST] <nevcairiel> ie. when decoding, subtitle_header is even overwritten by avcodec_open2 [15:20:54 CEST] <ubitux> the ASS header currently lies into subtitle_header [15:20:57 CEST] <nevcairiel> and then re-set by the decoder, i assume [15:21:21 CEST] <ubitux> it's using it to interpret the dialogues (from decoded subtitles data) [15:21:25 CEST] <ubitux> and encode it to its own markup [15:21:36 CEST] <ubitux> now it also needs to write an extradata for the muxer [15:21:53 CEST] <nevcairiel> but decoder->encoder communication is not governed by codecpar [15:22:12 CEST] <ubitux> let's ignore codecpar for now [15:22:23 CEST] <ubitux> my question is how do you communicate the ass header to the encoder [15:22:31 CEST] <ubitux> and how it communicates its own header to the muxer [15:23:43 CEST] <nevcairiel> so that makes subtitle_header an output for decoders, and an input to encoders, right? [15:24:12 CEST] <nevcairiel> so those can agree about a header [15:32:27 CEST] <ubitux> yes, iiuc, the subtitle_header is copied from decoder context to encoder context by the user [15:32:52 CEST] <ubitux> then the encoder read it/interpret it, and outputs its own header in the encoder context extradata [15:33:23 CEST] <ubitux> now if you put the decoded ass header in extradata instead of subtitle_header [15:33:29 CEST] <ubitux> where is the encoder going to write its own header? [15:33:37 CEST] <ubitux> read the extradata, free it, and reuse it? [15:34:24 CEST] <nevcairiel> right, for that step you need the subtitle_header as a sort-of raw header [15:35:43 CEST] <ubitux> so you think it would be better for the encoders to replace the extradata buffer instead of reading from subtitle_header and write to extradata? [15:36:00 CEST] <nevcairiel> nah, encoders should output to extradata [15:36:08 CEST] <nevcairiel> just like any other encoder [15:36:19 CEST] <ubitux> yeah, that part doesn't change [15:36:23 CEST] <ubitux> the question is from where it would read [15:38:40 CEST] <ubitux> maybe we could have side data or something [15:39:34 CEST] <ubitux> but if we decide to keep the subtitle_header, then we should offer a way for users to copy it from the decoder context to the encoder context [15:39:55 CEST] <ubitux> and since they only have codecpar as interface for that purpose, it might become the holder [15:40:16 CEST] <nevcairiel> but they dont [15:40:22 CEST] <nevcairiel> decoder->encoder has no codecpar in between [15:40:31 CEST] <nevcairiel> codecpar is only demuxer->decoder and encoder->muxer [15:40:33 CEST] <nevcairiel> not in the middle [15:40:37 CEST] <nevcairiel> there remains codec context [15:41:10 CEST] <nevcairiel> or more specifically, there is no universal api to configure an encoder from a decoder [15:41:18 CEST] <ubitux> ah, right [15:41:21 CEST] <nevcairiel> it expects you to configure the encoder manually [15:41:58 CEST] <ubitux> so i probably got lost somewhere [16:37:38 CEST] <ubitux> errr i need dec_ctx->pkt_timebase = st->time_base; [16:37:47 CEST] <ubitux> in order to decode properly with codecpar :( [16:41:14 CEST] <nevcairiel> that was always required [16:42:31 CEST] <ubitux> nevcairiel: i don't need it when decoding using the stream codec context [16:42:55 CEST] <nevcairiel> well that has been discouraged for years now, even if it wasnt officially deprecated [16:43:06 CEST] <ubitux> http://sprunge.us/UEIJ :( [16:43:24 CEST] <ubitux> i wonder if i need to do something else [16:43:31 CEST] <ubitux> so far it seems to work [16:43:33 CEST] <nevcairiel> maybe you should find out why subtitles need pkt_timebase to absolutely be set and cant deal without it [16:44:05 CEST] <nevcairiel> iirc video doesnt need it at all and audio only for sample skipping [16:44:07 CEST] <ubitux> because the api sucks [16:44:22 CEST] <ubitux> there is no way around it with the current state [16:44:50 CEST] <ubitux> the decoded subtitles don't use the same time base as audio and video [16:45:15 CEST] <ubitux> (they use AV_TIMEBASE, so they need to rescale and thus know the tb of the stream) [16:45:30 CEST] <ubitux> i need to write a new api for subz [16:45:34 CEST] <ubitux> fuck my life [16:46:21 CEST] <ubitux> but that's actually the last step before proper integration of subtitles [16:46:40 CEST] <ubitux> (before they can be pushed savagely into lavfi) [16:53:41 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:6bcb1e1aff2c: lavfi/subtitles: switch to codecpar [16:54:58 CEST] <ubitux> i'm going to try to submit a draft for the new api asap [16:55:39 CEST] <ubitux> nevcairiel: are you going to work on the merge this week end? [16:57:43 CEST] <nevcairiel> i can probably do some later and tomorrow [17:04:40 CEST] <ubitux> oh i can use avcodec_send_packet() and avcodec_receive_frame() for the new api [17:05:04 CEST] <nevcairiel> of course [17:06:09 CEST] <ubitux> that's actually perfect, just need to make a few tricks [17:36:10 CEST] <ubitux> why do we have frame->pts and frame->best_effort_timestamp? [17:36:53 CEST] <ubitux> in the decoding process, we have some code setting best_effort_timestamp to either pkt_pts or pkt_dts (based on reordering logic or whatever) [17:37:05 CEST] <ubitux> but why not set frame->pts so user can just use that value? [17:44:57 CEST] <durandal_1707> can I get comments about ylc? [17:56:56 CEST] <nevcairiel> ubitux: there is a patch from libav in the queue i think to make it set frame->pts instead of pkt_pts [17:57:07 CEST] <nevcairiel> (or in addition to) [17:57:57 CEST] <ubitux> but what's the historic background of not using frame->pts in the first place, and also introducing best_effort_timestamp? [18:13:03 CEST] <cone-423> ffmpeg 03Martin Vignali 07master:1e38791b7f8e: avcodec/exr: fix reading float channel when there is half and float channels in a file [18:17:10 CEST] <durandal_1707> I will apply ylc soon, if I read no comments [18:19:08 CEST] <jamrial> ubitux: shouldn't you call avcodec_free_context(&dec_ctx) after your vf_subtitles changes? [18:19:46 CEST] <jamrial> i don't have libass here so i can't test with valgrind to confim [18:28:59 CEST] <cone-423> ffmpeg 03Martin Vignali 07master:d96b8144c005: avcodec/exr: add missed hunks from previous exr commit [18:53:30 CEST] <cone-423> ffmpeg 03Aman Gupta 07master:ee2a8f142b51: avcodec/omx: fix deprecation warning for ff_alloc_packet [19:03:05 CEST] <BtbN> This will be an interesting release [19:09:09 CEST] <durandal_1707> why? [19:12:15 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:e73ccfd6ad10: lavfi/subtitles: fix memleak after 6bcb1e1a [19:14:34 CEST] <cone-423> ffmpeg 03Clément BSsch 07master:a887fbb582fe: lavfi/subtitles: remove unecessary checks [19:14:48 CEST] <ubitux> jamrial_: you're right; fixed [19:22:03 CEST] <BtbN> durandal_1707, a lot of hwaccel stuff was added, the RPi encoder, CUDA, VAAPI encoders/filters, ffmpeg_vaapi.c [19:44:49 CEST] <durandal_1707> why nobody voted to ban Cehoyos? [19:56:02 CEST] <jamrial_> durandal_1707: the four months part was arbitrary. the amount was not agreed in the meeting [19:56:12 CEST] <jamrial_> it kinda rubbed people the wrong way [19:56:52 CEST] <iive> durandal_1707: because 4 months are excessive and you didn't even try to explain why that ban is necessery [19:56:57 CEST] <jamrial_> then michael enacted that arbitrary one day ban with an things got weird [20:11:49 CEST] <cone-423> ffmpeg 03Michael Niedermayer 07master:4cc896ea5f06: avformat/format: Fix registering a format more than once and related races [20:50:31 CEST] <Compn> durandal_1707 : because no one cares ? [20:50:38 CEST] <Compn> or they dont want to get involved [20:50:44 CEST] <Compn> i think someone said as much in the thread [20:51:19 CEST] <Compn> you got democratic vote anyways, so if you dont like results... [20:52:31 CEST] <Compn> durandal_1707 : but i like you, so i hope you dont rage quit [20:52:44 CEST] <ubitux> meanwhile no one to write release notes [20:52:49 CEST] <Compn> not at all :D [20:53:12 CEST] <ubitux> and we're going to release like an unwanted child [20:53:36 CEST] <Compn> who said we need to write up release note message anyway? [20:53:50 CEST] <Compn> for "yet another release"? [20:54:47 CEST] <ubitux> "hey here are a thousands of cryptic lines of code after months of change, we worked a lot on it, but we were too lazy to spend half an hour making a summary, so figure out yourself" [20:54:59 CEST] <ubitux> "also try to find what will break with your app after the upgrade ;)" [20:55:10 CEST] <ubitux> seriously it's totally antiprofessionnal [20:55:21 CEST] <ubitux> we passed for idiots again last time on HN [20:56:59 CEST] <ubitux> https://news.ycombinator.com/item?id=11103066 [21:03:20 CEST] <jamrial_> ubitux: the changelog for this release seems clear enough about new features at least. but i agree some comments about new api like codecpar are probably needed [21:05:44 CEST] <ubitux> see 65dc7ca4c8e7e56362626a5d31e563e80108f104 btw [21:06:11 CEST] <ubitux> maybe we shouldn't release so often if we are not capable of doing them properly [21:12:34 CEST] <jamrial_> we could cherry pick lines from those notes. unless it's considered bad practice... [21:13:57 CEST] <Compn> ytgg [21:14:00 CEST] <Compn> oops [21:14:08 CEST] <Compn> yeah just copy what phronoix did [21:14:17 CEST] <jamrial_> another option for future releases is to make people submitting new api to also add a few lines describing it to RELEASE_NOTES and not just a line to APIChanges [21:14:37 CEST] <jamrial_> that way at the time of release it's a matter of polishing it a bit and adding an introductory paragraph [21:15:37 CEST] <Compn> how many upvotes did that comment even get ? [21:15:43 CEST] <Compn> "who reads release notes" [21:20:28 CEST] <Compn> 6 comments [21:20:30 CEST] <Compn> way to worry [21:28:02 CEST] <ubitux> Compn: guess how much i got by just taking 5 minutes to write my answer [21:29:37 CEST] <Compn> we could probably just write some crap up instead of arguing :D [21:31:29 CEST] <ubitux> https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/refs/heads/release/2.5:/RELEA… [21:31:35 CEST] <ubitux> https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/refs/heads/release/2.6:/RELEA… [21:31:44 CEST] <ubitux> and since then, full garbage [21:36:26 CEST] <DSM_> our gitweb seems too old :P [21:43:10 CEST] <jamrial_> ubitux: what i said above might work in the future. if anything to not end up with the same situation of having to write full notes from scratch with every release and nobody to do it [21:43:42 CEST] <ubitux> fine with me [21:55:57 CEST] <cone-423> ffmpeg 03Martin Storsjö 07master:a590d344e316: omx: Don't return > 0 from omx_encode_frame [21:59:23 CEST] <Compn> sorry ubitux , i just get weird sometimes :\ [22:00:49 CEST] <Compn> i dont mean to argue. but i'm sorry i did [22:31:12 CEST] <BtbN> ubitux, michaelni, https://github.com/BtbN/FFmpeg/commit/6d734b1aecac04032f170b96833a5d95be857… any comments? Should it be pushed before the release? [22:31:24 CEST] <BtbN> Also, do I need to bump lavc minor because of the new names? [22:39:42 CEST] <nevcairiel> adding the new and future names early seems like a good idea [22:40:41 CEST] <BtbN> hm? [22:40:54 CEST] <BtbN> deprecating the existing ones without adding the new ones seems silly [22:41:37 CEST] <nevcairiel> well of course [22:41:52 CEST] <BtbN> Or do you mean, just adding the new ones for the 3.1 release, and deprecating the old ones after it? [22:42:11 CEST] <nevcairiel> nah if the new ones show up the old ones should be deprecated, otherwise people would never find out [22:42:38 CEST] <BtbN> Ok, so I'll just add the lavc version minor bump because of the new names [22:43:03 CEST] <fritsch> may I ask (for kodi) when do you plan to release 3.1? [22:43:09 CEST] <BtbN> today [22:43:14 CEST] <fritsch> cause, we are currently making planes to go into beta soon [22:43:20 CEST] <fritsch> and may bump prior to that [22:43:54 CEST] <fritsch> okay - will investigate as fast as possible [22:44:04 CEST] <fritsch> what feeling do you have about 3.1? [22:44:15 CEST] <fritsch> rock solid? :-) maintainance release? feature release? bleeding edge? [22:44:28 CEST] <michaelni> rcombs, about the patches ..., when can you push them ? [22:45:08 CEST] <michaelni> also about release notes, can someone please write release notes, several people want release notes [22:46:28 CEST] <michaelni> fritsch, planned today, of course it might slip and be tomorrow [22:46:38 CEST] <fritsch> that's not a problem for us [22:46:49 CEST] <fritsch> michaelni: what's your feeling about 3.1? all good so far? [22:46:57 CEST] <fritsch> that's more important to us [22:47:57 CEST] <michaelni> it seems working fine, there where a bunch of regressions that got fixed, fritsch you might want to ask carl, he tends to know every bug or so [22:48:20 CEST] <fritsch> kodi will roughly have some months left until v17 will hit the streets, it's less than a year though - but I think going with 3.1 is a good idea [22:48:36 CEST] <fritsch> especially considering that we are "stable" in n months first [22:48:54 CEST] <fritsch> okay, will ask carl [22:49:24 CEST] <fritsch> thx much [22:51:35 CEST] <cone-423> ffmpeg 03Rodger Combs 07master:1df401505c6d: lavf/srtdec: fix probing files with negative first timestamps [22:51:36 CEST] <cone-423> ffmpeg 03Rodger Combs 07master:150e5e13b1fa: lavf: deprecate av_apply_bitstream_filters [22:51:37 CEST] <cone-423> ffmpeg 03Rodger Combs 07master:af7e2734b9c1: lavf: update auto-bsf to new BSF API [22:51:50 CEST] <ubitux> BtbN: great! thanks a lot for doing this [22:51:56 CEST] <rcombs> there memleak fixed [22:52:16 CEST] <ubitux> rcombs: thx for srt; you could have fixed the indent though ;) [22:52:23 CEST] <rcombs> oh dammit [22:52:29 CEST] <ubitux> :D [22:52:42 CEST] <ubitux> no worry :) [22:52:50 CEST] <rcombs> I'll fix [22:53:14 CEST] <cone-423> ffmpeg 03Rodger Combs 07master:6ee7adb881e4: lavf/srtdec: fix indent [22:56:38 CEST] <BtbN> ubitux, am I right about this needing a lavc minor bump? It technically adds new encoders? [22:57:43 CEST] <michaelni> BtbN, the lazy rule for minor / micro is, when in doubt bump, it does no real harm if t wasnt needed [22:57:59 CEST] <nevcairiel> rcombs: was that the entire set now? [23:01:13 CEST] <rcombs> nevcairiel: no, just the one people wanted for the release (since it fixes a memleak) [23:01:24 CEST] <rcombs> nevcairiel: the later ones didn't apply cleanly and needed changes [23:02:05 CEST] <rcombs> (resending now) [23:08:35 CEST] <cone-423> ffmpeg 03Timo Rothenpieler 07master:888a5c794778: avcodec/nvenc: Bring encoder names in line with other encoders [23:33:03 CEST] <jamrial_> rcombs: thanks for the bsf fix! [23:36:21 CEST] <jamrial_> BtbN: yeah, new components are minor bump. micro is for small things like new or changed avoptions [23:36:57 CEST] <BtbN> well, it's not realy a new component, but i guess the same rules apply [23:37:27 CEST] <BtbN> Just another "alias" for the same encoders [23:49:29 CEST] <cone-423> ffmpeg 03Jan Sebechlebsky 07master:d46a8e30dcac: avformat/tee: Support arbitrary number of slaves [00:00:00 CEST] --- Sun Jun 26 2016

1 0

ffmpeg.log.20160625
by burek 26 Jun '16

26 Jun '16

[01:26:21 CEST] <tommo> can ffmpeg downsample an ac3 file from 384kbps to 192kbps? [01:27:24 CEST] <BtbN> you mean re-encode at a lower bitrate/quality. downsampling is something diffrent. [01:27:35 CEST] <tommo> yes btbn [01:28:04 CEST] <tommo> a show here was broadcast over two channels the first part was in 384kbs the second 192 i want them to match [01:28:11 CEST] <BtbN> I think ffmpeg has a native ac3 encoder, but I'm not sure. If not, there is definitely support for an external one. [02:01:47 CEST] <DHE> I believe there is an internal AAC encoder [02:02:26 CEST] <DHE> a lot of OTA channels offer two audio streams [02:04:01 CEST] <tommo> well i capped one channel from satellite and the other from cable so i didnt loose anything in the crossover [02:04:15 CEST] <tommo> but cable always used 384kbps [02:20:18 CEST] <blue_misfit> yeah the internal AC3 encoder is okay [02:20:27 CEST] <blue_misfit> E-AC3 not so much [02:20:43 CEST] <blue_misfit> it works but the native Dolby encoder is much better quality and will set dialnorm metadata correctly etc [03:15:41 CEST] <snakeryslug> can ffplay play silent black video for X seconds programmatically? [03:18:21 CEST] <furq> snakeryslug: ffplay -f lavfi -i color=c=black:duration=10 [03:41:14 CEST] <snakeryslug> cool. now i've gotta figure out how to add something to the queue. [10:29:15 CEST] <_MyStartx_> Hi guys [10:29:29 CEST] <tommo> morning [10:30:47 CEST] <_MyStartx_> Is possible than ffmpeg use gpu instead cpu? :) [10:34:39 CEST] <tommo> yeah [10:34:40 CEST] <tommo> https://trac.ffmpeg.org/wiki/HWAccelIntro [10:34:57 CEST] <tommo> you can use use gpu to decode frames and cpu to encode frames [11:22:36 CEST] <viric> _MyStartx_: you can also use the gpu to encode, but it is not of very good quality [14:27:16 CEST] <spirou> are there a changelog for ffmpeg somewhere? [14:27:42 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=Changelog;h=aabdf9050a754725… [14:27:56 CEST] <JEEB> that's for features [14:28:08 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/APIchanges;h=9ca71b7f8b9… [14:28:11 CEST] <JEEB> API changes [14:30:14 CEST] <spirou> thanks [15:01:24 CEST] <DHE> hmm... I put a feature patch on the mailing list, but it's not listed in that changelog [15:01:41 CEST] <JEEB> was it merged? [15:01:54 CEST] <JEEB> basically usually the person doing the patch is supposed to add it to the changelog [15:07:06 CEST] <DHE> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=e06114fed3afa69187b3dfc09a… yes it was [15:08:55 CEST] <JEEB> yeah, you forgot to add a changelog entry :) [15:09:05 CEST] <JEEB> I guess you can just send a patch that adds that [15:11:08 CEST] <DHE> seems there's already been a release or two since then... [15:12:22 CEST] <JEEB> :D [15:16:04 CEST] <DHE> well damn... [15:16:15 CEST] <hero_biz> hi guys [15:16:26 CEST] <hero_biz> I have a small question [15:17:09 CEST] <hero_biz> I wonder how I need to configure ffpmeg building process to use x265 multilib feature. [15:17:18 CEST] <hero_biz> does it use it by default? [15:17:44 CEST] <JEEB> if it provides a single library to link against then it should work out of the box as long as you link against it [15:18:09 CEST] <JEEB> if it has to be implemented by the user, then much less likely [15:18:13 CEST] <DHE> ffmpeg uses x265_api_get() so if that works with multilib then it should be okay [15:20:05 CEST] <hero_biz> x265 have a multilib.sh that makes 1 lib containing all sub-libs. [15:20:25 CEST] <hero_biz> just need to change it a little. [15:20:27 CEST] <JEEB> we don't care [15:20:33 CEST] <hero_biz> ok,ty info :) [15:23:01 CEST] <Mooniac> I have corrupted MP4 files as the battery died before writing the moov entry at the end of the file. Can I use ffmpeg, or something else, to repair the broken files? [15:26:14 CEST] <JEEB> you'd need heuristics based on the files created by the same thing, and there's some more or less shady software (including at least one OSS thing) that tries to do that [15:26:33 CEST] <JEEB> ffmpeg itself doesn't try to apply any logic like that where you'd input two files (one working and one without the index) [15:26:33 CEST] <furq> Mooniac: https://github.com/ponchio/untrunc [15:26:40 CEST] <Mooniac> I have plenty of good sample files. [15:26:45 CEST] <JEEB> yeah, that's the less shady one [15:26:50 CEST] <JEEB> although it has lulzy comments in the code [15:26:51 CEST] <Mooniac> Yes, I've found untruc. But it's for ubuntu. I use Fedora. [15:27:16 CEST] <Mooniac> I now need to find the package names that correspond to that in Fedora. uh. [15:28:26 CEST] <JEEB> just build it :P [15:28:35 CEST] <JEEB> probably doesn't have too many deps if it NIH'd everything [15:28:58 CEST] <Mooniac> I tried the compilation, it's complaining about packages [15:30:01 CEST] <furq> https://github.com/ponchio/untrunc/blob/master/Makefile [15:30:02 CEST] <furq> wtf [15:30:19 CEST] <furq> https://github.com/ponchio/untrunc/blob/master/Makefile#L13 [15:30:23 CEST] <furq> is this even the right makefile [15:32:42 CEST] <furq> i guess all of that is qmake boilerplate bullshit but then it's using hardcoded paths to libavformat.a [15:32:49 CEST] <JEEB> lol [15:33:15 CEST] <furq> where would we be without all these great build systems to make our lives easier [15:33:39 CEST] <Mooniac> hmmm ... so any way to make this work on Fedora? Or some alternative? [15:34:26 CEST] <JEEB> you'll have to poke the build system to be less "this works on my system" [15:34:32 CEST] <JEEB> or poke the author [15:34:41 CEST] <JEEB> oh [15:34:42 CEST] <JEEB> lol [15:34:49 CEST] <JEEB> their example doesn't even use the damn makefile [15:35:02 CEST] <JEEB> `g++ -o untrunc file.cpp main.cpp track.cpp atom.cpp mp4.cpp -L/usr/local/lib -lavformat -lavcodec -lavutil` [15:35:18 CEST] <Mooniac> yes, I tried that line, and that adidn't work [15:35:22 CEST] <JEEB> yeah... why use build systems if you can just call g++ manually [15:35:30 CEST] <JEEB> Mooniac: what error(s) did you get? [15:35:44 CEST] <JEEB> pastebin if much [15:35:54 CEST] <Mooniac> 5 lines. too much? [15:36:07 CEST] <JEEB> rather pastebin [15:36:10 CEST] <JEEB> and link here [15:36:25 CEST] <Mooniac> https://paste.fedoraproject.org/384583/ [15:36:33 CEST] <JEEB> oh right [15:36:38 CEST] <JEEB> fedora doesn't package FFmpeg or Libav [15:36:42 CEST] <Mooniac> but as I said, I don't have these devel packages [15:36:59 CEST] <Mooniac> right, I don't have libav, and not their devel [15:37:30 CEST] <JEEB> wonder what FFmpeg/Libav versions their usage expects [15:37:37 CEST] <JEEB> in general the gist is [17:32:27 CEST] <utack> Hi. does this blend 4 frames into one, or is the syntax total crap? thanks https://paste.ubuntu.com/17860535/ [17:33:33 CEST] <furq> utack: you can't call -vf or -r twice, it'll just ignore the first ones [17:33:59 CEST] <utack> any ideas how i could use tblend for something like 4 frames then? [17:34:01 CEST] <furq> at a guess you want -vf tblend=all_mode=average,tblend=all_mode=average -r 24000/4004 [17:34:15 CEST] <utack> ok thanks, i will try that [17:35:12 CEST] <utack> but wouldn't that just blend the same two frames, twice? [17:36:14 CEST] <furq> at a guess it'll actually blend three frames into one [17:36:24 CEST] <furq> i can't say i've ever used tblend though [17:36:41 CEST] <utack> i'll give it a try [19:48:22 CEST] <tombert> hello, I have a dumb question: is there a way to have some kind of output stream and feed that to FFMpeg to transcode [19:48:55 CEST] <BtbN> ffmpeg can read from stdin, if that's what you're asking? [19:49:04 CEST] <tombert> yeah [19:49:11 CEST] <tombert> so I want something like getstream [19:49:19 CEST] <tombert> getStream "blah" | ffmpeg -i input -c:v libx264 -preset slow -crf 22 -c:a copy output.mkv [19:49:35 CEST] <tombert> where I want input to be stdin [19:49:49 CEST] <furq> ffmpeg -i pipe:0 [19:49:57 CEST] <DHE> or just "ffmpeg -i -" [19:49:57 CEST] <BtbN> Or - , or /dev/stdin [19:50:17 CEST] <tombert> I didn't know that stdin was a file...lol. [19:50:58 CEST] <DHE> under unix, lots of things are files. your terminal, TCP and UDP sockets, epoll devices, directories.. [19:51:16 CEST] <tombert> I knew about all of those, I should have assumed stdin as well [19:52:05 CEST] <DHE> when you run an application with 'appname < somefile' all it does is replace stdin with the open file instead of the regular terminal [20:45:50 CEST] <hero_biz> guys,a question [20:46:06 CEST] <hero_biz> i'm trying to build ffmpeg with tessarect support. [20:46:26 CEST] <hero_biz> i have installed it from repository, but I get this error: [20:46:29 CEST] <hero_biz> "ERROR: tesseract not found using pkg-config" [20:46:33 CEST] <hero_biz> any idea why? [21:18:43 CEST] <DHE> and he's gone [22:01:17 CEST] <Bray90820_> Prob a dumb question but is ffmpeg installed by default on ubuntu [22:29:52 CEST] <kepstin> Bray90820: depending on the ubuntu version, some libraries from ffmpeg or libav may be installed by default, but the command line tool won't be. [22:30:11 CEST] <Bray90820> Yea I figured that out [22:47:41 CEST] <Bray90820> What do these errors mean? [22:47:41 CEST] <Bray90820> http://pastebin.com/raw/uBzaC8VH [00:00:00 CEST] --- Sun Jun 26 2016

1 0