July 2018 - Ffmpeg-devel-irc - lists.ffmpeg.org

ffmpeg-devel.log.20180714
by burek 15 Jul '18

15 Jul '18

[00:05:24 CEST] <Compn> j-b what have you done! [00:05:30 CEST] <Compn> ehe [00:05:46 CEST] <Compn> webmaster@mphq got a mail from "anna brooks" at "eltima software" [00:07:22 CEST] <Compn> j-b : did you send them anything or did someone impersonate you ? [00:07:23 CEST] <Compn> ehe [00:10:14 CEST] <Compn> i forward you mail [00:29:59 CEST] <Compn> hmm i hope both j-b@vo and jb@vo work heh [00:51:39 CEST] <j-b> Compn: those are GPL violators [01:02:43 CEST] <j-b> Compn: see my email. [01:58:26 CEST] <atomnuker> BBB / j-b: gratz on getting funds for the av1 decoder [01:58:28 CEST] <atomnuker> RELEASE [02:04:43 CEST] <atomnuker> kierank: I haven't been affected by any french workers on strike and I do consider them fairly not-lazy [02:05:14 CEST] <atomnuker> canadians otoh; take every single bad experience with london buses or any bus service ever and it won't measure up to how bad its here [02:05:14 CEST] <kierank> oh cool [02:05:48 CEST] <atomnuker> 30 minutes for a change of driver in 33 degrees heat barely 1 stop after we left the airport [02:06:01 CEST] <kierank> in london? [02:06:03 CEST] <atomnuker> (i should mention it took 25 minutes to get to stop #1 from the airport) [02:06:07 CEST] <atomnuker> no, montreal [02:06:25 CEST] <atomnuker> london's cool compared to this [02:07:14 CEST] <atomnuker> a funny thing: the bus stop had a heater you could turn on in case it was colder than -5, though its hard to imagine that right now [02:10:48 CEST] <TD-Linux> oh yeah, that's common in minnesota too. doesn't really help that much [02:17:32 CEST] <rcombs> oh is av1 gonna go fast [02:17:58 CEST] <jamrial_> if the vp9 decoder is any indication, yes :p [08:35:00 CEST] <cone-595> ffmpeg 03Gyan Doshi 07master:28ed68fa3177: avformat/movenc: add reason for minf->hdlr in MOV only [11:21:55 CEST] <durandal_1707> j-b: you owe me some money [12:45:45 CEST] <j-b> durandal_1707: sure. [18:11:31 CEST] <cone-061> ffmpeg 03Shiyou Yin 07master:c0b42987a272: avcodec/mips: fix conflicting types error of ff_vc1_h_s_overlap_mmi. [18:11:31 CEST] <cone-061> ffmpeg 03Michael Niedermayer 07master:181435a4de6e: avcodec/dirac_dwt_template: Fix signedness regression in interleave() [21:20:48 CEST] <durandal_1707> anybody have comments about lensfun filter wrapper? [22:17:59 CEST] <cone-160> ffmpeg 03Karsten Otto 07master:c5329d64b126: aadec: improve seeking in mp3 content [22:43:24 CEST] <atomnuker> jdarnley: why are you forcing yuv422p12 in the new vc2 tests? [22:44:03 CEST] <atomnuker> in fact, why are there new tests at all, the vsynth tests are pretty extensive covering pixel formats and even losslessness [22:44:10 CEST] <jdarnley> p10 but because we want to use 10bit [22:44:24 CEST] <jdarnley> wavelet types [22:44:59 CEST] <jdarnley> I needed tests to check that I was rewriting the transform correctly. [22:49:43 CEST] <jdarnley> Oh, I guess it also tests the decoder more [23:14:34 CEST] <atomnuker> 10 bits are tested currently in vsynth [23:15:11 CEST] <atomnuker> I think all formats are, from 420 8bit to 444 12 bit [23:22:39 CEST] <kierank> atomnuker: but not all the transforms, no? [23:22:58 CEST] <jdarnley> Yes, the matrix of 8 10 12 and 444 422 420are all tested [23:24:24 CEST] <jdarnley> I could leave the new wavelet tests to do the default pixel format but we want to use 422p10 so I will test the other wavelets with 422p10 [23:25:42 CEST] <jdarnley> Maybe I should be testing 8 10 12 for the other wavelets so the decoder gets tested even more. [23:34:34 CEST] <kierank> jdarnley: -wavelet_type 444p12 [23:34:35 CEST] <kierank> lol [23:55:51 CEST] <atomnuker> kierank: actually yes, haar, 5_3 and 9_7 are tested [23:56:45 CEST] <kierank> How come the broken transform wasnt picked up the [23:56:46 CEST] <kierank> Then [23:59:18 CEST] <atomnuker> broken transform? [00:00:00 CEST] --- Sun Jul 15 2018

1 0

ffmpeg.log.20180714
by burek 15 Jul '18

15 Jul '18

[00:30:34 CEST] <chocolate-elvis> Been trying to find some jp2k acceleration plug-ins or something to speed up conversions. Anyone have any ideas? [01:01:08 CEST] <kerio> chocolate-elvis: but y tho [01:38:44 CEST] <RougeR> can anyone explain what a stream id is? [01:38:48 CEST] <RougeR> new to video stuff [01:38:54 CEST] <RougeR> or can anyone link a wiki article [01:38:59 CEST] <RougeR> google isnt giving me answers i need [01:40:54 CEST] <chocolate-elvis> Selection of media streams [01:40:54 CEST] <chocolate-elvis> Some media containers like AVI, Matroska, MP4, etc. can contain multiple streams of various type, [01:40:55 CEST] <chocolate-elvis> FFmpeg recognizes 5 stream types: audio (a), attachment (t), data (d), subtitle (s) and video (v). [01:40:55 CEST] <chocolate-elvis> Stream are selected with -map option followed by a stream specifier with the syntax: [01:41:13 CEST] <chocolate-elvis> file_number:stream_type[:stream_number] [01:41:35 CEST] <chocolate-elvis> File_number and stream_number are denoted also file_index and stream_index and are counted from 0, it [01:41:36 CEST] <chocolate-elvis> means that the first one is 0, the second one is 1, etc. There are some special stream specifiers: [01:41:36 CEST] <chocolate-elvis> -map 0 selects all streams from all types [01:41:37 CEST] <chocolate-elvis> -map i:v selects all video streams from the file with a number i (index), -map i:a selects all audio [01:41:39 CEST] <chocolate-elvis> streams, -map i:s selects all subtitle streams, etc. [01:41:39 CEST] <chocolate-elvis> special options -an, -vn, -sn exclude all audio, video or subtitle streams respectively. [01:42:38 CEST] <RougeR> thankyou for that chocolate elvis, thats above n beyond [01:42:39 CEST] <chocolate-elvis> this is from http://ffmpeg.tv/ FFmpeg Basics pdf by Frantisek Korbel [01:42:40 CEST] <RougeR> will read now [01:42:59 CEST] <RougeR> im doing a tech test for a company basically [01:43:14 CEST] <chocolate-elvis> nice, best of luck [01:43:34 CEST] <RougeR> thanks, its all going well. just pull some metadata and throw it into json, then manipulate [01:43:34 CEST] <RougeR> ty [02:28:28 CEST] <RougeR> chocolate-elvis: if the test asked for the audio "format" [02:28:31 CEST] <RougeR> would AAC be correct? [02:28:56 CEST] <chocolate-elvis> RougeR Yes, that would be a audio codec [02:29:14 CEST] <RougeR> yeah i figure that they are after the codec [02:29:18 CEST] <RougeR> sorry thats what i should have said [02:29:25 CEST] <RougeR> thanks [02:29:41 CEST] <RougeR> lol, ill throw up the repo when im done, its not very interesting but eh [02:41:37 CEST] <RougeR> https://github.com/CodePint/VideoUrl-API [02:41:39 CEST] <RougeR> think im done [02:41:45 CEST] <RougeR> gotta make it into a little cli api [02:41:48 CEST] <RougeR> but logic is done [02:41:56 CEST] <RougeR> will wrap it up in methods etc too [03:01:13 CEST] <chocolate-elvis> RougeR have you checked out FFprobe? [03:01:40 CEST] <chocolate-elvis> you can get json outputs directly [03:02:53 CEST] <RougeR> chocolate-elvis: ill have a look at that now, interesting [03:04:07 CEST] <RougeR> i think for what i want to do, this probably works quite well. as i only want a small sample of the metadata saved to json [03:04:15 CEST] <RougeR> but FFprobe looks pretty cool [03:04:36 CEST] <RougeR> theres a ruby gem for FFprobe too, which is neat [03:06:41 CEST] <chocolate-elvis> I think you're after ffprobe -v quiet -print_format json -show_format -show_streams , but perhaps another day [03:08:54 CEST] <RougeR> chocolate-elvis: hmmm that would probably do it, although im not sure it is as good for demonstrating basic programming skills in a tech test [03:09:09 CEST] <RougeR> thankyou all the same, im going to try that command and see if it works [03:09:14 CEST] <RougeR> would be cool to do it in a one liner [03:09:50 CEST] <chocolate-elvis> RougeR Probably good to know its there if you need it [03:10:08 CEST] <RougeR> yeah it is, the role is backend as a service for video streaming [03:10:12 CEST] <RougeR> medium startup [03:10:14 CEST] <RougeR> first dev role [03:10:23 CEST] <RougeR> so might end up doing thi smore [08:41:58 CEST] <cesdo> Hi guys! I have three mp4 videos: 25 fps, 23.976 fps, 29.97 fps. How can I mix them with variable framerate? [08:53:37 CEST] <cesdo> https://pastebin.com/EWjkEkXT [08:54:46 CEST] <cesdo> Here is information about my files [08:57:40 CEST] <cesdo> Ah, I need concatenate videos with sound, of course! [13:35:38 CEST] <RougeR> finished it as an api [13:35:39 CEST] <RougeR> https://github.com/CodePint/VideoUrl-API/blob/master/video_api_main.rb [13:43:38 CEST] <commando> hey can anybody help me to use ffmpeg in iOS [13:43:39 CEST] <commando> ? [13:46:12 CEST] <JEEB> it should be the same as everywhere else [13:46:17 CEST] <JEEB> use the API, basically [13:46:40 CEST] <JEEB> I should try cross-compiling for iOS one of these days, got the mac VM running again [13:47:07 CEST] <commando> iOS does not allow to excute commands . [13:47:12 CEST] <JEEB> yes [13:47:14 CEST] <JEEB> that's why I said [13:47:18 CEST] <JEEB> "use the API" [13:47:23 CEST] <commando> so complied the ffmpeg and i have that. [13:47:26 CEST] <JEEB> ffmpeg.c is just an example command line API [13:47:32 CEST] <JEEB> *API client [13:47:37 CEST] <JEEB> the APIs are still there [13:47:46 CEST] <JEEB> there's examples like the transcoding one under doc/examples [13:49:47 CEST] <commando> okay i saw that example somewhere on ffmpeg [13:49:59 CEST] <commando> but i forget where i saw it. [13:50:09 CEST] <JEEB> if you have the FFmpeg source code [13:50:10 CEST] <commando> @JEEB can you help me ? [13:50:13 CEST] <JEEB> it's under doc/examples [13:50:29 CEST] <JEEB> I think the transcoding one was relatively up-to-date [13:50:36 CEST] <JEEB> but you should think what you want to do btw [13:50:49 CEST] <JEEB> because there might be higher level abstraction libraries already available [13:50:55 CEST] <JEEB> like libvlc/libmpv [13:51:02 CEST] <JEEB> if you need playback for example [13:51:43 CEST] <commando> i need to do some stuff like cropping video , resizing it, applying filter and adding music. [13:52:47 CEST] <commando> i found example here -- https://ffmpeg.org/doxygen/trunk/examples.html [13:53:03 CEST] <commando> that's what were talking about earlier [13:53:07 CEST] <JEEB> yes that is the exactly same stuff that's in the source [13:53:20 CEST] <JEEB> if you look under the doc/examples directory in the FFmpeg source tree the examples are there [13:53:31 CEST] <JEEB> but yes, you can look at them through doxy as well [13:54:39 CEST] <commando> thanks buddy. but these examples are in c language and i almost forgot that thing. [13:55:04 CEST] <commando> do you know how i can find some java or objective-c examples ? [13:55:15 CEST] <JEEB> you can use C libraries from swift or objc [13:55:34 CEST] <JEEB> you can use the C stuff as an example and then translate that into swift or objc [13:56:13 CEST] <commando> thanks for your help buddy. I will try that stuff. [13:56:17 CEST] <commando> have a good day. [13:59:33 CEST] <RougeR> yeah i just did it with ruby and used a library(gem) for it [15:35:33 CEST] <sagax> hi all! [15:35:51 CEST] <sagax> how to choose video position when set -video_size? [15:36:24 CEST] <sagax> i try this, it's just example -video_size 800x600+10,10 [15:36:32 CEST] <sagax> but this doesn't work [15:40:41 CEST] <sagax> hm, maybe i found this [18:34:20 CEST] <tidbit> new to ffmpeg, fills my needs perfectly. question though: [18:34:20 CEST] <tidbit> if I use '-c libx264' or '-c:v libx264', I can't convert videos to gif (and probably other non-264 formats). is there either: a way to make it work for everything OR get a list of everything it supports, so I can check before I start converting? [18:35:27 CEST] <JEEB> I think muxers only define their default video codec [18:35:34 CEST] <JEEB> (possibly audio as well if relevant= [18:36:12 CEST] <JEEB> usually an application will limit itself to some things for some containers [18:37:24 CEST] <JEEB> you can see what the API returns with the command line application as well [18:37:25 CEST] <tidbit> ya, I currently check "if converting to gif, user mist specify a bitrate instead". was hoping there was some like of format that x264 supported so I could toss them all in that If [18:37:34 CEST] <JEEB> -h muxer=gif [18:37:49 CEST] <JEEB> for example asks some basics about the gif muxer [18:37:59 CEST] <tidbit> I see [19:36:17 CEST] <dshowoff> hi all. been getting repeated video frames from a dshow capture dongle, but first few attempts encode without issues. [19:37:32 CEST] <dshowoff> that common? any recommended way to fix it, preferably without a reboot. [20:40:18 CEST] <nicolas17> is there anything that will let ffmpeg read from AWS S3? I was thinking of writing a new libavformat protocol but maybe there's an easier trick [20:41:20 CEST] <DHE> isn't S3 just HTTP-based? [20:42:19 CEST] <nicolas17> yes if the file is public, otherwise you need an authorization HTTP header with a signature [20:43:21 CEST] <JEEB> I think you should be able to set HTTP headers? [20:43:42 CEST] <JEEB> yes [20:43:43 CEST] <DHE> ffmpeg -headers "X-Whatever-Header: valuegoeshere" -i http://s3.amazon.com/..../file.mp4 [...] [20:43:48 CEST] <JEEB> there's a "headers" avoption for http [20:43:58 CEST] <DHE> I don't know how s3 actually works so I just made all of the above up. I expect you can make it work properly [20:44:29 CEST] <nicolas17> and in particular I'd like to point ffmpeg to an HLS .m3u8 in S3, for which it would have to calculate the signature every time it fetches a .ts [20:44:49 CEST] <JEEB> right, those pesky meta-demuxers [20:44:57 CEST] <JEEB> and if it's a separate signature/whatever for each file [20:45:03 CEST] <JEEB> then it gets tricky [20:45:15 CEST] <JEEB> so you can't just say "this authorizes the whole directory" kind of thing? [20:45:43 CEST] <DHE> there is another option maybe? mpegts is highly stream-friendly, so if you can script something to just output all the .ts files in sequence then ffmpeg could just read stdin [20:46:07 CEST] <nicolas17> afaik AWS auth signatures are a hash of the secret key, request URL, and current timestamp [20:46:14 CEST] <nicolas17> and some headers [20:46:25 CEST] <DHE> ( curl -H "X-Header: value" http://s3.amazon.com/../file1.ts ; curl -H ... ... ; curl ... ; curl ... ) | ffmpeg -f mpegts -i - [...] [20:47:21 CEST] <nicolas17> maybe I should see if there is some kind of local proxy... such that unauthenticated http://localhost:8080/foo is proxied into an authenticated request to S3 [20:47:35 CEST] <JEEB> yea, that sounds scriptable [20:50:17 CEST] <DHE> "timestamp" in the signature means that my curl command wouldn't be reliable. you'd have to make it a script that generates on-demand... [20:50:59 CEST] <JEEB> yea you need scripting in any case [20:51:35 CEST] <nicolas17> I still don't know what's the point of AWS having such complex auth system... instead of just sending the secret key in every request and relying on TLS to keep it secret and non-replayable [20:52:23 CEST] <sfan5> the point is that you can give out links to some content to third parties [20:52:50 CEST] <JEEB> nicolas17: they have a separate authentication system for streaming content delivery [20:53:08 CEST] <nicolas17> the "pre-signed URL" thing is separate [20:53:18 CEST] <JEEB> where you only need to authenticate for the playlist, and they will rewrite the URLs in the playlist [20:53:32 CEST] <JEEB> so that all the accesses automagically are valid [20:53:43 CEST] <JEEB> (for that piece of content, for X amount of time and for Y IP) [20:59:07 CEST] <nicolas17> if I was crazy enough to make a lavf protocol, would the hls demuxer Just Work? it works with http: and file: so I guess it works with any protocol? [20:59:51 CEST] <JEEB> it should work with various, yes [21:00:48 CEST] <JEEB> I must say though that just making a python script that feeds you the data might be a better idea [21:00:56 CEST] <JEEB> running as a http proxy or something [21:01:16 CEST] <nicolas17> yeah [21:31:17 CEST] <LukasStribrny> hi there,i would like to know what's the diference between : ffmpeg build 4.0.1 vs ffmpeg build 20180714-28ed68f [21:31:32 CEST] <LukasStribrny> thanks [21:31:42 CEST] <JEEB> 4.0.1 is from the 4.0 branch as the release 4.0.1 [21:31:51 CEST] <JEEB> the other one seems to have a beginning of the hash at the end [21:31:52 CEST] <JEEB> 28ed68f [21:32:07 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=28ed68f [21:33:19 CEST] <JEEB> the github mirror actually can show you all the commits from that release branch to master [21:33:35 CEST] <JEEB> or well, that commit in master [21:33:38 CEST] <JEEB> https://github.com/FFmpeg/FFmpeg/compare/n4.0.1...28ed68f [21:33:40 CEST] <JEEB> there [21:33:50 CEST] <LukasStribrny> yeah but what's the diference between : ffmpeg build 4.0.1 vs ffmpeg build 20180714-28ed68f [21:33:53 CEST] <JEEB> comparison from n4.0.1 to thath hash [21:34:09 CEST] <JEEB> LukasStribrny: one is a release branch release, and the latter is a thing from the active master branch [21:34:13 CEST] <JEEB> releases get branched out of master [21:34:23 CEST] <JEEB> and I just linked you the exact list of differences [21:34:36 CEST] <JEEB> if you want to know exactly what has happened in master since the 4.0 release [23:53:21 CEST] <killown> how can I cut the first 30 seconds from a video for a output.mp4 [00:00:00 CEST] --- Sun Jul 15 2018

1 0

ffmpeg-devel.log.20180713
by burek 14 Jul '18

14 Jul '18

[00:13:42 CEST] <jamrial> jkqxz: re annexb(8since i see you're handling it), i thought the idea was to treat that as a container format and make sure it was never propagated as is internally [00:14:18 CEST] <jamrial> so packets would only ever contain Low Overhead Bitstream Format obus [00:14:51 CEST] <jamrial> so no need to handle it in cbs [00:15:15 CEST] <jkqxz> I haven't done any more with that, the stuff there is the same as before and won't match current libaom. [00:15:28 CEST] <jamrial> ah ok [00:15:49 CEST] <jkqxz> (Mostly a "wait and see".) [00:16:32 CEST] <jkqxz> If it's a container, you'd put the size-handling stuff in lavf only if you wanted to implement it? [00:18:07 CEST] <jamrial> you mean for obus without a leb128 size field? [00:18:13 CEST] <jkqxz> Maybe it's best to handle it on input, but never create it. That's not difficult to do. [00:18:16 CEST] <jkqxz> Yeah. [00:20:58 CEST] <jamrial> annexb demuxer would extract the obus from each annexb temporal unit, and add the size field if required to the last obu on each annexb frame [00:21:48 CEST] <jamrial> better to have lavf handle that so no packet ever has annexb encapsulated data [00:22:13 CEST] <jamrial> we were able to get mp4 and matroska to only use raw obus for this purpose :p [00:33:00 CEST] <cone-735> ffmpeg 03Danil Iashchenko 07master:7cd58a8a8c53: lavfi/convolution_opencl: use CL_FAIL_ON_ERROR for error handling [00:45:32 CEST] <jkqxz> Would "select operating point" want to be a separate bsf? [00:45:53 CEST] <nevcairiel> whats an operating point [00:46:47 CEST] <jkqxz> Stream layer identifer for scalable stuff. [00:46:58 CEST] <nevcairiel> ie. a feature never going to be used? [00:47:21 CEST] <nevcairiel> they try to add scalability features into all codecs, and i never see them used anywhere [00:49:39 CEST] <jkqxz> Vidyo did it with H.264! (And then spent years trying to convince everyone it was a good idea, but noone cared.) [00:49:48 CEST] <nevcairiel> heh [00:50:00 CEST] <jamrial> jkqxz: i think you should be setting frame_type on each refreshed AV1ReferenceFrameState in read_uncompressed_header [00:51:03 CEST] <jamrial> you're reading the field when show_existing_frame == 1, but i can't see where it's being set [00:51:06 CEST] <jkqxz> Hmm, yeah. [00:51:41 CEST] <jkqxz> The reference frame information stuff needs to be cleaned up generally. [00:54:05 CEST] <atomnuker> jkqxz: does that mean there may be multiple operating points within a single stream? [00:54:31 CEST] <jkqxz> Yes. [00:55:31 CEST] <atomnuker> so multple decodable video sizes from a single stream? [00:57:58 CEST] <atomnuker> dunno if the decoder would be more appropriate [00:58:39 CEST] <jkqxz> That's how H.264 SVC works. I don't know if that stuff (including deterministic scaling for references to smaller layers) is actually defined here. [00:59:44 CEST] <atomnuker> a separate bsf would work if the decoder could handle switching whilst keeping/resizing the reference frames [01:00:23 CEST] <jkqxz> No, the decoder is too late for that. The idea is that you can do things like dropping layers in the network if there isn't enough bandwidth. [01:01:22 CEST] <cone-735> ffmpeg 03Carl Eugen Hoyos 07master:5545a6df879f: lavc/h263dec: Remove a variable declaration that can lead to a warning. [01:01:51 CEST] <atomnuker> wouldn't the bsf just error out saying there's no such layer (anymore), so you'd reinit the bsfs with a new layer and feed the decoder the new packets? [01:02:18 CEST] <atomnuker> the whole point of scalability was afaik to be able to switch instantly between qualities [01:03:16 CEST] <jkqxz> The bsf isn't for decode-time. [01:04:42 CEST] <atomnuker> oh, nvm then, I misunderstood [01:05:02 CEST] <atomnuker> yeah, I think its reasonable to have a separate bsf for that [01:08:41 CEST] <jkqxz> Though yeah, there is still the question of whether anyone will ever care. (I do wonder what the people who semi-regularly ask for H.264 SVC in ffmpeg actually want it for.) [01:11:44 CEST] <atomnuker> they kinda do; there's still a bounty for it afaik but the patches were rejected 2 or so years ago iirc [01:16:20 CEST] <nevcairiel> patches get rejected when they are bad, not because we dislike the feature, apparently noone cared enough to make it nice then [01:19:11 CEST] <atomnuker> yep, absolutely, and they were bad iirc [02:22:35 CEST] <cone-735> ffmpeg 03Michael Niedermayer 07master:aba13dc13e52: avformat/mov: Break out of inner loop early in mov_estimate_video_delay() [02:22:36 CEST] <cone-735> ffmpeg 03Karsten Otto 07master:ce372bc278ce: libavcodec/mpegaudiodecheader.h: fix version check pattern [02:22:37 CEST] <cone-735> ffmpeg 03Michael Niedermayer 07master:b0644f7f72a9: avformat/mov: Simplify last element computation in mov_estimate_video_delay() [03:25:33 CEST] <memeka> hi, is it possible to set the pix_fmt sent to the decoder from the ffmpeg command line? [03:26:54 CEST] <memeka> the AVCodecContext pix_fmt [06:42:43 CEST] <cone-290> ffmpeg 03Gyan Doshi 07master:1a31c2b5df11: avfilter/drawtext: fix box sizing [07:16:10 CEST] <memeka> is it possible to set the pix_fmt sent to the decoder from the ffmpeg command line? the AVCodecContext pix_fmt [07:20:46 CEST] <seodisparate> I'm having trouble getting 'configure' to recognize the new filter I'm writing. Is there more documentation besides "doc/writing_filters.txt" about setting up a filter? [07:25:28 CEST] <seodisparate> oh wait... wow for some reason it's working again? I'm not quite sure what fixed it but I guess I no longer need help on this issue..? [07:26:04 CEST] <cone-290> ffmpeg 03Gyan Doshi 07master:97d766ff52fb: doc/filters: correct description of variables in blend filter [07:26:52 CEST] <seodisparate> I'm guessing that invoking "git clean -xfd" to remove some cached files might have fixed it after changing configure... [07:38:08 CEST] <seodisparate> I acutally identified my problem, it seems adding the string "gplv3" to the *_filter_deps of my filter in 'configure' seems to cause it to not be enabled even if the flag "--enable-version3" is set (for GPL3) [07:38:56 CEST] <seodisparate> oh, it looks like I have to use "version3" instead of "gplv3" [09:15:10 CEST] <gagandeep_> related to threads: what are the restrictions on reading and writing to a same memory block [09:21:44 CEST] <gagandeep_> i need to understand this so as to properly allocate memory for the threads working [09:23:16 CEST] <rcombs> that's a little bit vague [09:23:38 CEST] <rcombs> are you asking about, like, how C's memory model works [09:24:19 CEST] <gagandeep_> kierank: had told me that some write restrictions are there for multiple threads writing to memory [09:28:37 CEST] <gagandeep_> so i am asking are there some restrictions in place in ffmpeg frame thread model [09:28:39 CEST] <kierank> well if you have multiple threads writing you can obviously read [09:28:41 CEST] <kierank> can't [09:28:58 CEST] <kierank> because you can't guarantee the data will be consistent [09:29:48 CEST] <gagandeep_> ok, so i shouldn't be getting a system generated error from that part [09:30:21 CEST] <gagandeep_> it is a logical error but not a system error, right? [09:30:49 CEST] <kierank> you'll have nondeterministic errors [09:32:39 CEST] <gagandeep_> ok, so if in cfhd case, one thread is reading the coefficients for the next subbands and writing them in allocated memory, while the other thread is decoding the previous wavelet and writing it in the same memory but at an independent location in same memory [09:33:02 CEST] <gagandeep_> i don't think here i should have error, from this part [09:33:51 CEST] <kierank> should be ok [09:34:04 CEST] <kierank> but not clear exactly what you mean "same memory" [09:34:30 CEST] <gagandeep_> the large chunk of memory allocated in first thread to store all the coefficients in the packet [09:34:39 CEST] <kierank> gagandeep_: there is a program called tsan which can help you check for race conditions [09:34:56 CEST] <gagandeep_> i know about race conditions [09:34:57 CEST] <kierank> as long as there is no overlap it's fine [09:35:20 CEST] <gagandeep_> k, i am just working out the logic to get the decoding distributed across the 2 threads [09:35:53 CEST] <gagandeep_> also, update_thread_context runs after finish_thread_setup? [09:36:13 CEST] <kierank> not sure about that bit [09:36:16 CEST] <kierank> not familiar with the thread code [09:36:35 CEST] <gagandeep_> k, was not able to see this update bit in the code [09:36:44 CEST] <gagandeep_> rest is much clear now [14:19:49 CEST] <cone-290> ffmpeg 03Jun Zhao 07master:896854b2336f: lavc/hevc_ps: Refine sps_range_extension parse. [14:19:50 CEST] <cone-290> ffmpeg 03Jun Zhao 07master:d746a2e3cf5c: lavc/hevc_ps: use skip_bits instead of get_bits when skip bits. [17:53:33 CEST] <Mathieu_Du> Hey, is it possible to cherry-pick e84212b78e00df17799e01be1e153a073eb8f689 to the release/4.0 branch ? [17:56:09 CEST] <jdarnley> Ping the maintainer of 4.0? [17:59:27 CEST] <Mathieu_Du> I assume that would be michaelni ? [18:16:37 CEST] <jdarnley> God damn fuzzing people! You broke dirac decoding with your "undefined behaviour"! [18:17:40 CEST] <jdarnley> 575d8ca026 "avcodec/dirac_dwt_template: Fix undefined behavior in interleave()" [18:18:47 CEST] <jdarnley> I guess it is only for >8bit otherwise fate would have caught it. [18:31:21 CEST] <michaelni> Mathieu_Du, only 4.0 or do other releases need this too ? [18:32:02 CEST] <Mathieu_Du> michaelni, afaict only 4.0 is affected, as the commit that introduced the issue happened recently [18:32:08 CEST] <Mathieu_Du> let me find the hash [18:32:38 CEST] <Mathieu_Du> that was b22db4f465c9adb2cf1489e04f7b65ef6bb55b8b [18:36:10 CEST] <michaelni> that one was backported so the fix is needed in more branches [18:38:46 CEST] <Mathieu_Du> michaelni, I checked, it's indeed in 3.4 [18:38:59 CEST] <Mathieu_Du> not in 3.3 so I would assume nowhere elese ? [18:40:34 CEST] <michaelni> ill backport it locally to all branches that seem to need it so it should be included where its needed [18:41:28 CEST] <Mathieu_Du> OK, thanks! [18:45:39 CEST] <BtbN> Working on android sure is fun. "Let me rebase those two patches real quick!" Now it's 2 hours later. It still rebasing. [19:03:26 CEST] <michaelni> jdarnley, ill fix it unless you already did ? can you add a fate test for this ? [19:25:19 CEST] <Mathieu_Du> michaelni, want me to file an issue somewhere or that's not needed ? :) [19:33:49 CEST] <jdarnley> michaelni: I have more fate tests. I didn't fix only reverted but I will make a fix for both the "undefined behaviour" and the decoding error if that's what you want. [19:48:08 CEST] <michaelni> jdarnley, already posted: (1,2K) [FFmpeg-devel] [PATCH 1/4] avcodec/dirac_dwt_template: Fix signedness regression in interleave() [19:48:32 CEST] <michaelni> can you check if that works/fixes it, or was there some other issue too ? [19:49:06 CEST] <michaelni> Mathieu_Du, not needed [19:51:50 CEST] <Mathieu_Du> ack :) [19:57:51 CEST] <jdarnley> michaelni: that does fix it. I will also send an email reply for the record. [20:01:13 CEST] <jdarnley> And I was wrong about the >8bit depth being the cause. Only some of the wavelet transforms use that deinterleave function, haar and 5_3 which we don't test. [20:03:30 CEST] <electron_rotosco> Hello I have a question about a bug I submitted a few weeks ago to trac.ffmpeg.org here https://trac.ffmpeg.org/ticket/7280 It got moved to "enhancement" but I think of it as a defect, I'm not sure how to tell the difference [20:05:10 CEST] <jdarnley> A defect would be existing code producing an incorrect result. You want 12-bit encoding added from what I read. [20:05:14 CEST] <electron_rotosco> I'm sure problems with the dnxhd module aren't the highest priority in terms of how many users interact with it of course [20:05:33 CEST] <electron_rotosco> Yes. 10-bit encoding is incorrect for the spec [20:06:07 CEST] <electron_rotosco> So either it needs to be 12 bit or I would think it should be disabled. [20:06:15 CEST] <jdarnley> Then perhaps we need to abort if we can't satisfy the spec with the current code. [20:06:38 CEST] <electron_rotosco> I don't know if the current code could just be switched to 12 bit mode, I don't know what's involved with that [20:06:49 CEST] <jdarnley> Along the lines of what x264 does when the users asks for or gives incompatible restraints. [20:07:02 CEST] <jdarnley> I don't know either. [20:07:30 CEST] <electron_rotosco> Yeah that makes sense. Or a warning like "This will be incompatible with some equipment" like x264 used to do (maybe still does) if you try to use it in 10 bit mode [20:07:47 CEST] <kierank> That's not a correct statement [20:08:06 CEST] <electron_rotosco> which statement is that? [20:08:22 CEST] <kierank> Incompatibility with equipment [20:08:51 CEST] <JEEB> FFmpeg's libx264 wrapper notes that since you're not using 8bit 4:2:0 some (consumer) stuff might not be able to decode it [20:08:57 CEST] <JEEB> it's not that the stream is out of spec for anything [20:09:04 CEST] <nevcairiel> the x264 warning was not because it was invalid, just because it was uncommon [20:09:08 CEST] <JEEB> yes [20:09:11 CEST] <electron_rotosco> yes [20:09:21 CEST] <nevcairiel> if its actually generating something thats invalid to the spec, then it should just not be able to do that anymore until its properly implemented [20:09:26 CEST] <kierank> The underlying codec is fine [20:09:26 CEST] <JEEB> yea [20:09:34 CEST] <electron_rotosco> HQX recorded in 10-bit mode is technically outside of the spec, but some equipment will play it back [20:09:43 CEST] <electron_rotosco> *encoded not recorded [20:09:45 CEST] <kierank> That's not how dct codecs work [20:10:18 CEST] <kierank> You can have whatever bitdepth you want in and whatever you want out [20:10:31 CEST] <kierank> It's just shifting [20:10:37 CEST] <electron_rotosco> I mean DNxHD HQX is a specific profile defined by Avid. Sure it will work but you can't just make it whatever bit rate you want [20:10:55 CEST] <JEEB> bit depth != bit rate [20:10:58 CEST] <nevcairiel> so its just going to be inaccurate? [20:11:14 CEST] <kierank> Sure but it's dct to begin with [20:11:23 CEST] <kierank> So it's inaccurate anyway [20:11:48 CEST] <electron_rotosco> dnxhd and prores are dct codecs with specific profiles associated with them [20:11:49 CEST] <nevcairiel> well more so, of course i dont know if any other bitdepth things are coded anywhere, like recording the input bitdepth in a header for example [20:12:23 CEST] <electron_rotosco> there are pieces of hardware and software that expect certain profiles within those codecs [20:12:28 CEST] <electron_rotosco> those profiles define bit rate and bit depth [20:12:33 CEST] <kierank> I can put 1 bit data in if I want [20:12:36 CEST] <kierank> Doesn't matter [20:12:45 CEST] <electron_rotosco> yeah but it won't follow the profile [20:13:25 CEST] <electron_rotosco> The current code for libavcodec\dnxhdenc.c has a line "pixel format is incompatible with DNxHR HQX profile" if you try to encode it in 12 bit mode [20:13:46 CEST] <electron_rotosco> which is, as far as I can tell, inaccurate. The profile should only be 12 bit, and never 10 bit [20:14:00 CEST] <JEEB> does the format have a concept of bit depth in itself? [20:14:38 CEST] <electron_rotosco> I'm not sure if this is what you mean, but this documentarion for the format http://avid.force.com/pkb/articles/en_US/White_Paper/DNxHR-Codec-Bandwidth-… specifies bit depth [20:14:45 CEST] <electron_rotosco> *documentation [20:14:50 CEST] <JEEB> if yes, and there's a spec that says that the profile we're advertising should require 12bit input, then we check the place that is the defining part of it [20:15:00 CEST] <JEEB> *input and coding [20:15:13 CEST] <JEEB> and then the thing gets disabled until the feature's in [20:16:12 CEST] <kierank> electron_rotosco: it will follow the profile [20:16:21 CEST] <kierank> you conflate input bit-depth with output bit-depth [20:16:31 CEST] <kierank> an encoder can choose to support what it wants and it will play [20:16:52 CEST] <JEEB> ok, so the format effectively encodes either at no bit depth or at 12bit? [20:17:06 CEST] <JEEB> and the input for the codec just happens to be 10bit, since that's what mostly used as input for such encoder [20:17:07 CEST] <electron_rotosco> for that profile yes, that would be the spec as I understand it [20:17:17 CEST] <electron_rotosco> the input can be whatever [20:17:27 CEST] <electron_rotosco> 8 bit, 10 bit, 12 bit, 16 bit [20:17:34 CEST] <JEEB> in a larger application yes, which converts to whatevert the encoder part takes in [20:17:37 CEST] <electron_rotosco> I mean according to the profile anyways there's no restrictions [20:17:47 CEST] <electron_rotosco> I don't know about the code in ffmpeg [20:18:00 CEST] <JEEB> encoders usually take their input at bit depth X [20:18:07 CEST] <JEEB> in FFmpeg and outside of it [20:18:16 CEST] <JEEB> some just hide it from you :P [20:18:32 CEST] <JEEB> also some video formats will internally always code at bit depth X, but then have a flag about "what was the input bit depth" [20:18:37 CEST] <electron_rotosco> @kierank: the encoder currently forces output to 10 bit but it should be forcing to 12 bit [20:18:38 CEST] <BradleyS> commercial encoders will likely make 12-bit from any bit depth input [20:18:52 CEST] <kierank> electron_rotosco: nope, the encoder doesn't do anything [20:19:04 CEST] <electron_rotosco> Avid Media Encoder only produces 12-bit content if you use the DNxHR HQX profile [20:19:05 CEST] <kierank> there an "internal bit-depth" [20:19:11 CEST] <BradleyS> so the issue is whether that's a manual step in ffmpeg at the input/filter stages or whether the encoder does this internally [20:19:38 CEST] <BradleyS> (not literally internally, but forces the appropriate depth conversion) [20:19:54 CEST] <electron_rotosco> @keirank: I'm not sure, but lines 385 to 398 of libavcodec\dnxhdenc.c seem to be forcing a bit depth of 10 bits on output [20:20:02 CEST] <JEEB> encoders only take input [20:22:04 CEST] <electron_rotosco> I guess specifically lines 394 to 398 [20:22:35 CEST] <electron_rotosco> "if (ctx->profile == FF_PROFILE_DNXHR_HQX && avctx->pix_fmt != AV_PIX_FMT_YUV422P10)" then produce error [20:23:20 CEST] <electron_rotosco> but the flagship product that was released with this format, Avid Media Composer, only makes files in that profile at yuv422p12le [20:24:51 CEST] <BradleyS> so input format/depth is restricted but incorrectly [20:25:36 CEST] <kierank> no you're conflating a number of different things here [20:25:43 CEST] <kierank> if I understand correctly [20:26:35 CEST] <kierank> but ask paul [20:27:12 CEST] <JEEB> I see in the decoder at least that there's a random flag in the bit stream that says 8/10/12, and a separate DCT function is used for 12bit [20:27:24 CEST] <JEEB> so now the question is how defines that profile [20:27:43 CEST] <JEEB> is it somewhere in ISO/SMPTE/licker place, or some random proprietary vendor [20:28:01 CEST] <JEEB> and then whatever is hte authority should be checked regarding that profile [20:28:26 CEST] <electron_rotosco> I think it's known to SMPTE as VC-3 [20:28:59 CEST] <JEEB> wasn't VC-3 the gopro thing? [20:29:03 CEST] <JEEB> or was that VC-4 [20:29:53 CEST] <electron_rotosco> VC-3 was DNxHD [20:30:03 CEST] <electron_rotosco> I'm not sure if DNxHR falls under that or not [20:30:31 CEST] <BradleyS> kierank: genuinely, i'm not sure what else the quoted line would do... what are we missing? [20:31:33 CEST] <kierank> you can produce 12-bit output with 10-bit input [20:32:03 CEST] <electron_rotosco> not as the code is now [20:32:21 CEST] <electron_rotosco> if you feed it 12 bit input or 10 bit input and try to force the output to 12 bit it just gives an error and stops [20:32:32 CEST] <JEEB> electron_rotosco: btw the guy who edited the ticket and the guy who commented "This is just not correct" are not the same person [20:32:49 CEST] <electron_rotosco> @JEEB yeah I know. I wasn't sure at the motivations for either thing [20:32:52 CEST] <JEEB> electron_rotosco: also in FFmpeg generally the encoders don't take in anything else than they support [20:33:37 CEST] <JEEB> as in, if the encoder supports 12bit it should do that with 12bit input being a requirement [20:34:23 CEST] <JEEB> as far as I can see the dnxhdenc only supports 10bit, and thus the encoder requires 10bit input for that. and then there's some random profile limitation which you have noticed. [20:34:30 CEST] <JEEB> I should check who added that chekc [20:34:52 CEST] <JEEB> that might lead one to the source/definition of that requirement [20:35:27 CEST] <electron_rotosco> There has been some confusion online about that in the past so that might be where that came from. I suspect Avid originally intended it to be a 10 bit profile and then changed their mind [20:35:41 CEST] <electron_rotosco> Avid the company that is [20:36:06 CEST] <JEEB> aand it was durandal_1707 in f078bc4c5e6675a93166a7e5b23feb5b04ac9320 [20:36:20 CEST] <JEEB> so if he based that requirement on something he should know what he based that requirement on :) [20:36:36 CEST] <electron_rotosco> Makes sense! :) [20:38:14 CEST] <JEEB> also the 2016 12bit thing is for the decoder [20:38:18 CEST] <JEEB> which supports 12bit IDCT [20:39:05 CEST] <electron_rotosco> Which is good, since that's the only way that Avid makes HQX files [20:39:12 CEST] <electron_rotosco> Avid Media Composer that is [20:40:02 CEST] <electron_rotosco> Actually my code output at https://trac.ffmpeg.org/ticket/7280#comment:1 is decoding a 12 bit stream [20:40:30 CEST] <JEEB> yes, that thing you linked was just an unrelated patch adding a decoding test sample for 12bit mode [20:40:46 CEST] <electron_rotosco> aaah I see [20:41:48 CEST] <durandal_1707> electron_rotosco: i have actual specification [20:42:24 CEST] <JEEB> durandal_1707: so SMPTE defines these profiles? [20:43:25 CEST] <JEEB> specifically "DNxHR HQX profile" [20:46:00 CEST] <durandal_1707> yes, and 444 one [20:46:09 CEST] <durandal_1707> they can be both 10 and 12 depth [20:46:27 CEST] <JEEB> and we just don't implement 12bit, which is OK because both are then valid [20:46:41 CEST] <JEEB> if you can get a quote/screenshot of the spec [20:46:48 CEST] <JEEB> and link it in the trac issue, that'd be fabulous [20:47:00 CEST] <durandal_1707> 12 could be added easily if someone wants to actually sponsor that [20:47:22 CEST] <JEEB> yea, definitely not free work because of where that format gets used :) [20:47:44 CEST] <electron_rotosco> oh man is there a place to get information about that [20:47:56 CEST] <electron_rotosco> We've never sponsored development before [20:48:50 CEST] <JEEB> I'm not sure if we have guide lines on that - most such work tends to be a contract between a developer and the sponsoring party. or then something like VideoLAN's bounties. [20:49:04 CEST] <electron_rotosco> right now 10 bit HQX is useless because of https://trac.ffmpeg.org/ticket/4973 [20:50:55 CEST] <electron_rotosco> Well not useless completely, but can't be used with Avid Media Composer in the same timeline as HQX generated by Avid [20:51:33 CEST] <JEEB> also whatever trac is doing to that log is weird [20:51:46 CEST] <JEEB> it makes firefox hide it and then show it again a bit later [20:52:06 CEST] <JEEB> also I saw the word NAL pop up which is not something I'd expect with something that isn't H.264/H.265 [20:52:19 CEST] <JEEB> and MBAFF [20:52:44 CEST] <electron_rotosco> is that in 4973? That's an H264 encode I think in that giant log [20:53:08 CEST] <JEEB> yea [20:58:48 CEST] <durandal_1707> http://0x0.st/sOsx.png [20:59:50 CEST] <JEEB> cool [20:59:59 CEST] <JEEB> that brings the QED to this thing then :) [21:00:26 CEST] <JEEB> HD HQX is 10bit, RI HQX is 12/10bit [21:01:18 CEST] <JEEB> thank you [21:01:23 CEST] <electron_rotosco> Thanks! [21:01:26 CEST] <BradleyS> nice [21:02:25 CEST] <electron_rotosco> I guess to start out with the error could change to "12 bit is not currently supported in ffmpeg" [21:02:40 CEST] <JEEB> I think there should be two errors [21:02:45 CEST] <JEEB> one for not 10/12 [21:02:47 CEST] <electron_rotosco> yeah that would make sense [21:02:52 CEST] <JEEB> and one for 12bit [21:30:20 CEST] <cone-680> ffmpeg 03Carl Eugen Hoyos 07master:0576ef466d8a: lavc/aarch64/h264dsp_init_aarch64: Fix weight function prototypes. [21:41:01 CEST] <jamrial> jkqxz: re cbs_av1, some streams may have no temporal delimiter obus (mp4, mkv), so the whole seen_frame_header logic as is wouldn't work with those [21:41:52 CEST] <jamrial> libaom's decoder doesn't complain when they are missing, so i guess it internally assumes that new packet == new temporal unit, and handles it as if a TD obu was there [22:50:36 CEST] <cone-680> ffmpeg 03Marton Balint 07master:85bfcc46d192: ffplay: add support for various YUV conversion modes [22:50:37 CEST] <cone-680> ffmpeg 03Marton Balint 07master:5982078e8d56: avcodec/utils: report insane channel count errors [22:50:38 CEST] <cone-680> ffmpeg 03Marton Balint 07master:3e0f3be2b027: avcodec/internal: increase FF_SANE_NB_CHANNELS to 256 [23:14:15 CEST] <cone-680> ffmpeg 03Marton Balint 07master:e5ff2c0c0618: avformat/mxfdec: only return stream indexes which have a corresponding track [00:00:00 CEST] --- Sat Jul 14 2018

1 0

ffmpeg.log.20180713
by burek 14 Jul '18

14 Jul '18

[01:42:43 CEST] <BtbN> wlfgang, that depends entirely on the API. There is no generic "hwaccelerate this" recipe [03:45:54 CEST] <wlfgang> well, for example, is there a way to query for what is actually supported by the hardware/OS? (h264_nvenc, h264_qsv, ...) [03:46:52 CEST] <wlfgang> i am interested in h264 only, so if i need to query each one, that is fine [03:47:05 CEST] <memeka> hi, is it possible to set the pix_fmt sent to the decoder from the ffmpeg command line? [03:47:25 CEST] <memeka> the AVCodecContext pix_fmt [07:16:07 CEST] <memeka> is it possible to set the pix_fmt sent to the decoder from the ffmpeg command line? the AVCodecContext pix_fmt [07:16:33 CEST] <nicolas17> -pix_fmt? :P [08:10:40 CEST] <memeka> nicolas17: pix_fmt will actually be recognized later in the process [08:10:52 CEST] <memeka> and it's not set to AVCodecContext [08:11:33 CEST] <memeka> so it will actually try to do conversion to it, instead of setting it as AVCodecContext pix_fmt [12:03:10 CEST] <aaaa> I am trying to reverse an mp4 video but keep getting this error: Error while decoding stream #0:0: Invalid data found when processing input. The video plays fine with vlc. I notice that memory usage rockets when I run the command. The command I am using is /usr/bin/ffmpeg -i /tmp/original.mp4 -vf reverse /tmp/reversed.mp4 [12:03:27 CEST] <aaaa> Can anyone help with the error? [12:04:42 CEST] <JEEB> -v verbose and post the full terminal output on pastebin or so, and link here [12:04:48 CEST] <JEEB> most likely though you're running out of memory [12:04:57 CEST] <JEEB> since -vf reverse probably is going to buffer the whole shebang [12:05:13 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#reverse [12:05:14 CEST] <JEEB> yes [12:05:19 CEST] <JEEB> > Warning: This filter requires memory to buffer the entire clip, so trimming is suggested. [12:05:26 CEST] <JEEB> and that is the *decoded* clip [12:05:30 CEST] <JEEB> not just your clip [12:09:59 CEST] <aaaa> Here is the verbose output: https://pastebin.com/VsREznmf [12:10:41 CEST] <aaaa> Is there any workaround for this issue? Sorry if this is a stupid question... I'm very new to this :P [12:11:43 CEST] <sfan5> you're running out of memory [12:11:59 CEST] <sfan5> your best bet is not to run this on a terrible underpowered device (a raspberry pi) [12:13:23 CEST] <JEEB> sfan5: well he *is* buffering the whole clip [12:13:30 CEST] <JEEB> because that's the only way to reverse [12:14:26 CEST] <sfan5> sure, just using a rpi for this task doesn't help [12:14:36 CEST] <JEEB> yes, of course [12:14:46 CEST] <JEEB> I didn't check the length of his clip [12:14:55 CEST] <aaaa> its 15 seconds long [12:14:57 CEST] <JEEB> but I would guess a lot of *nix distros would just nope out [12:15:04 CEST] <sfan5> reversing would work better if it was done for each GOP: start with the last one, encode it reversed, go to the previous one [12:15:09 CEST] <sfan5> ffmpeg doesn't support any of this though [12:15:25 CEST] <JEEB> yea, going backwards efficiently is a special case [12:15:35 CEST] <JEEB> and generally with just FFmpeg you can't expect frame-exactness [12:15:44 CEST] <JEEB> (although with mp4 it will most likely be frame-exact) [12:15:51 CEST] <aaaa> :( [12:17:35 CEST] <aaaa> Would it work if the file was segmented to say 1 second clips and each one reversed separately and then join them together at the end? [12:17:59 CEST] <JEEB> it would require less buffering, but with an rpi I don't think you're gonna get far [12:20:15 CEST] <aaaa> Ok, I'll give it a go and see what happens. Thanks for your help [12:23:42 CEST] <King_DuckZ> hey guys, I've finally got something up, this was really messy and hard [12:24:18 CEST] <King_DuckZ> now my video looks mostly ok, except for some crazy colours appearing where highlits should be [12:24:43 CEST] <King_DuckZ> like bright magenta, yellow and such - any idea of what might be causing this? [12:24:58 CEST] <King_DuckZ> my input is rgb24, output is yuv422p [12:25:41 CEST] <sfan5> what are you decoding it with? [12:25:59 CEST] <King_DuckZ> I can change those, I just picked two random ones but it's not like I must use them - however my input is RGB [12:26:39 CEST] <King_DuckZ> sfan5: nothing, input comes from separate still images (jpg, png...) which I load with openimageio [12:26:49 CEST] <sfan5> the final video, i mean [12:28:31 CEST] <King_DuckZ> sfan5: you mean what I'm using to watch it? mplayer [12:29:12 CEST] <sfan5> that should handle 4:2:2 fine [12:29:59 CEST] <King_DuckZ> should I use something else instead of 422? [12:30:15 CEST] <sfan5> you can give yuv420p a try to see if that fixes it [12:30:21 CEST] <King_DuckZ> ok [12:52:27 CEST] <King_DuckZ> uhm no, that just breaks my code when I select the dnxhd codec, and with h264 it just shows the same green/magenta/blue bands in the sky and in lit areas [12:52:56 CEST] <King_DuckZ> I'm sure mplayer is right and my code is wrong, though I don't see how [12:59:13 CEST] <King_DuckZ> maybe a better question would be: how do I make any sense out of all the pixelformats in the enum, and how do I know which one can be used? [14:02:23 CEST] <mort> Weird question: when converting a png to a yuv (nv12) with ffmpeg, is there a way to set the number of bytes per line? [14:02:34 CEST] <mort> using the CLI [14:27:57 CEST] <DHE> you're saving to rawvideo? [14:28:00 CEST] <utack> is there anything that can be done here? "[png @ 0x557e39382b00] [IMGUTILS @ 0x7f8430390300] Picture size 21465x31581 is invalid [14:28:00 CEST] <utack> " [14:28:12 CEST] <utack> is the size too large, or the uneven pixel number a problem? [14:28:50 CEST] <DHE> I'd try the uneven pixel thing first. the resolution is large but not unreasonably so [14:29:29 CEST] <sfan5> 2.5GiB is pretty large, wouldn't surprise me if there was a sanity check put in for that [14:29:46 CEST] <sfan5> s/GiB/GiB per frame/ [14:37:59 CEST] <DHE> looking at the source where that error comes from, it looks like it is a memory allocation limit... [15:17:40 CEST] <utack> thanks DHE sfan5 [15:17:54 CEST] <utack> not a fan of resizing to evne pixels but i will try [16:07:36 CEST] <aaaa> I managed to reverse the video by extracting all the frames and joining them in reverse. Its a bit slower but works [16:33:42 CEST] <DHE> aaaa: that's going to be the best way without some kind of custom solution. like the batching by GOP which still requires a lot of RAM or disk space for buffering [17:02:07 CEST] <aaaa> DHE: Yeah it seems to be working well. I did try increasing swap space (can't add more ram as its a raspberry pi) but I underestimated the amount of ram it actually uses so abandoned that idea.. [17:51:08 CEST] <King_DuckZ> I want to give my program's users the ability to pipe my output into ffmpeg, I normally have RGB frames one at time, how should I output them so that ffmpeg will understand data across the pipe? [17:51:41 CEST] <furq> as rgb frames one at a time [17:51:59 CEST] <furq> if you want your users to not have to specify the frame size, pixel format etc then it's a bit tricker [17:53:23 CEST] <TheAMM> NUT is a simple container ffmpeg understands, so that's one solution to ez piping [17:53:39 CEST] <TheAMM> However I don't consider NUT all that simple to implement [17:53:40 CEST] <King_DuckZ> furq: that would be ideal... I can change pretty much anything quite easily on my buffers - planar or interleaved, alignment, bit depth... [17:53:47 CEST] <furq> there are much simpler ways than nut [17:53:52 CEST] <furq> unless your program links to lavf [17:53:55 CEST] <TheAMM> Do tell [17:54:09 CEST] <furq> i'd probably just output a sequence of bmp/tiff frames or something [17:54:12 CEST] <TheAMM> Because I'm still half-looking for piping frames with timestamps [17:54:19 CEST] <furq> oh right [17:54:22 CEST] <furq> yeah that doesn't help with timestamps [17:54:30 CEST] <furq> y4m would be another way but obviously it doesn't work with rgb [17:55:12 CEST] <King_DuckZ> hold on, bmp? you mean the actual windows format, with headers, 4-byte aligned scanlines and all? [17:55:44 CEST] <furq> i do mean that but it doesn't necessarily have to be bmp [17:55:55 CEST] <furq> whatever the simplest image format that image2 will accept is [17:57:07 CEST] <King_DuckZ> I can do bitmap... just wondering if there's any case where I'd want to use more than 8bpp, because bmp is capped to that irrc [17:57:09 CEST] <King_DuckZ> iirc [17:59:03 CEST] <furq> maybe ppm would be simpler [17:59:24 CEST] <furq> you'd still have to specify input framerate in ffmpeg [18:01:14 CEST] <King_DuckZ> that's fine, odds are original input comes from an image sequence, 1 frame per file, so users would have to specify the frame rate anyways [18:01:29 CEST] <King_DuckZ> what is ppm tho? [18:01:43 CEST] <furq> portable pixmap [18:01:45 CEST] <furq> part of netpbm [18:02:02 CEST] <furq> iirc it's a simple header and then just rgb24 data [18:03:08 CEST] <King_DuckZ> ok I found some resources on ddg, thanks for the help! :) [18:03:44 CEST] <furq> it's annoying that there's no rgb extension for y4m [18:03:46 CEST] <furq> that'd be perfect otherwise [18:04:14 CEST] <King_DuckZ> what format would that need? YUV? [18:04:20 CEST] <furq> any yuv rawvideo, yeah [18:05:20 CEST] <King_DuckZ> hm I can write code to convert to YUV... it's probably a bit complicated, but in terms of run time, that conversion would happen anyways, one side of the pipe or the other, no? [18:05:32 CEST] <furq> depends what you're doing [18:05:42 CEST] <furq> or what your user is doing, rather [18:06:15 CEST] <King_DuckZ> who knows, this is a support-any-input/write-any-output kind of tool [18:12:45 CEST] <King_DuckZ> am I looking at the right thing? https://wiki.multimedia.cx/index.php?titel=YUV4MPEG2 [18:13:07 CEST] <King_DuckZ> https://wiki.multimedia.cx/index.php?title=YUV4MPEG2 sorry [18:13:15 CEST] <furq> yeah [18:14:07 CEST] <furq> http://vpaste.net/Y6ZlI [18:14:12 CEST] <furq> that's all the supported pixel formats [18:18:13 CEST] <King_DuckZ> those in the "use strict -1" list, are they also valid? [18:27:40 CEST] <podman> Hi there! Is the 'allowed_extensions' options only available when the input file is a hls manifest? I get "Option allowed_extensions not found." when including that option for other file types [19:03:31 CEST] <saml_> podman, https://www.ffmpeg.org/ffmpeg-all.html#hls-1 yeah it's for hls only [20:17:37 CEST] <chocolate-elvis> If someone wanted to emulate this cheezy Adobe Media Encoder setting, https://postimg.cc/image/w5xoyrmgn/ just -timecode and using [20:17:46 CEST] <chocolate-elvis> ; or . would work right? [20:25:42 CEST] <insonifi> hi, I want to use VAAPI along with VidStab filter, but can't figure out the correct filter chain. Is it at all possible? [20:27:00 CEST] <insonifi> here is the script I tried: https://pastebin.com/h20d3ptA [20:53:07 CEST] <Hello71> why bother with vaapi [20:53:27 CEST] <Hello71> oh, you want to *output* with vaapi [21:19:18 CEST] <insonifi> Hello71: because it does recompression 3-6 times faster :) No, I don't want to output. [21:19:35 CEST] <Hello71> encode [21:19:44 CEST] <Hello71> and also much worse, but whatever [21:25:33 CEST] <DHE> hardware encoding is very fast, but loses to software encoders like x264 even on the default "medium" settings [21:44:43 CEST] <kerio> hardware encoding is useful if you're encoding at crazy high bitrates for later reencoding [21:45:00 CEST] <kerio> like, if you're saving a video stream on an embedded device [21:45:19 CEST] <kerio> or a computer as a background task (game recording, for instance) [21:45:27 CEST] <kerio> otherwise, it's just shite [22:25:53 CEST] <fsphil> hey all. I've been using av_frame_get_best_effort_timestamp() and noticed it's marked as deprecated, what's the replacement? just read the pts value from AVFrame? [22:27:05 CEST] <JEEB> fsphil: `git grep -B5 "av_frame_get_best_effort_timestamp"` in the FFmpeg source directory [22:29:24 CEST] <JEEB> basically the AVFrame structure has a field called like that, and it can just be accessed as-is [22:29:37 CEST] <JEEB> if you need that specific field as opposed to just the pts/dts [22:31:13 CEST] <fsphil> oh yes, best_effort_timestamp, I'd missed that one [23:54:54 CEST] <figgisfiggis> Hi! Any hevc guys around? Im trying to extract the qp-map for hevc on a x86 system but I'm lost in the code. It's simple for H.264 with everything gathered nicely in mpeg.c. No debug information implemented yet for hevc... [00:00:00 CEST] --- Sat Jul 14 2018

1 0

ffmpeg-devel.log.20180712
by burek 13 Jul '18

13 Jul '18

[00:06:34 CEST] <cone-553> ffmpeg 03Ruiling Song 07master:48a1abed133d: lavfi/opencl: add macro for opencl error handling. [00:06:35 CEST] <cone-553> ffmpeg 03Ruiling Song 07master:923ee63d6cd1: lavfi/vf_avgblur_opencl: remove useless clFinish(). [00:18:35 CEST] <cone-553> ffmpeg 03Danil Iashchenko 07master:2bdb6b64969f: lavfi/avgblur_opencl: fix using uninitialized value [01:29:06 CEST] <cone-553> ffmpeg 03Michael Niedermayer 07master:c995e01b1e01: avformat/mov: remove modulo operations from mov_estimate_video_delay() [01:29:07 CEST] <cone-553> ffmpeg 03Michael Niedermayer 07master:3ce4034308a3: avformat/mov: Eliminate variable buf_size from mov_estimate_video_delay() [02:56:56 CEST] <gnafu> Someone in another channel asked about AV1 in Ogg, and it got me thinking: Anyone working on AV1 in NUT yet? [09:31:33 CEST] <cone-780> ffmpeg 03Zhong Li 07master:3c26ce464435: lavc/qsv: handle MFX_FRAMETYPE_UNKNOWN case [10:50:50 CEST] <atomnuker> gnafu: its just a matter of adding a fourcc code to libavformat/nut.c [11:33:24 CEST] <jkqxz> ZhongLi: For the patch above, what is the case where you get UNKNOWN? That seems pretty weird. [12:42:59 CEST] <gagandeep> kierank: i am using update_thread_context to pass the buffer with coefficients to 2nd thread and then once all the buffers are allocated ff_thread_finish_setup [12:43:15 CEST] <gagandeep> pass the buffer pointers i mean [12:43:18 CEST] <kierank> Ok [12:44:38 CEST] <gagandeep> the rest of the context is copied right, or i have to copy the context myself on using update context [14:13:32 CEST] <gnafu> atomnuker: Is it really that simple? [14:17:22 CEST] <atomnuker> yeah, its not complicated, its the same as adding support for av1 in matroska [14:17:56 CEST] <atomnuker> though some people seem bent on overcomplicating that and having a special, non-standard mapping of av1 in matroska for no good reason [14:17:59 CEST] <nevcairiel> you should check how much the matroska people are d iscussing this to death [14:18:37 CEST] <atomnuker> I haven't heard anything since the original proposal which insisted on annexb, not on the mailing list anyway [14:18:53 CEST] <nevcairiel> you must not be on the right mailing list [14:19:01 CEST] <nevcairiel> but the annexb thing was killed anyway [14:19:17 CEST] <atomnuker> I am on the main av1 one, but not on the cellar one [14:19:54 CEST] <nevcairiel> latest version can be read here anyway https://github.com/Matroska-Org/matroska-specification/blob/av1-mappin/code…, plus changes in the commits of course [14:19:59 CEST] <atomnuker> yeah, just saw [14:20:06 CEST] <atomnuker> 39 commits since I first saw it [14:20:10 CEST] <j-b> atomnuker: the spec has been updated with remarks from cellar, the main ML, the IRC logs [14:20:20 CEST] <j-b> atomnuker: we plan to make it official at the same time as the MP4 one. [14:24:09 CEST] <atomnuker> j-b: do you know if there's been any development on any list/irc about having more accurate timestamps? [14:25:05 CEST] <j-b> atomnuker: I have seen no discussion about timestamps since a long time. [14:25:14 CEST] <j-b> (for AV1) [14:25:20 CEST] <j-b> or are you talking about MKV? [14:25:54 CEST] <atomnuker> mkv [14:26:03 CEST] <nevcairiel> i mentioned this the last time, you can have like nanosecond timestamps, that should be plenty? =p [14:26:25 CEST] <j-b> atomnuker: yes, of course. [14:26:33 CEST] <j-b> atomnuker: but noone cared much, IIRC. [14:26:41 CEST] <j-b> atomnuker: it's trivial to make, if you want. [14:27:07 CEST] <atomnuker> nevcairiel: wat? matroska still requires millisecond precision timestamps, no? [14:27:14 CEST] <nevcairiel> not at all [14:27:50 CEST] <atomnuker> you can't use a timebase which isn't 1/1000 when muxing, else everything breaks [14:28:03 CEST] <nevcairiel> if thats even true, then its not matroskas problem [14:28:22 CEST] <nevcairiel> it allows up to full nanosecond precision [14:28:28 CEST] <nevcairiel> although thats probably a bit overkill [14:29:23 CEST] <nevcairiel> you can set the TimecodeScale value in the mkv header to indicate the scale of the timestamps relative to nanoseconds, ie. the default scale of 1000000 means every timestamp increment is 1ms [14:29:31 CEST] <nevcairiel> so if you used a TimecodeScale of 1, it would only be 1ns [14:31:42 CEST] <atomnuker> put_ebml_uint(pb, MATROSKA_ID_TIMECODESCALE, 1000000); [14:31:55 CEST] <atomnuker> grr, this blows [14:31:58 CEST] <nevcairiel> blame the muxer, not the format :) [14:33:36 CEST] <atomnuker> j-b: anyway, what's the difference currently between webm and matroska av1 mapping? shouldn't both be basically identical [14:33:48 CEST] <nevcairiel> they will be [14:33:55 CEST] <nevcairiel> there is no official webm mapping yet [14:34:09 CEST] <nevcairiel> what aomenc currently produces is just a random file with no official menaing [14:34:11 CEST] <j-b> atomnuker: they will be 100% the same. [14:34:32 CEST] <j-b> but the issue is that currently both avformat and aomenc are not respecting the spec when producing webm [14:35:58 CEST] <nevcairiel> i dont think avformat can even produce webm/mkv with av1 [14:37:01 CEST] <nevcairiel> not webm at the very least since there are codec checks [14:38:20 CEST] <j-b> ok, I might have misunderstood. [14:38:32 CEST] <j-b> I was waiting for james av1/mp4 patches to be merged :) [14:45:52 CEST] <durandal_1707> atomnuker: i dont see noise reduction code in main opus, only in experimental branch, also who is working on porting that code? [14:55:59 CEST] <atomnuker> not me right now, I'm working on ffv2 and the lavu mdcts, you can go ahead and port that to a filter [14:56:17 CEST] <atomnuker> I thought it was merged in libopus git master, I guess it hasn't [14:56:29 CEST] <atomnuker> I'll ask jmspeex if he intends to [14:57:18 CEST] <atomnuker> j-b: oh, ok, I thought webm mapping was already defined (since we've been using it as a container since the codec was started) [14:59:29 CEST] <j-b> atomnuker: it is invalid and wrong, so no. [20:44:47 CEST] <gagandeep> guys, when using update_thread_context, do i also manually need to write code inside this funcition to copy the avctx or just the part i want to be changed? [20:52:15 CEST] <gagandeep_> nevermind, in pngdec.c, it isn't done so i am assuming this function is only to change relevant avctx parts [22:59:38 CEST] <jkqxz> Are there any official AV1 test streams yet? [23:01:03 CEST] <TD-Linux> no, not yet. [23:03:43 CEST] <jamrial> libaom downloads some [23:03:50 CEST] <jamrial> when you run the tests [23:04:05 CEST] <jamrial> https://aomedia.googlesource.com/aom/+/master/test/test_vectors.cc [23:05:01 CEST] <jamrial> jkqxz: ^ [23:05:03 CEST] <gnafu> See also: https://aomedia.googlesource.com/aom/+/master/test/test_vectors.cc [23:05:05 CEST] <jamrial> feature coverage is not too great, though. for example, none seem to use delayed random access points [23:05:17 CEST] <gnafu> Oops [23:05:24 CEST] <gnafu> Meant: http://storage.googleapis.com/aom-test-data [23:05:54 CEST] <gnafu> I believe running 'make testdata' downloads all of the current test files. [23:05:55 CEST] <jamrial> no 12bit samples, no still picture (with or without reduced header) [23:05:57 CEST] <TD-Linux> those are the same files. and yeah they don't cover much of the important stuff to test in ffmpeg (seeking) [23:06:02 CEST] <TD-Linux> their codec coverage isn't good either [23:09:04 CEST] <kierank> GOOG should just pay argon to publish them [23:09:41 CEST] <atomnuker> I think argon is basically google [23:09:42 CEST] <jkqxz> Hmm, yeah. I guess they're coverage for size and quantisation edge cases, but not much else? [23:12:35 CEST] <jamrial> one intra-only sample and that's it, yeah [23:17:21 CEST] <kierank> 10:09:39 PM <"atomnuker> I think argon is basically google [23:17:22 CEST] <kierank> atomnuker: ? [23:18:29 CEST] <gnafu> Je suis Google? [23:34:01 CEST] <atomnuker> kierank: well they have a weird relationship, I think google invested quite a bit in them [23:34:49 CEST] <atomnuker> and afaik hired them and even reduced the entry requirements to get into aom to do work on av1 [23:36:14 CEST] <kierank> atomnuker: hired maybe but the public record doesn't show google investment [23:37:22 CEST] <atomnuker> dunno then, I always have had the impression they had some relation to google [23:37:52 CEST] <kierank> maybe spent a lot [23:37:59 CEST] <kierank> the public record is a bit old though [23:49:52 CEST] <kierank> nevcairiel: not sure what carl is asking for [23:49:55 CEST] <kierank> he's asking for 264 [23:51:22 CEST] <jkqxz> jamrial: <http://ixia.jkqxz.net/~mrt/ffmpeg/av1/0002-lavc-Add-coded-bitstream-read-wr…> [23:52:44 CEST] <jkqxz> Not complete but does implement a working av1_metadata filter. (I think it needs a full set of streams and traces from something else to compare with to finish with confidence that it's actually right.) [00:00:00 CEST] --- Fri Jul 13 2018

1 0

ffmpeg.log.20180712
by burek 13 Jul '18

13 Jul '18

[02:03:45 CEST] <Polochon_street> Hey! I'm trying to make a spectrogram out of what my audio card is playing, and I've managed to put the spectrogram into a video file, but any idea how I could directly play it in a window? [02:03:49 CEST] <Polochon_street> right now, I have: [02:03:50 CEST] <Polochon_street> ffmpeg -f pulse -i alsa_output.usb-DAC_FOR_USB_FOCAL_XS-00.analog-stereo.monitor -filter_complex "showspectrum=s=1280x480:scale=log" coucou.avi [02:11:01 CEST] <Polochon_street> okay, it works doing ffmpeg -f pulse -i alsa_output.usb-DAC_FOR_USB_FOCAL_XS-00.analog-stereo.monitor -filter_complex "showspectrum=scale=log" -f matroska - | ffplay - [02:11:06 CEST] <Polochon_street> but I have 2s of latency for some reason [02:11:28 CEST] <furq> matroska defaults to x264 [02:11:36 CEST] <furq> you probably want -c:v rawvideo [02:11:47 CEST] <furq> and ffplay -fflags nobuffer or mpv --cache=no [02:12:03 CEST] <furq> or --no-cache rather [02:13:07 CEST] <Polochon_street> furq: you mean, dropping the -f matroska? [02:13:12 CEST] <furq> no keep that [02:13:21 CEST] <furq> or -f nut [02:13:25 CEST] <Polochon_street> ffplay -fflags nobuffer adds 5 seconds of delay for some reason [02:14:25 CEST] <Polochon_street> okay, it works fine with the nobufer + nut, thanks :) [02:14:36 CEST] <Polochon_street> obviously, the video quality sucks a bit, but I can probably manage [02:15:58 CEST] <furq> it shouldn't suck with rawvideo [02:16:09 CEST] <furq> unless it's just ffplay generally looking shit [02:16:14 CEST] <furq> it'll do that on account of it's not very good [02:16:34 CEST] <Polochon_street> I used -f nut, but I don't know where to put the -c:v rawvideo :x [02:16:47 CEST] <furq> between the input and the output [02:17:25 CEST] <Polochon_street> indeed [02:17:28 CEST] <Polochon_street> thanks! :D [02:33:55 CEST] <chocolate-elvis> hey, I have a client who needs a mpeg-2 program stream with a specific GOP structure such as IBBPBBPBBPBBPBB, and needs to be M=3, N=15. anyone have a clue as to how to specify this? possible? [02:56:36 CEST] <furq> if M is bframes and N is gop size then -bf 3 -g 15 [03:00:40 CEST] <DHE> I thought it was number of bframes in which case shouldn't it be 2 for that pattern? [03:02:48 CEST] <chocolate-elvis> thanks for that! [03:12:03 CEST] <chocolate-elvis> DHE I think you're correct [06:08:48 CEST] <kepstin> also make sure you leave -b_strategy at the default value 0. Values >0 enable dynamic B frame modes that'll make it not strictly follow the sequence you want. [06:10:59 CEST] <kepstin> is that GOP structure you want in PTS order? [06:14:20 CEST] <kepstin> it must be, if the inital sequence is IBBP [10:11:32 CEST] <Nacht> Am I correct to assume NetVC isn't a new codec on it's own, but only IETF selecting either Dalaa, Thor or AV1 to be their official codec ? [10:34:46 CEST] <erwu> Hello ;-) [10:41:27 CEST] <erwu> I [10:41:57 CEST] <erwu> I'm having some problem with ffmpeg understanding: https://stackoverflow.com/questions/51295370/stream-frame-from-video-to-pip… anyone ever challenged similar task ? [10:43:20 CEST] <squ> you have to split project into questions [10:43:23 CEST] <squ> and ask [10:48:48 CEST] <erwu> I have 2 main problems : Creation of pipe under windows and communication with it from C++ level. I guess that cv::VideoWriter can handle that task. But to be honest It's a bit unclear for me how can I define pipes. [12:05:50 CEST] <King_DuckZ> 'morning [12:13:06 CEST] <King_DuckZ> I got a debug build of ffmpeg 3.3.7 yesterday, and stepping inside av_frame_get_buffer() I could see that buffers inside the data[] array only get allocated if the pixel format has certain flags set [12:13:57 CEST] <King_DuckZ> frame.c:208 - if (desc->flags & AV_PIX_FMT_FLAG_PAL || desc->flags & AV_PIX_FMT_FLAG_PSEUDOPAL) { [12:14:56 CEST] <King_DuckZ> so I don't understand... was that intended behaviour in 3.3? if so, what do I have to set my buffer formats to, so that all the necessary buffers get allocated correctly? [12:20:21 CEST] <King_DuckZ> or is align=0 the thing causing all the troubles here? should I just set that to 16 or something? [13:52:08 CEST] <King_DuckZ> anything to say about my findings, anyone? [16:06:37 CEST] <King_DuckZ> anyone around? [16:07:10 CEST] <Nacht> Yes, but I have no idea what the C code all does [16:07:47 CEST] <King_DuckZ> :( [16:13:44 CEST] <atomnuker> King_DuckZ: check your build, no, no and no, none of this is intended, the API is identical between 3 and 4 [16:13:56 CEST] <atomnuker> alignment does nothing [16:15:56 CEST] <atomnuker> and make sure your frame->format is something sane and not a hardware frame [16:17:29 CEST] <King_DuckZ> atomnuker: yet setting align to 16 fixes my crash - if you look at the code align=0 causes most code in that function to be skipped [16:18:23 CEST] <King_DuckZ> I tried some formats but I had no luck, the one I've settled on to is 0 I think... let me find it in my code... [16:19:04 CEST] <King_DuckZ> YUV420P [16:19:38 CEST] <King_DuckZ> which again, works with ffmpeg 4.0.1 [16:21:20 CEST] <atomnuker> what are the width and height? [16:22:36 CEST] <atomnuker> if alignment fixes the issues you can use the value from av_cpu_max_align() [16:22:44 CEST] <atomnuker> which is the default alignment in case align is 0 [16:24:16 CEST] <King_DuckZ> width=3280 height=1550 but I think I tried other values as well, like 1024x512 [16:24:23 CEST] <King_DuckZ> ok, I'll set it to that then [19:55:01 CEST] <ksk> hola [19:57:37 CEST] <ksk> I try to convert some mp3 to lower quality, which has worked countless times for me, using this simple setup: "ffmpeg -i "${input}" -codec:a libmp3lame -b:a 48k -ac 1 "${output}" [19:57:40 CEST] <ksk> " [19:58:27 CEST] <ksk> however, when I use it on specific input ffmpeg starts, but does not count any bytes and does not write anything (though it is running). The input in question is the following: http://paste.debian.net/1033456/ (ffmpeg -i output) [19:58:31 CEST] <ksk> any Idea whats wrong? [20:17:00 CEST] <ksk> mhhm, I added "-codec:v copy" and now its transcoding. [20:17:16 CEST] <ksk> iirc I had mp3s with covers attached in the past, but these went fine without any of this. [21:14:21 CEST] <new2ffmpeg> Hi all [21:14:26 CEST] <new2ffmpeg> I am new to ffmpeg [21:15:02 CEST] <new2ffmpeg> I tried to convert a mkv file to mp4 file. ffmpeg -i input.mkv -c copy ouput.mp4 [21:15:26 CEST] <new2ffmpeg> I get the following [21:15:46 CEST] <new2ffmpeg> Could not find codec parameters for stream 1 (Video: mjpeg, none(bt470bg/unknown/unknown), 1920x1080): unspecified pixel format Consider increasing the value for the 'analyzeduration' and 'probesize' options [21:16:09 CEST] <new2ffmpeg> Can someone help me through this? [21:20:12 CEST] <ChocolateArmpits> new2ffmpeg, you can try doing it like it says [21:21:07 CEST] <ChocolateArmpits> put this before -i: -analyzeduration 20000000 [21:21:09 CEST] <atomnuker> its a broken file, blame mp4 [21:21:41 CEST] <kepstin> the input is mkv tho? [21:23:34 CEST] <atomnuker> well its still somewhat broken if it doesn't get probed properly [21:25:22 CEST] <new2ffmpeg> I included -analyzeduration 20000000 [21:25:38 CEST] <new2ffmpeg> I got the following [21:25:39 CEST] <new2ffmpeg> Stream #1: not enough frames to estimate rate; consider increasing probesize [21:25:55 CEST] <ChocolateArmpits> if 20 seconds isn't enough then nothing is [21:26:07 CEST] <ChocolateArmpits> new2ffmpeg, does the file play anywhere? [21:26:19 CEST] <new2ffmpeg> It plays on VLC [21:26:38 CEST] <ChocolateArmpits> what is your version of ffmpeg ? [21:27:09 CEST] <new2ffmpeg> 4.0.1 on a Mac [21:27:56 CEST] <ChocolateArmpits> How big is the file, do you know the bitrate? [21:28:03 CEST] <furq> new2ffmpeg: did you try increasing probesize [21:28:24 CEST] <ChocolateArmpits> instead of analyzeduration try -probesize 40000000 [21:28:29 CEST] <furq> well no set both [21:28:35 CEST] <furq> it'll stop at whichever is lower [21:28:58 CEST] <ChocolateArmpits> I treat them separately myself [21:39:44 CEST] <new2ffmpeg> The file is ~600MB in size [21:41:13 CEST] <new2ffmpeg> I tried that [21:41:16 CEST] <new2ffmpeg> got the smae [21:41:17 CEST] <new2ffmpeg> same [21:41:19 CEST] <new2ffmpeg> ffmpeg -analyzeduration 20000000 -probesize 40000000 -i Truck_FreewaySample1.mkv -c copy truck_n.mp4 ffmpeg version 4.0.1 Copyright (c) 2000-2018 the FFmpeg developers built with Apple LLVM version 9.1.0 (clang-902.0.39.2) configuration: --prefix=/usr/local/Cellar/ffmpeg/4.0.1 --enable-shared --enable-pthreads --enable-version3 --enable-hardcoded-tables --enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-gp [21:41:36 CEST] <new2ffmpeg> Sorry [21:41:37 CEST] <new2ffmpeg> [matroska,webm @ 0x7ffe78808e00] Could not find codec parameters for stream 1 (Video: mjpeg, none(bt470bg/unknown/unknown), 1920x1080): unspecified pixel format Consider increasing the value for the 'analyzeduration' and 'probesize' options [22:11:18 CEST] <Hello71> sounds like the input file is broken [22:53:32 CEST] <wlfgang> any pointers on doing hw-accelerated h264 encoding via the API? [00:00:00 CEST] --- Fri Jul 13 2018

1 0

ffmpeg-devel.log.20180711
by burek 12 Jul '18

12 Jul '18

[07:28:50 CEST] <cone-553> ffmpeg 03Steven Liu 07master:bd8a5c6b7ce7: avformat/hlsenc: improve compute after_init_list_dur [10:16:00 CEST] <thardin> hm no baptiste [11:23:32 CEST] <gagandeep> related to frame_threading: ff_thread_await_progress() only allows execution to start once 'all the previous threads' that had to use ff_thread_report_progress have reported the required progress number [11:24:23 CEST] <gagandeep> also the earlier threads that don't use report_progress for that same number are not considered for waiting? [11:24:46 CEST] <gagandeep> same number = progress int in report and await progress [11:26:21 CEST] <nevcairiel> every thread should always report progress when you use that model [11:26:40 CEST] <nevcairiel> and if its only a final progress report when its entirely done with the frame [11:27:09 CEST] <nevcairiel> although for performance its better to do it more fine-grained [11:28:32 CEST] <gagandeep> thanks, also for communicating buffer info b/w threads i need to use update_thread_context, or any other way? [11:29:31 CEST] <gagandeep> cause one thread in cfhd gets all the coefficients and i need to use 2nd thread to make it actually do something [11:32:48 CEST] <gagandeep> buffer in this case is NOT AVBuffer, but av_malloc buffer used to hold coefficients [13:01:22 CEST] <kierank> https://sorting.cr.yp.to/ [14:04:28 CEST] <memeka> hi ... [14:05:04 CEST] <memeka> when having decoder -> filter ... is it possible to know in the decoder that its output will go through a specific filter? [14:06:04 CEST] <memeka> or to access decoder->priv in the filter? [14:13:02 CEST] <cone-553> ffmpeg 03Jun Zhao 07master:09628cb1b4cc: avutil/pixelutils: correct the function name in comments [14:21:58 CEST] <nevcairiel> no thats not possible [14:22:05 CEST] <nevcairiel> those components are all separate [14:25:18 CEST] <memeka> nevcairiel: is there a way then to "signal" between them? [14:25:52 CEST] <nevcairiel> a tight coupling between such components is probably not a good idea in general [14:26:04 CEST] <memeka> nevcairiel: i want to do dmabuf between decoder and filter, so I need the filter to signal the decoder to export dmabuf .... [14:26:28 CEST] <nevcairiel> the filter does not control that, the outer layer (ie. the user) would indicate this [14:27:02 CEST] <memeka> nevcairiel: indicate it to the decoder? [14:27:46 CEST] <nevcairiel> yes [14:27:54 CEST] <memeka> can't it be done using AVPixelFormat? [14:28:26 CEST] <nevcairiel> thats how it is done, but filters cant tell decoders the format they want, decoders always deliver the format they have [14:29:14 CEST] <memeka> is there a way then for the decoder to know a filter is being used? [14:29:25 CEST] <nevcairiel> no [14:29:34 CEST] <nevcairiel> the user is responsible for setting this up [14:29:40 CEST] <nevcairiel> the filter and the decoder cannot talk to each other [14:30:24 CEST] <memeka> thx [14:35:13 CEST] <atomnuker> yep, the user can specify what output pixel format to use for decoding as well as filtering [14:37:53 CEST] <atomnuker> memeka: tbh I really think v4l decoders should always output dmabufs [14:38:28 CEST] <atomnuker> you can easily download them without going through lavfi if you want them to [14:38:57 CEST] <atomnuker> and on the devices that v4l decoders are available you don't have the speed needed to do operations on raw frames in ram [14:39:35 CEST] <memeka> atomnuker: i wonder, is it better then to have a filter that outputs the buffers? [14:39:46 CEST] <atomnuker> what? [14:39:54 CEST] <atomnuker> go system ram -> filter -> dmabuf? [14:40:02 CEST] <memeka> so the decoder is always dmabuf, and then there is a filter that takes in a dmabuf and gives you the content [14:40:17 CEST] <memeka> if you want it [14:40:37 CEST] <atomnuker> there's already a filter to get you a raw buffer in ram, its called hwdownload [14:41:05 CEST] <memeka> right... [14:41:36 CEST] <atomnuker> but we can't break behavior, by default hardware decoders decode to system ram [14:42:07 CEST] <atomnuker> using the command line you need to force them if you want to get a native zero-copy frame in device memory via -hwaccel_output_format <format> [14:42:50 CEST] <atomnuker> so what the decoder needs to do is detect whether the format is drmprime and if so output dmabufs [14:42:50 CEST] <memeka> how does the hardware decoder knows that? [14:43:28 CEST] <nevcairiel> it would call get_format2 and get told [14:43:36 CEST] <memeka> hmmm is there a way to activate a filter automatically? [14:44:15 CEST] <atomnuker> if you want to download a frame in the decoder to system ram you can use lavu's hwcontext functions [14:44:22 CEST] <atomnuker> no need for a filter [14:44:36 CEST] <memeka> atomnuker: i am thinking of v4l2 hardware scaler [14:44:50 CEST] <atomnuker> absolutely no filters in lavc, thank you very much [14:44:55 CEST] <memeka> so you get the drmprime, you do scaling, then send another drmprime [14:45:25 CEST] <jdarnley> Aren't there already some HW scalers you can steal from to do that? [14:45:45 CEST] <atomnuker> yep, plenty, libavfilter/vf_scale_(vaapi/cuda/qsv).c [14:45:53 CEST] <memeka> would they be activated automatically on DRMPRIME ? [14:46:02 CEST] <nevcairiel> no [14:46:36 CEST] <atomnuker> you need to add any and all hardware filters manually [14:46:37 CEST] <nevcairiel> zero-copy hardware chains require the user to properly set it up [14:46:40 CEST] <nevcairiel> for all hardware variants [14:47:18 CEST] <jdarnley> Here the user means either the user of the command line or the user of the libraries. [14:47:31 CEST] <memeka> yeah i understand [14:47:44 CEST] <memeka> so you can't make it invisible .... [14:49:52 CEST] <jdarnley> Invisible to whom? You can probably hide it all from the end user by making your program smart enough. [14:51:51 CEST] <memeka> jdarnley: invisible to existing software :) [14:52:18 CEST] <nevcairiel> proper hardware usage does require software aware of it [14:54:56 CEST] <atomnuker> yep, with very good reason - downloading and uploading is very expensive generally, so that's definitely not something that can be done without the API user's knowledge [00:00:00 CEST] --- Thu Jul 12 2018

1 0

ffmpeg.log.20180711
by burek 12 Jul '18

12 Jul '18

[00:21:33 CEST] <nicolas17> how do I get the number of video frames in a file with ffprobe? [00:22:20 CEST] <nicolas17> there might be dropped frames (VFR?) so I can't just multiply duration by 30 [00:25:12 CEST] <nicolas17> hrm "ffprobe -select_streams v -count_frames -show_entries stream=nb_read_frames" seems to work, although the output format is suboptimal [00:25:44 CEST] <nicolas17> it also takes almost a second for a 10s video [00:28:23 CEST] <nicolas17> this is stupid, "ffmpeg -vcodec copy -an input.mp4 output.mp4" is orders of magnitude faster than ffprobe counting frames o.O [00:30:41 CEST] <furq> nicolas17: count_frames requires decoding the stream [00:30:46 CEST] <furq> stream copying doesn't [00:31:31 CEST] <nicolas17> stream copying knows the frame count [00:31:41 CEST] <nicolas17> it's shown in the status bar [00:32:00 CEST] <JEEB> amount of packets. in mp4 most likely amounts to amount of frames [00:32:07 CEST] <JEEB> aka -show_packets in ffprobe [00:32:25 CEST] <nicolas17> so ffmpeg's "frame=297132" in the final status bar could be inaccurate? [00:32:33 CEST] <JEEB> with -c copy, yes [00:32:58 CEST] <JEEB> of course for most formats you have some sort of parser etc [00:32:58 CEST] <furq> some containers will give a result for nb_frames in ffprobe [00:32:58 CEST] <nicolas17> boo [00:33:08 CEST] <furq> which doesn't require count_frames [00:33:13 CEST] <JEEB> so each packet is some sort of "frame" [00:33:27 CEST] <furq> mediainfo also has a frame count output but i assume it has the same restrictions [00:33:33 CEST] <furq> it might be worth investigating that further though [00:33:53 CEST] <nicolas17> with this .ts I get: [00:33:54 CEST] <nicolas17> nb_frames=N/A [00:33:56 CEST] <nicolas17> nb_read_frames=300 [00:33:57 CEST] <nicolas17> nb_read_packets=N/A [00:33:59 CEST] <nicolas17> and nb_read_frames is only filled in if I use -count_frames [00:34:18 CEST] <furq> yeah mpegts definitely isn't one of those containers [00:34:23 CEST] <CoderDawson> JEEB: I added code to set the JVM prior to attempting to open the codec and the av_jni_set_java_vm call succeeds (return code 0). However, the call to avcodec_open2 is now returning -1 (Operation not permitted). Any thoughts when you get a chance? [00:34:24 CEST] <JEEB> no index [00:34:28 CEST] <furq> ^ [00:34:49 CEST] <JEEB> nicolas17: anyways if you want quick and close enough [00:34:55 CEST] <JEEB> count_packets [00:35:06 CEST] <JEEB> lol [00:35:48 CEST] <nicolas17> I love you too, freenode >:( [00:37:28 CEST] <nicolas17> yeah count packets will do [00:37:35 CEST] <nicolas17> I just found a .ts with dropped frames [00:37:48 CEST] <nicolas17> duration=10.000333 [00:37:50 CEST] <nicolas17> nb_read_frames=247 [00:37:51 CEST] <nicolas17> nb_read_packets=247 [00:40:11 CEST] <nicolas17> stream|nb_read_packets=297132 [00:40:13 CEST] <nicolas17> real 0m4.213s [00:41:16 CEST] <nicolas17> now to shred my hard disk reading 100GB of video [00:45:54 CEST] <nicolas17> ext4 lets me defragment individual files but there's no way to make separate files (such as a thousand .ts files) contiguous... [00:46:02 CEST] <nicolas17> that'd be nice [09:30:05 CEST] <newuserhere> hi [09:31:10 CEST] <newuserhere> Anybody here? [09:31:26 CEST] <azarus> sure [09:34:12 CEST] <newuserhere> I have a newbie question... I'm trying to download ffmpeg on OSX 10.6.3 and it doesn't seem to be working. Is this too olda OS? [09:34:22 CEST] <newuserhere> too old an OS [09:38:18 CEST] <JEEB> if it's someone's build then possibly yes [09:41:47 CEST] <newuserhere> I bought the computer with the OS installed around about 2009. It's a Mac Pro (old silver tower). [09:42:23 CEST] <azarus> newuserhere: try building it yourself https://trac.ffmpeg.org/wiki/CompilationGuide/macOS [09:42:42 CEST] <azarus> and/or a VM with a better supported OS ;) [09:42:46 CEST] <azarus> or upgrade your OS [09:45:39 CEST] <newuserhere> Thanks... I don't know if I'm competent to build it but I can try. I've downloaded from the official site, but when I unzip the file it there is nothing [09:46:05 CEST] <JEEB> there's no "official" builds ;) [09:46:17 CEST] <JEEB> officially you only get the source code [09:48:27 CEST] <newuserhere> Oh ! I was downloading from http://ffmpeg.org/download.html#releases [09:49:20 CEST] <azarus> newuserhere: with that guide i posted, it really shouldn't be too hard [09:49:31 CEST] <azarus> also, those release tarballs? [09:49:34 CEST] <azarus> those are just sources [09:50:53 CEST] <newuserhere> That's odd then... I unzip them and it looks like they're unzipping, but no files show up. [09:51:38 CEST] <azarus> what file did you download, exactly? [09:53:04 CEST] <newuserhere> ffmpeg-4.0.1.tar.bz2, ffmpeg-0.8.15.tar.bz2, and ffmpeg-0.5.15.tar.bz2. Tried three different ones. [09:53:16 CEST] <azarus> those aren't zip files [09:53:28 CEST] <azarus> those are bzip2'd tarballs [09:53:31 CEST] <newuserhere> But they should open with unarchiver right? [09:53:37 CEST] <azarus> dunno what that is [09:54:02 CEST] <azarus> but you can extract them with "tar xjvf <file>" [09:54:30 CEST] <newuserhere> Would I run that command in Terminal? [09:54:34 CEST] <azarus> sure [09:55:02 CEST] <newuserhere> I'll try it right now. [09:56:58 CEST] <newuserhere> Well something happened:) Should the files show up somewhere? [09:57:08 CEST] <azarus> yes [09:57:55 CEST] <newuserhere> Now I see them. In a folder. [09:58:19 CEST] <azarus> Good, you've sucessfully extracted the ffmpeg source code. [10:00:20 CEST] <newuserhere> So now I run Configure as a command? [10:00:31 CEST] <azarus> yes, follow the compilation guide [10:02:10 CEST] <newuserhere> "C compiler test failed" :( [10:02:18 CEST] <azarus> to be expected [10:02:24 CEST] <azarus> do you have a compiler? [10:02:44 CEST] <newuserhere> Not unless one came with the computer. [10:02:52 CEST] <azarus> likely not [10:03:10 CEST] <azarus> https://trac.ffmpeg.org/wiki/CompilationGuide/macOS#Xcode [10:03:27 CEST] <newuserhere> Oh well... I guess now I need to install a compiler [10:03:38 CEST] <azarus> (look at the link i posted) [10:03:54 CEST] <azarus> ... can you use brew? [10:06:54 CEST] <newuserhere> I've never used it before. [10:07:45 CEST] <azarus> you can use it to automate the install of ffmpeg and many other software [10:08:38 CEST] <newuserhere> I see. It looks like it's free. [10:11:09 CEST] <newuserhere> I think I'll try to install Xcode before trying Homebrew. [10:11:58 CEST] <azarus> yup you need xcode anyhow [10:12:19 CEST] <azarus> (but tbh I haven't used macOS in more than 5 years) [10:13:16 CEST] <newuserhere> This is all territory I've avoided previously... but now's as a good a time as any:) [10:13:33 CEST] <newuserhere> One more question... "make" and "make install" -- are those commands? [10:13:35 CEST] <azarus> it's fun, learning is always nice [10:14:06 CEST] <azarus> make is a program to "build" a program based on its source code dependencies [10:14:26 CEST] <azarus> "make install" installs the compiled result onto your computer [10:14:45 CEST] <JEEB> oh boy, 10.6 macos [10:14:47 CEST] <JEEB> and xcode [10:14:55 CEST] <JEEB> 10.6 is the last version which *only* has paid xcode [10:15:03 CEST] <JEEB> 10.7+ have freely available xcode [10:15:05 CEST] <azarus> aww :( [10:15:09 CEST] <azarus> didn't know that [10:15:18 CEST] <JEEB> and I do not recommend pirating it because it makes like zero sense [10:15:21 CEST] <newuserhere> Crap :) [10:15:37 CEST] <JEEB> and for some reason apple never made the paid version free even though all *newer* versions [10:15:39 CEST] <newuserhere> Well it's not that expensive... I hope... [10:15:40 CEST] <JEEB> were free [10:15:44 CEST] <JEEB> newuserhere: no, don't [10:15:45 CEST] <azarus> how about upgrading to 10.7? [10:16:04 CEST] <newuserhere> I would upgrade but I'm stuck because of legacy programs I need to run [10:16:12 CEST] <JEEB> newuserhere: it's free software which still costs like $100 on the apple store becuase you're on 10.6 [10:16:25 CEST] <azarus> thanks, apple! [10:16:26 CEST] <newuserhere> $100? Yuck [10:16:37 CEST] <JEEB> also even if you get it, you're building software with tools that are way out of support [10:16:56 CEST] <newuserhere> Maybe there's some free compiler I can get. [10:17:30 CEST] <JEEB> I wouldn't bet on it, unfortunately [10:17:42 CEST] <JEEB> 3rd parties are pretty much forced to drop compatibility as well [10:17:52 CEST] <JEEB> since Apple breaks things without much consideration [10:17:56 CEST] <newuserhere> BTW, when I enter "make" on Terminal it doesn't recognize the command [10:18:05 CEST] <JEEB> yea, make comes with the xcode toolset on Macs [10:18:16 CEST] <JEEB> xcode basically contains all the basic *nix tools [10:18:23 CEST] <JEEB> (for building softwarE) [10:18:29 CEST] <newuserhere> Jeeb, I see. And yep, Apple sure abandons their old products without a second thought [10:18:51 CEST] <azarus> newuserhere: maybe you can run a VM or something? [10:19:07 CEST] <newuserhere> Maybe. That's something else I've never tried, but it makes sense. [10:19:24 CEST] <azarus> what sort of computer is it, exactly? [10:19:25 CEST] <JEEB> I'd recommend running 10.6 in a VM on a newer macos [10:19:32 CEST] <JEEB> if you can upgrade [10:19:33 CEST] <azarus> or that, yup [10:19:40 CEST] <JEEB> and really require 10.6 [10:19:42 CEST] <JEEB> specifically [10:21:21 CEST] <furq> can you not still get xcode 3.2 for free on 10.6 [10:21:36 CEST] <furq> the macports docs seem to think you can [10:21:55 CEST] <newuserhere> I'll have to figure something out. This old OS is a pain. [10:22:09 CEST] <furq> also yeah you might want to look into macports in general [10:22:13 CEST] <furq> https://guide.macports.org/chunked/installing.html [10:22:19 CEST] <furq> this is the bit specific to xcode though [10:22:23 CEST] <newuserhere> It's a Mac Pro, the old silver tower model [10:22:40 CEST] <azarus> newuserhere: doesn't help much. exact computer model, CPU, whatever [10:23:30 CEST] <JEEB> furq: no [10:24:16 CEST] <JEEB> basically I remember specifically that if you tried to install xcode it'd just derp at you for $99 [10:25:45 CEST] <newuserhere> I see where it claims 3.2 is free, but I'll see if it's really true. [10:26:31 CEST] <newuserhere> Oh. 2 2.8 Ghz Quad-Core Intel Xeon. Memorty 8 Gb 667 Mhz RAM [10:28:02 CEST] <Mavrik> Shouldn't that still run a decently new macOS? [10:29:59 CEST] <newuserhere> Sure, but I have some software installed that will give me problems if I upgrade any further. Speiifally Final Cut Pro [10:33:14 CEST] <codebam> what would be the best -tune option for a screenrecord? animation? [10:33:19 CEST] <codebam> or stillimage? [10:38:11 CEST] <furq> probably stillimage [10:38:28 CEST] <codebam> okay, thank you [10:38:31 CEST] <furq> animation will lose some fine detail [10:38:41 CEST] <furq> you might want to tweak it beyond the default tuning though [10:39:06 CEST] <Mavrik> also avoid yuv420p [10:39:13 CEST] <Mavrik> since that makes colors look awful [10:39:26 CEST] <furq> it's difficult to avoid yuv420p but yeah [10:39:31 CEST] <furq> if at all possible then use 444 or rgb [10:39:41 CEST] <codebam> furq: but I need that for it to be playable on android, don't I? [10:39:47 CEST] <furq> yeah [10:39:57 CEST] <furq> it might support 444 nowadays, idk [10:40:05 CEST] <furq> but generally speaking you need 420 for compatibility, especially with hwdec [10:40:28 CEST] <codebam> is rgb playable on android? [10:40:38 CEST] <codebam> I know 444 isn't, even on P [10:40:44 CEST] <furq> i doubt it [10:40:45 CEST] <Mavrik> Nope, 444 isn't reliably supported. [10:40:51 CEST] <Mavrik> I mean, it depends on HW, not ANdroid [10:40:56 CEST] <codebam> oh, okay [10:41:02 CEST] <furq> try and avoid coloured text then [10:41:15 CEST] <Mavrik> red colored text especially :) [10:41:41 CEST] <codebam> oh okay [10:41:45 CEST] <newuserhere> Hmm. Looks like Xcode 3.2 is no longer offered. [10:42:24 CEST] <furq> codebam: http://vpaste.net/lZzoA [10:42:25 CEST] <furq> fwiw [10:43:19 CEST] <furq> you definitely want deblock as low as possible but you probably also want high bframes and other stuff [10:43:22 CEST] <Mavrik> hmm, does vp9 support 444 modes? [10:43:27 CEST] <codebam> oh cool, thanks furq [10:43:38 CEST] <codebam> Mavrik: yes [10:44:07 CEST] <codebam> I know because I encoded with it earlier, it's much slower though because I don't have hardware vp9 support [10:44:11 CEST] <Mavrik> I wonder if that's a better choice for targeting Android :) [10:44:31 CEST] <newuserhere> I'm going to take off for now. This has been very helpful. Thanks! [10:44:37 CEST] <codebam> Mavrik: ideally yes, but it takes 5 mins to encode a 10 second clip [10:44:56 CEST] <Mavrik> That sounds a bit excessive... is that on device itself? [10:45:11 CEST] <codebam> no that's on my laptop because it doesn't have hardware support for vp9 [10:45:27 CEST] <codebam> and I don't have a gpu [10:45:31 CEST] <furq> that sounds about right for a laptop cpu with 1080p (or more) and no multithreading [10:45:43 CEST] <Mavrik> 5 minutes for 10s clip seems ridiculous for any kind of Intel chip O.o [10:45:45 CEST] <furq> but you probably want to tune -cpu-used and also make sure you have the latest libvpx with row-mt [10:45:56 CEST] <furq> remember vpx doesn't multithread at all unless you tell it to [10:45:58 CEST] <codebam> I have multithreading, i7 4 core 8 thread 2720qm [10:46:09 CEST] <codebam> it was on 8 threads [10:46:14 CEST] <codebam> still took 5 mins or so [10:46:28 CEST] <furq> if you mean -threads 8 then you'll want to make sure it was actually using them lol [10:46:35 CEST] <codebam> for 400 1366x768 frames [10:46:35 CEST] <furq> vpx's multithreading is a bit arcane [10:46:47 CEST] <furq> you ideally want to use 1.7+ and row-mt [10:47:39 CEST] <furq> and yeah try increasing -cpu-used [10:49:21 CEST] <codebam> I don't think it makes sense for me to encode vp9 on my cpu, I'm using this for a screenrecord script. So ideally it would be ready to send right after recording (or very shortly after) [10:49:59 CEST] <codebam> right now I have it setup with x264 yuv420p and the veryslow preset [10:50:10 CEST] <codebam> which takes about a second after recording to finish [10:50:55 CEST] <codebam> man I need to sleep [10:51:42 CEST] <furq> if 420 h264 looks ok then there's no reason to use vp9 [10:52:10 CEST] <codebam> yeah it's not too bad, like nothing I'd complain about [10:52:13 CEST] <furq> you probably want to explicitly clamp it at -level 41 for hwdec [10:52:22 CEST] <furq> otherwise i think veryslow at 768p will exceed it by default [10:52:39 CEST] <codebam> oh okay, thanks [11:12:23 CEST] <codebam> furq: what does -level 41 do? isn't -level for device compatibility? [11:12:47 CEST] <JEEB> yes, it limits the amount of memory required to decode your stream [11:12:55 CEST] <JEEB> things like reference frame max counts etc [11:13:03 CEST] <furq> yeah in this case it'll just clamp refs [11:13:08 CEST] <codebam> ohh okay [11:13:24 CEST] <codebam> why 41 though? all the examples are much lower. like 4.1 and 4.2 [11:13:40 CEST] <JEEB> 41 = 4.1 [11:13:41 CEST] <codebam> I just don't understand why I'd want that [11:13:43 CEST] <codebam> ohh [11:14:11 CEST] <codebam> okay, thank you [12:42:46 CEST] <King_DuckZ> hi, I'm still having problems with av_frame_get_buffer(pic, 0) not filling in any of the items inside pic->data[] [12:44:18 CEST] <atomnuker> set the frame width, height and format [12:44:46 CEST] <King_DuckZ> I'm having this problem only with our custom built ffmpeg on the production server, ffmpeg --version: 3.3.1 built with gcc 7.1.0 configuration: --prefix=/builds/ffmpeg/3.3.1/c53822b641 --enable-pic --enable-shared --enable-libopenjpeg --enable-libvorbis --enable-libvpx --enable-libx264 --enable-gpl --enable-libschroedinger --enable-libsnappy [12:44:59 CEST] <King_DuckZ> atomnuker: I did [12:45:48 CEST] <King_DuckZ> code works just fine with ffmpeg 4.0.1-2 from archlinux [12:47:07 CEST] <King_DuckZ> is there a bug in 3.3.1 maybe, or some difference in how objects are initialised, or any way to detect if it's a faulty build in some way? [12:47:27 CEST] <King_DuckZ> I'm really clueless on this [12:49:09 CEST] <atomnuker> no, make sure you're not linking to a different version to what you expect [12:49:27 CEST] <atomnuker> check the return value too [12:50:50 CEST] <King_DuckZ> I do, return value is 0 [13:29:14 CEST] <King_DuckZ> is there a function I can call to get the version of the ffmpeg library I'm using, as reported by ffmpeg --version? ie: something returning 3.3.1 [13:29:57 CEST] <BtbN> yes. [13:30:14 CEST] <atomnuker> avcodec_version() [13:30:41 CEST] <BtbN> Actually I'm not sure if there is one to get the ffmpeg version. But you can get each individual libraries version. [13:32:12 CEST] <King_DuckZ> ok, that should be enough, thanks [13:45:57 CEST] <DHE> yeah the libraries are versioned based mainly on the API/ABI compatibility levels [13:52:18 CEST] <King_DuckZ> yeah, I'm getting 58.18.100 in fact [13:52:41 CEST] <King_DuckZ> is there a way I can get the 3.3.1 string instead? [13:52:56 CEST] <King_DuckZ> ah 4.0 in this case [13:55:39 CEST] <DHE> have you tried av_version_info() ? (libavutil/avutil.h) [13:55:55 CEST] <DHE> docs say this should be it, but I haven't tried it myself [14:05:21 CEST] <King_DuckZ> DHE: yes, that's the string I was after, thanks! :) [14:06:37 CEST] <King_DuckZ> and that confirms my program is using 3.3.1 [15:12:18 CEST] <mabynogy-> hello [15:13:02 CEST] <mabynogy-> I wonder if it's possible to work in seconds for positions - like with the -ss switch [15:14:22 CEST] <ariyasu> can you give an example of what you mean? [15:15:01 CEST] <mabynogy-> ffmpeg -ss 42s for example [15:15:53 CEST] <ariyasu> give it a full time stamp -ss 00:00:42 [15:16:19 CEST] <ariyasu> you can use -t to specify a duration in seconds like -t 90 for 90 secconds from the time specified by -ss, [15:18:45 CEST] <mabynogy-> ok understood thanks ariyasu - I use -t after indeed [15:27:56 CEST] <furq> mabynogy-: -ss 42 works fine [15:28:02 CEST] <furq> or 1:42, or 1:23:42 [15:28:22 CEST] <furq> anything that takes a timestamp will accept any of those formats [15:30:42 CEST] <MrBeardyMan> I'm seeing an issue where ffmpeg/ffprobe 2.* (testing with an old 2.5 static build and the Ubuntu 16.04 ffmpeg 2.8 build) detect a video codec as Apple ProRes 422 and process it correctly, but ffmpeg 4.0.1 (static build downloaded via the ffmpeg download page) detect the codec as Avid DNxHD Codec and it then unable to process it - any suggestions? is this a known problem? [15:35:17 CEST] <mabynogy-> oh nice furq [15:36:20 CEST] <mabynogy-> and the position is 0 in my case, so -ss 0 -t 42 is nicer for me than 00:00:00 ... [15:45:59 CEST] <MrBeardyMan> poking around in a hex viewer the source video appears to list both Prores 422 & DNxHD codecs, ffmpeg 2 appears to use the first, ffmpeg 4 uses the second [15:48:24 CEST] <tuna> Hardware decoding issue....I am having two issues, they may be related...1) Not everytime, but most times avcodec_open sets my hw_frames_ctx within the codeccontext to null...2) My cuMemcpy2D returns invalid value...kinda makes me feel like my hwframe isnt being allocated properly.. [15:56:43 CEST] <tuna> However, I gave the hwframe the correct width, heigh sw_format==AV_PIX_FMT_NV12 and format ==AV_PIX_FMT_CUDA [15:58:11 CEST] <tuna> I am using ffmpeg to allocate two hardware frames...could this be the issue? I have a m_avBufferRefOutputFrame = av_hwframe_ctx_alloc(m_avBufferRefDevice) for the output of cuvid and m_avBufferRefOutputConvertedFrame = av_hwframe_ctx_alloc(m_avBufferRefDevice) for the out put of a color conversion kernal [16:21:56 CEST] <mabynogy-> I have my video excerpts working well now http://dailyprog.org/videos/ - thanks guys ariyasu furq :-) [17:07:09 CEST] <tuna> Hardware Decoding...what causes avcodec_open2 to remove the reference of the hw_frames_ctx and set it to null ? [17:11:43 CEST] <tuna> It also seems to shorten the 'size' field of the bufferref for the hwframe from 88 to 48...after it sets the reference it holds to null [17:13:38 CEST] <Hello71> isn't the default -ss 0 [17:17:35 CEST] <tuna> ? [17:19:41 CEST] <mabynogy-> probably yeah [18:05:27 CEST] <CoderDawson> Does av_mediacodec_alloc_context and av_mediacodec_default_init need to be called manually to get H.264 hardware video decoding to work in FFmpeg via MediaCodec? [18:06:42 CEST] <JEEB> not that I know [18:07:05 CEST] <JEEB> in mpv-android we just set the JVM [18:07:14 CEST] <JEEB> and then use the non-texture version [18:09:04 CEST] <CoderDawson> Bummer. Still getting a -1 (operation not permitted) return code from avcodec_open2 when setting the JVM before the call. [18:11:23 CEST] <CoderDawson> I added the av_jni_set_java_vm call to the JNI_OnLoad method of my plugin and it returns 0. Anything else I could be missing? [18:13:52 CEST] <CoderDawson> I only ask about the av_mediacodec* method call due to this older patch post https://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/191700.html showing "In order to do so the user needs to initialize the hwaccel through the use of av_mediacodec_alloc_context and av_mediacodec_default_init functions. The later takes a reference to an android/view/Surface as parameter." [18:33:46 CEST] <tuna> Why is avcodec_open2 nullifying its hw_frames_ctx on a return of 0 call to it? [18:34:59 CEST] <tuna> Looking through source for avcodec_open2 this makes no sense..... [18:36:53 CEST] <JEEB> CoderDawson: the texture/surface output mode IIRC might require that [18:38:08 CEST] <JEEB> CoderDawson: also older versions of the decoder used to use private APIs to get the JVM. that was quickly removed though because it was not kosher and newer versions of Android just didn't let you do that [18:41:01 CEST] <CoderDawson> Sorry, I must be confused. Is there another output mode for H.264 MediaCodec that is hardware accelerated? [18:43:08 CEST] <JEEB> you can either get YCbCr from the decoder as a RAM buffer, or an Android surface as RGB [18:43:47 CEST] <JEEB> the default I think is the mode that doesn't require Android surfaces [18:45:11 CEST] <CoderDawson> Perfect. I just need to figure out why I am getting the -1 from avcodec_open2 then. Any thoughts? [18:45:39 CEST] <JEEB> nope [18:46:34 CEST] <Mavrik> Is there a benefit of doing Java code - ffmpeg (native) - MediaCodec (java) - ffmpeg (native) dance on Android? [18:46:54 CEST] <Mavrik> (vs. invoking mediacodec directly) [18:48:55 CEST] <JEEB> a) you don't need to do the decoding code yourself b) you get it within the context of FFmpeg [18:49:07 CEST] <JEEB> thus f.ex. in mpv it was relatively easy to get hwdec going [19:49:38 CEST] <clanig> Hi. I have played around a little bit with kmsgrab as source for screen capture. Everything worked fine as long as the X- or Wayland session stayed the same but logging from Wayland to X and vice versa, as well as running ffmpeg on a tty and switching through tty or graphical display resulted in either ffmpeg to crash or having weird screen corruption in case of zapping ttys. My question is whether someone [19:49:40 CEST] <clanig> has had this running successfully so far. Have I done something wrong or is it just buggy? [19:49:59 CEST] <atomnuker> works fine here; its your system [19:50:13 CEST] <atomnuker> kmsgrab survives vt switcing and standby [19:52:49 CEST] <clanig> atomnuker: It's nice to hear that it does work as intended with the right settings. That means I will do further testing with several configurations. I hope very much that it's not related to VGA passthrough on the VM I was using because I don't have an option to change that for my purpose. [19:53:04 CEST] <nicolas17> if I wanted to grab a single frame from a video, by frame number, in O(1), what information should I cache? [19:53:38 CEST] <clanig> atomnuker: Thank you very much for your answer. [19:54:11 CEST] <nicolas17> I assume I can't seek to a specific frame number in a possibly-VFR .mp4... can I seek to a specific PTS, such that calculating the PTS of every frame and caching that list would help me later? [19:56:21 CEST] <kepstin> nicolas17: yes [19:59:22 CEST] <nicolas17> of course I still need to decode a whole GOP, but... [19:59:37 CEST] <nicolas17> that's still O(1) in video duration [20:00:50 CEST] <kepstin> (the lookup will then be O(whatever your lookup table is, probably log N) plus looking up the timestamp in the file's seek table (likely also somewhere in the neighbourhood of log N), plus some bounded overhead finding the exact frame within the gop [20:01:52 CEST] <nicolas17> anything is faster than decoding an hour of video while (frame_n < frame_wanted) :) [20:48:22 CEST] <Mavrik> nicolas17, the most help would be storing keyframes with their frame number and byte offset I guess [20:49:50 CEST] <JEEB> that sounds like what ffms2 does [20:50:06 CEST] <JEEB> if you need frame exact access to decoded frames [20:50:23 CEST] <JEEB> it already does the indexing etc [23:34:11 CEST] <mont3z> how can I depacketize a rtp stream without having them tied to the libavformat network IO? [23:36:03 CEST] <atomnuker> use the custom avio [23:36:38 CEST] <polysics> hello everyone! I have a system that is recording videos that cannot be seeked properly [23:36:53 CEST] <polysics> example: 30 seconds recording, mp4 format [23:37:25 CEST] <polysics> I seek to any time 0-9, goes to 0, 10-25 goes to 10, 25-30 goes t o25 [23:38:09 CEST] <polysics> what is happening here? can I somehow have ffmpeg fix that sequencing? [23:39:10 CEST] <mont3z> @atomnuker: thx, can you point me to some example of use of the custom avio [23:39:27 CEST] <ariyasu> it's your key frame interval polysics [23:40:12 CEST] <polysics> ariyasu: can I somehow re-encode that so all frames have it? [23:40:49 CEST] <ariyasu> making every frame a keyframe would make your filesize huge [23:41:22 CEST] <polysics> it does not matter to a degree [23:41:28 CEST] <polysics> maybe one every 5? 10? [23:41:49 CEST] <polysics> I am not sure I can go set those options on the original file, so if I could re-encode it would be perfect [23:43:30 CEST] <polysics> -g, right? [23:44:54 CEST] <mont3z> atomnuker: I found it, thx a lot :) [23:45:23 CEST] <polysics> ariyasu: if that works even just the word "keyframe" saved my project :D [23:48:20 CEST] <ChocolateArmpits> polysics, that is the command yes [23:49:07 CEST] <polysics> that worked. I love everyone here. If anyone is at FOSDEM next year, I'll find you and buy you a beer :D [23:49:21 CEST] <interval> polysics, good band [23:49:38 CEST] <polysics> very whimsical [23:51:45 CEST] <polysics> well, in the short term, that works [00:00:00 CEST] --- Thu Jul 12 2018

1 0

ffmpeg-devel.log.20180710
by burek 11 Jul '18

11 Jul '18

[00:32:12 CEST] <tmm1> rcombs: did you ever try MediaCodec in async mode via ndk? [00:32:56 CEST] <rcombs> iirc there's no way to install a callback from ndk [00:33:00 CEST] <rcombs> I could be misremembering though [00:33:22 CEST] <tmm1> there's AMediaCodec_setAsyncNotifyCallback [00:33:37 CEST] <tmm1> not sure when that was added, i assume along with the rest of NdkMediaCodec.h [00:34:42 CEST] <rcombs> huh [00:35:01 CEST] <rcombs> maybe I either missed it, or couldn't think of a good way to apply it within lavc's sync API [00:35:39 CEST] <tmm1> maybe it's new in android P, the docs don't specify [00:38:25 CEST] <rcombs> it's not in 24, at least [00:39:16 CEST] <JEEB> seems like a VLC bug regarding the async callback API was added 3 months ago [00:39:21 CEST] <JEEB> so around then? [00:39:53 CEST] <rcombs> yeah, just saw that [00:39:58 CEST] <JEEB> https://developer.android.com/ndk/reference/group/media#group___media_1ga1a… [00:40:21 CEST] <rcombs> afaik they still don't provide an API to start a binder thread pool in a process that doesn't already have one :/ [00:42:42 CEST] <rcombs> they do provide separate notifications for input and output buffer availability though, so it's probably useful [00:43:20 CEST] <rcombs> they don't specify what thread the callbacks run on or what you might have to lock against, though [00:44:23 CEST] <jamrial> nevcairiel: curious, your mail was super delayed [00:45:17 CEST] <nevcairiel> can at most be 10 minutes delayed because thats when i wrote it [00:45:20 CEST] <rcombs> you pass in a struct of function pointers by value, which is a bit funky but I guess it's equivalent to having an arg for each one, but with the bonus of being able to use designated initializers [00:45:23 CEST] <jamrial> you seemingly wrote/sent it at the same time as mine, but it arrived two minutes ago [00:45:37 CEST] <rcombs> named optional args in C! [00:45:39 CEST] <nevcairiel> who knows what google or the ML is doing [01:18:46 CEST] <cone-382> ffmpeg 03Michael Niedermayer 07master:fa19fbcf712a: avformat/movenc: Write version 2 of audio atom if channels is not known [06:43:53 CEST] <cone-705> ffmpeg 03Gyan Doshi 07master:0bd48ab2d9e4: fate: allow temp files for passed test to be kept [11:06:58 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:299b98138272: avcodec/diracdec: Use int64 in global mv to prevent overflow [11:06:58 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:36a1e9be5a1d: avcodec/jpeg2000dwt: Fix integer overflows in sr_1d53() [11:06:58 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:84bf347ff054: avcodec/diracdec: Fix integer overflow in mv computation [11:06:58 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:d81e0f925a94: avcodec/cavsdec: Check alpha/beta offset [11:06:58 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:11d0464565d1: avcodec/smc: Check input packet size [11:06:59 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:e724bd1dd9ef: avcodec/utvideodec: Check subsample factors [11:06:59 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:6d3f8992acc9: avcodec/bintext: sanity check dimensions [11:07:00 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:5279e865961f: libavformat/oggparsevorbis: Fix memleak on multiple headers [11:07:00 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:4bcfe9f19c8e: avformat/utils: Fix integer overflow of fps_first/last_dts [11:07:01 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:7d915afd23aa: avformat/oggparsetheora: Do not adjust AV_NOPTS_VALUE [11:07:02 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:3b5645a72928: avformat/avidec: Fix integer overflow in cum_len check [11:07:04 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:31783dc5fe00: avformat/oggparseogm: Fix undefined shift in ogm_packet() [11:07:04 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:6b51dc922346: avformat/oggparseogm: Check lb against psize [11:07:06 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:5770793dec3a: avformat/mov: Fix integer overflows related to sample_duration [11:07:06 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:1c0914e4f34e: avcodec/wmalosslessdec: Reset num_saved_bits on error path [11:07:08 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:ff587292238c: avcodec/nuv: Check for minimum input size for uncomprssed and rtjpeg [11:07:08 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:b4e66382c207: avcodec/nuv: rtjpeg with dimensions less than 16 would result in no decoded pixels thus reject it [11:07:09 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:17f626528a29: avformat/mov: Check STSC and remove invalid entries [11:07:10 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:20e6a8dee8f8: avcodec/get_bits: Make sure the input bitstream with padding can be addressed [11:07:11 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:e1aec9bb8d80: avcodec/tableprint_vlc: Fix build failure with --enable-hardcoded-tables [11:07:12 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:367d459f78c1: avcodec/wmalosslessdec: Fix null pointer dereference in decode_frame() [11:07:13 CEST] <cone-531> ffmpeg 03heimdallr 07release/2.8:eb8654610927: avcodec/imgconvert: Fix loss mask bug in avcodec_find_best_pix_fmt_of_list() [11:07:14 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:704bebc91fa5: avcodec/cscd: Error out when LZ* decompression fails [11:07:16 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:d3d5382dadcd: avcodec/aacdec_fixed: Fix integer overflow in apply_independent_coupling_fixed() [11:07:16 CEST] <cone-531> ffmpeg 03Hendrik Schreiber 07release/2.8:fe4e35e202d3: swresample/swresample: Fix for seg fault in swr_convert_internal() -> sum2_float during dithering. [11:07:18 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:01f124da7f79: avcodec/aacsbr_fixed: Fix integer overflow in sbr_hf_assemble() [11:07:18 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:07cd51f10e96: avcodec/movtextdec: Check style_start/end [11:07:19 CEST] <cone-531> ffmpeg 03Matt Wolenetz 07release/2.8:54bde32f37fd: lavc/libopusdec: Allow avcodec_open2 to call .close [11:07:21 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:23dcc9ff7c37: avcodec/mjpegdec: Check input buffer size. [11:07:22 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:6186bfad3870: avcodec/truemotion2: Propagate out of bounds error from GET_TOK() [11:07:23 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:9af1e014f788: avcodec/utils: Enforce minimum width also for VP5/6 [11:07:24 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:25ecdac8beca: avformat/utils: Check cur_dts in update_initial_timestamps() more [11:07:25 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:f337adcd28de: doc/APIchanges: Fix typos in hashes [11:07:26 CEST] <cone-531> ffmpeg 03Rahul Chaudhry 07release/2.8:e5b29c60f02f: swresample/arm: remove unintentional relocation. [11:07:27 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:173e04ee85a8: avcodec/cinepak: move some checks prior to frame allocation [11:07:28 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:bd7231cad119: avcodec/cinepak: Skip empty frames [11:07:29 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:79cc326baba5: avcodec/dfa: Check dimension against maximum [11:07:30 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:a868e804d92f: avcodec/dsicinvideo: Propagate errors from cin_decode_rle() [11:07:31 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:c7329c733cb3: avcodec/dsicinvideo: Fail if there is only a small fraction of the data available that comprises a full frame [11:07:32 CEST] <cone-531> ffmpeg 03Stephan Holljes 07release/2.8:187728232390: lavf/http.c: Free allocated client URLContext in case of error. [11:07:33 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:8eee712737c2: avcodec/ffv1enc: Check that the crc + version combination is supported [11:07:34 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:60e7be58d996: avcodec/vc1_block: simplify ac_val computation [11:07:35 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:6f68d2ca0b04: avcodec/elsdec: Fix memleaks [11:07:36 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:1f057b23c70c: avcodec/h263dec: Check slice_ret in mspeg4 slice loop [11:07:37 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:9a7a3b22625e: avcodec/error_resilience: Fix integer overflow in filter181() [11:07:38 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:f20c62538b03: avcodec/wavpack: Fix integer overflow in DEC_MED() / INC_MED() [11:07:39 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:8e3918f1db50: avcodec/flac_parser: Fix infinite loop [11:07:40 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:02f4e846d288: avcodec/g2meet: Change order of operations to avoid undefined behavior [11:07:41 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:4e9e1ab815c5: avcodec/jpeg2000dec: Skip init for component in CPRL if nothing is to be done [11:07:42 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:c10babcadc34: avcodec/jpeg2000dec: Fix undefined shift in the jpeg2000_decode_packets_po_iteration() CPRL case [11:07:43 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:fc097bf1cd0a: avcodec/g2meet: Check RGB upper limit [11:07:44 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:888bdb127b54: avcodec/fic: Check available input space for cursor [11:07:45 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:a89f074d8953: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_DD97iH0 / COMPOSE_DD137iL0 [11:07:46 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:854835966b33: avformat/mov: Only fail for STCO/STSC contradictions if both exist [11:07:47 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:931f83773119: indeo4: Decode all or nothing of a band header. [11:07:48 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:3d4e0858d68b: avcodec/mlpdec: Only change noise_type if the related fields are valid [11:07:49 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:6bbef938839a: avcodec/mpeg4videoenc: Use 64 bit for times in mpeg4_encode_gop_header() [11:07:50 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:4c2bb473d3f9: avcodec/aacdec_fixed: use 64bit to avoid overflow in rounding in apply_dependent_coupling_fixed() [11:07:51 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:781dcd5db6ac: avcodec/g2meet: ask for sample with overflowing RGB [11:07:52 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:f98794c73a7f: avcodec/fic: Avoid some magic numbers related to cursors [11:07:53 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:674929cd46c7: avformat/mov: Break out early if chunk_count is 0 in mov_build_index() [11:07:54 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:17ed3c809da5: avformat/mov: replace a value error by clipping into valid range in mov_read_stsc() [11:07:55 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:832d9accfc23: avcodec/amrwbdec: Fix division by 0 in find_hb_gain() [11:07:56 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:4c3a7aaea8ba: avcodec/opus_silk: Change silk_lsf2lpc() slightly toward silk/NLSF2A.c [11:07:57 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:ea0734e3f011: avcodec/truemotion2: Fix overflow in tm2_apply_deltas() [11:07:58 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:ce4cb475a371: avcodec/mjpegdec: Fix integer overflow in ljpeg_decode_rgb_scan() [11:07:59 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:f41da2bd5ff7: avcodec/shorten: Sanity check nmeans [11:08:00 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:6fdc61b8f6f1: avcodec/shorten: Fix multiple integer overflows [11:08:01 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:acfdaa463e7c: avcodec/wavpack: Fix overflow in adding tail [11:08:02 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:2b60986513c9: avcodec/xwddec: Use ff_set_dimensions() [11:08:03 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:cc65755a0ddb: avcodec/h264_mc_template: Only prefetch motion if the list is used. [11:08:04 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:ed4e35a0fdef: avformat/mov: Only set pkt->duration to non negative values [11:08:05 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:83260729955b: fftools/ffmpeg: Fallback to duration if sample rate is unavailable [11:08:06 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:c1121e7ec29b: avutil/common: Fix undefined behavior in av_clip_uintp2_c() [11:08:07 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:e495910d4ca3: avcodec/aacdec_fixed: Fix undefined integer overflow in apply_independent_coupling_fixed() [11:08:08 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:8db6c2993bb5: avcodec/mjpegdec: Check for end of bitstream in ljpeg_decode_rgb_scan() [11:08:09 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:9bfdb49b7402: avcodec/escape124: Check buf_size against num_superblocks [11:08:10 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:3b02b9ad2b81: avcodec/cscd: Check output buffer size for lzo. [11:08:11 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:65c9c1b061db: avcodec/ra144: Fix integer overflow in ff_eval_refl() [11:08:12 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:f780dabc5019: avcodec/escape124: Fix spelling errors in comment [11:08:13 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:76e10cd327b3: avcodec/jpeg2000dec: Check that there are enough bytes for all tiles [11:08:14 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:b6af5c8880e1: avcodec/jpeg2000dec: Fixes invalid shifts in jpeg2000_decode_packets_po_iteration() [11:08:15 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:29c7a02bb285: avcodec/shorten: Fix undefined addition in shorten_decode_frame() [11:08:16 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:4652b0f8fe8a: avcodec/indeo4: Check for end of bitstream in decode_mb_info() [11:08:17 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:c75b8c9733ef: avformat/pva: Check for EOF before retrying in read_part_of_packet() [11:08:18 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:feb31c7ade15: avformat/mms: Add missing chunksize check [11:08:19 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:a80b8a01cc93: avformat/movenc: Check that frame_types other than EAC3_FRAME_TYPE_INDEPENDENT have a supported substream id [11:08:20 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:270a7ff111aa: avcodec/mjpegdec: Check for odd progressive RGB [11:08:21 CEST] <cone-531> ffmpeg 03Michael Niedermayer 07release/2.8:5775f837963d: avformat/movenc: Check input sample count [11:08:22 CEST] <cone-531> ffmpeg 03James Almer 07release/2.8:81997136995e: libwebpenc_animencoder: add missing braces to struct initialization [11:08:23 CEST] <cone-531> ffmpeg 03James Almer 07release/2.8:7ae182e0b7de: avformat/utils: fix mixed declarations and code [15:43:07 CEST] <JEEB> TIL ff_spdif_probe [15:43:13 CEST] <JEEB> how the flying mcnuggets did I miss that one [16:36:30 CEST] <akravchenko188> jkqxz: Hello. I have sent updated patches with hwcontext_amf and vf_scale_amf. Could you please review it? Thanks [16:59:08 CEST] <atomnuker> akravchenko188: I don't like how it accepts d3d11 and dxva2 frames [16:59:17 CEST] <atomnuker> while its name is amf [17:04:37 CEST] <BtbN> atomnuker, nvenc also accepts d3d11 frames. They're pretty standard on Windows. [17:04:55 CEST] <akravchenko188> atomnuker: filter uses amf components to provide scaler/converter for dxva and dx11 surfaces. soon it will convert also vulkan frames [18:13:05 CEST] <atomnuker> can't you use the lavu hwcontext api to map frames rather than having to duplicate code to do so? [22:34:07 CEST] <akaWolf> hi, guys! how can I debug the case when HLS stop downloading without errors [22:34:09 CEST] <akaWolf> ? [00:00:00 CEST] --- Wed Jul 11 2018

1 0

ffmpeg.log.20180710
by burek 11 Jul '18

11 Jul '18

[00:33:54 CEST] <lavalike> hello, how can I use ffmpeg to take a live twitch stream, re-encode it to a different fps & bitrate (60 -> 30, >3000kbps -> 1000kbps), and serve it so that I can play it locally with mpv? [01:47:56 CEST] <Hello71> youtube-dl [01:48:06 CEST] <Hello71> or better just use mpv directly [01:56:15 CEST] <DHE> normally I'd agree, but it's a strange request. like they want to turn a twitch feed into a multicast stream or something? [01:57:23 CEST] <Faust> Hi [01:58:27 CEST] <Faust> Is it possible to compress an image with ffmpeg? [02:30:46 CEST] <DHE> Faust: while ffmpeg does support some standard image formats, you might want to use more typical tools if you have specific needs [02:33:48 CEST] <Faust> It's just an icon for an application launcher. [02:37:27 CEST] <Faust> is the PNG format recognizable? [02:38:36 CEST] <Faust> Nevermind, just found a way. [02:39:03 CEST] <Faust> See ya. [07:31:36 CEST] <vaporstack> derrida: it's a secret ;) [07:31:42 CEST] <vaporstack> oops wrong chan [07:33:53 CEST] <zulu> my [07:48:09 CEST] <zulu> help [07:53:29 CEST] <vidgrapp> Installed libvorbis-dev, and ran configure with --enable-libvorbis and got and error `vorbis not found using pkg-config`, more info at https://pastebin.com/LYgfATTG . An ideas why? [10:50:58 CEST] <th3_v0ice> Hi, what is the muxer that is used when the output file is .h264( raw bitstream )? [10:51:40 CEST] <JEEB> one of the raw ones under libavformat [10:51:59 CEST] <JEEB> libavformat/rawenc.c: .name = "h264", [10:52:00 CEST] <JEEB> yup [10:52:08 CEST] <JEEB> which is the one that just dumps the data as-is [10:56:37 CEST] <th3_v0ice> Ok, thanks! [12:00:58 CEST] <flavi0> Is there a de-reverberation filter available in ffmpeg/libavfilter? [12:15:39 CEST] <termos> When doing HTTP PUT of HLS to Akamai the FFmpeg client will close the connection before Akamai has sent me a status code. Is there a way to wait for them to send me this response code? [12:19:03 CEST] <tankenmate> hey all, what are the command line options to get ffmpeg to make a m4a file _without_ using a .m4a filename? [12:20:18 CEST] <tankenmate> i've tried using a mp4 format but that generates a different type of container to a m4a file [12:21:00 CEST] <tankenmate> i.e. aac codec + mp4 produces a mp4 video with only an audio stream, not a m4a containter with an aac codec [12:24:54 CEST] <furq_> tankenmate: -f ipod [12:27:50 CEST] <tankenmate> furq_: thanks, it would have taken me ages to find that [12:28:08 CEST] <tankenmate> \quit [12:28:12 CEST] <tankenmate> doh! [14:17:46 CEST] <^Neo> So, some progress from my IEC61937 issue. I can do something like this ffmpeg -ac 2 -f alsa -i <pcm> -f ac3 blah.ac3 [14:17:58 CEST] <^Neo> and it can be playable as far as I know [14:18:21 CEST] <^Neo> however, I want it to be now embedded in a mpegts stream... [14:18:42 CEST] <^Neo> there might be a -c:a copy in there too [14:23:48 CEST] <squ> change -f to type of result [14:24:31 CEST] <squ> maybe it will convert automagically [14:24:53 CEST] <JEEB> it's AC3-in-PCM packing, it will mux it as raw PCM in MPEG-TS [14:26:10 CEST] <JEEB> what you want is to demux/parse it as AC3, that gives you AC3 AVPackets and you create a stream of those [14:27:19 CEST] <JEEB> because the input -f is overloaded by libavdevice in that example you cannot force it to use the raw ac3 demuxer, and I'm not sure if you'd get the parser with that [14:27:59 CEST] <JEEB> unless the input is of course noted as AC3 [14:28:13 CEST] <JEEB> if it is, then ffmpeg.c should be able to remux it as long as the parsing is done [14:29:12 CEST] <furq_> you can presumably do it by piping to another ffmpeg [15:09:30 CEST] <^Neo> furq_ yeah, that's what I'm thinking I might have to do [15:10:10 CEST] <^Neo> JEEB, can you hint the input type? I didn't think so in ffmpeg.c [15:10:24 CEST] <JEEB> yes, as long as it's not a container [15:10:35 CEST] <JEEB> or well, no - you can't override a codec in a container [15:10:40 CEST] <JEEB> but you can override the container [15:10:47 CEST] <JEEB> the problem is, in your case you're having `-f alsa` [15:10:54 CEST] <JEEB> which uses up your -f before -i [15:10:55 CEST] <JEEB> :P [15:11:02 CEST] <^Neo> I need multiple -f's! [15:11:02 CEST] <JEEB> (plus the parsing part) [15:11:05 CEST] <^Neo> hah [15:11:20 CEST] <^Neo> I'm surprised no one's wanted this before for FFmpeg [15:11:37 CEST] <^Neo> I figure using FFmpeg for AVR capabilities would be something the community would want [15:11:47 CEST] <JEEB> also there's an spdifdec "demuxer" [15:12:05 CEST] <^Neo> yeah, but I wasn't sure how to get my PCM plugin as input in that case [15:12:24 CEST] <JEEB> ^Neo: basically people all do it in their specific-usecase API clients [15:13:20 CEST] <JEEB> seems like the library does have `ff_spdif_probe` [15:13:30 CEST] <JEEB> which is a private function that other demuxers can use [15:13:35 CEST] <JEEB> it seems like only WAV uses it [15:13:47 CEST] <^Neo> Yeah I was looking into that, and had some test code that basically pulled in those functions [15:14:04 CEST] <JEEB> as an external application you cannot use ff_* though [15:14:05 CEST] <^Neo> and I was basically able to sort of pull the AC3 packet data out and decoded [15:14:19 CEST] <JEEB> since ff_* are internal functions [15:14:52 CEST] <^Neo> yeah it was just some hack code to confirm that it was iec61937 that I was receiving [15:15:14 CEST] <^Neo> the -f spdif -i <pcm> doesn't work unfortunately lol [15:15:20 CEST] <JEEB> but yea, basically it means that it's less bad than it sounds. there's already a decoder and for formats that can have packed compressed audio in them that can be utilized [15:16:12 CEST] <^Neo> hmm [15:16:31 CEST] <^Neo> I wonder if I can take the pcm output and output to wav and pipe it into the spdif demuxer? [15:16:43 CEST] <JEEB> the WAV demuxer I think supports it [15:16:56 CEST] <JEEB> since libavformat/wavdec.c: ret = ff_spdif_probe(buf, len, &codec); [15:17:08 CEST] <JEEB> so it at least tries to probe if the WAV contains SPDIF [15:18:14 CEST] <^Neo> that seemed to work [15:18:53 CEST] <JEEB> but yea, now I know what to use in my eternal project :P [15:19:03 CEST] <JEEB> a capture file format demuxer [15:19:23 CEST] <^Neo> hah [15:19:40 CEST] <JEEB> I have at least one example of AAC in SPDIF from that :D [15:19:48 CEST] <furq_> ^Neo: there's an spdif muxer as well [15:20:04 CEST] <JEEB> yea but I think he only needs to get the data [15:20:05 CEST] <furq_> ffmpeg -f lavfi -i sine=d=10 -c:a ac3 -f spdif - | ffmpeg -f spdif -i - -c:a copy out.m4a [15:20:07 CEST] <^Neo> how does the piping syntax work? ffmpeg -f alsa -i <pcm> -c:a copy -f wav - | ffmpeg -i pipe -c:a ac3 -f mpegts pipe.ts doesn't seem to work [15:20:19 CEST] <furq_> that works for me so i guess you can do the same thing with alsa instead of lavfi input [15:20:35 CEST] <^Neo> furq_, the input data is pcm_s16le and it seems like the spdifenc doesn't support that codec [15:20:49 CEST] <^Neo> unless I rework my asoundrc? [15:21:05 CEST] <furq> oh [15:21:17 CEST] <furq> does piping s16le work [15:21:26 CEST] <^Neo> I think so? [15:22:37 CEST] <^Neo> next step is to get AV sync with the hdmi video coming in over v4l2 lol [15:24:07 CEST] <^Neo> but this is great [15:24:09 CEST] <^Neo> thanks a lot! [15:56:48 CEST] <^Neo> can I pipe two inputs into a single output? [16:01:58 CEST] <Mavrik> What would that "pipe" do with the actual content of your two inputs? [16:03:19 CEST] <^Neo> my workflow with ffmpeg.c is similar to something like ffmpeg -f alsa -i <pcm> -c:a copy -f wav - | ffmpeg -y -f wav -i - -c:a ac3 -f v4l2 -i <v4l2device> -c:v libx264 -f mpegts output.ts [16:03:23 CEST] <^Neo> but the av sync is off [16:03:29 CEST] <^Neo> so I'm wondering if I could do something like [16:04:39 CEST] <^Neo> ffmpeg -f alsa -i <pcm> -c:a copy -f wav - -f v4l2 -i <v4l2device> -c:v libx264 -f h264 | ffmpeg -y -f wav -i pipe1 -c:a ac3 -f h264raw -i pipe2 -f mpegts output.ts [16:30:50 CEST] <SaberArthur> Hello, I encounter a problem when I try to create timelapse from existing video [16:31:45 CEST] <SaberArthur> I use this script: ffmpeg -i input.mkv -filter:v "setpts=0.5*PTS" output.mkv [16:32:16 CEST] <SaberArthur> When I make 1 minute video into 2x, it still has 1 minute duration. But the video is really speed up 2x. After 30 second the video freeze until 1 minute [16:36:09 CEST] <SaberArthur> when I upload to youtube it weird https://i.imgur.com/4gLfTi1.png [16:37:00 CEST] <Nacht> Does it contain audio ? [16:37:26 CEST] <SaberArthur> no [16:40:41 CEST] <Blacker47> SaberArthur, i would doublecheck with ffprobe input.mkv if it has more than one track. [16:41:44 CEST] <Blacker47> or maybe set the output framerate with -r [16:42:34 CEST] <SaberArthur> Ah, maybe because the audio track exist but it's silent so it doesn't get speed up? [16:42:42 CEST] <Nacht> Yes [16:43:11 CEST] <Blacker47> yes. try -shortest or second processing with -codec copy and -shortest. [16:46:41 CEST] <Nacht> -an would be simpler [16:47:32 CEST] <SaberArthur> Dang, thank you. Solved [16:48:40 CEST] <SaberArthur> Yeah, apparently there is a silent audio channel. I had to get rid of it first or using -an to make it work [16:50:22 CEST] <Nacht> The thing is, setpts only applies to video. So it was speeding up your video, but leaving your audio the same, which still had the duration [16:52:13 CEST] <SaberArthur> Yeah, makes sense [16:52:23 CEST] <Blacker47> Nacht, i belive youtube always needs an audio track. [16:52:50 CEST] <Nacht> Blacker47: You got a point there [16:52:59 CEST] <SaberArthur> so what do I do? [16:53:27 CEST] <Blacker47> SaberArthur, try & error & learn ;-) [16:54:17 CEST] <Nacht> SaberArthur: As Blacker47 said, used -shortest [16:54:20 CEST] <Blacker47> SaberArthur, you can try audo-less upload (after using -an). if it fails you can try cut audio as i wrote or add silent audio-track after -an. [16:54:31 CEST] <Nacht> *use [16:55:32 CEST] <SaberArthur> I uploaded the -an and it works, so... I think it's okay to upload the audio-less one. idk [16:55:51 CEST] <SaberArthur> But yeah, if it not gonna work I'm gonna do the other way [16:56:55 CEST] <atbd> hi, i'm using ffmpeg c api to split a one hour video in multiple small videos. ffplay reads them right, vlc reads them but set a bad start time (for example start at 15:10:54 and ends at 15:12:54). I thought setting AVStream::start_time would succeed but no, and AVFormatContext::start_time does no seem to be the solution too. Someone has an idea on what to set ? Thanks! [16:59:31 CEST] <Blacker47> SaberArthur, so the need for an audio i heard about may be only for livestreaming. [16:59:42 CEST] <SaberArthur> okay, gotcha [17:00:02 CEST] <SaberArthur> thank you guys [17:58:00 CEST] <Trufa> Can I install ffmpeg 3.x with brew on a mac? Now that it's updated to 4 I don't seem to find v3 with brew, thank you! [17:58:36 CEST] <Hello71> ask brew [20:20:46 CEST] <CoderDawson> In an attempt to get H.264 hardware decoding working on Android using MediaCodec, I have cross-compiled ffmpeg with a command-line of https://pastebin.com/ej1w7j7Y from an Ubuntu 18.04 virtual machine. When executing avcodec_open2 for the h264_mediacodec (found via avcodec_find_decoder), I receive an error code result of -542398533 (Generic error in an external library). Are there steps I may have missed during the ffmpeg build pr [20:23:10 CEST] <JEEB> try without as limited thing first [20:23:24 CEST] <JEEB> I build FFmpeg+mpv for android and hwdec works [20:25:41 CEST] <CoderDawson> Unfortunately, I am using ffmpeg with WebRTC so I don't believe mpv is an option. [20:26:38 CEST] <JEEB> also I would recommend not posting a command line to chromium's build script but rather the actual configure line [20:26:41 CEST] <JEEB> in any case [20:27:09 CEST] <JEEB> http://up-cat.net/p/900c2b90 [20:27:17 CEST] <JEEB> this is how my build config looks for FFmpeg [20:27:51 CEST] <CoderDawson> Here is the configure output: https://pastebin.com/QGE44cLe [20:27:52 CEST] <JEEB> I make a "standalone toolchain" for ARM and then add it to PATH and utilize the clang it contains [20:28:05 CEST] <JEEB> but basically esp. during first tests I don't disable random things [20:28:18 CEST] <JEEB> bevause you might be missing a file protocol or whatever [20:32:56 CEST] <CoderDawson> Previous was the configure line. Here is the configure output: https://pastebin.com/02PXxy8N [20:33:28 CEST] <CoderDawson> I was thinking that h264_mediacodec should appear in the enabled hwaccels section. [20:35:01 CEST] <JEEB> h264_mediacodec is kind of special. it has a more hwaccel'y mode, but it also can be used as "just a decoder" [20:35:55 CEST] <JEEB> anyways, you might want to check if that stream works when dumped to a file with something like mpv-android [20:36:08 CEST] <JEEB> if it does then it's either your build or your API usage [20:36:19 CEST] <JEEB> and just try building without limiting the build as much, you're not yet in the optimization part [20:36:23 CEST] <JEEB> you're in the "getting shit to work" part [20:37:14 CEST] <JEEB> I posted my *full* configure line (which of course does contain extra things like GMP/GNUTLS) [20:37:20 CEST] <JEEB> but it also contains jni/mediacodec [20:37:21 CEST] <JEEB> and zlib [20:37:28 CEST] <JEEB> the two first are important [20:37:44 CEST] <JEEB> and then remember that for the JNI stuff in mediacodec decoder you need to first provide libavcodec the JVM [20:38:31 CEST] <JEEB> https://github.com/mpv-android/mpv-android/blob/master/app/src/main/jni/mai… [20:38:34 CEST] <JEEB> like this :P [20:39:01 CEST] <JEEB> the av_jni_set_java_vm [20:39:52 CEST] <CoderDawson> I actually have ffmpeg working without anything limited in WebRTC and it goes for the VP8 codec without hardware decoding and runs very slow on device. [20:40:34 CEST] <CoderDawson> I did another build with both h264 and h264_mediacodec enabled and it choose h264 without hardware decoding through ffmpeg and was again very slow. [20:41:02 CEST] <CoderDawson> That's actually what has lead me down the path of attempting to get h264_mediacodec working to speed up the decoding on device. [20:42:08 CEST] <CoderDawson> I am testing on a Google Pixel 2. [21:14:14 CEST] <Hello71> why not just use stagefright [21:14:40 CEST] <JEEB> no [21:15:16 CEST] <JEEB> he just completely ignored my lines about registering the JVM, but stagefright at this point of time is *not* an answer [21:15:27 CEST] <JEEB> mediacodec is what you use on android. period. [21:20:45 CEST] <CoderDawson> Still trying to figure out my options for the JVM lines you pointed out as I don't know how that fits in with WebRTC's use of FFMpeg. [21:37:06 CEST] <CoderDawson> Out of curiosity, shouldn't there be an entry in libavcodec/hwaccels.h for h264_mediacodec? Something like ff_h264_mediacodec_hwaccel? [21:38:33 CEST] <JEEB> CoderDawson: when you initialize libavcodec and before you start poking at the decoders, you call the JVM registration [21:39:00 CEST] <JEEB> and while there's a more hwaccel like thing for Mediacodec, no. at least I think like that. [21:39:05 CEST] <JEEB> you just utilize it as a decoder [21:39:11 CEST] <JEEB> which in many ways is simpler :P [21:39:41 CEST] <CoderDawson> Thanks, JEEB. [21:40:34 CEST] <CoderDawson> RE: JVM registration. WebRTC is initializing ffmpeg and libavcodec from my understanding and I am not familiar with how that works yet. [21:44:21 CEST] <JEEB> CoderDawson: I have no idea but you were calling avcodec_open2 [21:44:33 CEST] <JEEB> before that, call the registration function with the JVM [21:47:37 CEST] <CoderDawson> Ah. Gotcha. The code calling avcodec_open2 is actually part of WebRTC (in h264_decoding_impl.cc). Guess I just need you to point out that call for it to actually click. Not sure how to access the JVM at that point though. More research will be needed. [23:01:20 CEST] <faLUCE> hello, is there an alternative for the "-t" option? I want to cut a mp3 file from 00:03:00 to 00:07:45 [23:01:36 CEST] <faLUCE> If I use -ss then I have to calculate the duration for -t [23:05:13 CEST] <kepstin> you could use -copyts in combination with -to, probably. Note that this may result in bad timestamps in the output file, depending on format. [00:00:00 CEST] --- Wed Jul 11 2018

1 0