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

[burek]

[05:10] <cone-358> ffmpeg.git 03Michael Niedermayer 07master:61d59703c918: avcodec/snow: split block clipping checks
[09:38] <superware> can someone please explain how to sync video frames to internal timer using PTS. I found https://trac.handbrake.fr/wiki/LibHandBrakeSync but don't really understand the concept..
[09:41] <ubitux> j-b: "With FFmpeg, HuffYUv is broken." huh?
[09:42] <j-b> ubitux: fact.
[09:42] <j-b> ubitux: https://wiki.videolan.org/Libavcodec_regressions
[09:42] <j-b> ubitux: being bored of FUD, I do my own tracking
[09:42] <ubitux> yes that from where i quoted it
[09:43] <ubitux> i'm just wondering where is the sample/ticket/whatever
[09:43] <j-b> https://forum.videolan.org/viewtopic.php?f=14&t=117212&p=398361&hilit=huffyuv#p397579
[09:43] <j-b> and as usual, you'll dismiss this
[09:44] <av500> dismissed
[09:44] <av500> next
[09:44] <ubitux> i? huh?
[09:45] <ubitux> confirmed, 'will open a ticket
[10:00] <ubitux> bisecting.
[10:05] <ubitux> michaelni: e6d1c66d742d766a80a26ed2a9524a0fffbcf958 ’ #3395
[10:06] <ubitux> j-b: other facts while i'm at it?
[10:06] <nevcairiel> that is one odd commit to break stuff
[10:07] <nevcairiel> i mean, it just disables asm
[10:08] <j-b> ubitux: some issues with bmp encoding and threading, IIRC
[10:09] <ubitux> j-b: ticket/forum post/sample/anything? :p
[10:10] <j-b> no
[10:11] <j-b> and the famous vdpau issue
[10:11] <ubitux> what's that?
[10:19] <av500> FFmoped?
[11:48] <ubitux> lol @ mp4 files with megabytes of zero padding...
[11:55] <nevcairiel> i was wondering if someone would dig up my old h264 dxva2 patches one day. :p
[13:59] <cone-331> ffmpeg.git 03Michael Niedermayer 07master:469de4f58317: avcodec/huffyuvdec: use the correct height field
[13:59] <michaelni> j-b, fixed
[14:02] <michaelni> j-b, that is the huffyuv issue. What do you mean by "and the famous vdpau issue" ?
[14:02] <michaelni> which ticket is that ?
[14:03] <j-b> don't know if there is a ticket
[14:03] <j-b> but vdpau from libav and ffmpeg is not the same, IIRC
[14:04] <michaelni> "not the same" is a bit vague, is there some incompatibility? something not working?
[14:06] <ubitux> michaelni: https://mailman.videolan.org/pipermail/vlc-devel/2014-February/096628.html
[14:06] <ubitux> i think that's this thread
[14:07] <nevcairiel> the thread reads more like vlc drama then a technical discussion of issues in ffmpegs code
[14:08] <ubitux> i read later "An ugly workaround would be to disable VDPAU if micro > 100, aka FFMpeg case." but i have no idea what the issue actually is
[14:24] <BBB> does anyone mind if we temporarily use upload.ffmpeg.org/incoming for sharing some files between developers (ubitux/nevcariel/me)?
[14:24] <ubitux> Compn ^ ?
[14:26] <ubitux> ETA 30h for the etv5k vp9 samples
[14:26] <BBB> \o/
[14:27] <nevcairiel> I added a few more bitrates to my encodes, and to my own surprise a 1mbit vp9 encodes much slower then 5mbit :p
[14:28] <nevcairiel> (also, 1mbit vp8 looks like crap)
[14:29] <ubitux> 5k in 17h, 10k in 22h and 20k in 30h
[14:29] <ubitux> larger = slower for me here with vp9
[14:29] <nevcairiel> was the same for me, except that it went back up with 1mbit
[14:29] <ubitux> vp9 backfire
[14:30] <BBB> ubitux: yeah same for me
[14:30] <BBB> libvpx doesn't seem to prune rd modes very well at high bitrates, not sure why
[14:30] <JEEB> <nevcairiel> (also, 1mbit vp8 looks like crap) <- IIRC libvpx's vp8 encoder lacks a lot of psyopts. Although for example AQ is already quite expensive to do because signaling the change is expensive IIRC?
[14:30] <BBB> nevcairiel: yeah more bitrates is good, also if you guys can, make sure the resulting ssim values are recorded somewhere before you destroy the y4m original
[14:31] <nevcairiel> i kept the original
[14:31] <BBB> ok thanks
[14:31] <nevcairiel> everything here; http://files.1f0.de/encodes/ .. except the 1mbit vp9 which is still encoding
[14:31] <BBB> I use this script to measure ssim: http://pastebin.com/iyC3C4Xp
[14:31] <BBB> it uses tiny_ssim and then please do apply the patch I sent to the ML
[14:32] <BBB> so that we have both db as well as raw ssim numbers (and it will also record psnr, this isn't terribly useful but why not...)
[14:32] <BBB> and relevant files are in ftp://upload.ffmpeg.org/incoming/vp9-speed/
[14:33] <BBB> that probably needs to be moved somewhere to be world-readable but I don't have the password anymore
[14:33] <BBB> so if someone feels like organizing that, that'd be wonderful
[14:35] <BBB> nevcairiel: ubitux: can you guys try to generate the ssim/psnr numbers per file yourself? then I don't have to download the raw y4ms :-p
[14:35] <BBB> (still have a diskspace problem)
[14:35] <ubitux> sure
[14:36] <BBB> ty :)
[14:36] <ubitux> if you give me the command
[14:36] <BBB> http://pastebin.com/iyC3C4Xp
[14:36] <nevcairiel> I suppose the tool should work on windows right
[14:36] <BBB> I think so
[14:36] <BBB> maybe mkfifo won't?
[14:36] <BBB> don't know
[14:36] <BBB> it basically just calls ffmpeg twice to decode the file and the y4m, and then calls tiny_ssim
[14:37] <BBB> then run that in a loop on all encoded files
[14:37] <BBB> off to work now, bbl
[14:39] <j-b> ubitux: michaelni: details in your mail.
[14:42] <Compn> ubitux : why would i mind? :)
[14:42] <ubitux> Compn: dunno, i thought you were somehow maintainer of the samples
[14:42] <Compn> (p.s. upload.ffmpeg.org is j-b's server)
[14:43] <Compn> its ok with me 
[14:43] <Compn> i actually dont know how to delete off incoming
[14:44] <Compn> maybe carl knows
[14:45] <Compn> j-b would know , i only have http access...
[14:50] <nevcairiel> hm a 500k encode still looks surprisingly well, wonder if i should try to do something extreme like 100k :p
[15:01] <nevcairiel> BBB: yeah mkfifo doesn't work, but no matter, i'll just create the full files first
[15:36] <{V}> nevcairiel, there is a mkfifo-like solution if creating the full files is less desireable
[15:41] <cone-331> ffmpeg.git 03Reimar Döffinger 07master:e535897fad2c: Fix libswresample compilation with Apple Neon assembler.
[15:41] <cone-331> ffmpeg.git 03Michael Niedermayer 07master:1355cafcb675: Merge remote-tracking branch 'cehoyos/master'
[16:10] <ubitux> nevcairiel: we definitely need a "stream" metadata to be exported in lavfi though
[16:10] <ubitux> for the final values
[16:10] <ubitux> frame metadata works, but final one are not exported up to the stream
[16:21] <nevcairiel> lavfi doesnt have a concept for that though, and pushing that in frame side data to be extracted later and copied to stream metadata seems like a terrible ugly thing
[16:22] <ubitux> i wasn't thinking of this
[16:23] <nevcairiel> but "the others" were :p
[16:23] <ubitux> more like AVStream metadata linked to AVFilterlinks
[16:23] <ubitux> so like, rotate/transpose filters could use the rotate metadata from the stream
[16:23] <ubitux> or we could inject replaygain metadata in the stream metadata
[16:23] <ubitux> so it's written as id3 or whatever
[17:01] <cone-331> ffmpeg.git 03Michael Niedermayer 07master:9bb1af8f36ec: avcodec/huffyuvdec: use RGB0 for 24bit rgb output instead of BGRA
[17:43] <cone-331> ffmpeg.git 03Hendrik Leppkes 07master:7716eda0aad7: vp9/x86: set correct number of registers used in intra pred asm
[18:19] <cone-331> ffmpeg.git 03Gonzalo Garramuno 07master:3d20260157cb: avcodec/exr: read layers
[19:08] <aca> Hi. I'm trying to compile ffmpeg 2.1.3 on Debian testing and I thought it went well. But 'make check' fails: "Test idct8x8 failed. Look at tests/data/fate/idct8x8.err for details." This file says: "symbol av_buffer_allocz, version LIBAVUTIL_52 not defined in file libavutil.so.52 with link time reference" Does someone know what went wrong?
[19:09] <nevcairiel> sounds like it tried to load a system library
[19:09] <aca> Can I tell it not to do so?
[19:35] <ubitux> ffplay -user-agent "Mozilla/5.0" "http://translate.google.com/translate_tts?tl=ja&q=................"
[19:41] <ubitux> (seems the user agent is not necessary anymore/in this case - can be ignored)
[19:42] <michaelni> aca, simple/quick solution is not to use --enable-shared
[19:44] <cone-331> ffmpeg.git 03Michael Niedermayer 07master:cbcfd7da4d1f: avcodec: support setting the chroma intra matrix
[19:44] <cone-331> ffmpeg.git 03Michael Niedermayer 07master:3e70c7023e59: ffmpeg: support setting the chroma intra matrix
[19:46] <aca> michaelni, thanks for the hint, but I'm trying to make a Debian package... Not build-depending on libopencv-dev should help, as this pulled in libavutil52.
[19:47] <michaelni> aca, debian package for yor personal use or something official ? 
[19:49] <aca> At the moment for personal use, but I intent to send the debian.tar.xz to the RFP bug and see what comes of it.
[19:52] <michaelni> about doing it the correct way with shared libs, there are 2 ways, the first is to change the major version numbers to match libav and use --enable-incompatible-libav-abi, this would then install libs matching libav as a theoretically 100% compatible replacement. Or instead of all that use --enable-raise-major to install libs with different sonames which theoretically should be installable side by side with libav
[19:52] <michaelni> if either of these fails somehow iam quite interrested in bug reports
[19:55] <aca> Do you mean that with --enable-incompatible-libav-abi programs compiled with libav will work with ffmpeg? Has this negative consequences, e.g. missing features?
[19:56] <michaelni> no missing features, the only problem is that this has not been tested much so it likely will hit bugs that will need to be fixed
[19:57] <ubitux> note that it probably won't be enough; i believe some apps depends not only on the libraries but the programs as well
[19:57] <ubitux> you will probably have to make sure those apps can call both ffmpeg and avconv
[19:57] <ubitux> ...or add a avconv symlink to ffmpeg as a tmp workaround, but that would be evil
[20:00] <aca> At the moment I'm not installing qt-faststart in the ffmpeg package, so that it does not conflict with libav-tools. So if e.g. avconv works with the ffmpeg libraries this should work, if both ffmpeg and libav-tools are installed.
[20:01] <ubitux> qt-faststart has a limited usage nowadays, and it doesn't diff much between the 2 projects
[20:01] <ubitux> we just have a few fixes iirc
[20:03] <Daemon404> the epic ticket reached 256
[20:03] <aca> Would packages compiled against these ffmpeg libraries with --enable-incompatible-libav-abi work with the libav libraries?
[20:04] <nevcairiel> Daemon404: I wish they would find some commitable changes already
[20:04] <Daemon404> yeah
[20:04] <ubitux> aca: i'd say probably very badly
[20:05] <ubitux> ah mmh sorry misread
[20:05] <ubitux> aca: as long as they don't use ffmpeg specific features...
[20:07] <ubitux> aca: if you want to package both libs properly i'm afraid you'll have to duplicate dep packages (foobar-libav and foobar-ffmpeg)
[20:12] Action: Daemon404 sees BB patche tiny_ssim
[20:12] <Daemon404> BBB*
[20:12] Action: Daemon404 used to use xiph's dump_ssim for that
[20:12] <ubitux> aca: a lot of packages have various .100 minor check to enable ffmpeg specific path; so even if it's build with --enable-incompatible-libav-abi, the app will probably try to use ffmpeg features
[20:12] <ubitux> s/minor/micro/
[20:12] <nevcairiel> he tried, he hated it because it was incredibly slow, Daemon404
[20:12] <Daemon404> of course it is
[20:12] <aca> ubitux: Do you mean every package using ffmpeg/libav would need to be duplicated? I don't think that is doable...
[20:13] <nevcairiel> we're already spending hours and hours encoding test footage in vp9, at least the ssim can be fast!
[20:13] <Daemon404> iirc the windowing in tiny_ssim is a lot bigger
[20:13] <ubitux> aca: doesn't debian already do that with various libs?
[20:13] <ubitux> aca: like gnutls vs openssl or stuff like that
[20:13] <Daemon404> nss1
[20:13] <Daemon404> !
[20:14] <aca> ubitux: Yes, but that's rather painful and I think nobody wants to do this for ffmpeg/libav...
[20:14] <aca> ubitux: But compiling with --enable-raise-major should give packages that are coinstallable with libav?
[20:15] <michaelni> ubitux, why would any packages need to be duplciated ?
[20:17] <ubitux> michaelni: well, it means every app using libav* will need to be build against libav
[20:17] <ubitux> aca: it's simple, we are basically "retro" compatible with libav assuming the --enable-incompatible-libav-abi flag, in the sense that we are a subset of it
[20:17] <ubitux> you can consider it that way
[20:17] <Daemon404> i think you mean superset
[20:17] <ubitux> a superset*
[20:18] <ubitux> yes
[20:18] <michaelni> ubitux, i think you are wrong on the "every" i thnk the majority of apps that work with libav would also work with it when they have been build against ffmpeg
[20:19] <ubitux> michaelni: i think most app nowadays use the .100 micro check to do specific ffmpeg path
[20:19] <ubitux> maybe i'm wrong..
[20:19] <aca> By the way, is this compatible with libav 9 or libav 10?
[20:20] <shahriman> hi guys
[20:20] <Daemon404> the version #s more or less have no me meaning at all
[20:20] <Daemon404> s/me //
[20:20] <shahriman> can anyone please unblock my message to ffmpeg-devel
[20:20] <shahriman> my patch*
[20:20] <shahriman> who is the mod for ffmpeg-devel ML?
[20:21] <michaelni> aca, compatibility should be always to the versions from about the same time
[20:21] <nevcairiel> Daemon404: technically tiny_ssim is part of fate, and not the tool set. :p alternative suggestions to detect isatty are surely welcome i reckon
[20:21] <aca> Daemon404: I'm not so sure about that. A lot of packages that build with libav9 fail to build with libav 10.
[20:21] <nevcairiel> I think the patch to tiny_ssim breaks fate anyway, since it changes the output
[20:21] <Daemon404> nevcairiel, it actually was originally a tool
[20:21] <Daemon404> by pengvado 
[20:21] <Daemon404> we just happened to import it
[20:21] <aca> michaelni: So 2.3.1 is libav10?
[20:21] <Daemon404> aca, i mean the version numbers between libav and ffmpeg are in no way related
[20:21] <Daemon404> there is no " is comptible with Y"
[20:22] <Daemon404> X*
[20:22] <aca> Daemon404: I see.
[20:23] <ubitux> shahriman: i think llogan has control over it
[20:25] <llogan> shahriman: there you go
[20:25] <shahriman> llogan: thanks a lot.
[20:26] <llogan> mail mod with UTC -9 results in odd queue clearing times.
[20:27] <aca> Now the next test fails: make[1]: *** [tests/data/ffprobe-test.nut] Error 127 How to make this one work?
[20:28] <wm4> ubitux: ping on the subtitle shit?
[20:28] <Daemon404> aca, ?
[20:28] <ubitux> wm4: yes i'll have a look tonight, 'didn't forget
[20:29] <ubitux> wm4: i have some stuff to get done right now though, sorry
[20:29] <superware> can someone please explain https://trac.handbrake.fr/wiki/LibHandBrakeSync ? I'm looking for an algorithm for syncing network stream video frames for display.
[20:30] <Daemon404> superware, perhaps you should go as in teh handbrake channel
[20:30] <Daemon404> we're not handbrake
[20:31] <aca> Daemon404: I'm trying to get 'make check' working, but it fails...
[20:31] <Daemon404> if it fails then it's a bug
[20:32] <aca> Daemon404: How can I debug this?
[20:32] <Daemon404> well...
[20:32] <Daemon404> error 127 is a POSIX code
[20:32] <Daemon404> it means command not found
[20:32] <Daemon404> something isnt being built, or a makefile dep is wrong
[20:32] <Daemon404> probably.
[20:33] <ubitux> ffprobe maybe :)
[20:33] <aca> Daemon404: Maybe it needs --enable-libnut, but I think libnut is not available in Debian.
[20:33] <Daemon404> no
[20:33] <superware> Daemon404: my issue is rather general, not really handbrake related (plus their channel is empty)
[20:33] <Daemon404> the nut tests use our own thing
[20:33] <Daemon404> its probably what ubitux said.
[20:34] <Daemon404> superware, looks pretty full to me
[20:36] <Daemon404> 23
[20:36] <Daemon404> woops.
[20:39] <superware> Daemon404: you're right, sorry :)
[22:21] <superware> if I set AVCodecContext->refcounted_frames = 1; I will later need to av_frame_unref(frame); av_free(frame); per frame, right?
[22:24] <wm4> superware: yep
[22:24] <wm4> superware: actually, you have to be careful
[22:24] <Daemon404> you dont av_free frames
[22:24] <wm4> first, don't call av_free(frame), but av_frame_free(frame)
[22:24] <wm4> it will also do the unref for you
[22:25] <superware> woops
[22:25] <wm4> and second, I think you should always unref the frame you pass to the decoder
[22:25] <wm4> I'm not sure what currently happens if you pass a referenced frame to it
[22:27] <wm4> maybe use av_frame_move_ref
[22:28] <superware> I have a rendering thread which dequeues AVFrame*s, renders, and free/unref
[00:00] --- Wed Feb 19 2014