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

[burek]

[00:07:39 CET] <BtbN> Daemon404, well, iirc that was because of the overall quality of that patch itself. I'd prefer a set of yami de/encoders over the current QSV mess
[00:12:38 CET] <Daemon404> BtbN, also because it didnt add anything
[00:13:05 CET] <BtbN> hm?
[00:13:37 CET] <Daemon404> it added nothing of value
[00:14:46 CET] <BtbN> Well, beeing able to use the various hardware-encoders in current Intel-Hardware without the mess that QSV is on linux would be of value for me.
[00:14:52 CET] <BtbN> Or what did that patch do?
[00:16:21 CET] <Daemon404> http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/187520
[00:16:26 CET] <Daemon404> it's a big thread
[00:20:41 CET] <BtbN> oh, it was just a h264 decoder
[00:20:48 CET] <BtbN> And it's cpp
[00:41:07 CET] <rcombs> BtbN: same
[02:19:01 CET] <Daemon404> i sure would like to know who asyncts is a "maitenece burden" to
[02:19:27 CET] Action: Daemon404 wonders if aresample is even feature-parity with asyncts now
[02:32:33 CET] <J_Darnley> Daemon404: it exists in ffmpeg -- it is a maintainance burden
[02:32:36 CET] Action: J_Darnley runs
[02:33:36 CET] <Daemon404> J_Darnley, which is ironically what the ffmpeg people laughed at libav for doing ;p
[02:35:34 CET] <J_Darnley> I should have dropped the "in ffmpeg" to mae it more funny
[02:35:39 CET] <J_Darnley> *make
[02:36:38 CET] <Daemon404> ;p
[04:26:03 CET] <Compn> [swscaler @ 0332b0c0] deprecated pixel format used, make sure you did set range correctly
[04:26:07 CET] <Compn> -did
[04:26:16 CET] <Compn> +the
[09:26:56 CET] <cone-741> ffmpeg 03Claudio Freire 07master:4720a562c8d4: AAC encoder: fix possible assertion failure in PNS
[09:30:19 CET] <cone-741> ffmpeg 03Carl Eugen Hoyos 07master:b18230ee8c16: lavf/rmdec: Use correct format specifier for int64_t.
[10:20:41 CET] <nevcairiel> New NVIDIA drivers came out yesterday, fixed VP9 DXVA2 support
[10:21:01 CET] <nevcairiel> Now the surprising thing: it doesn't appear to be hybrid, practically no CPU usage
[10:22:52 CET] <nevcairiel> Including 4k at decent frame rates
[10:23:04 CET] <nevcairiel> 100+ fps
[10:23:56 CET] <nevcairiel> BtbN: fritsch ^^ even if you might not care about Windows much :D
[10:53:11 CET] <Loriker> wow
[12:49:47 CET] <BtbN> nevcairiel, does nvidia even have any hybrid decoders?
[12:49:54 CET] <BtbN> Except for the old CUVID stuff
[12:53:56 CET] <durandal_1707> michaelni: do you know how to calculate magnitude value at n frequency for filter in anequalizer?
[12:54:08 CET] <nevcairiel> BtbN: pre-960 they do it for HEVC
[13:15:58 CET] <cone-741> ffmpeg 03Timo Rothenpieler 07master:d7c2b75681e5: vaapi: Add VP9 hwaccell support
[13:17:07 CET] <michaelni> durandal_1707, not sure i understand the question but if you mean to find the scalar power/amplitude/... of a specific frequency in a signal that can be found by many means, fft being one (if you need multiple frquencies) or abs() of dot product with e^(f*i*x) or using some filter to split into bands and compute the energy in each band, ...
[13:20:00 CET] <durandal_1707> I need frequency response, not using fft
[13:20:29 CET] <durandal_1707> of single filter
[13:21:05 CET] <durandal_1707> michaelni: ^
[13:21:41 CET] <michaelni> sine sweep -> filter -> fft
[13:43:46 CET] <durandal_1707> michaelni: I want to add video output to anequalizer which will give frequency response, using fft for this is IIRC suboptimal 
[14:00:56 CET] <cone-741> ffmpeg 03erankor 07master:18cd7891cb10: MAINTAINERS: add Eran Kornblau for aes_ctr and movenccenc
[14:05:04 CET] <BtbN> Damn, just noticed the typo in the commit message. Oh well.
[14:07:25 CET] <fritsch> :p
[14:15:35 CET] <ubitux> michaelni: are you using the gaspp from the ffmpeg mirror on these fate instances?
[14:15:46 CET] <ubitux> iirc our gaspp isn't in sync anymore with upstream
[14:16:04 CET] <ubitux> maybe it causes some issues with recent additions?
[14:19:24 CET] <michaelni> the mail was about 2.7.1, gaspp is installed on the box, i assumed its used but who knows
[14:23:49 CET] <michaelni> how can i force gaspp to be used to test this?
[14:46:35 CET] <ubitux> michaelni: --as="/path/to/gas-preprocessor.pl $CC"?
[14:51:41 CET] <kierank> ar: libavresample/: File format not recognized
[14:51:43 CET] <kierank> what does that mean
[14:54:14 CET] <durandal_1707> I found out design data of filter in matlab on web, it have what I need :)
[15:04:50 CET] <cone-741> ffmpeg 03Michael Niedermayer 07master:05af8608c2dc: avcodec/ass: check for av_mallocz() failure
[15:35:25 CET] <philipl> nevcairiel: nvidia has dedicated vp8 and vp9 blocks - previously only exposed in Tegra.
[15:35:43 CET] <philipl> but the whole video decoder section is present on the new desktop cards
[16:04:15 CET] <fritsch> michaelni: https://github.com/FFmpeg/FFmpeg/commit/07b43fb69afdcd091af7fd32228c2608fd4821cb concerning this fix it seems even higher handbrake versions need full parsing
[16:04:40 CET] <fritsch> michaelni: here is a sample video: https://www.dropbox.com/s/1g71uytvdzqdqj1/Endangered%20Species%201x01%20Collecting%20Merl.mp4?dl=0
[16:04:40 CET] <kierank>   av_frame_alloc(), av_frame_unref() and av_frame_free() now can and should be
[16:04:41 CET] <kierank>   used instead of avcodec_alloc_frame(), avcodec_get_frame_defaults() and
[16:04:41 CET] <kierank>   avcodec_free_frame() respectively. The latter three functions are deprecated.
[16:04:42 CET] <kierank> wtf
[16:06:53 CET] <kierank> Daemon404: any idea how I set an AVframe to defaults then
[16:06:58 CET] <kierank> the APIchanges statement is useless
[16:07:09 CET] <nevcairiel> unref it
[16:07:21 CET] <kierank> really?
[16:07:32 CET] <kierank> I guess "reset the frame fields." probably means put them as default
[16:07:34 CET] <kierank> a bit unclear
[16:11:24 CET] <cone-741> ffmpeg 03Nicolas George 07master:63f7bee75221: lavfi/vf_mpdecimate: remove request_frame().
[16:11:25 CET] <cone-741> ffmpeg 03Nicolas George 07master:d03eab34dd8a: lavfi: rename link.current_pts to current_pts_us.
[16:11:26 CET] <cone-741> ffmpeg 03Nicolas George 07master:b8b7d5ac6c79: lavfi: add link.current_pts field.
[16:11:27 CET] <cone-741> ffmpeg 03Nicolas George 07master:39a09e995d32: lavfi: deprecate avfilter_link_set_closed().
[16:11:28 CET] <cone-741> ffmpeg 03Nicolas George 07master:108b4de5529a: lavfi: replace link.closed by link.status.
[16:11:29 CET] <cone-741> ffmpeg 03Nicolas George 07master:165578871272: lavfi: make request_frame() non-recursive.
[16:40:00 CET] <cone-741> ffmpeg 03Michael Niedermayer 07master:d3b6a9abacc9: avformat/mov: Update handbrake_version threshold for full mp3 parsing
[16:41:08 CET] <fritsch> michaelni: what about always parsing full if it was handbrake? :-)
[16:42:57 CET] <michaelni> i was planing to move towards that stepwise if the next versions still have the problem, didnt want to do it now though as it puts a weight on not fixing it as a fixed handbrake then would generate unplayable files for ffmpeg until we update the version check then again
[16:43:58 CET] <fritsch> I understand your reasoning, but what if the handbrake guys don't play copperative?
[16:44:09 CET] <fritsch> e.g. if they say: 2.7.x worked - we won't change anything and keep it as is
[16:45:14 CET] <rcombs> fritsch: michaelni why not just always do full parsing
[16:45:28 CET] <rcombs> if there's a bug in the MP3 parser that should be fixed there
[16:45:46 CET] <fritsch> i think wm4 proposed such a patch on the ML but this broke one sample
[16:45:53 CET] <fritsch> that (not other player could play)
[16:45:55 CET] <michaelni> full parsing would break some standard compliant mp4s IIUC
[16:46:21 CET] <rcombs> so the parser should be fixed
[16:47:27 CET] Action: michaelni is happy about any solution that works with all samples
[16:47:33 CET] <rcombs> anyone got a sample it breaks?
[16:47:47 CET] <fritsch> nevcairiel: <- linked me one last time
[17:08:19 CET] <fritsch> rcombs: http://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/184188.html
[17:08:32 CET] <Daemon404> [15:07] <@nevcairiel> unref it <-- never woi;d have guessed that
[17:09:57 CET] <fritsch> same - unref means something totally different
[17:26:48 CET] <cone-741> ffmpeg 03Michael Niedermayer 07master:5dbd114b83b0: avformat/movenc-test: Make format static
[17:29:49 CET] <rcombs> http://puu.sh/m4T1z/dbed312206.png this blip does not sound pleasant
[17:30:31 CET] <fritsch> last time I tried it - the sample worked with master
[17:33:27 CET] <fritsch> but no other player could play it (including mp123, totem, mplayer with old ffmpeg, older ffmpeg)
[17:35:14 CET] <rcombs> for me it plays, but with lots of error messages and a highly unpleasant noise towards the end
[17:35:43 CET] <rcombs> but if nothing else can play it I'm not sure why we care much about that particular sample
[17:38:19 CET] <fritsch> hehe, try what you get with ffmpeg 2.7.x
[17:38:21 CET] <fritsch> or mpg123
[17:38:29 CET] <fritsch> but silence the speakers before doing so
[17:41:23 CET] <rcombs> I'm not gonna take you up on that one
[17:43:13 CET] <fritsch> rcombs: hehe
[17:43:55 CET] <fritsch> concerning the other workaround for handbrake, what makes me wonder most: they use ffmpeg to encode that audio ...
[17:44:06 CET] <fritsch> afaik
[17:47:37 CET] <fritsch> https://github.com/HandBrake/HandBrake/blob/master/libhb/encavcodecaudio.c <- i think that last commit could fix / workaround the issues
[17:47:57 CET] <fritsch> https://github.com/HandBrake/HandBrake/commit/d05e644d5243dbd0d0cb7550e28345b897c8f7cd <- and this was most likely the issue
[17:49:43 CET] <fritsch> michaelni: ^^ rcombs ^^ you probably have already seen this
[17:51:48 CET] <BtbN> Just noticed that libyami depends on ffmpeg, so using it from ffmpeg creates an interesting situations.
[17:51:57 CET] <BtbN> well, optionaly depends.
[17:52:09 CET] <BtbN> And only on avformat
[17:56:30 CET] <cone-741> ffmpeg 03Michael Niedermayer 07release/2.6:d6ce1cb14077: Update for 2.6.6
[18:00:58 CET] <kierank> Deprecate av_write_header
[18:00:59 CET] <kierank> ???
[18:01:00 CET] <kierank> wtf
[18:01:21 CET] <fritsch> most things I just used to implement an ffmpeg image viewer are deprecated, too
[18:02:06 CET] <nevcairiel> where are you reading that kierank
[18:02:06 CET] <kierank> replaced with what though
[18:02:13 CET] <kierank> APIChanges
[18:02:50 CET] <nevcairiel> avformat_write_header is the replacement, apparently
[18:03:30 CET] <nevcairiel> yeah av_write_header hasnt existed for ages
[18:04:15 CET] <nevcairiel> deprecation from 2011
[18:04:21 CET] <nevcairiel> so likely removed a while ago as well
[18:04:30 CET] <kierank> yes I am aware
[18:04:40 CET] Action: kierank has old code
[18:07:43 CET] <Daemon404> kierank, APIChanges is a useless document
[18:07:46 CET] <Daemon404> add X
[18:07:48 CET] <Daemon404> remove Y
[18:09:41 CET] <durandal_1707> fritsch: does it have replacement?
[18:10:08 CET] <nevcairiel> this particular entry actually mentiones their replacement Daemon404
[18:10:22 CET] <fritsch> durandal_1707: yes - can be workarounded
[18:10:23 CET] <Daemon404> nevcairiel, sure, im just speaking from past experiences
[18:10:44 CET] <fritsch> though some instructions are not fully clear, for example we use since a long time encoded_frame->pts
[18:11:03 CET] <fritsch> for encoding raw streams to ac3
[18:11:26 CET] <fritsch> for pictures it's mostly: av_picture_fill stuff and all the linesize[] and data[] members
[18:11:35 CET] <fritsch> need to look more into it on howto fix up those
[18:11:53 CET] <nevcairiel> av_picture was generally replaced with av_image*
[18:12:17 CET] <nevcairiel> and AVPicture as a struct either with AVFrames or manually keeping linesize and data arrays around, depending on how you need it
[18:12:26 CET] <fritsch> I will look into all of this, when we got out our "v16" release
[18:13:00 CET] <fritsch> out of the door
[18:13:40 CET] <kierank> avformat_new_stream ??
[18:13:44 CET] <kierank> doesn't explain how  to free it
[18:15:22 CET] <Daemon404> eh
[18:15:24 CET] <Daemon404> yes it does
[18:15:32 CET] <Daemon404> User is required to call avcodec_close() and avformat_free_context() to clean up the allocation by avformat_new_stream().
[18:15:51 CET] <kierank> but what about the AVStream?
[18:16:06 CET] <fritsch> implicitely freed?
[18:16:08 CET] <Daemon404> it's part of the avformatcontext free
[18:16:20 CET] <Daemon404> that's why you call it with an afctx
[18:17:13 CET] <nevcairiel> yeah you never create stand-alone AVStreams, always directly associated with a context
[18:17:17 CET] <nevcairiel> and it gets free'ed with it
[18:17:26 CET] <Daemon404> in my code i also call avcodec_close on their ->codec member
[18:21:06 CET] <cone-741> ffmpeg 03Michael Niedermayer 07n2.6.6:HEAD: avformat/movenc-test: Make format static
[19:42:34 CET] <cone-741> ffmpeg 03Andreas Cadhalpun 07master:7172175da6f8: mlvdec: validate bits_per_coded_sample
[20:03:53 CET] <BtbN> i realy wonder how people got the idea that "encode" is a good symbol name
[20:24:41 CET] <cone-741> ffmpeg 03Andreas Cadhalpun 07master:b648b246f07a: diracdec: add missing check for pixel_range_index
[21:03:11 CET] <JEEB> man, what is with the sudden surge of people trying to use ffserver as of late
[21:03:23 CET] <JEEB> (on #ffmpeg)
[21:03:31 CET] <JEEB> did it get mentioned somewhere?
[21:07:01 CET] <ubitux> it's not that rare
[21:07:35 CET] <JEEB> well no, but this is the first time since 2011 when there's multiple people within a month or so
[21:08:50 CET] <JEEB> it's kind of scary looking at the usability of ffserver
[21:09:13 CET] <JEEB> (it might do something, but you have to go through three pools of goat blood on the night of the crimson moon to get there)
[21:09:25 CET] <ubitux> ffserver was mentioned by 25 unique people this year
[21:09:27 CET] <ubitux> on #ffmpeg
[21:09:43 CET] <JEEB> now give me a time distribution :)
[21:09:59 CET] <JEEB> I'd bet a lot of them would be during the latter part of the year
[21:10:06 CET] <ubitux> ...and 167 time last year
[21:10:14 CET] <JEEB> ouch
[21:11:14 CET] <ubitux> (actually a bit less, an idiot pasted some <Stream> thing, my grep is borked :D)
[21:11:24 CET] <ubitux> maybe 150 or so
[21:11:42 CET] <ubitux> i only have a year unit in my logs, can't really give more insight :p
[21:11:50 CET] <ubitux> (without pain that is)
[21:12:17 CET] <JEEB> and let's not go towards pain :) we all have enough of that for ourselves
[21:13:58 CET] Action: ubitux disappointed, the pthread assert thing didn't find any issue in fate :(
[21:14:56 CET] <durandal_1707> kierank: what channel layouts are used by s302m?
[21:15:17 CET] <kierank> None
[21:15:28 CET] <kierank> It's arbitary
[21:15:32 CET] <JEEB> yeah
[21:15:59 CET] <durandal_1707> then why decoder sets it?
[21:19:29 CET] <kierank> Because decoder is wrong
[21:19:40 CET] <kierank> And iirc nobody would listen to me last time
[21:45:13 CET] <durandal_1707> kierank: what's way to get channel layouts?
[21:48:41 CET] <Prelude2004c_> hey guys... good day.. is there something known that is a problem with vdpau ? i can't seem to decode using the GPU the h264 sources but i can do mpeg2video ones without a problem
[21:48:59 CET] <Prelude2004c_> i am wondering if this is something with ffpmeg and if so i will use something else to decode and set to raw data to re-encode
[21:50:46 CET] <Daemon404> it should work afaik
[22:10:37 CET] <Prelude2004c_> anyone... having trouble with decoding h264 content
[22:10:40 CET] <Prelude2004c_> using M4000 card
[22:12:58 CET] <kierank> durandal_1707: cant
[23:05:00 CET] <ubitux> so, with vtb (in async), how are we supposed to know how much frame we need to wait before getting sure that we get all frames and we can then sort them?
[23:10:08 CET] <BtbN> Does ffmpeg/lavu have something to get the fourcc of a pixel format?
[23:11:15 CET] <ubitux> av_get_pix_fmt_name?
[23:13:01 CET] <ubitux> actually, avcodec_pix_fmt_to_codec_tag()
[23:13:36 CET] <ubitux> i wonder why it's not in the pixel format desc
[23:13:42 CET] <BtbN> ah, was looking into the pixel format descrition struct instead
[23:14:12 CET] <ubitux> would be nice to have them there indeed
[23:16:57 CET] <BtbN> Great, yami expectes frame data to be in a single continous buffer, and wants offsets into it instead
[23:17:02 CET] <BtbN> so a lot of pointless copying
[23:18:04 CET] <ubitux> "
[23:18:06 CET] <ubitux> You should be able to keep decoding frames until the decode timestamp is greater than or equal to the earliest presentation timestamp in the reorder queue"
[23:18:08 CET] <ubitux> mmmh
[23:18:12 CET] <ubitux> so that might answer my question
[23:24:04 CET] <rcombs> BtbN: `yami_frame->buf = avframe->buf; yami_frame->offset0 = avframe->data[0] - avframe->buf; <etc&>`?
[23:24:53 CET] <BtbN> rcombs, but isn't there one buf for every plane?
[23:25:02 CET] Action: rcombs shrugs
[23:25:04 CET] <BtbN> at least it's AVBufferRef *buf[AV_NUM_DATA_POINTERS];
[23:25:41 CET] <rcombs> `yami_frame->buf = avframe->data[0]; yami_frame->offset0 = 0; yami_frame->offset1 = avframe->data[1] - avframe->data[0];`
[23:25:46 CET] <rcombs> <etc&>
[23:25:59 CET] <rcombs> unless it actually reads the intervening data in which case lolsegfaults
[23:26:13 CET] <BtbN> That sounds kinda awfull
[23:26:33 CET] <rcombs> it is!
[23:26:39 CET] <rcombs> but it's not memcpy
[23:26:46 CET] <Daemon404> .. what are you trying to do here
[23:26:51 CET] <Daemon404> does yami have no concept of stride?
[23:26:58 CET] <BtbN> It does
[23:27:08 CET] <BtbN> It has: data pointer, offset[3], stride[3]
[23:27:55 CET] <Daemon404> is data even guaranteed to be a contiguous buffer
[23:28:06 CET] <BtbN> in ffmpeg? No.
[23:28:12 CET] <BtbN> But yami seems to expect it to be.
[23:28:17 CET] <BtbN> So copying stuff around it is
[23:28:22 CET] <Daemon404> yeah thats why i asked
[23:28:38 CET] <fritsch> better rise an issue with them before it's too late
[23:28:51 CET] <fritsch> it seems libyami is not really what should be coped with
[23:28:54 CET] <BtbN> But if yami doesn't touch the data in between, just giving it the lowest of the 3 data pointers, and calculating offsets might still work
[23:29:08 CET] <Daemon404> it may work
[23:29:13 CET] <Daemon404> but it's not guaranteed to stay working
[23:29:18 CET] <rcombs> yeah, that's my (potentially very bad) idea
[23:29:35 CET] <rcombs> yelling at the yami guys may be a better idea
[23:30:43 CET] <Daemon404> otherwise youre stuck with av_image_copy_to_buffer
[23:30:45 CET] <rcombs> maybe I should have my intel guy do the yelling
[23:31:06 CET] <Daemon404> alternatively
[23:31:07 CET] <Daemon404> if you can
[23:31:12 CET] <Daemon404> you can control get_buffer2
[23:31:16 CET] <Daemon404> and ensure it is contiguous
[23:31:27 CET] <Daemon404> if this is a downstream codebase.
[23:31:35 CET] <Daemon404> if this is internal, you're SOL
[23:32:04 CET] <durandal_1707> who wants parametric equalizer to draw frequency response curve?
[23:32:28 CET] <Rokam> I'm trying to understand why the use of avformat_open_input for m3u8 playlist doesn't work like the ffmpeg command line
[23:32:47 CET] <rcombs> Rokam: what happens?
[23:34:28 CET] <rcombs> I may be able to wield some amount of influence over libyami
[23:34:45 CET] <Rokam> rcombs: Kodi uses avformat_open_input and avcodec_open2. When I pass the playlist
[23:35:12 CET] <Rokam> on every response and on every ts file it changes the cookie
[23:35:43 CET] <Rokam> after about 5 minutes the server returns error 403 due to a wrong cookie
[23:36:11 CET] <Rokam> I've sent a patch for that issue: https://github.com/FFmpeg/FFmpeg/commit/770dd105044d00263da041f509a08b316296a78e
[23:36:35 CET] <Rokam> And it works fine when I pass the playlist through the command line
[23:36:52 CET] <Rokam> but Kodi remains with the issue
[23:37:10 CET] <Rokam> even with the fixed ffmpeg code
[23:37:35 CET] <Rokam> I'm trying to find the issue to send a patch to kodi or ffmpeg
[23:38:00 CET] <Rokam> but I'm kind noob and I'm unable to compile kodi on win10
[23:39:15 CET] <Rokam> I think the issue is that the context is getting lost when the call comes by libavformat shared
[23:40:43 CET] <Rokam> rcombs: any tip for me?
[23:41:30 CET] <rcombs> maybe debug the process and see if line 548 there is running?
[23:42:52 CET] <Rokam> I'll try to compile kodi again
[23:43:56 CET] <Rokam> rcombs: Is there a simple player that uses ffmpeg shared libs?
[23:44:03 CET] <rcombs> almost certainly easier to do this on a POSIX system
[23:44:11 CET] <rcombs> ffplay, for one
[23:44:30 CET] <rcombs> or mpv (less simple)
[23:44:31 CET] <Rokam> I can't set a cookie on ffplay
[23:44:37 CET] <rcombs> sure you can
[23:44:42 CET] <Rokam> I'll try mpv
[23:45:10 CET] <Rokam> so, I'll try it again
[23:45:43 CET] <Rokam> should I use --headers "Cookie: xxxxxx"?
[23:45:58 CET] <fritsch> Rokam: how did you build kodi against an ffmpeg version with that patch integrated in the first place?
[23:46:32 CET] <Rokam> The beta2 is already with that patch
[23:46:33 CET] <rcombs> just `-cookies <whatever>` I believe
[23:46:34 CET] <fritsch> Rokam: kodi ships 2.8.4 (Jarvis nightly / master nightly), latest stable has 2.7.x
[23:46:52 CET] <Rokam> the patch is on 2.8.2
[23:47:01 CET] <Rokam> I think
[23:47:06 CET] <Rokam> or 2.8.3
[23:47:11 CET] <fritsch> i updated kodi's ffmpeg that afternoon
[23:47:35 CET] <fritsch> jep, it's there -verfied
[23:48:08 CET] <fritsch> was pushed to 2.8.x on 30 october
[23:48:21 CET] <rcombs> Rokam: if the caller sets a cookie using the "Headers" option, that patch won't work as expected
[23:49:03 CET] <Rokam> fritsch: https://github.com/xbmc/FFmpeg/blob/release/2.8-xbmc/libavformat/hls.c#L629 ;)
[23:49:24 CET] <Rokam> rcombs: Thanks for the info. But why it won't work?
[23:51:23 CET] <rcombs> because the patch doesn't handle that case?
[23:53:26 CET] <fritsch> Rokam: yes, found it as said above
[00:00:00 CET] --- Wed Dec 23 2015