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

burek burek021 at gmail.com
Thu Nov 15 03:05:03 EET 2018

[00:00:57 CET] <JEEB> can't speak for everyone but if it's his own code and he has only used any leaked stuff for hints at how things work, then the result is still under his copyright. not as great as full RE of course :P
[00:01:46 CET] <Pdrome> I don't come here to put project contribs noses out of joint or to cause trouble, I just don't feel confident starting to use FFmpeg with regards to a commercial game if RADs leaked code is in use then could 'FFmpeg using gamedevs' be liable?
[00:02:41 CET] <JEEB> I don't know what hypothetical scenario we're talking about, nor about juristiction etc
[00:02:46 CET] <Pdrome> I promise I will be back with link to the mailing list entry soon as i refind it
[00:02:48 CET] <JEEB> nor am I a lawyer
[00:03:40 CET] <JEEB> also for the record, you can disable complete functionality in FFmpeg if you don't like it or don't want to distribute binaries with that functionality in it
[00:03:59 CET] <Pdrome> ^interesting thanks.
[00:04:28 CET] <JEEB> quite a few people do it anyways since FFmpeg has so many minor/barely tested formats implemented
[00:11:02 CET] <Pdrome> I should also state that rads source code is still up online after all these years - it is in one of the avp1 source code mirros
[00:11:05 CET] <Pdrome> mirrors
[00:13:02 CET] <JEEB> I would be surprised if that was the actual RAD codec code
[00:13:32 CET] <JEEB> game developers generally don't need to get that far, they just need the headers etc to be able to use bink dlls
[00:18:15 CET] <JEEB> also I didn't even notice Kostya had published a WIP patch for bink2 when he gave up
[00:18:29 CET] <JEEB> you just caused me to go through his blog posts regarding bink
[00:18:30 CET] <JEEB> lol
[00:18:53 CET] <Pdrome> it is bink.c
[00:19:08 CET] <Pdrome> the headers are also near the C file
[00:19:56 CET] <JEEB> ok, don't worry then it seems :P that seems to be their wrapper around the bink interfaces :P
[00:20:02 CET] <JEEB> stuff link BINK *binkHandle
[00:20:03 CET] <Pdrome> I wonder if avp1 is where the leak that ffmpeg acquired originated from
[00:20:56 CET] <JEEB> nope
[00:21:05 CET] <JEEB> it literally uses bink's APIs to open a file and play it
[00:21:17 CET] <Pdrome> also the DLLs are there as well and also bink_Rad.h
[00:21:21 CET] <JEEB> looking at that bink.{c,h} and bink_Rad.h
[00:21:42 CET] <JEEB> so MPC might have gotten the bink_Rad.h from something like this back in ye olden days
[00:21:47 CET] <JEEB> but that only documents the interfaces
[00:21:59 CET] <Pdrome> yeah avp1 was nearly 20yrs old now
[00:22:19 CET] <JEEB> so what you would be able to do with this is just know how to take bink dll and play a video with it :P
[00:22:25 CET] <Pdrome> and the later avp1 source code release has removed those radgame tools source code files
[00:22:49 CET] <Pdrome> Thanks JEEB for the insight
[00:22:57 CET] <JEEB> I hope the differencei s clear between these things :P
[00:23:50 CET] <Pdrome> it isn't crystal clear (as I am new to gamedev) but it is simple enough for me to appreciate basic understanding given my gamedev research up to this point ;o)
[00:26:49 CET] <Pdrome> I know other commercial developers have used FFmpeg in games but without knowing if in the clear or not, most could be unaware of the rad source code leak association to FFmpeg project
[00:27:11 CET] <Pdrome> the more I just googled the more I think it was realting to RADs Bink Video
[00:30:33 CET] <JEEB> basically, the stuff that avp dump has is 100% useless for FFmpeg
[00:30:45 CET] <JEEB> since FFmpeg doesn't want to just use the bink DLLs
[00:31:18 CET] <JEEB> also you may poke Kostya yourself if you want to ask some questions to him to be honest
[00:31:26 CET] <JEEB> https://codecs.multimedia.cx/2009/07/brief-notes-about-bink/ is his blog
[00:34:04 CET] <Pdrome> How would I poke him?
[00:34:17 CET] <JEEB> e-mail or otherwise
[00:34:44 CET] <JEEB> you can see his e-mail in his commits :P http://git.videolan.org/?p=ffmpeg.git;a=search;h=HEAD;s=Kostya+Shishkov;st=author
[00:35:29 CET] <JEEB> originator of http://git.videolan.org/?p=ffmpeg.git;a=commit;h=342c7dfdbb46b1ff778ef142dc93d24990e776d7
[00:36:13 CET] <Pdrome> Oh nice, what is his link to FFmepg - eg is he the main developer or is he just best to ask as he worked on RE bink so much?#
[00:36:26 CET] <JEEB> he is the author of the decoder :P
[00:36:30 CET] <JEEB> he reverse engineered it
[00:38:04 CET] <Pdrome> I will try to email him, thanks for all your help JEEB
[00:45:28 CET] <JEEB> the only thing I find with any relevant keywords from GOOG is where a person mentions that he has access to the Real Video 4 spec, but that he is under an NDA and cannot share it from 2010's IRC logs
[00:45:47 CET] <JEEB> which a) isn't Bink b) pretty clear that nothing was passed on
[00:46:10 CET] <JEEB> so so far I can just see you making random allegations
[00:46:26 CET] <JEEB> possibly out of not understanding what is discussed
[00:48:47 CET] <Pdrome> thats is the thing, I don't want to alledge anything, I just want to understand what the situation is regarding what i found about RAD source on an old FFmpeg mailing list entry.. and until I can actually refind that specific mailing list entry, I dont really have any position to ask from
[00:49:06 CET] <Pdrome> earlier above I said the allude as that was the best word i could think of
[00:49:31 CET] <Pdrome> I dont want to alledge anything as even I am not sure what exactly the situation is
[00:49:47 CET] <JEEB> given the history of kostya regarding random game formats getting done (obviously by means of RE/open research) I would also pretty much default to it being RE'd :P
[00:49:54 CET] <Pdrome> you have helped JEEB fill in some things for me which is both interesting and helpful
[00:50:21 CET] <Pdrome> I have now sent the email so at the very least Kostya will get a laugh out of my obvious ignorance ;o)
[00:51:43 CET] <Pdrome> i am 100% sure the mailing list entry was regarding RAD software and not Real
[02:22:07 CET] <JEEB> auri_: sent a patch for the FLAC MPEG-DASH identifier to the mailing list
[02:25:55 CET] <ealdeguer> Hi FFMPEG Team,
[02:25:56 CET] <ealdeguer> I attended Demux in SF, and Will Law(akamai) demoed CMAF low latency.
[02:25:56 CET] <ealdeguer> I understood it was possible to package a source to HLS - CMAF with FFMPEG
[02:25:57 CET] <ealdeguer> but I'm not sure how and can't find much on google, can you guys help ?
[02:26:00 CET] <ealdeguer> I already managed to take a source, encode it with x264, package it as regular HLS with ffmpeg and push it to Akamai, but I wonder how it could work with CMAF ?
[02:53:52 CET] <KombuchaKip> Hey everyone. I'd really appreciate a code review of my custom AVIOContext for reading media from memory: https://pastebin.com/NGALFw8Y
[02:54:24 CET] <remlap> Hi I am trying to build ffmpeg but I get ERROR: chromaprint not found but I have it installed
[03:02:23 CET] <relaxed> remlap: do you have libchromaprint-dev installed?
[03:02:27 CET] <remlap> yes
[03:02:42 CET] <relaxed> pastebin.com the end of ffmpeg's config.log
[03:04:12 CET] <remlap> https://pastebin.com/ieZ28BvT this enough?
[03:05:45 CET] <relaxed> /usr/bin/ld: warning: libcodec2.so.0.7, needed by //usr/local/lib/libavcodec.so.58, not found
[03:06:57 CET] <remlap> libcodec2-dev install
[03:07:34 CET] <remlap> libcodec2-0.8.1 install
[03:07:46 CET] <remlap> 'ed
[03:09:05 CET] <relaxed> that provides /usr/lib/x86_64-linux-gnu/libcodec2.so.0.8.1
[03:09:39 CET] <remlap> yes so to new?
[03:10:35 CET] <relaxed> yes
[03:11:05 CET] <remlap> how would I correct for that (noob sorry)
[03:11:27 CET] <relaxed> you need libcodec2.so.0.7 installed
[03:13:21 CET] <remlap> my os comes with libcodec2.so.0.8.1 so I am bit out of luck?
[03:25:57 CET] <remlap> that's weird
[03:25:59 CET] <remlap> its building now
[03:26:35 CET] <remlap> configure went ok and now make is running, fingers crossed
[04:06:16 CET] <PhantomOfNyx> there we go I'm not used to IRC, quick question in libx264, I've kinda succeded getting the quality for my stream i want but the high quality of getting rid of all grain and blurr results in another thing becoming more obvious .... color banding
[04:07:46 CET] <PhantomOfNyx> I had truly not noticed until I cleaned out the blur but is there anyone in here with any smart ideas for reducing that or making it blend further, it's only in obvious stuff like areas with a lot of the same color ( loading screens or specifically torches lighting effect in minecraft becomes bad, mainly because it happens in game but it's just amplified 10x on after the encode) <3
[04:53:00 CET] <Hello71> did you turn off dithering
[05:22:45 CET] <saucecode_> I'm using OBS to record gameplays, and I've set it up to record an audio streams for the game, and a stream for my microphone. So it outputs a file with a video stream and two audio streams.
[05:23:28 CET] <saucecode_> Is there an easy way to merge the two audio streams from the same file into one stream, with copied video?
[09:18:00 CET] <bencc> how can I convert mp3 file to mp4 with black video frames?
[09:18:42 CET] <bencc> ffmpeg -i audio.mp3 -c:a aac -b:a 128k -vn out.m4a
[09:19:05 CET] <bencc> this encode to m4a. now I'm trying to encode to mp4 with black video stream
[09:27:41 CET] <furq> bencc: -i audio.mp3 -f lavfi -i color=black:s=1280x720 -shortest -c:a copy out.m4a
[09:27:53 CET] <furq> or -c:a aac if you want aac
[09:28:05 CET] <furq> no reason to do that unless you need to though
[09:29:02 CET] <furq> also that should be out.mp4 although i don't remember how much difference it makes, if any
[09:31:43 CET] <bencc> furq: thanks
[09:31:46 CET] <bencc> no reason to do what?
[09:31:53 CET] <furq> no reason to reencode the audio
[09:32:03 CET] <furq> most stuff supports mp3 in mp4
[09:32:27 CET] <bencc> ok. I'll try without reencoding
[09:32:53 CET] <bencc> I saw people do "-c:v libx264 -tune stillimage -pix_fmt yuv420p -shortest"
[09:33:36 CET] <furq> you don't need either but they won't hurt
[09:33:51 CET] <furq> i can't imagine stillimage will have any effect on a totally black frame
[09:33:58 CET] <furq> and the color source defaults to yuv420p anyway
[09:37:17 CET] <bencc> cool
[09:38:28 CET] <ritsuka> apple doesn't support mp3 in mp4, so avoid it if you need to play it back on a mac or iphone
[09:48:19 CET] <bencc> ritsuka: I do need safari. I'll avoid it
[10:31:33 CET] <llanotheroom> hi,  I developed a library based on libav*. It adds run time control when do video audio/video process, such as  add new input/output streams,  request I frame, etc..  I would like to seek your suggestions,  also desired features not supported by current version of FFmpeg  which I may give a try then.
[10:31:45 CET] <llanotheroom> https://github.com/Xingtao/FFdynamic
[13:49:14 CET] <abi> hi
[14:24:08 CET] <th3_v0ice> Why would a packet coming from the UDP given by av_read_frame have AV_NOPTS_VALUE for PTS and DTS while having size and data != 0 ?
[16:36:02 CET] <fahadash> What is wrong with this? ffmpeg -i .\PostmanInterceptor.webm -filter_complex "[0:v]trim=duration=13[a];[0:v]trim=start=40:duration=60,setpts=PTS-STARTPTS[b];concat=[a][b]" -y Postmaninterceptor.MOV
[16:36:24 CET] <fahadash> I am getting this error [AVFilterGraph @ 03e1cbc0] No output pad can be associated to link label 'b'.
[16:38:37 CET] <fahadash> Found it nvm
[16:47:25 CET] <th3_v0ice> If I have an input video of 12288x5760 and want to have 1080p output without black bars, how can I do that?
[16:48:11 CET] <kepstin> th3_v0ice: crop off the sides
[16:49:27 CET] <th3_v0ice> How? One more question. The original is in yuva444p10le, specifying pix_fmt yuv420p removes alot of color from the output, is there a way to remedy this?
[16:49:29 CET] <furq> or resize to 1920*900
[16:49:45 CET] <furq> that's still technically 1080p
[16:49:52 CET] <th3_v0ice> I am more interested in 1080 height,
[16:50:31 CET] <furq> going from 10-bit 4:4:4 to 8-bit 4:2:0 is specifically going to remove colour information
[16:51:30 CET] <kepstin> th3_v0ice: 10-bit video like that might be HDR, you might have to tonemap it to make it look good
[16:51:57 CET] <furq> i'm guessing from the input res that it's from a camera so yeah
[16:52:48 CET] <th3_v0ice> Yeah, raw information from camerea. So there is no automatic option that tries to map the colors?
[16:53:30 CET] <furq> there's a tonemap filter but i've never had cause to use it
[16:53:33 CET] <furq> https://ffmpeg.org/ffmpeg-filters.html#tonemap-1
[16:55:33 CET] <furq> anyway to crop and scale it you want -vf "crop=ih*(16/9):ih:(iw-ow)/2:0,scale=1920:1080"
[16:59:31 CET] <th3_v0ice> That did the trick for the video size, thanks! Let me try the tonemapping part.
[17:01:51 CET] <th3_v0ice> Guess I am out of luck for that one :) code 3074: no path between colorspaces
[17:11:34 CET] <JEEB> you can only convert video to float with zscale
[17:11:36 CET] <JEEB> (and back)
[19:49:49 CET] <JEEB> auri_: the patch is now in master
[19:53:38 CET] <ChocolateArmpits> Is there any practical purpose to "initial_pause" rtsp parameter?
[21:52:39 CET] <GuiToris> hey! can you help me with the presets of the x26[45]? I don't understand it. According to the ffmpeg guide they only affect the file size ( quote: The visual quality will be the same) Well I compared ultrafast and veryslow, and ffmpeg guide cannot be true. There are huge differencies between ultrafast and veryslow.
[21:53:02 CET] <GuiToris> So I don't know, does it really improve the quality?
[21:53:36 CET] <GuiToris> or they are just filters and they look nicer
[21:54:01 CET] <JEEB> for the same file size if the only difference is the preset, the slower ones will look better of course
[21:54:26 CET] <JEEB> since with each slower preset you enable features and use more CPU time to try and compress the video better
[21:55:10 CET] <GuiToris> JEEB: should I use a slower preset or a higher crf number to achieve better quality?
[21:55:39 CET] <GuiToris> JEEB: hey, no the file sizes were different
[21:55:42 CET] <JEEB> both. you use the slowest preset that is still fast enough for you, and then you tweak the CRF value to your needs
[21:56:11 CET] <JEEB> because the results of the CRF value depend on the preset
[21:56:25 CET] <GuiToris> ultrafast was big and ugly while veryslow was smaller and nicer (with the same crf value)
[21:56:39 CET] <JEEB> yes, the CRF values' results differ between presets
[21:56:47 CET] <JEEB> since the preset enables and disables 'eyes'
[21:57:42 CET] <GuiToris> I was wondering if   let's say  crf 28, preset ultrafast   is equal to  crf 30, preset veryslow
[21:58:07 CET] <JEEB> there is no straight relevancy
[21:58:25 CET] <JEEB> just pick like 2500 frames or so of a clip that show you what sort of content you're encoding
[21:58:28 CET] <JEEB> then decide on your preset
[21:58:32 CET] <JEEB> then tweak CRF
[21:58:34 CET] <JEEB> that is it
[22:01:01 CET] <GuiToris> that's exactly what I did, then it took about 23h to encode the final video, and I wasn't content with the result. I used x265, crf 30 and slower preset. I didn't know which value should I modify and also keep a small filesize
[22:01:32 CET] <GuiToris> in the end I chose crf 28, and hoping it'll be good
[22:03:04 CET] <GuiToris> during the tests I saw color banding with ultrafast but I didn't with veryslow. I was thinking that it didn't actually improve the quality it just use some kind of blur
[22:03:07 CET] <JEEB> GuiToris: that is why you look at the result of those 2500 or so frames? and you make sure you try to see that it looks like a point in the video that is actually of relevant type/movement etc for the rest of that sort of content you are going to encode
[22:03:15 CET] <JEEB> also x265 is completely different from x264 internally btw
[22:03:35 CET] <JEEB> so any specifics regarding other than x265 has something called crf and something called presets
[22:03:43 CET] <JEEB> goes out of the window :P
[22:03:46 CET] <JEEB> also x265 can have bugs
[22:03:59 CET] <JEEB> in any case, just use relevant samples for the actual CRF tweaking
[22:04:00 CET] <GuiToris> I read that x264 crf 23 ~ x265 crf 28
[22:04:21 CET] <JEEB> I have no idea. the ranges were quite different the last I checked x265
[22:04:38 CET] <JEEB> while x265 can use x264's code because of the licensing agreement
[22:04:45 CET] <JEEB> it's still very, very different
[22:04:56 CET] <JEEB> of course the general idea should still match
[22:05:12 CET] <JEEB> pick preset, use actually relevant sample of 2500-3000 frames to test CRF values with
[22:07:17 CET] <GuiToris> JEEB: I'd have liked to compare frames. I used something like $ffmpeg -ss 2 -i input -frames 1 output.png   does this keep the actual quality?
[22:07:39 CET] <GuiToris> I'm not sure whether png modifies the image
[22:07:48 CET] <JEEB> for comparison you can use something like vapoursynth editor with ffms2
[22:08:00 CET] <JEEB> has preview, is frame exact etc
[22:08:19 CET] <GuiToris> I'll check it, thank you
[22:08:45 CET] <GuiToris> does ffmpeg have a similar tool?
[22:09:10 CET] <JEEB> no since FFmpeg by itself is not frame exact. you can use video players like mpv for *some* containers, but they make no promises
[22:09:30 CET] <JEEB> ffms2 for example indexes the files with FFmpeg's APIs and makes things frame exact by keeping an index
[22:10:16 CET] <JEEB> also you can use vapoursynth to do the clip cutting and then you can pipe the output of that vapoursynth script into ffmpeg.c with vspipe
[22:10:33 CET] <JEEB> so you can cut different short clips of the longer clip you were going to test your parameters with
[22:10:53 CET] <JEEB> because it makes no sense to wait for hours just to figure out if a CRF value is good enough at a certain preset for your content
[22:11:16 CET] <GuiToris> it seems vapoursynth is superior to ffmpeg
[22:11:17 CET] <JEEB> of course -ss and -t with ffmpeg.c does the same thing with ffmpeg.c if  you only need a single clip
[22:11:26 CET] <JEEB> vapoursynth is different
[22:11:36 CET] <JEEB> and source modules for vapoursynth of course use FFmpeg
[22:11:40 CET] <JEEB> the APIs that is
[22:11:48 CET] <JEEB> because there's nothing like FFmpeg handling random multimedia
[22:12:00 CET] <JEEB> but then vapoursynth is a frame server :P
[22:13:00 CET] <GuiToris> thank you for your help
[22:13:03 CET] <GuiToris> one last thing
[22:13:12 CET] <GuiToris> is   flac   also a container?
[22:13:27 CET] <JEEB> pretty sure what "flac" generally is is FLAC audio in ogg?
[22:13:47 CET] Action: JEEB checks libavformat
[22:14:12 CET] <GuiToris> My audio files are named    something.flac rather than something.ogg
[22:14:19 CET] <c_14> isn't flac raw?
[22:14:28 CET] <JEEB> oh, just looked through lavf/flacdec.c
[22:14:37 CET] <JEEB> it might actually be raw FLAC with a header
[22:14:46 CET] <JEEB> also > 2001 copyright header
[22:14:51 CET] <JEEB> ye olden times' code
[22:15:53 CET] <GuiToris> I only named them ogg when I used vorbis
[22:16:34 CET] <GuiToris> I've never used opus but I think I would name it also something.opus, which might not be correct
[22:17:01 CET] <c_14> .ogg and .opus are both fine, .opus is an extension for "opus in ogg"
[22:17:24 CET] <JEEB> yes, they stopped trying to do raw audio I think
[22:17:38 CET] <JEEB> which is a good thing because containers generally let you do stuff like seeking
[22:18:05 CET] <GuiToris> so, is .flac also fine? I don't have to use ogg, do I?
[22:18:56 CET] <c_14> .flac is what's normally used, but you can pack it into a container if you want
[22:20:27 CET] <GuiToris> thank you so much
[22:42:48 CET] <trashPanda_> Hello, I am attempting to read in a rtsp stream with ffmpeg and I get numerous "Error parsing AU headers" errors.  I am able to view the stream in ffplay, but I want to restream it via ffmpeg.
[22:42:57 CET] <trashPanda_> the command line I'm using is
[22:43:27 CET] <trashPanda_> "ffmpeg -fflags nobuffer -rtsp_transport udp -i (sourceaddress) -vcodec copy -f mpegts (outaddress)
[22:43:35 CET] <Hello71> youtube prefers opus in matroska, dunno why
[22:43:40 CET] <Hello71> maybe it's a hls requirement or something
[22:43:48 CET] <Hello71> er, not hls, the other thing
[22:43:55 CET] <Hello71> dash
[23:27:18 CET] <BlackBishop> for a 'Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)' 'Duration: 02:18:17.50, start: 0.000000, bitrate: 71665 kb/s' I assume I'd need a 71mb/s connection, right ?
[23:27:40 CET] <BlackBishop> which should be well within a 802.11ac connection, right ?
[23:29:57 CET] <JEEB> hope that your connection actually goes that fast
[23:30:33 CET] <JEEB> I think I was able to remux some ultra hd blu-rays into mp4 and then tried streaming them off through wifi onto my TV
[23:30:46 CET] <JEEB> but with blade runner f.ex. it just didn't work very well
[23:31:00 CET] <JEEB> so I do recommend a cable when possible
[23:31:43 CET] <BlackBishop> the AP can do it .. https://www.ubnt.com/unifi/unifi-ap-ac-pro/
[23:31:59 CET] <BlackBishop> and I just noticed, I can play it just fine over http on my macbook pro ( on vlc )
[23:32:14 CET] <BlackBishop> but not on the tv ( sony kd-55xf9005 )
[23:32:23 CET] <BlackBishop> so it's not the wifi
[23:32:28 CET] <JEEB> welcome to plastic boxes
[23:32:47 CET] <BlackBishop> it also plays great when on usb in the tv :|
[23:33:03 CET] <JEEB> wow, in my case the USB input seems worse off than network :P
[23:33:14 CET] <BlackBishop> the usb plays perfect.
[23:33:47 CET] <BlackBishop> the wire does seem better than the wifi though
[23:34:04 CET] <BlackBishop> I tried ssh/ftp/http/nfs, nfs seems to be the best of all
[23:34:16 CET] <BlackBishop> but it still stutters and at some point it totally looses audio.
[23:36:38 CET] <BlackBishop> let's see if vlc will do a better job than kodi over http
[23:45:54 CET] <BlackBishop> vlc doesn't want to play it at all...
[23:49:31 CET] <AlexMax> Hi folks.  Got a question.  From what I understand, FFMPEG can use hardware acceleration to decode h264.  However, I'd like to do this from a library.  I'm trying to repurpose some existing h264 code, but the problem is that I'm not exactly sure how I'm suppsoed to specify "Hey, please fetch the h264 decoder that is mmal-accelerated".
[23:50:12 CET] <AlexMax> ffmpeg lists the decoder as "h264_mmal"
[23:50:30 CET] <JEEB> all hwaccels can have some specifics because they might need outside init for system-specific contexts etc, but if it's not a hwaccel then it's "just a decoder"
[23:51:04 CET] <AlexMax> Well, I think I have to use -hwaccel to get the decoder to show up
[23:51:17 CET] <AlexMax> well...actually...
[23:51:31 CET] <AlexMax> if I do ffmpeg -codecs, i get:
[23:51:53 CET] <AlexMax> DEV.LS h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_mmal h264_vdpau ) (encoders: libx264 libx264rgb h264_omx h264_vaapi )
[23:52:09 CET] <JEEB> yea, so try to get the AVCodec by name with the _mmal
[23:52:21 CET] <AlexMax> JEEB: Tried that, got an error
[23:52:24 CET] <JEEB> ok
[23:52:25 CET] <AlexMax> avcodec_find_decoder_by_name("h264_mmal"); right?
[23:52:31 CET] <JEEB> yea
[23:52:36 CET] <AlexMax> some codec not found error
[23:53:15 CET] <AlexMax> "Couldn't find decoder" was the specific error
[23:54:04 CET] <AlexMax> To be frank, I know very little about the ffmpeg API and I've been repurposing some existing working code that was built for nearly my exact use-case
[23:54:55 CET] <AlexMax> but in the old codebase, ffmpeg was not used to hardware-decode on the raspberry pi, presumably because the ffmpeg provided didn't support it
[23:55:21 CET] <AlexMax> Now it does, and I want to reduce code complexity by having as much stuff as possible funnel through ffmpeg
[23:55:43 CET] <AlexMax> with maybe a non-ffmpeg fallback on windows
[23:56:52 CET] <JEEB> windows has d3d11 and dxva2
[23:57:05 CET] <JEEB> *d3d11va
[23:58:48 CET] <AlexMax> Well, more to not have an ffmpeg dependency on windows - building stuff on windows is a pain anyway, and at the end of the day I need a single .dll file with no other depenedncies
[23:59:16 CET] <JEEB> dunno, mingw-w64 works comfy enough for me
[23:59:32 CET] <JEEB> the only thing I hate about windows dev is that there's no valgrind
[23:59:37 CET] <AlexMax> I dunno, that's kinda beside the point
[00:00:00 CET] --- Thu Nov 15 2018

More information about the Ffmpeg-devel-irc mailing list