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

burek burek021 at gmail.com
Sat Sep 21 02:05:02 CEST 2013


[00:00] <ubitux> anyway, should be fixed in a day or two, hopefully
[00:05] <michaelni> ubitux, do you want to review "James Almer     (0.9K) [FFmpeg-devel] [PATCH 1/2] matroskaenc: Add CuePoints for subtitle tracks" ?
[00:06] <ubitux> i'm not really a mkv maintainer
[00:06] <ubitux> i don't know much about the format
[00:11] <durandal_1707> michaelni: what sample you used to make that yadif patch?
[00:12] <durandal_1707> yadif=7 is better than yadif=0/1 with sample i have except last horizontal scrolling text which imho is worse
[00:13] <durandal_1707> the sample i use is SD_PAL_25_576i.ts
[00:13] <michaelni> i remember how the sample looked but not the filename so finding it might be tricky ...
[00:14] <durandal_1707> well first few frames is rainbow test pattern
[00:15] <michaelni> mine was panning a cammera around in a room
[00:15] <Compn> ehe
[00:15] Action: Compn posts reply to yadif mail
[00:16] <Compn> JEEB : so -dumpstream then? :P
[00:16] <durandal_1707> michaelni: this one http://dl.dropbox.com/u/8424544/SD_PAL_25_576i.ts
[00:17] <michaelni> Error (404)
[00:19] <durandal_1707> https://dc2.safesync.com/FdSVjnr/offen/Slices/SD_PAL_25_576i.zip?a=nEMYwdW4GdQ
[00:24] <durandal_1707> but yes this generally improves scrolling/rotating text stuff
[00:31] <cone-685> ffmpeg.git 03Paul B Mahol 07master:3e2a5b33f035: avformat/matroskadec: use av_malloc_array() and check for allocation error
[00:42] <michaelni> ruggles, btw, we have some ac3 patches on ffmpeg-devel that would need a review (Nedeljko Babic  (0.3K) [FFmpeg-devel] Implementation of fixed point aac and ac3 decoders) if you are interrested and have time?
[01:04] <durandal_1707> michaelni: when size of input images changes ffmpeg drops rest of images...
[01:11] <durandal_1707> it just drops other frames
[01:18] Action: Compn wonders what the heck don moir is talking about in the alpha thread
[01:18] <Compn> is don on irc ?
[01:38] <durandal_1707> michaelni: that happens if i use -r for image2 demuxer, doesn't if i use -framerate
[01:53] <durandal_1707> actually this is non-issue....
[02:33] <BBB> whoever privmsg'ed me should probably repeat his statement
[02:33] <BBB> my log isn't there
[02:35] <BBB> michaelni: any opinions on ffvp9? I think it passes all conformance samples now so we can probably merge it (though it's currently not simd optimized)
[02:35] <BBB> michaelni: I can send a patch
[02:41] <michaelni> sending a patch sounds like a good idea
[02:42] <michaelni> maybe others have comments too
[03:28] <Compn> yeah, does it do alpha ? :P
[03:28] <Compn> 50 comments on alpha
[03:31] <smjd> 'volumedetect' filter always says max_volume is 0.0db when there's clipping but that doesn't help at all in normalizing audio
[03:43] <BBB> Compn: no, that's profile 1, only profile 0 is spec'ed so far (that is, the alpha bitstream isn't finalized yet)
[03:50] <cone-852> ffmpeg.git 03Monty Montgomery 07master:f6622f9610af: avformat/matroskadec: correct spurious keyframe warnings in webm
[11:06] <cone-1> ffmpeg.git 03Vladimir Pantelic 07master:5f408333601a: asfdec: substract preroll time from marker presentation time
[11:06] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:c16470d77a1b: Merge commit '5f408333601a827054335f309defcb246a532b21'
[11:07] <av500> \o/
[11:18] <cone-1> ffmpeg.git 03Vladimir Pantelic 07master:c53b5dda3524: asfdec: replace magic constant with DATA_HEADER_SIZE
[11:18] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:c6526620a9a8: Merge commit 'c53b5dda352452e79a9e962cd4c74c813186d9ed'
[11:18] <michaelni> hmm, why does the server today need ages for a git push ? :(
[11:23] <av500> why cant I click on git urls from cone-1?
[11:24] <nevcairiel> there are no urls there
[11:24] <av500> yes
[11:24] <av500> that much I understood
[11:36] <ubitux> mmh the quality factor with libfaac needs to be extremely high to be relevant
[11:38] <ubitux> too bad.
[11:40] <av500> there is always ffaacenc
[11:43] <ubitux> is it competitive with faac or not yet?
[11:45] <nevcairiel> imho faac has horrible quality, and at least the patched native encoder with the patch from the epic ticket should beat it easily
[11:50] <ubitux> but still WIP, right?
[11:51] <ubitux> btw, opencoreamr is a fork of fdk-aac?
[11:51] <ubitux> is it relevant for encoding?
[11:51] <ubitux> i see only fdk-aac mentioned most of the time
[11:52] <nevcairiel> nah its kinda related, they are hosting fdk-aac in their repository or somethin'
[11:56] <cone-1> ffmpeg.git 03Vladimir Pantelic 07master:1eb932803037: asfenc: add ASF_Reserved_4 as defined in section 10.10 of the ASF spec
[11:56] <cone-1> ffmpeg.git 03Vladimir Pantelic 07master:09f3c937ed6f: asfenc: remember send time and offset of the index entries
[11:56] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:c6b425896541: Merge commit '1eb932803037a3c9f98f66aeb80024dfa3c5c743'
[11:56] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:018e0db5eff2: Merge commit '09f3c937ed6fd7c5bd64450d45f73b0f4975f4c9'
[11:56] <ubitux> what about the wrappers?
[11:58] <Harold_> Can someone please explain line 506 of "libavformat/aviobuf.c"?
[11:59] <saste> who can explain ticket 2877?
[11:59] <saste> is it possible that the decoder keep some info in the context which may affect the decoder output?
[12:00] <saste> there is a small (imperceptible) difference when seeking and decoding again
[12:01] <saste> all the differences are of the order of -3.05176e-05 (comparing doubles)
[12:02] <durandal_1707> well that is how mp3 works...
[12:02] <durandal_1707> you get different output each time you play it...
[12:05] <saste> durandal_1707, why? is that a joke or what
[12:05] <Harold_> Does anyone else think that line 506 of "libavformat/aviobuf.c" is at least strange?
[12:06] <saste> Harold_, show the line
[12:06] <Harold_> No, that's not a joke -- lots of decoders keep all kinds of estimates and fudge factors as they decode, so that if you play like 10 seconds in the middle of a track it is not precisely the same as if you played the entire track
[12:06] <Harold_> s->buf_ptr = s->buffer;                     s->buf_end = s->buffer/* + len*/;
[12:07] <Harold_> I think "adaptive" is the word I'm looking for, re MP3.
[12:07] <durandal_1707> git blame is your friend
[12:07] <durandal_1707> so person responsible for than code is michaelni 
[12:07] <ubitux> any idea what's the range of the quality factor for our aac encoder?
[12:08] <durandal_1707> you mean qscale ?
[12:08] <saste> Harold_, indeed, makes sense
[12:08] <saste> ^ regarding the MP3 issue
[12:09] <Harold_> You have sharp eyes, Saste, but even the sharpest ears can't tell the difference, I'm sure.  Nothing to worry about.
[12:09] <av500> MP3 decoder has a "back buffer"
[12:09] <ubitux> durandal_1707: yes, assuming -q:a, -qscale:a and "global_quality" are the same
[12:09] <av500> so it has "state"
[12:09] <av500> if the seek does not reset the decoder, seeking back could indeed change the output
[12:09] <av500> assuming the first frame of the file has a back pointer
[12:09] <Harold_> I daresay all the lossy compression algorithms have similar state-related effects.
[12:11] <nevcairiel> ubitux: i think its 0-10
[12:11] <ubitux> nevcairiel: yeah, above 10 it's becoming nonsense
[12:11] <ubitux> http://pastie.org/8341308
[12:11] <saste> Harold_, indeed the difference is unperceptible
[12:11] <nevcairiel> note that global_quality if set from code is qscale * FF_QP2LAMBDA 
[12:11] <ubitux> nevcairiel: but look abouve 4
[12:12] <ubitux> above*
[12:12] <nevcairiel> is that with or without the patch?
[12:12] <ubitux> without, git/master
[12:12] <nevcairiel> the patch focused a lot on ABR, not VBR, but no idea how master behaves on VBR
[12:13] <durandal_1707> saste: do you know how to avoid queue filing thus kepping all frames in memory when filter_frame() returns many frames out of single one?
[12:13] <nevcairiel> it may have fixed such things as well, might be worth a try
[12:13] <ubitux> i'd like to have some aac vbr but... it looks like every aac encoder is completely fucked up with qscale
[12:26] <cone-1> ffmpeg.git 03Vladimir Pantelic 07master:bb461370e34b: asfenc: mux chapters in ASF files using an ASF "marker" section
[12:26] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:04ee57ce0aba: Merge commit 'bb461370e34b1fa1637f34ce7d37b934ddb472d5'
[12:28] <michaelni> someone might want to double check that asf chapters work correctly, our index handling differs from libavs, av500?
[12:29] <av500> ?
[12:29] Action: michaelni thought av500 is interrested in asf
[12:31] <cone-1> ffmpeg.git 03Martin Storsjö 07master:3627ce2f1dab: aviobuf: Add functions for null buffers
[12:31] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:2ad8056c5e4c: Merge commit '3627ce2f1dab1d33b7f99d78907a3e4d86b7d847'
[12:43] <cone-1> ffmpeg.git 03Martin Storsjö 07master:72fe16a13e3e: movenc: Use null buffers for measuring the amount of data to be written
[12:43] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:35a8387b4026: Merge commit '72fe16a13e3ebd5396ac173bf84c8b20085c16d5'
[12:58] <cone-1> ffmpeg.git 03Martin Storsjö 07master:f50803354c6a: asvdec: Verify the amount of extradata
[12:58] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:1e9a850df9b2: Merge commit 'f50803354c6acb4575379d7c54ca48ec5d36dd61'
[12:58] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:13b353a7cb27: avcodec/asvdec: dont fail without extradata
[13:18] <cone-1> ffmpeg.git 03Martin Storsjö 07master:e9d61de96c11: mpegaudiodec: Validate that the number of channels fits at the given offset
[13:18] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:3f4cf77abde2: Merge commit 'e9d61de96c113ee0ef8082833c7e682df0e23eec'
[13:26] <cone-1> ffmpeg.git 03Martin Storsjö 07master:7a5a55722749: qpeg: Add checks for running out of rows in qpeg_decode_inter
[13:26] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:61a8eaf7119d: Merge commit '7a5a55722749a3ab77941914707277b147322cbe'
[13:42] <cone-1> ffmpeg.git 03Martin Storsjö 07master:601c2015bc16: svq3: Avoid a division by zero
[13:42] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:c092af30088e: Merge commit '601c2015bc16f0b281160292a6a760cbbbb0eacb'
[13:51] <durandal_1707> saste: so do you have any idea how to handle quueue filling issue?
[13:52] <durandal_1707> i guess it should not queue them if that is not really needed
[13:56] <wm4_> ubitux: will you push your vosub fix to master? and the releases, preferably
[13:57] <ubitux> i'm still debugging it
[13:57] <ubitux> (not right now though)
[13:57] <ubitux> wm4_: it's breaking something
[13:57] <wm4_> nasty
[13:57] <ubitux> yeah
[13:57] <wm4_> stupid DVD crap
[13:57] <wm4_> DVDs and everything related is a nightmare :(
[13:58] <ubitux> there are multiple size information
[13:58] <ubitux> and sometimes/often/all-the-time they mistmatch
[13:58] <ubitux> and since one sub chunk can be splitted, it's a bit tricky to handle properly
[13:59] <ubitux> i have an heuristic to fix that particular issue you have without breaking the rest, but as i said yesterday i might be simply missing something
[14:00] <ubitux> so, i'm looking for the expected behaviour
[14:01] <cone-1> ffmpeg.git 03Martin Storsjö 07master:82e266c6d3fb: segafilm: Validate the number of audio channels
[14:01] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:c188c10805aa: Merge commit '82e266c6d3fbf3cc74e515b883e66543381a0f2c'
[14:02] <wm4_> anyway, it works with the mplayer vobsub reader
[14:02] <wm4_> if you need any reference
[14:02] <ubitux> that's the last one i would pick
[14:03] <ubitux> i remember fixing it for a particular nasty vobsub stream (which is now part of ffmpeg fate test)
[14:03] <ubitux> and i still don't know if that was the correct way of fixing it
[14:04] <ubitux> and thx to your report, i realized it's still not entirely supported by our demuxer
[14:04] <wm4_> it was reported by a mpv user
[14:05] <ubitux> yeah i remember
[14:09] <durandal_1707> anyone needs ladspa wrapper in lavfi?
[14:09] <wm4_> yes, here please
[14:10] <wm4_> btw. I wonder why the libmpcodecs thing hasn't been done for libaf?
[14:10] <durandal_1707> wm4_: first remove random filter from mpv
[14:11] <saste> wm4_, because they are few filters, and we have already many of them
[14:11] <saste> it's easier to port the few missing filters
[14:12] <wm4_> but the libmpcodecs wrapper is not yet to be removed from lavfi despite only a few filters left to port, heh
[14:12] <durandal_1707> wm4_: what libaf filter is needed in lavfi?
[14:13] <wm4_> hm maybe af_volnorm (af_drc in mpv), af_hrtf, af_equalizer, af_bs2b
[14:14] <wm4_> not that any of these is particularly great
[14:14] <durandal_1707> wm4_: have you ever checked what lavfi filters have?
[14:16] <wm4_> yes?
[14:16] <durandal_1707> af_volnorm/af_drc is crap
[14:16] <wm4_> yes
[14:17] <wm4_> but so are most filters you are porting
[14:17] <wm4_> they are all somewhat/maybe useful, but not state of the art
[14:17] <durandal_1707> huh?
[14:17] <wm4_> the filters I mentioned also belong in that category
[14:18] <durandal_1707> af_drc certainly not
[14:20] <wm4_> so what is there in lavfi?
[14:22] <cone-1> ffmpeg.git 03Martin Storsjö 07master:3185a80259ce: fraps: Make the input buffer size checks more strict
[14:22] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:9bb86faca793: Merge commit '3185a80259ce1f8f8111073dbd14a69a396e03a3'
[14:23] <durandal_1707> wm4_: ffmpeg -filters | grep dynamic\ range
[14:29] <saste> durandal_1707, about the queuing issue, i still can't understand what's your use case
[14:29] <saste> also, did you read doc/filter_design.txt?
[14:30] <saste> we have some constraints on the number of frames generated by filter_frame(), we can produce only one frame per output
[14:30] <saste> the other frames must be cached
[14:30] <saste> why is that an issue?
[14:32] <durandal_1707> it eats memory but it does not need to
[14:32] <durandal_1707> so design sucks
[14:33] <saste> caching is difficult to design properly
[14:33] <durandal_1707> saste: doesn't doc/filter_design.txt needs updates?
[14:33] <saste> the constraint was added later
[14:33] <saste> durandal_1707, it was updated
[14:33] <durandal_1707> no you fail point, caching should not be done when it is not needed
[14:34] <durandal_1707> saste: it still have no more relevant text
[14:35] <ubitux> nicolas said he would do it
[14:35] <ubitux> blame him
[14:37] Action: saste goes to beach
[14:37] <saste> bbl
[14:42] <cone-1> ffmpeg.git 03Martin Storsjö 07master:d8b68660145c: yop: Clear all references to the AVBuffer in the local AVPacket
[14:42] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:09b09ef4ab5c: Merge commit 'd8b68660145c76a23fc9665f96932449514ecad2'
[14:45] <ubitux> it seems faac vbr is starting to sounds ok around -q:a 100
[14:46] <nevcairiel> what bitrate is that?
[14:46] <durandal_1707> 500k
[14:47] <ubitux> fdk-aac is broken the other way around: -q:a can't actually be used
[14:47] <ubitux> 0 -> 0, 1 -> 118
[14:47] <nevcairiel> thats the stupid lambda quality scaling ffmpeg applies
[14:48] <ubitux> (-q:a -> fdkquant)
[14:48] <ubitux> (fdkquant which should be 1-5)
[14:48] <nevcairiel> it takes all input params and multiplies them by 118
[14:48] <nevcairiel> presumanly for mpeg4
[14:48] <nevcairiel> many decoders then take global_quality and divide it by that factor again before using
[14:48] <ubitux> so no one ever does vbr with aac?
[14:49] <nevcairiel> s/decoders/encoder/
[14:49] <nevcairiel> fdk-aac has its own parameter
[14:50] <nevcairiel> try -vbr 1-5
[14:51] <ubitux> mmh i see; so we need a mapping/warning/whatever when qscale is set
[14:51] <nevcairiel> it could just unscale the global_quality again to get rid of that damn factor
[14:51] <nevcairiel> like the native one does
[14:52] <ubitux> the native one is also broken, in yet another way
[14:52] <ubitux> now the question is; are we supposed to do that rescaling in the codec itself, or in the caller?
[14:52] <ubitux> api users might be relying on that global_quality verbatim value
[14:52] <nevcairiel> its kinda stupid when the codec does it, because the caller needs to know to multiply global_quality with the factor first
[14:53] <nevcairiel> the whole thing should just vanish
[14:53] <nevcairiel> the factor, i mean
[14:53] <nevcairiel> and the one codec that needs it, should apply it manually
[14:53] <nevcairiel> but that breaks API
[14:54] <ubitux> - git grep 'global_quality.*FF_QP2LAMBDA' libavcodec|wc -l
[14:54] <ubitux> 10
[14:55] <ubitux> there is also this FF_QUALITY_SCALE
[14:56] <cone-1> ffmpeg.git 03Martin Storsjö 07master:83c285f88016: wtv: Add more sanity checks for a length read from the file
[14:56] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:6c18775bae78: Merge commit '83c285f88016b087c2f0f4b9ef356ad8ef12d947'
[14:56] <durandal_1707> wm4_: i'm just looking at ladspa source code, but perhaps there are 3rd plugins that use ladspa?
[14:57] <wm4_> durandal_1707: not sure what you're saying
[14:59] <ubitux> oh global_quality is deduced from the qscale mmmh
[15:00] <durandal_1707> wm4_: what is so useful in ladspa that we need wrapper for it?
[15:00] <wm4_> no idea, but it gives access to a lot of filters
[15:05] <cone-1> ffmpeg.git 03Martin Storsjö 07master:3ca14aa5964e: rl2: Avoid a division by zero
[15:05] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:2a930fa29ea2: Merge commit '3ca14aa5964ea5d11f7a15f9fff17924d6096d44'
[15:15] <ubitux> actually it might be correct currently for faac
[15:15] <ubitux>        -q <quality>
[15:15] <ubitux>               Set default variable bitrate (VBR) quantizer quality in percent (default: 100).
[15:15] <ubitux> of course there is no information on the range so...
[15:18] <ubitux> maybe we could introduce an overall scaled quality option
[15:18] <ubitux> such that for a 0-100 range, we would have a common behaviour between codec
[15:19] <ubitux> 0-100 would scale on 0-5 for fdk-aac, 0-10 for libvorbis (invert if necessary), a similar thing for libmp3lame etc
[15:21] <durandal_1707> ubitux: what are you doing?
[15:22] <ubitux> wondering
[15:22] <cone-1> ffmpeg.git 03Martin Storsjö 07master:d8798276b655: r3d: Add more input value validation
[15:22] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:f657ca0d0b3b: Merge commit 'd8798276b65543d921adadf63cc7f5ba2d1604af'
[15:29] <cone-1> ffmpeg.git 03Luca Barbato 07master:e5d45e028cf4: build: Support cparser
[15:29] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:2be92abac7f3: Merge commit 'e5d45e028cf4193b562075897e55091779e49f15'
[15:36] <cone-1> ffmpeg.git 03Martin Storsjö 07master:b97b1adb3f80: rtmpproto: Add a comment explaining the logic in handle_notify
[15:36] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:391e272c1637: Merge commit 'b97b1adb3f807e1acd00d56319ee6cb41cc727e4'
[15:45] <cone-1> ffmpeg.git 03Martin Storsjö 07master:a9d50bb578ec: dcadec: Validate the lfe parameter
[15:45] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:8c320b3c0831: Merge commit 'a9d50bb578ec04c085a25f1e023f75e0e4499d5e'
[15:50] <cone-1> ffmpeg.git 03Luca Barbato 07master:5532ee6d7d55: rtmp: Unbreak get_packet
[15:50] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:dda7bd13b349: Merge commit '5532ee6d7d554bb54d4374d0b69f72bc9ab9fd91'
[16:00] <durandal_1707> wm4_: i'm writting ladspa wrapper
[16:01] <wm4_> nice
[16:02] <cone-1> ffmpeg.git 03Alex Smith 07master:09f2581dc5ed: msvc/icl: Use __declspec(deprecated)
[16:02] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:e1f74ad1f010: Merge commit '09f2581dc5edb3642858d69d9a70b67e249167e9'
[16:09] <cone-1> ffmpeg.git 03Alex Smith 07master:33b88f2a4ae5: msvc/icl: Use __declspec(noinline)
[16:09] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:8377b2b6bfa3: Merge commit '33b88f2a4ae54d5397c45e39a5326289ebdc7747'
[16:30] <cone-1> ffmpeg.git 03Vittorio Giovara 07master:1cad7171dd68: h264: remove an unused static constant
[16:30] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:bed611f937cf: Merge remote-tracking branch 'qatar/master'
[17:38] <TimNich> ubitux: thanks
[17:41] <durandal11707> what happened?
[17:44] <ubitux> I/O flood from bogdanp
[17:44] <ubitux> not the first time it happens btw
[19:52] <durandal_1707> saste: you have wrote ladspa plugin for lavfi?
[19:56] <Compn> why is russia making a great firewall like china did ?
[20:03] <durandal_1707> actually it was written by Mina but never got into tree
[20:12] <wm4_> durandal_1707: why? because wrappers are evil?
[20:13] <durandal_1707> wm4_: nah probably because it never worked correctly
[20:58] <ubitux> fuck those dvd subtitles FFS
[20:58] <wm4_> heh
[20:59] <wm4_> fuck DVD
[21:00] <ubitux> so the idea is that some subtitles bitmaps are split into smaller packets
[21:01] <ubitux> but sometimes, there is not only one bitmap but multiple exploded ones into one chunk
[21:01] <ubitux> and so you have different sizes, the one for each chunk, and the total one
[21:01] <ubitux> but those sometimes mismatch
[21:01] <ubitux> but that's not all, since the vobsub (.idx) file also specify offset
[21:02] <wm4_> ah, yes, I remember something about this, and mplayer's spu decoder and lavc's dvdsub decoder accepting different packets forms
[21:02] <ubitux> you can use them to split these chunks
[21:02] <ubitux> but of course, they don't match either sometimes
[21:02] <ubitux> so you actually never know where to cut
[21:02] <ubitux> that's so fucking braindead
[21:02] <ubitux> sometimes you have something like 10 sub chunk
[21:03] <ubitux> to finally have 3 final sizes that mismatch
[21:03] <ubitux> and you just don't know which one to pick
[21:03] <ubitux> that's so fucking braindead
[21:03] <wm4_> yeah, that does sound terrible...
[21:04] <durandal_1707> i cant set filter options dynamically?
[21:04] <durandal_1707> this would be awesome for wrappers....
[21:05] <wm4_> an additional API that can set options at runtime would be nice
[21:06] <wm4_> maybe it couldn't use the current avoption api, because you can't notify or reject changes
[21:13] <ubitux> nice, remuxing a .ts with subtitles with ffmpeg break them
[21:50] Action: ubitux look for the shigoku shoujo homepage in order to curse the author of dvdsubs & vobsubs
[21:51] <JEEB> s/shi/ji/
[21:52] <JEEB> (0Ds)
[21:53] <ubitux> JEEB: oups :)
[21:56] <wm4> man that ticket
[22:09] <ubitux> wm4: it's better to have vobsub packets getting out interleaved by stream, right?
[22:09] <ubitux> i'm wondering about changing, but that doesn't sound like a good idea
[22:09] <wm4> well yes, we expect stuff interleaved
[22:09] <wm4> maybe _I_ can deal with non-interleaved, not sure
[22:10] <wm4> but in general it seems like a bad idea
[22:10] <ubitux> i'm wondering why it's not interleaved in dvd
[22:10] <ubitux> (and if that's actually always the case...)
[22:39] <rcombs> can anyone help me deal with a software package that's distributing modified FFmpeg binaries without providing source, in violation of LGPL/GPL?
[22:41] <durandal_1707> rcombs: did you reported it to but tracker?
[22:41] <rcombs> no; is that where that should be done?
[22:42] <durandal_1707> i guess so, others violators are there too
[22:42] <rcombs> in this case, it's Plex Media Server
[22:43] <rcombs> the project head seems to think he doesn't need to provide source, and I'm not sure what leads him to believe that
[22:43] <rcombs> welp, I'll type up a report
[22:44] <rcombs> right now, it's mostly that I want to look through the source and try to fix a particular bug, but I can't because it's not public
[22:47] <j0sh> isn't xbmc gpl anyway? (which plex is apparently based off)
[22:48] <cone-816> ffmpeg.git 03James Almer 07master:39442b1a1b22: matroskaenc: Add CuePoints for subtitle tracks
[22:48] <rcombs> j0sh: Plex Media Server is separate
[22:48] <rcombs> j0sh: the Home Theatre code is available online, as it's a fork of XBMC
[22:49] <rcombs> but the media server uses ffmpeg for transcoding, and doesn't provide sources anywhere
[22:49] <nevcairiel> you're free to submit a report, but thats usually where it ends, short of some  potential bad press that this could maybe generate, there is unlikely anything else going to happen
[22:50] <rcombs> I'd really just like someone from the dev team to tell Elan (Plex's main guy) that yes, he does have to make the source available
[22:51] <ubitux> we need someone to verbally assault those people
[22:51] <ubitux> and eventually start the legal course
[22:52] <rcombs> they used to also include libfaac, but then someone told them they can't do that and they stopped
[22:55] <rcombs> https://trac.ffmpeg.org/ticket/2974
[22:55] <rcombs> if it includes libx264, then it's GPL, not LGPL, right?
[22:55] <nevcairiel> yes
[22:56] Action: rcombs found a bug in fflogger
[22:56] <rcombs> my nick on track is 11rcombs, not 1rcombs :/
[22:56] Action: rcombs marks issue as "thoroughly unimportant"
[22:56] <ubitux> it's important
[22:56] <nevcairiel> so thats why your name is green
[22:56] <nevcairiel> the first one went into the color code :p
[22:56] <ubitux> :D
[22:57] <rcombs> heh
[22:57] <rcombs> that's& interesting
[22:57] <rcombs> I guess it should zero-pad to 2 digits, then?
[22:58] <nevcairiel> i dont really remember how these color codes worked
[22:59] Action: rcombs probably has standing for a lawsuit that's not worthwhile, as he's purchased Plex-related services from them
[23:01] <rcombs> ah, *here* we go
[23:01] <rcombs> it appears there was a series of miscommunications here
[23:02] <rcombs> they'll provide me with the code; it just doesn't say anywhere on their site that they'll do so, nor does it include a copy of the GPL
[23:02] <rcombs> which means it's still a violation; just not quite as bad, I guess?
[23:02] <ubitux> j-b: can we use videolan to help fixing those legal issues?
[23:03] <nevcairiel> i dont think they have to provide the source on the website or even mention it, as long as they provide it on request
[23:03] <nevcairiel> a notice that it uses GPL components is required though, with a link to the license at least
[23:04] <j-b> ubitux: no idea what legal issues you are referring to, but yes
[23:05] <j-b> ubitux: whom do you want me to kill?
[23:05] <ubitux> j-b: https://trac.ffmpeg.org/ticket/2974 this one for instance, assuming they refuse to provide the source
[23:05] <j-b> Plex
[23:05] <j-b> NICE
[23:06] <ubitux> mmmh i just realized the logo is pretty close to brazzers' one
[23:06] <j-b> good bunch of assholes, IIRC
[23:06] <rcombs> it looks like they'll provide the source; they just don't mention that fact (which is still a violation)
[23:06] <ubitux> rcombs: ask them, confirm they do
[23:06] <ubitux> and post the source in the ticket
[23:07] Action: rcombs is in the process of doing that
[23:07] <ubitux> also, make sure you ask them after each release
[23:07] <ubitux> when they get bored of sending it to you, maybe they will provide a download link
[23:08] <rcombs> nevcairiel: it requires a written offer to provide the source
[23:08] Action: rcombs has just been reading over the relevant GPL bits
[23:08] <j-b> maybe they have a good DLNA server :)
[23:09] <rcombs> I've used the DLNA feature now and then; it's decent
[23:09] <rcombs> I want to know how they're doing SSA font rendering
[23:10] <ubitux> libass?
[23:10] <rcombs> because when they do live-transcoding with their modified ffmpeg with an SSA track selected for burning, the renderer uses the fonts attached to the MKV
[23:10] <rcombs> and ffmpeg's ssa filter doesn't do that
[23:11] <ubitux> i guess they do it like any player
[23:14] <rcombs> yeah, but FFmpeg doesn't have that builtin, and I'd like to upstream that
[23:15] <nevcairiel> i wouldnt be surprised if they do that outside of ffmpeg
[23:15] <nevcairiel> (i would)
[23:17] <rcombs> it's definitely done within the transcoder binary
[23:20] <rcombs> hmm, if I'm parsing the GPL correctly, they need to provide sources for the entire media server because the transcoder is distributed as part of it, not as a separate product
[23:21] <cone-816> ffmpeg.git 03Michael Niedermayer 07master:fcd64dcc374e: avformat/avienc: remove unused variable
[23:21] <cone-816> ffmpeg.git 03Michael Niedermayer 07master:15672e832f47: avformat/utils: remove unused variable
[23:34] <wm4> loading fonts from a video filter would be pretty involved...
[23:35] <wm4> muxed fonts, I mean
[23:38] <rcombs> yeah
[00:00] --- Sat Sep 21 2013


More information about the Ffmpeg-devel-irc mailing list