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

burek burek021 at gmail.com
Wed Apr 19 03:05:04 EEST 2017


[04:07:08 CEST] <cone-121> ffmpeg 03Mickael Maison 07master:fdd4922dc489: doc/fftools-common-opts: Fixed a typo in the common arguments list
[04:07:08 CEST] <cone-121> ffmpeg 03Michael Niedermayer 07master:d0b3922d2472: ffmpeg: Clear fifo pointer on deallocation
[06:50:11 CEST] <wm4> so why does get_audio_frame_duration still exist
[06:52:34 CEST] <kierank> wm4: dunno but we ignore any ffmpeg provided frame-size apart from Avframe
[06:52:57 CEST] <kierank> we have found on corrupt data that it can produce frames > codec->frame_size
[06:56:32 CEST] <JEEB> :D
[08:02:21 CEST] <ubitux> wm4: did you get my message (here) yesterday?
[08:03:26 CEST] <wm4> ubitux: hm I guess I did
[08:16:09 CEST] <ubitux> so do you want to work on this?
[08:18:13 CEST] <wm4> I wouldn't mind but currently I'm a bit swamped
[08:31:24 CEST] <cone-310> ffmpeg 03James Zern 07master:fd1443b5dda6: doc/encoders.texi: document libvpxenc's -row-mt
[11:52:54 CEST] <funman> is there an AVStream::opaque to replace AVStream::codec::opaque ?
[11:54:09 CEST] <nevcairiel> what exactly would the use for that be?
[11:54:36 CEST] <funman> storing stuff
[11:55:03 CEST] <nevcairiel> why do you  need to store stuff in avstreams
[11:55:09 CEST] <kierank> funman: remember that ffmpeg people don't understand the concept that people use other structures apart from avframe :)
[11:55:28 CEST] <kierank> reordered data I would guess
[11:55:40 CEST] <funman> no that's for context stuff
[11:55:52 CEST] <nevcairiel> what I dont understand is why you dont have "struct FunmansStream { AVStream stream; MyData goes here }" :)
[11:55:57 CEST] <funman> nevcairiel: well per-stream data was conveniently stored in stream->codec->opaque
[11:56:13 CEST] <funman> existing code
[11:56:59 CEST] <funman> next q: how do i set AVStream->codec->flags &= CODEC_FLAG_GLOBAL_HEADER and AVStream->codec->ticks_per_frame=2 ?
[11:57:32 CEST] <nevcairiel> you just dont use avstream->codec at all
[11:57:35 CEST] <rcombs> those sound like actual codec operations
[11:57:40 CEST] <nevcairiel> because neither does avformat
[11:57:41 CEST] <rcombs> you should have your own AVCodecContext
[11:57:56 CEST] <nevcairiel> if you want to decode things, create your own AVCodecContext and set it there, like rcombs says
[11:58:17 CEST] <rcombs> (or encode; messing with CODEC_FLAG_GLOBAL_HEADER sounds like encoding?)
[11:58:31 CEST] <funman> git grep ticks_per_frame libavformat shows it is still in use
[11:59:11 CEST] <nevcairiel> only in deprecated code thats going away
[11:59:17 CEST] <rcombs> some uses of the old API are still not removed, right
[11:59:22 CEST] <rcombs> not _yet_
[11:59:54 CEST] <funman> well same for me ^_^
[11:59:55 CEST] <nevcairiel> (and for some auto-magic thats reading it from the internal decoder context used for probing, but you a re not supposed to mess with those e ither way :))
[12:00:29 CEST] <nevcairiel> you can of course still set them like you used to, until AVStream->codec  vanishes for good
[12:00:59 CEST] <funman> so i'm looking for info on how to use new API
[12:01:38 CEST] <funman> maybe ticks_per_frame is useless at avformat layer
[12:01:49 CEST] <funman> maybe to repeat PAT/PMT i should use an AVFMT flag
[12:01:50 CEST] <funman> dunno
[12:02:10 CEST] <funman> if libavformat is still not updated maybe i should wait a couple years before doing this
[12:02:24 CEST] <funman> and just dis deprecation warnings for now
[12:02:30 CEST] <funman> disable*
[12:02:31 CEST] <nevcairiel> it is updated, it just has a few layers of compat left that get used when people didnt  update their client code
[12:03:13 CEST] <nevcairiel> its a good chance to try to figure out why such things were set in your code in the first place
[13:43:59 CEST] <superware> the mp4 output format returns "Could not find tag for codec none in stream #1, codec not currently supported in container" for avformat_write_header, stream #1 is a AVMEDIA_TYPE_DATA with codec AV_CODEC_ID_NONE, any ideas?
[14:22:04 CEST] <nevcairiel> clearly you cant put arbitrary data streams into mp4
[15:12:20 CEST] <cone-248> ffmpeg 03Paul B Mahol 07master:a96db6be06cf: avcodec: add Mandsoft Screen Capture Codec decoder
[15:12:20 CEST] <cone-248> ffmpeg 03Paul B Mahol 07master:61088051bd70: avcodec: add Screen Recorder Gold Codec decoder
[15:13:26 CEST] <BBB> omg are we finally going to get rules that abolish patch blocking?
[15:13:34 CEST] <BBB> that would be the most amazing change ever in ffmpeg history
[15:15:36 CEST] <ubitux> am i missing something?
[15:39:29 CEST] <jamrial> ubitux: https://github.com/jamrial/FFmpeg/tree/mergework this one seems to work
[15:39:50 CEST] <jamrial> the following commit (making the old decode api a wrapper for the new one instead of the other way around) is far from trivial
[15:41:17 CEST] <jamrial> gave that one a try and got it mostly working, except frame pts is shifted a bit somewhere so a bunch of tests predicably fail
[16:02:54 CEST] <Gramner> J_Darnley: re. strip, I'd just prefer a more generic solution if possible instead of changing stuff in a thousand places
[16:03:57 CEST] <ubitux> jamrial: oh, cool
[16:04:27 CEST] <ubitux> but yeah the next ones looked pretty sensible and i'm not familiar with this so i gave up early
[16:04:40 CEST] <ubitux> especially since we have ppl here who know this well
[16:04:48 CEST] <ubitux> or at least better than i do
[16:06:54 CEST] <jamrial> wm4: ^
[16:07:04 CEST] <jamrial> think you could give 061a0c14bb5767bca72e3a7227ca400de439ba09 a try?
[16:41:56 CEST] <BBB> Gramner: I was actually going to ask you about that
[16:42:31 CEST] <BBB> Gramner: do you have any ideas to fix that?
[16:42:48 CEST] <BBB> Gramner: also, is the issue mac-tools specific or does it affect unix/linux tools also?
[16:44:53 CEST] <Gramner> using objdump on linux will treat local symbols the same as global ones at least
[16:45:38 CEST] <Gramner> x264 just uses strip -x on all asm to get rid of all that
[20:50:53 CEST] <TimothyGu> atomnuker: no I don't. IIRC llogan operates Twitter, and durandal_1707 has access to Google+
[20:51:30 CEST] <durandal_1707> and facebook?
[00:00:00 CEST] --- Wed Apr 19 2017


More information about the Ffmpeg-devel-irc mailing list