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

[burek]

[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