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

[burek]

[00:08] <cone-191> ffmpeg.git 03Hendrik Leppkes 07b87ff3449662: vc1: implement vc1 field interlaced dxva2 decoding * 03http://tinyurl.com/8wlpu6r03
[00:08] <cone-191> ffmpeg.git 03Hendrik Leppkes 0733f2a4942380: vc1: only disable interlaced b-frames for software decoding * 03http://tinyurl.com/8lgvq8703
[00:33] <ubitux> saste: i have a strange issue with lavfi device and ffprobe, which is not reproducible with ffmpeg & ffplay
[00:33] <ubitux> interested? :)
[00:34] <saste> ubitux, what?
[00:34] <saste> and don't forget to file a bug report, if you don't plan to work on it
[00:34] <ubitux> i kind of try to understand it at the moment
[00:34] <ubitux> i'm doing ./ffprobe -f lavfi -i 'amovie=input.mp3,ebur128=video=1 [out0][out1]'  -show_frames
[00:35] <ubitux> it stops immediately without error
[00:35] <ubitux> av_read_frame() is returning an "invalid argument" err code
[00:35] <ubitux> (coming from the request frame thing)
[00:36] <saste> what if you remove ebur?
[00:36] <ubitux> works fine
[00:37] <ubitux> actually even a split & showwaves works
[00:37] <ubitux> so maybe i miss something in the filter
[00:37] <ubitux> but since it works fine with ffplay & ffmpeg..
[00:37] <saste> ubitux: gdb...
[00:37] Action: ubitux prefers random av_log debugs
[00:38] <saste> may be related to internal caching
[00:38] <ubitux> i was just asking in case you may have an idea
[00:48] <ubitux> saste: yes, the fifo looks empty
[00:49] <saste> uhm...
[00:52] <ubitux> it looks like the main difference with ffplay is that ffplay just doesn't care and continue to read frame anyway
[00:55] <saste> ubitux: and ffmpeg?
[00:55] <ubitux> ffmpeg has no issue either
[00:55] <saste> and yes i remember that i saw a similar error
[00:55] <saste> why not?
[00:56] <ubitux> mmh maybe it has..
[00:56] <ubitux> heh it has an explicit error
[00:58] <ubitux> well, i'll see later©
[00:58] <ubitux> 'night
[00:58] <ubitux> saste: tomorrow is your last chance to comment on the lavfi metadata btw ;)
[00:58] Action: ubitux &
[00:59] <saste> ubitux, are you waiting for reviews?
[01:00] <saste> what about the issue spotted by nicolas?
[01:00] <saste> anyway give some time, i'll try to review tomorrow
[01:00] <saste> if not feel free to push it
[01:37] <durandal_1707> seeking in he-aac-v2 have problems
[02:02] <cone-191> ffmpeg.git 03Hendrik Leppkes 07953a3dcc4e28: Mark data symbols shared between libraries with av_export * 03http://tinyurl.com/8qq2auf03
[02:02] <cone-191> ffmpeg.git 03Hendrik Leppkes 0704bf2e7f0e9c: swresample: include ff_log2_tab for shared builds * 03http://tinyurl.com/9x793yo03
[02:03] <ramiro> hi
[02:08] <durandal_1707> hi
[03:06] <michaelni> hi ramiro 
[03:06] <michaelni> do you want a coverity account ?
[11:31] <cone-120> ffmpeg.git 03Stefano Sabatini 076d6ccbae4cee: examples/decoding_encoding: add missing checks on avcodec_alloc_context3() * 03http://tinyurl.com/8sfr9n703
[11:31] <cone-120> ffmpeg.git 03Stefano Sabatini 078c4753f7f5f1: examples/decoding_encoding: remove misplaced and confusing comment * 03http://tinyurl.com/8l6ardw03
[11:31] <cone-120> ffmpeg.git 03Stefano Sabatini 077b116a94af99: examples/decoding_encoding: fix misc typos in the usage text * 03http://tinyurl.com/9ju6pws03
[12:12] <cone-120> ffmpeg.git 03Stefano Sabatini 071cd9c81ddb31: lavc/utils: extend feedback provided by avcodec_open2() * 03http://tinyurl.com/8sq24yg03
[12:12] <cone-120> ffmpeg.git 03Stefano Sabatini 077bc533c41b40: lavc/utils: fix a few case/punctuation inconsistencies in avcodec_open2() * 03http://tinyurl.com/8z2cs5c03
[12:12] <cone-120> ffmpeg.git 03Stefano Sabatini 07935ecfb00238: examples/scaling_video: remove unnecessary intermediary variable in fill_yuv_frame() * 03http://tinyurl.com/9aq6tmf03
[12:22] <cone-120> ffmpeg.git 03Stefano Sabatini 07cdea54b4c8cd: lavu/parseutils: rework rational reduction logic in av_parse_ratio() * 03http://tinyurl.com/9bs83ga03
[12:43] <cone-120> ffmpeg.git 03Michael Niedermayer 076bcdfe48d0d0: mpeg4videodec: Disable frame multithreading for GMC, its not implemented at all * 03http://tinyurl.com/9tgkg7k03
[12:43] <cone-120> ffmpeg.git 03Diego Biurrun 07c896aa984e88: build: Drop OBJS declaration for non-existing PCM_DVD encoder * 03http://tinyurl.com/9quocpn03
[12:43] <cone-120> ffmpeg.git 03Diego Biurrun 078fb1e2640505: lzo: Drop obsolete fast_memcpy reference * 03http://tinyurl.com/8nucuew03
[12:43] <cone-120> ffmpeg.git 03Diego Biurrun 074b587848ce03: configure: Disable Snow decoder and encoder by default * 03http://tinyurl.com/96m9mnq03
[12:43] <cone-120> ffmpeg.git 03Martin Storsjö 0712549db6535c: fate: Add proper dependencies for the tests in video.mak * 03http://tinyurl.com/9qdyr6303
[12:43] <cone-120> ffmpeg.git 03Hendrik Leppkes 07d2d08d706b8f: gitignore: ignore files created by msvc * 03http://tinyurl.com/8ncnbsc03
[12:43] <cone-120> ffmpeg.git 03Martin Storsjö 072f41eaa9c6b5: rtsp: Make sure the ret variable is initialized in ff_rtsp_fetch_packet * 03http://tinyurl.com/9hcvvju03
[12:43] <cone-120> ffmpeg.git 03Mans Rullgard 071846ddf0a787: ARM: fix overreads in neon h264 chroma mc * 03http://tinyurl.com/8ft4fht03
[12:43] <cone-120> ffmpeg.git 03Mans Rullgard 07c9ef43215c7d: fate-vc1: add dependencies * 03http://tinyurl.com/9zy67nl03
[12:43] <cone-120> ffmpeg.git 03Michael Niedermayer 0704c6ecb7da67: Merge commit 'c9ef43215c7d68c2cdcdbe02287aa114f27a32ed' * 03http://tinyurl.com/98b3o8m03
[13:30] <cone-120> ffmpeg.git 03Diego Biurrun 07c08536979be1: avutil/lzo: K&R formatting cosmetics * 03http://tinyurl.com/8pyva9y03
[13:30] <cone-120> ffmpeg.git 03Diego Biurrun 075532cf317838: avutil/mem: K&R formatting cosmetics * 03http://tinyurl.com/9audojc03
[13:30] <cone-120> ffmpeg.git 03Diego Biurrun 0779042ab37619: configure: Group math functions into a separate variable * 03http://tinyurl.com/966qcpy03
[13:30] <cone-120> ffmpeg.git 03Michael Niedermayer 076912e7a008ac: Merge remote-tracking branch 'qatar/master' * 03http://tinyurl.com/9cs2zuz03
[14:05] <cone-120> ffmpeg.git 03Michael Niedermayer 07bf52ad1e49d3: lavc: revert broken hunk from 1cd9c81ddb317ca00061d11d3562d3a34888d91b * 03http://tinyurl.com/9xw3wbu03
[14:41] <ubitux> <@saste> what about the issue spotted by nicolas? // i fixed it and sent a new version
[17:03] <Compn> oh no! bsd fail!
[17:03] <Compn> :P
[19:39] <durandal_1707> ping for lvf
[20:25] <durandal_1707> same_quant should be put back
[20:28] Action: michaelni is wondering where cone went ...
[20:29] <michaelni> j-b, is cone ok, she didnt report the last few commits ?
[20:29] <JEEB> durandal_1707, even though it didn't work as it even was supposed to in the first place, and even if most damn users were misusing it?
[20:29] <JEEB> it's like wtf
[20:30] <JEEB> if it's put back
[20:30] <JEEB> it was the most misused option ever
[20:30] <JEEB> I think it even set quants to zero for a long time now instead of copying them
[20:30] <durandal_1707> but there is guy, look above ffloger post, that is using it and it is useful to him
[20:31] <JEEB> it's not useful for him, he just thinks it's the proper damn option
[20:31] <JEEB> and I'm pretty sure he wasn't getting the same quants
[20:31] <JEEB> also he could just use a low enough quant with the setting
[20:35] <ubitux> didn't we add a dummy sameq/same_quant option displaying a warning?
[20:35] <durandal_1707> yep
[20:35] <JEEB> durandal_1707, not to mention that sameq IIRC would just give random results if the input format was different from the output one
[20:36] <JEEB> I really don't see why sameq would have to be brought back to life
[20:36] <durandal_1707> it just hack to be used with mpeg2?
[20:36] <JEEB> ...
[20:37] <JEEB> it was a hacked that used to be used for development of something or another to copy the quants of the same format input to the output. It has for all I know not worked for a relatively long amount of time and most of its users are thinking it's "same quality".
[20:37] <JEEB> the first sentence already tells you why with MPEG-4 Part 2 -> MPEG-2 you shouldn't be using it
[20:38] <JEEB> it was probably just setting a low enough quant there /by chance/
[20:38] <durandal_1707> omg
[20:38] <JEEB> he would have better and more predictable results by just using a certain low enough quant instead
[20:40] <ubitux> saste: well, i don't know how that buffering is supposed to work; i'll likely open an issue soon :(
[20:40] <ubitux> (the lavfi device issue)
[20:44] <ubitux> wtf some of my mails didn't reach ffmpeg-devel.. ?
[20:45] <ubitux> arg again i replied in private..
[20:53] <JEEB> someone please copypasta what I said on the trac on that sameq issue or someone might actually end up putting it back >_>
[20:53] <michaelni> one could fix the issues and then put it back
[20:54] <JEEB> why? I understand it's a usable setting for development, but in this case it was different formats to begin with
[20:54] <cbsrobot> JEEB: http://ffmpeg.org/trac/ffmpeg/wiki/Option%20%27-sameq%27%20does%20NOT%20mean%20%27same%20quality%27
[20:54] <JEEB> he was depending on (most probably broken) utility
[20:54] <JEEB> cbsrobot, and why am I getting that linked to me?
[20:55] <cbsrobot> well it's already a subject on trac
[20:55] <cbsrobot> we could also just point the ticket to the page
[20:56] <JEEB> which doesn't mention what I noted
[20:56] Action: cbsrobot reads it again
[20:56] <JEEB> "...that used to be used for development of something or another to copy the quants of the same format input to the output...."
[20:56] <JEEB> the guy on trac wants it for MPEG-4 Part 2 -> MPEG-2
[20:56] <JEEB> IMHO it'd be better to just set a low'ish quant or something
[21:00] <cbsrobot> This option actually means "same quantizers" and should only be used to copy the quants from the input to the output of the same format (f.ex. mpeg2 -> mpeg2).
[21:02] <durandal_1707> JEEB: what option should he use instead?
[21:03] <JEEB> <JEEB> he would have better and more predictable results by just using a certain low enough quant instead
[21:11] <saste> but we should at least warn the user
[21:11] <saste> just dropping an option like this overnight is bad
[21:12] <durandal_1707> saste: option is ignored
[21:12] <saste> also, aren't there some proper use of the option?
[21:13] <JEEB> yes, but I haven't seen it used in the last few years
[21:13] <saste> copy quantization coefficients may make sense when one is transcoding+filtering and re-encoding to the same codec
[21:14] <JEEB> personally I'm just happy a setting that has caused so much herp and derp is no longer there, and I don't think re-adding it for some development work would be much work if someone becomes to have a need for it during development
[21:14] <JEEB> (although I've heard it didn't work in the end for a relatively long time, just setting some low'ish quants)
[21:15] <durandal_1707> transcoders are evil
[21:17] <saste> fb722a900fc5cc9e003b9fef25b27ed7fc5547a2
[21:17] <saste> i can agree on the rationale, but breaking API should be avoided
[21:17] <saste> anyway maybe it should *fail* rather than print a warning
[21:18] <durandal_1707> saste: than revert michaelni commit
[21:20] <saste> ahah it was even mentioned in the FAQ
[21:20] <saste> no wonder people were misusing it
[21:20] <saste> i misused it as well
[21:21] <durandal_1707> wait....
[21:21] <saste> that's because people looks for a magic option - keep same quality
[21:21] <Compn> should just make ffmpeg -magic ....
[21:22] <saste> having to set a quantization parameter is not that user-friendly (you have to get a clue about what the quantizer is in the first place)
[21:22] <saste> Compn: ffmpeg -dwim
[21:23] <Compn> ffmpeg -thatfilterfromavisynth-daemonkeepstalkingabout
[21:23] <michaelni> ffmpeg `cat /dev/brain`
[21:23] Action: Daemon404 has been hilighted
[21:23] <Daemon404> michaelni, do you happen to know sort of input the mpeg2video decoder expects?
[21:24] <Daemon404> im passing it a gop offset in a mpeg2 PS
[21:24] <Daemon404> and its... -sorta- working
[21:24] <Daemon404> [15:21] <@Daemon404> http://i.imgur.com/20jJm.png
[21:24] <Daemon404> [15:21] <@Daemon404> ^ output luma
[21:24] <Daemon404> [15:21] <@Daemon404> doesnt look quite right ;)
[21:24] <Daemon404> e.g. i i know teh offset of a GOP in an mpeg2 ps file, and i read in from that offset, and pass to avcodec
[21:24] <saste> but the thing is that -sameq sometimes seemed to work
[21:25] <saste> at least it was better that no option at all
[21:25] <saste> so the question is, why was it working?
[21:25] <michaelni> Daemon404, the decoder expects MPEG-ES video frames
[21:25] <Daemon404> michaelni, im not -that- fimiliar with mpeg-ps
[21:25] <Daemon404> but should a gop offset point to mpeg-es frams?
[21:25] <Daemon404> shoudlnt*
[21:26] <michaelni> what is a "gop offset" ?
[21:26] <Daemon404> sec
[21:26] <Daemon404> http://neuron2.net/dgmpgdec/DGIndexManual.html#AppendixA
[21:26] <Daemon404> the "position" marker
[21:27] <Daemon404> "The position field is a decimal number that points to the byte position in the source file at which decoding of the indexed I picture should begin."
[21:27] <saste> ugh i was wrong, there was no API break (no lavc option was removed)
[21:28] <saste> michaelni, what about to fail rather than printing a warning in case of -sameq?
[21:28] <michaelni> Daemon404, a I-Picture can be split in many lets call them chunks at the PS level
[21:29] <michaelni> or more precissely, MPEG-ES frames get concatenated and then randomly choped in a series of bytes
[21:29] <michaelni> then headers added and interleaved with audio then more crap added and you have MPEG-PS
[21:29] <saste> and direct the user towards some option which may achieve the same effect
[21:30] <Daemon404> i see
[21:30] <michaelni> saste, theres no option that achives the same effect currently
[21:32] <saste> michaelni, mention something about quality options?
[21:32] <saste> there are so many of them
[21:32] Action: saste feels like we need a proper manual for the lavc options
[21:33] <michaelni> the most fitting would probably to mention that the user should select a bitrate similar to the input
[21:33] <michaelni> but if people want this option so much we should think about fixing it and putting it back
[21:33] <Daemon404> michaelni, is there anything tangible i can do with libavcodec given these "gop offsets"
[21:33] <michaelni> convert the quality between formats and all that 
[21:34] <michaelni> (if i understand correctly what they are) you can use them as seed for our random number generator
[21:34] <Daemon404> <.<
[21:35] <saste> michaelni, I have no clue about how -sameq was working, but it was quite hackish
[21:35] <Daemon404> it wasnt working
[21:35] <saste> it was *somehow* working in some cases
[21:35] Action: Daemon404 thinks it was a coincidence
[21:36] <michaelni> the problem with sameq was that it was written 10 years ago and not maintained since then 
[21:36] <michaelni> or something like that :)
[21:36] <JEEB> yes
[21:36] <JEEB> I hear it had been broken for a /long/ time
[21:36] <JEEB> and just used some zero/low quant
[21:39] <Daemon404> michaelni, so given those offsets, is there a way to get it into an mpeg-es format easily?
[21:39] <saste> JEEB: allright, it was copying the quality param of the input decoded frame, and putting it in the encoded frame
[21:40] <saste> that info was possibly used by the encoder
[21:40] <michaelni> Daemon404, if you have a MPEG-PS file you need to run it through a demuxer that produces ES frames
[21:40] <michaelni> or a ES stream which you can feed through a AVParser
[21:40] <saste> from avcodec.h: quality (between 1 (good) and FF_LAMBDA_MAX (bad))
[21:41] <Daemon404> michaelni, i may only access the ps at those offsets
[21:41] <Daemon404> and start reading from there
[21:41] <Daemon404> i dont know if avparser can handle that
[21:41] <Daemon404> i.e. i am NOT using libavformat
[21:41] <Daemon404> to open the ps
[21:41] <nevcairiel> if there is PS headers in the middle of the coded frames, the parser wont remove those
[21:41] <saste>  FF_LAMBDA_MAX (256*128-1) defined in avutil.h
[21:41] <nevcairiel> you may need to write some magic to do that
[21:42] <Daemon404> nevcairiel, its certainly possible
[21:42] <Daemon404> every d2v related filter in existence has done it
[21:42] <saste> in general it seems like something related to some specific codec, so I agree it doesn't make much sense to rely on that option
[21:42] <saste> i suppose it was working more or less when transcoding from MPEG-family-codec to MPEG-family-codec
[21:42] <nevcairiel> its not like PS parsing is that complicated
[21:43] <Daemon404> nevcairiel, yeah but i have no idea how?
[21:43] <nevcairiel> i never looked at PS much. i could tell you how to deal with TS :)
[21:44] <Daemon404> ;p
[21:44] <Daemon404> im am readign dgdecode's source
[21:44] <Daemon404> pity me
[21:44] <michaelni> Daemon404, if it is PS you could try to feed it through libavformats PS demuxer
[21:45] <Daemon404> mmm maybe
[21:45] <Daemon404> this code is lol...
[21:45] <Daemon404> 	// If the D2V filename has _P just before the extension, force
[21:45] <Daemon404> 	// progressive upsampling.
[21:45] <Daemon404> surely this cannot be a bad idea...
[21:50] <Daemon404> heh.. can lavf even open a buffer
[21:50] <Daemon404> or does it only take filenames...
[21:50] <nevcairiel> you can feed it buffers, but need to give it a custom avio context
[21:51] <Daemon404> what func?
[22:04] <Daemon404> wtf is the ps demuxer called
[22:04] <Daemon404> there isnt a mpegps
[22:05] <michaelni> its called "mpeg"
[22:06] <michaelni> ff_mpegps_demuxer ... name= "mpeg"
[22:07] <Daemon404> i see this now...
[22:11] <durandal_1707> is mkv streaming actually supported?
[22:18] <ubitux> mpf. i need to introduce another side data thing
[22:18] <ubitux> (codec srt -> codec subrip)
[22:19] <michaelni> ubitux, btw make sure all the metadata stuff gets fate tests so it is all regularly tested
[22:20] <ubitux> mmh
[22:20] <michaelni> could easily break with noone noticing otherwise
[22:20] <ubitux> maybe i should add a ffprobe test indeed
[22:20] <Daemon404> aha.. works!
[22:21] <ubitux> michaelni: do you have a video fate sample in mind with 2-3 scene changes?
[22:22] <michaelni> no but one could run a scene detect filter over all the samples to find a good candidate
[22:22] <michaelni> small file low resolution is probably preferable
[22:22] <michaelni> so its faster
[22:22] <ubitux> yep
[22:23] <ubitux> i need to find a sample with silence too
[22:28] <ubitux> michaelni: any other comment btw?
[22:29] <michaelni> ubitux, didnt really look at the latest patch yet
[22:29] <michaelni> just wanted to point that fate thing out ...
[22:30] <ubitux> yes, good point :p
[22:48] <ubitux> meh side data doesn't get transmitted
[22:51] <ubitux> (with subtitles)
[22:57] <ubitux> oh it's because ffmpeg isn't reusing the decoded subtitle&
[23:03] <ubitux> rha the subtitles api really is completely out of time :D
[23:15] <ubitux> seems related to AVFMT_FLAG_KEEP_SIDE_DATA
[23:15] <ubitux> what's this side data merge thing?
[23:20] <ubitux> michaelni: av_packet_merge_side_data() in lavf/utils.c:ff_read_packet is trashing the side data set in the subtitle demuxer
[23:20] <ubitux> any idea why?
[23:22] <michaelni> no
[23:23] <ubitux> :(
[23:30] <durandal_1707> j
[23:30] <ubitux> oh ok the function is moving the side data at the end of the pkt data... huh.
[23:31] Action: ubitux doesn't get the point
[23:32] Action: ubitux doesn't get how that's supposed to work
[23:33] <durandal_1707> is there nice way to read null terminated string from avio?
[23:33] <michaelni> ubitux, the point is that older user apps do not preserve side data but just the main data between lavf and lavc
[23:34] <michaelni> its easy to disable the merging if its unwanted
[23:34] <ubitux> yes with keepside option
[23:34] <ubitux> but&
[23:34] <ubitux> how is the side data supposed to be restored?
[23:34] <michaelni> magic :)
[23:35] <ubitux> oh indeed the magic thing 
[23:35] <ubitux> FF_MERGE_MARKER? :p
[23:35] <michaelni> av_packet_split_side_data()
[23:36] <ubitux> yeah ok
[23:36] <ubitux> so i'm supposed to get the data back
[23:37] <ubitux> and that function is called only for audio & video, ok, get it.
[23:37] <ubitux> thank you :)
[23:37] <michaelni> ahh uhm, i forgot adding that for subtitles ? ^^;;
[23:37] <ubitux> seems so :p
[23:43] <durandal_1707> i forgot name of function that reads string up to NULL or X chars whatever comes first
[23:44] <ubitux> something like bprint + a avio_r8() loop?
[23:45] <ubitux> ff_get_line maybe
[23:45] <ubitux> libavformat/aviobuf.c:int ff_get_line(AVIOContext *s, char *buf, int maxlen)
[23:46] <ubitux> michaelni: could we simply disable it for subtitle btw?
[23:47] <ubitux> since no subtitle use side data at the moment, the "old user app" should not need it, right?
[23:47] <ubitux> (assuming the subtitles side data are always optional)
[23:47] <ubitux> do you plan to keep the split side data thing indefinitely btw?
[23:48] <durandal_1707> ubitux: actually i need it in lavc
[23:48] <ubitux> durandal_1707: i'd be interested in a bprint version of ff_get_line btw
[23:48] <ubitux> too bad :p
[23:48] <ubitux> want a bytestream_get_line? :)
[23:49] <durandal_1707> avio_get_str(utf8) variant for lavc
[23:49] <j-b> good morning
[23:50] <durandal_1707> j-b: good midnight
[23:50] <michaelni> ubitux, we could but that would be inconsistent
[23:54] <durandal_1707> i will use strnlen
[00:00] --- Sun Oct 21 2012