August 2019 - Ffmpeg-devel-irc

ffmpeg-devel.log.20190719
by burek 31 Aug '19

31 Aug '19

[01:45:25 CEST] <rcombs> Dmitri_Ovch: hmm, have you tried using the OpenCL integration? it looks like that has better support for passing in GPU-side buffers [01:45:43 CEST] <rcombs> i.e. AV_PIX_FMT_OPENCL [01:46:31 CEST] <rcombs> also, in either case, how does device selection work? [01:47:08 CEST] <rcombs> looks like it's just letting the library pick a default? (which is probably fine for most cases I suppose) [01:48:37 CEST] <rcombs> or, hmm, there is a CreateSurfaceFromVulkanNative function, but there's no AV_PIX_FMT_VULKAN yet [08:27:50 CEST] <cehoyos> Good morning [08:28:04 CEST] <cehoyos> Who else had a lovely chat with a lady from Berlin - in English? [08:53:24 CEST] <akravchenko188> rcombs: AV_PIX_FMT_OPENCL is planned to support soon. since we submit this change. hopefully this will not take a lots of time [08:54:58 CEST] <akravchenko188> rcombs: device selection in case of incoming host buffers is also planned in different commit [08:55:21 CEST] <rcombs> fair enough, looking forward to seeing those [08:57:02 CEST] <akravchenko188> since FFmpeg does not have hwcontext_vulkan, vulkan is used internaly in amf uploading from Host to Vulkan surface [08:58:12 CEST] <akravchenko188> when hwcontext_vulkan is implemented, we could implement full hw pipeline with AV_PIX_FMT_VULKAN [08:58:36 CEST] <akravchenko188> probably there should be interop between opencl and vulkan, didnt investigated yet [09:18:29 CEST] <thilo> cehoyos: uuuh, Berlin is yet another location on the list [10:22:35 CEST] <cone-170> ffmpeg 03Michael Niedermayer 07master:00ed04d61496: avformat/ifv: Check for EOF in read_index() [10:22:35 CEST] <cone-170> ffmpeg 03Shiyou Yin 07master:153c60752558: avutil/mips: refactor msa load and store macros. [12:04:22 CEST] <jdarnley> I see Big Brother shills are out in force in order to dissuade people from using PGP [12:04:47 CEST] <jdarnley> They have reminded my that my key expires next year. [12:09:10 CEST] <rburton> getting qdm2_tablegen.c:(.text+0x36a): undefined reference to `avpriv_request_sample' when building 4.1.4 , 4.1.3 worked. any ideas? [12:27:22 CEST] <mkver> Do you use hardcoded tables? [12:32:16 CEST] <mkver> c8232e50074f6f9f9b0674d0a5433f49d73a4e50 should probably be backported. [13:29:43 CEST] <rburton> yes, we do! [13:29:52 CEST] <rburton> i'm just drive-by upgrading, what does that mean? :) [13:30:04 CEST] <rburton> ah, mkver left [14:45:49 CEST] <Lynne> rburton: why are you using hardcoded tables? [15:18:19 CEST] <jdarnley> I wonder how much work it is to replace the "parser" used in expressions with an actual parser, Lua maybe. [15:54:03 CEST] <whitestone> hello, i am ffmpeg user, i want to know something about the HLS demuxer, i know this is not the channel, but i am searching this info in google and i dont find a lot and in the users channel it looks like no one knows a lot about this demuxer [17:33:31 CEST] <rburton> Lynne: reading up, dunno. i can turn that off :) [17:42:45 CEST] <Lynne> yeah, you should, its not really used anywhere anymore but the mp3 decoder and a few others to generate a few hundred odd floats [18:23:25 CEST] <JEEB> wbs: since you're the fragmented movenc person - adjusting all packet timestamps to the end of previous fragment or generating an empty sample at the beginning of a fragment to keep the fragment pts continuous? [18:25:58 CEST] <wbs> JEEB: we do (at least my original code in libav) adjust the first timestamp of a fragment to the guessed end of the previpus [18:27:43 CEST] <wbs> JEEB: if you know better than what the code guesses, set pkt_duration of the last packet in the prev fragment [18:34:50 CEST] <wbs> JEEB: although I guess the proper meaning of pkt_duration is from this pts to the next after reordering, but movenc iirc treats it as duration until the next dts [18:38:40 CEST] <JEEB> wbs: yea, frag_start is ok [18:40:17 CEST] <JEEB> i just am trying ro think of the least bad way of doing the crap that says one sample per fragment, and i think the spec says that the single sample starts at the fragment start [18:40:54 CEST] <JEEB> so do I either start wryyy'ing the packet timestamps, or do I add an empty sample in the beginning [18:41:40 CEST] <JEEB> so that the second sample is then the starting packet [18:42:13 CEST] <JEEB> of ourse that means I hope the place i am pushing this crap properly parses multipöe samples in a single fragment [18:42:56 CEST] <JEEB> since the sample then contains subtitles timed after the start of sample [18:44:47 CEST] <wbs> JEEB: ah, subs... the current code isn't written with that in mind no [19:02:12 CEST] <JEEB> wbs: funny enough I think mov_text might more or less be working because it adds extra samples at the end of the segment I think? [19:02:29 CEST] <JEEB> although not sure how that works when you don't know the required time until the next fragment [19:02:50 CEST] <JEEB> I did quickly test and mov_text results seemed kind of sane [19:03:28 CEST] <JEEB> wbs: also I wonder if it's simpler to just limit every sample into its own fragment instead of trying to buffer them until fragment flush [19:03:51 CEST] <JEEB> which would mean a fragment per subtitle sample, but at that point we're anyways getting enough overhead :P [22:51:34 CEST] <cone-407> ffmpeg 03Michael Niedermayer 07master:ed4c6ce750cf: tools/target_dem_fuzzer: ignore avformat_find_stream_info() failure [22:51:34 CEST] <cone-407> ffmpeg 03Michael Niedermayer 07master:c5f265bb2468: avcodec/atrac9dec: Check conditions before apply_band_extension() to avoid out of array read in initialization of unused variables [22:51:34 CEST] <cone-407> ffmpeg 03Michael Niedermayer 07master:b789ebf681ea: avcodec/h264_cavlc: Fix integer overflows with motion vector residual addition [22:51:34 CEST] <cone-407> ffmpeg 03Michael Niedermayer 07master:7d3581e6bbec: avcodec/h264_refs: Also check reference in ff_h264_build_ref_list() [22:51:34 CEST] <cone-407> ffmpeg 03Michael Niedermayer 07master:6ebbfb377f7b: avcodec/agm: Fix overflow of signed shift [22:51:34 CEST] <cone-407> ffmpeg 03Michael Niedermayer 07master:5c46fdf305ca: avformat/utils: Check rfps_duration_sum for overflow [22:51:35 CEST] <cone-407> ffmpeg 03Michael Niedermayer 07master:76af425159cf: avcodec/flashsv: add FF_CODEC_CAP_INIT_CLEANUP to flashsv1 [22:51:35 CEST] <cone-407> ffmpeg 03Michael Niedermayer 07master:1123331f59d3: avcodec/flashsv: add FF_CODEC_CAP_INIT_CLEANUP to flashsv2 [00:00:00 CEST] --- Sat Jul 20 2019

1 0

ffmpeg-devel.log.20190830
by burek 31 Aug '19

31 Aug '19

[00:43:40 CEST] <kierank> tl [00:59:12 CEST] <BtbN> Oh, new Video decode SDK [00:59:22 CEST] <BtbN> "Added support for CUStream in NVENCODE API to facilitate parallel execution of pre-/post-processing of video on CUDA and encoder tasks." that sounds useful [01:00:19 CEST] <BtbN> rcombs, btw. nvenc does nowhere claim to support anything but "x64 and ppc64le" [01:01:28 CEST] <BtbN> hm, SDK is nowhere to be found yet [02:33:06 CEST] <rcombs> BtbN: "stream-based API" frightens me though [02:40:19 CEST] <philipl> rcombs: It's not that scary. For us it mostly means explicitly propagating streams through the hwcontexts, decoder, encoder, filters. [02:40:49 CEST] <philipl> We just use the default stream; stream management is a client's responsibility. [02:51:20 CEST] <rcombs> philipl: I've seen people try to cram stream-based APIs (that don't expose frames to the user) in ffmpeg and it's always ended in horrible horrible hacks [03:18:38 CEST] <philipl> rcombs: this isn't that. Streams are acuda synchronisation mechanism [03:18:49 CEST] <rcombs> ah, alrighty then [03:23:05 CEST] <cone-786> ffmpeg 03Jun Zhao 07master:7ce15b1d4394: avutil/file: always set *size to zero if *bufptr is NULL [03:23:05 CEST] <cone-786> ffmpeg 03Jun Zhao 07master:95780f4dcbf8: avutil/file: add more check befor destory the buffer [08:23:30 CEST] <thardin> michaelni_: I've been poking at a thorough check for cinepak validness. validating all length fields, requiring that strips cover the entire frame, checking that each strip is at least as required for their specified mode [08:23:59 CEST] <thardin> at least as large* [08:33:18 CEST] <thardin> proper recognition is a good way to reduce computing power greed [09:15:12 CEST] <michaelni_> thardin, yes, if it doesnt break any files out in the wild, more throughout checking is "always" good [09:30:40 CEST] <thardin> it's impossible to know if it breaks any files in the wild [09:31:02 CEST] <thardin> but it can be made as strict as the win3.1 decoder [09:32:06 CEST] <thardin> any broken files need to be in FATE so refactoring can be done with confidence [09:43:19 CEST] Action: JEEB likes how track_duration in movenc gets updated for a track without any entries in a fragment before seemingly write_packet gets called, and thus various timestamp validation checks fail because they think I'm trying to go backwards in time \o/ [09:45:02 CEST] <JEEB> because it unconditionally checks the next packet and updates in mov_flush_fragment :) [09:59:23 CEST] <JEEB> ok, but skipping that leads to fragment timestamps not being written right, so I will just adjust the sanity check in check_pkt [10:03:23 CEST] <JEEB> that seems to have done it \o/ [10:07:09 CEST] <thardin> noice [10:13:36 CEST] <JEEB> so basically for each flushed fragment the track_duration gets updated to the next upcoming packet in the lavf context's buffer. then when you come to write your next packet check_pkt will not let you write a packet starting before that. except in my case I have to squash packets with the contents of the packet containing timestapms. so if the DTS/PTS of the packet gets adjusted to the start of the [10:13:42 CEST] <JEEB> fragment at the end, that of course skews it completely xD so I start it at the previous fragment's end if such is available. and that was catching up in fire now :) [10:14:47 CEST] <JEEB> but basically using the previous fragment's end as the minimum dts in the case of such track (I have a flag for it already) made it pass and everything went OK [10:15:30 CEST] Action: JEEB checks that this stuff works for non-fragmented too although the frag_start variable seems to get updated with each packet write [10:22:47 CEST] <JEEB> seems to work :) [11:20:49 CEST] <J_Darnley> Have any other samplie test programs or examples been converted to refcounted packets and frames recently? [11:20:57 CEST] <J_Darnley> *simple [11:45:13 CEST] <cone-279> ffmpeg 03Eugene Lyapustin 07master:20a12448aaf1: avfilter/vf_v360: add facebook's format [12:54:08 CEST] <JEEB> ugh... now I'm rnadomly getting CTS offsets most likely due to somehow end_pts not matching start_dts + duration [13:35:53 CEST] <JEEB> I /think/ I found it [13:35:55 CEST] <JEEB> > trk->cluster[trk->entry].dts = trk->start_dts + trk->track_duration; [13:36:10 CEST] <JEEB> track_duration was already picked up from an *upcoming* packet instead of an already written one [13:36:55 CEST] <JEEB> and then pkt->pts gets adjusted for that [16:03:10 CEST] <Lynne_> jkqxz: can you post a vulkaninfo dump from an amd with new-ish drivers? [16:03:26 CEST] <Lynne_> I'm still not sure one image per plane is the best idea [16:04:01 CEST] <Lynne_> mainly because the decode API that's coming up will 100% decode to such images... that you allocate and give it [16:04:36 CEST] <Lynne_> having 2 different incompatible types of vulkan frames is not good [16:08:56 CEST] <Lynne_> since you allocate the images to decode into, you'd obviously want to use optimal tiling, and you can't split apart optimally tiled non-disjoint multiplane images [16:09:17 CEST] <jamrial> durandal_1707: that wcmv sample doesn't have duplicate frames, so not really useful in the end [16:10:25 CEST] <durandal_1707> ah will send another one [16:47:21 CEST] <cone-216> ffmpeg 03Guo, Yejun 07master:09a455a24649: dnn: introduce dnn operand (in c code) to hold operand infos within network [16:47:22 CEST] <cone-216> ffmpeg 03Guo, Yejun 07master:2d5e39c13e50: dnn: change .model file format to put layer number at the end of file [16:47:23 CEST] <cone-216> ffmpeg 03Guo, Yejun 07master:83e0b71f66f2: dnn: export operand info in python script and load in c code [18:48:26 CEST] <kierank> durandal_1707: do you know how ER code works [18:48:34 CEST] <kierank> why i get er errors when output is bitexact [18:54:12 CEST] <durandal_1707> dunno, im not author of that code [19:03:23 CEST] <kierank> durandal_1707: i made twit [19:32:11 CEST] <durandal_1707> kierank: great, write more, but only I read your twits :p [19:41:02 CEST] <kepstin> there we go. two years late, but i finally got around to posting the trivial fixes to my patch so the concat filter doesn't break if videos have different framerates :/ [20:41:55 CEST] <kierank> J_Darnley: ok so the race condition is here [20:42:00 CEST] <kierank> avctx->execute(avctx, decode_slice, h->slice_ctx, [20:42:01 CEST] <kierank> NULL, context_count, sizeof(h->slice_ctx[0])); [20:42:08 CEST] <kierank> if I make that serial the errors go away [20:42:50 CEST] <kierank> could still be a testcase problem [20:42:51 CEST] <kierank> not sure [20:43:43 CEST] <kierank> let's see what happens if I put a lock in the testcase [20:52:03 CEST] <kierank> what is "job_size" in avctx->execute [21:06:40 CEST] <jamrial> durandal_1707: did you find a sample? [21:08:17 CEST] <durandal_1707> jamrial: see ml [21:08:43 CEST] <jamrial> huh, missed it somehow [21:08:45 CEST] <jamrial> thanks [21:09:04 CEST] <durandal_1707> can encode with wine and virtualdub2 [21:09:14 CEST] <durandal_1707> just need to install codec [21:10:39 CEST] <jamrial> i'm not going to install weird binary codecs, so thanks for generating the sample :p [21:11:07 CEST] <kierank> we could have a windows vm for devs [21:11:38 CEST] <JEEB> thankfully windows 10 works without activation for some time [21:12:04 CEST] <jamrial> durandal_1707: so zero sized packets when it's meant to duplicate frames? [21:12:06 CEST] <JEEB> although a shared one might lower the entry barrier. that said it would have to be reset for each user etc [21:17:16 CEST] <durandal_1707> jamrial: yes [21:17:41 CEST] <durandal_1707> wine is fine, suffer now [21:19:54 CEST] <jamrial> durandal_1707: the decoder never sees them, it seems. even if i revert 976dae8b32 [21:20:03 CEST] <jamrial> they are evidently dropped earlier in the process [21:20:30 CEST] <jamrial> so for this sample, that commit didn't change anything [21:21:00 CEST] <durandal_1707> argh, that kind of sucks [21:33:02 CEST] <cone-593> ffmpeg 03Michael Niedermayer 07master:9b57b90c4c27: avcodec/vaapi_encode: Simplify code with av_clip_int8() [22:05:36 CEST] <tmm1> jkqxz: what do you think of something like this to be able to use -init_hw_device for dummy drm when /dev/dri does not exist (i.e. rpi3 when trying to use v4l2 dec/enc): https://github.com/Kwiboo/FFmpeg/commit/0c4c87e72463da1a4bf45032e4db3c2c86d… [22:33:47 CEST] <kierank> michaelni_: where does this calculation come from? [22:33:48 CEST] <kierank> https://github.com/FFmpeg/FFmpeg/blob/8788dd67b851ec652bdd83bb5d5afb12101b7… [22:34:00 CEST] <kierank> it seems broken with chunks+sliced_threads+draw_horiz_band [22:34:21 CEST] <kierank> and deblock_mode=2 [22:34:54 CEST] <kierank> you can have slice 1 be decoded before slice 0 but this code tells the reader to read from slice 0 [22:45:36 CEST] <cone-593> ffmpeg 03Paul B Mahol 07master:62459d6584ad: avfilter/vf_stereo3d: improve dubois anaglyphs [22:59:43 CEST] <michaelni_> kierank, yes looks broken and seems to come from the initial code adding multithreading [22:59:59 CEST] <kierank> michaelni_: the 4 I guess is from the 4 pixel deblock offset but I don't know where the +16 comes from [23:57:25 CEST] <cone-593> ffmpeg 03Michael Niedermayer 07master:07b948fe6078: avcodec/vorbisdec: Check get_vlc2() failure [00:00:00 CEST] --- Sat Aug 31 2019

1 0

ffmpeg.log.20190830
by burek 31 Aug '19

31 Aug '19

[00:01:27 CEST] <kepstin> do you know if the decoder has any h264 profile or level limits? [00:02:35 CEST] <TheDrode> the Colable 5011 you mean? kepstin? [00:03:00 CEST] <kepstin> that command will be generating (probably) high profile video with arbitrarily high level, and since you're using crf mode without any vbv controls it'll have large dynamic range in frame sizes too, possibly causing issues with network buffering. [00:04:03 CEST] <TheDrode> That would cause those colors and shapes that appear and dissapear? [00:04:15 CEST] <kepstin> oh, that's a dvb encoder/modulator? you're gonna need to do a bunch more work to get a stream correctly encoded for broadcast. [00:04:54 CEST] <kepstin> huh, looks like it does transcoding on the device tho [00:05:00 CEST] <kepstin> so i guess not actually [00:05:15 CEST] <TheDrode> kepstin: yeah, it's really f'ing complicated, spent one week getting it to display video from ffmpeg, really picky thingie [00:05:25 CEST] <furycd001> HI.. Running ffmpeg version 3.4.6, is there any way I can glitch a .jpg images using ffmpeg ?? [00:06:10 CEST] <TheDrode> Yeah, she has ffmpeg inside i think, at least some h264 encoder for dvb and multicast IP broadcast [00:07:13 CEST] <kepstin> furycd001: you should get a newer ffmpeg, but https://www.ffmpeg.org/ffmpeg-bitstream-filters.html#noise might be interesting to you. That said, you should probably use some standalone tools rather than ffmpeg to get more control over what's being done to the file. [00:07:55 CEST] <kepstin> ffmpeg, of course, tries its best to avoid glitches in normal usage :) [00:09:44 CEST] <furycd001> ffmpeg was recommended to by a friend. Wasn't sure why they recommended it.... [00:10:17 CEST] <furycd001> It's my first time trying to glitch an image so I don't really know what to use.... [00:10:23 CEST] <kepstin> after you glitch a jpeg file, you can try using ffmpeg to decode it if you like, might give different results from other decoders [00:10:45 CEST] <kepstin> but glitching a file is just modifying bytes of the file before decoding it, in hopes that the decoder will do something interesting looking [00:11:15 CEST] <furycd001> Hmmm yea I could do that. Oh didn't actually know that. Thanks for the info :) [00:11:43 CEST] <kepstin> furycd001: anyways, my suggestions would be to reduce the burstiness of packets by e.g. using the zerolatency tune, consider switching from crf mode to bitrate with vbv controls. [00:12:15 CEST] <furycd001> Ok thanks. I will give that a try.... [00:12:22 CEST] <kepstin> by default x264 will buffer a lot of frames, then output them at a rate unrelated to the input speed, which might mess up stuff expecting a realtime stream [00:14:37 CEST] <furycd001> That makes sense. [00:16:20 CEST] <kepstin> er, wait, i got mixed up - TheDrode the comments about burstiness of packets were for you :) [00:16:57 CEST] <TheDrode> kepstin: yeah, tough so :P [00:17:18 CEST] <TheDrode> kepstin: so, what codec should i use? What can be the approach? i feel clueless [00:18:36 CEST] <TheDrode> kepstin: will try both things, thanks so much, and thanks to everyone. [00:18:42 CEST] <kepstin> TheDrode: oh, hmm, i'm not actually sure which codec you're using right now. i assumed libx264 encoder, but it depends on what the format default is (and I haven't had time to look through your full output) [00:18:55 CEST] <kepstin> libx264 is what you *want* to be using. [00:19:13 CEST] <TheDrode> kepstin: i am using libx264, will look into zerylatency and vbv [00:19:46 CEST] <kepstin> the simplest thing first would be to add -tune zerolatency and see if that fixes it. If you have good network bandwidth (i assume either a direct or switched gigabit link?) then crf mode is probably fine [00:21:16 CEST] <TheDrode> kepstin: yeah, direct GB Link between the server and the encoder [00:21:24 CEST] <TheDrode> 62Gib of RAM [00:21:41 CEST] <TheDrode> and 12 core Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz [00:22:25 CEST] <kepstin> (note that zerolatency mode disables frame threading, so your big fancy multi-core system won't be put to work as much) [00:22:44 CEST] <kepstin> if that fixes the issue, there might be intermediate things you can do rather than the big "zerolatency" hammer [00:25:06 CEST] <kepstin> if you end up having to stick with the low-latency mode and are doing HD video, you can enable slices to get slice threading. [00:26:48 CEST] <TheDrode> kepstin: it got way better but is not yet solved: https://anonymousfiles.io/F4bXvnKz/ [00:26:59 CEST] <TheDrode> daniel@encoder:~$ ffmpeg -report -re -i "http://localhost:5080/LiveApp/streams/132242199223583235253206.m3u8" -vcodec libx264 -preset veryfast -tune zerolatency -acodec mp2 -ac 2 -f rtp_mpegts rtp://10.10.13.3:1001 [00:27:03 CEST] <TheDrode> this the command i used [00:27:28 CEST] Action: kepstin is off for a bit [00:41:38 CEST] <TheDrode> This one did the trick: [00:41:41 CEST] <TheDrode> ffmpeg -report -re -i "http://192.168.201.3:5080/LiveApp/streams/132242199223583235253206.m3u8" -vcodec libx264 -vb 500k -preset veryfast -tune zerolatency -acodec mp2 -ac 2 -f rtp_mpegts -fec prompeg=l=8:d=4 rtp://10.10.13.3:1001?tcp [00:41:41 CEST] <TheDrode> not sure why to lol [00:44:19 CEST] <TheDrode> Just one last question, what is the best way to use... 40 concurrent instances of ffmpeg? [00:50:56 CEST] <TheDrode> Used & at the end simply and its holding, i will hang onto the channel so i can help other people, thanks sir @kepstin [01:20:23 CEST] <TheDrode> Is there any way to lower cpu consumption? [01:20:48 CEST] <BtbN> depends [01:21:08 CEST] <BtbN> You can reduce the amount of threads [01:21:29 CEST] <BtbN> But if you're transcoding a file, it will pretty much always fully utilize all threads it is allowed to. [01:21:54 CEST] <TheDrode> i am restreaming an hls source, if i limit the threads, wouldn't it run sloooow? [01:22:10 CEST] <nicolas17> oh so you're dealing with live stuff [01:22:10 CEST] <BtbN> Real Time stuff is different [01:22:29 CEST] <BtbN> pick a faster preset if you're using x264 [01:22:35 CEST] <BtbN> the default of medium is quite CPU intensive [01:23:13 CEST] <nicolas17> amazingly my CPU manages almost realtime for x265 720p -preset slow [01:23:23 CEST] <BtbN> 720p is small [01:23:30 CEST] <BtbN> Also, if you're restreaming as in not even need to transcode, just use -c copy? [01:24:44 CEST] <nicolas17> -preset slower is already slower than my patience can deal with... so I dunno why I ever considered trying av1 :P [01:25:15 CEST] <BtbN> Isn't even the fastest preset of av1 still less than 1fps for 1080p? [01:25:40 CEST] <TheDrode> BtbN: i need to transcode because the darn machine likes h264, mpegts, mp2 sound [01:25:43 CEST] <nicolas17> I *think* I was getting 8spf on 720p? [01:25:50 CEST] <nicolas17> TheDrode: what's your input? [01:25:50 CEST] <BtbN> mp2 sound? What? [01:26:10 CEST] <BtbN> And what source HLS won't be h264 already? [01:27:50 CEST] <nicolas17> out of curiosity, is there any difference between MPEG1 and MPEG2 audio? [01:27:50 CEST] <TheDrode> BtbN: nicolas17 is a Colable5011 hell machine [01:28:19 CEST] <TheDrode> BtbN: the thing wont take hls from my source, so i have *have* to convert to hls... So annoying [01:28:34 CEST] <BtbN> But the source is not h264 already? [01:29:17 CEST] <nicolas17> you can remux from <weird Colable thing> to HLS while passing-through the h264 video stream in it [01:37:47 CEST] <furq> it's hls to rtp, but yeah [01:38:09 CEST] <furq> you should nominally be able to copy the h264 stream and transcode the audio [01:38:38 CEST] <furq> but all bets are off when it comes to rando hardware [01:39:02 CEST] <furq> plus you have a whole other world of pain because it's a broadcast box that takes mpegts ingest [01:41:22 CEST] <TheDrode> furq: exactly, it's taken 2 weeks from me that i won't get back [01:41:23 CEST] <TheDrode> lol [01:46:47 CEST] <cehoyos> nicolas17: The MPEG2 standard also contains aac, the MPEG1 standard only mp1, mp2 and mp3 [01:47:51 CEST] <furq> nicolas17: https://en.wikipedia.org/wiki/MPEG-2_Part_3 [02:05:35 CEST] <ullbeking> has anybody here used ffmpeg technology to construct a media server that is capable of playing to a display over the LAN, possibly with on-the-fly transcoding? [02:28:39 CEST] <DHE> like UMS? [02:28:54 CEST] <DHE> it uses ffmpeg as a workhorse if the device connecting doens't support the contained codec [02:30:32 CEST] <kepstin> pretty much any tool that accepts arbitrary videos and converts them probably has ffmpeg in it, whether they say so or not :/ [02:37:28 CEST] <ullbeking> kepstin: i'm sure that is the case, and indeed i expected some sort of answer like that... [02:37:32 CEST] <ullbeking> but the issue is... [02:37:53 CEST] <ullbeking> is it possible to have an interface that maches? [02:37:56 CEST] <ullbeking> that is... [02:38:21 CEST] <ullbeking> something that doesn't pull you into some unnecessary propritary land? [02:38:29 CEST] <ullbeking> everybody talks of plex and emby [02:38:32 CEST] <ullbeking> and i think why? [02:45:09 CEST] <kepstin> well, on the open source server side, it's basically kodi. iirc kodi does support streaming to a web browser player. [03:33:56 CEST] <ullbeking> is vlc/videolan server+client not also used as the basic for media servers? [03:34:12 CEST] <ullbeking> kepstin: kodi is properly open source? i'm looking now... [03:37:10 CEST] <furq> there's also jellyfin which is a fork of the last oss emby [03:38:14 CEST] <furq> but ultimately 99% of users only care about app support [03:38:22 CEST] <furq> so it lives and dies on that [04:44:18 CEST] <ullbeking> furq: i actually was building Jellyfin for an afternoon and trying to use it [04:44:25 CEST] <ullbeking> .NET was AWFUL [04:44:44 CEST] <ullbeking> i subsequently erased every trace of my involvement in that project [06:33:53 CEST] <lain98> so i want to read the first video frame in a stream. i do av_seek_frame(ctx, video_stream_index, 0, AVSEEK_FLAG_BACKWARD); and then av_read_frame(ctx, &pkt) but the packet i get is audio [06:36:03 CEST] <lain98> any clues ? [07:31:22 CEST] <troyBORG> If I'm trying to build from the git version would I ask here or in Dev channel? [07:32:06 CEST] <troyBORG> Or what does "ERROR: dav1d >= 0.4.0 not found using pkg-config" mean? [07:42:52 CEST] <JEEB> troyBORG: you tried enabling dav1d but configure couldn't find it [07:46:29 CEST] <troyBORG> where do I get dav1d? [07:47:23 CEST] <troyBORG> whenever I try to build it, it keeps redownloading the PKGBUILD file, so I can't figure out how to tell it not to install it [07:48:03 CEST] <troyBORG> Here is the build file it trying to use (Hopefully it doesn't kick or ban me for URLS?) [07:48:07 CEST] <troyBORG> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=ffmpeg-full-git [07:48:14 CEST] <furq> troyBORG: there should be an ffbuild/config.log somewhere unless aur deleted it or something [07:48:38 CEST] <furq> it'll probably have some kind of cc or ld error at the bottom [07:50:36 CEST] <troyBORG> gcc -D_FORTIFY_SOURCE=2 -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -I/opt/cuda/include -I/usr/include/tensorflow -std=c11 -fomit-frame-pointer -fPIC -pthread -I/usr/include/p11-kit-1 -I/usr/include/lilv-0 -I/usr/include/serd-0 -I/usr/include/sord-0 [07:50:36 CEST] <troyBORG> -I/usr/include/sratom-0 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/uuid -I/usr/include/fribidi -I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/uuid -I/usr/include/bs2b -c -o [07:50:36 CEST] <troyBORG> /tmp/ffconf.AunXBayo/test.o /tmp/ffconf.AunXBayo/test.c [07:50:36 CEST] <troyBORG> gcc -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -L/opt/cuda/lib64 -Wl,--as-needed -Wl,-z,noexecstack -o /tmp/ffconf.AunXBayo/test /tmp/ffconf.AunXBayo/test.o -lcodec2 [07:50:36 CEST] <troyBORG> require_pkg_config libdav1d dav1d >= 0.4.0 dav1d/dav1d.h dav1d_version [07:50:36 CEST] <troyBORG> check_pkg_config libdav1d dav1d >= 0.4.0 dav1d/dav1d.h dav1d_version [07:50:37 CEST] <troyBORG> test_pkg_config libdav1d dav1d >= 0.4.0 dav1d/dav1d.h dav1d_version [07:50:37 CEST] <troyBORG> pkg-config --exists --print-errors dav1d >= 0.4.0 [07:50:38 CEST] <troyBORG> Package dependency requirement 'dav1d >= 0.4.0' could not be satisfied. [07:50:38 CEST] <troyBORG> Package 'dav1d' has version '0.3.1', required version is '>= 0.4.0' [07:50:39 CEST] <troyBORG> ERROR: dav1d >= 0.4.0 not found using pkg-config [07:51:36 CEST] <troyBORG> looks like it has an old version of it in the git? [07:56:01 CEST] <troyBORG> the non -git version "ffmpeg-full" builds fine, its just "ffmpeg-full-git" that seems to fail [07:57:02 CEST] <troyBORG> any ideas @furq ? [07:59:13 CEST] <poutine> install dav1d 0.4.0 or higher (and use pastebins) [08:04:38 CEST] <troyBORG> sorry, and ok, going I wonder since its required for ffmpeg-full-git, wonder why it doesn't download it as well..... [08:06:51 CEST] <troyBORG> yeah that fixed it. Thanks [09:18:42 CEST] <lain98> does the av_seek_frame assure that if i read a frame after seeking the packet will have the same stream index that i passed to av_seek_frame ? [09:19:58 CEST] <JEEB> I don't think there's any promises of that in the doc? [09:20:09 CEST] <lain98> then why have the paramater [09:20:49 CEST] <JEEB> not sure but I would expect that to be the stream according to which the seek is being done? [09:20:51 CEST] <lain98> av_seek_frame takes format_context, stream_index, timestamp, flags [09:21:12 CEST] <JEEB> although you'd have to look at the implementation if you'd want to be sure instead of my guesstimations [09:21:27 CEST] <lain98> after seek if i av_read_frame, the packet didnt have the same stream index [09:21:41 CEST] <lain98> i thought av_seek would seek to a frame of the stream index passed to it [09:24:22 CEST] <lain98> JEEB: whats a fast way to read any packet of a stream index that i know. i just want a video packet and dont care about the frame number or timestamp [09:25:17 CEST] <lain98> right now i do something like while(..) { if index != .. {do nothing} else if {index == video} break} [09:27:56 CEST] <JEEB> lain98: I think the docs did note that the parameter was mostly utilized to "make sure" that you probably were around that time in that stream. [09:28:03 CEST] <JEEB> but nothing about what gets read first [09:28:29 CEST] <JEEB> lain98: that's how you typically do it. you read AVPackets and check if they match your stream selections [09:28:34 CEST] <JEEB> if they don't; you discard [09:29:04 CEST] <lain98> okay. the doxygen says that timestamp is converted from AV_TIME_BASE to time base of the stream [09:29:28 CEST] <lain98> but doesnt say about seeking to a point with a packet of that index [09:29:46 CEST] <lain98> so i guess youre right [09:32:12 CEST] <JEEB> ah yes, so it's for time base only [09:32:30 CEST] <JEEB> (welcome to me guesstimating things by memory ;) sometimes doxygen says it better) [11:32:41 CEST] <Guest88210> how to know the meaning of ARCH_AVR32_AP?? [11:35:51 CEST] <lain98> Guest88210: its a microcontroller [11:35:53 CEST] <lain98> arch [11:36:52 CEST] <Guest88210> I want to know where is the document that I can reference for this micro? [11:39:06 CEST] <lain98> Guest88210: source code its mentioned in libavutil/avr32 [11:41:28 CEST] <Guest88210> Thanks. How to know the meaning of macro ALT_BITSTREAM_READER? [11:41:52 CEST] <lain98> Guest88210: clone ffmpeg. search in the source code [11:42:18 CEST] <Guest88210> I am reading the source code. [11:43:04 CEST] <Guest88210> but I want to know whether has document introducing it. [11:43:28 CEST] <Guest88210> because it spends many time to read source code. [11:43:46 CEST] <lain98> grep it [11:44:09 CEST] <lain98> cant find that symbol in source code [11:47:41 CEST] <Guest88210> there are so many symbol related it. [12:02:09 CEST] <lain98> if i get EMFILE when trying to open file with the library. it only depends on ulimit right ? libav should handle if i up the limit ? [12:19:19 CEST] <JEEB> lain98: that generally comes from the system so you either have a leak somewhere, or you just raise the limit yes [13:09:48 CEST] <classsic> buen dia [14:22:16 CEST] <goel> Hi, I am having some trouble writing in a packet using av_write_frame. I am using FFmpeg bindings for C# (FFmpeg.AutoGen). All packets work except for 1, the first audio packet in a stream. When av_write_frame is called I am getting a memory access violation, so it may be a pointer I am not sure what is causing the issue but I know av_write_frame c [14:22:16 CEST] <goel> hanges the side_data. The packet->side_data.data is null but the packet->side_data.size is 10. [14:23:32 CEST] <JEEB> goel: were buffers etc allocated with av_malloc? [14:24:11 CEST] <JEEB> (or through the functions that set up AVPackets [14:29:00 CEST] <goel> I am guessing that is something wrong there. The side_data.data is null but the side_data.size is 10 after passing the packet to av_write_frame. If the side_data is not allocated, would size be present? [14:29:15 CEST] <goel> I call av_init_packet [14:35:22 CEST] <Guest88210> libavcodec/put_bits.h and libavcodec/bitstream.h have almost same function. Why not merge the two files? [14:43:05 CEST] <durandal_1707> Guest88210: you looking at wrong project files, bro [14:43:41 CEST] <Guest88210> http://ffmpeg.org/doxygen/0.5/bitstream_8h-source.html [14:43:47 CEST] <Guest88210> https://ffmpeg.org/doxygen/0.6/put__bits_8h-source.html [14:44:09 CEST] <Guest88210> durandal_1707: you can look at put_bits function. [14:47:02 CEST] <durandal_1707> sorry but you are not making any sense by comparing so old versions [14:50:36 CEST] <saml> bitstream.h got split into put_bits.h and get_bits.h [14:50:44 CEST] <saml> it no longer exists [14:53:05 CEST] <Guest88210> lol,soga [14:53:26 CEST] <Guest88210> durandal_1707: saml thanks [15:04:04 CEST] <idlus> Hi, I am gathering info from libavformat/electronicarts.c to try to remux a vp6 file with different audio, I can follow what happens in the header parsing functions but I dont get where the offset to sample data is retrieved. [15:04:31 CEST] <goel> Thank you, it is fixed now by calling av_packet_alloc, av_init_packet and av_packet_ref. [15:04:45 CEST] <goel> It could have been trying to access unallocated memory. [15:05:35 CEST] <lain98> do you thinks its possible to generate an index of (frame number)->(position in stream) by just iterating at the container level. avpacket only has timestamp information, but avframe has the number information. i wanted to use this index to seek quickly to the n'th frame [15:07:32 CEST] <lain98> right now i can imagine sorting the index based on pts and then assuming the packets are in the order they would be if i had the frame numbers [15:10:04 CEST] <DHE> if you sort AVPackets by pts time, you'll effectively get your frame number. it's just that they don't come out in render order from the container [15:10:31 CEST] <DHE> at least, it's not guaranteed [15:10:54 CEST] <lain98> any other better approach ? [15:11:28 CEST] <lain98> the problem i'm actually trying to solve is vfr [15:12:26 CEST] <lain98> my problem statement is something like decode x frames starting from n from video y [15:14:06 CEST] <lain98> but right now i cant handle vfr without indexing [16:21:46 CEST] <th3_v0ice> Hi, how can I configure ffmpeg so that I can debug it? [16:27:14 CEST] <JEEB> th3_v0ice: by default debug symbols are left in the _g files and stripped from the files without _g suffix [16:27:25 CEST] <JEEB> if you want everything to hvae debug symbols, --disable-stripping in configure [16:32:04 CEST] <th3_v0ice> So essentially that should allow me to step trought each line of code? I am trying to debug with VS2017 but the code is run on linux. [16:32:53 CEST] <DHE> yeah I just use ffmpeg_g directly as my binary with gdb when I'm troubleshooting [16:33:18 CEST] <JEEB> well I would check running gdb BINARY or BINARY_g and seeing if you can see that the symbols get loaded [16:33:25 CEST] <JEEB> if you are using the command line app [16:33:43 CEST] <JEEB> I'm not sure if we even strip the libs? I couldn't see a STRIP line during compilation for libavcodec.a for example [16:34:00 CEST] <JEEB> I just see STRIP lines for the cli binaries [16:34:13 CEST] <DHE> the libs are still full of debug symbols, and only the ffmpeg binary is stripped at the end of it [16:34:16 CEST] <JEEB> but yes, --disable-strip never strips anything during the build process :P [16:34:26 CEST] <DHE> brings my typical ffmpeg/ffprobe binary from 50 MB to 20 MB or so [16:34:46 CEST] <JEEB> DHE: ok so it's how it looks from my limited compilation log here in another terminal :P [17:02:29 CEST] <th3_v0ice> JEEB: Thanks, that did the trick. [18:24:11 CEST] <classsic> hi, I have two videos :A.avi: fps 30 tbr 30 tbn 30 tbc 30. B.avi: fps 2 tbr 2 tbn 2 tbc 2. [18:24:43 CEST] <classsic> how can copy tbr tbn and tbc from a.avi to b.avi? [18:24:56 CEST] <classsic> or get same values. [18:28:20 CEST] Action: Hello71 smells xy problem [20:03:51 CEST] <TheDrode> how is it going? [21:00:46 CEST] <lyncher> hi, I'm looking to the latm to adts bsf filter and I'm wondering if that would be even possible [21:01:08 CEST] <lyncher> because the input of that BSF would be aac_latm and the output will be ADTS [21:01:19 CEST] <lyncher> there's a "format" change inside the BSF [21:01:35 CEST] <lyncher> how will ffmpeg filtering handle that change inside a BSF? [21:01:50 CEST] <JEEB> right, yes. avcodec id change in the middle. [21:01:58 CEST] <JEEB> not sure if any other BSF has done that yet [21:02:37 CEST] <lyncher> maybe there's a concept that is missing in ffmpeg [21:03:01 CEST] <lyncher> for instance, if you try to extract CEA-608 captions from a H264 video [21:03:09 CEST] <lyncher> you'll find the same limitation [21:03:16 CEST] <JEEB> there it's side data [21:03:33 CEST] <lyncher> the BSF filter input is H264 but it's output is now CEA_608 [21:03:34 CEST] <JEEB> you get side data of type closed captions, and you have to make your own decoder instance etc [21:03:51 CEST] <JEEB> umm, why would you bsf that? the packets are already extracted for you? [21:03:54 CEST] <lyncher> which means that you cannot connect to a SUBTITLE filter [21:04:06 CEST] <lyncher> to convert the CC to SRT (for instance) [21:04:34 CEST] <JEEB> I think that's more of a problem regarding ffmpeg.c [21:04:36 CEST] <JEEB> than the APIs [21:05:17 CEST] <JEEB> to do CC to SRT you start reading the packets from input, and see if the AVPackets for the H.264 or MPEG-2 or HEVC stream have closed caption side data attached [21:05:19 CEST] <lyncher> I agree. the CC data is already at the side data [21:05:37 CEST] <JEEB> then when you get that you just initialize your decoder and the rest is your usual stuff [21:05:56 CEST] <JEEB> you get AVSubtitles from the decoder, you can then stick them where you want [21:06:51 CEST] <JEEB> so the closed caption part is a bad example tbh. it's just a limitation of how the ffmpeg.c command line app uses the API [21:06:56 CEST] <JEEB> rather than an issue with the API itself [21:07:21 CEST] <JEEB> just like ffmpeg.c will happily ignore any new AVStreams that will appear in your input :P [21:07:26 CEST] <lyncher> the only decoder that I found that is able to do that is lavfi: it receives a video and present two outputs: a video and a CC [21:07:35 CEST] <lyncher> the CC output will contain the side data CC [21:07:47 CEST] <lyncher> and can be then automatically connected to a subtitle processing filter [21:08:06 CEST] <JEEB> that is a workaround because people found it easier to do that than to rework ffmpeg.c? [21:08:15 CEST] <JEEB> separate ffmpeg.c and the APIs, please [21:08:49 CEST] <lyncher> right now that the only way that I found to dump the CC that is in side data [21:08:53 CEST] <DHE> is there a closed caption decoder available? [21:08:57 CEST] <JEEB> yes [21:09:08 CEST] <DHE> oh? I am interested. did not see it last time I checked [21:09:12 CEST] <JEEB> lyncher: in ffmpeg.c yes, if you make a short API client of yours it's much simpler :P [21:09:25 CEST] <JEEB> as I said a few times *please* separate ffmpeg.c from the APIs [21:10:04 CEST] <JEEB> there's (unfortunately) a lot of stuff that you can do with the API, but ffmpeg.c was never adapted for :P [21:10:06 CEST] <lyncher> I was trying to use ffmpeg.c to separate all source streams and process them individually (including CC) [21:10:25 CEST] <JEEB> DHE: ccaption I think [21:10:52 CEST] <lyncher> libavcodec/ccaption_dec [21:10:53 CEST] <DHE> thanks, found it [21:13:27 CEST] <DHE> Actually I think I want to do my own decoding and understanding of the format, but this is still awesome [21:14:29 CEST] <lyncher> so to do the LATM->ADTS conversion, the only option available right now is to do a full audio transcode [21:15:02 CEST] <lyncher> and the alternative will be to make an "encoder" that only repacks AAC packets in ADTS [21:15:28 CEST] <lyncher> that way the codec can be changed [21:16:09 CEST] <DHE> so there are adts and latm formats independent of the AAC encoder/decoders. [21:16:46 CEST] <DHE> so it should be possible to do an independent demux/remix with that [21:17:15 CEST] <DHE> the mpegts muxer does something like that with input that doesn't conform to the mpegts format needs [21:18:46 CEST] <lyncher> I'm trying to remux a latm into a mpeg-ts to be distributed over HLS, and the browsers currently don't have support for latm [21:24:01 CEST] <JEEB> DHE: so yea if you add a feature to the LATM demuxer that outputs ADTS AAC, that would be possible [21:26:05 CEST] <TheDrode> Guys, how do i tell ffmpeg to output unicast? It is pointing to a tcp address [21:26:12 CEST] <TheDrode> but tcp dump shows the packets as udp [21:29:42 CEST] <JEEB> I think unicast is just udp://IP.ADDRESS.HERE:PORT ? since udp://MULTICAST_ADDRESS:PORT works for multicast just fine [21:30:57 CEST] <TheDrode> JEEB: i dont want to send multicast packets [21:31:06 CEST] <JEEB> and I didn't say you would [21:31:24 CEST] <JEEB> I just say that according to my memory you should already with the first one have unicast UDP [21:31:37 CEST] <JEEB> you can verify that with netstat -apn or something :P [21:46:29 CEST] <TheDrode> ffmpeg -f hls -re -i http://localhost:5080/LiveApp/streams/548003639818081365541257.m3u8 -vcodec copy -tune zerolatency -r 20 -async 1 -acodec mp2 -ab 24k -ar 22050 -bsf:v h264_mp4toannexb -maxrate 700k -bufsize 3000k -f rtp_mpegts -fec prompeg=l=4:d=4 rtp://@10.10.13.3:1002 [21:46:43 CEST] <TheDrode> this command sends video to my headend [21:48:26 CEST] <TheDrode> but it looks like this: [21:49:34 CEST] <TheDrode> https://anonymousfiles.io/xnMUQaB8/ [23:26:58 CEST] <classsic> somebody know wha fps and tbr can differ? [23:27:35 CEST] <classsic> *why [23:29:37 CEST] <pink_mist> if they couldn't, there'd be no reason for both to exist [23:29:42 CEST] <pink_mist> but both do exist, so of course they can [23:32:53 CEST] <classsic> ok, here is the question, I have to concatenate black screen + video + blackscreen [23:34:10 CEST] <classsic> If I create blackscreen without exaclty tbn, when concatenate, I get wrong duration [23:36:41 CEST] <classsic> so, I need a ffprobe command that givme fps,tbn,tbr [23:46:31 CEST] <classsic> ffmpeg -i 5b4353828469a60001ee51c5\@5d5348f65336ad988628349e_2019-08-30_07-23-43_00-01-01.16_std.mp4 2>/dev/stdout |grep tbr [00:00:00 CEST] --- Sat Aug 31 2019

1 0

ffmpeg.log.20190812
by burek 30 Aug '19

30 Aug '19

[00:41:32 CEST] <ncouloute> I'm trying to concat multiple mp4 files together. It seems I get a +-8 frame offset between clips.. How can I maintain the video frame location after concatenation.Using ffmpeg cmd line [01:56:42 CEST] <Compressionz> Do we have a way to set the audio output device for FFplay? Or is it always the default device? [01:57:11 CEST] <cehoyos> "We" not but SDL has an option (just a moment): [01:58:16 CEST] <cehoyos> I have: [01:58:24 CEST] <cehoyos> export SDL_AUDIODRIVER=alsa [01:58:32 CEST] <cehoyos> export AUDIODEV=plughw:0,1 [01:58:49 CEST] <cehoyos> in my .bashrc to select alsa 0.1 as default device for ffplay [01:59:10 CEST] <cehoyos> (actually for sdl) [02:00:22 CEST] <Compressionz> Thats great! Thats a workaround at least :D Thanks a bunch for that info...Is it possible on Windows, too? [02:04:09 CEST] <Compressionz> I'd love to be able to route audio from FFplay into a virtual sound device on Windows but i've had to use this alternative https://github.com/audiorouterdev/audio-router [02:11:48 CEST] <DHE> well ffplay isn't really intended as a fully featured video player. more as a proof of concept, and it's convenient to run filter tests with it and stuff [02:11:49 CEST] <DHE> oh goddammit [04:10:58 CEST] <JAK-Zero> hey, just wanted to ask a quick question. On Windows, is there a way to update ffmpeg, or do I just have to download new versions myself? [04:12:11 CEST] <TheAMM> No*, yes [04:12:24 CEST] <TheAMM> (* technically depends on how you installed ffmpeg) [04:13:18 CEST] <JAK-Zero> oh? How can you install ffmpeg on Windows, besides downloading it from here? https://ffmpeg.zeranoe.com/builds/ [05:25:12 CEST] <KombuchaKip> What is the simplest way of determining the length of the data field in an AVFrame? [05:37:53 CEST] <Compressionz> heyo, so earlier I was asking about if it were possible to change the output audio device for ffplay. Cehoyos pointed out you can set some SDL enviromnent variables to change the device https://i.imgur.com/tzVblpm.png [05:38:02 CEST] <Compressionz> Thats great news but I'd also like to do the same on Windows. I've tried both the SDL_PATH_DSP and AUDIODEV variables but nothing seems to change... However if I make the SDL_AUDIODRIVER variable an incorrect one I do get this error https://i.imgur.com/aVy3xUe.png am I doing something wrong or does FFplay/SDL not support this on Windows..? Also her [05:38:03 CEST] <Compressionz> es what I used to set directsound as the driver https://wiki.libsdl.org/FAQUsingSDL#Win32-1 [06:00:38 CEST] <Abbott> whatsapp lists the video requirements as "less than 16MB" and recommended is h.264, aac, and mp4 container. so if I ffmpeg -i test.mkv -c:v libx264 -c:a aac output.mp4, why would the video not play in whatsapp [06:07:00 CEST] <Compressionz> The only alternative I can come up with is setting the default device to Virtual Audio cable, starting ffplay, and changing device back to speakers. [06:19:44 CEST] <Compressionz> I scripted a workaround in AutoHotkey if anyone is interested https://pastebin.com/XXgHNMUh [06:59:43 CEST] <Compressionz> Keep getting disconnected :b But yea hopefully someone finds that workaround useful until another method comes around [09:16:19 CEST] <MoziM> what's the best way to 'compress' duplicate frames without altering the length of the video itself? [09:17:58 CEST] <MoziM> let's say i have 10 seconds of footage where nothing changes on the screen, can a codec tell a video player to simply repeat the same image at n FPS for 10 seconds? therefore resulting in a really small file? [09:34:51 CEST] <pink_mist> MoziM: that's what most modern codecs likely will do, yes ... it might not be 100% like that, but it should be fairly close [09:38:52 CEST] <MoziM> which codec do you recommend? [09:39:15 CEST] <pink_mist> x264 probably [09:41:06 CEST] <MoziM> that's it? [09:41:17 CEST] <MoziM> :o [11:42:43 CEST] <rahulch> Hi, I have a webcam that is being used for a videocall. During the call, is it possible to capture the frames that I can see in my videocall application? [14:37:44 CEST] <goel> Hi I am copying the packets from one mp4 to a new mp4 file using FFmpeg/libav. I noticed when looking at the difference in both input and output files that the difference is only within the trailer. The metadata (when using ffprobe) of the output mp4 file in comparison to the input mp4 is only different in two places. The encoder version i.e. Lavf5 [14:37:45 CEST] <goel> 7.56.100 vs Lavf58.30.100 and the tbn for the input was 16384 compared to the output which stated 90K. Is it possible to change the metadata of the output file (AVFormatContext) before calling av_write_trailer() ? [14:41:41 CEST] <DHE> you're supposed to do it before writing av_write_header actually. also I don't see a way of controlling that beyond using AVFMT_FLAG_BITEXACT which really just strips out the version number for consistency [14:47:38 CEST] <goel> I am new to FFmpeg and libav, is there a specific method which allows me to modify the metadata? [14:47:48 CEST] <goel> And thanks for the help DHE [14:48:11 CEST] <DHE> I'm looking at the source. doesn't look like it's editable beyond bitexact mode [14:48:33 CEST] <goel> I just wanted to have both files being byte for byte the same. [14:48:33 CEST] <DHE> which like I said, mostly either strips out the metadata or makes it version-agnostic with simply "Lavf" [14:48:42 CEST] <DHE> well you definitely want bitexact mode then [14:49:38 CEST] <goel> Ok thanks, I'll have a look at bitexact mode. I appreciate your help! [14:57:36 CEST] <goel> It removed encoder information from the output file. I mean we wanted to make all the metadata in the trailer byte for byte the same as the original but I am not sure if that is possible. [14:58:30 CEST] <durandal_1707> are you creating fake video by any chance? [14:59:04 CEST] <goel> I am not sure what you mean by fake video? [14:59:24 CEST] <goel> This is a beginning process of prototyping a program. [14:59:37 CEST] <goel> We wanted to just deconstruct some videos and rebuild them. [15:00:06 CEST] <goel> Hence, the fact that the output was different from the input was interesting. [17:34:06 CEST] <pk08> hi [17:35:07 CEST] <pk08> i can make 2 volumebars (mono and stereo) using showvolume filter but i am getting only 2 bars even if input audio have more channels [17:35:38 CEST] <pk08> can any one tell me, is this limitation of showvolume filter or am i missing something? [17:41:49 CEST] <durandal_1707> full command missing [17:43:04 CEST] <durandal_1707> there is no limitation on number of channels [17:44:59 CEST] <fred1807> can I restream/forward a live stream from twtich to youtube? [17:45:50 CEST] <pk08> https://pastebin.com/60FSjetC [17:46:15 CEST] <pk08> durandal_1707: above command [17:47:37 CEST] <durandal_1707> try swapping w and h values [17:49:51 CEST] <durandal_1707> or perhaps your athers channels are croped out by that overlay command [17:50:13 CEST] <durandal_1707> so use x=0 [17:51:11 CEST] <pk08> ok, let me try [17:53:19 CEST] <durandal_1707> you can use q to stop encoding [18:02:38 CEST] <pk08> durandal_1707: i have set x=0 and tried but still it outputs only 2 audiobars [18:03:05 CEST] <pk08> i have read somewhere that, we can only outputs 2 volumebars [18:03:10 CEST] <pk08> but i cant find now [18:03:48 CEST] <durandal_1707> lies [18:04:17 CEST] <durandal_1707> your audio have 2 channels only [18:04:51 CEST] <durandal_1707> if you use only showvolume filter you will see [18:09:06 CEST] <pk08> check this: https://pastebin.com/1UTJWZJc [18:09:51 CEST] <pk08> you can check my command and see output of input stream and mapping of streams [18:11:23 CEST] <durandal_1707> i doubt you can select audio stream like that [18:11:59 CEST] <durandal_1707> 0x34 is specific stuff that does not work with filters [18:13:10 CEST] <pk08> but you can see its working [18:13:27 CEST] <pk08> if you see in ffmpeg mapping [18:13:54 CEST] <pk08> you will find stream: 0:1 is being used as input [18:16:40 CEST] <durandal_1707> your encoding format is stereo [18:17:20 CEST] <durandal_1707> and there is implicit conversion in log [18:17:38 CEST] <durandal_1707> why you use mp2? [18:18:40 CEST] <durandal_1707> you will need to use aformat before showvolume filter if you need mp2 [18:20:04 CEST] <durandal_1707> otherwise use better codec [18:20:07 CEST] <pk08> im testing audio output so leave mp2 for now [18:20:33 CEST] <pk08> and i am using -f mpeg and outputing as file pipe [18:20:48 CEST] <pk08> and using that piped output to play on screen [18:20:59 CEST] <pk08> so there is nothing to do with mp2 and -f mpeg [18:21:35 CEST] <durandal_1707> no [18:21:51 CEST] <durandal_1707> its stored as stereo [18:22:05 CEST] <durandal_1707> so use aac or copy ac3 [18:59:15 CEST] <pk08> thanks durandal_1707, its working now! [22:34:12 CEST] <Thomas_J> I have been spending all day trying to compile a version of gnutls in an aarch64 OS with unending dependency and compile errors. My latest issue is now a massive "libgnutls.so: undefined reference" error compiling for the target psktool. I am now just remembering back last month on this channel that I was told that gnutls is now part of the ffmpeg core. Am I remembering this correctly? If so, can I compile the latest ffmpeg without the --enable-gnutls [22:34:12 CEST] <Thomas_J> and still expect a rtmps push to Facebook to work? [23:10:29 CEST] <cehoyos> Thomas_J: gnutls is definitely not part of FFmpeg, gnutls is an optional dependency of FFmpeg [23:18:04 CEST] <Thomas_J> Dang! Well, back to getting gnutls compiled. Forr just streaming out with rtmps as a client, do I really need the psktool? [23:18:12 CEST] <BtbN> Why not just openssl? [23:18:58 CEST] <Thomas_J> I don't think that Facebook handshaked with SSL. [23:20:48 CEST] <cehoyos> openssl and gnutls should be two different external libraries that offer the same functionality for FFmpeg [23:21:16 CEST] <cehoyos> (That may not be true in every detail but there is a good chance it works) [23:21:29 CEST] <Thomas_J> I guess that it wouldn't hurt to give it a try. [23:21:50 CEST] <BtbN> Also, why build it yourself? Does your distro not package any ssl lib ffmpeg supports? [23:26:14 CEST] <Thomas_J> Accordig to JEEB there has been a problem that has appeared in rtmps encrypting with gnutls that makes handshaking with Facebook fail. He says that he fixed it but it hasn't trickled down into all the repositories. The version that is in the debian repos still has the problem. I tried to use it and it fails still. [23:27:18 CEST] <BtbN> so... don't use gnutls then? [23:27:36 CEST] <Thomas_J> Besides, this version is so bloated with all possible uses, it's humongas. [23:29:26 CEST] <Thomas_J> I need to use what works with facebook. I got it running like a champ last month ago but I have a new ARM64 unit I need to run it in running Armbian. [23:30:28 CEST] <BtbN> And they don't package openssl there? [23:30:45 CEST] <Thomas_J> And this is where I am trying to remember my conversations with JEEB on this channel. [23:31:51 CEST] <Thomas_J> I'm trying to duplicate what I did last month running it in a Raspberry PI 3B with Raspbian. [23:35:11 CEST] <cehoyos> Did you see https://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2019-July/date.html ? It's currently broken though... [23:37:00 CEST] <BtbN> I really don't see the big issue [23:37:09 CEST] <BtbN> if they have a known issue with gnutls... use something else [23:45:17 CEST] <Thomas_J> As I say, The problem with rtmps has been fixed and I do have a running version using rtmps the core support in another ARM unit but I am trying to duplicate that. Actually, it is slowly coming back to me. I don't think that I used gnutls at all. I think I used the internal core support for the rtmps after it has been fixed. [23:46:25 CEST] <BtbN> ...? [23:46:29 CEST] <BtbN> "the internal core support"? [23:46:38 CEST] <BtbN> ffmpeg did not NIH a ssl lib as of yet [23:48:13 CEST] <Thomas_J> Yes. ffmpeg, in it's docs shows the command for rtmps use and a separate one for using the gnutls module to handle encryption [23:49:32 CEST] <furq> the internal rtmps stuff still depends on a linked tls lib [23:51:31 CEST] <furq> also you should just be able to link with your distro provided gnutls [23:53:18 CEST] <BtbN> furq, aparently it's older and has a bug that breaks it talking to Facebook [00:00:00 CEST] --- Tue Aug 13 2019

1 0

ffmpeg-devel.log.20190829
by burek 30 Aug '19

30 Aug '19

[10:56:01 CEST] <JEEB> > write a 30min+ TTML packet with a default subtitle time base [10:56:11 CEST] <JEEB> > pkt->duration > INT_MAX [10:56:30 CEST] <JEEB> `Application provided duration: 2264762930 is invalid` [10:56:31 CEST] <JEEB> vOv [10:56:48 CEST] <JEEB> probably gets fixed if I force time base to be 1/1000 [10:57:14 CEST] <nevcairiel> why one subtitle f or 30 minutes, slow readers? :D [10:57:24 CEST] <JEEB> nevcairiel: the spec says one document for the whole fragment [10:57:33 CEST] <nevcairiel> the spec is dumb [10:57:39 CEST] <JEEB> yes, yes it is [10:57:48 CEST] <JEEB> I've felt that in my bones for many, many times [10:57:54 CEST] <nevcairiel> heh [10:58:13 CEST] <JEEB> because now I have to keep a list of AVPackets for each track that's getting squashed packets [10:58:35 CEST] <JEEB> and then when fragment is generated or footer written you generate the final packet [10:58:56 CEST] <JEEB> that does lead to fun things like fragmentation based on time with only that track in the mux not working (unsurprisingly) [10:59:35 CEST] <JEEB> until I add that logic to also check the queue [10:59:45 CEST] <JEEB> for tracks that have the flag of squashing packets [11:00:25 CEST] <JEEB> TTML in mp4 </3 [11:03:21 CEST] <JEEB> nevcairiel: also there's two profiles seemingly. an older "unofficial" one that uses tag dfxp, where the TTML document's times are to be interpreted from the start of the sample (so fragment start + sample pts). and then you have stpp which is the official spec which says that the times of the documents should be on the "global time line", so unrelated to the actual sample's timestamp [11:03:46 CEST] <nevcairiel> opposing interpretation, fun. [11:04:20 CEST] <JEEB> at least they use differing codec_tags [11:05:02 CEST] <nevcairiel> assuming everyone is sane and sticks to those :D [11:06:00 CEST] <JEEB> yea I've seen exoplayer's comments which seemed to note something about offsetting and thus I have this fright that they might be interpreting stpp like dfxp [11:06:22 CEST] <JEEB> I haven't tested yet since this crapola is mostly utilized to feed live ingests [11:07:35 CEST] <JEEB> but yea, the squashing logic is fun to test [11:17:18 CEST] <JEEB> ok, by dropping time base to 1:1000 that worked [11:17:55 CEST] <JEEB> will have to figure out if there's a better way to do that duration check, although for such subtitles I might as well set time base to 1:1000 by default [11:18:11 CEST] <JEEB> since you don't get any additional fractions in the documents [11:27:33 CEST] <J_Darnley> Does anyone here use draw_horiz_band and h264? [11:27:51 CEST] <J_Darnley> I know the feature flag is commented in master [11:31:35 CEST] <J_Darnley> First, I'll get the api test to use it [11:31:44 CEST] <JEEB> :) [11:31:59 CEST] <JEEB> (also no, haven't used band drawing with H.264) [11:32:14 CEST] <J_Darnley> I put it in vc2 once [11:32:20 CEST] <J_Darnley> but that was easy [11:32:38 CEST] <J_Darnley> everything in order, all on the same thread [11:34:38 CEST] <JEEB> for a moment I thought I'd be able to dump the contents of an AVPacket easily with ffprobe :) [11:34:47 CEST] <durandal_1707> do not touch draw horiz band, you will kill small kittens [11:34:57 CEST] <JEEB> although I guess... I could maybe -c copy -f raw [11:35:26 CEST] <J_Darnley> durandal_1707: too late [11:35:34 CEST] <durandal_1707> i dump stuff from packets all the time [11:35:34 CEST] <J_Darnley> I need the practice [11:35:47 CEST] <J_Darnley> its been a year since I last killed one [11:36:54 CEST] <JEEB> durandal_1707: what's the muxer you usually use for it? rawvideo? [11:37:14 CEST] <durandal_1707> yes [11:37:28 CEST] <JEEB> yes, that worked \o/ [11:38:40 CEST] <durandal_1707> add draw horiz band to png [12:46:23 CEST] <J_Darnley> do I need to stick a framer in here? [12:46:55 CEST] <kierank> J_Darnley: framer? [12:47:07 CEST] <kierank> 10:34:46 <"durandal_1707> do not touch draw horiz band, you will kill small kittens [12:47:08 CEST] <kierank> nonsense [12:47:43 CEST] <J_Darnley> actually, I don't think this sample is what I want to use [12:48:28 CEST] <kierank> J_Darnley: I would say get it working single threaded first [12:48:31 CEST] <kierank> them sort threads out [12:48:47 CEST] <J_Darnley> does the test use threads? [12:49:04 CEST] <J_Darnley> "ctx->thread_count = 1" [12:49:45 CEST] <J_Darnley> I think this is the weird assembled file josh put together for a different test [12:49:55 CEST] <kierank> https://github.com/FFmpeg/FFmpeg/blob/master/tests/api/api-band-test.c [12:49:56 CEST] <kierank> not this one [12:50:28 CEST] <kierank> the chunks one is this one https://github.com/FFmpeg/FFmpeg/blob/master/tests/api/api-h264-slice-test.… [12:50:30 CEST] <kierank> -c [12:51:24 CEST] <J_Darnley> okay, i need to copy some stuff from the first to the second [12:51:52 CEST] <kierank> hmm yeah lots of combinations [13:06:58 CEST] <J_Darnley> why does the draw_horiz_band test negate frame dimentions twice? [13:07:14 CEST] <J_Darnley> -((-ctx->width) >> pix_fmt_desc->log2_chroma_w) [13:07:57 CEST] <J_Darnley> I thought we hated shifting negative numbers these days. [13:08:15 CEST] <J_Darnley> is it for rounding? [13:09:03 CEST] <durandal_1707> hackers remain hackers? or they grow up? [13:09:32 CEST] <J_Darnley> A student of one kind or another wrote it [13:10:03 CEST] <durandal_1707> draw horiz band is evil, kierank does not care :) [13:10:30 CEST] <J_Darnley> like all broadcast people he has a low latency fetish [13:10:52 CEST] <durandal_1707> modern codecs use macroblocks not bands [13:11:14 CEST] <J_Darnley> a block level callback sounds great for performance [13:16:24 CEST] <kierank> it's good for cache [13:16:32 CEST] <kierank> you can map the data to the format you need whilst it's still in cache [13:18:30 CEST] <J_Darnley> wtf [13:18:38 CEST] <J_Darnley> what is active_thread_type [13:18:54 CEST] <J_Darnley> 0 is no threads? [13:19:23 CEST] <BBB> J_Darnley: double neg rounds up [13:19:45 CEST] <BBB> it's the same as (ctx->width + (1 << log2_chroma_w) - 1) >> log2_chroma_w [13:19:47 CEST] <BBB> but shorter [13:19:48 CEST] <J_Darnley> I did wonder [13:21:03 CEST] <J_Darnley> whatever, I'll just change that check [13:24:01 CEST] <J_Darnley> dammit make! why won't you rebuild this? [13:25:47 CEST] <J_Darnley> make: *** No rule to make target 'tests/api/api-h264-slice-test'. Stop. [13:29:24 CEST] <J_Darnley> APITESTPROGS-$(call DEMDEC, H264, H264) += api-h264-slice [13:29:32 CEST] <J_Darnley> somtimes I really hate make magic [13:37:07 CEST] <J_Darnley> but that program in in the variable [13:37:21 CEST] <J_Darnley> so make knows to build it for the test [13:37:48 CEST] <J_Darnley> so why don't you know it by filename? [13:44:58 CEST] <J_Darnley> the test reports error concealment if I use 1 thread [13:46:07 CEST] <J_Darnley> but somehow it ends up with the same frame hash [13:52:51 CEST] <kierank> J_Darnley: yes we saw this last time [14:08:55 CEST] <JEEB> heh, all this timestamp handling makes me think of how much weird things I will have to handle :D in my case I'm at least getting packets with dts/pts that is monotonically rising and not AV_NOPTS_VALUE [14:36:15 CEST] <Lynne_> durandal_1707: I just can't find any motivation to submit patches when they'll be bikeshed for useless asserts and my opinions would get ignored [14:38:29 CEST] <Lynne_> or worse, be accused of being rude for brining up a valid but ignored point, then be accused for being aggressive for brining up the twice ignored valid point, then get thrown under a bus for attacking people because I can't seem to get any replies to my original point [14:38:51 CEST] <Lynne_> and even better when later on people think "hmm, that point was valid, why wasn't this brought up earlier?" [14:41:55 CEST] <durandal_1707> Lynne_: i will apply your patches [14:43:22 CEST] <durandal_1707> just post then on ml [15:41:29 CEST] <J_Darnley> what is return code -22? [15:42:23 CEST] <J_Darnley> EINVAL [15:42:35 CEST] <J_Darnley> because this has no pixel format [15:53:11 CEST] <J_Darnley> whoa, no way [15:53:18 CEST] <J_Darnley> I don't eblieve this works [16:03:10 CEST] <J_Darnley> no it doesn't work, frames differ [16:06:15 CEST] <J_Darnley> works in single thread [16:06:22 CEST] <J_Darnley> but 2 or more doesn't [16:07:00 CEST] <J_Darnley> Are some of these calls for different frames? [16:10:32 CEST] <J_Darnley> i have no idea [16:10:43 CEST] <J_Darnley> the AVFrame pointer is the same [16:10:56 CEST] <J_Darnley> but this tets only allocates 1 [16:16:38 CEST] <kierank> J_Darnley: you're doing chunks, sliced threads and draw_horiz? [16:16:43 CEST] <kierank> and your sample is x264 slice threads encoded? [16:17:00 CEST] <J_Darnley> the sample is the nal file [16:17:14 CEST] <kierank> ok [16:17:38 CEST] <J_Darnley> yes to the other [16:18:04 CEST] <kierank> not sure if the nal file sample is progressive or interlaced [16:18:17 CEST] <kierank> could be a progressive vs interlaced problem [16:18:27 CEST] <J_Darnley> maybe [16:18:39 CEST] <J_Darnley> why does that work on 1 thread then? [16:19:05 CEST] <kierank> dunno [16:22:40 CEST] <kierank> J_Darnley: are you reordering the slices [16:22:46 CEST] <kierank> maybe try dumping the output [16:22:50 CEST] <kierank> see what's different [16:23:04 CEST] <cone-764> ffmpeg 03Michael Niedermayer 07master:e0c973e5bea9: avformat/mpsubdec: Remove floating point usage [16:23:04 CEST] <cone-764> ffmpeg 03Michael Niedermayer 07master:37bc8e3249c8: avcodec/cavsdec: Limit the number of access units per packet to 2 [16:23:04 CEST] <cone-764> ffmpeg 03Michael Niedermayer 07master:dea2591d4fbc: avcodec/vb: Check input packet size to be large enough to contain flags [16:23:04 CEST] <cone-764> ffmpeg 03Michael Niedermayer 07master:7e9aecc9f358: avcodec/tta: Fix integer overflow in prediction [16:23:04 CEST] <cone-764> ffmpeg 03Michael Niedermayer 07master:738ff94f7c38: tools/target_dec_fuzzer: adjust pixel threshold for SANM, as it allows coding gigantic images on tiny input [16:23:05 CEST] <cone-764> ffmpeg 03Michael Niedermayer 07master:96efaa9a1a22: tools/target_dec_fuzzer: Adjust GDV pixel threshold down by a factor of 2 [16:23:05 CEST] <cone-764> ffmpeg 03Michael Niedermayer 07master:ba823394f65a: tools/target_dec_fuzzer: Adjust maxpixels for indeo4 [16:23:06 CEST] <cone-764> ffmpeg 03Michael Niedermayer 07master:15a65c13e184: avcodec/ivi: Allocate bufs later [17:16:04 CEST] <JEEB> hah, got myself debugging capability by using the segment muxer and csv output + making it utilize the rawvideo muxer for segments by using the extension .rgb xD [17:17:48 CEST] <J_Darnley> impressive hackery [17:18:24 CEST] <J_Darnley> kierank (and anyone else following): the differing frames have obvious errors [17:18:29 CEST] <JEEB> `-map 0:2 -c copy -f segment -segment_format data -segment_list debug_segments/index.csv -break_non_keyframes 1 -segment_time 0.01 'debug_segments/%04d.rgb'` [17:18:40 CEST] <J_Darnley> the first frame has a large grey gap [17:18:47 CEST] <JEEB> 0:2 being an XML based sample format that I'm not going to write a decoder for at least now [17:19:24 CEST] <JEEB> so now I get an index out of the csv, and then every document goes into its own "rgb" file :) [17:19:36 CEST] <JEEB> also yes the segment_format says data but it seems like it's being 100% ignored [17:19:52 CEST] <JEEB> the extensions trumps all [17:20:24 CEST] <J_Darnley> 3rd frame has a green gap at the right edge [17:21:37 CEST] <kierank> J_Darnley: is your draw_horiz_band thread safe [17:21:54 CEST] <kierank> i.e could two threads call fwrite at the same time [17:22:00 CEST] <kierank> and cause that [17:22:03 CEST] <J_Darnley> I think memcpy is fine [17:22:15 CEST] <J_Darnley> if I don't overlap regions [17:23:15 CEST] <kierank> what allocates the main frame buffer? [17:23:25 CEST] <J_Darnley> main() I think [17:23:56 CEST] <kierank> I'm not sure you can do that [17:23:59 CEST] <kierank> because of the frame slice boundary [17:24:07 CEST] <kierank> |frame1_slice|frame2_slice| [17:24:14 CEST] <kierank> you could get a callback from frame2_slice first [17:24:20 CEST] <kierank> then frame1_slice [17:24:23 CEST] <kierank> or do you handle that? [17:24:47 CEST] <J_Darnley> what? [17:25:18 CEST] <kierank> if each thread is working on a slice [17:25:21 CEST] <J_Darnley> I copy from AVFrame into a flat buffer based on the arguments given to the callback. [17:25:29 CEST] <kierank> J_Darnley: can you pastebin your code [17:28:07 CEST] <J_Darnley> ah no, I am allocating wring, I think [17:30:36 CEST] <J_Darnley> and it allegedly asserts on a line that has no assert when I run in gdb [17:30:58 CEST] <J_Darnley> time for --disable-optimizations [17:46:32 CEST] <J_Darnley> kierank: https://pastebin.com/8WyQhX4D [17:47:48 CEST] <J_Darnley> save into tests/api/api-h264-slice-test.c if you want to diff it with git [17:49:34 CEST] <kierank> I think one frame might work with that code [17:49:43 CEST] <kierank> But it doesn't handle the boundaries afaict [17:51:37 CEST] <kierank> Also not really sure how the test works tbh because I think it assumes every nal is a slice [17:51:50 CEST] <kierank> That's the fault of the original test I think [17:52:39 CEST] <kierank> Will look when back at pc with a diff [17:53:19 CEST] <cone-764> ffmpeg 03Aman Gupta 07master:59e651c05244: configure: fix --enable-omx compile on raspberry pi [17:58:42 CEST] <kierank> J_Darnley: do you have an easy link to the .nal sample [17:58:46 CEST] <kierank> I don't want to rsync the whole lot [17:59:21 CEST] <J_Darnley> just a mo [17:59:38 CEST] <kierank> I wonder if he removed the sei [17:59:49 CEST] <kierank> and maybe merged the sps/pps with first slice [17:59:53 CEST] <J_Darnley> https://0x0.st/s6ap.nal [18:01:06 CEST] <kierank> J_Darnley: seems not [18:01:09 CEST] <kierank> but maybe it works anyway [18:01:49 CEST] <J_Darnley> it is between 33 and 50% of frames that come out identical [18:02:02 CEST] <J_Darnley> Does valgrind do threads? [18:02:03 CEST] <kierank> bugger, no AUDs [18:02:06 CEST] <kierank> no it doesn't [18:02:11 CEST] <J_Darnley> tsan then [18:02:22 CEST] <kierank> J_Darnley: the problem is when you have, say 4 threads and 2 are working on frame n and two are working on frame n+1 [18:02:32 CEST] <kierank> if the two that are working on frame n+1 return first I think it breaks the code [18:02:53 CEST] <kierank> J_Darnley: does avframe return pts [18:03:08 CEST] <kierank> or some frame number identifier, then you could identify which frame was which [18:03:39 CEST] <J_Darnley> AVFrame in the callback? I can check [18:04:01 CEST] <kierank> yeah [18:04:07 CEST] <kierank> I think it has an incrementing counter or something [18:05:10 CEST] <J_Darnley> pts and dts look like INT64_MIN on the first callback [18:06:04 CEST] <J_Darnley> there's 2 picture numbers which I will watch [18:06:54 CEST] <kierank> J_Darnley: maybe write a new file for each frame [18:07:00 CEST] <kierank> so you know the fwrite calls don't collide [18:07:07 CEST] <kierank> or new buffer for every frame [18:07:09 CEST] <kierank> and then write them all at the end [18:07:13 CEST] <J_Darnley> How can that? they're in the main thread [18:07:22 CEST] <kierank> sorry not fwrite [18:07:49 CEST] <kierank> actually wait a second [18:08:07 CEST] <J_Darnley> c [18:08:12 CEST] <kierank> so while (ret >= 0) { [18:08:28 CEST] <kierank> that will ring true but other frames may have been completed and memcpyied to your buffer by then [18:08:59 CEST] <kierank> other slices I mean [18:09:22 CEST] <kierank> printf might tell you but not guaranteed to be ordered I guess [18:09:49 CEST] <J_Darnley> yes [18:09:59 CEST] <J_Darnley> you did say I needed to get single thread working forst [18:10:01 CEST] <J_Darnley> it does [18:10:07 CEST] <J_Darnley> now I neeed to handle order [18:10:19 CEST] <kierank> I would just allocate n buffers [18:10:23 CEST] <kierank> for the time being [18:10:29 CEST] <kierank> just to see if it's an ordering problem [18:10:36 CEST] <kierank> and use the frame counter in avframe to pick the right one [18:10:44 CEST] <kierank> then write them all at the end of the file [18:10:55 CEST] <J_Darnley> coded_picture_number incements [18:11:00 CEST] <kierank> that'll do [18:11:03 CEST] <J_Darnley> so I'll use that for the test [18:11:08 CEST] <kierank> no bframes so should be fine [18:13:01 CEST] <J_Darnley> q [18:32:20 CEST] <cone-764> ffmpeg 03Paul B Mahol 07master:0067da587a08: avcodec/msrle: add a flush() callback [18:38:35 CEST] <J_Darnley> oh dammit [18:38:37 CEST] <J_Darnley> src/libavfilter/vsrc_testsrc.c: In function color_gradient: [18:38:37 CEST] <J_Darnley> src/libavfilter/vsrc_testsrc.c:718:1: error: control reaches end of non-void function [-Werror=return-type] [18:40:10 CEST] <J_Darnley> and another one! [18:42:33 CEST] <J_Darnley> two more [18:54:35 CEST] <J_Darnley> wow tsan is slooo~ooow [18:57:03 CEST] <J_Darnley> and this seems to be even worse [18:57:13 CEST] <J_Darnley> fewer frames are identical [18:57:39 CEST] <J_Darnley> and I do have at least one data race [18:59:39 CEST] <J_Darnley> memcpy in the callback [19:00:56 CEST] <J_Darnley> Maybe I need a new AVFrame for each call to decode [19:05:49 CEST] <J_Darnley> i get data races with the stock test anyway [19:08:38 CEST] <J_Darnley> it seems as though fate knows [19:08:51 CEST] <J_Darnley> but nobody looks [19:09:45 CEST] <J_Darnley> oh, h264 is filled with them it seems [19:12:12 CEST] <J_Darnley> hm, I want a whitelist, not a blacklist [19:14:17 CEST] Action: J_Darnley goes to look for the ref counting patch for the fuzzer [19:20:58 CEST] <kierank> J_Darnley: yeah we had this discussion a few years ago, tsan is full of false positives [20:51:28 CEST] <durandal_1707> gonna apply imm5 decoder soon [21:07:57 CEST] <cone-764> ffmpeg 03Paul B Mahol 07master:7c0b3ba7ddaa: avcodec: add IMM5 decoder [22:59:54 CEST] <kierank> durandal_1707: what is imm5 [22:59:59 CEST] <kierank> is that thing with hevc and h264 [23:00:09 CEST] <durandal_1707> yes [23:02:22 CEST] <j-b> nice [23:03:13 CEST] <durandal_1707> not really, piece of cctv crap [23:03:55 CEST] <durandal_1707> should be forbiden and punished by law to make such codecs [23:06:30 CEST] <jamrial> can't even call it a codec. it's like a wrapper [23:07:44 CEST] <durandal_1707> thera are already less and more complicated codecs wrappers [23:53:20 CEST] <jamrial> ubitux: your coverage client hasn't run since early last year. any chance to resurrect it? [00:00:00 CEST] --- Fri Aug 30 2019

1 0

ffmpeg.log.20190829
by burek 30 Aug '19

30 Aug '19

[00:00:20 CEST] <dastan> With this one i get the speed of the process [00:00:20 CEST] <dastan> tail -f "log" | grep -o -E "speed=[0-9]+.[0-9]+++[a-z]+|speed=[0-9]+.[0-9]++[a-z]+|speed=[0-9]+.[0-9]+[a-z]+|speed=[0-9]+[a-z]+" [00:01:42 CEST] <dastan> With this one i get the file being opened at the moment [00:01:42 CEST] <dastan> tail -f "log" | grep -o -E "Opening '/home/build/MSS-ONE/temp/cache/TN-27153d00/TN[0-9]+.ts|TN[0-9]++.ts|TN[0-9]+++.ts' for writing" [00:01:52 CEST] <dastan> i need to show them together [00:06:47 CEST] <klaxa> you can simply combine those to: grep -o -E "(speed=[0-9]+.[0-9]+++[a-z]+|speed=[0-9]+.[0-9]++[a-z]+|speed=[0-9]+.[0-9]+[a-z]+|speed=[0-9]+[a-z]+|Opening '/home/build/MSS-ONE/temp/cache/TN-27153d00/TN[0-9]+.ts|TN[0-9]++.ts|TN[0-9]+++.ts' for writing)" or can you not? [00:12:56 CEST] <dastan> lets try [00:14:23 CEST] <dastan> its not in the same line but its a good improvement [00:14:53 CEST] <dastan> i get this speed=1.01x [00:14:53 CEST] <dastan> TN829.ts' for writing [00:15:47 CEST] <dastan> and i dea to show the info in two columns? [06:17:01 CEST] <mr_lou> Does ffmpeg have any fancy way of detecting and removing socalled flash frames? I.e. frame in the video overexposed due to flash photography. [06:28:14 CEST] <VikeStep> just wanted a quick sanity check, I've written a program that does the avcodec_send_packet/avcodec_receive_frame loop for every frame in a video. for a 1h20m 1080p h264 mp4 video at 30fps, it takes 4m32s to parse the entire video. Does that sound like a reasonable amount? Or would you expect it to be much faster? [06:37:02 CEST] <furq> VikeStep: time ffmpeg -i foo.mp4 -f null - [06:37:13 CEST] <furq> should at least give you something to compare it against [06:37:29 CEST] <VikeStep> ah, I've never actually used the ffmpeg tool before so forgot that existed [06:37:54 CEST] <VikeStep> will see how that goes [06:44:25 CEST] <VikeStep> it gives pretty much the exact same speed, cheers [07:54:37 CEST] <lain98> whats a good heuristic to check for vfr. i know vfrdet does this but i dont want to run a filter over the entire video [07:59:12 CEST] <furq> https://ffmpeg.org/doxygen/trunk/structAVPacket.html#a622e758be29fd500aed0f… [07:59:15 CEST] <furq> probably that [08:00:02 CEST] <furq> ffprobe -show_packets if you're not using the spi [08:00:03 CEST] <furq> api [08:09:30 CEST] <lain98> furq: so AVPacket::duration [08:09:32 CEST] <lain98> will be unknown(0) ? [08:14:42 CEST] <furq> if it's cfr then it should be the same for every packet [08:15:21 CEST] <lain98> but that still means i have to iterate over packets :D [08:15:40 CEST] <furq> sure but you don't have to decode the video [08:15:40 CEST] <lain98> hmm [08:15:42 CEST] <lain98> yes thats true [08:15:42 CEST] <furq> you can also break early if it is vfr [08:16:51 CEST] <lain98> right now i just check avg_frame_rate.num==1 in stream [08:16:51 CEST] <lain98> thanks furq [08:17:43 CEST] <furq> there might be a better way, i've not used the api very much [08:26:35 CEST] <JEEB> lain98: if you really want to know there's no other way than indexing :P [08:26:40 CEST] <JEEB> you can try and attempt to hack around it [08:26:53 CEST] <JEEB> but you have asked a technical question and technically there is just one answer to it [08:26:59 CEST] <JEEB> I am sorry to bring it to you :P [08:32:04 CEST] <lain98> JEEB: looks like most of my problems could be solved by indexing [08:32:06 CEST] <lain98> :) [08:33:30 CEST] <JEEB> lain98: the best stuff of course is when you have a container with non-exact timestamps like MPEG-TS or FLV. then you also have to have logic (like ffms2 has I think) which looks at some difference to constant frame rate and sets the content as CFR if the timestamps seem to be just oscillating because of time base being inexact [08:34:09 CEST] <lain98> *mind blow* [08:34:47 CEST] <lain98> codecs and containers are as varied as animals in the jungle [08:53:56 CEST] <Mavrik> It is easier if you have a limited number of input options [08:58:10 CEST] <lain98> got me thinking if i have a list of some non-standard fps like 29.97 and stuff and then combine the check with or the fps is a whole number like 1/x where i just check the avg_frame_rate.num==1 [09:07:41 CEST] <lain98> i should be fine ? [13:27:52 CEST] <kepstin> note that 29.97 (actually exactly 30000/1001) is a standard fps [13:31:41 CEST] <lain98> okay, so i was checking out a video. and the frames have duration of 1024 and 512 alternatively. but this is constant frame rate how ? [13:32:44 CEST] <lain98> oh shit its an audio packet [13:41:56 CEST] <pomaranc> does anyone have an example HLS stream with webvtt subtitles? [13:42:07 CEST] <termos> hmm, I'm trying to init a bsf like so av_bitstream_filter_init("filter_units=remove_types=35") but it just returns nullptr, it's not null if I just try to specify the filter name "filter_units". Is there another way to specify the arguments? [13:42:24 CEST] <termos> I should probably switch to the non-legacy API, but just doing this as a quick test [16:30:04 CEST] <classsic> Hi somebody can explain what means the parameters "speed=1.01x" at the end of logs? [16:30:51 CEST] <FooNess> classsic, the speed of transcoding relative to the actual length of the media on the file. [16:31:18 CEST] <FooNess> classsic, so if you see, for example, "speed=1x" for a movie that lasts 90 minutes, the transcode took 90 minutes. [16:31:38 CEST] <FooNess> If you saw "speed=2.00x", then it took 45 minutes to transcode it. [16:31:44 CEST] <classsic> but, this appear when stream with vcodec copy to rtmp server, some cases under 1x [16:32:21 CEST] <FooNess> Right; it could be faster or slower than the original time. [16:32:26 CEST] <durandal_1707> yes, its normal [16:32:28 CEST] <FooNess> Depending on a lot of things. [16:32:38 CEST] <FooNess> Network latency/bandwidth, processing power, etc. [16:49:45 CEST] <classsic> but that not means something is wrong, right? [16:52:06 CEST] <kepstin> are you streaming from a file with -re, or restreaming another live source? [17:19:44 CEST] <classsic> kepstin restreaming frome another live source [17:34:51 CEST] <dastan> hello people [17:35:39 CEST] <dastan> i am redirecting the std out of a ffmpeg command to create a log [17:36:25 CEST] <dastan> and i want to read this log but i want to only show the speed, can someone help me with the scripting [17:37:12 CEST] <dastan> with ths next command i get speed=1.01 or speed=1.02 [17:37:44 CEST] <dastan> tail -f /home/build/MSS-ONE/temp/logs/TN-f9aa8baa/TN-f9aa8baa-cache.log | awk '/speed=/ { speed=$10 ; print speed ; }' [17:38:53 CEST] <dastan> how can i save the number 1.01 or 1.04 or 1 in the variable speed? [17:39:19 CEST] <pink_mist> since you're using awk, ask in an awk channel [17:39:21 CEST] <pink_mist> this is #ffmpeg [17:39:35 CEST] <dastan> there is a awk chnnel? [17:39:39 CEST] <pink_mist> no clue [17:40:20 CEST] <dastan> yep [17:40:21 CEST] <dastan> #awk [17:40:21 CEST] <pink_mist> #ffmpeg is not the awk channel however [17:40:36 CEST] <dastan> i am workiung with ffmpeg [17:40:39 CEST] <BtbN> You also asked the exact same question yesterday, and got a pretty good answer? [17:41:09 CEST] <pink_mist> you're working with text data. the fact that it's ffmpeg producing it is completely irrelevant [17:41:15 CEST] <dastan> we didnt get a solution with klaxa [17:41:55 CEST] <dastan> he was more friendly than you [17:42:20 CEST] <dastan> but dont worry, i will check in the awk channel [18:15:26 CEST] <durandal_1707> i want working solution now and for free [18:16:11 CEST] <durandal_1707> also ffmpeg developers do free consulting because it is free [18:46:34 CEST] <classsic> talking about logs output, ffmpeg don`t write logs line by line right? [18:47:12 CEST] <classsic> I get a looooooong line with speed, and other data. [19:00:46 CEST] <durandal_1707> you do something wrong [19:00:55 CEST] <durandal_1707> log output is fine [19:02:24 CEST] <classsic> ok, I execute ffmpeg inside docker, maybe that`s the problem [19:04:11 CEST] <kepstin> the stats line is terminated with \r instead of \n (that causes it to overwrite the same line on a terminal) [19:04:32 CEST] <kepstin> you need to account for that when splitting lines [19:06:24 CEST] <classsic> but I user tail .....ffmpeg.log, in bash env [19:07:04 CEST] <classsic> *i use [23:10:22 CEST] <TheDrode> Good afternoon, i am trying to re-stream an hls source to a Colable 5011 device using the command related in my pastebin (available in a second) I am getting broken video full of artifacts [23:10:26 CEST] <TheDrode> what am i doing wrong? [23:10:27 CEST] <TheDrode> http://paste.ubuntu.com/p/y42pzmXnyZ/ [23:10:37 CEST] <TheDrode> any help will be really appreciated [23:18:17 CEST] <DHE> is anyone else getting a broken paste? [23:18:47 CEST] <DHE> n/m [23:19:05 CEST] <TheDrode> tIt takes a little while to load sir DHE [23:25:38 CEST] <TheDrode> https://anonymousfiles.io/5b9fLcOa/ [23:25:42 CEST] <TheDrode> The Video looks like this: [23:26:03 CEST] <TheDrode> and like this: https://anonymousfiles.io/RhiiUYUE/ [23:26:32 CEST] <TheDrode> i checked all the NICs, replaced them, just bought a more powerful CPU and still can't get it working [23:48:47 CEST] <kepstin> wow, what a terrible pastebin site. the show raw paste link takes you to an ubuntu login page :/ [23:54:11 CEST] <TheDrode> kepstin: sorry, will take my log to another site right now :D [23:56:02 CEST] <furq> could you run that with FFREPORT=level=24 ffmpeg ... instead of ffmpeg -report [23:56:12 CEST] <furq> so we don't have to wade through 85k lines of debug messages [23:57:44 CEST] <TheDrode> Sorry :D [23:59:54 CEST] <TheDrode> furq: this is what i get with level=24 [23:59:55 CEST] <TheDrode> https://paste.laravel.io/694c6ebe-307d-4853-b6d0-02062fb00af7 [00:00:00 CEST] --- Fri Aug 30 2019

1 0

ffmpeg-devel.log.20190801
by burek 29 Aug '19

29 Aug '19

[00:00:00 CEST] --- Thu Aug 1 2019 [02:26:25 CEST] <mkver> Does anybody know why h264_mp4toannexb parses IDR slices itself in order to detect whether this is the first slice of a new IDR picture? Is this a remnant from the age when the bsf api didn't use AVPackets? [02:46:44 CEST] <jamrial> mkver: it's possible. git blame for that line might help [02:48:20 CEST] <mkver> Has been introduced in bf428bb3145c4f0eef32f8ef00de0ee222b3e414; it has been done in order to support multiple IDR pictures directly after each other (so that all of them would get extradata). [02:49:30 CEST] <mkver> But why are these variables (new_idr, idr_sps_seen, idr_pps_seen) kept in the context at all? [02:50:08 CEST] <mkver> This would only make sense if one tries to support situations in which the input the bsf gets is not an access unit. [02:52:03 CEST] <mkver> (And the current implementation has interesting side effects: Think of something like ... PPS non-IDR pic IDR pic. The non-IDR pic will get a SPS, too, and the idr_s/pps_seen variables will be set to 1. Therefore the IDR pic won't get extradata even when it needs it. Have I already said that the naming of idr_s/pps_seen is suboptimal?) [03:04:27 CEST] <mkver> Did the old bitstream filter API actually send data from several packets at once or partial packets? Then everything would make sense. [03:10:14 CEST] <cmptr> The config.h include in fftools/ffmpeg.c, that is created when ./configure is ran, correct? [03:11:02 CEST] <cmptr> Or is it refering to compat/avisynth/avs/config.h? [03:17:02 CEST] <jamrial> the autogenerated by configure, yes [04:55:50 CEST] <tmm1> i'm trin gto figure out where in the vaapi encoding pipeline is the best place to extract AV_FRAME_DATA_A53_CC [11:12:25 CEST] <durandal_1707> kierank: Nicolas finally agrees with me in something! [13:26:09 CEST] <cone-231> ffmpeg 03Steven Liu 07master:46b97c0527ed: FATE: add hls single file mode test case [13:34:21 CEST] <kierank> durandal_1707: wow [15:01:58 CEST] <durandal_1707> some guy wrote much better prores encoder (ffmpeg binary provided with no source) [15:02:08 CEST] <durandal_1707> our both encoders sucks big time [15:04:52 CEST] <JEEB> durandal_1707: are you sure it's not just a wrapper over the apple stuff? I think they released something semi-recently? [15:13:23 CEST] <durandal_1707> JEEB: it appears to be proresenc_amcdx from same company and one ukraine guy [15:30:57 CEST] <durandal_1707> i have just edited apple prores wikipedia page, where it shits on open source decoder [15:59:50 CEST] <cehoyos> durandal_1707: Do you want me to test? [16:00:11 CEST] <durandal_1707> cehoyos: sure, it should be faster now [16:05:15 CEST] <cehoyos> Please point me to a sample input file [16:05:31 CEST] <durandal_1707> you removed old one? [16:06:32 CEST] <cehoyos> Isn't this now another codec? [16:06:38 CEST] <cehoyos> Sorry if I misunderstand... [16:07:01 CEST] <durandal_1707> cehoyos: no it is same, dsddec patch [16:07:35 CEST] <durandal_1707> dstdec is also there be its not worth comparing as its very slow in another code [16:07:50 CEST] <durandal_1707> http://www.lindberg.no/hires/test/2L-145/2L-145_mch_DSF_2822k_1b_01.dsf [16:08:00 CEST] <durandal_1707> that is file [16:08:22 CEST] <durandal_1707> 5.1 DSD 64 [16:09:44 CEST] <durandal_1707> and long dstdec files are not available that freely [17:04:18 CEST] <durandal_1707> kierank: please apply msrle patch if you can, it is very trivial [17:30:35 CEST] <durandal_1707> cehoyos: how it goes? [18:34:59 CEST] <cehoyos> Sorry for the delay: For two threads, time is a little slower, for six and more threads, it also gets slower, only for four threads do I see a small speed improvement, in all cases at the cost of a huge increase of cpu cycles [18:36:03 CEST] <cehoyos> Given that it's 17x realtime on a ppc core (which is much slower than an Intel core), I am not convinced this patch is worth the effort [18:36:10 CEST] <cehoyos> on one ppc core... [18:37:45 CEST] <durandal_1707> cehoyos: what? it gives better speed on old celeron cpu, on what hw have you tested it? [18:38:18 CEST] <durandal_1707> you need to look at speex= X report from ffmpeg [18:38:23 CEST] <durandal_1707> *speed [18:38:50 CEST] <cehoyos> Intel E3-1230 V2 and POWER7 altivec [18:39:04 CEST] <cehoyos> Thank you for explaining how to do an FFmpeg performance test... [18:40:08 CEST] <cehoyos> I don't think speed is the ideal testtool though: It doesn't tell you anything about the cost of the speedup. [18:40:47 CEST] <durandal_1707> this is not about cost of speedup, more about speedup alone [18:41:18 CEST] <cehoyos> You would accept a 10% speedup by default if it doubles cpu load? [18:41:35 CEST] <durandal_1707> it would not double cpu load [18:41:43 CEST] <cehoyos> No, it triples it;-) [18:42:27 CEST] <durandal_1707> use correct tool, and not time :) [18:42:50 CEST] <cehoyos> (for threads=2, cpu load gets doubled, but on both very different systems, decoding gets slower) [18:43:33 CEST] <durandal_1707> on which system decoding is slower? [18:44:13 CEST] <durandal_1707> i get 50% more speed on very shitty cpu [18:44:28 CEST] <durandal_1707> perhaps you test on even older hw [18:44:50 CEST] <durandal_1707> test with modern CPU if you can [18:46:09 CEST] <cehoyos> On both systems [18:49:56 CEST] <cehoyos> Which of the patches do I have to appy to do the tests? [18:50:42 CEST] <durandal11707> cehoyos: what you applied? [18:50:57 CEST] <cehoyos> I originally only tested 0002 [18:52:01 CEST] <durandal11707> cehoyos: from new thread? [18:52:26 CEST] <cehoyos> yes, I get different results than with the test I did last time [18:54:56 CEST] <cehoyos> Applying also the libavformat patch makes threads=4 also slower on my Intel [18:58:41 CEST] <durandal11707> cehoyos: what slower means exactly? [18:59:37 CEST] <durandal11707> libavformat patch should not make a difference at all, it just forces demuxer to set timestamp instead of ffmpeg [19:01:05 CEST] <cehoyos> 10-20% [19:01:19 CEST] <cehoyos> I thought the same, but I can reproduce the difference applying and reverting the lavf patch. [19:05:48 CEST] <durandal11707> cehoyos: how much RAM you have? [19:06:03 CEST] <cehoyos> infinite on ppc, 8G on Intel [19:06:21 CEST] <cehoyos> no, only 64G [19:06:36 CEST] <cehoyos> (The other ppc systems have much more iirc) [19:07:16 CEST] <cehoyos> maxrss reports 12M iiuc [19:07:28 CEST] <cehoyos> 20 on ppc [19:10:23 CEST] <cone-868> ffmpeg 03Andriy Gelman 07master:f60b1211b2aa: lavfi/zmq: Avoid mem copy past the end of input buffer [19:11:02 CEST] <durandal11707> whats up with fflogger, its in very poor state [19:11:45 CEST] <durandal11707> cehoyos: the demuxer behaves strangely, -f null - is more slow than -f framecrc -, which is illogical [19:13:11 CEST] <cehoyos> I used crc for my tests [19:13:22 CEST] <cehoyos> As said, this is just not worth your valuable time [19:15:21 CEST] <durandal11707> i strongly disagree [19:16:14 CEST] <durandal11707> with dsf patch disabled its approx same speed [19:16:54 CEST] <cehoyos> What does "dsf patch disabled" mean? [19:17:43 CEST] <durandal11707> reverted [19:18:14 CEST] <durandal11707> on this shitty CPU ffmpeg ld on ffmpeg takes eons [19:19:10 CEST] <durandal11707> also in my case using more threads does not hurt much [19:19:47 CEST] <cehoyos> You mean since you only have two cores, the cpu load is never bigger than twice the cpu load with threads=1 ? [19:29:43 CEST] <durandal11707> cehoyos: test with -vn [19:29:56 CEST] <cehoyos> I used -vn for all tests (did not test without it) [19:32:05 CEST] <durandal11707> cehoyos: what speed up you get with flac decoding? [19:32:19 CEST] <durandal11707> using threads 1 and more? [19:34:57 CEST] <durandal11707> i wonder how that dsfdec libavformat patch could slow down things for you? previously it would pick wrong 90k TB [19:35:08 CEST] <durandal11707> now it picks correct one [19:39:45 CEST] <durandal11707> cehoyos: what you think is useful load, is max possible load from multithreading, that is scales exactly with number of cores, linearly - thats never possible [19:44:20 CEST] <nevcairiel> 90% per core up to number of channels might be reasonable [19:49:30 CEST] <durandal11707> isn't his CPU older than mine anyway? [19:49:37 CEST] <cehoyos> I can only say that the current patch shows no clear speedup at very high costs, I have to leave soon and will not be able to test until Wednesday [19:51:21 CEST] <durandal11707> cehoyos: if you see no gain there, do you see at least gain with frame decoding and flac? [19:51:53 CEST] <durandal11707> or any other threading feature in whole ffmpeg codebase? [19:52:36 CEST] <durandal11707> because if not, your cpus are ready for recycle [19:56:37 CEST] <durandal11707> who have modern CPU generation? [19:59:55 CEST] <durandal11707> nobody? what a shame... [20:04:34 CEST] <durandal11707> looks like nobody gives shit about DSD, and patches in general [20:05:52 CEST] <cehoyos> I can test current cpus next week but I doubt that the results will be completely different [20:07:28 CEST] <cehoyos> I seee a *massive [20:07:48 CEST] <cehoyos> I seee a *massive* speedup with multi-threaded flac decoding, it may even scale [20:12:48 CEST] <cehoyos> bye [20:26:28 CEST] <Lynne> >a graph would merge the L/R to build a dolbyE stream that the filter could decode [20:27:10 CEST] <Lynne> next up: base64 encoding! in umm, old binary excel documents! sent as attamchments to a special email server [20:28:50 CEST] <Lynne> but its fine, its standardized. besides, everyone can easily hook in an excel decoder in their pipeline [20:28:50 CEST] <durandal_1707> i will pay 100$ for someone to test patches on modern CPU [20:29:09 CEST] <Lynne> are you that desparate? send me a sample [20:29:12 CEST] <J_Darnley> Oh money? [20:29:26 CEST] <J_Darnley> I have a Ryzen 2200 I can use [20:29:54 CEST] <durandal_1707> i will pay only if i get positive results :) [20:30:25 CEST] <durandal_1707> Lynne: what CPU do you have? [20:32:12 CEST] <Lynne> core i7 6600 [20:49:55 CEST] <BradleyS> i can probably test intel e5 in the coming days [20:53:12 CEST] <rcombs> durandal_1707: wonder if you'd get better improvements with SIMD [20:53:47 CEST] <nevcairiel> dsd is hard to impossible to simd, every single bit depends on the one before it [20:54:36 CEST] <nevcairiel> the only hope is that channel are entirely independent, so you could thread them, but apparently no scaling [20:54:57 CEST] <rcombs> yeah, I meant on channels [20:56:00 CEST] <durandal_1707> there is scaling, ignore cehoyos and 5year old cpus [20:56:25 CEST] <nevcairiel> 5 year old CPUs are still quite similar to those today, stuff hasnt moved much =p [20:57:04 CEST] <durandal_1707> yes, thats why get with 2 cores, %50 speedup [20:58:52 CEST] <J_Darnley> Is this the DSD patch(es) you're testing? If so where can I get a reasonable length file to decode? [20:59:06 CEST] <Lynne> durandal_1707: 1 thread - 53x realtime, 2 threads - 59x realtime, 4 threads - 47x realtime [20:59:24 CEST] <Lynne> for the long dsf file [20:59:26 CEST] <durandal_1707> J_Darnley: or any from last column links: http://www.2l.no/hires/index.html [21:00:13 CEST] <durandal_1707> Lynne: huh, how many cores is that? [21:00:56 CEST] <Lynne> 2 cores, 4 threads [21:02:03 CEST] <durandal_1707> well, in my case, main issue was that other channels/jobs would get misaligned buf[] [21:02:53 CEST] <durandal_1707> perhaps they are still not aligned properly, causing unaligned access [21:03:24 CEST] <Lynne> could always make it output planar, I think [21:03:38 CEST] <nevcairiel> definitely use planar for threading [21:04:00 CEST] <durandal_1707> planar? [21:04:15 CEST] <nevcairiel> one seperate buf for each channel [21:04:21 CEST] <J_Darnley> like video [21:04:33 CEST] <durandal_1707> and not DECLARE_ALIGNED ? [21:04:53 CEST] <J_Darnley> make -sj4 [21:05:03 CEST] <nevcairiel> buffers are always aligned [21:05:25 CEST] <nevcairiel> apparently dsddec already uses FLTP tho [21:05:49 CEST] <durandal_1707> i'm talking about buf in dsd2pcm [21:06:21 CEST] <durandal_1707> its buf[16]* number of channels [21:08:00 CEST] <durandal_1707> actually i forgot there is unsigned pos after buf, causing misaligned access, DECLARE_ALIGNED fixed it to me [21:08:24 CEST] <durandal_1707> but perhaps that is not good fix [21:08:47 CEST] <durandal_1707> because 4 threads should decode faster for 6ch file [21:43:12 CEST] <J_Darnley> oh bloody hell, why does -benchmark use av_log? [21:45:50 CEST] <jamrial> what did you want it to do instead? [21:45:56 CEST] <J_Darnley> printdf [21:46:02 CEST] <J_Darnley> *printf [21:47:45 CEST] <jamrial> that's the default for av_log [21:48:30 CEST] <J_Darnley> yeah, but I can't do -loglevel quiet and -benchmark [21:57:11 CEST] <J_Darnley> Oh well he left. [21:57:24 CEST] <J_Darnley> Anyway I get sppeds of 74 [21:57:28 CEST] <J_Darnley> .uh [21:57:51 CEST] <J_Darnley> Anyway I get speeds of 74.1 101.7 120.4 128.4 [21:59:20 CEST] <J_Darnley> thread counts 1-4 [22:43:14 CEST] <extrowerk> Hi Guys, i am with the HaikjuPorts team here. [22:44:29 CEST] <extrowerk> We have an annoying bug with the Haiku's MediaPlayer, it crashing randomly at opening mjusic files with embedded cover art. As MediaPlayer based on ffmpeg, i came here to ask: is it possible to disable the cover-art support at compile time? [22:44:50 CEST] <J_Darnley> no [22:45:12 CEST] <J_Darnley> the files will present you with a video stream [22:45:17 CEST] <extrowerk> MediaPlayer doesn't handles it correctly, and as i can't fix it (well over my skills), i tojught maybe it would be possible to just disable it. [22:46:16 CEST] <J_Darnley> It is a poor design choice to represent this binary data attachment as a stream of any sort. [22:47:26 CEST] <J_Darnley> But that choice was made an now we must all suffer with it [22:47:40 CEST] <extrowerk> J_Darnley: yep, i know it is a video stream, in some case MediaPlayer handles it well, like in this case: http://0x0.st/zfG4.png [22:48:05 CEST] <J_Darnley> If this is a *music* player then maybe you can disable all the video codecs. [22:48:21 CEST] <extrowerk> but in many othjer cases it just crashes. Stripping the cover art solves the problem, so we are almost sure, thje cujlprit is the embedded cover art. [22:48:39 CEST] <extrowerk> So there is no way to disable it? [22:48:53 CEST] <J_Darnley> If you have an example file, try decoding it with ffmpeg and see if it crashes [22:49:00 CEST] <J_Darnley> maybe there's just a bug [22:49:54 CEST] <extrowerk> every other ffmpeg based player plays it just fine, just MediaPlayer crashes, so it is a known and acknowledged bug in Haikju's MediaPlayer, but currently nobody got time to fix it, and i have not enough skills to do it. [22:50:26 CEST] <extrowerk> but i can build ffmpeg and try to disable it, so we can fix the MediaPlayer code later... [22:50:32 CEST] <extrowerk> at least thats my plan [22:50:43 CEST] <J_Darnley> oh okay [22:53:06 CEST] <extrowerk> Does ffmpeg uses libid3tag for the cover art? [22:54:39 CEST] <J_Darnley> almost certainly not [22:54:52 CEST] <kepstin> no, ffmpeg's mp3 & id3 reader don't use external libraries. [22:55:19 CEST] <kepstin> does this only affect mp3 files? or multiple file formats? [22:55:58 CEST] <extrowerk> i have seen crashes only with mp3 diles so far [22:56:04 CEST] <extrowerk> *files [22:56:46 CEST] <extrowerk> here is an example crashlog: http://0x0.st/zfGm.report [23:00:01 CEST] <J_Darnley> _DecodeVideodoesn't look like one of our functions [23:00:37 CEST] <extrowerk> i can't give you more info sadly. [23:00:58 CEST] <J_Darnley> How about the source code of the player? Is that public somewhere? [23:02:56 CEST] <extrowerk> yes, of course [23:03:19 CEST] <extrowerk> https://github.com/haiku/haiku/tree/master/src/apps/mediaplayer [23:10:09 CEST] <J_Darnley> :vs [23:17:54 CEST] <J_Darnley> "This function MUST be called after _DeinterlaceAndColorConvertVideoFrame()" [23:18:10 CEST] <J_Darnley> look, it's being called before [23:18:51 CEST] <J_Darnley> no my bad, wonf function [23:20:59 CEST] <J_Darnley> No actually, do have a look at _HandleNewVideoFrameAndUpdateSystemState [23:23:37 CEST] <J_Darnley> but I don't see what that only breaks covers [23:24:59 CEST] <J_Darnley> *why that [23:26:32 CEST] <extrowerk> J_Darnley: as i stated before i am not in the shape to fix it, but thjanks for looking it, your finding is noted. [23:26:46 CEST] <J_Darnley> you're welcome [23:27:07 CEST] <J_Darnley> sorry I couldn't give you what you're looking for [23:27:59 CEST] <extrowerk> maybe i will just write a bash script to strip all the cover arts. [23:28:08 CEST] <extrowerk> the problem is, i like them showing up nicely. [23:28:21 CEST] <extrowerk> so, yeah, i still have to use mpd on haiku :( [23:28:37 CEST] <extrowerk> that doesn't have this problem :) [23:28:49 CEST] <J_Darnley> My argument is that there should be 1 file (cover.jpg or similar) in the directory [23:29:14 CEST] <J_Darnley> folder.jpg if you're on Windows [23:46:21 CEST] <extrowerk> J_Darnley: thanks again. [23:46:26 CEST] <extrowerk> good night andbye! [23:47:54 CEST] <J_Darnley> good night [00:00:00 CEST] --- Fri Aug 2 2019

1 0

ffmpeg-devel.log.20190722
by burek 29 Aug '19

29 Aug '19

[04:48:13 CEST] <cone-735> ffmpeg 03Leo Zhang 07master:116303cd2451: avformat/dashenc: add descriptor which is useful to the scheme defined by ISO/IEC 23009-1:2014/Amd.2:2015. [05:32:09 CEST] <dastan> are someone online? [06:42:07 CEST] <dastan> i make all the compilation for qsv [06:42:20 CEST] <dastan> but the decoder doesent appear [06:42:27 CEST] <dastan> very frustrating [08:27:04 CEST] <Compn> dastan, : ask in #ffmpeg [08:27:31 CEST] <dastan> already made [08:58:17 CEST] <Compn> durandal_1707, going to backport flash filter to 4.2 ? [08:58:28 CEST] <Compn> i might have to write up something for changelog hmm [08:58:52 CEST] <durandal_1707> filter was not approved by michaelni [09:00:50 CEST] <durandal_1707> vel0city: please concat me via e-mail if you have some questions or want to report something [09:01:23 CEST] <cone-735> ffmpeg 03Matthieu Bouron 07master:6251ad89a775: avcodec/mediacodec_wrapper: add missing "avcodec.h" include [09:01:24 CEST] <vel0city> @durandal_1707: ok, will do [09:01:24 CEST] <cone-735> ffmpeg 03Matthieu Bouron 07master:9cb8875c165e: avcodec/mediacodec_wrapper: fix a local reference leak in ff_AMediaCodec_getName() [09:01:25 CEST] <cone-735> ffmpeg 03Matthieu Bouron 07master:3f232d713db3: avcodec/mediacodec_wrapper: fix a potential local reference leak in ff_AMediaCodec_getCodecNameByType() [09:01:26 CEST] <cone-735> ffmpeg 03Matthieu Bouron 07master:817235b195f5: avcodec/mediacodec_wrapper: remove unused local variables in ff_AMediaCodec_getCodecNameByType() [09:05:26 CEST] <durandal_1707> whats status of fflogger, it is not sending new logs to web? [15:21:53 CEST] <jdarnley> I know there are a few scripts under the hood of the fate tests but maybe someone can answer this anyway... [15:23:21 CEST] <jdarnley> Do the tests actually look like "target: source" rules/recipes to Make? [15:37:05 CEST] <thilo> IIRC yes, next to make fate you can call make <test>, if that is what you mean [15:38:21 CEST] <jdarnley> sort of [15:38:45 CEST] <jdarnley> ... [15:39:08 CEST] <jdarnley> fate-specific-test isn't any of the filename involved though [15:41:33 CEST] <jdarnley> Does Make see a rule like "%.o: %.c" for the fate tests? Or are they only aliases and the scripts handle the filenames? [15:46:37 CEST] <thilo> concrete targets usually, compare to some patch adding test cases, like "[PATCH] fate: add hls_list_size fate test case" from steven as of July 2nd [15:59:25 CEST] <jdarnley> i see [15:59:48 CEST] <jdarnley> now I need to lookup what that pipe symbol means to make [16:00:33 CEST] <jdarnley> "TARGETS : NORMAL-PREREQUISITES | ORDER-ONLY-PREREQUISITES" [16:01:04 CEST] <thilo> are you adding a target or do you want to tweak fate? [16:01:46 CEST] <jdarnley> I am creating something a little similar but a lot smaller for another project. [16:02:48 CEST] <thilo> ok [16:03:07 CEST] <jdarnley> yeah, sorry to steal brain power like that [16:03:58 CEST] <thilo> nah, I hope you've checked some new fancy CI tools before writing scripts/makefiles yourself - that might reduce your brain power needed ;) [16:04:15 CEST] <jdarnley> no [16:04:33 CEST] <thilo> that's the most fun way then ;) [16:04:51 CEST] <jdarnley> most of those seem to be centered around web dev stuff that you can pull in over git [16:05:53 CEST] <thilo> you might want to checkout videolans CI [16:09:19 CEST] <jdarnley> An order-only prerequesite doesn't cause targets to be updated if it is newer. [16:11:33 CEST] <thilo> no in depth knowledge about Make magic here [16:32:32 CEST] <jdarnley> oh fuck you cloudflare [16:32:45 CEST] <jdarnley> fuck you and your [email protected] garbage [16:37:36 CEST] <thardin> indeed [17:01:28 CEST] <jdarnley> I bashed a makefile into the right shape. I needed to think about its pattern matching in more detail and then use $(subst tests/cmp,tests/ref,$@) [19:18:04 CEST] <cone-069> ffmpeg 03Gyan Doshi 07master:d51d71c1e3a6: avformat/mov: fix return code for trun box with no sample entries [20:25:16 CEST] <durandal_1707> fflogger is not working correctly [22:18:00 CEST] <cone-069> ffmpeg 03Baptiste Coudurier 07master:9e24b98b15cb: avformat/mxfenc: fix index byte count in partition header [23:11:01 CEST] <cone-069> ffmpeg 03Limin Wang 07master:53462cea2f2a: avformat/f_select: support scenecut with more pixel formats [23:11:02 CEST] <cone-069> ffmpeg 03Limin Wang 07master:d75c7dd45edf: fate: change the scenecut fate threshold [23:11:03 CEST] <cone-069> ffmpeg 03Limin Wang 07master:b696caba1a6a: avformat/f_select: add support for more pixel formats for scene change score calculations [23:28:07 CEST] <cone-069> ffmpeg 03Baptiste Coudurier 07release/4.2:c60e1d6be5a3: avformat/mxfenc: fix index byte count in partition header [23:59:20 CEST] <cone-069> ffmpeg 03Paul B Mahol 07master:3883c9d1479d: avfilter/vf_ciescope: add DCI-P3 [00:00:00 CEST] --- Tue Jul 23 2019

1 0

ffmpeg-devel.log.20190726
by burek 29 Aug '19

29 Aug '19

[03:50:40 CEST] <cone-611> ffmpeg 03Jun Zhao 07master:606be4cb503a: lavf/hls: remove redundancy reset_packet() after av_packet_unref() [03:50:40 CEST] <cone-611> ffmpeg 03vacingfang 07master:d83a3117e2f0: lavf/hls: replace the same code logic with ensure_playlist() [08:39:30 CEST] <cone-393> ffmpeg 03Matt Wolenetz 07master:052d41377a02: lafv/wavdec: Fail bext parsing on incomplete reads [09:58:09 CEST] <vel0city> when I revise a patchset's commit (not all of them), do I need to update the patch revision in the subject (ie. "PATCH v4") annd send a new email for all of the commits? or can I only send the one I changed? [09:58:38 CEST] <vel0city> I don't mind, but I think it's a bit spammy if I have to re-send all of them every time [09:59:20 CEST] <vel0city> also it makes the threads on Gmail more confusing [10:39:21 CEST] <durandal_1707> vel0city: we love spam [10:41:19 CEST] <vel0city> hehe [10:59:34 CEST] <whiteboard> Hi ! I am working with h.264 and .mp4. Is it feasible to modify ffmpeg or a decoder so that It would be able to extract data from SEI messages (previously inserted by a bsf filter) and forward it to a vf filter ? [11:00:36 CEST] <JEEB> we have already some parsing like that, which then adds side data to avpackets/frames [11:00:52 CEST] <JEEB> so definitely possible if you put the correct parser after your bsf [11:05:43 CEST] <nevcairiel> that seems like a dumb method if you can just make the bsf set side data in the first place [11:05:50 CEST] <JEEB> yes [11:05:56 CEST] <JEEB> I just didn't remember if BSFs can set that [11:06:05 CEST] <JEEB> if the BSF can do it should definitely do it itself :P [11:10:29 CEST] <whiteboard> The main problem I am facing is that I am not able to send anything "from a bsf filter to a vf filter" because bsf filters are applied after having "reencoded vf filtered" frames. [11:16:31 CEST] <whiteboard> Even if a bsf could set side data before a vf filter using it, the two filters must be chained in one operation since side data are not stored in the encoded video stream. [11:21:49 CEST] <durandal_1707> Lynne: i'm working on rnnoise filter [11:22:56 CEST] <nevcairiel> side data by definition is not meant to be stored in the encoded video stream, thats why its side data [11:23:15 CEST] <nevcairiel> its a seperate stream of data that sits in parallel of the main video data [11:23:51 CEST] <nevcairiel> and it can be passed all the way through the entire chain if one wanted that [11:25:59 CEST] <whiteboard> Is this data stream stored in the outputed .mp4 ? [11:27:29 CEST] <nevcairiel> not usually, no. [11:27:48 CEST] <nevcairiel> although it can be if the muxer knows how to do that [11:27:51 CEST] <nevcairiel> some types are [11:31:16 CEST] <whiteboard> If we chain mutliple filters, I agree that the side data could be accessed/modifed through the entire chain but not in the order I need. VF filters are applied before bsf filters, therefore, I cannot make use of results from a bsf filter in a vf filter. [11:34:02 CEST] <nevcairiel> that doesnt even make any sense. your first suggestion was to use a bsf filter to write data to SEIs and then have the decoder pull that out again, but if BSFs run too late, how does that even make sense then [11:34:46 CEST] <nevcairiel> there its two spots a BSF can run, either before the decoder, or after the encoder, since they run on encoded bitstreams [11:35:30 CEST] <whiteboard> You're right, how can I make it run before the decoder ? [11:38:01 CEST] <whiteboard> Writing data to SEIs was an idea to persistently store the side data, that I could recover in the "second run". [11:40:45 CEST] <JEEB> not sure how easy it is with ffmpeg.c if that's what you mean [11:41:34 CEST] <rcombs> whiteboard: what data are you trying to transmit anyway [11:41:53 CEST] <rcombs> like, where is your data coming from, what's in it, where are you trying to get it to, and why [11:43:31 CEST] <nevcairiel> typically the pre-decoding BSFs are defined by the decoder itself, dont think we have the ability to let users add any [11:47:04 CEST] <whiteboard> My idea is to have a bsf filter (1) inserting encrypted data in SEI (working), stream this to another device which applies bsf filter (2) recovering/decrypting/processing the data from SEI (working) and now, I want to draw something on the frames according to the result of processed data in filter (2). The data could simply be an array of uint8_t. [11:47:56 CEST] <whiteboard> Is my explanation clear enough to visualize the challenge ? [11:49:13 CEST] <rcombs> whiteboard: yeah I still don't know what this data actually is or why you're trying to transmit it this way [11:52:49 CEST] <whiteboard> "why you're trying to transmit it this way", which way do you mean ? Because I haven't decided yet which way could work to do this : sending the results (unint8_t*) of bsf filter (2) to a vf filter. [12:57:57 CEST] <cone-074> ffmpeg 03Paul B Mahol 07master:f79873409b05: avcodec/adpcm: add support for 5.1 ADPCM MS [12:57:57 CEST] <cone-074> ffmpeg 03Paul B Mahol 07master:ebfcd4be3302: avcodec/adpcm: reindent after last commit [13:37:09 CEST] <Lynne> durandal_1707: keep in mind the last person to work on it did some modifications, some of which did get upstreamed, so you should probably use that repo [15:05:49 CEST] <durandal_1707> NGA going open source? [15:43:45 CEST] <kierank> durandal_1707: what is nga? [16:13:17 CEST] <durandal_1707> next gen audio [16:30:50 CEST] <kierank> durandal_1707: won't be open source [16:30:57 CEST] <kierank> d*lby and d*s don't do that [16:35:48 CEST] <durandal_1707> kierank: but on twitter it said it gonna be itu [16:36:03 CEST] <kierank> durandal_1707: it will describe maybe the properties of NGA [16:36:06 CEST] <kierank> but not the codec itself [16:40:38 CEST] <Lynne> "There are three standardised solutions for NGA: MPEG-H Audio, AC-4 and DTS-UHD." [16:47:18 CEST] <kierank> durandal_1707: https://www.etsi.org/deliver/etsi_ts/103400_103499/103491/01.01.01_60/ts_10… [16:47:36 CEST] <kierank> eugh specification with copy paste from c++ [16:50:03 CEST] <thardin> also using different names for established concepts [16:50:13 CEST] <thardin> CountBitsSet_to_1() instead of popcount() [16:50:30 CEST] <thardin> wait there are classes in the spec? rrrrrr [17:00:17 CEST] <JEEB> lol [17:38:11 CEST] <durandal_1707> there will be ITU-R implementation of something IIUC [17:38:53 CEST] <kierank> durandal_1707: email andy quested and ask him [17:49:50 CEST] <durandal_1707> i dunno his email [17:51:02 CEST] <durandal_1707> where to store rnn model files? [17:53:56 CEST] <Lynne> they weren't that big, right? [18:01:58 CEST] <durandal_1707> Lynne: there is policy to not ship stuff that cant be reproduced [18:05:05 CEST] <durandal_1707> and they together take up to 1MB [18:06:33 CEST] <Lynne> oh well [18:06:58 CEST] <Lynne> what samplerates and formats did it support? wasn't it 16k 8bit only [18:07:32 CEST] <durandal_1707> no, 48k float [18:09:31 CEST] <cone-584> ffmpeg 03Guo, Yejun 07master:1b9064e3f4ca: libavfilter/dnn: move dnn files from libavfilter to libavfilter/dnn [18:30:40 CEST] <cone-584> ffmpeg 03Matthieu Bouron 07release/4.2:65434823a1ee: avcodec/mediacodec_wrapper: add missing "avcodec.h" include [18:30:41 CEST] <cone-584> ffmpeg 03Matthieu Bouron 07release/4.2:a3d986ff47b1: avcodec/mediacodec_wrapper: fix a local reference leak in ff_AMediaCodec_getName() [18:30:42 CEST] <cone-584> ffmpeg 03Matthieu Bouron 07release/4.2:3abec7f39735: avcodec/mediacodec_wrapper: fix a potential local reference leak in ff_AMediaCodec_getCodecNameByType() [18:30:43 CEST] <cone-584> ffmpeg 03Matthieu Bouron 07release/4.2:1df4a99e892f: avcodec/mediacodec_wrapper: remove unused local variables in ff_AMediaCodec_getCodecNameByType() [19:49:30 CEST] <durandal_1707> peak of life: helping leader to apply fuzzer patches by giving approval to leader patches [19:50:02 CEST] <durandal_1707> we are america [19:50:14 CEST] <kierank> durandal_1707: you trolling me? [19:52:21 CEST] <durandal_1707> kierank: not trolling you, i'm talking about myself, if you found yourself in those words its your problem, not mine [19:52:33 CEST] <kierank> 18:49:20 <kierank> Daemon404: we are becoming america [19:52:33 CEST] <kierank> 18:49:23 <kierank> it's that simple [19:52:33 CEST] <kierank> 18:49:29 <kierank> trumpville lite [19:52:33 CEST] <kierank> 18:50:40 <Daemon404> correct [19:52:42 CEST] <kierank> literally 40 seconds difference compared to #videolan [19:53:07 CEST] <durandal_1707> its just coincidence that GB is behaving like that [19:53:56 CEST] <durandal_1707> actually, i just stoled your idea, sorry! [19:54:13 CEST] <kierank> durandal_1707: will you be like trump when you are leader of ffmpeg [19:54:32 CEST] <durandal_1707> yes, because we are now more like putin [19:55:22 CEST] <durandal_1707> actually, when i think better, it will not be like trump/boris at all [19:56:12 CEST] <durandal_1707> there will not be leader at all, just high council [19:57:04 CEST] <kierank> who will lead high council [19:59:33 CEST] <durandal_1707> high council will be led by high council [20:40:27 CEST] <kierank> durandal_1707: it will be called FFmpegX [20:40:37 CEST] <kierank> you can be Paul B Musk [20:52:31 CEST] <durandal_1707> i'm afraid FFmpegX is already taken [20:53:53 CEST] <kierank> FFmpegY [20:56:13 CEST] <durandal_1707> XXXmpeg [21:14:13 CEST] <durandal_1707> the bayer format in cineform is just gray12[4] [21:14:36 CEST] <durandal_1707> meaning we need planar bayer formats [21:19:02 CEST] <durandal_1707> another approach is decoding it in current bayer format, but at 2x width and 2x height [21:19:26 CEST] <durandal_1707> which could be quite slow [21:19:40 CEST] <durandal_1707> what you devs think? [21:20:53 CEST] <durandal_1707> DING! DONG! [21:30:14 CEST] <kierank> I hate bayer [21:30:16 CEST] <kierank> It's that simple [21:36:40 CEST] <durandal_1707> kierank: grow up, bayer is your bright future [21:37:04 CEST] <kierank> It is out of scope for FFmpeg [21:37:09 CEST] <durandal_1707> lies [21:37:12 CEST] <durandal_1707> stop lying [21:37:16 CEST] <kierank> There are too many subjective things when processing it [21:37:30 CEST] <kierank> Which are creative not technical [21:37:47 CEST] <durandal_1707> i'm not talking about bayer conversion [21:37:57 CEST] <kierank> Yes but it will happen [21:38:02 CEST] <kierank> Slippery slope [21:38:05 CEST] <durandal_1707> but about support of decoding of bayer [21:38:14 CEST] <durandal_1707> no no no no no no no no no no [21:38:14 CEST] <kierank> How to view it? [21:38:36 CEST] <kierank> Got to decode it to format that pc can view [21:38:45 CEST] <kierank> -> processing [21:38:46 CEST] <durandal_1707> drop one plane, and merge others into rgb [21:43:54 CEST] <kierank> Pfft [21:50:22 CEST] <durandal_1707> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c [21:50:22 CEST] <durandal_1707> index 49a5a2c30a..5c4a2436c0 100644 [21:50:22 CEST] <durandal_1707> --- a/libavcodec/cfhd.c [21:50:22 CEST] <durandal_1707> +++ b/libavcodec/cfhd.c [21:50:22 CEST] <durandal_1707> @@ -521,6 +521,8 @@ static int cfhd_decode(AVCodecContext *avctx, void *data, int *got_frame, av_log(avctx, AV_LOG_DEBUG, "Sample format? %i\n", data); [21:50:25 CEST] <durandal_1707> if (data == 1) [21:50:28 CEST] <durandal_1707> s->coded_format = AV_PIX_FMT_YUV422P10; [21:50:30 CEST] <durandal_1707> + else if (data == 2) [21:50:33 CEST] <durandal_1707> + s->coded_format = AV_PIX_FMT_GBRAP12; [21:50:35 CEST] <durandal_1707> else if (data == 3) [21:50:38 CEST] <durandal_1707> s->coded_format = AV_PIX_FMT_GBRP12; [21:50:41 CEST] <durandal_1707> else if (data == 4) [22:17:21 CEST] <Compn> xxxmpeg :D [22:17:33 CEST] <Compn> durandal_1707, : we need bayer for r3d camera i think ;P [22:32:34 CEST] <kierank> durandal_1707: honestly I think that is an ugly hack [22:36:03 CEST] <durandal_1707> kierank: so i will add planar bayer format [22:37:15 CEST] <kierank> both are bad [22:37:15 CEST] <kierank> first one is least worst [22:43:15 CEST] <durandal_1707> kierank: actually i will not, the components are not stored raw, they are like ycocg [22:44:14 CEST] <durandal_1707> so i will use temp frame to decode with GBRAP pixel format and than use BAYER to put it back into one big frame [23:03:15 CEST] <tmatth> is it normal that the checksum for fresh downloads of ffmpeg-4.1.4.tar.gz seems to be changing on me, or is it just too hot for me to thing straight? [23:04:09 CEST] <JEEB> actual release tarball hashes should not be changing. the ones generated by gitweb *might* change (or ones generated by github if you're trying that way) [23:09:58 CEST] <tmatth> JEEB: yeah, i've never had this issue before (and i'm getting it from http://ffmpeg.org/releases/) [00:00:00 CEST] --- Sat Jul 27 2019

1 0

ffmpeg-devel.log.20190828
by burek 29 Aug '19

29 Aug '19

[01:12:25 CEST] <cone-544> ffmpeg 03James Almer 07release/4.2:c1dc4d2d501c: avcodec/h2645_parse: zero initialize the rbsp buffer [03:33:26 CEST] <cone-544> ffmpeg 03OvchinnikovDmitrii 07master:f8ad2ddd7a51: libavcodec/amfenc: Vulkan initialization support for encoder. [09:18:01 CEST] <JEEB> wbs: so for current end point of a track in movenc: is it track->end_pts or (track->start_dts + track->duration) ? I seem to have utilized the first one first, but now I've got at least one case where latter seems to be the correct value :) [09:18:48 CEST] <JEEB> right now for testing I've got FFMAX between those two, but I wonder if I can just use the latter [09:37:10 CEST] <wbs> JEEB: it's been a few years since I've touched that, but I think start_dts + duration is the one used for fragment stuff [09:37:39 CEST] <wbs> as pts is just done with offsets on top of the dts, but dts is used for building the structure of the fragments etc [09:41:15 CEST] <JEEB> yea [09:42:23 CEST] <JEEB> not sure why on a subtitle track those two weren't the same here (will still have to re-check), but the start_dts + duration seemed to give the correct value [09:42:52 CEST] <JEEB> this is mostly utilized when a padding packet has to be generated and thus the start of it is at the end of the previous fragment :) [09:45:12 CEST] <JEEB> here's what the monstrocity currently looks without/with fragmentation from the debug logs I'm currently keeping: http://up-cat.net/p/6bf94b85 http://up-cat.net/p/d8fc4f9e [09:45:31 CEST] <JEEB> will have to polish this up a bit and then should be ready for initial reviews [09:47:51 CEST] <wbs> sorry, might look later. no time and not enough attention at the moment [09:48:12 CEST] <JEEB> yea, it's OK :) that's just logs [09:48:25 CEST] <JEEB> to see how stupid some of that whole queueing business is [09:48:40 CEST] <JEEB> (but since the spec wants squashing there's not much more you can do) [11:11:51 CEST] <mostynb> i wonder if patches that add SPDX license identifiers would be accepted, to make automated license checking simpler? an example source file comment would look like this (in whichever commenting style is already used in a given file): // SPDX-License-Identifier: LGPL-2.1-or-later [11:16:30 CEST] <JEEB> mostynb: I think it'd mostly depend on where those would be useful [11:16:48 CEST] <JEEB> we already have the license at the top of most files where fuzzy logic can grab it [11:18:43 CEST] <mostynb> JEEB: the actual license is good for humans (well, sorta) but not so good for automated license checking tools [11:19:21 CEST] <JEEB> sure [11:19:44 CEST] <mostynb> for example if you wanted to get a list of all the GPL files in ffmpeg, a line like this would make this really easy to do [11:20:43 CEST] <rcombs> that's already not especially difficult, since they all have a pretty distinct chunk of, well, GPL at the top [11:21:39 CEST] <nevcairiel> in fact we have a test that ensures that license headers are consistent, so it would be possible to use a tool for th at, even if slightly more wordy then the header string [11:22:29 CEST] <JEEB> yea [11:22:40 CEST] <mostynb> rcombs: being consistent is difficult, especially with automated tools. there are several variations of licenses, formatting can be different, comment style can be different, there can be additional exceptions added etc etc [11:23:03 CEST] <mostynb> these SPDX headers are a standardised effort to make this easier [11:24:37 CEST] <rcombs> BtbN: could you test to see if it works with a 32-bit build for you [11:24:39 CEST] <mostynb> nevcairiel: such a tool would be ffmpeg-specific though, and therefore less likely to be used [11:25:20 CEST] <BtbN> rcombs, I'll need to get a 32bit cross toolchain, and can't use WSL for that. So yes, but it might take a moment. [11:25:46 CEST] <rcombs> I'm building with a 32-bit install of msys2 [11:25:58 CEST] <rcombs> (and do the 64-bit build with a 64-bit install) [11:26:05 CEST] <BtbN> But yes, due to the limited address space with 32bit applications, the CUDA CUdevptr Unified Memory stuff is VERY limited [11:26:27 CEST] <BtbN> I can totally see it running out of mappable address space rather quickly [11:26:59 CEST] <rcombs> it looks like my 64-bit issues were due to something dopey on my end around logging (not entirely sure what but it only happens at -v trace so w/e), but I'm still seeing the crash in 32-bit [11:28:34 CEST] <rcombs> I'm seeing this crash just with 720p after 2 frames, that seems at least a _bit_ quick [11:29:20 CEST] <BtbN> There is only a few 100MB of mappable address space with 32bit [11:30:23 CEST] <BtbN> Also, from Nvidias docs: "Deployment and execution of CUDA applications on x86_32 is still supported, but is limited to use with GeForce GPUs." [11:30:33 CEST] <BtbN> https://docs.nvidia.com/cuda/cuda-installation-guide-microsoft-windows/inde… [11:31:03 CEST] <BtbN> So your "Operation not supported" might very well be the driver telling you to go use 64bit on your Quadro [11:31:25 CEST] <BtbN> Or "Not Implemented" or what it was [11:32:29 CEST] <rcombs> I was getting that on 64-bit [11:32:36 CEST] <rcombs> the 32-bit build crashes [11:32:52 CEST] <rcombs> but hmm, I _do_ only see the crash when I have a cuda filter in the chain [11:36:12 CEST] <rcombs> I guess I'll look into shipping a 64-bit build; it's just a massive PITA on windows for a whole bunch of reasons [11:36:32 CEST] <rcombs> like the user having to select which version they want, installer/updater stuff, upgrade path& [11:37:11 CEST] <mostynb> nevcairiel: where can i find the license consistency test that you mentioned? [14:08:16 CEST] <BtbN> philipl, I wonder if we should revive atomnukers old Vulken hwcontext stuff? [14:08:33 CEST] <BtbN> It might be worthwhile to have it. It had _a lot_ of discussion. Over a year ago, but was never merged. [15:18:11 CEST] <kierank> durandal_1707: "Fulfills precision requirements outlined in the official SMPTE specs" [15:18:17 CEST] <kierank> mainconcept is trolling us over prores [15:26:30 CEST] <durandal_1707> kierank: where? [15:27:07 CEST] <kierank> email [15:29:48 CEST] <durandal_1707> i received no such mail [15:31:56 CEST] <kierank> I forwarded [15:34:37 CEST] <durandal_1707> kierank: so buy/use it [15:34:42 CEST] <kierank> LOL [15:34:50 CEST] <kierank> I don't care for prores [16:33:12 CEST] <cone-980> ffmpeg 03Paul B Mahol 07master:1232e67b16dd: avfilter/af_compand: change error condition into warning [16:33:13 CEST] <cone-980> ffmpeg 03Paul B Mahol 07master:d8410e9cf9db: avformat/dhav: always initializer ret [16:33:14 CEST] <cone-980> ffmpeg 03Paul B Mahol 07master:d063f13700aa: avcodec/tiff: add missing break in tiff_decode_tag() [16:33:15 CEST] <cone-980> ffmpeg 03Paul B Mahol 07master:428b4aacb1a9: avformat/mov: improve timecode calculation [16:33:16 CEST] <cone-980> ffmpeg 03Paul B Mahol 07master:ef73ccc2c419: avcodec/h264_refs: do not use invalid mmco values in case of error [17:21:19 CEST] <philipl> BtbN: I think it's a capability worth having. But I don't have much spare time these days, and I'm sure it would be a slog. [17:49:58 CEST] <cone-980> ffmpeg 03Paul B Mahol 07master:98f5cbcb7db4: avformat/dsfdec: set packet pts/duration/pos correctly [17:49:59 CEST] <cone-980> ffmpeg 03Paul B Mahol 07master:9606e4b6e68d: avcodec/dsddec: add slice threading support [17:50:00 CEST] <cone-980> ffmpeg 03Paul B Mahol 07master:330ba8d537b4: avcodec/dsd: use uint8_t instead of unsigned char [18:02:18 CEST] <kierank> jdarnley_obs: just fyi someone has sent v210 patches [18:04:17 CEST] <BradleyS> thanks for pushing the amf/vulkan patch philipl [18:04:22 CEST] <philipl> np [18:04:35 CEST] <philipl> Thanks for reminding me it was still an open issue [18:09:39 CEST] <J_Darnley> thanks [18:14:47 CEST] <J_Darnley> i see they removed something I think I added for assembly reasons but I don't really remember [18:20:30 CEST] <cone-980> ffmpeg 03Limin Wang 07master:ffd65c8862e1: lavf/dump: dump the vbv_delay with N/A instead of 18446744073709551615 [20:14:20 CEST] <tmm1> jkqxz: is there any way to create a dummy drm hwaccel device on the cli? [20:15:21 CEST] <jkqxz> -init_hw_device drm:/dev/dri/card0 [20:16:51 CEST] <jkqxz> philipl: Is there any resolution to the problem with the multiple-plane formats in Vulkan not actually being supported properly by any drivers? [20:18:10 CEST] <jkqxz> That seemed like the ugliest problem blocking stuff last time. If it hasn't improved then using the OpenCL approach of handling each plane separately is an alternative. [20:21:08 CEST] <Lynne_> jkqxz: all platforms support it now, including amd - https://vulkan.gpuinfo.org/displayreport.php?id=6699#formats [20:21:28 CEST] <Lynne_> BtbN: I worked on the hwcontext until 2 weeks or so ago when I lost all motivation to do anything [20:22:14 CEST] <Lynne_> since all my contributions and work were valued less than the opinions of a spammer and a rogue deaf developer [20:22:48 CEST] <jkqxz> Lynne_: Does "support" mean they actually work properly? [20:25:18 CEST] <Lynne_> yes? why wouldn't they work properly? [20:29:01 CEST] <jkqxz> I may be misremembering, but I think a year ago the Intel driver declared the support but then died randomly trying to use it. [20:31:24 CEST] <Lynne_> jkqxz: yes, some specific illegal usage of shared memory in shaders made intel die, and it still does [20:33:47 CEST] <Lynne_> hopefully no one evil will ever figure out its reading from storage-viewed images which don't have the storage flag set [20:36:33 CEST] <Lynne_> I rewrote the context to split up multiplane images nonetheless, no penalty for doing so, less validator bugs, easier to import, etc. [20:38:34 CEST] <Lynne_> can't use the builtin yuv conversions, but amd still doesn't support those, and driver dev's understanding of colorspaces is very relative [21:05:37 CEST] <jkqxz> Probably for the best, then. Awesome! Is there anything else to do? [21:07:52 CEST] <jkqxz> (Excepting "find a sensible way to make shaders for it".) [21:14:32 CEST] <Lynne_> all the code for writing shaders sensibly was already well written [21:15:24 CEST] <jkqxz> I mean the compiler. [21:15:56 CEST] <Lynne_> glslang is available everywhere, and the c++ wrapper isn't big [21:16:12 CEST] <durandal_1707> so use it?! [21:17:08 CEST] <Lynne_> all that's left is to move my repo to a windows pc and then throw it all in the "Waste Bin" folder, since I don't have one on linux to perform this symbolic gesture [21:17:44 CEST] <taliho> Hello, are there any define flags that indicate a system is POSIX compliant. Specifically, I'm trying to infer if errno is available on a particular system for my patch [21:24:38 CEST] <BBB> #ifdef EINVAL [21:24:40 CEST] <BBB> ? [21:24:48 CEST] <BBB> but I think we typically assume these thngs just exist [21:24:55 CEST] <BBB> also see AVERROR() [21:31:03 CEST] <J_Darnley> Configure might check and produce HAVE_ERRNO or something [21:31:04 CEST] <taliho> BBB: ah yes, seems reasonable just to check if that is set. thank you! [21:31:49 CEST] <taliho> J_Darnley: thanks, I'll do a grep [21:33:48 CEST] <J_Darnley> ffmpeg.c includes errno.h without anycheck [21:33:50 CEST] <jkqxz> errno is required by C. I don't think we can not have it. [21:35:28 CEST] <J_Darnley> Then there is no need to check [21:35:55 CEST] Action: J_Darnley has no idea where posix stops and c starts [21:36:04 CEST] <jkqxz> C only defines a few error codes, so it's possible some particular codes might not be present. We certainly assume a set of usual ones like EINVAL though. [21:43:18 CEST] <BtbN> Fun, pre-auth remote code exec flaw in dovecot. [21:47:40 CEST] <thardin> I warned you about parsing bro [21:48:00 CEST] <thardin> I told you dog [21:50:47 CEST] <durandal_1707> Lynne_: i do not get it, what is an issue? [21:58:20 CEST] <cone-980> ffmpeg 03Thierry Foucu 07master:a80fdbcf1391: lavc/cbs_h2645: Use av_realloc instead of av_malloc [00:00:00 CEST] --- Thu Aug 29 2019

1 0