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

[burek]

[00:21] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:59a479283020: avcodec/libutvideodec: Support YUV422P10
[03:16] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:4ef02ddd8188: Changelog: add entry for libutvideo 422P10
[03:16] <cone-692> ffmpeg.git 03Vittorio Giovara 07master:ac84c1ce24a2: avfilter: check filter link validity
[03:16] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:1945db1f1307: Merge commit 'ac84c1ce24a285f9cf16d4297bce73b1c4a6e435'
[03:34] <cone-692> ffmpeg.git 03Vittorio Giovara 07master:1967cd4e4c1c: audiointerleave: check av_new_packet return value
[03:34] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:6d2a2bfb59f8: Merge commit '1967cd4e4c1cd96dfa195ce14e4b212ddb70586d'
[03:44] <cone-692> ffmpeg.git 03Vittorio Giovara 07master:f1ed83e23add: img2dec: check av_new_packet return value
[03:44] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:d6095662706d: Merge commit 'f1ed83e23add1c26c50b146727e4c2399dfc0b3a'
[04:15] <cone-692> ffmpeg.git 03Vittorio Giovara 07master:0b66fb4505e0: flac_picture: prevent a possible out of bound write
[04:15] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:af89c144181f: Merge commit '0b66fb4505e0bb43de3797f63f3290f0188d67cc'
[04:30] <cone-692> ffmpeg.git 03Luca Barbato 07master:7785ce1c7693: lavf: replace rename() with ff_rename()
[04:30] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:97a8f4dd119e: Merge commit '7785ce1c769369abf85b276148548a5510aabb5f'
[04:35] <cone-692> ffmpeg.git 03Vittorio Giovara 07master:3c1199c3c4cb: matroskadec: fix leak on error
[04:35] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:45fd5935313b: Merge commit '3c1199c3c4cbdb4ffff0de89f06d5a08acefe356'
[04:43] <cone-692> ffmpeg.git 03Vittorio Giovara 07master:e0caa1eb4e51: matroskadec: check return values
[04:43] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:3ae818f6ab04: Merge commit 'e0caa1eb4e518111a81801db0d2ccdd2733ba94b'
[04:51] <cone-692> ffmpeg.git 03Vittorio Giovara 07master:28c020d4df9b: matroskaenc: check avio_open_dyn_buf return value
[04:51] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:8be93ba049f1: Merge commit '28c020d4df9b060a58a124a7a5406d4313fbe249'
[04:53] <cone-692> ffmpeg.git 03Vittorio Giovara 07master:ad6b00d85f68: mxfdec: add missing break
[04:53] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:5408d8828a75: Merge commit 'ad6b00d85f686324aa2bd93e39261fa1d411f141'
[04:56] <cone-692> ffmpeg.git 03Tomas Härdin 07master:7df3b426bbfb: mxfenc: Fix possible integer overflows
[04:56] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:48579041bae5: Merge commit '7df3b426bbfbd7efd9a0f56393e3cc78413b0869'
[05:28] <cone-692> ffmpeg.git 03Vittorio Giovara 07master:50dbe6b3544f: mov: fix assigment check
[05:29] <cone-692> ffmpeg.git 03Michael Niedermayer 07master:eeb9242b623c: Merge commit '50dbe6b3544fa64d5611e16553bf542fd71276b8'
[10:53] <ubitux> what's about all this bikesheding about the v4l2 & /dev/video probing?
[10:54] <ubitux> the patch looks just fine...
[10:56] <wm4> ubitux: I think it's evil, btw., reminds me of image2
[10:56] <ubitux> what's the problem?
[11:01] <wm4> ubitux: it shouldn't interpret the URL in magic ways
[11:07] <arwa> Hey, I am really getting confused with the hqx code...!! I dont know how to convert rgb to yuv without float :/
[11:10] <wm4> why are floats suddenly evil, anyway?
[11:11] <wm4> just because of the bitexact issue?
[11:11] <nevcairiel> rgb to yuv is something you can do perfectly fine in integer anyway
[11:12] <arwa> How do I do that with integers? Can you give me a link?
[11:34] <J_Darnley> I seem to recall that ubitux gave you a commit to see how its done.
[11:43] Action: michaelni wonders how many people who ask a question and leave before getting a reply do read the log
[11:52] <J_Darnley> oh, I didn't even notice that
[13:40] <cone-669> ffmpeg.git 03Michael Niedermayer 07master:92d366f6abf8: avformat: Print error message on failure of ff_rename()
[13:40] <cone-669> ffmpeg.git 03Michael Niedermayer 07master:2fc970a6b845: cmdutils: Read errno before av_log() as the callback from av_log() might affect errno
[13:40] <cone-669> ffmpeg.git 03Michael Niedermayer 07master:dd5c2fe17727: avcodec: Read errno before av_log() as the callback from av_log() might affect errno
[13:40] <cone-669> ffmpeg.git 03Michael Niedermayer 07master:a63096953559: avdeviece: Read errno before av_log() as the callback from av_log() might affect errno
[13:40] <cone-669> ffmpeg.git 03Michael Niedermayer 07master:0d96d44c4fa5: avfilter: Read errno before av_log() as the callback from av_log() might affect errno
[13:40] <cone-669> ffmpeg.git 03Michael Niedermayer 07master:af03ba9aa205: avformat/hdsenc: Read errno before av_log() as the callback from av_log() might affect errno
[14:23] <cehoyos> ubitux: Sorry if I misunderstood your question, but I really don't know why it makes a difference if pullup is used...
[14:23] <ubitux> well
[14:23] <ubitux> what if you disable all the pts manipulations in decimate?
[14:24] <ubitux> it looks like to me that the main difference is pullup completely ignoring the pts part
[14:26] <ubitux> if you just comment out the frame->pts assignment in vf_decimate, i'm pretty sure you'll get similar result as in pullup
[14:28] <ubitux> but i dunno
[14:29] <ubitux> anyway fieldmatch/decimate needs some look by someone more used to telecined content than i
[14:29] <ubitux> i didn't get much feedback on it
[14:36] <cehoyos> But without the pts assignment, you cannot keep A/V sync, or do I misremember?
[14:37] <ubitux> how does pullup deal with that?
[14:37] <ubitux> i see no pts changes in it
[14:41] <cehoyos> As said, I don't know.
[14:42] <Compn> have to ask dalias , the mplayer deinterlacer dev :P
[14:42] <ubitux> it would be better to understand this before we document it
[14:42] <cehoyos> Actually, I do:
[14:43] <cehoyos> pullup removes one frames of five if it finds a telecined sequence, or leaves all frames in place if it doesn't find such a sequence.
[14:43] <cehoyos> You have to use -r 24000/1001 to drop the remaining telecined frames (or actually a random frame of five) whenever pullup misses a frame.
[14:43] <cehoyos> misses a telecined frame.
[14:44] <ubitux> alright
[14:44] <ubitux> well then
[14:44] <ubitux> remove the pts adjustment from decimate
[14:44] <ubitux> and use -r just like with pullup
[14:44] <ubitux> assuming -r does a better job at it
[14:44] <ubitux> but i doubt it does
[14:44] <cehoyos> As I tried to write on -devel this works fine from a A/V sync pov, it of course leaves teleconed frames behind (becuase the detections is not so good / faster).
[14:45] <cehoyos> It cannot afair.
[14:45] <cehoyos> Remember that -r does nothing as long as the filter works (both for progressive and telecined input)
[14:46] <ubitux> doesn't it adjust the pts of the frames going out?
[14:46] <cehoyos> While fieldmatch outputs cfr iirc, no? So frames have to be dropped
[14:46] <ubitux> fieldmatch doesn't do anything to pts
[14:46] <cehoyos> This adjustment makes sense, I meant it neither drops nor duplicates in the good case while it would have to with fieldmatch but cannot decide.
[14:47] <ubitux> it just merge fields, and decimate is here to drop the dups
[14:47] <ubitux> but decimate also "fix" the pts to output cfr
[14:50] <ubitux> for N frames in, fieldmatch will output N frames, without touching their timing
[14:50] <ubitux> the only thing it does is making sure each frame going out has a better matching field
[14:51] <ubitux> but this creates dups, which the decimate filter is here to drop
[14:51] <ubitux> and since it drops some frame, it takes the responsibility to fix the timing in a cfr way
[14:51] <ubitux> if you think a -r will make a better job at it, just remove the timing adjustment from decimate
[14:51] <ubitux> and you'll get a similar behaviour
[14:59] <cehoyos> But doesn't decimate even drop a frame (of five) if the pts indicate it should not?
[15:00] <cehoyos> Isn't this how the issue can be fixed ("once and for all")?
[15:01] <cehoyos> I just removed the pts setting from decimate and tested with progressive input:
[15:02] <cehoyos> It still drops frames when it shouldn't.
[15:03] <cehoyos> I also tested with fps=30000/1001,fieldmatch,decimate and it drops the wrong frames (when it should drop frames)
[15:05] <cehoyos> And sorry for misremembering how fieldmatch works: My explanation above was of course very wrong.
[15:14] <ubitux> cehoyos: decimate drops based on the content, it doesn't care about the pts
[15:25] <cehoyos> This doesn't work for fps=30000/1001,decimate with 23.9 fps input - it should drop the duplicated frame but drops a random one afaict.
[15:27] <ubitux> yes, if it finds no dup it just drop a "random" one
[15:28] <ubitux> decimate could benefit some real improvements
[15:29] <cehoyos> So without knowing the internals I suspect two possible solutions: Either detect on pts that the input switched framerate and do not drop anything (the "perfect" solution) or search harder for duplicates (with or without additional options).
[15:29] <cehoyos> (MPlayer prints a message whenever the framerate switches from 24->30 or from 30>24 frames)
[15:30] <cehoyos> And my patch is of course bad, it appears I mixed up issues, I will look at it again.
[16:26] <michaelni> BBB, is "[FFmpeg-devel] [PATCH] avformat/rdt: Forward whitelists to rdt demuxer" ok ? (with ff_copy_whitelists())
[16:39] <cone-669> ffmpeg.git 03Michael Niedermayer 07master:e7513e1286ca: avformat: Read errno before av_log() as the callback from av_log() might affect errno
[16:39] <cone-669> ffmpeg.git 03Michael Niedermayer 07master:39a7ded22df3: tools/ffhash: read errno before calling functions which might change it
[16:39] <cone-669> ffmpeg.git 03Michael Niedermayer 07master:2ce10542570d: avformat/rtpdec_asf: Use av_find_input_format() instead of directly linking to the demuxer
[16:39] <cone-669> ffmpeg.git 03Michael Niedermayer 07master:ff03df647570: avformat/mpeg: Use av_find_input_format() instead of directly linking to the demuxer
[17:08] <cone-669> ffmpeg.git 03Christophe Gisquet 07master:eacf2e8eb35c: dv: better split weight tables assignment
[17:08] <cone-669> ffmpeg.git 03Christophe Gisquet 07master:80b29c2d0c0b: dv: use smaller type for weight tables
[18:58] <arwa> what does git log do??
[19:04] <J_Darnley> Shows you the commit history
[19:04] <wm4> google it
[19:04] <J_Darnley> also git help log
[19:05] <ubitux> or just run it
[19:06] Action: J_Darnley thought that being familiar with git was one of the requirements
[19:13] <arwa> I ran it
[19:14] <arwa> Does it show the history of commits done on my patch?
[19:14] <arwa> or in general?
[19:16] <wm4> you should try to find out such simple things yourself (that's part of the job)
[19:17] <wm4> we can answer such question, but doing that all of the time wouldn't be appropriate
[19:22] <arwa> okay :)
[19:28] <iive> arwa: if you want your patches to be always on top, you may want to do updates by `git pull --rebase`
[19:31] <arwa> okay thanks :D
[19:31] <wm4> iive: that's not what she asked, also git rebase is one of the best ways to shoot yourself into the foot
[19:32] <iive> yes. that happens too :)
[19:51] <cone-669> ffmpeg.git 03Christophe Gisquet 07master:1086f09da30c: dv: more precise weight table for 8x8
[19:51] <jamrial> git rebase is fairly safe and far from a pain if you skip adding stuff like changelog/apichanges/version.h until the very end
[19:54] <wm4> how often did I make unintended changes or lost changes due to resolving conflicts while rebasing...
[20:08] <cone-669> ffmpeg.git 03Lukasz Marek 07master:1cff9085898c: doc/fftools-common-opts: document -devices option
[20:21] <cone-669> ffmpeg.git 03Lukasz Marek 07master:5f5581985020: opts: add list device sources/sinks options
[20:22] <arwa> Can anyone tell me what should I infer from "stand alone function - moving code into a shared function"? I am not getting its meaning :/
[20:45] <liquidmetal> I'm having some trouble with http://dranger.com/ffmpeg/tutorial05.html
[20:45] <liquidmetal> Fetching the PTS for every frame
[20:46] <liquidmetal> The issue is, the video seems to have a pFormatCtx->stream->time_base of 1/90000
[20:46] <liquidmetal> However the framerate is 30/1
[20:46] <liquidmetal> I'm not sure how/why that happened
[20:46] <liquidmetal> Am I doing something wrong/
[20:47] <wm4> frame rate doesn't have to happen the time base
[20:47] <wm4> in fact, the frame rate ffmpeg reports should be treated as random value
[20:47] <wm4> because it's almost never accurate
[20:47] <liquidmetal> So 1/90000 is accurate?
[20:48] <JEEB> it's the time base of the container
[20:48] <nevcairiel> thats a pretty common value for TS files
[20:48] <liquidmetal> I quick search reported that apparently mp4/avi don't support those kinds of values
[20:48] <liquidmetal> okay
[20:48] <JEEB> mp4 has a timebase and pts just fine :P
[20:48] <JEEB> avi is set to a specific frame rate, yes. so you would have it as the timebase I guess?
[20:49] <JEEB> of course at one point before when AVI was relatively used you could have 120/1.001fps AVI files because those could accomodate 24/1.001 , 30/1.001 as well as 60/1.001
[20:49] <JEEB> and then you had "frames" there without any data (aka null frames)
[20:50] <liquidmetal> okay then, my major concern was 1/90000 seemed like a wrong number
[20:50] <liquidmetal> I'll dig further
[20:50] <JEEB> that's the mpeg-ts timebase
[20:51] <JEEB> the data packets will then have a timestamp within that timebase
[20:52] <BBB> michaelni: I dont know what whitelists are, but otherwise it was ok
[20:54] <wm4> liquidmetal: also note that these tutorials are quite outdated
[20:54] <wm4> liquidmetal: they encourage broken things
[20:55] <wm4> BBB: they are a security feature... to exclude all codecs but some whitelisted ones
[20:55] <BBB> just compile them out
[20:55] <BBB> am I that old-fashioned?
[20:55] <liquidmetal> wm4, yes - I'm looking at the API changes doc to figure out how it works with the new version
[20:55] <wm4> liquidmetal: e.g. look at this terrible get_buffer crap... this is absolutely NOT needed just to get the PTS
[20:56] <wm4> BBB: mini can't be convinced of that
[20:56] <liquidmetal> wm4, so how is it done now?
[20:56] <wm4> liquidmetal: AVFrame has the packet fields (reordered)
[20:56] <iive> wm4: who is mini?
[20:59] <michaelni> wm4, is that trolling really needed ? compiling them out is of course better but some distros dont "allow/want" binaries to exit multiple times but want them rather shared
[20:59] <michaelni> i mean the reasoning was mentioned multiple times
[21:00] <liquidmetal> wm4, pkt_pts? I quickly tried that - it seems to be working! Thanks!
[21:01] <wm4> michaelni: how is that trolling... also I reject that reasoning; if distros want to allow unsafe codecs, so be it
[21:03] <BBB> I dont quite see how it helps, yes
[21:03] <BBB> apps like chrome just want their own ffmpeg, codecs isnt the only reason
[21:04] <BBB> I doubt theyll agree whitelisting is the right way to get chrome and vlc/mplayer to share the same ffmpeg binary/lib in debian
[21:05] <BBB> but anyway, if someone finds it useful Im not against it
[21:05] <michaelni> chrome like apps and distros arent the only use case, a simple player like vlc also might want to restrict the codecs&demuxers for remote urls
[21:05] <wm4> it's less bad than the previous option (allowing to register only some codecs to the global codecs list)
[21:06] <wm4> sometimes I think ffmpeg should just disable all these potentially-unsafe rarely used fringe codecs by default
[21:07] <wm4> why does ffmpeg need to be able to decode Descent 2 movies by default? (decoding of them is broken, too)
[21:07] <BBB> because mike REed the codec 15 years ago
[21:07] <j-b> because mike ROCKS :)
[21:07] <BBB> (or paul, or whoever)
[21:07] <BBB> hi j-b
[21:08] <j-b> hi :)
[21:20] <michaelni> also players may want to restrict what formats & codecs can be in a url thats intended for the flash player, theres alot that can be disabled for that without any lost functionality
[21:20] <michaelni> and it should improve security
[21:22] <michaelni> same for any other player or spec spefific urls
[21:22] <wm4> michaelni: one problem I see is with the propagation of those whitelists
[21:22] <wm4> there are a lot of places that may open codecs or parsers or formats
[21:23] <michaelni> wm4, thats what i meant by that they are fragile
[21:23] <michaelni> still its better than nothing
[21:27] <Compn> it cannot hurt much, so good idea
[21:27] <cone-669> ffmpeg.git 03Michael Niedermayer 07master:13ee94a480e8: avformat/rdt: Forward whitelists to rdt demuxer
[21:28] <wm4> Compn: it can create a false sense of security
[21:28] <wm4> at one point, we're also going to have passthrough av_log state (since having a global callback is unacceptable)
[21:29] <wm4> maybe there should be some semi-global state for all those things? i.e. not really global, but the user has to pass it to all sub-libraries when opening contexts
[21:32] <Compn> its a layer of security, which i'm assuming you can agree on
[21:34] <Compn> do you think we could measure all of the values of each const or struct and then set a range of reasonable asserts for each variable? 
[21:35] <Compn> so height = range of 2 to 24000 , width = range of 2 to 24000 , slice size = range of 0 to 20000000, etc
[21:36] <Compn> and if we come across samples that dont fit in the ranges (set by our samples collection and other private collections) we ask for samples or tell user to run with -i-am-secure-play-the-file-already
[21:38] <Compn> or would that be a false sense of security, since fuzzing could still be done and find crashes
[21:52] <michaelni> posted a patch which fixes the issue with forgotten to be set whitelists
[22:57] <cone-669> ffmpeg.git 03Thilo Borgmann 07master:a6555f88aaf0: lavd/avfoundation: Add support for screen capturing.
[23:21] <BBB> Compn: lets not go there& history is so full of this should be enough for everybody integer values
[23:27] <cone-669> ffmpeg.git 03Mark Reid 07master:90bf1e304600: libavformat/mxfdec: read source timecode from pulldown component
[00:00] --- Sun Oct 26 2014