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

[burek]

[00:00:49 CEST] <cone-889> ffmpeg 03Paul B Mahol 07master:88d79dbd16ae: avformat/movenc: write pasp atom even if sar.num == sar.den
[00:01:58 CEST] <JEEB> durandal117: out of interest was this only to simplify the code? :)
[00:02:12 CEST] <JEEB> or was there some thing that didn't read tkhd but instead wanted pasp
[00:06:29 CEST] <durandal117> JEEB: see http://trac.ffmpeg.org/ticket/5852
[00:09:53 CEST] <JEEB> struggling to understand "Similar issue goes for sample aspect ratio and display aspect ratio in the video filter"
[00:10:33 CEST] <JEEB> I understand the colorspace stuff because in case of prores it seems like the bitstream doesn't have the info but instead the container has it
[00:10:57 CEST] <durandal117> JEEB: bitstream have that info, but wrong one was written
[00:11:27 CEST] <JEEB> I am confuzzled due to the word "filter" there
[00:11:39 CEST] <durandal117> JEEB: if one does not write pasp for 1/1, ffmpeg at least iterprets it as 0/1
[00:12:04 CEST] <JEEB> and that leads to filters thinking it's something else than 1/1?
[00:12:12 CEST] Action: JEEB scratches his head
[00:12:40 CEST] <durandal117> JEEB: nope, he uses setsar & setdar to properly mark its mov
[00:12:41 CEST] <JEEB> I mean, I understand the reasoning for its addition now (something needs it), but now I'm more confused about other things :D
[00:14:36 CEST] <JEEB> durandal117: I still don't get it :D what is the "filter" he mentions in the post regarding aspect ratio? what is going wrong and was it going wrong in FFmpeg or the Other App?
[00:14:45 CEST] <JEEB> maybe I just fail at reading, I don't know : D
[00:18:02 CEST] <durandal117> JEEB: setsar & setdar filters
[00:20:26 CEST] <durandal117> JEEB: ffpobe reports:
[00:20:28 CEST] <durandal117> sample_aspect_ratio=0:1
[00:20:30 CEST] <durandal117> display_aspect_ratio=0:1
[00:20:37 CEST] <durandal117> for prores created by ffmpeg
[00:20:58 CEST] <JEEB> how does that compare to other things where there is no sar/dar information?
[00:21:31 CEST] <durandal117> JEEB: what other things?
[00:21:42 CEST] <JEEB> anything?
[00:21:50 CEST] <JEEB> raw H.264 without sar f.ex.
[00:22:43 CEST] <durandal117> it its 0/1 or 1/0, pasp simply will not be written
[00:23:06 CEST] <JEEB> no, I thought we left the pasp side of things now?
[00:23:28 CEST] <JEEB> I am possibly even more confused
[00:24:28 CEST] <JEEB> (and as I noted already I am not fighting against the pasp addition. That ticket description and your short couple-word explanations just seriously only cause me to go "?!?")
[00:26:31 CEST] <JEEB> anyways, if the issue is that ffprobe reports 0:1 for sar/dar with prores without pasp and that then leads to some logic going wrong, that is a bug in FFmpeg somewhere else than in movenc.c. which is why I wanted to ask you if other formats without sar/dar information led to the same result?
[00:26:51 CEST] <JEEB> as in, are we globally broken or just broken when reading prores/mov-like?
[00:29:58 CEST] <durandal117> JEEB: Media Encoder have both pasp and tkhd atoms, and displays fine in all applications OP care, Quicktime 7 & 10 for example
[00:30:31 CEST] <durandal117> so it is not something else, but specifically our mov muxer
[00:32:32 CEST] <JEEB> is that it? just thinking if I may ask or not already. (you never know on IRC since  you can't see if the other side is still typing something)
[00:34:23 CEST] <JEEB> ok, it was four minutes without a reply so I will consider your explanation finished
[00:35:35 CEST] <JEEB> ok, so it was just a 3rd party application reading mov that we produce. what was the filter that was talked about then? why did you post ffprobe output and complain that it was set to "unset"? what did that crapola do without pasp? it assumed something else than tkhd width/height?
[00:36:52 CEST] <JEEB> mostly I'm interested in if we do anything wrong in case of "unset" (0/1) sar. and I want to know WTF that proprietary stuff would do in case of no pasp :D .
[00:37:24 CEST] <JEEB> if you have no answer to the second part, that's OK. you didn't test and for whatever reason the user wanted the info in pasp.
[00:37:51 CEST] <JEEB> the whole posting ffprobe part just confused me. end of transmission.
[00:40:36 CEST] <Compn> JEEB : i think i can answer your questions
[00:40:42 CEST] <Compn> what is your question exactly?
[00:41:18 CEST] <Compn> the ffmpeg muxer was not writing a default sar if the dar was 0/0 or 1/1
[00:41:39 CEST] <Compn> other tools write and expect a sar to be there
[00:41:58 CEST] <Compn> in apple world, we must copy what apple tools do. mp4 is apple and blah blah...
[00:42:00 CEST] <JEEB> yes, that I know. And as I've noted a few times I'm completely OK with that even though tkhd's width/height overrides it.
[00:42:40 CEST] <Compn> its probably just unset in quicktime from ffmpeg muxer, while all other software muxers have a value in there.
[00:43:05 CEST] <JEEB> durandal117's explanation of things just led to him posting the ffprobe 0/1 result of the encoded file as if there's an issue there. also the word "filter" was mentioned so I just... maybe my English is just that bad
[00:43:15 CEST] <JEEB> I'm struggling to understand if there was anything else
[00:44:17 CEST] <Compn> i've been reading so much broken english over the past 10 years that i figure it makes sense to someone :P
[00:44:47 CEST] <Compn> it would be nice if durandal117 tests with quicktime and fcp to see if this breaks anything but whatever :P
[00:44:50 CEST] <JEEB> I have, too. But this time my parser is just failing on me
[00:45:17 CEST] <JEEB> for me the main part was to check if 14496-12 or qtff.pdf say anything about pasp
[00:45:25 CEST] <Compn> of
[00:45:26 CEST] <JEEB> like, limiting its values or whatever
[00:45:39 CEST] <JEEB> if not, as I noted hours ago. everything's OK by me
[00:45:41 CEST] <Compn> er , probably totally not, this is probably a quicktime / fcp/ appleworld thing only
[00:46:00 CEST] <Compn> but it could be in there, i guess pasp might be standardized 
[00:46:05 CEST] <JEEB> it is
[00:46:21 CEST] <Compn> did you grep for pasp ? required or not ? for prores or not? for that particular isom or not? :P
[00:46:31 CEST] <JEEB> I have gone through the "what overrides what in 14496-12 aspect ratios"
[00:46:39 CEST] <JEEB> a couple years back
[00:46:43 CEST] <JEEB> qtff is a separate thing
[00:46:59 CEST] <JEEB> no, I just mean that I have the knowledge that pasp is standardized :P
[00:47:46 CEST] <JEEB> also at this point I will just try to forget what durandal tried to explain me and just focus on that *something* was fixed, although I have no idea how you can interpret a thing without a pasp other than tkhd's width/height or something.
[00:49:08 CEST] <durandal117> JEEB: so you are saying that ffmpeg should derive dar and sar from tkhd ?
[00:51:41 CEST] <JEEB> it doesn't already?
[00:52:32 CEST] <JEEB> I will have to re-check this but as far as I remember from my discussions with Paranoialmaniac it's basically (bit stream SAR)=>(pasp [overrides bit stream SAR])=>(tkhd width/height [uber alles])
[00:52:46 CEST] <JEEB> buut, this is a whole different discussion
[00:53:15 CEST] <JEEB> I was more asking if something in FFmpeg (esp. video filters) does something wrong if reading a source file where sar/dar are set to "unset" (0/1)
[00:56:40 CEST] <JEEB> durandal117: for example if you have a file that contains 1440x1080 video and a 4:3 sar you will get 1920x1080 in tkhd
[00:56:57 CEST] <JEEB> and the pasp/clap boxes are optional
[00:57:06 CEST] <JEEB> (a quote from ISO/IEC 14496-12: "These (pasp and clap boxes) are both optional; if present, they over-ride the declarations (if any) in structures specific to the video codec, which structures should be examined if these boxes are absent.")
[00:59:17 CEST] <Paranoialmaniac> i talked with the mp4 chairman several times, and he says pasp is only descriptive, "If they are two different sample entries in the same track, they should be scaled to the track dimensions, so the track has a uniform presentation size."
[01:00:22 CEST] <Paranoialmaniac> if you want to show another presentation size in the middle of the presentation of a movie (e.g. as if 640x480 -> 873x480), use another track with empty edits and layers in the track headers
[01:01:40 CEST] <rcombs> if you give QuickTime an MP4 with a track that lists its resolution as 1920x1080 containing a 2x2px H.264 stream, it shows the stream in the upper-left corner and gives you uninitialized buffers for the rest
[01:02:19 CEST] <rcombs> (in 10.12 it changes to give zeroed buffers instead; this used to be exploitable to read random chunks of freed mem)
[01:04:21 CEST] <JEEB> jesus christ
[01:04:29 CEST] <JEEB> tried copy pasting from the iso 14496-12
[01:04:42 CEST] <JEEB> and even in a "proper" PDF reader
[01:04:50 CEST] <JEEB> result: http://up-cat.net/p/6363b545
[01:05:13 CEST] <JEEB> I tried to copypasta the matrix/(width,height) values' explanations
[01:05:24 CEST] <rcombs> welcome to PDFs
[01:05:26 CEST] <rcombs> (fuck PDFs)
[01:05:57 CEST] <iive> that's a new one... anyway, there is a mail client that could fix that :D
[01:06:53 CEST] <JEEB> rcombs: but yeah - this definition makes QT's behavior incorrect then. "all images are *scaled* to this size, before the overall transformation of the track represented by the matrix"
[01:07:12 CEST] <JEEB> which, of course, isn't anything new :)
[01:07:29 CEST] <rcombs> see http://rcombs.me/steal.html for an example
[01:07:32 CEST] <JEEB> everyone gets ISOBMFF wrong, even better with stuff that qtff.pdf defines otherwise
[01:07:58 CEST] <rcombs> pre-10.12 you can see random bitmaps floating around
[01:08:12 CEST] <JEEB> :D
[01:08:18 CEST] <rcombs> I often noticed tab titles and Dock icons in there
[01:08:54 CEST] <JEEB> also this reminds me of mov and container  cropping.
[01:09:03 CEST] <rcombs> lol container cropping
[01:09:10 CEST] <Paranoialmaniac> clean aperture
[01:09:40 CEST] <JEEB> http://www.cccp-project.net/beta/test_files/h263_adpcm_lolborders.mov
[01:09:42 CEST] <JEEB> I think this was it
[01:12:00 CEST] <rcombs> seems everyone agrees it's lol
[01:12:25 CEST] <JEEB> yup
[01:12:27 CEST] <rcombs> though one of these days I need to write a bsf to modify H.264 SPS (or is it PPS?) crop params
[01:12:36 CEST] <JEEB> there's one already on doom9
[01:12:36 CEST] <Paranoialmaniac> mov defines the clef atom which honors the clap atoms and indicates images are scaled into this size. the spec of mov twists and turns. i heard once quicktime honors the pasp atom
[01:12:45 CEST] <rcombs> oh, is there?
[01:13:15 CEST] <rcombs> for lavc? Or something standalone? (still useful as a starting point)
[01:13:35 CEST] <JEEB> it was a patch for ffmpeg
[01:13:40 CEST] <JEEB> I think it was a bsf
[01:14:22 CEST] <rcombs> neat
[01:15:42 CEST] <JEEB> http://forum.doom9.org/showthread.php?t=152419
[01:15:44 CEST] <JEEB> finally found it
[01:19:59 CEST] <rcombs> nice patches
[01:20:02 CEST] <rcombs> piles of unrelated changes
[01:20:08 CEST] <JEEB> yup
[01:22:33 CEST] <rcombs> will probably need to be mostly rewritten to work with the new BSF API, but thanks, looks like a good starting point
[01:22:46 CEST] <rcombs> also, it has some other features that could be useful
[01:22:47 CEST] <JEEB> yeah, kind of expected that :)
[01:22:59 CEST] <JEEB> but yeah, that was a set of random features that could be useful
[01:23:03 CEST] <JEEB> but never posted in a proper way
[01:23:07 CEST] <rcombs> if I end up with something useful I'll send a patch
[01:24:40 CEST] <rcombs> remind me, does H.264 provide a top/left crop mechanism, or just bottom/right?
[01:25:00 CEST] <rcombs> for some reason I thought it could do both, but I suppose it makes sense that it wouldn't
[01:26:11 CEST] <JEEB> I only remember the one that is generally used
[01:27:20 CEST] <rcombs> yeah it can do both
[01:27:33 CEST] <rcombs> according to my extremely scientific quick glance at libavcodec/h264_parser.c
[01:27:38 CEST] <JEEB> :D
[01:27:41 CEST] <JEEB> then that's probably the case
[01:27:47 CEST] <rcombs> this filter just doesn't handle both
[01:27:50 CEST] <rcombs> probably not hard to change
[01:28:21 CEST] <rcombs> I initially wanted something like this to give people who want to crop letterboxes without reencoding (since lolcontainercrop)
[01:28:32 CEST] <rcombs> so with some tweaking it should be able to do that
[01:29:31 CEST] <rcombs> but some of the other features (fix color range, remove duplicated headers) are also interesting
[01:30:21 CEST] <rcombs> I've seen some devices trip over themselves decoding some BD remuxes that spew SPS/PPS a lot, though I don't know if they're actually updating anything (in which case this wouldn't be so easy)
[01:33:11 CEST] <JEEB> meanwhile I need to find out if we're just not parsing some info from MXF or if some of my samples are just borked
[01:33:32 CEST] <JEEB> aspect ratio and non-active picture area mostly
[01:33:49 CEST] <rcombs> no film projectors/playback servers laying around to test with?
[01:33:50 CEST] <JEEB> checked with BBC's dumper that there's an aspect ratio flag at least somewhere
[01:34:13 CEST] <JEEB> rcombs: the provider of course said that "shit works on our systems"
[01:38:23 CEST] <JEEB> also this reminds me that I should see if the actual colorspace is mentioned anywhere in netflix's HDR sample :P
[01:38:42 CEST] <JEEB> it's JP2K in MXF and with a quick look I can't see anything else than "this is yuv422p10"
[03:40:39 CEST] <cone-313> ffmpeg 03Philip Langdale 07master:f59e10b0f486: cuvid: Add MIT licenced nvcuid headers from Video SDK 7.0
[03:40:39 CEST] <cone-313> ffmpeg 03Philip Langdale 07master:843aff3cf7ad: cuvid: Use bundled headers
[03:40:39 CEST] <cone-313> ffmpeg 03Philip Langdale 07master:289a6bb8b118: cuvid: Pass bit depth information to decoder
[04:11:35 CEST] <cone-313> ffmpeg 03Michael Niedermayer 07master:bc26fe89275c: avcodec/h264: Use ptrdiff_t for (bi)weight functions
[04:56:38 CEST] <cone-313> ffmpeg 03James Almer 07master:7d17d31db432: fate: update fate-source reference file
[05:25:06 CEST] <jamrial_> ubitux: check ffmpeg-new-bsf branch in my github repo
[05:25:27 CEST] <jamrial_> it's ugly, but not uglier than pre bsf port
[05:25:36 CEST] <jamrial_> and it seems to work
[05:40:02 CEST] <michaelni> jamrial_, the branch breaks: ./ffmpeg -i matrixbench_mpeg2.mpg -vbsf noise=1 noise.avi
[05:40:50 CEST] Action: michaelni falls asleep, will test more tomorrow 
[05:48:45 CEST] <jamrial_> michaelni: is filter=value even valid? i thought it was filter=opt1=value1:opt2=value2
[05:53:19 CEST] <jamrial_> that command is not rejected in git head (noise filter ignores any args), but i don't think it's valid
[05:55:18 CEST] <jamrial_> if it is and should be supported, then i'll ask if someone else can adapt the parsing code because i suck at string handling
[06:01:35 CEST] <jamrial_> michaelni: actually, noise filter doesn't ignore args. but its only option is amount, and it indeed works as noise=amount=0
[06:22:48 CEST] <jamrial_> i see, av_bitstream_filter_filter() converted filter=value into filter=first_opt_in_filter=value, ugh
[06:50:44 CEST] <jamrial_> michaelni: pushed a fix that restores that functionality
[06:51:56 CEST] <jamrial_> replaced two blocks of copy paste with one block of copy paste, so not bad
[06:52:20 CEST] <jamrial_> thanks for testing
[08:21:01 CEST] <Chloe> michaelni: are you sure you have the 32bit SDL2 installed?
[09:14:37 CEST] <Chloe> michaelni: it uses pkg-config which can't discern between 32bit and 64bit afaict
[09:24:25 CEST] <wm4> does anyone have plans to add vaapi profile mappings?
[09:24:47 CEST] <j-b> 'morning
[09:38:18 CEST] <rcombs> wm4: profile mappings?
[09:42:01 CEST] <wm4> see vaapi_profile_map
[09:42:18 CEST] <wm4> vdpau can already create the decoder for the user
[09:49:55 CEST] <jkqxz> wm4:  You mean like this <https://git.libav.org/?p=libav.git;a=commit;h=123ccd07c55ccf075cc5daf5581237fbccb86bdb>, and following patches?
[10:00:24 CEST] <wm4> jkqxz: where's the API for that?
[10:01:29 CEST] <jkqxz> What API for it?
[10:01:53 CEST] <wm4> vaapi context creation
[10:02:21 CEST] <nevcairiel> through hwcontext api i assume
[10:03:31 CEST] <jkqxz> There isn't any, struct vaapi_context is killed off.  You supply the hw_frames_ctx containing a device and lavc does all of that stuff.
[10:03:50 CEST] <wm4> nevcairiel: the hwcontext API is centered around managing video frames, not decoders
[10:04:24 CEST] <wm4> jkqxz: ok sounds good... I wonder where all this discussion about lavc not being able to do this for all API users went
[10:04:35 CEST] <wm4> like I'm certain nevcairiel would NACK such an API for dxva
[10:05:25 CEST] <nevcairiel> hwcontext offers device creation as well, not sure what more you need
[10:05:30 CEST] <nevcairiel> it manages both devices and frame pools
[10:06:00 CEST] <wm4> jkqxz: how does it control pixel format selection?
[10:08:00 CEST] <wm4> (or more importantly, determining the pixel format on the libavcodec side)
[10:29:02 CEST] <jkqxz> That is an annoying hole in the abstraction - the user needs to know the answer, but currently it is always 10bit ? P010 : NV12.
[10:31:43 CEST] <jkqxz> So you get <https://git.libav.org/?p=libav.git;a=blob;f=avconv_vaapi.c#l183> and <https://git.libav.org/?p=libav.git;a=blob;f=avconv_dxva2.c#l366> (vdpau ducks the problem by the surface format only specifying the chroma subsampling, but that isn't so good if you need to be able to access the surface directly).
[10:41:48 CEST] <wm4> jkqxz: well I was wondering what it sets AVHWFramesContext.sw_format to
[10:42:03 CEST] <wm4> because libva isn't so sure about itself what the format is
[10:42:09 CEST] <wm4> it can change at runtime, for the same surface instance
[10:42:34 CEST] <wm4> though that might be a bug, and even one that has been fixed: https://bugs.freedesktop.org/show_bug.cgi?id=79848
[10:43:04 CEST] <wm4> considering the 10 bit mess, I'm not sure if this is solved yet, though
[10:43:37 CEST] <wm4> also why does the application have to set this with lavc? makes no sense to me
[10:44:18 CEST] <wm4> (I mean the thing you pointed out: https://git.libav.org/?p=libav.git;a=blob;f=avconv_vaapi.c#l183)
[10:44:58 CEST] <j-b> 1m
[10:45:51 CEST] <wm4> indeed... I mean, what
[10:49:36 CEST] <jkqxz> It's a consequence of the user being responsible for making the hwframe context.  If it goes one step further to "here's a device, make the frames automatically" then that goes away (and people who want to render directly to whatever other thing can continue to use the current form).
[10:54:04 CEST] <wm4> shouldn't there be a function to create a hw frames context that's sufficient for a decode configuration? that seems to be the right way around
[10:59:30 CEST] <jkqxz> Oh noes, sounds like new API in lavc!
[11:01:24 CEST] <jkqxz> But yeah, something like that.  Patches welcome.
[11:03:09 CEST] <wm4> I'm not quite sure where it'd even be used
[11:03:20 CEST] <wm4> seems like a chicken and egg problem
[11:09:01 CEST] <jkqxz> The current form is motivated by it being set in the get_format() callback, under the control of the user.
[11:12:07 CEST] <jkqxz> If anything happens automatically there then there it becomes a bit magical, because the user doesn't know in advance what format they are going to receive at all (even whether it is a hardware surface or not).
[11:13:45 CEST] <wm4> oh right... so such an API could actually work
[11:14:21 CEST] <jkqxz> Hmm.  enum AVPixelFormat avcodec_get_sw_format(AVCodecContext*, AVHWDeviceContext*) which is only callable in the get_format() callback might work, yeah.
[11:19:54 CEST] <BtbN> "<wm4> shouldn't there be a function to create a hw frames context that's sufficient for a decode configuration?" Doesn't such an API already exist?
[11:20:00 CEST] <BtbN> Or am I misremembering something?
[11:20:14 CEST] <BtbN> I think there was a hw context creation API merged from libav
[11:48:35 CEST] <cone-670> ffmpeg 03Timo Rothenpieler 07master:30d3e36a4602: avcodec: add new AVOID_PROBING capability
[11:48:36 CEST] <cone-670> ffmpeg 03Timo Rothenpieler 07master:9777ba33f52c: avformat/utils: avoid using marked decoders for probing
[11:48:37 CEST] <cone-670> ffmpeg 03Timo Rothenpieler 07master:dcea61897647: avcodec/cuvid: mark as avoid for probing
[11:48:38 CEST] <cone-670> ffmpeg 03Timo Rothenpieler 07master:7904859fd821: compat/cuda: convert to unix line endings
[11:50:42 CEST] <BtbN> now to see what other codecs might need that flag
[12:23:53 CEST] <michaelni> "<Chloe> michaelni: are you sure you have the 32bit SDL2 installed?", No, theres no 32bit SDL2 installed, i have few 32bit libs installed but only for SDL2 configure detects its avaialable and then breaks build
[13:34:54 CEST] <cone-670> ffmpeg 03Michael Niedermayer 07master:a5fafabc8411: tests/fate: Add fate-ffmpeg-bsf-remove-* tests
[14:28:06 CEST] <BBB> nevcairiel: the stride is still an int, are we waiting for the libav merge to change that to ptrdiff_t?
[14:29:54 CEST] <nevcairiel> BBB: i think michaelni applied a patch to change that
[14:30:04 CEST] <BBB> in your patch its still int
[14:30:10 CEST] <BBB> also in my tree its still itn
[14:30:14 CEST] <BBB> but I dont update very day
[14:30:55 CEST] <nevcairiel> its ptrdiff_t now, but it appears michaelni forgot to update the comment with the function signature at the top of the file
[14:31:08 CEST] <BBB> thats ok
[14:31:18 CEST] <BBB> loopfilter stride is still int
[14:31:32 CEST] <nevcairiel> plenty strides are still int all  over the place, yes
[14:31:36 CEST] <BBB> but anyway ignore me, your patch is obviously ok
[14:31:38 CEST] <BBB> nice fix also
[14:32:12 CEST] <nevcairiel> i didnt really start debugging yet, but i saw that those regs are used inconsistently .. without d there, and then with d later in the macro
[14:32:23 CEST] <nevcairiel> made sense that this might cause it
[14:32:59 CEST] <BBB> right, on win64 4-5 are loaded from memory
[14:33:11 CEST] <BBB> so the upper 32 bit are random noise
[14:36:30 CEST] <mifritscher> hi
[14:36:53 CEST] <mifritscher> I try to repair the ffserver regression tests
[14:38:04 CEST] <mifritscher> The problem is with the command wget --user-agent=NSPlayer -q --proxy=off -O - http://localhost:9999/test_h.asf?date=19700101T000000Z  | dd bs=1 count=20000 > ff-test_h.asf , it downloads 20 kB. dd exits then, but wget keeps happily downloading. Observerd on cygwin
[14:39:02 CEST] <BtbN> stuff on cygwin behaves wildly diffrent. I don't think it's a supported fate platform.
[14:39:42 CEST] <mifritscher> BtbN: fate runs without problems ;)
[14:40:14 CEST] <BtbN> what test are you running then?
[14:40:16 CEST] <mifritscher> ffserver regressions tests are outside fate (at least still ;-) )
[14:40:29 CEST] <mifritscher> make ffservertest
[14:40:50 CEST] <BtbN> ffserver is about to be deprecated. If you want to keep it, better get it up to date soon.
[14:41:09 CEST] <mifritscher> BtbN: I'm the Michael Fritscher on the mailing list ;-)
[14:41:22 CEST] <ubitux> BtbN: http://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/199686.html
[14:42:06 CEST] <nevcairiel> having seen (parts of the) ffserver source code, somehow it would seem easier to just start over
[14:42:15 CEST] <mifritscher> yes, and I'm trying to fix the first point :-)
[14:42:16 CEST] <nevcairiel> its so reliant on internals
[14:42:55 CEST] <mifritscher> nevcairiel: my first impression is that the main problem is the integrated rtsp server
[14:43:06 CEST] <BtbN> I honstely think ffserver might have more luck as an external project.
[14:43:25 CEST] <nevcairiel> the entire "ffm" format its based on can practically not exist anymore
[14:43:30 CEST] <mifritscher> for this I've the main question: do we want to have a rtsp-Server in libav*, or external?
[14:43:56 CEST] <mifritscher> ok, what are the main problems regarding ffm?
[14:44:51 CEST] <nevcairiel> its basically a serialized avcodeccontext on a muxer/demuxer level, but those dont have access to an avcodeccontext anymore
[14:45:28 CEST] <atomnuker> it'll get removed with ffserver I think
[14:46:10 CEST] <nevcairiel> and I think keeping it in its own repository is definitely best, it can still be considered part of the "FFmpeg project" if thats wanted, just maybe easier to start it off cleanly separated
[14:46:19 CEST] <mifritscher> is there any documentation about ffm?
[14:46:54 CEST] <mifritscher> is this used only for the cache or also as the transport format between ffmpeg and ffserver?
[14:48:11 CEST] <mifritscher> nevcairiel: Then I would move ALL ff* programs to an oen repo to have a strict destinction between the library and the programs/tools
[14:49:15 CEST] <nevcairiel> thats definitely a goal some people like to see in the future, but its easier to just start a "new" (or at least hugely refactored and rewritten) program over there, instead of forcing a move of everything else right now
[14:49:16 CEST] <mifritscher> ffmpeg uses e.g. libavformat/os_support.h, which is marked internal
[14:52:51 CEST] <mifritscher> what can you recommend as a replacement for ffm? If I understand it correctly, it is "yust" used as a buffer for shifted play
[14:55:19 CEST] <mifritscher> and as an encapsulation format between ffmpeg anf ffserver
[15:04:08 CEST] <Compn> mifritscher : unfortunately most devs here want to kill ffserver currently
[15:04:35 CEST] <Compn> so there is no plan to develop a interop format between ffserver / ffmpeg
[15:05:22 CEST] <Compn> at least right now
[15:05:27 CEST] <Compn> i could be wrong :)
[15:06:46 CEST] <mifritscher> Compn: perhaps an other format could be used. What are the requirements for such a format? If I'm right, ffmpeg retrieves the requested format with its options from ffserver, sets the encoder accordently and stream the data to ffserver
[15:07:26 CEST] <mifritscher> I want to rescue ffserver ;-) And the first things I would like to do is to setup the testing environment and get an overview what needs to be done
[15:07:55 CEST] <Compn> oh mifritscher , save ffserver :))))
[15:08:16 CEST] <Compn> probably send a mail to ffmpeg-devel with intent to maintain ffserver 
[15:08:24 CEST] <Compn> then check trac for ffserver bugs
[15:08:42 CEST] <Compn> as for the format supported, you'd maybe want to ask users what they want, what formats are common, etc
[15:08:51 CEST] <Compn> making a new format could be difficult with various network formats...
[15:08:57 CEST] <Compn> im not sure at all :)
[15:09:53 CEST] <mifritscher> the thing is that ffm seems to be used to negotiate the needed formats between ffmpeg and ffserver
[15:10:18 CEST] <atomnuker> mifritscher: why would you want a link between the 2?
[15:11:01 CEST] <mifritscher> ffmpeg says "Hello, here am I, I want to feed /feed1.ffm". ffserver says "ok, I need the formats mjpeg with 640x480 with 20 fps and h264 with 30 fps". ffmpeg says "here we go, I'm streaming"
[15:11:28 CEST] <mifritscher> atomnuker: Its the way it works atm (if I unterstand it correctly)
[15:11:54 CEST] <atomnuker> ok, as long as it lives outside the libraries and in the 2 programs it's going to work fine
[15:14:02 CEST] <mifritscher> I've yet to find the logic regarding parsing the needed codecs etc - or how deep there are hidden in the library
[15:23:15 CEST] <michaelni> "BtbN> stuff on cygwin behaves wildly diffrent. I don't think it's a supported fate platform." fate worked fine on cygwin in the past i think
[15:24:47 CEST] <michaelni> mifritscher, nut might be an option as ffm replacement
[15:25:21 CEST] <michaelni> we can extend nut as its "our" format if theres some need to extend it
[15:26:41 CEST] <michaelni> parameters can easy be put in nut as key value metadata by the muxing app and read by some demuxing app
[15:27:15 CEST] <mifritscher> michaelni: yes, it looks promising (I'm reading the spec)
[15:28:04 CEST] <michaelni> ffm though is used by ffserver & ffmpeg as some kind of ring buffer between ffmpeg and ffserver, this functionality may be harder to do outside ffm, didnt think much about it
[15:28:29 CEST] <michaelni> s/between ffmpeg and ffserver//
[15:30:39 CEST] <mifritscher> if nut has some kind of packeting it could be doable I think
[15:33:13 CEST] <mifritscher> the most critical thing is the codec negotiate thing between ffmpeg and ffserver - because this is the thing which is needed to leave in ffmpeg. Honestly I'm still searching where is this logic - in libavformat/ffm* I didn't found anything, and in ffmpeg.c I didn't found anything on the first glance either
[15:33:18 CEST] <michaelni> the easy solution for the ring buffer is to have the muxing app open a new file when its hits th max size and delete the old eventually
[15:35:30 CEST] <michaelni> see override_ffserver (which IIRC disables the use of ffserver supplied options (the code checking for that is the copy code) and read_ffserver_streams()
[15:37:48 CEST] <mifritscher> ah, in ffmpeg_opt.c
[15:37:55 CEST] <michaelni> also search for "recommended_encoder_configuration"
[15:37:58 CEST] <mifritscher> thanks :-)
[15:41:30 CEST] <mifritscher> ok, so it seems that the negotiation itself is not in the library, ffmpeg just reuses the ffm format for this. Which is good.
[15:46:44 CEST] <wbs> mifritscher: keep in mind that the way that ffm does it currently iirc relies on the actual binary representation of avcodeccontext, so if ffserver and ffmpeg aren't of the exact same version, things go south pretty soon
[15:46:53 CEST] <wbs> I might be mistaken, but this was what I remember of it
[15:47:29 CEST] <nevcairiel> hence why I said that ffm as it is right now can never survive the future
[15:48:38 CEST] <wbs> the whole concept of the server telling the client what options to use for encoding is pretty brittle as well. it doesn't only say "I need h264", but includes all the options, and the client might have a different encoder with different options, etc
[15:48:46 CEST] <wbs> the client == ffmpeg in this case
[15:49:59 CEST] <mifritscher> yes @options handling with all of the options
[15:50:19 CEST] <mifritscher> honestly I like this way ( to configure all things on the ffserver side)
[15:50:28 CEST] <jamrial> michaelni: http://pastebin.com/CifZsXZY fixes the remove_extradata failures
[15:51:02 CEST] <jamrial> or rather, it fixes it for the valid values. "a" and "r" are rejected since they are invalid values for the "freq" option
[15:51:14 CEST] <jamrial> those two tests should be removed
[15:51:36 CEST] <nevcairiel> heh it failed because the bsf has broken options?
[15:51:37 CEST] <nevcairiel> classic
[15:52:00 CEST] <jamrial> no, the tests he added had two wrong values on purpose i guess :p
[15:52:16 CEST] <jamrial> ah wait, that option had the wrong range of values, yeah
[15:52:22 CEST] <jamrial> that was a bug in the bsf, yes
[15:52:35 CEST] <ubitux> ah, i was trying to figure out what these values meant
[15:52:37 CEST] <nevcairiel> and rejecting invalid params seems like a good thing, so yeah
[15:52:38 CEST] <ubitux> :D
[15:53:04 CEST] <jamrial> yeah, i don't know why it silently ignored wrong values until this port
[15:53:14 CEST] <jamrial> but it's not good behavior
[15:53:27 CEST] <jamrial> ubitux: so yeah, hopefully that does it
[15:54:15 CEST] <jamrial> so in the end, aac_adtstoasc changing extradata in a filter() call is wrong behavior
[15:54:36 CEST] <jamrial> the bsf api explicitly says that extradata can only be modified during init()
[15:54:37 CEST] <nevcairiel> its not ideal behavior, unfortunately with many such formats there is no better time to do it
[15:54:57 CEST] <ubitux> jamrial: how do we move from this? are you commiting on top of my branch?
[15:54:59 CEST] <jamrial> after that, filter can create new packet side data to notify the muxer to handle stuff
[15:55:00 CEST] <nevcairiel> because you cant extract in-band extradata before actually getting it in-band
[15:55:13 CEST] <jamrial> ubitux: yeah, check my repo, i committed on top of your stuff
[15:55:23 CEST] <jamrial> you can squash it
[15:55:33 CEST] <nevcairiel> in fact, the entire auto-bsf scheme was specifically build to allow a bsf to filter the first frame before initing the muxer
[15:56:02 CEST] <jamrial> yeah, but since apparently mov can't use autobsf...
[15:56:16 CEST] <nevcairiel> it can, would just need to finish rcombs's patch set
[15:56:25 CEST] <jamrial> the above pastebin fix for remove_extradata should go separately
[15:56:54 CEST] <nevcairiel> of course autobsf has it easy because at that point its all codecpar, no context in between that messes everything up
[15:56:55 CEST] <nevcairiel> :D
[15:56:59 CEST] <jamrial> the removal of the two wrong value tests for remove_extradata can be squashed with the port commit, much like the updated ref file for mpeg4-bframes test
[15:58:05 CEST] <nevcairiel> in fact rcombs re-posted his mov autobsf patchset two weeks ago, should find it and ping it : )(
[15:58:45 CEST] <mifritscher> ok, I found in ffm_write_header_codec_ctx the line av_opt_serialize(ctx), ctx being an AVCodecContext - which is not good. (the stream data pakets doesn't to that, so it seems only to be the header). 
[16:01:14 CEST] <mifritscher> (but at least the serialization seems to be ascii and not binary)
[16:01:41 CEST] <michaelni> yes, it was binary a really long time ago, IIRC lukasz fixed that
[16:04:09 CEST] <mifritscher> so, the steps are: fixing the ffserver regression test (the first problem I stumbled over is more a cygwin problem I guess ;) ), putting of the rtsp server code, replace ffm with nut (both for codec negotation and actual streaming)
[16:04:30 CEST] <mifritscher> are there any other technical steps to do? ;-)
[16:07:02 CEST] <ubitux> jamrial: nice
[16:07:14 CEST] <ubitux> so we can mix shorthands with keys now?
[16:07:17 CEST] <ubitux> just like filters?
[16:07:26 CEST] <ubitux> (the lavfi ones)
[16:08:06 CEST] <mifritscher> regarding the rtsp server code: is there a possibility to put this in a libav* library? Or is it better to make a "lib_rtsp_server" sort of thing? If the later one, is it allowed that this is using libav* internals (utilities and official rtsp packet headers, no "real" internals), or should I copy them as well?
[16:08:38 CEST] <ubitux> there is a listen mode in rtsp demuxer
[16:08:44 CEST] <ubitux> added "recently" for some reason
[16:09:35 CEST] <michaelni> jamrial, 'a' existed: git show release/2.8:libavcodec/remove_extradata_bsf.c
[16:09:53 CEST] <michaelni> IIRC it broke due to API changes and no easy fix
[16:10:34 CEST] <mifritscher> ubitux: if I'm right I would need a rtsp muxer (and one with can cope with multiple connections), wouldn't I?
[16:11:15 CEST] <mifritscher> *which
[16:11:31 CEST] <ubitux> no idea, but i think it's documented if you want to try it out
[16:14:43 CEST] <mifritscher> is the API for muxer/demuxer designed for coping with more than one concurrent connection in general?
[16:15:25 CEST] <ubitux> that's probably just a hack to justify the drop of ffserver ;)
[16:15:37 CEST] <mifritscher> the docu (https://ffmpeg.org/ffmpeg-protocols.html#rtsp) says "Act as a server, listening for an incoming connection." - which sounds for only one connections
[16:15:41 CEST] <mifritscher> could be :-/
[16:16:19 CEST] <mifritscher> Its really sad that I got no warning of problems with fserver before :-(
[16:18:29 CEST] <wm4> there are plenty of ffmpeg devs who complained about ffserver before for years
[16:18:37 CEST] <wm4> and it was removed years ago in Libav
[16:19:55 CEST] <mifritscher> yes, but I didn't payed attention at the libav-fork, because my impression was that this fork is almost dying anyway...
[16:21:27 CEST] <mifritscher> (it was at the time at which debian switched to ffmpeg again)
[16:22:23 CEST] <Mavrik> Which doesn't really change the fact that ffserver is obsolete, unmaintained and a terrible idea for a streaming server :/
[16:25:20 CEST] Action: michaelni likes ffserver or rather the idea of a maintained and upto date API ad feature wise ffserver
[16:25:29 CEST] <michaelni> aNd
[16:26:41 CEST] <mifritscher> Mavrik: obsolete: in which way? unmaintained: I want to change this :-) terrible idea: Why?
[16:27:04 CEST] <Mavrik> obsolete in a way that it wasn't updated and expanded to support modern streaming tech reliably
[16:27:25 CEST] <Mavrik> terrible idea because it's obsolete and unmaintained and things like wowza, nginx-rtmp and similar do a better job :)
[16:29:03 CEST] <mifritscher> which forms a circle^^
[16:30:06 CEST] <mifritscher> wowza is not an open source solution
[16:30:58 CEST] <mifritscher> and can't do MJPEG
[16:31:14 CEST] <Mavrik> MJPEG really shouldn't be used in 2016 :P
[16:31:47 CEST] <ubitux> some webcam / cameras outputs this
[16:31:50 CEST] <mifritscher> Mavrik: even 2016, MJPEG is the only real stable thing for live streaming in browsers with a delay of under one second...
[16:32:00 CEST] <ubitux> it might makes sense to just forward it
[16:33:45 CEST] <Mavrik> Yeah, it's low CPU requirements make it good for webcams
[16:34:19 CEST] <mifritscher> we don't want to use browser plugins like flash, and the html5 <video> tag isn't usefull for real live streaming (TV, for which a delay up to 30 seconds is ok is another story)
[16:34:42 CEST] <ubitux> mifritscher: i think most devs here are afraid that you won't be able to make ffserver in shape before its due death
[16:35:07 CEST] <ubitux> which will end up in delaying it because it's flagged as "maintained" while it's a dead end project
[16:35:16 CEST] <ubitux> that's why you get that much negative feedback
[16:35:19 CEST] <mifritscher> ubitux: yes, this is my biggest concern as well
[16:35:47 CEST] <Mavrik> What ubitux said.
[16:36:47 CEST] <wm4> everyone would welcome a streaming solution that does not have ffserver's disadvantages wrt. code maintainability
[16:36:52 CEST] <nevcairiel> the deprecationg cycle of that is about a year away, but yeah, delaying removal of that just for ffserver is not something that should happen
[16:37:06 CEST] <ubitux> TBH, i really like the concept of having such tool (the problematic of streaming stuff myself came several times)
[16:37:28 CEST] <mifritscher> some does technical concerns of maintaining and changing critical components (which I want to change), some people seem to "hate" ffserver (which I cannot change)
[16:37:41 CEST] <Mavrik> It would be nice, even though isn't there a decently popular OSS streaming server out there?
[16:38:12 CEST] <mifritscher> ok, when will ffmpeg-critical stuff (I think ffm is the most problematic thing) be removed?
[16:38:14 CEST] <Mavrik> That the guys organizing Berlin's CCC use?
[16:38:17 CEST] <ubitux> mifritscher: they hate the idea that in one year we are going to say "we have to keep ffserver longer; it still depends on internals but it's much better!"
[16:38:20 CEST] <wm4> mifritscher: what they hate is the insistence of ffserver to mess (or to be part of) libav* internals
[16:38:26 CEST] <ubitux> and have an endless debate about keeping it or not
[16:38:54 CEST] <ubitux> maybe we should clarify the deadline somehow
[16:38:57 CEST] <mifritscher> thats why I want to get an overview of all the internal stuff.
[16:39:01 CEST] <mifritscher> yes @deadline
[16:39:19 CEST] <nevcairiel> the big problem there is that this debate wouldnt be just about ffserver, but big parts of  deprecated avformat functionality (which ffm relies on), so there is that =p
[16:39:22 CEST] <mifritscher> I'm more than willing to make a precise time schedule of my ffserver work
[16:39:28 CEST] <ubitux> maybe something along the line "if it technically can't work outside of ffmpeg repository, then we drop it on xx/xx/xxxx"
[16:39:56 CEST] <ubitux> (that doesn't mean it has to be out of the repository in the end, just that it should be clean of ANY internal use)
[16:40:00 CEST] <jamrial> ffm is going to be removed once avstream.codec is gone, right?
[16:40:21 CEST] <Chloe> michaelni; this is a limitation of sdl, nothing we can do about it iirc. If SDL1 didn't install 32bit libs then it would error out just the same. afaik
[16:41:06 CEST] <michaelni> jamrial, ok if ii commit your remove_extra AVOption fix patch (and also fix the e/a fate test ?) or should i post a patch ?
[16:41:08 CEST] <ubitux> mifritscher: ffserver really has a fundamental design issue wrt how it messes with internals; you will probably have to rethink that (and breaks things in the process)
[16:41:33 CEST] <jamrial> michaelni: just commit it, no need for a patch
[16:41:40 CEST] <michaelni> ok
[16:41:55 CEST] <jamrial> but the a/e tests are going to be removed anyway once we commit the bsf port code
[16:41:59 CEST] <mifritscher> ubitux: with the design issue you mean the area ffm (and a bit of rtsp) - or are there any other big obstacles?
[16:42:08 CEST] <jamrial> sorry, a/r
[16:42:13 CEST] <michaelni> Chloe, linking should be checked in configure before setting it as available
[16:42:19 CEST] <cone-670> ffmpeg 03Hendrik Leppkes 07master:5ae0ad001a65: x86/h264_weight: use appropriate register size for weight parameters
[16:43:09 CEST] <ubitux> mifritscher: afaik that's the main one, but it looks kind of fundamental
[16:43:15 CEST] <Chloe> michaelni: oh right, ok
[16:43:33 CEST] <ubitux> mifritscher: it really has a lot of implication afaik
[16:45:08 CEST] <Chloe> michaelni: something like check_lib SDL.h -lsdl2 $sdl2_cflags && enable sdl2 I geuss?
[16:45:10 CEST] <mifritscher> ubitux: I'm a optimist :-) And if I ended up rewriting much of the code - thats ok for me ;-)
[16:45:18 CEST] <Chloe> oh
[16:45:21 CEST] <Chloe> or just sdl2_libs
[16:46:01 CEST] <ubitux> mifritscher: when it's all about code it's fine, but when you have to deal with api and (retro)compatibility it can becomes a nightmare real quick
[16:46:19 CEST] <Chloe> michaelni: could you check if this fixes it? https://0x0.st/QZ3.patch
[16:46:32 CEST] <ubitux> but yeah, maybe try to move ffm stuff out of lavf for now, into a ffserver_cache.c or whatever
[16:46:47 CEST] <ubitux> if that's possible?
[16:47:10 CEST] <ubitux> i haven't used ffserver for a long time
[16:47:32 CEST] <mifritscher> Ok, one thing I didn't mentioned earlier: I don't do this in my free time. I got allocated min. 1 manmonth until end of the year for rescuing, and time for maintaining in the long run.
[16:47:39 CEST] <nevcairiel> its big problem of course is that it uses avcodeccontext on a de/muxer level, which is going away, so it would have to be re-designed, but without avcodeccontext it cant communicate all the things, since it relies on having encoder settings etc, which a muxer is not designed to have
[16:47:46 CEST] <nevcairiel> so you're really stuck there without a real big design change
[16:48:03 CEST] <mifritscher> ubitux: could be possible, but I think the avcodeccontext problem is the main problematic thing
[16:49:16 CEST] <jamrial> Chloe: sdl1 checks using check_func_headers(), so why not use that for sdl2?
[16:49:56 CEST] <ubitux> mifritscher: i don't even remember how it works tbh
[16:50:30 CEST] <jamrial> Chloe: for the non pkg_config path, at least
[16:51:27 CEST] <mifritscher> I'm writing a mail to ffmpeg-devel with my findings right now to get feedback whether there are right and to get further hints, planing steps etc :-)
[16:53:18 CEST] <wm4> jamrial: and here's the question why non-pkg-config should be supported
[17:02:09 CEST] <jamrial> wm4: i guess we could drop it for sdl2, yes, assuming the pkg-config path works in all situations (native, cross compile, etc)
[17:03:57 CEST] <wm4> as long as you set it up correctly
[17:17:02 CEST] <cone-670> ffmpeg 03Michael Niedermayer 07master:1bd9b960ba74: tests/fate/ffmpeg: Remove dead automatic remove extradata test update the keyframe test
[17:17:03 CEST] <cone-670> ffmpeg 03James Almer 07master:d41c9b1c275f: avcodec/remove_extradata_bsf: Fix AVoption parameter max value
[17:17:33 CEST] <michaelni> Chloe, https://0x0.st/QZ3.patch seems to work
[17:22:26 CEST] <Chloe> michaelni: ok, thanks
[17:32:58 CEST] <michaelni> Chloe, actually, while it fixes 32bit it breaks 64bit
[17:33:16 CEST] <michaelni> SDL2 is not detected on 64bit anymore it seems
[17:34:31 CEST] <Chloe> ugh.
[17:36:21 CEST] <Chloe> why does check_header not get passed the cflags?
[18:03:54 CEST] <mifritscher> bye
[18:06:42 CEST] <Chloe> jamrial: sure
[18:11:23 CEST] <Chloe> michaelni: using check_func now, pretty sure this should fix it.
[18:16:33 CEST] <noob> good day, anyone know how to use ffmpeg.exe to extract h264 nalu from *.mp4 file and save them per frame%d.dat file?  I've tried something like ffmpeg -i {some mp4 file} -vcodec copy -bsf h264_mp4toannexb -an -f {rawvideo|h264|whatever} out%d.h264 but it outputs a single file not muliple frame files. 
[18:16:52 CEST] <noob> is it even possible? 
[18:17:19 CEST] <Compn> the nalu , as in the nals ?
[18:17:27 CEST] <Compn> or what part do you want to extract, exactly? 
[18:17:35 CEST] <Compn> and what will you be using this output for , exactly ?
[18:18:12 CEST] <Compn> oh, you want to extract h264 video to raw h264 frames ?
[18:18:21 CEST] <Compn> individually
[18:18:33 CEST] <Mavrik> demux it?
[18:18:48 CEST] <Chloe> noob: you probably want #ffmpeg
[18:19:08 CEST] <Compn> the problem is h264 is made up of b and p frames, which arent complete frames. so extracting frames output would be incomplete
[18:19:20 CEST] <Compn> only the keyframes would be complete
[18:19:43 CEST] <cone-670> ffmpeg 03Michael Niedermayer 07master:0e318f110bcd: avcodec/cavsdsp: use av_clip_uint8() for idct
[18:19:55 CEST] <Chloe> Compn: maybe that's what they want
[18:20:06 CEST] <noob> sure, but I want to get my hands on actual NAL units, if I could save each nal unit to a separate file that would be good. 
[18:20:29 CEST] <noob> NAL units that are saved in mp4 container
[18:21:03 CEST] <Compn> noob : http://stackoverflow.com/questions/6062190/parsing-nal-units-using-ffmpeg
[18:22:28 CEST] <noob> yeah I was at #ffmpeg but got no response.  I can write code but don't have time right now. So if I could use ffmpeg.exe to extract nals for me that'd be great. 
[18:22:50 CEST] <noob> I guess it's not possible since I couldn't find any info...anyone can confirm? 
[18:23:03 CEST] <Compn> what are you using the nalu for ?
[18:23:05 CEST] <Compn> i need to know :P
[18:23:07 CEST] <Compn> ehe
[18:23:21 CEST] <Compn> 99999% of people dont need to split h264
[18:23:24 CEST] <noob> I'll be using the nalu to feed into some other program
[18:23:32 CEST] <Compn> which program?
[18:23:37 CEST] <noob> yes but 1% do :) 
[18:23:54 CEST] <noob> Campn, I don't think you have an answer.  Thanks anyways. 
[18:24:01 CEST] <Compn> lol
[18:24:10 CEST] <Compn> wants to use open source, wants to be secret about it
[18:24:12 CEST] <noob> I'm going with my assumption that ffmpeg.exe doesn't have this kind of option. 
[18:24:19 CEST] <Compn> go for it , then
[18:24:42 CEST] <noob> no true
[18:25:05 CEST] <noob> it doesn't matter what other program is. It doesn't exist actually.  I simply want to analyze the nals...
[18:25:56 CEST] <Compn> we might be able to point you to programs that analyze nals from mp4 :)
[18:25:57 CEST] <Compn> bah
[18:37:06 CEST] <jamrial> ubitux: mix keys and shorthands always worked afaik
[19:10:14 CEST] <Chloe> michaelni: is it fixed now for you?
[20:34:15 CEST] <michaelni> jamrial, is there a new bsf patch to test ? your branch seems to stil fail fate-ffmpeg-bsf-remove-r and fate-ffmpeg-bsf-remove-k
[20:37:38 CEST] <michaelni> Chloe, ive uninstalled ubuntu sdl2 and build my own now, but i think build worked
[20:37:54 CEST] <michaelni> that is ffmpeg build
[20:38:21 CEST] <jamrial> michaelni: no, i noticed those two are failing inmy branch, but i'm thinking the new output is correct and current git head is wrong
[20:39:23 CEST] <jamrial> r is remove on keyframes, k is remove on non keyframes
[20:39:44 CEST] <jamrial> the current output of k looks like it removed on keyframes instead, and the oposite for r
[20:43:45 CEST] <jamrial> for that matter, what i mentioned just now is after rebasing the branch with current git head to get the fate tests in the tree, in case that wasn't clear
[20:44:48 CEST] <jamrial> i didn't push a rebased version to keep it in sync with ubitux's branch of the same name so he can squash things and move forward
[20:51:14 CEST] <michaelni> Chloe, libavdevice/sdl2.c:207:5: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
[21:53:20 CEST] <jayridge> Hi. I am working on a project that requires RTSP over TLS with cafile support. I patched 3.1.3. Is this something of interest to the maintainers? If so, I am happy to finish out the patch. https://gist.github.com/jayridge/3eca6c04d002e726b86d57322b051b49
[21:59:22 CEST] <wm4> jayridge: I'm not sure if it should pass down the options this way... but I'm not an expert in the option system
[22:00:21 CEST] <jayridge> yeah i started with an rtsp url that had cafile=&
[22:01:43 CEST] <wm4> I think rather than URL options, these should be passed as private options somehow
[22:04:41 CEST] <jayridge> if someone can tell me the proper ffmpeg approach i will make the changes so everyone can have rtsps. this is my first foray with ffmpeg so there is clearly some stumbling.
[22:05:38 CEST] <Compn> jayridge : wait for rtsp maintainer to show up , or post to ffmpeg-devel 
[22:05:48 CEST] <Compn> and yes, it is appreciated to fix rtsps support...
[22:05:50 CEST] <Compn> :)
[22:06:07 CEST] <jayridge> ok thank you
[22:24:53 CEST] <cone-670> ffmpeg 03Michael Niedermayer 07master:4a3b41bed0d1: fate: add Test for h264_mp4toannexb (ticket2991)
[22:27:32 CEST] <Chloe> michaelni: is that the last thing? I don't particularly want to have to post a v4 :s
[22:28:21 CEST] <michaelni> Chloe, i dont think you need to post a new patch to fix a compiler warning
[22:28:54 CEST] <michaelni> that is if thats the only thing diferent
[22:29:17 CEST] <Chloe> yep, nothing else has changed except for just reorganising the commits due to sdl1 being dropped
[22:46:11 CEST] <jamrial> michaelni: yes, the new output seems to be correct. keyframes in this scenario are apparently marked wrong in git head
[22:47:23 CEST] <michaelni> interresting
[00:00:00 CEST] --- Sat Sep 24 2016