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

[burek]

[04:52] <troy_s> michaelni: Got the one up.
[04:53] <troy_s> michaelni: Going to test the second again. My values are theoretically ideal floats. Poynton's have the (rather silly) multiplied versions.
[04:53] <troy_s> michaelni: Needless to say, I want to test to be certain.
[05:03] <ogrgkyle> hello
[05:03] <ogrgkyle> anyone use rtmpdump?
[05:34] <michaelni> troy_s, the bug you reported is about +-1 differences, that is for all we know it might be a difference in the rounding
[05:35] <troy_s> michaelni: Absolutely. I'm a little more concerned about the full range version.
[05:35] <michaelni> but what you post says no word about the rounding
[05:35] <troy_s> michaelni: Because I have no clue where the deviation is coming from.
[05:35] <michaelni> deviation to what ?
[05:35] <troy_s> michaelni: To the theoretical.
[05:35] <troy_s> (As in proper via a calc, then rounded.)
[05:36] <michaelni> you will not get the same rounding between fixed and floating point implementations normaly
[05:36] <michaelni> noone does rgb <->ycbcr in float
[05:38] <michaelni> not to mention why would float be better
[05:38] <troy_s> michaelni: Well float is pretty typical in most industrial imagers, and most use matrices to calc the YCbCr. So it isn't a stretch.
[05:38] <troy_s> michaelni: Just keeps the quantization errors to a minimum up to the round.
[05:39] <michaelni> everyone with a brain used fixed point
[05:39] <troy_s> michaelni: Two different design sets of needs.
[05:39] <michaelni> the need is to have no brain ?
[05:39] <troy_s> The reality of needing performance for a playback situation versus the need for accuracy for image extraction.
[05:39] <troy_s> LOL
[05:39] <michaelni> float is less accurate
[05:39] <michaelni> for this
[05:39] <troy_s> Not 32 bit float.
[05:39] <michaelni> than 32bit fixed point would be
[05:40] <troy_s> (Which is again where all industrial imagers live.)
[05:40] <troy_s> Does the intermediate depth sit fixed in FF?
[05:40] <troy_s> Or is it based on various context?
[05:41] <troy_s> (And really, this ultimatley boils down to quantization errors and the variance between input to output on a round trip. That's probably the best baseline we can have.)
[05:43] <michaelni> what intermediate depth ?, the one in the matrix multiply? see the code
[05:43] <michaelni> i mean we move 100% in circles here none of these questions move us forward
[05:44] <troy_s> Well the deviations are large enough to impact the round trip as they stand.
[05:45] <troy_s> If there is a clean way to improve them, it might be worth exploring. (Assuming we can get a round trip down clean.)
[05:45] <michaelni> troy_s, if you have a testcase that shows any of this please provide that testcase
[05:45] <troy_s> I've shown the variance between the theoretical and the output. If we assume we see two sets of that (one for an encode, one for a decode) I think it is pretty safe that the round trip will be off.
[05:46] <troy_s> (And there's no real reason it should at 444 full range.)
[05:46] <troy_s> Fair point?
[05:47] <michaelni> troy_s, ive asked since days for a testcase and you provided nothing solid
[05:47] <troy_s> I have the PNG!
[05:47] <troy_s> That's the test. That's direct dumps of the channels.
[05:47] <troy_s> I'm not sure I can do any better within the limited realm of my understanding.
[05:47] <michaelni> you made the PNG
[05:47] <troy_s> (Entirely plausible I'm a dimwit however and missing the goal here.)
[05:48] <troy_s> I generated one off of a 32 bit float reference EXR, and generated an 8 bit equivalent with rounded values.
[05:48] <troy_s> I also generated the raw YCbCr out of ffmpeg and dumped those channels into a PNG as well.
[05:49] <troy_s> So we have theoretical and ffmpeg, and the deviation tells us that we are already drifting in some manner, which is not really plausible given 8 bit 444 at full range.
[05:49] <michaelni> if you say that the roundtrip is suboptimal then a testcase is to show that rgb24-> ycbcr24 -> rgb24 is worse than it could be, iam sure it is but to fix it we need a testcase
[05:50] <troy_s> michaelni: Although you can help on the re-encode version - what is the correct syntax for an encode from raw YCbCr ("yuv" in ffmpeg's busted phrasing) to an RGB output using the scale flags?
[05:50] <troy_s> Ok.
[05:50] <troy_s> So I need that command (in terms of the best knowledge, of which I am quite certain you are the highest qualified expert to answer)
[05:51] <troy_s> (I can conduct the round trips painlessly to and fro using the math and other tools, but not ffmpeg.)
[05:51] <troy_s> (And to be fair to ffmpeg, the studio range dump only shows errors inthe gradient, which is rather impressive, but still i think we can aim higher.)
[05:52] <troy_s> (And apologies for seeming pedantic on this, but the only way we can move onward to tackling the codec level is to assert with 100% certainty that the transforms are as accurate as they possibly can be.)
[05:52] <michaelni> troy_s, IMHO your reference is very far away from optimal output
[05:53] <michaelni> round to nearest is not optimal, you would need some dither or noise shaping
[05:53] <michaelni> and iam just assuming you did round to nearest, i think you never stated that
[05:54] <michaelni> also which was x+0.5 is rounded is also something that might differ
[05:55] <michaelni> do the specs even say how to round? or what precission the coefficients should have ?
[05:56] <troy_s> michaelni: I took a round to nearest because that's the RGB image.
[05:56] <troy_s> We don't want to futz the round trip, so dither would make no sense.
[05:56] <troy_s> (Certainly for perceptual or something, but not in this context.)
[05:57] <troy_s> michaelni: The coefficients can go as deep as one wishes.
[05:57] <troy_s> (Based off of the white point and primaries, you can take it to as far as is required. In some instances, deeper can hold the integrity of the data where needed.)
[05:58] <troy_s> (and yes, regarding the offset for full range, the theoretical is directly in the middle of the Cb or Cr axis, which is 0.5. I've got an email to Poynton on that subject coincidentally. Shall see how he responds, but all of his literature suggests the theoretical.)
[05:59] <troy_s> I think the most logical baseline is that if we encode an 8 bit sRGB image, and round trip it through 444 full range YCbCr, we should expect 1:1 back as an ideal.
[06:00] <michaelni> troy_s, no
[06:00] <troy_s> ?
[06:00] <troy_s> That's a pretty reasonable baseline.
[06:00] <troy_s> Example, encoding to ProRes from a master
[06:00] <troy_s> or DNxHD.
[06:00] <troy_s> Very reasonable.
[06:01] <troy_s> Suggesting that there is a necessary degredation of image quality at equivalent models and depths (eg 8 bit RGB at 444 YCbCr 8 bit) is reasonable.
[06:01] <troy_s> (The extreme edge cases of quantization aside.)
[06:01] <troy_s> (Not sure what the theoretical count of those is, but I'm guessing it is extremely slight if any.)
[06:02] <troy_s> (And should diminish as we increase our bit depths.)
[06:03] <troy_s> Do you happen to know the single frame encode from rawvideo in ffmpeg?
[06:03] <michaelni> troy_s, you have 2^24 RGB values but they are mapped on fewer than that ycbcr values as not the whole 2^24 cube of ycbcr 444 values is used thus its not possible to be 1:1
[06:03] <troy_s> (Using the newer scale commands)
[06:03] <troy_s> Again, that's the edge of quantization.
[06:03] <troy_s> Given that I can get a perfect 1:1 using outside tools passing to ffmpeg to encode
[06:03] <troy_s> I'm thinking it's pretty reasonable. :)
[06:04] <michaelni> troy_s, talking with you is hard as you use very odd terminology
[06:04] <michaelni> at least for me
[06:04] <troy_s> Apologies.
[06:05] <troy_s> The mapping is indeed different, but we are talking some very minute adjustments. We can't even get to the encode though.
[06:05] <michaelni> of course if you mutiply a matrix by its inverse you get the original but not when you quantize to 8bit in the middle
[06:05] <troy_s> I'm doing all of this as an 8 bit stop.
[06:05] <troy_s> (in the middle)
[06:05] <troy_s> but I still need to know ffmpeg's single frame encode syntax from the rawvideo format.
[06:05] <troy_s> Then I can do the conclusive end comparison.
[06:06] <troy_s> (Which I've already done comparing against the source RGB)
[06:06] <troy_s> (Using again, different tools to perform the transform.)
[06:08] <michaelni> troy_s, google and our docs explain how to use ffmpeg, its 6o clock in the morning, i need to sleep, also iam sure others can explain how to encode a image from a video with ffmpeg
[06:08] <troy_s> Okie. I've searched high and low and none have the new scale syntax.
[06:08] <troy_s> (Hence why I'm asking.)
[06:08] <troy_s> but get some sleep.
[06:08] <troy_s> We can chat tomororw.
[06:09] <michaelni> what is "new scale syntax" and how is that related to your question about "single frame encode syntax from the rawvideo format."
[06:10] <troy_s> -vf scale="in_range/out_range/in_color_matrix/out_color_matrix"
[06:11] <troy_s> That's the syntax I'm using for encodes, so I want to be sure the identical code paths are crossed.
[06:12] <troy_s> michaelni: Sleep.
[06:12] <troy_s> Night.
[06:12] <troy_s> (It can wait until tomorrow.)
[06:51] <ersatzbeardr> hum am i rgiht in thinking i could set up an ffmpeg worker with libav's filter graph and fire data straight out of my rasterizer (another machine) across zmq into the worker
[11:17] <sspiff> Hi! I have a problem with dvb subtitle decoding. The spec states that if no Display Definition segment is present, the subtitle should be assumed to be rendered at 720x576 and upscaled accordingly.
[11:18] <sspiff> However, the subtitle resolution is not something that FFMpeg exposes, and ffplay doesn't upscale the subtitles in a sample I have that expects this (standard) behavior
[11:19] <sspiff> Currently, I plan on working around this by accessing the private data in the AVCodecContext and determining if a DDS is present or not, but this is not the best solution I can imagine.
[11:19] <sspiff> However, I suppose that exposing this kind of information in a generic way requires some reworking in the AVSubtitle API
[13:00] <Mavrik> sspiff, yes, I doubt TS input currently parses DDS
[13:00] <Mavrik> but so far on all broadcasted streams I've encountered, persuming that DVB subitltes are PAL works well
[13:08] <sspiff> Mavrik, a client of ours is apparently muxing Chinese and Korean subtitles as a DVB subtitle PID into an HD signal, and the subtitles are not correctly upscaled.
[13:09] <sspiff> If you want, I can send you a capture.
[13:10] <Mavrik> hmm, possibly
[13:10] <sspiff> the dvbsubdec.c parses the DDS, not the TS demuxer or dvbsub parser.
[13:10] <Mavrik> well, sending me capture really won't accomplish anything :)
[15:06] <jeffreylevesque> I updated my Ubuntu 11.04 to Ubuntu 14.04.  I couldn't install ffmpeg as the system suggested me to install avconv
[15:08] <jeffreylevesque> could someone assist me with the equivalent code in 'avconv' - https://github.com/jeff1evesque/audio-analyzer/issues/357
[15:08] <sacarasc> Read that, also the avconv channel is #libav.
[15:29] <drwx> hi, i pressed a key or something and ffmpeg outputs tons of messages like this: http://sprunge.us/HdgN how can i stop it?
[15:37] <sfan5> you enabled verbose logging
[15:38] <sfan5> try pressing d
[18:31] <drwx> thanks sfan5, where is that documented?
[18:37] <diegoviola> hi
[18:37] <diegoviola> will ffmpeg replace libav in Debian?
[18:47] <sfan5> drwx: pressing ? while encoding shows the help
[18:47] <sfan5> diegoviola: I'd suggest asking the debian maintainers about that
[18:47] <diegoviola> ok thanks
[19:00] <sythe> So, why does it seem like ffmpeg is ultra fast compared to video editors?
[19:00] <sythe> (when encoding)
[19:01] <sythe> Regardless of how few edits are made to a video
[19:02] <sacarasc> sythe: If you run ffmpeg without any commands, it will tell you.
[19:02] <sythe> Hyper fast
[19:02] <sythe> HEh
[19:02] <sythe> *heh
[19:03] <sythe> Does Kdenlive use ffmpeg?
[22:56] <invintus> I would like to find a way to use a reference video to copy it's codec settings for a transcode. convert a.mp4 to b.mp4 using c.mp4's codec settings
[22:57] <Mavrik> Unless the encoder wrote it's settings into the video... you're doing something that needs trial and error.
[22:59] <llogan> also re-using certain settings such as bitrate on a completely different video is usually not recommended.
[23:01] <invintus> as I have the workflow laid out (no code written yet) if the video container does not have enough info. i just convert it to x settings.. the reason for this is to create consistency for video that needs to be edited then concatenated.
[23:02] <llogan> you can use ffprobe to get info about a video
[23:02] <invintus> I was just hoping for a more elegant way to use a refrenece video for the settings
[23:02] <llogan> https://trac.ffmpeg.org/wiki/FFprobeTips
[23:03] <invintus> thanks. already down the ffprobe parsing rabbit whole.
[23:03] <llogan> there is no option in ffmpeg to look at a video and attempt to re-use whatever settings were used to encode it. not that all of them are possible to know.
[23:04] <Mavrik> also, using CRF for example in x264 will keep constant quality, which is probably what you want for intermediate representation
[23:04] <invintus> I just thought I would ask since it already does something similar to the input video with -vcodec copy ect..
[23:05] <llogan> that is to stream copy (re-mux). to me it seemed like you wanted to re-encode
[23:07] <llogan> if you need to re-encode for whatever reason (for the editor comaptibility?), and want to edit the output, then a lossless intermediate may be the way to go. depending on your editor that may be using the encoders: utvideo, huffyuv, libx264 (lossless mode), ffv1, among a few others
[23:07] <invintus> i do need to re-encode. The first video that someone uploads, I need to convert each successive video as close to the original as possible so the concatenation works. otherwise I have to do concat another more painful way
[23:07] <llogan> sound like you plan on using the concat demuxer
[23:08] <llogan> concat filter may be a better option
[23:08] <llogan> but you'll have to experiment
[23:08] <invintus> I am using now, realizing that my own probe parsing is not getting close to whats needed for consistency for the reset of the clips
[23:08] <Mavrik> yep that sounds like the usecase for concat filter.
[23:09] <Mavrik> you do know ffprobe has JSON and other types of outputs to ease parsing? :)
[23:09] <invintus> Yeah I am using -pretty and the json
[23:09] <llogan> it means that the original will also be re-encoded, but big deal, it's probably worth the tradeoff of being (possibly) easier to implement and likely to provide a more "stable" output
[23:09] <invintus> right now I am using the concat with just a list of files, I think i need to use the filter diffrently
[23:10] <invintus> agreed
[23:11] <invintus> thanks folks! off to hours of debugging.. :)
[23:11] <llogan> come back if you need help building the filter_complex
[23:12] <invintus> Oh i will hehe.. I went the easy road. now here i am at your good graces.
[23:18] <sine0_> hi
[23:18] <sine0_> ok. 14.04 amd64. whats my best skype solution
[23:19] <sine0_> wehoops
[23:19] <sine0_> wrong channel lol
[00:00] --- Wed Jul 30 2014