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

[burek]

[00:30:29 CET] <jkhsjdhjs> sorry faLUCE, noticed just now that you highlighted me
[00:31:02 CET] <jkhsjdhjs> https://hastebin.com/ogaxiwequh.bash
[00:31:06 CET] <jkhsjdhjs> this is the command
[00:32:50 CET] <jkhsjdhjs> -r 15 sadly doesn't seem to have any effect, just checked a recording
[00:43:52 CET] <faLUCE> jkhsjdhjs: rtsp AFAIK is not well supported on ffmpeg, use vlc instead
[00:44:57 CET] <jkhsjdhjs> hm, i think it's good enough supported for me. according to my understanding the problem is, that the camera reports a wrong framerate
[00:45:15 CET] <jkhsjdhjs> and i currently attempt to fix that when capturing the stream
[00:45:23 CET] <JEEB> there's a patch on the mailing list that lets you use -r before input like you did
[00:45:33 CET] <JEEB> although I'm not 100% sure if it works with anything else than raw streams
[00:45:56 CET] <jkhsjdhjs> hm, interesting, thanks for the info!
[00:46:00 CET] <JEEB> there's also an option to set the input timestamps to match receipt (more or less) timestamps
[00:46:04 CET] <faLUCE> jkhsjdhjs: it's not sure that this is a wrong framerate. It could be a reference framerate
[00:47:02 CET] <faLUCE> how are you sure that the camera reports a wrong framerate?
[00:49:23 CET] <jkhsjdhjs> i'm not sure. you could be right, maybe it's just a reference framerate. but i thought ffmpeg is a program developed over years by skilled developers. and the camera is rather cheap
[00:50:12 CET] <faLUCE> jkhsjdhjs: of course ffmpeg is developed by skilled developers but some parts could not have an up to date support...
[00:50:19 CET] <faLUCE> jkhsjdhjs: ffmpeg is huge
[00:50:45 CET] <faLUCE> jkhsjdhjs: I remember that in the past years I always had troubles with rtsp on ffmpeg, and no troubles at all with vlc
[00:50:53 CET] <damdai> i just saw a website that has to wait 60 seconds to go to the next page, but  that 60 seconds stops when you minimize the browser and go to different windows.  only way for 60 seconds to go to zero is you litterally have to stare at the scren,  HOW is this possible?
[00:50:56 CET] <DHE> I've used rtsp webcams in the past with ffmpeg. ran fine for days at a time considering.
[00:51:31 CET] <jkhsjdhjs> that's true faLUCE
[00:51:44 CET] <faLUCE> anyway, you should try if with other players you experience the same frame rate problem
[00:51:46 CET] <jkhsjdhjs> does vlc offer a headless version?
[00:52:05 CET] <faLUCE> jkhsjdhjs: at least, what does it happen if you record the rtsp stream?
[00:52:12 CET] <faLUCE> does it provide a wrong frame rate?
[00:52:59 CET] <jkhsjdhjs> you mean when i record it with vlc?
[00:53:11 CET] <faLUCE> no, I mean when you record it with ffmpeg
[00:54:25 CET] <jkhsjdhjs> the frames the camera sends get recorded. but since it's only 15fps instead of 25fps, the recorded duration is shorter then the time actually recorded
[00:54:40 CET] <jkhsjdhjs> if i record 1 hour the file will have a duration of about 38 minutes
[00:56:10 CET] <faLUCE> jkhsjdhjs: https://tools.ietf.org/html/rfc4566  <--- do you have the framerate in the sdp description?  If so, the rfc doc says that that value is a recomandation
[00:56:16 CET] <faLUCE> not the exact value
[00:57:35 CET] <jkhsjdhjs> where can i view the sdp description? it it the metadata shown by ffmpeg at record start?
[01:03:17 CET] <faLUCE> jkhsjdhjs: I would try with a player with a verbose output
[01:16:32 CET] <jkhsjdhjs> ok thanks, i'll try to take a look on the sdp
[01:19:15 CET] <faLUCE> yw
[01:48:43 CET] <Retro64XYZ> Can anyone help me convert 'ffmpeg -i input.mp4 -c:v libx264 -crf 24 -b:v 1M -c:a aac output.mp4' into a python-ffmpeg equivalent?
[01:49:07 CET] <Retro64XYZ> I am trying to write a script to convert my anime into smaller files.
[02:11:16 CET] <Retro64XYZ> https://pastebin.com/7m2QTauy This is what I have right now but it errors out due to missing input stream. Obviously I am doing something wrong. Can any one help make this work?
[02:20:03 CET] <Retro64XYZ> Never mind. I got it working. Should I post the fix or do I just leave it at 'Fixed'?
[02:20:21 CET] <faLUCE> Retro64XYZ: was it a path issue? :-)
[02:21:02 CET] <damdai> from which ffmpeg version, did  ffmpeg started supporting   Stream #0:0: Audio: dst (DST  / 0x20545344), 352800 Hz, 5.1(side), flt
[02:21:06 CET] <Retro64XYZ> No, formatting. I changed to a different method of formatting and I needed to specify lib(x)<--264 and not just lib264.
[02:21:18 CET] <faLUCE> ok
[02:28:21 CET] <damdai> i was told opusenc  does not support  44.1khz : is this true?
[02:28:29 CET] <damdai> i was told opus does not support  44.1khz : is this true?
[02:33:12 CET] <faLUCE> damdai: the available sample rates are      48000, 24000, 16000, 12000, 8000, 0,
[02:33:34 CET] <damdai> faluce thanks
[02:33:50 CET] <damdai> i wonder why it doesn't support 44.1
[02:34:36 CET] <faLUCE> damdai: https://github.com/xiph/opus/issues/43
[02:35:23 CET] <damdai> is that opus bugreport website?
[02:35:41 CET] <faLUCE> not exactly, it explains why adding 44.1 would be unuseful
[02:36:13 CET] <faLUCE> (basically because it's not loseless)
[02:36:49 CET] <damdai> okay let me read
[02:37:18 CET] <faLUCE> I'm using opus and I find it excellent. It has a very low latency
[02:37:43 CET] <damdai> i am so confused: people in #opus is saying it does support 44.1
[02:38:05 CET] <faLUCE> damdai: the ffmpeg wrapper doesn't
[02:38:09 CET] <damdai> [18:34] <+gmaxwell> I wouldn't be shocked if _ffmpeg_ (not opusenc) didn't support 44100, but openenc happily does.
[02:38:09 CET] <damdai> [18:34] <damdai> it's it same thing
[02:38:09 CET] <damdai> [18:34] <damdai> don't they both use same lib
[02:38:09 CET] <damdai> [18:35] <+gmaxwell> It's not the same thing
[02:53:41 CET] <damdai> faclue i have no idea what gmaxwell is talking about
[02:53:47 CET] <damdai> faluce
[02:53:55 CET] <faLUCE> damdai: ?
[02:54:04 CET] <damdai> so it does support 44.1 or not
[02:54:17 CET] <faLUCE> damdai: he says that it supports it
[02:54:40 CET] <damdai> but he keeps talking about how opus like 48 integers
[02:54:44 CET] <faLUCE> damdai: he says that it supports it as INPUT but not as OUTPUT
[02:55:22 CET] <faLUCE> instead, from what I see, ffmpeg considers that samplerate a "global" one
[02:55:27 CET] <faLUCE> do you understand?
[02:55:32 CET] <damdai> so you can do  clean   44-1.wav to  44.1.opus
[02:55:46 CET] <faLUCE> yes, but only as input
[02:55:53 CET] <faLUCE> the output will be 48
[02:56:02 CET] <damdai> output meaning, only during playback?
[02:56:08 CET] <faLUCE> yes
[02:56:11 CET] <damdai> i see
[02:56:24 CET] <damdai> but ffmpeg does not even support 44.1 as input (at least right now)
[02:56:29 CET] <damdai> ??
[02:56:40 CET] <faLUCE> damdai: in fact this could be a limitation
[02:57:02 CET] <faLUCE> I don't know why ffmpeg people made this limitation
[02:57:37 CET] <faLUCE> maybe they thought that input was resampled. Dunno.
[02:57:51 CET] <faLUCE> maybe gmaxwell is wrong and the input is really resampled
[02:58:27 CET] <damdai> does this paste prove anything?  https://0bin.net/paste/QqX3c1N9SnGYArz6#W0wazxWh3q3i6RZrp+z1dCIKQAQLHKah2aPfKpLh4pg
[02:58:55 CET] <damdai> in your opinion
[02:59:15 CET] <faLUCE> from what I see, it doesn't prove
[02:59:23 CET] <damdai> i see
[02:59:28 CET] <faLUCE> because you can't know if the input has been resampled before processing
[03:00:19 CET] <faLUCE> I mean, it could be   1)   input 44.1 ---> resample to 48 ---> encode ---> output 48     OR   2) input 44.1 ---> encode ---> output 48
[03:02:22 CET] <damdai> which one is gmaxwell claiming?  1 or 2
[03:02:33 CET] <faLUCE> damdai: 2)
[03:03:00 CET] <damdai> i see
[04:14:00 CET] <kepstin> internally, opus encodes at 48khz and a couple divisions thereof depending on the particular encoding mode and tools it's using
[04:14:12 CET] <kepstin> most input will end up being resampled to 48kHz before encoding
[04:16:17 CET] <damdai> kepstin not according to opus dev
[04:16:37 CET] <damdai> if you use opusenc binary
[04:16:56 CET] <kepstin> i mean, you can technically run the opus encoder in celt-only mode at arbitrary sample rates, but that's not following the spec so it's not officially "opus"
[04:17:18 CET] <damdai> opusenc is  "official opus binary"
[04:19:09 CET] <kepstin> damdai: not sure what you're on about. opusenc (the tool) accepts input at arbitrary sample rates, but resamples to 48khz before encoding.
[04:19:23 CET] <kepstin> notably, opusenc *does* store the original sample rate as metadata in the ogg opus file
[04:19:48 CET] <damdai> kepstin join #opus because that's not what the opus devs are saying
[04:19:48 CET] <kepstin> and i think opusdec can use that to resample the when decoding from 48kHz back to what the input was
[04:21:46 CET] <damdai> kepstin let me paste you the logs
[04:22:31 CET] <damdai> https://pastebin.com/7DpAxMUe
[04:25:30 CET] <kepstin> hmm, they say that opus can produce an exact number of output samples for arbitrary input sample rates, which is kind of interesting.
[04:25:46 CET] <kepstin> kind of a weird edge case, but sure.
[04:27:00 CET] <damdai> kepstin so what did you learn from that log
[04:27:31 CET] <kepstin> that the libopus encoder/decoder can preserve an exact number of samples when the input/output rate is something other than 48kHz
[04:27:55 CET] <damdai> then why can't ffmpeg ?
[04:28:02 CET] <kepstin> which is more a property of their resampler than anything else, really.
[04:28:04 CET] <damdai> then why can't ffmpeg using libopus ?
[04:30:05 CET] <kepstin> it's not required by the opus spec, so I guess nobody bothered with the internal opus decoder, and it never got added to the libopus wrapper.
[04:31:04 CET] <damdai> kepstin are you ffmpeg dev?
[04:31:29 CET] <kepstin> you'll need to better define "ffmpeg dev"
[04:31:41 CET] <kepstin> i am a developer who has written code that's been merged into ffmpeg
[04:31:43 CET] <kepstin> fwiw.
[04:31:58 CET] <damdai> do you have access to ffmpeg dev site?
[04:32:19 CET] <kepstin> what do you mean "dev site"?
[04:32:39 CET] <damdai> ffmpeg site then
[04:34:16 CET] <kepstin> what about it? most of the stuff on there is just autogenerated from the ffmpeg source code.
[04:36:02 CET] <damdai> lol never mind
[04:37:38 CET] <damdai> why can't single player  able to find proper length of .mlp file?  including  ffprobe/ffplay
[04:37:50 CET] <kepstin> it's not like there's any secret cabal of ffmpeg developers, I mean the link to the development irc channel is right in the topic of this one.
[04:38:07 CET] <damdai> kepstin but i am sure some dev have more access than the other
[04:38:29 CET] <damdai> it's not like anybody can upload a ffmpeg binary to  ffmpeg.org
[04:38:40 CET] <kepstin> yeah, some have the ability to commit directly to the git tree (and they're also responsible for merging stuff from other contributors)
[04:39:02 CET] Action: kepstin has no idea about mlp
[04:39:26 CET] <damdai> kepstin i see,  but if ffmpeg doesn't fix it , then nobody else will
[04:39:39 CET] <damdai> almost everything relies on ffmpeg
[04:39:43 CET] <kepstin> assuming that's a raw bitstream of a compressed format, it makes sense that the length would be tricky to determine
[04:39:57 CET] <kepstin> it's not like pcm where you can just measure the file size
[04:40:11 CET] <kepstin> and without headers, there's no metadata for length
[04:41:09 CET] <kepstin> i suspect this is very much a case of "if you can figure out how to do it in a reasonable way, please send a patch"
[04:42:01 CET] <damdai> i've seen ffprobe giving warning to a different audio format;  it will calculate duration by filesize but this might not be accurate
[04:42:09 CET] <damdai> sayying something like that
[04:42:30 CET] <damdai> but it was accurate
[04:42:37 CET] <kepstin> there's some code for that in a few specific demuxers in cases where it can make an educated guess
[04:42:57 CET] <damdai> if ffprobe can do that with that format, why can't it work with MLP
[04:43:25 CET] <kepstin> because it requires format specific knowledge to make an educated guess, and it's only been implemented in a few specific demuxers
[04:43:26 CET] <damdai> uration: N/A, start: 0.000000, bitrate: N/A
[04:43:26 CET] <damdai>     Stream #0:0: Audio: mlp, 96000 Hz, 5.1, s32 (24 bit)
[04:43:48 CET] <kepstin> iirc it works reasonably well in mp3 because a lot of mp3 content is constant bitrate, or has a xing header with average bitrate
[04:44:19 CET] <damdai> xing ? that's one of the rare mp3 encoders
[04:44:23 CET] <damdai> that nobody uses
[04:44:44 CET] <kepstin> sure, but xing encoder wrote an extra header with some metadata, and the lame encoder and a bunch of others copied it
[04:44:56 CET] <kepstin> so that header is a de-facto standard now
[04:45:05 CET] <damdai> kepstin i see,  metadata on mp3 was invented by xing first?
[04:45:23 CET] <damdai> didn't know that
[04:45:35 CET] <kepstin> no, it wasn't. this one particular header containing information that helps determine the length of vbr mp3 files was invented by xing.
[04:46:03 CET] <damdai> i see
[04:46:12 CET] <damdai> what about for VBR AAC or VBR OPUS
[04:46:26 CET] <kepstin> aac is typically used in an mp3 container, which has length as metadata
[04:46:41 CET] <kepstin> opus has to be stored in a container, and in ogg opus it has timestamped packets so you can figure out the length
[04:46:45 CET] <damdai> aac uses same container as mp3 ?
[04:46:48 CET] <kepstin> er, mp4 container*
[04:46:48 CET] <damdai> didn't know that either
[04:46:52 CET] <kepstin> typo :)
[04:46:55 CET] <damdai> oh
[04:48:05 CET] <damdai> Duration: 00:04:19.17, bitrate: 6819 kb/s
[04:48:05 CET] <damdai>     Stream #0:0: Audio: dst (DST  / 0x20545344), 352800 Hz, 5.1(side), flt
[04:48:36 CET] <damdai> only MLP has this issue of not finding the duration
[04:49:11 CET] <kepstin> lots of formats can't determine a duration, or can do so only unreliably. it's not just mlp
[04:49:18 CET] <kepstin> but if you know how to do it, please share
[04:49:38 CET] <damdai> kepstin what other format can you think off right now
[04:50:38 CET] <kepstin> i have no idea what 80%+ of the formats ffmpeg supports even are, since there's a lot of esoteric stuff.
[04:51:15 CET] <kepstin> obviously you have to exclude network/live streaming formats since the concept of length doesn't make sense for those at all
[04:51:40 CET] <damdai> i am interested in what version of ffmpeg did ffmpeg started supporting "DST"  how do i find out
[04:52:08 CET] <kepstin> damdai: look through the news posts to see when it's mentioned, check the git logs for the dst files.
[04:52:24 CET] <damdai> does ffmpeg even use github?
[04:52:30 CET] <kepstin> git, not github
[04:52:34 CET] <damdai> oh
[04:52:50 CET] <kepstin> (there is actually a github mirror of ffmpeg's git repository, tho)
[04:52:55 CET] <damdai> why can't ffmpeg use github
[04:53:04 CET] <damdai> github is really nice
[04:54:12 CET] <kepstin> dunno entirely. probably part of it is to add an extra barrier for people contributing code rather than having open pull requests (most code is still reviewed on a mailing list before being committed)
[04:55:04 CET] <damdai> how can ffmpeg even playback DSD  when i don't even have a soundcard that only supports PCM
[04:55:30 CET] <kepstin> i cannot parse the grammar of that sentence
[04:55:46 CET] <damdai> how can ffmpeg even playback DSD  when i have a soundcard that only supports PCM
[04:55:48 CET] <damdai> sorry
[04:56:12 CET] <damdai> most people don't have dsd soundcard
[04:56:16 CET] <kepstin> ffmpeg has a dsd "decoder" that converts it to pcm
[04:56:36 CET] <damdai> don't you still need a dsd DAC ?
[04:56:49 CET] <kepstin> no, because after you convert it to pcm, it's pcm
[04:56:56 CET] <kepstin> so you can use a normal pcm dac
[04:57:36 CET] <damdai> i am guessing you lose a lot of quality during that converting by ffmpeg
[04:57:48 CET] <damdai> conversion*
[04:58:12 CET] <kepstin> should introduce very little distortion, well below the audible range
[04:58:54 CET] <kepstin> some claims i've seen are that the dsd to pcm conversion should in theory be lossless
[04:59:14 CET] <damdai> really? where did you hear that
[04:59:56 CET] <kepstin> https://wiki.jriver.com/index.php/DSD - but that assumes you're converting to ridiculously high pcm sample rates
[05:00:20 CET] <kepstin> in real use cases you'd have to downsample to something reasonable like 48kHz which would mean doing a lowpass to remove ultrasonics
[05:01:14 CET] <kepstin> (hopefully dsd dacs have such a lowpass filter builtin to avoid damaging speakers and whatnot)
[05:07:08 CET] <kepstin> i'm kind of curious where all this dsd content comes from anyways, since the vast majority of audio is recorded & mixed in pcm
[05:07:32 CET] <kepstin> i'd expect a lot of dsd stuff to actually be converted from pcm (I assume there are exceptions)
[05:10:22 CET] <damdai> kepstin SACD
[05:10:53 CET] <damdai> all sacd uses dsd
[05:12:21 CET] <kepstin> sure, but i'm willing to bet that a lot of sacds are mastered by converting pcm audio to dsd :)
[05:12:47 CET] <kepstin> (again, not all, i have definitely heard of sacds being mastered through a full dsd pipeline)
[05:13:22 CET] <damdai> no, dsd audio can be edited using  8bit dsd audio
[05:13:49 CET] <damdai> and they finalize to 1bit dsd audio
[05:25:44 CET] <kepstin> i wouldn't be surprised if most of the newer classical recordings on sacd were dsd from start to finish. and remasters of old (pre-80s) albums may have been newly digitized from analogue tapes in dsd. but other than that...
[05:25:59 CET] <kepstin> you know, i haven't actually really seen anything other than that on sacd
[05:28:44 CET] <kepstin> oh, hah, there's a sacd release of dire straits "brothers in arms", which was originally recorded/mixed/edited on sony digital audio equipment in pcm.
[05:31:13 CET] <damdai> lol , they cheated
[05:31:24 CET] <damdai> and cheating customers too
[05:31:59 CET] <damdai> how did you know it was originally in PCM?
[05:33:18 CET] <kepstin> because that's a historical record since it's once of the first CD releases marked as 'DDD', meaning recorded/mixed/mastered digitally, and it was one of the first albums recorded using a particular sony 24track digital recorder. it's a pretty well documented release because of the firsts.
[05:34:03 CET] <damdai> i see
[05:35:05 CET] <damdai> vlc nightly is so buggy, it's unusable
[14:19:35 CET] <jkhsjdhjs> hey. i'm capturing an rtsp stream with the following command: https://hastebin.com/ogaxiwequh.bash
[14:19:36 CET] <jkhsjdhjs> the problem is that ffmpeg assumes the stream has 25fps, when it actually has 15fps. this can be seen here: https://hastebin.com/uricefabic
[14:19:36 CET] <jkhsjdhjs> so i checked the session description by printing the sdp data: https://hastebin.com/leqimogiho
[14:19:36 CET] <jkhsjdhjs> as you can see in line 11 the camera tells ffmpeg that it streams with a framerate of 15, but ffmpeg ignores this information
[14:19:36 CET] <jkhsjdhjs> is there a way to make ffmpeg capture with 15fps instead of 25fps? i was told yesterday that there is a patch on the mailing list allowing me to use -r 15 in front of -i, but i couldn't find it. it would be cool if anyone could paste a link
[14:56:11 CET] <faLUCE> hello
[14:59:28 CET] <jkhsjdhjs> hey faLUCE
[14:59:40 CET] <jkhsjdhjs> i found the sdp data
[14:59:56 CET] <jkhsjdhjs> https://hastebin.com/leqimogiho
[15:01:01 CET] <faLUCE> jkhsjdhjs: yes, as said yesterday ffmpeg uses that framerate in a strict sense
[15:01:13 CET] <faLUCE> then you should use another receiver
[15:02:31 CET] <JEEB> double-check if the rtsp demuxer sets pts by anything else. I am not sure if rtsp has timestamps in the packets, but if there are such they should be utilized?
[15:02:53 CET] <faLUCE> JEEB: it's not rtsp which has ts, but rtp
[15:02:54 CET] <JEEB> (it will probably print the sdp fps as metadata, but timestamps of packets should be with the pts)
[15:03:02 CET] <JEEB> and rtp has no pts in packets?
[15:03:09 CET] <faLUCE> JEEB: yes, it has
[15:03:48 CET] <faLUCE> but, in each case, it's a matter of interpretation of the sdp metadata. Ffmpeg takes it more strictly than other players
[15:04:47 CET] <JEEB> http://up-cat.net/p/6d5a1e7c
[15:04:50 CET] <JEEB> this looks like relevant?
[15:05:15 CET] <JEEB> anyways, dunno - I've not used rtsp too much but it's worked for me in general
[15:05:24 CET] <JEEB> (in the few cases I've poked at it)
[15:06:05 CET] <faLUCE> JEEB: yes, but IMHO jkhsjdhjs would not be fixed. It's a matter of how you interpret that field
[15:06:21 CET] <JEEB> is the part I linked irrelevant?
[15:06:37 CET] <JEEB> found it by quickly checking `git grep -C2 "pts =" -- libavformat/rtp*`
[15:06:43 CET] <JEEB> and checking parts where not NOPTS was set
[15:06:59 CET] <JEEB> rtsp code seems to not touch packets, rtp code seems
[15:07:04 CET] <JEEB> (timestamp wise)
[15:07:16 CET] <faLUCE> JEEB: from what I see, the "delta" part is obtained by rtsp
[15:07:22 CET] <faLUCE> (maybe)
[15:07:28 CET] <JEEB> anyways $dayjob for me o/
[15:07:48 CET] <faLUCE> JEEB: rtsp is an additional layer for rtp
[15:08:46 CET] <JEEB> yea but it didn't seem to touch AVPackets' pts at all :)
[15:09:04 CET] <JEEB> git grep "pts =" -- libavformat/rtsp*
[15:09:07 CET] <JEEB> see the result of that
[15:09:22 CET] <JEEB> anyways, off
[15:09:41 CET] <jkhsjdhjs> cu
[15:09:52 CET] <faLUCE> JEEB: we'll discuss about that later :-)
[15:10:49 CET] <faLUCE> jkhsjdhjs: as said before, CHECK if with other players you can record properly the stream
[15:11:06 CET] <jkhsjdhjs> ok, will do
[15:11:18 CET] <faLUCE> jkhsjdhjs: you can also try live555, there are some examples for receiving and dump a rtsp stream
[15:11:35 CET] <faLUCE> that library is completely focues on rtsp
[15:11:39 CET] <faLUCE> focused
[15:12:00 CET] <jkhsjdhjs> ah, it is used by vlc
[15:12:16 CET] <jkhsjdhjs> i'll check recording with vlc then
[15:12:19 CET] <faLUCE> jkhsjdhjs: yes, and note that vlc DOESN'T use the laavf rtsp
[15:53:51 CET] <moef> Is it possible to force the processing of an input stream to follow the duration of the input video file?
[15:54:21 CET] <moef> For example: Process of video1.mp4 with the duration 30s will result in an output stream that lasts 30s?
[16:02:39 CET] <moef> YES I CAN
[16:02:44 CET] <moef> It's called native
[16:02:58 CET] <moef> It processes input at the native framerate
[16:02:59 CET] <moef> awesome
[21:43:52 CET] <orlcp440> Is there a way for one to concatenate/pipeline/chain/nest (whatever the term is) two protocols and/or two demuxers? For example, if I want to use the UDP demux/protocol and I want the output of it to be in input of the RTP demux/protocol module how do I go about doing that?
[21:47:00 CET] <orlcp440> I want to use the UDP module because it uses pthreads and a fifo buffer so I can set a bit rate etc but I want the UDP module's output which in this case the payload is nothing but RTP to go into the RTP demux for further processing
[22:45:31 CET] <faLUCE> are there parts of ffmpeg that are compatible with gpl v2 but not compatible with gpl v3 ?
[22:48:35 CET] <furq> no
[22:48:53 CET] <DHE> this is explicitly discussed in the LICENSING.md file in the source
[22:49:57 CET] <furq> afaik (l)gpl2 is always gpl3 compatible as long as it mentions "or later" in the license
[22:50:12 CET] <furq> which it does
[22:55:02 CET] <faLUCE> I see. nevcavriel answered too that, instead, there could be parts compatible with gpl v3 but not compatible with gpl v2
[22:55:13 CET] <furq> right, and there are
[22:55:30 CET] <furq> or there are libs you can link to that are
[22:55:49 CET] <faLUCE> so the best choice would be always to use the newer version of gpl/lgpl
[22:56:21 CET] <furq> if you're writing an application that might need a gpl3 component then yeah
[22:57:14 CET] <faLUCE> except for the case you specifically want something that is in v2+ license but is not in the v3+ version... but it could be very hard to figure what :-)
[22:57:38 CET] <furq> well there is no such case within ffmpeg
[23:11:26 CET] <faLUCE> but, is v3 license different than v3+  ?  From what I see, the license doc is "v3"  and the "any later part" must be specified, instead, on the source code
[23:12:27 CET] <furq> well there is no gplv4 so that's fine
[23:13:24 CET] <faLUCE> furq: :-)
[23:14:22 CET] <faLUCE> furq: but this doesn't answer to my question...
[23:14:48 CET] <faLUCE> anyway, I could not find any text of the "gpl v3+" license. Only "gpl v3"
[23:14:57 CET] <furq> v3+ and v3 are identical as long as v3 is the latest version
[23:15:08 CET] <furq> they both subsume any other compatible license
[23:15:40 CET] <furq> you only need to worry that gpl2/lgpl2 stuff specifies that it's 2+ or 2 or later
[23:15:55 CET] <furq> otherwise it's incompatible by some weird technicality afaik
[23:16:33 CET] <faLUCE> furq: yes, anyway, in the gnu channel they gave me an exact answer:   "[23:15] <AliciaC> GPLv3+ is not a license of its own, but shorthand for GPLv3 and invoking the option to let people upgrade to a newer version of the GPL"
[23:16:42 CET] <furq> with that said, if you're not actually depending on gplv3 code then you can just use v2 anyway
[23:16:52 CET] <furq> even if a user links it with an --enable-version3 ffmpeg
[23:17:09 CET] <faLUCE> I see
[23:17:28 CET] <furq> and there's only a couple of obscure libs that need v3
[23:19:42 CET] <Hello71> gplv3 is compatible with gplv2 by a special exception
[23:19:57 CET] <Hello71> iirc
[23:20:43 CET] <faLUCE> Hello71: from what alicia said, the compatibility is done by the option mentioned in the license
[23:22:25 CET] <Hello71> hm. must be confusing it with cc by-sa 4.0 then
[23:22:55 CET] <DHE> it's hardly even an exception, the license's shipped boilerplate version contains the "or later" clause, or strongly encourages you to use such wording.
[23:23:12 CET] <DHE> linux is considered slightly unusual in NOT taking the "or later" clause.
[23:23:16 CET] <faLUCE> DHE: yes, it's an option, not an execption
[00:00:00 CET] --- Tue Mar 26 2019