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

[burek]

[00:04:21 CEST] <ChocolateArmpits> DragonsLord: yes however it will most likely not be distributed evenly across the file as compared with other files
[00:05:27 CEST] <DragonsLord> whould you be so kind to elaborate?
[00:05:47 CEST] <DragonsLord> What happens with AVIdemux is that, for some files,
[00:06:01 CEST] <DragonsLord> the average bitrate seems to be not respected
[00:06:06 CEST] <DragonsLord> only for some files
[00:06:16 CEST] <DragonsLord> I mean 1500 kbps avg bitrate
[00:06:26 CEST] <DragonsLord> and the resulting file is something like 2800 :O
[00:06:39 CEST] <DragonsLord> of course also the file size is completely different
[00:07:02 CEST] <DragonsLord> if compared with the other episodes/files with the same duration
[00:07:03 CEST] <DragonsLord> :/
[00:07:32 CEST] <ChocolateArmpits> it probably uses some other ratecontrol rate than the 2 pass method
[00:07:57 CEST] <ChocolateArmpits> 2 pass will always result in aproximately the same file size
[00:08:43 CEST] <iive> you don't need color key, you need alpha channel
[00:09:36 CEST] <DragonsLord> so, what could I do ChocolateArmpits ... in order to have the same filesize for all the episodes?
[00:09:40 CEST] <DragonsLord> one more pass?
[00:09:50 CEST] <ChocolateArmpits> what? use 2 passes
[00:10:01 CEST] <ChocolateArmpits> for variable encoding
[00:10:30 CEST] <ChocolateArmpits> or if you want to save time then constant bitrate by setting b:v maxrate and bufsize
[00:11:04 CEST] <DragonsLord> I am already using 2-passes VBR
[00:11:10 CEST] <ChocolateArmpits> well ok
[00:11:38 CEST] <DragonsLord> but, as mentioned before, for some files the "codec" seems to be not able to respect the average bitrate I set
[00:11:38 CEST] <Kolizer> there are Russians?
[00:13:29 CEST] <ChocolateArmpits> DragonsLord:  sorry, can't comment on this, but that shouldn't be ever happening using 2 pass
[00:14:48 CEST] <ps-auxw> DragonsLord: What encoder are you using? It seems to be a broken one if it can't respect your bitrate. Or you are encoding perfect noise, maybe. :)
[00:15:33 CEST] <DragonsLord> ps-auxw, thank you in advance ... I am using libxvid
[00:15:50 CEST] <ps-auxw> That *should* have decent rate control.
[00:16:03 CEST] <ps-auxw> Are you sure you are doing both passes?
[00:16:08 CEST] <DragonsLord> it respect my bitrate 90% of the times ... but sometimes no :(
[00:16:17 CEST] <DragonsLord> YES, I am 100% sure
[00:16:19 CEST] <ps-auxw> Okay.
[00:16:55 CEST] <DragonsLord> I am going to try also with FFmpeg
[00:17:26 CEST] <ps-auxw> You could check the quantizer limits somewhere in xvid's settings. Maybe it can't use high enough quants to reach the target...
[00:18:01 CEST] <ps-auxw> Or try switching to x264. It'll probably do better and has much better quality.
[00:18:10 CEST] <DragonsLord> I should have set 1 as a min and 31 as a maximum
[00:18:24 CEST] <ps-auxw> That sounds okay.
[00:18:24 CEST] <DragonsLord> I know but there is not an option
[00:18:32 CEST] <DragonsLord> I need XviD or DivX
[00:20:17 CEST] <ps-auxw> DragonsLord: How about resolution? If you are encoding HD or something, you might be better off downscaling with XviD.
[00:20:27 CEST] <DragonsLord> 704x400
[00:20:47 CEST] <DragonsLord> c_14 & ChocolateArmpits, y=[pixels to cut from the top] this is right?
[00:20:59 CEST] <ChocolateArmpits> DragonsLord: yes
[00:21:41 CEST] <DragonsLord> y should not also start from 0,0?
[00:21:58 CEST] <DragonsLord> so I thought it was from the bottom
[00:22:39 CEST] <DragonsLord> looking at the x,y Cartesian coordinate system, wasn't it?
[00:22:49 CEST] <ChocolateArmpits> x,y 0,0 is top left
[00:23:00 CEST] <ChocolateArmpits> 1919,1079 is bottom right
[00:23:32 CEST] <DragonsLord> Well, so it's not the Cartesian coordinate system
[00:23:39 CEST] <DragonsLord> :)
[00:28:30 CEST] <DragonsLord> ps-auxw, I love your nickname :)
[00:28:34 CEST] <DragonsLord> are you still there?
[00:42:38 CEST] <ps-auxw> DragonsLord: :)
[00:42:48 CEST] <ps-auxw> I'm still here. Got a bit distracted.
[00:43:35 CEST] <ps-auxw> I also kind of ran out of ideas. ;)
[00:44:37 CEST] <ps-auxw> I suppose you could try adding in some kind of denoising filter to make things more compressible.
[00:44:53 CEST] <DragonsLord> I don't really know :|
[00:45:20 CEST] <DragonsLord> here is an example of what I am doing
[00:45:20 CEST] <DragonsLord> http://pastebin.com/D1FRhPfh
[00:46:40 CEST] <ps-auxw> Hmm.
[00:48:18 CEST] <ps-auxw> And your commandline for the second pass is the same (except for -pass 1/2 of course)?
[00:49:01 CEST] <DragonsLord> yes + the audio of course
[00:51:52 CEST] <ps-auxw> Maybe try to see if you can find a setting for hqdn3d or owdenoise filters that doesn't ruin your video but still makes xvid happier. That should go into the -vf part.
[00:54:00 CEST] <DragonsLord> I have just tried to perform the conversion with FFmpeg
[00:55:00 CEST] <DragonsLord> and it's seems to be that ...
[00:55:14 CEST] <DragonsLord> Average Bitrate is ...
[00:55:15 CEST] <DragonsLord> 1499.789828 kbps
[00:55:20 CEST] <DragonsLord> 100% respected
[00:55:21 CEST] <DragonsLord> :D
[00:55:23 CEST] <ps-auxw> Oh... So it worked. :)
[00:55:30 CEST] <DragonsLord> only with FFmpeg
[00:55:34 CEST] <ps-auxw> I wonder what went wrong before...
[00:55:44 CEST] <DragonsLord> for some reason (unkonwn to me)
[00:55:56 CEST] <DragonsLord> with AVIdemux and Xmedia Recode not
[00:56:03 CEST] <ps-auxw> Well, as long as it works now... :)
[00:56:20 CEST] <DragonsLord> please I'm curiuous ... tell me :)))
[01:00:17 CEST] <ps-auxw> I have no clue either. ;)
[01:00:59 CEST] <ps-auxw> Maybe I could see something from a paste of a failed second pass log.
[01:01:32 CEST] <DragonsLord> But with ffmpeg it works
[01:01:50 CEST] <DragonsLord> and with the other software I don't really know how to produce a log
[01:01:52 CEST] <ps-auxw> Maybe avidemux failed to correctly pass all arguments.
[01:02:01 CEST] <ps-auxw> Oh well.
[01:02:13 CEST] <DragonsLord> thank you for your time, ps-auxw
[01:02:25 CEST] <ps-auxw> Sure, you're welcome. :)
[11:44:54 CEST] <luc4> Hello! Does anybody know if, starting the playback of a video using ffplay perfectly at the same time on different computers, I should expect a perfect sync?
[11:45:35 CEST] <luc4> I know from past experiences that perfect sync is very difficult& but what can explain this?
[12:28:38 CEST] <rjp421> send the absolute timecode from the source?
[12:29:55 CEST] <iive> luc4: mplayer had an option to sync using udp packets.
[12:30:19 CEST] <iive> just running players won't do it, even if they start at the same moment
[12:30:52 CEST] <iive> usually audio playback is used as reference clock and video is synced to it
[12:31:18 CEST] <luc4> iive: yes, I know, but mplayer is commonly useless for me as I work on embedded. I would just like to know first why this happens, Im pretty curious.
[12:31:44 CEST] <iive> however many audio cards have something called frequency drift, where the sampling is a percent off by the 44.1kHz.
[12:32:34 CEST] <luc4> iive: ok, so this frequency drift causes video to accumulate somehow a deloy, correct?
[12:32:36 CEST] <iive> it could be caused by e.g. temperature of the oscillator.
[12:33:06 CEST] <luc4> iive: which means the clock is slightly different, which causes the delay to increase?
[12:33:12 CEST] <iive> it would simply mean that all players would play at different speed.
[12:33:38 CEST] <iive> you won't notice it at first, but the longer it play, the more they would drift.
[12:33:44 CEST] <luc4> iive: very interesting& and so mplayer, or whatever other implementation, keeps this updated by re-seeking?
[12:33:55 CEST] <luc4> iive: perfectly reasonable.
[12:34:13 CEST] <iive> e.g. STB players have a way to fine-tune the audio sampling freqency.
[12:34:50 CEST] <iive> luc4: they have a master server and they hold frames until it says them it is ok to show them. so one leads, the other follows.
[12:35:44 CEST] <luc4> iive: oh& so whichever is leading slows down?
[12:36:17 CEST] <iive> it's more of a hack... i don't remember if the followers had audio...
[12:37:17 CEST] <luc4> iive: I have to say I implemented something similar in the past, I was more interested in knowing why this happened and of how other projects managed to handle these problems. It is very interesting& thanks for your time!!
[12:37:34 CEST] <iive> :)
[12:40:10 CEST] <iive> i've heard that vlc could resample the audio by software, however the sinc method that is usually used is quite troublesome when conversion frequencies are close. still, it is an option.
[12:44:15 CEST] <luc4> iive: interesting is that I noticed this lack of sync even in perfectly identical devices.
[12:47:14 CEST] <iive> as i said, it depends on the oscillator, that's analog tech and it always have some tolerance of differences.
[12:48:30 CEST] <iive> one way to make it more precise is to use very high frequency oscillator (e.g. like the cpu one) that runs in GHz and divide it down to kHz.
[12:48:47 CEST] <iive> since it is embedded device, it would be practical.
[12:49:09 CEST] <iive> it would be interesting to see if the CPU speed also differs a little.
[12:50:40 CEST] <luc4> iive: yes, it would be very interesting...
[12:53:33 CEST] <iive> but hey, I remember that even the first multicore AMD cpu's had synchronization problems.
[12:55:05 CEST] <iive> (there is a counter based on clock clicks that is accessible by cpu instruction.  however there was slight drift and programs got confused when moved from one core to the other).
[16:29:43 CEST] <floholl> Hi all, I've noticed that ffmpeg, by contrast to avconv, supports fades to/from alpha (rather than to/from black), e.g., fade=out:99:25:alpha=1. Is this a fairly recent feature in ffmpeg? Would it justify a switch from avconv to ffmpeg?
[16:41:27 CEST] <c_14> 2011 afaict
[16:42:34 CEST] <c_14> Whether or not that's worth switching is up to you.
[16:43:32 CEST] <floholl> c_14: Thanks
[18:45:15 CEST] <floholl> leave
[23:03:31 CEST] <worried> hello
[23:03:47 CEST] <worried> i need some help
[23:04:11 CEST] <worried> i'm trying to record a restricted stream
[23:05:18 CEST] <worried> it's detecting ffmpeg and blocking it
[23:05:45 CEST] <worried> it works fine with ffplay
[23:07:32 CEST] <c_14> What's it using to block it? User agent? Username/password? IP?
[23:09:12 CEST] <worried> user agent block
[23:09:42 CEST] <worried> i did specified a user agent, but it gives me 404
[23:09:51 CEST] <worried> but not with ffplay
[23:10:15 CEST] <worried> so it detected ffmpeg and blocked it
[23:10:52 CEST] <worried> how to make the stream thinks i'm using ffplay
[23:11:12 CEST] <worried> so i can record
[23:15:06 CEST] <c_14> ffmpeg and ffplay use the same libraries. They send the exact same http headers by default
[23:17:48 CEST] <worried> then why the stream is working only with ffplay
[23:18:08 CEST] <c_14> no clue
[23:22:40 CEST] <worried> http://pastebin.com/ashHvbPX
[23:22:58 CEST] <worried> stream is censored, as i'm not allowed to share it with general public
[23:23:52 CEST] <c_14> user-agent should be an input option
[23:23:56 CEST] <c_14> (before -i)
[23:24:51 CEST] <worried> same error
[23:29:08 CEST] <c_14> Can you pastebin the command and output with ffplay that works?
[23:31:45 CEST] <worried> http://pastebin.com/d4mZD5EA
[23:35:00 CEST] <c_14> Does just `ffmpeg -user-agent Lavf53.32.100 -i url' give the same 404?
[23:35:23 CEST] <worried> yes
[23:42:22 CEST] <c_14> No clue. Can't really think of anything they do differently that would cause that.
[23:54:56 CEST] <jookiyaya> anybody know how extract  subtitles .idx/.vob or .srt  from MKV file
[23:55:25 CEST] <jookiyaya> anybody know how extract  subtitles .idx/.vob or .srt  from MKV file  (i know how to do it from dvd (video_ts))
[23:55:56 CEST] <c_14> ffmpeg -i mkv -c:s copy -map 0:s:0 out.srt
[23:57:02 CEST] <jookiyaya> c_14  what about  .idx/.vob
[23:57:36 CEST] <c_14> Not entirely sure how ffmpeg handles that internally. Would need to see an ffprobe.
[23:57:54 CEST] <jookiyaya> c_14 do you know the difference between  .idx/.vob  and .srt ?
[23:58:31 CEST] <c_14> srt is a text subtitle format. idx/vob is picture
[23:58:40 CEST] <jookiyaya> exactly
[23:58:46 CEST] <jookiyaya> are you sure "ffmpeg -i mkv -c:s copy -map 0:s:0 out.srt" will work?  since  srt will require OCR
[23:59:10 CEST] <c_14> That command only works for extracting srt subtitles from mkv.
[23:59:31 CEST] <jookiyaya> let me try. i doubt it will work though
[00:00:00 CEST] --- Sun Apr 12 2015