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

[burek]

[00:03] <BBB> positions in yuv file of first mismatch for a variety of cases I've just looked at: 3365648, 3386080, 3370736 - this is all frame 29.something, so it's always the same frame that fails. so now I just pick any of these, make sure the first $thatnumber+a few bytes are identical between the file and the one I'm tracking, and I'm good to go for printf debugging (cmp -n number file.yuv ref.yuv)
[00:04] <ubitux> BBB: that stuff sounds relevant for your blog btw
[00:05] <matthewjheaney_> @ubitix: I just pushed up the 1st of 2 patches
[00:06] <BBB> I could blog about it I guess... I don't blog very much though
[00:06] <BBB> let me try to fix it and then blog about the fixc
[00:09] <BBB> darn it it refuses to fail now :) 4.4k runs
[00:10] <BBB> maybe I shouldn't play youtube
[00:39] <Compn> j-b : i got a report from a user that mplayer doesnt run on mavericks either.
[00:40] <Compn> but he wouldnt tell me what version of mplayer he was using
[01:03] <BBB> ubitux: so the faulty mb for the case I'm tracking (3370736 first mismatch) is frame 29 (counting from zero as first, not counting invisible frames - ARFs), mb_x=11, mb_y=6
[01:04] <BBB> then print data pre and post loopfilter at that mb until you get the mismatch we're tracking, then you know if it's b/c of loopfilter or not
[01:04] <BBB> then backtrace from there
[01:04] <BBB> I'm betting it's not loopfilter but better be sure
[01:44] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:bcb42fb6dbef: sonic: use av_calloc()
[01:44] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:4ec7ef56bd03: sonic: simplify quant cliping
[01:44] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:730e07f10b97: sonic: avoid float sqrt() for integer input & output
[05:36] <BBB> ubitux: ah found it
[05:36] <BBB> somebody broke segmentation
[05:36] <BBB> that was relatively easy
[05:36] <BBB> let me do like 100k runs or so and make sure it works now
[12:20] <khali> saste: thanks for reviewing my delogo patch, I'll benchmark it in the afternoon and reply as soon as I have the numbers
[12:57] <cone-758> ffmpeg.git 03Luca Barbato 07master:1e340af8d6a9: avconv: drop additional strerror fallback
[12:57] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:d894e64acca9: Merge commit '1e340af8d6a97cc013a2ad8ba77c77129625a34f'
[13:01] <cone-758> ffmpeg.git 03Luca Barbato 07master:42cc6cefd315: avconv: report the error for codec open failure
[13:01] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:cc61ef0479f0: Merge commit '42cc6cefd315c1556e2a52f7ebe2f766ec82b790'
[13:46] <cone-758> ffmpeg.git 03Luca Barbato 07master:f963f701d90b: ogg: relax demuxer conformance checks
[13:46] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:780b1aa1efa8: Merge commit 'f963f701d90bd7bb03e39aab4e59bd137084e082'
[13:51] <cone-758> ffmpeg.git 03Alex Smith 07master:f11e4045b9c4: configure: More msvc/icl combining
[13:51] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:fb0df5c113e0: Merge remote-tracking branch 'qatar/master'
[14:29] <ubitux> matthewjheaney_: can you send the second one so i can push them?
[14:29] <ubitux> BBB: cool, thx :)
[16:49] <BBB> nobody review my patch :(
[16:57] <BBB> ubitux: go review my patch!
[17:02] <ubitux> BBB: you realize i never contributed to anything vpx related, right? :P
[17:02] <ubitux> my biggest implications in it was encoding a video in webm, and sending you an email
[17:17] <BBB> ubitux: I don't think anyone else here is particularly better suited to review any patch at all
[17:17] <BBB> ubitux: I could review it, but I already wrote it so it defeats the 4eye rule
[17:18] Action: ubitux feels like naming random people to run away
[17:18] <ubitux> well, i can have a look, but that will likely be a superficial review just to make you feel better
[17:19] <ubitux> OTOH i can spend some quite time on it, which i might not have right now
[17:19] <BBB> if only you worked for a company that cared about opensource software to such an extend that you could spend reasonable time on making it better, right?
[17:20] <ubitux> i have no job right now, no company is taking my time
[17:20] <BBB> how do you not have time then?
[17:20] <ubitux> i'm just busy with my own stuff
[17:20] <BBB> ok :)
[17:20] <michaelni> BBB the patch looks ok
[17:20] <BBB> ah review :)
[17:20] <BBB> thanks
[17:21] <michaelni> should i apply or do you want to apply it ?
[17:21] <BBB> you apply is easier
[17:21] <BBB> I'm mostly used to gerrit nowadays
[17:21] <wm4> ubitux: so you remember that libavcodec subtitle converters throw away the "decoded" text if it's not valid utf-8, right?
[17:21] <cone-758> ffmpeg.git 03Ronald S. Bultje 07master:c329713de7c6: vp8: wait for prev_frame to parse segment_map before reading it.
[17:22] <wm4> ubitux: I think it's ridiculous... it leads to the situation subtitle events that happen to contain badly encoded stuff are ignored, while others are displayed normally
[17:22] <ubitux> wm4: i don't like it either, as i said in the thread
[17:22] <wm4> ubitux: and considering how often this kind of stuff happens, like english subs that contain a badly encoded accent in _some_ events
[17:23] <ubitux> i just couldn't come with a relevant argument at that time, so i let Nicolas do what he prefered
[17:23] <wm4> ubitux: I'd say it's really damn offensive to the user
[17:23] <wm4> ubitux: however printing a warning would be perfectly fine
[17:23] <ubitux> i agree
[17:23] <ubitux> a patch should be trivial; can you send one (as a RFC eventually) explaining the issue you have?
[17:24] <wm4> ok
[17:24] <ubitux> thank you
[17:24] <wm4> I have some more question
[17:24] <ubitux> wm4: keep in mind the main argument was to prevent creating invalid files
[17:24] <wm4> so some subtitle formats are framebased - but the user can't know, the libavformat chooses a random FPS?
[17:24] <wm4> well, even video formats have error recovery
[17:25] <ubitux> yes, and i think you can just force a frame rate in the demuxer
[17:25] <wm4> I noticed that the aqtitles demuxer has a subfps option, but microdvd has not
[17:25] <wm4> and it'd be nicer if the application could take care of rescaling the times
[17:25] <ubitux> does it work if you set the input frame rate?
[17:26] <wm4> picking a random timebase is nice too, as long as the application knows it's a frame based format and the timebase is arbitrary
[17:26] <ubitux> also, with microdvd you can make it contain the fps in the first even or something like that
[17:26] <wm4> how do I set the input frame rate?
[17:26] <ubitux> ("{0}{0}25.000 FPS" or sth like that)
[17:26] <wm4> oh yeah, like in MicroDVD_capability_tester.sub
[17:26] <ubitux> wm4: with the API, dunno
[17:26] <wm4> but it seems it's displaying that text for 40 seconds
[17:26] <ubitux> how does ffmpeg does it when you -r as input option?
[17:27] <ubitux> check if ffmpeg -r 25 -i in.sub out.sub works
[17:27] <ubitux> (i never tried)
[17:27] <wm4> "{0}{}25.000 FPS" is converted to "Dialogue: 0,0:00:00.00,0:00:40.00,Default,25.000 FPS"
[17:28] <ubitux> yes, {} means "up to the next event"
[17:28] <ubitux> maybe we could add a special case
[17:28] <wm4> also ffmpeg just overwrote my test file
[17:28] <wm4> what
[17:28] <ubitux> nasty ffmpeg is nasty
[17:28] <wm4> ffmpeg -r -i file
[17:29] <wm4> oops
[17:29] <ubitux> hehe
[17:29] <wm4> for microdvd -r doesn't change anything
[17:29] <wm4> tried with MicroDVD_capability_tester.sub
[17:30] <ubitux> mmh
[17:32] <wm4> what's needed is a flag that says that the format is frame based and no FPS was specified in the file header
[17:32] <ubitux> there is clearly something to do here
[17:32] <wm4> and then it either needs to use frames as timebase, or a random fall back FPS that is known to the application
[17:33] <ubitux> yes well
[17:33] <ubitux> i need to know how the -r as input can me transmitted to the demuxer, if that's possible
[17:34] <wm4> -r is not good
[17:34] <wm4> it affects normal video as well right?
[17:34] <ubitux> there is no video in a standalone .sub
[17:35] <ubitux> or any frame count subtitles format
[17:35] <wm4> it would require the application to set -r conditionally based on whether the format is a frame based subtitle, or anything else
[17:35] <ubitux> (and that sounds better than the -subfps option...)
[17:35] <wm4> not all your users are ffmpeg...
[17:35] <ubitux> we can *also* add a flag
[17:36] <ubitux> but imo the first step is to make the demuxer access that frame rate information
[17:36] <ubitux> and the way -r seems to work looks appropriate
[17:40] <wm4> ubitux: btw. what I want to do is setting sub fps to video fps, like MPlayer does
[17:40] <ubitux> yes i understood
[17:40] <wm4> and doing that after loading the files is most convenient
[17:41] <ubitux> after? how could we allow you to do that easily?
[17:42] <wm4> basically, it's subtitle_time = frame_number * video_fps / fallback_sub_fps;
[17:43] <wm4> which is done if the video fps is known, and fallback_sub_fps is known to be an actual fallback
[17:44] <wm4> and where frame_number is the raw subtitle PTS
[18:14] <BBB> maybe I'll start writing the initial portions of a vp9 bitstream parser this week, that would be useful
[18:15] <BBB> and can't really be done in parallel anyway, so from there we can all take different directions
[19:35] <wm4> ubitux: also I have many failures and glitches with a real world .smi sample... should I send it to you?
[19:39] <durandal_1707> no, remove it from internet
[20:27] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:db27dadcb05a: sonic: replace divide() by ROUNDED_DIV()
[20:27] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:69d0a2922f76: sonic: cleanup/simplify num_taps check
[20:27] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:9375f5003d02: sonic: use av_freep() as its safer than av_free()
[20:31] <durandal_1707> michaelni: sonic actually compress/decompress losslessly?
[20:38] <michaelni> durandal_1707, sonicls should
[20:43] <durandal_1707> in what container it can be saved?
[20:44] <durandal_1707> anyway its doesn't encode losslessly here, is slower than flac and produce 2x times bigger files
[20:46] <durandal_1707> also its based on bonk, which is hilarious
[21:18] <michaelni> durandal_1707, if its not lossless for you then open a ticket
[21:26] <durandal_1707> no point
[21:27] <durandal_1707> if you do not plan to rewrite it completely that ignore it and do not waste time on touching it
[22:04] <durandal_1707> does anyone have 16/24bit float pcm wavs?
[22:59] <nevcairiel> 24 bit float? never heard of such a contraption
[23:40] <wm4> hm id3v2 can't be written without seeking?
[23:41] <durandal_1707> it could...
[23:42] <wm4> I ha the idea that shoutcast metadata could be convert to id3v2 on the fly (though that still sounds like a hack)
[23:43] <durandal_1707> indeed
[23:53] <BBB> I don't think 24bit floats exist
[23:55] <durandal_1707> i can't find half float sample but i know they exist
[23:57] <Skyler_> half floats are 16-bit, aren't they?
[00:00] --- Mon Jun 24 2013