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

burek burek021 at gmail.com
Tue May 26 02:05:01 CEST 2015


[03:16:27 CEST] <chrisjunkie> Hey all, I've been eagerly waiting QuickSync to appear in FFMpeg's main repo, this looks like its the case. Obviously its not in a current release (as I can't find any documentation) but is there a group thats working on this? Happy to provide testing help and offer fixes when I can
[03:16:49 CEST] <chrisjunkie> Also wondering if its working on Linux 8-)
[03:43:19 CEST] <aplund> I get this from ffprobe on a dvd iso image: http://pastie.org/10205581
[03:43:43 CEST] <aplund> What is stream #0:5 and is this correct or is it being probed wrong somehow?
[03:45:16 CEST] <intracube> aplund: you could try the mediainfo utility and see if shows anything else
[03:48:37 CEST] <aplund> intracube, it just reports that it is iso9660.  Though I'm not sure how to use it.
[03:50:21 CEST] <intracube> aplund: are you using the graphical frontend or command line?
[03:50:39 CEST] <aplund> intracube, command line.
[03:50:53 CEST] <intracube> hmm, it should report a lot more back than that by default
[03:51:45 CEST] <intracube> maybe it can't read within an ISO :/
[03:51:47 CEST] <aplund> gives the file size and says the stream type is iso9660, but nothing much more than that.
[03:52:12 CEST] <intracube> not sure what else to suggest
[03:52:58 CEST] <aplund> might try a loop mount and try it on the VOBs
[03:58:37 CEST] <aplund> well.. that stream id doesn't appear in any of the VOBs individually it seems.
[04:01:57 CEST] <intracube> aplund: looks a bit like some duff info reported by ffprobe
[04:02:56 CEST] <aplund> intracube, seems the handling of iso9660 is a bit flaky at times
[04:03:18 CEST] <aplund> this image has VIDEO_TS.VOB and VTS_*.VOB
[04:03:39 CEST] <aplund> but some of the IFO and BUP might be in between and maybe that's causing the issue
[17:29:38 CEST] <stark> Hello everyone i'm trying look for a solution to this error "x11grab @ 0x83f1e00". Bascially i'm trying to create a screencast using the following command "ffmpeg -f x11grab -s 1280x800 -an -r 16 -i :0.0 -b:v 5M -y test.webm" And i'm getting the following error:
[17:29:42 CEST] <stark> Capture area 1280x800 at position 0.0 outside the screen size 1280x800
[17:29:45 CEST] <stark> :0: Invalid argument
[17:29:59 CEST] <stark> with that error code
[17:34:33 CEST] <kepstin-laptop> stark, huh, what ffmpeg version are you using?
[17:36:03 CEST] <stark> kepstin-laptop, 2.6.3
[17:40:11 CEST] <kepstin-laptop> huh, that error was only added fairly recently, it's newer than the source I'm looking at :)
[17:41:47 CEST] <kepstin-laptop> looks like the issue's already been fixed in git, guess it didn't make it into the ffmpeg stable tarball.
[17:42:45 CEST] <kepstin-laptop> stark, you can grab this change to fix it, was an off-by-one in the comparison. http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=7971fa9ce0ead8d2e8a79dbe422e91dcef8222ba
[17:46:06 CEST] <stark> Ah, nice. Thanks for looking into this  kepstin-laptop.
[21:59:35 CEST] <jbmcg> Hey there, can anyone explain to me why trimming videos without re-encoding can yield unexpected results sometimes? I feel like its related to keyframes or lack thereof but I really don't know for sure. Here's an example of what I'm trying to do: http://pastebin.com/6xLBv71j
[22:04:41 CEST] <kepstin-laptop> jbmcg, yeah, that's probably the case. If you're not re-encoding the video, you can only choose start points that correspond to the location of a keyframe.
[22:05:23 CEST] <kepstin-laptop> ffmpeg will move your selected start point to a different spot in this case; I think it tries to find the nearest keyframe before your requested start point.
[22:06:01 CEST] <DragonsLordKERNE> yes, kepstin ... you are right
[22:06:19 CEST] <DragonsLordKERNE> c_14 explained this to me some weeks ago
[22:06:46 CEST] <DragonsLordKERNE> key-frame accurancy is possible only with re-encoding
[22:08:10 CEST] <jbmcg> but, where I provided the same time in both commands, shouldn't ffmpeg have found the same keyframe on each command and therefore not have overlapping footage in the output videos?
[22:08:44 CEST] <kepstin-laptop> jbmcg, the *end* point doesn't have to be on a keyframe boundary, only the start point does
[22:08:50 CEST] <kepstin-laptop> so ffmpeg only moves the start point.
[22:09:18 CEST] <kepstin-laptop> (although there's some weirdness when you have B frames, dunno how that works)
[22:10:47 CEST] <kepstin-laptop> but yeah, the start time might be moved to an earlier time to find a keyframe to start at, and the end time can maybe be moved to a later time if you have B-frames, to keep the necessary references intact.
[22:11:21 CEST] <kepstin-laptop> so you'd get overlap if you do two cuts with the end of one being the start of the next, if the selected time isn't right on a keyframe.
[22:11:41 CEST] <kepstin-laptop> unless you're reencoding, of course.
[22:16:30 CEST] <jbmcg> ok cool that makes sense with the results I've been getting. so to get what I'm expecting to work, I need to make sure my -t value matches a keyframe on each command, right?
[22:17:31 CEST] <jbmcg> or I guess, ss+t needs to match a keyframe
[22:18:02 CEST] <kepstin-laptop> jbmcg, you need to make sure ss hits a keyframe, and t includes everything up to but not including the next keyframe.
[22:24:48 CEST] <jbmcg> Ok cool that makes sense. Would you say the most efficient way to programmatically figure out the closest keyframe to a time would be to use ffprobe to get the full list of the frames and loop through to find the closest one?
[22:26:24 CEST] <jbmcg> Something like this I suppose: "ffprobe -show_frames -select_streams v -print_format json=c=1 output.mp4" and then go through the json to find the closest one
[23:07:25 CEST] <NehezvoltRegelni> Hi! I've managed to loop a transparentpng, and now i want to render subtitle on it
[23:07:41 CEST] <NehezvoltRegelni> the problem is that the subtitle is only visible where the transparent png has something, otherwise it's invisible
[23:07:56 CEST] <NehezvoltRegelni> can you help me? ffmpeg -loop 1 -f image2 -i subtitle.png  -t 10 -vcodec png -pix_fmt rgba -vf "ass=hu.ass"   -y -deinterlace  jpg/image%08d.png
[23:08:39 CEST] <NehezvoltRegelni> (The goal is to have the subtitles rendered onto a transparent png, so that i would be able to use it in an NLE)
[23:09:12 CEST] <kepstin-laptop> huh, interesting. I suppose that's a bug in the 'ass' filter. Does the 'subtitles' filter behave any differently?
[23:10:13 CEST] Action: NehezvoltRegelni trying to convert ass->srt, and i'll check it out
[23:11:13 CEST] <kepstin-laptop> hmm? 'subtitles' filter can take ass input, no need to convert anything.
[23:11:42 CEST] <NehezvoltRegelni> o, i didn't knew that
[23:11:47 CEST] <kepstin-laptop> i wouldn't be surprised if it's the same result tho, since the core rendering is done by libass in both cases.
[23:13:28 CEST] <NehezvoltRegelni> kepstin-laptop: yeah, the same
[23:13:29 CEST] <NehezvoltRegelni> http://imgur.com/Avg1Zda
[23:13:57 CEST] <NehezvoltRegelni> do you have any idea/workaround?
[23:15:14 CEST] <kepstin-laptop> dunno, I'm not familiar with the libass api. It's almost certainly going to require code changes; most likely in ffmpeg, possibly in libass.
[23:15:33 CEST] <NehezvoltRegelni> :(
[23:15:51 CEST] <kepstin-laptop> I suspect the ffmpeg filter will have to be changed to actually adjust the alpha channel of the resulting image - it presumably only currently sets the r,g,b values.
[23:16:15 CEST] <kepstin-laptop> the normal use is to render subtitles on opaque images, so this works fine in most cases.
[23:16:33 CEST] <NehezvoltRegelni> yes, i'm the 1%percent of crazyness:)
[23:16:39 CEST] <NehezvoltRegelni> And do you have any idea how could i render subtitle in any way into set of png frames?
[23:17:10 CEST] <NehezvoltRegelni> hmm.... Rendering on a green png... and greenbox:D
[23:17:21 CEST] <NehezvoltRegelni> I would be happy for a better solution:)
[23:17:36 CEST] <kepstin-laptop> will fail if there's any green text in the subs, but otherwise I suppose that might work :)
[23:17:46 CEST] <NehezvoltRegelni> no, it just b&w
[23:17:53 CEST] Action: NehezvoltRegelni wanna cry
[23:17:54 CEST] <NehezvoltRegelni> :D
[23:18:15 CEST] <kepstin-laptop> Looks like the libass api does provide enough info to get the alpha right, it's just not done in ffmpeg (it looks like a pain to do).
[23:24:04 CEST] Action: rak[2] likes ffmpeg.. thanks to contributers :)
[23:27:00 CEST] <NehezvoltRegelni> ^ me 2
[00:00:00 CEST] --- Tue May 26 2015


More information about the Ffmpeg-devel-irc mailing list