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

[burek]

[00:38:57 CEST] <yashi> CounterPillow: TF is BLB?
[00:39:24 CEST] <CounterPillow> a user in here who gets his name spammed by some kid.
[01:47:06 CEST] <nine_milli> blb
[02:00:55 CEST] <koz_> I'm getting very bizarre behaviour from ffmpeg when I try to do a FLAC -> Ogg Vorbis conversion. I did a trace here: http://paste.debian.net/1092488/ Am I doing something wrong?
[02:24:47 CEST] <DHE> it's trying to convert the poster art into theora, the default video codec for .ogg. you might just want to remove it. add: -map 0:a just before the output filename
[02:30:54 CEST] <koz_> DHE: If I wanna keep it, do I have to specify -c:v and -b:v respectively?
[02:31:54 CEST] <DHE> I'm not sure, never tried it. but it sounds googlable. ffmpeg copy poster art or something...
[02:32:01 CEST] <koz_> DHE: OK, thanks, will try.
[02:34:21 CEST] <koz_> DHE: That _still_ blows up. Here's trace: http://paste.debian.net/1092490/
[02:38:25 CEST] <DHE> nope, I've left my area of knowledge.
[02:38:53 CEST] <koz_> DHE: Thanks anyway. This is causing me to question my own sanity - I've been using ffmpeg to do this kind of conversion for ages, and I've never had these kinds of issues.
[03:31:03 CEST] <nine_milli> blb
[03:35:26 CEST] <another> koz_: something rings a bell in my head
[03:36:18 CEST] <another> add:  -ar 48k
[04:01:43 CEST] <Hello71> koz_: I'm going to wager a guess that your encoder actually does have problems
[04:02:31 CEST] <Hello71> 96khz is ridiculous too, but I'm pretty sure it's not the problem
[04:08:34 CEST] <another> pretty sure it is
[04:08:51 CEST] <another> my tests here work
[04:11:17 CEST] <another> and i remember stumbling upon it a while ago. something about libvorbis not accepting certain sample rates which ffmpeg doesn't know about
[04:39:29 CEST] <nine_milli> blb
[05:00:02 CEST] <koz_> another and Hello71: I figured out the issue. I used the wrong -map command and ffmpeg assumed it was a video, not 'audio + cover art'. Fixed it up though.
[05:00:10 CEST] <koz_> Thanks for the help everyone!
[05:39:31 CEST] <hendry> hi, I tried out hevc_vaapi but it doesn't playback on IOS safari like it should https://caniuse.com/#search=hevc
[05:40:18 CEST] <hendry> can someone tell where I went wrong creating this video? https://s.natalian.org/2019-07-21/h-whodis.mp4 log file: https://s.natalian.org/2019-07-21/h-whodis.mp4.log
[06:10:25 CEST] <nine_milli> blb
[12:33:59 CEST] <viktorg> Hello, how does -init_hw_device work? Where is the "named global device" being created? Is this persistent? Where can I list created named global devices?
[12:36:59 CEST] <relaxed>  hendry: the frame size is 2688x1520
[12:38:21 CEST] <relaxed> maybe that;s too much for an IOS device?
[12:41:23 CEST] <relaxed> viktorg: did you see https://trac.ffmpeg.org/wiki/Hardware/VAAPI ?
[12:44:37 CEST] <viktorg> relaxed, I already saw this page. But it doesn't clarify where the "named global device" of the command `ffmpeg -init_hw_device vaapi=foo:/dev/dri/renderD128` (’ foo) is being created and where I can delete it (if I want).
[12:46:55 CEST] <relaxed> it's created by ffmpeg for use within ffmpeg
[12:49:24 CEST] <viktorg> but does it outlive the end of the process?
[12:49:46 CEST] <viktorg> so can I access the device foo after e.g. a reboot?
[12:50:18 CEST] <JEEB> I don't think any contexts created for the devices outlive a process unless there's a boog somewhere. the device should stay just fine, though?
[12:50:37 CEST] <JEEB> FFmpeg itself doesn't create the device
[12:51:07 CEST] <JEEB> and if it creates a named context for a device, then that of course is specific to that process
[12:51:16 CEST] <JEEB> since the naming is on FFmpeg's side I would guess
[12:52:04 CEST] <viktorg> so init_hw_device just creates something like an alias for a device for further usage in the command?
[12:52:49 CEST] <JEEB> most likely yes
[13:09:31 CEST] <sine0> what is the best format or the most 'safe' for mp3 in these dodgy little players and devices. would it be vbr or cbr
[13:12:33 CEST] <JEEB> safest would be to use something in a container, like AAC in mp4 :P
[13:12:51 CEST] <JEEB> if you *have* to use MP3, CBR means that seeking is more likely to work
[13:13:06 CEST] <JEEB> you have to remember that MP3 is raw bit stream without a container
[13:13:21 CEST] <JEEB> for some reason we ended up in a space-time continuum where that was considered acceptable
[13:13:40 CEST] <sine0> hmmm cool ok
[13:13:42 CEST] <JEEB> so most audio players that are software just index the mp3 files
[13:13:54 CEST] <JEEB> and that way you get to seek
[13:14:05 CEST] <JEEB> for plastic boxes
[13:14:09 CEST] <JEEB> all bets are off
[13:18:57 CEST] <sine0> what does ffmpeg use for mp3 encoding by default
[13:19:38 CEST] <sine0> im going to fire some questions at you now, I have a few
[13:19:49 CEST] <relaxed> libmp3lame
[13:20:19 CEST] <sine0> relaxed: so it has used the code from the lame_enc.dll i thought that needed paymet
[13:21:09 CEST] <relaxed> nope
[13:21:11 CEST] <JEEB> LAME is an open source project, so in that sense you can get the source code for free. what you can do with the source or binary depends on your local juristiction
[13:21:33 CEST] <JEEB> because unlike software licensing, patent licensing is a mess :P
[13:21:37 CEST] <JEEB> and I'm not a lawyer
[13:22:02 CEST] <JEEB> that said, I think Fedora finally enabled mp3 decoding some time ago so they apparently decided that at least decoding related patents in the US have vanished?
[13:23:03 CEST] <JEEB> that's btw why various modules for things like mp3 or aac generally from corporations require a payment. patents. :P
[13:23:15 CEST] <JEEB> or at least that's how I guess it goes
[13:29:21 CEST] <sine0> -ar is the rate so like 44100 etc, -ac is the channels so 1 for mono etc, what is the bit for 192 128 etc is that -aq
[13:30:48 CEST] <relaxed> -b:a 192
[13:31:03 CEST] <relaxed> -q:a is for vbr
[13:31:39 CEST] <relaxed> er, 192k
[13:34:02 CEST] <sine0> ok thanks
[13:37:51 CEST] <relaxed> sine0: https://trac.ffmpeg.org/wiki/Encode/MP3
[13:40:42 CEST] <sine0> ffmpeg is a real swiss army knife
[16:58:23 CEST] <nine_milli> blb
[16:59:49 CEST] <MoziM> what's the point of fractional frame rates?
[17:00:48 CEST] <JEEB> hysterical raisins
[17:01:18 CEST] <JEEB> xxx/1001 has been in use for ages in broadcast etc
[17:01:53 CEST] <JEEB> heck, even blu-rays are mostly 24000/1001 for films etc instead of 24
[17:02:11 CEST] <JEEB> (I've seen like one or two cases of straight 24Hz since it's accepted on blu-rays as well)
[17:07:05 CEST] <MoziM> i see...
[17:07:27 CEST] <MoziM> i'm asking because a bunch of old cartoons have 24.95587 whatever fps
[17:07:58 CEST] <MoziM> and i was wondering what someone would want to do that -_-
[17:18:35 CEST] <JEEB> MoziM: more likely to be variable frame rate or offset somewhat and whatever you're looking up the frame rate with does an average
[17:28:02 CEST] <[olli]> Re all. I misunderstand command options. This command is wrong: "ffmpeg -i ${dvr_source_stream_file}  -codec copy -frames:60:0  ${destination_stream_file}". destination file is not set. I want 60 frames in src be written into dst w/o any transformation - simple "cut". ffmpeg "thinks" that dst is missing. In man I see no option to specify dst stream "-something" - it always autoselected in TLDR easy samples. In result I'm confused - where
[17:28:02 CEST] <[olli]> I'm wrong? %)
[17:29:26 CEST] <JEEB> you miss spaces after frames since you probably didn't mean it to be limited to whatever is "60:0"
[17:29:50 CEST] <JEEB> and thus destination gets parsed as parameter for the -frames option
[17:29:51 CEST] <JEEB> :P
[17:30:09 CEST] <JEEB> for explicit stream mapping, if you ever need that try searching for -map in ffmpeg-all.html
[17:34:31 CEST] <[olli]> JEEB: hmm.. man says I should reference files from 0. 60:0 is 60 frames in file 0 in my mind. I want exactly 60 frames - trying to learn from simple cut. I will dig option -map in man ffmpeg-all. Thanks.
[17:37:13 CEST] <JEEB> [olli]: that is usually used with things that map to inputs. with an output you generally have just one and the options after input start again from zero as you put another output in
[17:37:34 CEST] <JEEB> so -map 0:v:0 would be "first input, video stream, #0 of previous"
[17:37:58 CEST] <JEEB> but in case of output side options you generally just have the stream number
[17:38:08 CEST] <JEEB> like -c:v:0 copy
[17:38:32 CEST] <JEEB> codec for "video, 0th stream" gets set to copy
[17:39:40 CEST] <JEEB> I'm not sure if the frames option is even stream dependent, but in any case -frames:v:0 60 sounds more like it if you mean the first video stream of your output
[17:40:22 CEST] <JEEB> (you don't need the stream type specifier but generally simpler than to keep your mind on what got selected as which stream from the input)
[18:36:20 CEST] <[olli]> JEEB, thank you and one more question - I don't know how many streams in dvr source file. Is there a simple way how to find out number of streams - what options I should point my attention to? My idea is cut 200 frames and ffmpeg should write all found frames into output files with names like output.stream1 output.stream2 .. output.streamN . Should this work and what option lands stream to file names with autonaming?
[18:46:32 CEST] <nine_milli> blb
[18:58:56 CEST] <JEEB> [olli]: either make your own API client, or utilize ffprobe with -of json -show_streams -show_programs
[18:59:24 CEST] <[olli]> thanks!
[22:02:55 CEST] <nine_milli> blb
[00:00:11 CEST] --- Mon Jul 22 2019