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

[burek]

[01:02:46 CEST] <DHE> marcoslater: there's a setsar and setdar filter to help during encoding time
[01:41:20 CEST] <hiru> hello I have a issue with video filters and subtitles. I can import subtitles from a file only if I previously use cd moving in the video file and using the file name instead of the full path
[01:41:24 CEST] <hiru> why is this happening?
[01:41:41 CEST] <hiru> *moving in the video file path
[01:50:27 CEST] <marcurling> hiru: which OS are you using? maybe try to double quote full path...
[01:55:33 CEST] <nicolas17> yeah do you have spaces in your paths?
[02:01:37 CEST] <hiru> using win10
[02:02:07 CEST] <hiru> the command is something like: -vf "scale=-1:360,subtitles='file_path'"
[02:02:59 CEST] <hiru> the output command and the error in the output report the path correctly
[02:03:10 CEST] <hiru> the error says "no such file or directory.." tho
[02:04:03 CEST] <hiru> something I forgot to mention is that the file is shared via smb so the beginning part of the path is "\\device\path\to\file.mkv"
[02:11:33 CEST] <nicolas17> the backslashes are probably interpreted in a special way
[02:13:26 CEST] <hiru> Error reinitializing filters! Failed to inject frame into filter network: Invalid argument Error while processing the decoded data for stream #0:0
[02:13:30 CEST] <hiru> what does it mean
[02:14:11 CEST] <hiru> I always use " and ' to enclose paths so there should be no problem with spaces or special characters
[02:20:26 CEST] <hiru> I tried escaping the \ characters adding an additional \ before each one of them but it didn't help, same error
[02:30:21 CEST] <marcurling> hiru Do you have to double quote your -vf params? I use smb pathes also (but only for input or output file) : seems to me I had some similar error when using filters
[02:30:52 CEST] <hiru> I have the scale parameter too so I have to quote the whole -vf thing somehow
[02:31:19 CEST] <marcurling> using filters under Win seems to 'corrupt' prarmeters/options parsing
[02:32:03 CEST] <hiru> maybe I should open a issue on github about this
[02:32:44 CEST] <marcurling> wouldn't -vf scale=-1:360 -vf subtitles="file_path" work?
[02:33:46 CEST] <hiru> I think you can use only one -vf parameter. one of the two will be ignored in the end
[02:36:49 CEST] <hiru> I'll try again with the same command on the host pc since there is raspbian installed
[02:39:57 CEST] <marcurling> so try to put your -vf param in a var (and eventually in a .bat)
[02:42:06 CEST] <marcurling> syntax should be: (I'm looking for it...)
[02:45:46 CEST] <slalom> anybody here have nielsen encoding in their pipeline?
[02:45:48 CEST] <slalom> in production
[02:46:35 CEST] <nicolas17> no idea what it is
[02:46:51 CEST] <slalom> nielsen watermarks
[02:46:55 CEST] <slalom> e.g. for nielsen ratings
[02:47:11 CEST] <slalom> if you're not in the US you probably won't know what that is
[02:47:59 CEST] <slalom> their VOD encoder only supports ac3 audio properly and inside mpegts only.. and since we don't use any of those formats i have to convert the WAV to an mpegts container, encode and export it for our actual pipeline that makes all the versions
[02:48:03 CEST] <slalom> super lame
[02:48:39 CEST] <slalom> also its through a GUI, i was wondering if anyone has done it with command line
[02:56:20 CEST] <marcurling> hiru I think your problem comes from the simple quotes for path (I just test it): it should be double ones
[02:56:54 CEST] <marcurling> Let see if inverting the simple and double quotes in your given example works
[04:34:17 CEST] <convert> that sucks that ffplay doesnt work with SDL-1 anymore. it immediately broke stuff I've been using for 10 years
[04:34:42 CEST] <convert> the software renderer gives an black screen, and the opengl renderers cannot be maximised
[04:35:37 CEST] <convert> i mean it is a good thing not to depend on a renderer
[04:36:10 CEST] <convert> maybe i should try disabling the option in sdl
[04:40:36 CEST] <convert> i reverted back to 2.9 anyway
[04:44:03 CEST] <nicolas17> SDL1? what year is it?
[04:49:31 CEST] <convert> nope "SDL: could not set video mode - exiting"
[04:49:49 CEST] <convert> the year when things stop working because of "progress"
[05:57:38 CEST] <convert> sdl1's on x11 was superior, dropping support is most likely the work of some agency infiltrate
[05:58:13 CEST] <convert> luckily other players that use ffmpeg still support sdl1
[05:59:11 CEST] <convert> pity that the best player that shipped with ffmpeg itself fails completely, the diabolical hand in development
[07:14:37 CEST] <convert> disabling AV_PIX_FMT_YUV420P in ffplay.c fixes the fullscreen issue
[07:14:53 CEST] <convert> with the opengl renderer
[07:15:20 CEST] <convert> i mean with the software renderer
[07:15:39 CEST] <convert> disabling AV_PIX_FMT_YUV420P in ffplay.c makes the software renderer work again, including fullscreen
[07:16:11 CEST] <convert> opengl renderer still has problems
[07:37:13 CEST] <convert> with opengl renderer it needs to be SDL_WINDOW_FULLSCREEN not SDL_WINDOW_FULLSCREEN_DESKTOP
[07:43:05 CEST] <relaxed> convert: file a bug report
[09:54:46 CEST] <durandal_1707> i like when they tell its agency doings
[11:04:02 CEST] <blaze06> anyone here who can help me with some questions??
[15:05:49 CEST] <JC_Yang> are there good ways to read/parse sps nal unit in h264 streams?   from the public api, I can't figure out a way to read the desired parameter, that's no obvious side data types which represent fps in AVPacket, for example.
[15:10:39 CEST] <BtbN> you get the packet timestamp
[15:11:03 CEST] <BtbN> The h264 parsing API is private as far as I'm aware
[15:11:17 CEST] <JC_Yang> avg_frame_rate in AVStream is 0, so have to read sps(maybe libavformat does not do it for me in raw streams)
[15:11:51 CEST] <BtbN> pts
[15:11:53 CEST] <JEEB> it does get some "possibly the frame rate" from raw AVC streams, though. if you ffprobe the file you should see it
[15:11:54 CEST] <BtbN> not avg_frame_rate.
[15:12:31 CEST] <BtbN> I also don't think a raw h264 stream has a framerate. You need a container for that.
[15:12:37 CEST] <JC_Yang> I haven't analyzed the stream myself, but players like mpc-hc do recognize the fps correctly, so I think there should be a way to do it with libavformat
[15:13:01 CEST] <JEEB> just check what ffprobe says :P
[15:13:04 CEST] <JEEB> first
[15:13:16 CEST] <JEEB> before saying things about libavformat
[15:13:22 CEST] <BtbN> is it a raw h264 file, or some container?
[15:13:31 CEST] <JC_Yang> raw
[15:13:40 CEST] <BtbN> there's no framerate/timestamps then
[15:13:46 CEST] <JEEB> you will get the "maximum time base" thing from the parameter sets, and IIRC lavf does parse that
[15:13:50 CEST] <JEEB> you would see that in ffprobe
[15:21:17 CEST] <JC_Yang> just confirmed, yes, ffprobe do recognize the fps. then how to do it in with its public api? I've tried, av_open_input() yet nothing usable from AVStream   pts time_base and avg_frame_rate are both 0, and when I read each frame av_read_frame, all pts are set to 0 too. any clues?
[15:21:58 CEST] <BtbN> ffprobe only uses public API
[15:22:12 CEST] <BtbN> if it is able to do some guess on the framerate, look at what prints it and where it comes from
[15:22:27 CEST] <JC_Yang> so I'm asking for suggestions here
[15:22:30 CEST] <BtbN> But I wouldn't be surprised if it just displays the default fps guess, which happens to be right for this sample
[15:23:26 CEST] <JC_Yang>  Duration: N/A, bitrate: N/A
[15:23:27 CEST] <JC_Yang>     Stream #0:0: Video: h264 (Main), yuvj420p(pc, bt709, progressive), 1280x720, 25 fps, 25 tbr, 1200k tbn, 50 tbc
[15:26:05 CEST] <BtbN> the fps there is from AVFormatContext::streams[x]::avg_frame_rate
[15:26:20 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/dump.c#L510
[15:27:22 CEST] <BtbN> And I think 25 is just the default if nothing is set?
[15:27:55 CEST] <JEEB> yes, although I clearly remember it also can parse the maximum time base value if it's there. but yes, with 25 it's not easy to know which you're currently having there
[15:28:08 CEST] <JEEB> without maybe some -v debug? not sure if the H.264 parser logs that stuff, though
[15:29:02 CEST] <BtbN> I'm not aware of the h264 parser exporting and framerate/timestamp info
[15:29:05 CEST] <BtbN> *any
[15:29:16 CEST] <JEEB> well demuxer really
[15:29:29 CEST] <JEEB> but yes it will lack a lot of the timestamp fields
[15:29:34 CEST] <JEEB> as you demux stuff
[15:29:58 CEST] <BtbN> I also don't think any of that information is there in a raw h264 stream?
[15:30:24 CEST] <JEEB> there's a "maximum time base" thing which many things take as "frame rate"
[15:30:43 CEST] <JEEB> yea, checked ffprobe with an old encode of mine that was still a raw bit stream
[15:30:48 CEST] <JEEB> it gets the 24000/1001
[15:31:16 CEST] <JEEB> but I distinctly remember that lavf is bad at properly calculating time stamps for those things if you try to mux them with that rate into a container
[15:31:25 CEST] <JEEB> which is why I usually use L-SMASH's muxer for that
[15:31:43 CEST] <JEEB> but yes, the information is most definitely exported if it's there in the bit stream :P
[16:00:28 CEST] <JC_Yang> just tried ffprobe with -v debug, it indicate that ffprobe does read sps(nal unit type 7 and 8) and pps, which is what I suspected, same as my initial question, how to do so in with the public api?
[16:02:55 CEST] <JC_Yang> hmm...  I may know the solution now.
[16:03:36 CEST] <JC_Yang> avformat_find_stream_info() should come to rescue. let me try it
[17:18:44 CEST] <JC_Yang> it is confirmed as the solution, thank u
[17:19:17 CEST] <BtbN> What field does it set its framerate guess?
[17:19:30 CEST] <BtbN> And I still don't think it will lead to valid timestamps unless you make some up yourself
[17:24:53 CEST] <Filystyn> how to make video louder but keep video quality
[17:25:12 CEST] <Filystyn> ffmpeg -i vid1 -vol 1280 vid2  this has killed my quality
[17:34:21 CEST] <ChocolateArmpits> Filystyn, copy the video stream while encode only the audio ?
[17:34:34 CEST] <ChocolateArmpits> use -vcodec copy
[17:34:53 CEST] <BtbN> -c:v
[17:34:56 CEST] <BtbN> vcodec is deprecated.
[17:36:54 CEST] <Filystyn> nvm got it
[19:15:31 CEST] <Ommand> stupid question for you guys, lets say I'm cutting a video with the following command
[19:15:37 CEST] <Ommand> ffmpeg -ss 00:00:30 -i input.mp4 -t 45 output.mp4
[19:15:58 CEST] <Ommand> does that preserve all the previous encoder settings? it seems like it probably does
[19:16:19 CEST] <atomnuker> use -c copy and it will, otherwise it reencodes
[19:16:34 CEST] <Ommand> yea I need it to re-encode to remove black bits caused by key frames
[19:20:16 CEST] <kerio> black bits?
[19:20:26 CEST] <ChocolateArmpits> Ommand, outside of profile, level , pixel format used it won't preserve previous settings
[19:20:42 CEST] <Ommand> kerio: a couple of seconds of video will be black until it hits the next key frame
[19:20:49 CEST] <Ommand> ok ChocolateArmpits thanks
[19:20:57 CEST] <Ommand> suppose my best bet is to just cut at key frames and deal with the rest later
[19:21:06 CEST] <JEEB> ChocolateArmpits: uhh no. it will not
[19:21:12 CEST] <JEEB> profile depends on what the encoder picks depending on your parameters
[19:21:15 CEST] <JEEB> level's the same
[19:21:39 CEST] <ChocolateArmpits> well in his case there are no custom parameters
[19:21:42 CEST] <JEEB> literally the only thing that generally doesn't change unless you specify it is the pixel format, but you cannot promise that either (since ffmpeg.c will convert between them)
[19:22:03 CEST] <JEEB> even with that, how the <bleep> do you know how his original videos were encoded
[19:22:23 CEST] <ChocolateArmpits> well if the resolution is hd i wouldn't expect the level to be below 4
[19:22:41 CEST] <Ommand> well regardless, using that command I'll be reducing video quality for no reason
[19:22:46 CEST] <kerio> WTF is level
[19:22:46 CEST] <Ommand> no benefit, rather
[19:22:50 CEST] <JEEB> making such promises that sound like some parameters get parsed from the input stream and the encoder gets configured to that (which, btw, doesn't make any sense)
[19:22:58 CEST] <JEEB> is just bullcrap
[19:23:28 CEST] <JEEB> kerio: in video formats usually profiles = features available/used by the stream, level = how much memory the decoder requires to decode the clip
[19:23:34 CEST] <ChocolateArmpits> i never implied it honors previous settings
[19:23:56 CEST] <ChocolateArmpits> just that he shouldn't expect other settings to actually match on output
[19:23:59 CEST] <JEEB> > "outside of profile, level, pixel format used it won't preserve previous settings"
[19:24:06 CEST] <Ommand> alright well, it sounds like you guys could really use a drink
[19:24:11 CEST] <JEEB> that's a fucking literal quote of what you just mentioned
[19:24:13 CEST] <Ommand> so I'm jsut gonna go, thanks for the help
[19:24:15 CEST] <JEEB> np
[19:24:52 CEST] <JEEB> I know I might sound anal but not giving people weird ideas is the best way of helping them with regards to the future
[19:26:25 CEST] <kerio> oh so profiles and levels are things used by hardware accel
[19:26:33 CEST] <kerio> meh
[19:27:04 CEST] <JEEB> well they are ways of marking the streams regarding features/memory required
[19:27:29 CEST] <JEEB> x264 sets the profile and level automagically to the minimum values based on the parameters given to it
[19:27:46 CEST] <JEEB> (and if you set the profile/level to less than that, it will then constrain the encoder)
[19:28:22 CEST] <JEEB> but basically yes, with SW decoders it generally doesn't matter other than profiles that enable usage of things like non-4:4:4 or non-8bit
[19:28:27 CEST] <JEEB> *non-4:2:0
[19:28:46 CEST] <JEEB> because non-libavcodec software decoders often don't support non-4:2:0 or non-8bit
[19:29:07 CEST] <JEEB> (mainconcept which is utilized by adobe's flash being one of the exceptions, suporting up to 10bit 4:2:2)
[19:30:08 CEST] <kerio> why would you use that :^)
[19:30:26 CEST] <JEEB> that's a whole separate discussion.
[19:30:36 CEST] <kerio> jk I like QuickTime accelerated decoding
[19:31:23 CEST] <JEEB> but yea, the profiles and levels mostly became a real thing with AVC, before that the landscape of decoders used to be much more chaotic
[19:32:11 CEST] <JEEB> mpeg-4 part 2 being one of the major headaches of early/middle 2000s if you cared about plastic toys
[20:11:41 CEST] <samgoody> Hi,
[20:11:53 CEST] <samgoody> Am trying to use ffmpeg on Ubuntu 16.04
[20:15:48 CEST] <samgoody> apt-get claims it is up to date, but the version is ffmpeg version 2.8.11-0ubuntu0.16.04.1 Copyright (c) 2000-2017 the FFmpeg developers
[20:17:37 CEST] <kerio> isn't 16.04 a LTS releas3
[20:17:40 CEST] <DHE> up-to-date is relative. long term supported distros prefer to backport bugfix patches.
[20:17:41 CEST] <kerio> release
[20:17:45 CEST] <kerio> it's like super old
[20:18:22 CEST] <DHE> which is good for reliability of existing scripts and apps which depend on an ABI or parameter option specification, but bad for being truly "up to date"
[22:11:07 CEST] <DeHeiligeGeest> could someone explain to me how HLS kinda works
[22:11:17 CEST] <DeHeiligeGeest> specifically, you've got 1 big .mp4
[22:11:28 CEST] <DeHeiligeGeest> you split that up into parts, it creates a playlist file
[22:11:34 CEST] <DeHeiligeGeest> (ffmpeg can do this)
[22:11:47 CEST] <DeHeiligeGeest> but then it's only one quality right? how do you generate 'SD' or 'HD'
[22:12:49 CEST] <c3r1c3-Win> You create the split files for each resolution.
[22:13:13 CEST] <c3r1c3-Win> and in the m3u8 file you follow the Apple specs/guidelines for the new m3u8 file.
[22:13:27 CEST] <c3r1c3-Win> +*for the expanded/multi-bitrate m3u8 file.
[22:13:53 CEST] <DeHeiligeGeest> aye, cool
[22:14:12 CEST] <DeHeiligeGeest> second question: should there only be one playlist?
[22:14:39 CEST] <DeHeiligeGeest> in the scenerio that there are 2 versions
[22:14:49 CEST] <DeHeiligeGeest> (one low quality, one high)
[22:14:54 CEST] <JEEB> HLS has a definition of master and non-master playlists
[22:14:59 CEST] <JEEB> master playlist is a "meta" playlist
[22:15:04 CEST] <JEEB> which lists the alternatives
[22:15:05 CEST] <DeHeiligeGeest> haha, ok kill me now
[22:15:14 CEST] <JEEB> then the non-master ones actually contain the timeline
[22:15:25 CEST] <JEEB> just read the spec if you want to know how it works :P
[22:15:29 CEST] <DeHeiligeGeest> fair enough
[22:15:34 CEST] <JEEB> https://tools.ietf.org/html/draft-pantos-http-live-streaming-23
[22:15:40 CEST] <JEEB> that IIRC was the most recent version
[22:15:54 CEST] <DeHeiligeGeest> I was just hoping someone made one big bash file that ... does all :P (create the 2 streams, one playlist)
[22:16:42 CEST] <DeHeiligeGeest> ok, ill read that RFC. If meanwhile you can think of any scripts that can do this somewhat easily, do let know
[22:17:16 CEST] <JEEB> lavf can create the media playlists :P you can set the name for them
[22:17:28 CEST] <JEEB> creating a master playlist for them shouldn't be too hard :P
[22:17:57 CEST] <DeHeiligeGeest> I think I'm currently able to create a master playlist using: https://github.com/bentasker/HLS-Stream-Creator
[22:18:19 CEST] <DeHeiligeGeest> (yes im cheating)
[22:18:35 CEST] <DeHeiligeGeest> i just need 2 versions (SD/HD)
[22:22:08 CEST] <DHE> I'm using HLS. Honestly my "master" playlist is just the same file for everything (since it's all relative paths). to the point that I'm hard linking them. :)
[22:22:27 CEST] <JEEB> sounds good enough
[22:22:33 CEST] <DHE> and ffmpeg can handle the rest
[22:22:35 CEST] <JEEB> since you know what your file names
[22:22:41 CEST] <JEEB> for the media playlists
[22:24:21 CEST] <DeHeiligeGeest> apple should be banned from creating RFCs or any kind of protocol/interface
[22:25:10 CEST] <DHE> I don't think it's all THAT bad. I'd rather HLS than having to parse the XML of DASH most days
[22:25:24 CEST] <DeHeiligeGeest> the fact its over http is cool i guess
[22:25:42 CEST] <DeHeiligeGeest> but right now im trying to understand how to generate those master/meta playlist or whatever
[22:25:44 CEST] <DeHeiligeGeest> and i dont get it
[22:25:59 CEST] <JEEB> go look at the examples at the end of the spec :P
[22:26:01 CEST] <DHE> there's a whole section of examples in the spec
[22:26:03 CEST] <JEEB> like seriously
[22:26:03 CEST] <DHE> yes, that
[22:26:40 CEST] <furq> 8.4 should be all you need
[22:26:48 CEST] <furq> it's not exactly complicated
[22:27:10 CEST] <DeHeiligeGeest> take 8.4 as an example yes
[22:27:31 CEST] <DeHeiligeGeest> oh
[22:28:01 CEST] <DHE> 8.5 is an example with relative paths. which is where I get away with using 1 master playlist consistently
[22:28:45 CEST] <DeHeiligeGeest> i dont see why you would want to hardcore the domain + scheme in there
[22:28:47 CEST] <DeHeiligeGeest> @ 8.4
[22:29:22 CEST] <DeHeiligeGeest> s/hardcore/hardcode
[22:29:43 CEST] <DHE> depends. many of the decisions in the draft imply the use of a content delivery network (eg: Akamai). after all, it's just HTTP
[22:30:14 CEST] <DHE> so you might be offloading content delivery to another company
[22:30:27 CEST] <DeHeiligeGeest> fair nuff
[22:31:52 CEST] <DHE> and of course its' an example. they want to cover all sorts of concepts there
[22:33:16 CEST] <DeHeiligeGeest> HA. that bash thing I linked earlier can already do exactly what I want it seems
[22:33:35 CEST] <DeHeiligeGeest> that means I can stay a script kiddie and avoid having to read the RFC
[22:33:44 CEST] <DeHeiligeGeest> mua-ha-ha
[22:33:58 CEST] <JEEB> well not like the master playlists are dark magic
[22:34:03 CEST] <DeHeiligeGeest> true
[22:34:08 CEST] <DeHeiligeGeest> well thanks for the explanation anyway
[22:35:41 CEST] <DeHeiligeGeest> yep, it worked :) cool script, ill link it again: https://github.com/bentasker/HLS-Stream-Creator
[00:00:00 CEST] --- Mon Jul  3 2017