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

[burek]

[01:38:17 CEST] <JEEB> lol, when you have three sets of widths and heights and they are uint32_t, you suddenly have to do a whole lot of checks for value sanity :D
[01:53:22 CEST] <JEEB> there, sent an initial version to ML
[03:30:24 CEST] <cone-962> ffmpeg 03Jean-Yves Simon 07master:fb37da37ac1e: avcodec/hevc: Add YUV420P10 to vaapi hardware decode - permits hardware decoding of HEVC Main 10 on AMD RX 480
[08:31:33 CEST] <noobe1> Greetings.  Anyone has a working sample code of using AVOutputFormat to write to output mp4 file? I looked a sample h264 mp4 file and it has SEI right after "mdat". Anyone know if this is auto generated by av_write_frame()? Thanks!
[08:43:40 CEST] <monery> greetings channel, would this be the place to discuss error messages with nvenc compiled?
[08:51:31 CEST] <cone-988> ffmpeg 03Carl Eugen Hoyos 07master:46aae846165c: lavf/movenc: Allow to disable writing the timecode track.
[09:45:39 CEST] <JEEB> uhh, how should I read this? http://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/200080.html
[09:46:01 CEST] <JEEB> also I probably misused the word "overflow", but that was the closest word my dumb brain could think of at that point
[09:46:33 CEST] <JEEB> so we shouldn't check the values in the demuxer because the rest of the framework ignores certain values? :D
[10:02:07 CEST] <rcombs> apparently out-of-range unsigned->signed casts are _implementation-defined_ (as opposed to signed integer arithmetic overflow, which is _undefined_)
[10:02:33 CEST] <nevcairiel> still causes odd things to happen either way, you dont get the original value
[10:03:12 CEST] <rcombs> ^ yeah
[10:03:27 CEST] <rcombs> not really relevant here since it needs to be checked anyway, but good to know
[10:03:57 CEST] <rcombs> implementation-defined I guess because one's complement is technically legal but afaik literally nobody does that
[10:05:54 CEST] <JEEB> also this clearly shows that we need a definition of what the codecpar->width/height mean :)
[10:05:57 CEST] <JEEB> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/200072.html
[10:06:35 CEST] <JEEB> because the display_{width,height} is what should be output after decode, decoder cropping and then container cropping
[10:11:03 CEST] <rcombs> can we just change codecpar->width/height to unsigned
[10:12:02 CEST] <nevcairiel> no
[10:12:54 CEST] <nevcairiel> all w/h in avcodec are signed everywhere
[10:13:25 CEST] <JEEB> so the next step would be int64_t?
[10:13:50 CEST] <nevcairiel> i dont think there is a strong enough argument for w/h exceeding int32? how big of an image do you need? =P
[10:13:57 CEST] <rcombs> well that's actually a bigger type and is ridiculous
[10:14:15 CEST] <JEEB> well if we can't utilize unsigned version of a smaller type?
[10:14:17 CEST] <rcombs> whereas unsigned deals with this problem nicely and is more semantically sensible anyway
[10:14:38 CEST] <JEEB> well nev just said that's NG
[10:14:41 CEST] <rcombs> I don't think there's a reason we can't, other than that it'd require fixing it in a bunch of place
[10:14:43 CEST] <rcombs> *places
[10:14:52 CEST] <nevcairiel> also breakage everywhere
[10:14:54 CEST] <nevcairiel> imho not worth it
[10:14:57 CEST] <nevcairiel> whats to gain?
[10:15:37 CEST] <rcombs> it's less dumb; I guess we could just stick it in next time there's a major bump?
[10:15:44 CEST] <nevcairiel> why do you have images between 2 billion and 4 billion pixels wide? :d
[10:16:05 CEST] <nevcairiel> "less dumb" in itself is not e nough reason for me to really considersuch a change
[10:16:35 CEST] <rcombs> nobody does, but why are your fields signed when negative values are meaningless
[10:16:37 CEST] <nevcairiel> the way I see it, public api changes should be justified
[10:16:39 CEST] <rcombs> fair enough
[10:17:28 CEST] <rcombs> but oi stop using signed integers where they don't make any sense
[10:17:50 CEST] Action: rcombs shakes stick at ancient history
[10:22:30 CEST] <ubitux> JEEB: it's not a good idea to use unsigned for width/height
[10:22:47 CEST] <ubitux> it might actually slow down x/y loops over width/height ;)
[10:23:31 CEST] <ubitux> (overflow is defined in unsigned, so compiler can't make certain assumptions)
[10:24:20 CEST] <rcombs> none of those assumptions are relevant, though
[10:25:07 CEST] <rcombs> like, "it won't overflow" was already a given if you're doing `for (i = 0; i < height; i++)` and both i and height are unsigned
[10:25:51 CEST] <ubitux> for (y = slice_start; y < slice_end; y++)
[10:26:47 CEST] <rcombs> still can't overflow
[10:29:04 CEST] <ubitux> the compiler might not be able to tell if slice_start > slice_end
[10:29:46 CEST] <rcombs> hmm?
[10:32:08 CEST] <ubitux> the compiler might not be able to tell if slice_start = 100 and slice_end = 50 at the beginning of the loop, so he will assume y can go backward sometimes
[10:32:50 CEST] <ubitux> mmh wait sorry my bad
[10:32:59 CEST] <rcombs> it knows y is never decremented, and it can't overflow since there's a < check against a value of the same size
[10:33:03 CEST] <ubitux> what's the case i was thinking about...
[10:34:40 CEST] <ubitux> https://kristerw.blogspot.fr/2016/02/how-undefined-signed-overflow-enables.html a bunch of examples here
[10:34:58 CEST] <ubitux> i use a broken and wrong example, sorry
[10:37:23 CEST] <rcombs> all of those things are ways that signed overflow being undefined is more convenient to the compiler than it being implementation-defined or defined in an inconvenient way
[10:37:51 CEST] <rcombs> I don't think any of them are applicable here when compared to well-defined _unsigned_ overflow
[10:38:17 CEST] <nevcairiel> but we dont need the overflow, so any potential handling of it just adds more code?
[10:41:00 CEST] <rcombs> like, "it can assume the value will never become negative and use shifts instead of divisions" okay but an unsigned value will never become negative anyway
[10:43:12 CEST] <rcombs> I don't really care much about the suggested change; at this point I'm mostly curious if there really are any cases where unsigned is preferable to signed in cases where the value will never be negative for optimization reasons
[10:43:52 CEST] <ubitux> the point is to actually keep the signed values
[10:44:33 CEST] <rcombs> erm, sorry, swap those two
[10:44:38 CEST] <rcombs> where signed is preferable to unsigned
[10:48:08 CEST] <rcombs> I see a few possible cases around comparisons with (x + <constant>), I guess?
[13:20:17 CEST] <LA> hi there. I want to add custom network protocol (output).
[13:20:17 CEST] <LA> what is the proper way to do it? should it be a muxer - AVOutputFormat implementation
[13:20:17 CEST] <LA> or I have to make URLProtocol?
[15:36:24 CEST] <ubitux> i don't see the associated chunk in 5fa255b; noop i guess?
[15:46:46 CEST] <nevcairiel> so where is the info set in ffmpeg.c then?
[15:47:04 CEST] Action: nevcairiel pulls latest code
[15:48:43 CEST] <ubitux> it's in the !streamcopy case in transcode_init
[15:49:04 CEST] <nevcairiel> apparently transcode_init is too late in future changes, or so the commit makes one believe
[15:49:12 CEST] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg.c;h=df55a49eebda5b4eaa27062cc18a4067d1da919f;hb=HEAD#l3129
[15:49:15 CEST] <ubitux> this afaict
[15:49:37 CEST] <ubitux> i doubt i can move this in ffmpeg_opt
[15:49:48 CEST] <nevcairiel> appears so
[15:49:58 CEST] <ubitux> it seems to assume stuff like what goes out of the filtergraph etc
[15:52:18 CEST] <nevcairiel> you can always skip it and we will see what needs to be done about other things then, the immediate following commits dont seem to need it, but maybe later
[15:53:04 CEST] <nevcairiel> but its already quite different, so nothing really lost
[18:28:51 CEST] <kierank> any idea if alsa will let you send two mono streams to the same sound card?
[18:44:42 CEST] <BtbN> great, I'm getting a ton of bounces from the ml, because of dkim failures oO
[18:46:20 CEST] <cone-988> ffmpeg 03Timo Rothenpieler 07master:99b823f0a1be: avcodec/mpegvideo_enc: fix memory leak
[18:48:03 CEST] <nevcairiel> its just from one guy, i would guess his stuff is just too aggressive
[18:50:18 CEST] <BtbN> ok, so it's not me messing up my DNS
[18:50:29 CEST] <BtbN> messed around with DNSSEC
[18:51:19 CEST] <wm4> kierank: how does this question even make sense?
[18:51:38 CEST] <kierank> wm4: I want one mono stream on left and another mono stream on right
[18:51:52 CEST] <kierank> with two separate rtp sources
[18:51:57 CEST] <kierank> my question is does alsa mix them or not
[18:52:02 CEST] <BtbN> alsa will probably let you send as many streams as you want. But I doubt you'll be able to set a per-stream balance
[18:52:19 CEST] <BtbN> Provided dmix is set up or the device supports mixing natively
[18:52:36 CEST] <wm4> ALSA is a low level API, so you can access the hw device directly and workaround any plugins
[18:52:46 CEST] <wm4> and then you need to make sure the device itself does no mixing
[19:10:53 CEST] <kierank> hmm might have to try it
[19:17:36 CEST] <JEEB> heh, I had no idea of AVPanScan
[19:31:51 CEST] <wm4> JEEB: I'm sure the only people who know about it hate it
[19:33:49 CEST] <BtbN> wm4, haha, my toughts exactly regarding that ffprobe demuxer.
[19:34:08 CEST] <BtbN> I still haven't understood what the entire point of that thing is.
[19:34:41 CEST] <JEEB> wm4: is it even used anywhere?
[19:35:47 CEST] <wm4> JEEB: no idea, maybe some obscure API user?
[19:36:08 CEST] <JEEB> :D
[19:36:32 CEST] <JEEB> also I'm not sure I understand the position field in it
[19:36:58 CEST] <JEEB> int16_t AVPanScan::position[3][2] : position of the top left corner in 1/16 pel for up to 3 fields/frames 
[19:37:26 CEST] <wm4> supposedly due to something with deinterlacing considerations
[19:37:41 CEST] <wm4> s/deinterlacing/interlacing
[20:20:31 CEST] <wm4> what is codecpar->initial_padding actually used for?
[20:20:37 CEST] <wm4> encoding?
[20:23:32 CEST] <jamrial> wm4: amount of samples that need to be discarded before starting decoding, afaik
[20:23:50 CEST] <wm4> it's not used for decoding, though
[20:23:53 CEST] <jamrial> and seeing how it's in codecpar, it's container level info
[20:23:54 CEST] <wm4> not from what I can see
[20:24:05 CEST] <wm4> instead, AVStream fields are used (?)
[20:24:34 CEST] <wm4> like AVStream.start_skip_samples
[20:24:59 CEST] <jamrial> probably because we implemented it one way, then merged libav's implementation
[20:25:13 CEST] <jamrial> can't say, really
[20:25:14 CEST] <wm4> which is turned into AV_PKT_DATA_SKIP_SAMPLES
[20:25:24 CEST] <wm4> which is actually used by libavcodec
[20:25:32 CEST] <wm4> oh right, the API user is supposed to use the codecpar fields
[20:26:13 CEST] <wm4> and AVCodecContext.delay was deprecated
[20:26:26 CEST] <wm4> (still using it in mpv...)
[20:26:27 CEST] <wm4> what a mess
[20:27:14 CEST] <jamrial> deprecated for encoding, acording to its doxy
[20:28:59 CEST] <wm4> hm yeah, I guess that's why the code checks it only for decoding
[20:33:45 CEST] <debianuser> kierank> "any idea if alsa will let you send two mono streams to the same sound card?"  -- yes, if played to "default" pcm with no special configs both mono streams would be upmixed to stereo and added together. With a custom config you can do whatever you want, e.g. you can have mono stream added with 0.7 to the left channel and 0.3 to the right one.
[20:33:54 CEST] <kierank> upmixed?
[20:34:01 CEST] <kierank> what happens if i want them discrete?
[20:35:55 CEST] <debianuser> Like, playing one mono stream to left channel and another one to right channel?
[20:36:00 CEST] <kierank> correct
[20:36:16 CEST] <debianuser> Are they produced by the same program or different ones?
[20:36:20 CEST] <kierank> different program
[20:39:10 CEST] <Chloe> wm4: launching nethack?
[20:41:48 CEST] <wm4> undefined behavior
[20:42:05 CEST] <wm4> it seems it returns no value
[20:42:25 CEST] <wm4> actually, not sure if that is UB
[20:42:25 CEST] <debianuser> kierank: Then you can add to your ~/.asoundrc something like:
[20:42:27 CEST] <debianuser>   pcm.left { type route; slave.pcm "dmix"; ttable.0.0 1; }
[20:42:29 CEST] <debianuser>   pcm.right { type route; slave.pcm "dmix"; ttable.0.1 1; }
[20:42:29 CEST] <wm4> (fuck C)
[20:42:33 CEST] <debianuser> and configure your programs to play to "plug:left" or "plug:right" pcm. Can you configure your programs to play to a custom pcm? Because if it can only play to "default" - we can add one more line to read default pcm from env.variable for example.
[20:43:55 CEST] <kierank> Can add a custom pcm I guess
[20:44:11 CEST] <Chloe> why cant st->time_base be used instead?
[20:46:19 CEST] <jamrial> wm4: gcc 6.2 fails to compile it
[20:46:24 CEST] <debianuser> kierank: e.g. with   pcm.!default { @func getenv vars [ ALSA_PCM_DEFAULT ] default "sysdefault" }   added to ~/.asoundrc you can run your programs like `ALSA_PCM_DEFAULT=plug:left  ./yourprogram`
[20:46:26 CEST] <jamrial> it complains it has no return of any kind
[20:47:07 CEST] <kierank> debianuser: hmmm ok seems a bit complex
[20:47:08 CEST] <jamrial> no idea about other compilers, but failing is certainly the sanest thing to do
[20:57:16 CEST] <debianuser> kierank: Well, I can explain it if you're curious (alsa plugins idea is similar to ffmpeg filters - you build a chain of modules passing the sound to each other, like default=plug->softvol->dmix->hw, and there're modules to reroute channels around). But if those two "left" and "right" pcms work for you - you probably don't need other complex ideas. :)
[21:12:27 CEST] <wm4> jamrial: ok, I guess I still don't know how that stuff is supposed to work, so no more comments from me
[21:18:02 CEST] <jamrial> wm4: apparently, for stream copy, using the codec timebase is needed (or preferable) than copying the input stream timebase
[21:18:10 CEST] <jamrial> a bunch of tests fail if you use the latter, like this one muxing into mxf that refuses to mux anything othewise
[21:18:38 CEST] <Chloe> why is it preferable? shouldnt they always be the same?
[21:19:14 CEST] <jamrial> apparently not in some cases
[21:19:33 CEST] <Chloe> Surely that's an issue then
[21:20:10 CEST] <nevcairiel> some containers dictate odd timebases, like mpegts is always 1/90000, but some other containers may prefer something else entirely
[21:20:23 CEST] <Compn> carl didnt document -dn option? :)
[21:20:24 CEST] <Compn> ehe
[21:21:30 CEST] <nevcairiel> so container timebase doesnt have to be related to the codec framerate at all
[21:22:00 CEST] <nevcairiel> while the codec timebase probably is, if its available at all, that is
[21:22:25 CEST] <Chloe> ah, so the avstream generally relates the the container
[21:22:38 CEST] <Chloe> how do different timebases work with containers and codecs?
[21:22:38 CEST] <nevcairiel> yea
[21:24:04 CEST] <Chloe> is it just soemthing like: 3 ticks on the container is equal to 1 codec tick where the timebases are 1/90000 and 1/30000 (for example)
[21:24:30 CEST] <nevcairiel> container timebases often depend on the container itself, like mpegts i mentioned is always a fixed rate, while some other containers have a global timebase you can set for the entire file, and some for each stream individually
[21:24:55 CEST] <nevcairiel> but it doesnt have to be related to the codec timebase or the frame rate at all
[21:26:30 CEST] <nevcairiel> the codec timebase isnt really used for much, which is why its often a hot topic for discussion, since it seems to mostly be used as a hacky thing for some weird special cases
[21:28:36 CEST] <wm4> (I still don't get it)
[21:31:19 CEST] <Chloe> so if time base is handled by the container, why would the codec have a different one?
[21:31:34 CEST] <Chloe> is it just a hack, or do some codecs actually have time bases?
[21:34:35 CEST] <wm4> there's actually no decoder which requires real timestamps (and thus a timebase), except external wrappers
[21:38:55 CEST] <nevcairiel> some codecs have it yes
[21:39:06 CEST] <nevcairiel> but as wm4 says, decoders dont really need it
[21:39:17 CEST] <nevcairiel> encoders typically write it when they have fps info for rate control
[21:39:53 CEST] <nevcairiel> h264 has some timestamping info to generate timestamps from a raw stream, but avcodec doesnt use it (although it did at a time)
[21:43:00 CEST] <cone-988> ffmpeg 03Michael Niedermayer 07master:69449da43616: avcodec/ansi: Check dimensions
[00:00:00 CEST] --- Tue Sep 27 2016