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

[burek]

[00:12:06 CEST] <JEEB> and finally got to re-sending the smooth streaming things...
[02:14:46 CEST] <durandal_1707> ffmpeg doesnt support opus in mp4?
[03:52:00 CEST] <cone-178> ffmpeg 03James Almer 07master:64545dd60013: ffprobe: don't access AVCodecContext.pkt_timebase directly
[04:38:30 CEST] <noobe1> In movenc.c, 
[04:38:30 CEST] <noobe1> static void mux_frames(int n) at the end, there is  AV_WB32(pktdata + 4, pkt.pts);.  Why is it necessary to write 8 bytes of pts/dts before writing actual packet to file? 
[05:45:14 CEST] <noobe1> I'm looking for muxing raw compressed h264 data into a container (e.g. MP4) without.  What would be best source code to look at in ffmpeg? 
[06:00:26 CEST] <noobe1> does the command FFmpeg -framerate 30000/1001 -i "Video.h264" -codec copy -y "Video.mp4" decompress and recompress? or does it do raw copy? 
[06:12:47 CEST] <noobe1> anyone know what *.c file ends up muxing in the above command?? Thanks!!
[08:34:09 CEST] <JEEB> durandal_1707: the patch from el goog had issues so it's not merged
[08:34:21 CEST] <JEEB> (opus in isobmff)
[09:09:06 CEST] <cone-202> ffmpeg 03Carl Eugen Hoyos 07master:dcc506a91e77: doc: Mention -dn in the "Stream selection" paragraph.
[09:11:39 CEST] <rcombs> why do we have 3 different names for types of stereo3d modes
[09:12:34 CEST] <nevcairiel> probably usual reasons, merges and local development
[09:13:05 CEST] <rcombs> all of which cover different sets of possible formats
[09:14:19 CEST] <rcombs> one in lavf/matroska (exported in stream metadata) and lavc/h264_sei (exported in frame metadata), one in lavu/stereo3d, one in lavfi/vf_stereo3d
[09:14:57 CEST] <rcombs> the first is machine-formatted, the second is human-formatted, the third is _very_ machine-formatted
[09:15:48 CEST] <nevcairiel> i thought h264 and matroska would use the same data by now
[09:17:26 CEST] <rcombs> lavc/h264_sei uses the same names as lavf/matroska, but exports at the frame level instead of the stream level
[09:17:52 CEST] <rcombs> lavc/h264_slice exports an AVStereo3D side_data, which means a different set of names
[09:18:56 CEST] <nevcairiel> mkv also exports AVStereo3D
[09:20:28 CEST] <rcombs> ah, so I guess AVStereo3D stream side_data is always available, and I should go with that
[09:20:31 CEST] <nevcairiel> there appears to be some duplication due to an earlier string metadata format, but the AVStereo3D format is supposedly the new  stuff
[09:20:48 CEST] <nevcairiel> its either stream level if its from the container, or frame level  from the decoders
[09:20:50 CEST] <rcombs> also there's a function to get a name for an AVStereo3D but it ignores whether it's inverted
[09:21:35 CEST] <rcombs> isn't there something somewhere to copy frame side data to the stream
[09:24:43 CEST] <rcombs> &looks like no, so I guess there's no way to get stereo3d information at the bitstream level from find_stream_info
[09:26:46 CEST] <nevcairiel> arent you one of those that wants to stop find_stream_info from decoding anyway :D
[09:29:43 CEST] <rcombs> yeah but this is totally doable at the parser level
[09:29:57 CEST] <rcombs> except that parsers don't have access to anything they could use to export this
[09:30:02 CEST] <rcombs> (for ~some reason~)
[09:32:09 CEST] <rcombs> also, is there a standard way to distinguish e.g. "half-sbs" from "full-abs"
[09:32:12 CEST] <rcombs> *sbs
[09:33:19 CEST] <nevcairiel> whats with everyone wanting to do 3D all of the sudden anyway. CE vendors discontinue 3D, and suddenly there is software demand for it, now that screens are going away? =P
[09:34:15 CEST] <rcombs> tbh I just happened to stumble upon a GitHub issue about reporting it in analysis data and figured I'd check to see if it was easy to add
[09:34:36 CEST] <rcombs> and then read through the relevant code and went "wat is dis"
[09:35:26 CEST] <rcombs> as if often the case, each piece makes sense if you ignore the fact that all of the others exist
[10:37:54 CEST] <JEEB> -_- so was the FFmpeg code style to have braces or not around single-line if/elses
[10:39:11 CEST] <nevcairiel> dont think there is a fixed rule, if its a short single-line statement i wouldnt put braces, but if its long, has an else, or something like that, I would
[10:39:57 CEST] <JEEB> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/200119.html
[10:40:13 CEST] <JEEB> then http://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/200147.html
[10:40:23 CEST] <JEEB> "please consider adding braces to the if-else clause
[10:40:31 CEST] <nevcairiel> i would probably use  braces there because it has an else
[10:40:36 CEST] <JEEB> ok
[10:41:10 CEST] <JEEB> I just remember at some point people wanting to not have those braces
[10:41:18 CEST] <JEEB> for single-line if/elses
[10:41:36 CEST] <nevcairiel> like I said i dont think there is an established rule for that, so its up to everyones style, i guess
[10:41:53 CEST] <JEEB> at least this way is better than "remove those parenthesis"
[10:49:11 CEST] <rcombs> I usually do no braces if everything in an if/else if/else chain is single-line
[10:49:19 CEST] <rcombs> but if anything is multiple lines then everything gets braces
[10:49:30 CEST] <rcombs> not a big deal in any case, though
[10:56:24 CEST] <JEEB> yeah, I got the single-line => no braces thing from x264 I think?
[10:56:35 CEST] <JEEB> although I also think back a few years ago I got bit by that as well
[12:54:03 CEST] <cone-202> ffmpeg 03Michael Niedermayer 07master:740f5105d5bd: swresample: Use double and float for matrixes for best quality and speed
[13:12:30 CEST] <cone-202> ffmpeg 03Michael Niedermayer 07master:23c0779cda8c: swresample: Add swr_build_matrix()
[14:37:06 CEST] <BtbN> steve at j2eeguys.com should fix his mailserver please.
[14:37:25 CEST] <BtbN> Getting every mail bounced from ffmpeg-devel...
[15:38:57 CEST] <cone-202> ffmpeg 03Michael Niedermayer 07master:fd902510ac92: swr: Update version & APIChanges for swr_build_matrix()
[15:45:24 CEST] <cone-202> ffmpeg 03James Almer 07master:f0b6f7253f3e: avformat: add av_stream_get_codec_timebase()
[15:45:25 CEST] <cone-202> ffmpeg 03James Almer 07master:4a05d2eda721: ffmpeg: stop using AVStream.codec on stream copy
[15:47:12 CEST] <jamrial> ubitux: just applied the last of the codecpar commits that were noop'd
[15:58:38 CEST] <ubitux> nice :)
[15:58:44 CEST] <ubitux> thanks jamrial_ :)
[16:01:17 CEST] <jamrial_> that commit was supposed to also remove the avcodec_copy_context call in the non stream copy case, but at least some packet pts/duration code in lavf still seems to need st->codec
[16:10:01 CEST] <wm4> I can agree those <steve at j2eeguys.com> bounces, right?
[16:34:39 CEST] <anrao> durandal_170: you there ?
[16:42:05 CEST] <ubitux> jamrial_: btw, what happened to the channel layout fix in libav?
[16:44:24 CEST] <wm4> s/agree/ignore/ (how did this happen)
[16:48:42 CEST] <jamrial_> ubitux: they didn't like input codecpar being modified, and prefer a local codecpar being used instead
[17:21:54 CEST] <kierank> that guy really wants scte35
[17:22:01 CEST] <kierank> ffmpeg is really the dumping ground of people's crap
[17:29:29 CEST] <Chloe> wm4: I was wondering what that was
[17:30:02 CEST] <BBB> I dont mind having features
[17:30:05 CEST] <BBB> as long as theyre not outrageous
[17:30:14 CEST] <BBB> I have no idea what scte35 is, though
[17:31:02 CEST] <Chloe> I thought we were going to call 3.2 mrrobot
[17:31:13 CEST] <nevcairiel> as I understand it, some sort of metadata in mpegts to indicate when commercial breaks etc start, so you can use it to segment a stream
[17:32:54 CEST] <funman> https://en.wikipedia.org/wiki/Digital_program_insertion
[17:39:40 CEST] <kierank> BBB: it's amessy feature
[17:39:44 CEST] <kierank> it doesn't fit into ffmpeg
[17:41:31 CEST] <thardin> just tell them to maintain their own branch
[17:41:58 CEST] <kierank> I did and he said his customers don't want to do it
[17:42:12 CEST] <BBB> customers always want it upstream
[17:42:30 CEST] <kierank> want people to maintain it for free
[17:44:13 CEST] <Chloe> can it be integrated in such a way that if it breaks anything in the future (and the guy wont/cant fix it) that it will just immediately be dropped?
[17:48:11 CEST] <kierank> of course not
[17:48:17 CEST] <kierank> it doesn't even have pts and dts
[17:51:31 CEST] <Chloe> can it be implemented from using the public API?
[17:51:52 CEST] <nevcairiel> no
[17:59:48 CEST] <thardin> I'd charge some appropriate, regular sum to maintain it
[18:15:44 CEST] <wm4> nevcairiel: why not? (haven't really followed this)
[18:15:55 CEST] <wm4> surely there's some way to export parts of the raw data or whatever
[18:16:16 CEST] <nevcairiel> well you still need internal stuff to first do that
[18:16:33 CEST] <nevcairiel> and when you export it as a data stream or whatever, you might as well assign it a codec id
[18:19:25 CEST] <wm4> btw. does anyone have a indent command for ffmpeg codec style?
[18:21:06 CEST] <Chloe> similar to 'indent -i4 -kr -nut' according to the website
[18:21:14 CEST] <Chloe> https://www.ffmpeg.org/developer.html#Code-formatting-conventions
[18:22:55 CEST] <wm4> ah didn't see that
[18:27:05 CEST] <kylophone> Is there a quick way to configure and make ffmpeg by reusing the configuration string from a previously built ffmpeg?
[18:27:55 CEST] <kylophone> Imagining something like this: `./configure $(ffmpeg -configuration) && make install`
[18:29:51 CEST] <drv> ./configure $(ffmpeg 2>&1 | grep configuration | cut -d: -f2-)
[18:30:02 CEST] <drv> (not tested, but something like that should do the trick)
[18:30:38 CEST] <kylophone> Not pretty, but should work. Thanks!
[18:31:31 CEST] <Chloe> I like the idea of a ffmpeg --build_flags though
[18:31:50 CEST] <jamrial_> there is. "ffmpeg -buildconf"
[18:32:05 CEST] <kylophone> Ah, cool.
[18:32:24 CEST] <jamrial_> not sure if it's any better than just using drv's command, though
[18:32:29 CEST] <Chloe> jamrial_: still needs sed magic
[18:32:40 CEST] <jamrial_> yeah
[18:32:53 CEST] <Chloe> if the configuration: was output to stderr then it'd work
[21:05:47 CEST] <Chloe> is 'libavcodec/qdm2.c: fix warning due to misleading indentation' corrupt for anyone else?
[21:06:12 CEST] <Chloe> git am dies, and patchwork seems to have misparsed it as well
[21:12:13 CEST] <jkqxz> Chloe:  Yes, it has extraneous linebreaks.
[21:12:48 CEST] <cone-202> ffmpeg 03Mulvya 07master:a54c3ff65f87: doc/filters: blend terminates on longest input
[23:38:25 CEST] <Chloe> ubitux: make config returns the config of a ffmpeg binary?
[23:38:46 CEST] <nevcairiel> make config re-runs configure with the previous settings, afaik
[23:39:55 CEST] <Chloe> Ah right, ok. That's not what the patch on the ML is aiming to do afaik
[23:41:20 CEST] <ubitux> yes but it sounds likely that he wrote the patch in order to achieve that same goal but in a "generic" way
[23:41:37 CEST] <ubitux> maybe i'm wrong, i'm just suggesting something
[23:42:08 CEST] <Chloe> ubitux: either way, I think it's a useful patch potentially.
[23:42:31 CEST] <nevcairiel> it sounds like he only has the binary of the old version, but imho its fine to have it output a header for more human friendlyness
[23:42:56 CEST] <nevcairiel> if one wanted to automate something, why not keep the config string somewhere
[23:42:58 CEST] <nevcairiel> but shrug
[23:43:20 CEST] <Chloe> isnt the config string kept?
[23:54:57 CEST] <nevcairiel> guess he was happy with make config
[23:55:05 CEST] <Chloe> yep, looks like it
[23:56:32 CEST] <Chloe> I can apply trivial stuff like a warning fix without having to be the maintainer of it, right? (talking about the patch from Adriano Pallavicino) It passes fate, and looks good.
[00:00:00 CEST] --- Wed Sep 28 2016