[20:51] <wledoux> Hi there, 
[20:52] <wledoux> After my last upgrade of nvidia-current (yersteday, from 260.19.26 to 260.19.29), I noticed that VLC crashed (segmentation fault) when playing some videos 
[20:53] <wledoux> If I disable hardware decompression (vdpau on a ION in my case), it plays the video correctly (slowly, but without crashing)
[20:54] <wledoux> What could I do to let the developpers know with a maximum of usefull informations ?
[20:56] <bjsnider> are you sure you're using gpu acceleration in vlc? have you tried playing the same video in mplayer?
[20:57] <wledoux> The video works in totem and in vlc when gpu acceleration is disabled
[20:57] <wledoux> but when i enable gpu acceleration, it crashes
[20:57] <bjsnider> what about mplayer?
[20:57] <wledoux> I don't have it
[20:57] <wledoux> Let me try
[20:58] <wledoux> (btw, thank you for answering me)
[20:58] <bjsnider> what video container and codec is this?
[21:00] <wledoux> H264 - MPEG-4-AVC1
[21:00] <wledoux> it's a mkv
[21:00] <wledoux> 1916x820
[21:00] <wledoux> with two audio Flux and on subtitle
[21:01] <wledoux> -on +one
[21:03] <wledoux> What I call "dis/enable vdpau acceleration" is (un)checking the "hardware decoding" in the FFmpeg advanced settings
[21:03] <wledoux> My vlc is 1.2.0-git20100715 from lucid multimediappa2
[21:04] <wledoux> it was not updated recently
[21:05] <bjsnider> you're using lucid?
[21:05] <wledoux> yes
[21:07] <wledoux> It works with mplayer
[21:08] <wledoux> but not shure it uses vdpau
[21:08] <wledoux> -shure + sure
[21:10] <wledoux> is "mplayer -vo vaapi myfile.mkv" correct ?
[21:10] <bjsnider> try mplayer -vo vdpau -vc ffh264vdpau video.mkv
[21:10] <bjsnider> use mplayer-git
[21:12] <wledoux> the command you just gave me did not work
[21:12] <wledoux> Forced video codec: ffh264vdpau
[21:12] <wledoux> Cannot find codec matching selected -vo and video format 0x34363248.
[21:12] <wledoux> I'll try mplayer-git
[21:12] <wledoux> libva: libva version 0.31.1-sds1
[21:12] <wledoux> Xlib:  extension "XFree86-DRI" missing on display ":0.0".
[21:12] <wledoux> libva: va_getDriverName() returns 0
[21:12] <wledoux> libva: Trying to open /usr/lib/va/drivers/nvidia_drv_video.so
[21:12] <wledoux> libva: va_openDriver() returns 0
[21:13] <ricotz> bjsnider, hi, could you do some multitasking? 
[21:14] <ricotz> bjsnider, my xorg.conf is driving me crazy :( - http://paste.debian.net/103375/ - the edid information arent working so i need to override them
[21:14] <wledoux> doesn't work with mplayer-git either
[21:15] <bjsnider> what does mplayer-git do?
[21:16] <wledoux> no video,  and the audio only, after a long wait
[21:16] <bjsnider> ricotz, you've got a lot of info in that file. the inputdevice stuff was deprecated a long time ago. but that's what you get for using nvidia-xconfig
[21:16] <wledoux> Video: no video
[21:17] <wledoux> Error opening/initializing the selected video_out (-vo) device.
[21:17] <bjsnider> mplayer-git says that?
[21:17] <wledoux> Hum, the long wait is normal, there is no audio at the beginning of the video ^^
[21:17] <wledoux> yes
[21:18] <ricotz> bjsnider, yeah, i know, the problem is that the modeline defs arent accepted which results in max 640x480
[21:19] <bjsnider> what happens if you throw the modeline stuff out?
[21:19] <wledoux> mplayer -vo vaapi -vc ffh264vdpau VIDEO.mkv 
[21:19] <wledoux> MPlayer UNKNOWN-4.4.3 (C) 2000-2010 MPlayer Team
[21:19] <wledoux> mplayer: could not connect to socket
[21:20] <wledoux> mplayer: No such file or directory
[21:20] <wledoux> Failed to open LIRC support. You will not be able to use your remote control.
[21:20] <wledoux> Playing VIDEO.mkv.
[21:20] <wledoux> [mkv] Track ID 1: video (V_MPEG4/ISO/AVC) "x264", -vid 0
[21:20] <wledoux> [mkv] Track ID 2: audio (A_AC3) "AC3", -aid 0, -alang eng
[21:20] <bjsnider> mplayer-git uses vdpau
[21:20] <wledoux> [mkv] Track ID 3: audio (A_DTS) "DTS", -aid 1, -alang eng
[21:20] <wledoux> [mkv] Track ID 4: subtitles (S_TEXT/UTF8) "Subtitles", -sid 0, -slang dut
[21:20] <wledoux> [mkv] Will play video track 1.
[21:20] <wledoux> Matroska file format detected.
[21:20] <wledoux> VIDEO:  [avc1]  1916x820  24bpp  24.000 fps    0.0 kbps ( 0.0 kbyte/s)
[21:20] <bjsnider> use the command i listed above. do not use vaapi
[21:20] <wledoux> Error opening/initializing the selected video_out (-vo) device.
[21:20] <wledoux> [21:20] <wledoux> Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
[21:20] <wledoux> AUDIO: 48000 Hz, 2 ch, s16le, 640.0 kbit/41.67% (ratio: 80000->192000)
[21:20] <wledoux> Selected audio codec: [ffac3] afm: ffmpeg (FFmpeg AC-3)
[21:20] <wledoux> [21:20] <wledoux> AO: [pulse] 48000Hz 2ch s16le (2 bytes per sample)
[21:20] <wledoux> Video: no video
[21:20] <bjsnider> and don't spam the channel. use pastebin
[21:20] <wledoux> Starting playback...
[21:20] <wledoux> A:   5.7 (05.7) of 6181.2 ( 1:43:01.2)  1.2% 
[21:20] <wledoux> Hum, 'll use paste.debian next time
[21:20] <ricotz> bjsnider, the same as they were in because they are ignored now
[21:21] <bjsnider> ricotz, this sucks because right now the nvforums site is down. there's all sorts of chatter about this over there
[21:22] <wledoux> It works very fine and smooth, CPU usage proves that it use gpu
[21:22] <bjsnider> did you try fiddling with the horizsync/vertrefresh values?
[21:22] <ricotz> bjsnider, the edid i am getting is empty, and nouveau seems to get something but reports a checksum error
[21:22] <bjsnider> wledoux, so it sounds like a vaapi issue i guess
[21:22] <bjsnider> so even nouveau can't drive the monitor correctly?
[21:22] <ricotz> bjsnider, i created them with gtf
[21:23] <ricotz> bjsnider, yes, but it is a nvc0
[21:25] <bjsnider> ricotz, is your system a vaio?
[21:25] <ricotz> no, a desktop system
[21:26] <ricotz> with a gf104
[21:28] <ricotz> bjsnider, are more options to force a specific resolution?
[21:29] <bjsnider> one thing that nvidia has been talking about is having users create their own edid file and point the blob to it in xorg.conf
[21:29] <wledoux> I checked the last upgraded packages (http://pastebin.com/E4QtXQKv)
[21:29] <bjsnider> but like i said, the best site for this info is currently down
[21:29] <wledoux> So basically, you says that is is an old bug in a package not listed here ?
[21:31] <bjsnider> wledoux, probably, since i'm using the newer vaapi  that's available in maverick, and i have no trouble playing matroska x264 videos
[21:32] <bjsnider> ricotz, has that monitor ever worked with ubuntu?
[21:32] <ricotz> bjsnider, yes, of course ;)
[21:32] <bjsnider> whn did it stop working?
[21:33] <ricotz> this is hard to say, because i had to switch the graphics card
[21:34] <ricotz> but it is working properly on my laptop with intel/natty
[21:34] <wledoux> bjsnider: I had no troubles at all until the listed upgrades, so i though it was due to vdpau. Can I upgrade my vaapi lib in some more recent ppa ?
[21:34] <bjsnider> wledoux, i haven't put the newer ffmpeg/vlc/vaapi packages into that ppa because i don't use lucid anymore, so i can't test them
[21:35] <bjsnider> i suppose the best way to upgrade would be to use maverick
[21:36] <bjsnider> ricotz, what graphics card are you using?
[21:36] <ricotz> gf104
[21:36] <ricotz> gtx460
[21:37] <bjsnider> well that doesn't lack for horsepower
[21:38] <ricotz> bjsnider, do you know get-edid?
[21:39] <bjsnider> no
[21:39] <ricotz> mhh, i am trying to get the edid info with my laptop, but it only read the internal display data
[21:39] <wledoux> bjsnider: I will consider updating to maverick, but in case I choose not to, Is there another contributor that you know will test it and push it any time soon, or should I compile it myself ?
[21:42] <bjsnider> ricotz, that's a good idea though
[21:43] <bjsnider> wledoux, can you do ppa builds yourself?
[21:44] <wledoux> Never did, but in theory i could (i am a programmer, but only experienced on windows)
[21:45] <bjsnider> ever do any debian packaging before?
[21:45] <wledoux> nope
[21:45] <bjsnider> it's not quite as easy as saying "i'm a programmer"
[21:45] <bjsnider> wledoux, you know shell scripting?
[21:46] <wledoux> bash, yes, the others not that much
[21:46] <bjsnider> well it shouldn't be all greek to you then
[21:46] <bjsnider> if you want to sign up to launchpad, send me an email at the contact link for the team and i'll join you so you can try packaging the stuff
[21:47] <bjsnider> all you really need to do is backport the maverick packages
[21:48] <wledoux> how do I throughly test it before pushing ? do i need to test it on several hardware and hundreds of videos ?
[21:51] <bjsnider> wledoux, set up a pbuilder environment to test the builds first. then send them in. testing the hardware is something the source code needs to deal with, it's outside the purview of the packager
[21:58]  * wledoux is googling for pbuilder
[22:02] <bjsnider> there's an ubuntu wiki page about setting up pbuilder
[22:03] <wledoux> yes i am on it (but in my native language, ie french)
[22:04] <wledoux> So from what I understood, I would "backport" your packages for maverick, build them in a clean and neat lucid install up to date with pbuilder
[22:06] <wledoux> But the fact that it builds doesn't mean it works, so i must be missing a step between "build with pbuild" and "send it"
[22:07] <wledoux> if there is no testing, then I presume that you would maintain it on lucid, since pbuilder seems to manage several distributions
[22:32] <bjsnider> wledoux, it is impossible to conduct extensive tests on all platforms before the packages are published. we do not do that. we build them and if they build they're almostcertainly going to work
[22:33] <bjsnider> building them into binaries successfully pretty much means you've created packages the upstream devs intended when they wrote the software.
[22:33] <wledoux> bjsnider: You said previously that you did not push the packages for lucid, 'cause you could not "test" them, did you mean "test if they build", then ?
[22:34] <bjsnider> no, i meant test in the sense that you did
[22:35] <bjsnider> vlc/ffmpeg/vaapi is so complex that it would require regular use to test. so it's kind of an exception. but you would be using it which is why i suggested you could do it
[22:36] <wledoux> so when you push vlc/ffmpeg/vaapi, do you install yourself the packages you build before pushing it to test it against a couple of videos ?
[22:36] <bjsnider> sometimes
[22:37] <wledoux> it means that you are kind of forced to be always up to date with every related package, right ?
[22:37] <wledoux> else the package may not work.
[22:38] <bjsnider> everythin builds against ffmpeg, you can float for awhile building new vlc packages against one ffmpeg, but eventually there'll be an api/abi change that forces you to update ffmpeg too
[22:38] <bjsnider> on the other hand you could build vlc using internal ffmpeg
[22:41] <wledoux> What happens if you push something that you did not test and it breaks
[22:42] <wledoux> the users have no way to "undo" an update on a set of packages, do they ?
[22:49] <bjsnider> sledpush a newer version, but the users knew what they were getting into when they added the ppa
[22:49] <bjsnider> wledoux, push a newer version, but the users knew what they were getting into when they added the ppa
[22:53] <wledoux> bjsnider: So the packager's work is also to be all ears open to user's bugs,  investigate them and let the maintainer to fix it so that it can push a newer version ? 
[22:53] <wledoux> +know
[22:54] <bjsnider> that's more or less true
[22:55] <bjsnider> but you have to distinguish between a problem with the packaging and a problem with the software source code. something can be packaged so poorly that it's unusable
[22:57] <wledoux> is the "process" the same for mainstream ppa ?
[22:57] <wledoux> concerning testing
[23:04] <wledoux> bjsnider: sorry, had to reconnect
[23:04] <bjsnider> wledoux, i'm not sure what you're asking with that last question.
[23:07] <wledoux> bjsnider: I resume what you said as "it is hard to test, people were aware that it can breaks when subscribing to shis ppa". So my question is "Is there more tests on mainstream ppas, where people are expecting it to work, and if yes, how do the tests are done ?"
[23:08] <bjsnider> no, it's no different
[23:14] <wledoux> Okay, I undersand a little more what is expected from a packager. I think I will at try, at least for learning how it works
[23:14] <wledoux> -at
[23:16] <wledoux> But in the future, I will be more cautious about upgrades when nothing is breaked (yet).
[23:16] <wledoux> Thanks VERY MUCH for your time
[23:52] <bjsnider> no problem