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

[burek]

[00:00:04 CEST] <JEEB> I've also been looking into seeing if closed captions encoding could be done in FFmpeg :P
[00:00:46 CEST] <JEEB> (also because most web subtitle formats don't support subtitles that are shown until the next packet comes)
[00:01:02 CEST] <JEEB> as in, you can't pass a subtitle line through the system until you know when the subtitle ends
[00:01:20 CEST] <JEEB> stuff like SRT/ASS/WebVTT/TTML require that IIRC
[00:01:38 CEST] <JEEB> while for live streams you generally don't get stop times as input
[00:01:59 CEST] <JEEB> your stop time is when the next "reset" packet or next subtitle comes :P
[00:02:55 CEST] <poutine> I haven't looked at its actual data structure in the byte stream, I understand a lot of the SCC data (buffering, repeating command bytes, reset) but have no clue what that all ends up as in the byte stream
[00:03:20 CEST] <JEEB> you can look at the decoder I guess for hints
[00:03:33 CEST] <JEEB> also the specification IIRC is available on the interwebs as some FCC document?
[00:03:51 CEST] <JEEB> as opposed to the official one
[00:04:15 CEST] <poutine> Are you aware of any efforts to start that encoder? I feel like I've gone through every posting related to embedded captions on the lists
[00:04:35 CEST] <JEEB> not that I know, most use cases are about pass-through
[00:04:52 CEST] <JEEB> or decoding for conversion into "conventional" subtitle formats and/or playback
[00:11:16 CEST] <poutine> JEEB, A lot of our use case is that we mux subtitles on existing renditions without re-transcoding them, Do you have any idea how that would look like from a command line perspective? ffmpeg -i foo.srt -i foo.mp4 -c copy muxed.mp4 would not make much sense, not as a filter either are there any existing ways of using ffmpeg which just would augment the AVFrames/AVPackets without re-transcoding as an example?
[00:11:22 CEST] <vincerubinetti> Hello there. I'm trying to report a bug through the Trac system, but it's not letting me register an account (can't get past the anti-spam). Can someone help me with that?
[00:12:11 CEST] <vincerubinetti> the bug report i'm trying to file is related to this: https://bugs.chromium.org/p/chromium/issues/detail?id=884526
[00:12:52 CEST] <JEEB> poutine: `ffmpeg -i foo.srt -i foo.mp4 -c copy -c:s cc remux.mp4`
[00:13:23 CEST] <JEEB> although you would have to make custom logic in ffmpeg.c so that it doesn't try to write the closed captions as a separate closed captions track
[00:13:59 CEST] <JEEB> and with remuxing it's always fun to try and get the AVPacket right :P
[00:14:36 CEST] <JEEB> because you do get some timestamps, but due to b-frame reordering etc it can be fun to figure out at which point you should stick the closed caption packet into the AVPacket
[00:15:00 CEST] <poutine> JEEB, Ok not confident in my abilities to perform all this, I have written quite a bit of C, but not on a project of ffmpeg's scale. I appreciate the starting tips to look into here
[00:24:19 CEST] <vincerubinetti> can anyone help me file a bug
[00:35:39 CEST] <JEEB> poutine: well your first part is to be able to generate closed caption AVPackets
[00:36:36 CEST] <JEEB> so look at some relatively simple subtitle encoder, and then try to either implement captioning, or if libcaption or so has a nice encoding API for the data packets (and is under a reasonable license that's compatible) just use such a library
[01:12:39 CEST] <nicolas17> is there any good free tool to create and edit subtitles?
[01:12:47 CEST] <nicolas17> or do I stick to YouTube's web editor? :p
[01:21:39 CEST] <raytiley> JEEB: "I've also been looking into seeing if closed captions encoding could be done in FFmpeg" do you mean taking time / text and encoding it to actual cc608 or cc708?
[01:29:35 CEST] <JEEB> raytiley:
[01:29:36 CEST] <JEEB> yes
[01:29:42 CEST] <JEEB> (anyways, sleep time for me)
[01:29:49 CEST] <JEEB> (office in ~6.5h hours)
[01:30:04 CEST] <raytiley> Sorry. Thanks
[05:17:08 CEST] <rjeli> so I have a recorder application that takes webcam frames, feeds them into a CodecContext and saves the packet data with the dts and pts. However, when I take these binary records and reconstruct the AVPackets with the correct dts and pts, then mux them into a container, I get a lot of dropped frames and little jumps forward
[05:18:00 CEST] <rjeli> I'm not really sure where to start debugging it. Could ffplay not have enough lookahead to do reordering? I'm not sure how reordering is even implemented
[05:20:05 CEST] <rjeli> it's libx265 if that's relevant, with no tuning options
[08:51:05 CEST] <jsollie> hello everyone, I have a follow-up question about my VAAPI questions a few days ago:
[08:52:43 CEST] <jsollie> when using Tonga/Fiji/Polaris, is it normal that when using HW Decode on an mpeg2 movie stream, and encoding it in hardware, the output is worse than decoding it on the CPU and encoding in hardware?
[08:54:18 CEST] <jsollie> because that's what I see on the movie stream: when using the VAAPI decoder and encoding it on the GPU, the output is really bad quality, but when using the h264 software decoder and uploading to the polaris/fiji/tonga chip, the output is fine
[08:54:42 CEST] <jsollie> any suggestions?
[08:56:08 CEST] <jsollie> sorry, not a h264 software decoder, a mpeg2 software decoder
[08:57:12 CEST] <jsollie> I also tried this with the h264 software encoder, but the result is the same: when using the mpeg2 decoder in hardware, the output is terrible
[14:24:48 CEST] <kepstin> jsollie: you'd want to try using the hardware vs. software decoder along with a software encoder to try to isolate the issue
[14:32:35 CEST] <kepstin> oh, wait, i see you did
[14:33:11 CEST] <kepstin> can you describe the types of video artifacts you're seeing?
[14:34:22 CEST] <kepstin> but yeah, I wouldn't be surprised if it's a buggy driver or firmware or something.
[15:05:44 CEST] <jsollie> do you have specific names for video artifacts? I mean, it just looks like very low bitrate video
[15:05:54 CEST] <jsollie> not really artifacts
[15:06:05 CEST] <jsollie> the color is grouped together in blocks
[15:06:29 CEST] <jsollie> which are more or less related to what it should be
[15:07:03 CEST] <jsollie> so it is not really an error, more like a decoder incompletion
[15:09:58 CEST] <Gamoder_> Hi everyone, is it possible to do 'non-realtime' software h264 decoding with multiple threads, i.e. that multiple threads start decoding beginning from the next n keyframes and store the result in the RAM?
[15:11:59 CEST] <BtbN> Probably, if someone writes a decoder that does that. But why?
[15:14:43 CEST] <jsollie> no idea, with vdpau to the display rendering it is all ok.  Maybe I should use the vaapi->vdpau backend (no idea what it exactly does and what the disadvantages are) instead of radeonsi
[15:15:03 CEST] <iive> i don't get what is the difference than what the current "realtime" decoder does. The multiple threads things is limited by the dependency of the frames from each-other.
[15:15:49 CEST] <iive> mesa3d supports vdpau and vaapi natively, no wrappers needed.
[15:15:58 CEST] <jsollie> oh, wait, Btbn's question wasn't to me
[15:16:00 CEST] <iive> i mean, for radeon.
[15:16:25 CEST] <jsollie> or was it?
[15:16:34 CEST] <jsollie> what are we talking about?
[15:16:48 CEST] <jsollie> Gamoder's question or mine?
[15:16:52 CEST] <jsollie> :s
[15:17:06 CEST] <iive> jsollie, what is your question?
[15:19:18 CEST] <jsollie> why does MPEG2 VAAPI decode on (tonga, fiji, polaris) give a worse quality compared to software decoding of mpeg?
[15:20:29 CEST] <jsollie> ttried this with software and hardware encoder to h264
[15:20:53 CEST] <jsollie> but the result is awful with hardware vaapi decoder
[15:22:35 CEST] <jsollie> anyway, kepstin suggested something, but I don't know if you guys are currently helping Gamoder or me, so I'll shut up and listen
[15:24:38 CEST] <iive> the only explanation is that the hw decoding is doing something wrong.
[15:25:20 CEST] <jsollie> that's why I tought of trying VDPAU backend for VAAPI
[15:25:33 CEST] <iive> mpeg2 has short GOP (aka keyframe every second), because of imprecise dct
[15:26:44 CEST] <iive> that's not going to change anything... because the work would be done by the same driver/hw
[15:27:10 CEST] <iive> wrappers could only add bugs, not fix them.
[15:28:10 CEST] <jsollie> ok, but why does playing the mpeg2 with vdpau work?
[15:28:23 CEST] <jsollie> the quality is fine when just playing it
[15:33:07 CEST] <iive> ?
[15:33:58 CEST] <iive> if using vaapi and vpdau is different, then fill a bug with the driver.
[15:34:46 CEST] <jsollie> the source video is an mpeg2 file.  When rendering it to the screen, the quality is fine.  When transcoding with software decoder, the quality is also fine.  When using VDPAU with software or hardware encoder, the result is awful
[15:35:07 CEST] <jsollie> *VAAPI, not VDPAU
[15:35:38 CEST] <jsollie> that's the summary
[15:36:51 CEST] <jsollie> iive: is this a mesa or amdgpu problem?
[15:39:28 CEST] <iive> oh, encoder
[15:39:44 CEST] <iive> i got completely different situation.
[15:40:55 CEST] <jsollie> no, my problem is when decoding mpeg with vaapi
[15:41:43 CEST] <jsollie> decoding mpeg on the amdgpu with vdpau is ok (when I look at the screen)
[15:42:26 CEST] <jsollie> software transcoding to vaapi or software x also works fine
[15:43:30 CEST] <jsollie> but hardware vaapi transcoding to either vaapi or software x264 gives an awful result
[15:46:54 CEST] <jsollie> the question is: should I report this to mesa or to the kernel developers?
[15:48:21 CEST] <iive> well, hardware encoders are known to produce bad encodes, First, make sure you give them options that would produce good results
[15:48:39 CEST] <iive> aka big bitrates, low quantizers, stuff like that.
[15:48:41 CEST] <kepstin> iive: this is a problem with the hardware *decoder* not encoder.
[15:49:02 CEST] <kepstin> jsollie: this video transcodes fine if you use the software decoder, you said?
[15:49:05 CEST] <iive> didn't he just said the opposite?
[15:49:18 CEST] <iive> that decoding mpeg source produces good quality.
[15:49:53 CEST] <jsollie> kepstin: yes
[15:50:21 CEST] <jsollie> iive: when decoding to the screen (eg, with mplayer), it is fine
[15:50:24 CEST] <kepstin> honestly, mpeg2 is sufficiently low complexity that i'd just use the software decoder, especially if it's SD.
[15:51:06 CEST] <jsollie> ?
[15:51:39 CEST] <kepstin> jsollie: can you confirm using mpv that decoding with vaapi displays correctly? (it should indicate on console output whether it's actually doing hardware decoding)
[15:52:35 CEST] <kepstin> the last time i bothered using hardware accellerated mpeg 2 decoding, I was using xvmc on a mach64 card with a pentium 3 :/
[15:52:47 CEST] <jsollie> lol
[15:54:04 CEST] <jsollie> wouldn't it be faster to transcode a mpeg2 movie to h264 when it can be decoded on the gpu and the raw data is kept in gpu memory?
[15:54:51 CEST] <kepstin> jsollie: the only reason to transcode such a file is if you're really limited on storage space, or you need to transcode for a device that doesn't support mpeg2.
[15:55:19 CEST] <kepstin> jsollie: and if you're archiving the resulting file, rather than just using it live, you should probably be using a software h264 encoder for improved quality/efficiency.
[15:56:07 CEST] <jsollie> are radeon VCEs really that bad?
[15:56:24 CEST] <kepstin> all hardware encoders are that bad. the nvidia one is less worse than amd.
[15:57:08 CEST] <jsollie> so why do they exist?
[15:57:50 CEST] <kepstin> my impression is that the hardware encoders on gpus are mainly there for people doing live encoding/streaming while gaming or using other intensive apps, since the cpu and gpu are already busy.
[15:58:14 CEST] <kepstin> although nvidia also markets theirs on the quadro cards as being good for live transcoding of large numbers of streams
[15:59:20 CEST] <jsollie> so when I understand it correctly, I shouldn't be using a vaapi system at all when I have a 32-core cpu?
[15:59:54 CEST] <kepstin> jsollie: x264 on a modern 32core cpu with HD+ content should be both faster and better quality than using the amd gpu encoder :/
[16:00:17 CEST] <kepstin> (or alternately slower and much better quality)
[16:00:27 CEST] <kepstin> (where by "quality" i mean "efficiency")
[16:01:01 CEST] <jsollie> ok, then let's stop the dumb idea then.  Thank you for the clarification
[17:09:08 CEST] <linuxmaster> test
[17:09:18 CEST] <linuxmaster> wow...
[17:09:25 CEST] <linuxmaster> Hello!
[17:10:39 CEST] <linuxmaster> I have ffmpeg stream to rtsp server.... And I need to make ptime=20 in my rtp streams... How to do it?
[17:46:24 CEST] <raytiley> Not sure if this is better suited to the devel channel, but here we go... I'm running into issues where capturing from a decklink to hls can wind up getting bad audio, delayed / lots of distorition... Lookin at the logs I'm seeing a fair amount of the "no input signal detected" warnings from decklink_dec
[17:47:14 CEST] <raytiley> looking at https://github.com/FFmpeg/FFmpeg/blob/master/libavdevice/decklink_dec.cpp#L730-L742 it seems that if you set the draw_bars flag it will insert some video in these cases, but only for certain pxl formats
[17:47:59 CEST] <raytiley> Would drawing those bars / black / repeating last frame benefit keeping the video in sync / audio good
[17:48:59 CEST] <raytiley> I've tried using wall clock and -vsync 1 -af aresample=async=1 which I thought might help, but the problem persists
[18:05:52 CEST] <allohol> [18:01]  allohol: How to crop? My cmdline looks like this: 'ffmpeg -i input.vob -vf crop=100:100:12:34 -c:v libx264 -c:a aac out.mkv' -- i also tried '-filter:v crop=w:h:x:y' as well as "crop=..." and 'crop=' and even "crop w:h...". But OUT always has the same w:h as INPUT.
[18:24:09 CEST] <kepstin> allohol: that crop command should definitely be working. There might be some confusion about aspect ratios (vob files have non-square pixels and don't store the sar internally).
[18:49:42 CEST] <ariyasu> i encoded a tennis match to x264
[18:50:08 CEST] <ariyasu> and when the ball is served, you get like 10 frames in a row where the ball is missing from the encoded frames
[18:50:34 CEST] <ariyasu> could that be deblock / denoise treating it as some artifact and trying to remove it?
[18:52:10 CEST] <nicolas17> what encoding settings are you using?
[18:52:28 CEST] <nicolas17> crf? fixed bitrate?
[18:54:32 CEST] <ariyasu> crf 23, going from 1920x1080 to 720x404
[18:55:03 CEST] <nicolas17> are you using a denoise filter?
[19:19:28 CEST] <kepstin> ariyasu: going down that far in resolution, the tennis ball will get pretty small. Assuming you're not doing any other filtering, you might want to bump the crf a bit to preserve more details.
[19:50:29 CEST] <vince_> can someone help me register with the Trac system... i can't register to file a bug
[19:50:56 CEST] <vince_> can't get past the anti spam check
[19:51:54 CEST] <nicolas17> maybe you are a robot
[19:51:58 CEST] <nicolas17> sorry you had to find out like this
[19:53:11 CEST] <linuxmaster> nicolas17: ^__^
[19:53:41 CEST] <nicolas17> vince_: how can you not get past that? :P
[19:54:00 CEST] <vince_> project name, and two are the answers, right? or am i dumb
[19:54:14 CEST] <nicolas17> what is the project called?
[19:54:50 CEST] <vince_> ah okay i am dumb, thank you
[19:56:45 CEST] <ChocolateArmpits> nicolas17, do you have cookies enabled?
[19:57:00 CEST] <ChocolateArmpits> oops wrong user
[19:57:23 CEST] <cemerick> I am trying to extract a single frame from a particular timecode of a video, with (fast) input seeking, with subtitles applied. Is this possible?
[19:57:25 CEST] <cemerick> Despite rearranging arguments in a variety of ways, I can either get a single frame fast without subtitles, or a single frame slow (i.e. using output seeking) without subtitles, but not the happy combination.
[19:59:29 CEST] <nicolas17> cemerick: perhaps it needs to do slow-decoding starting before the point that particular subtitle appears
[20:00:01 CEST] <nicolas17> wait, you said 'without subtitles' both times, plz clarify :P
[20:00:11 CEST] <cemerick> ah, sorry
[20:00:24 CEST] <cemerick> yes, I can get a single frame, with subtitles, but only with output seeking (thus slowly)
[20:00:42 CEST] <cemerick> it seems -ss and the subtitle filtering don't talk to each other
[20:01:31 CEST] <kepstin> ah, the issue is that when you use -ss with fast seeking, it adjusts the timestamps to start at 0
[20:01:48 CEST] <kepstin> one workaround is to use the -itsoffset input option (set it to the same value as -ss)
[20:02:07 CEST] <kepstin> you might then need to use a setpts filter after applying the subtitles to reset the timestamps to start at 0
[20:03:10 CEST] <cemerick> kepstin: -itsoffset appears to get it done. Thanks!
[20:14:18 CEST] <nicolas17> https://trac.ffmpeg.org/wiki/Encode/FFV1
[20:14:26 CEST] <nicolas17> why does it say archival use should use GOP 1?
[20:20:51 CEST] <ChocolateArmpits> nicolas17, wouldn't that offer better resiliency to data loss when each frame is compressed individually?
[20:21:18 CEST] <nicolas17> hmm maybe, but if I cared about corruption I'd store separate parity data :P
[20:21:42 CEST] <nicolas17> what's the default gop size if I don't pass -g?
[20:22:50 CEST] <nicolas17> also
[20:23:22 CEST] <furq> what does -g even do in an intra-only codec
[20:23:22 CEST] <nicolas17> I assume "-context 1" (large) gives better compression at the cost of taking more time, but what does -coder do?
[20:24:08 CEST] <ChocolateArmpits> nicolas17, http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2012-April/122967.html
[20:24:41 CEST] <furq> they're just two different entropy coders
[20:25:03 CEST] <furq> iirc 0 is fastest and 2 is best compression
[20:25:07 CEST] <furq> but it probably depends on the input
[20:25:15 CEST] <nicolas17> furq: is ffv1 intra-only
[20:25:17 CEST] <nicolas17> ?
[20:25:18 CEST] <furq> yes
[20:27:13 CEST] <furq> oh i guess maybe not
[20:28:02 CEST] <furq> i'm sure it doesn't do any temporal compression though
[20:37:13 CEST] <nicolas17> I get marginal improvements with larger GOPs https://paste.kde.org/prqme6rl5
[20:37:53 CEST] <lays147> hello people... me again xD I am using this profile to normalize some videos with xdcam hd422 format with GOP : M=3, N=15, however the output video is GOP : M=4, N=13 https://paste.kde.org/pjkzg0ypc
[20:38:03 CEST] <lays147> so what could be wrong with my profile?
[20:44:31 CEST] <nicolas17> -coder 1 gets better space savings than messing with the GOP
[20:44:39 CEST] <ChocolateArmpits> lays147, did you check the stream with a proper mpeg2 stream analyzer?
[20:45:41 CEST] <lays147> ChocolateArmpits: nope, ffmpeg is not my strong point.
[20:45:41 CEST] <ChocolateArmpits> lays147, not related but you can set sc_threshold to 0 to disable gop creation on scene detect
[20:46:14 CEST] <lays147> ChocolateArmpits: I saw some docs about it, its just that soup of params doesnt make much sense to me...
[20:46:26 CEST] <nicolas17> gop1-coder1 is smaller than gop1000-coder0 :D
[20:47:52 CEST] <ChocolateArmpits> lays147, you can use ffprobe for that and inspect stream output or use something more user friendly like Streameye
[20:47:55 CEST] <kepstin> nicolas17: iirc the only thing larger gop size does in ffv1 is allow the entropy encoder to maintain state between frames. So, yeah, marginal improvement.
[20:48:33 CEST] <nicolas17> it looks like ffv1 compresses better than x264 -crf 0
[20:48:41 CEST] <nicolas17> (for my particular inputs)
[20:49:18 CEST] <furq> x264 obviously does way better for relatively static inputs
[20:49:36 CEST] <lays147> ChocolateArmpits: so, my params looks correct?
[20:49:55 CEST] <furq> lays147: M=3 should be -bf 2
[20:50:20 CEST] <furq> i forget how N maps to -g but i guess it could be two out either way
[20:50:32 CEST] <furq> with that said mediainfo isn't necessarily the most reliable tool for this
[20:50:53 CEST] <lays147> furq: will give it a try with 2
[20:51:24 CEST] <ChocolateArmpits> lays147, don't forget to replace -r 29 with -r ntsc if your content is actually ntsc
[20:52:18 CEST] <nicolas17> ntsc is an alias for 30000/1001?
[20:52:27 CEST] <furq> in certain places, yeah
[20:52:46 CEST] <lays147> so far on my knowledge the video format is that
[20:53:24 CEST] <furq> iirc you can do -r ntsc but you can't do -vf fps=ntsc
[20:53:45 CEST] <kepstin> lays147: depending on the exact settings you use, you may or may not need to use `-mpv_flags strict_gop`
[20:54:09 CEST] <kepstin> or, uh, what's the other one
[20:54:22 CEST] <nicolas17> ffv1 with coder 0: 1.3GB
[20:54:25 CEST] <nicolas17> ffv1 with coder 1: 1.1GB
[20:54:33 CEST] <furq> did you try 2
[20:54:35 CEST] <nicolas17> x264 -crf 0 -preset slow: 1.6GB
[20:54:56 CEST] <nicolas17> furq: I tried coder 2 and it was the same file size as coder 1 up to the byte
[20:55:06 CEST] <furq> fair enough
[20:55:11 CEST] <furq> it's been a while since i messed around with this
[20:55:20 CEST] <lays147> furq: the -bf 2 didnt solved =/
[20:55:39 CEST] <nicolas17> I'm still surprised x264 lossless is worse for this
[20:55:54 CEST] <furq> ffv1 is very good with certain inputs
[20:57:06 CEST] <ChocolateArmpits> lays147, what's the version of your ffmpeg?
[20:57:12 CEST] <furq> it's pretty much best in class for encoding single images
[20:57:22 CEST] <lays147> ChocolateArmpits: ffmpeg version 2.8.11
[20:57:49 CEST] <furq> sadly nobody would get any kickbacks from making it into an actual lossless image format
[20:57:53 CEST] <furq> which is a shame because it'd be really good at it
[20:58:00 CEST] <kepstin> lays147: well, I doubt the mpeg2 video encoder has changed much since 2.8, but still that's a very old version
[21:00:21 CEST] <ChocolateArmpits> lays147, can you try the parameters from this ? http://www.deb-indus.org/tuto/ffmpeg-howto.htm#Encoding_XDCAM-HD-50_FCP
[21:01:04 CEST] <lays147> well the change to ntsc made my M=3 instead of 4 but keeps the N=13
[21:03:02 CEST] <kepstin> lays147: please try the strict_gop option i mentioned above.
[21:04:52 CEST] Action: lays147 tries
[21:05:50 CEST] <lays147> ChocolateArmpits: this one? MPEG-2 Long GOP Encoding
[21:06:15 CEST] <ChocolateArmpits> lays147, nah. This one: XDCAM HD 50Mbps
[21:06:25 CEST] <ChocolateArmpits> it most closely matches your initial settings
[21:07:31 CEST] <kepstin> hmm, that just turns on interlaced encoding and sets some vbv limits
[21:08:15 CEST] <nicolas17> ew interlacing
[21:08:41 CEST] <nicolas17> bah, I need to hack some prefetching into the image2 demuxer
[21:09:35 CEST] <nicolas17> reading a video from a large file, the kernel takes care of readahead
[21:09:50 CEST] <nicolas17> reading an image sequence from thousands of tiny files, there's *so* much waiting for I/O
[21:10:37 CEST] <nicolas17> unless I "cat *.jpg > /dev/null" in another window to shove it into the disk cache, then ffmpeg gets faster (and uses more CPU)
[21:13:58 CEST] <lays147> kepstin: didnt work. I am leaving my work right now, will get back into this tomorrow, and try with a modern ffmpeg to see if that its the issue
[21:14:09 CEST] <lays147> thanks everyone for the help!
[21:16:08 CEST] <nicolas17> over the network it's worse
[21:16:16 CEST] <GuiToris> hello, what happened to the 'mp' filter?
[21:16:38 CEST] <GuiToris> I looked up how to brighten up a video, and I found -vf mp
[21:16:59 CEST] <GuiToris> but I can't find mp filter anywhere on https://ffmpeg.org/ffmpeg-filters.html
[21:17:26 CEST] <nicolas17> "ffmpeg -i https://example.com/playlist.m3u8" is *significantly* slower than downloading the .ts files *in parallel* and then working with the local files, but having to download first is inconvenient, bleh
[21:17:46 CEST] <nicolas17> that's harder for ffmpeg itself to handle though
[21:33:08 CEST] <furq> GuiToris: use eq (or colorlevels, or curves, or pp)
[21:35:14 CEST] <tanpi> I generate a mp4 using a android app and can't convert using ffmpeg. Remaining file is 0k. I'm plan to upload to youtube https://trac.ffmpeg.org/wiki/Encode/YouTube . VLC can play the video. ffprobe 1.mp4 = major_brand     : iso6, compatible_brands: mp42iso6avc1isom.
[21:35:44 CEST] <furq> tanpi: just upload it to youtube as is
[21:36:08 CEST] <tanpi> furq: youtube give a error too.
[21:36:20 CEST] <GuiToris> furq, thank you, I've already tried eq, but I'll try the rest maybe they will be somewhat better
[21:36:28 CEST] <tanpi> shows incompatible format
[21:39:26 CEST] <nicolas17> major_brand is one of the least useful bits of information from ffprobe, pastebin the full thing
[21:42:50 CEST] <tanpi> output is here: https://pastebin.com/eHyPpJDV
[21:43:50 CEST] <nicolas17> "Duration: 00:00:00.00"
[21:46:04 CEST] <kepstin> huh, that's really weird. You'd have to get someone familiar with the mp4 container to take a look at that and figure out what's going wrong
[21:46:11 CEST] <Pennth> I have a bunch olf old procedures in our wiki that need to be modernized becuse they use deprecated commands and codecs. Is there a phrasebook or rosetta stone for replacing things like -vpre and -acodec?
[21:46:16 CEST] <kepstin> nicolas17: I'd suggest filing a bug with a sample.
[21:46:36 CEST] <nicolas17> kepstin: you mean tanpi :)
[21:46:43 CEST] <kepstin> er, yeah :/
[21:47:34 CEST] <furq> Pennth: -acodec and -vcodec are -c:a and -c:v
[21:47:37 CEST] <furq> although the old aliases should work
[21:48:00 CEST] <furq> -vpre with x264 is probably -preset now
[21:48:33 CEST] <Pennth> furq, Yes, I'm just hoping to find one cheat sheet rather than having to check each option separately.
[21:48:47 CEST] <furq> i don't know of one
[21:49:46 CEST] <kepstin> Pennth: in general, most -asomething or -vsomething options turned into -something:a or -something:v (where the stuff after the : is actually a stream selector which can do other things too). But some have shorter or different versions.
[21:50:07 CEST] <kepstin> Pennth: most of the old aliases are still supported, so searching for the old option name in the man page will find the new option
[21:51:23 CEST] <debianuser> Pennth: does https://github.com/FFmpeg/FFmpeg/blob/master/fftools/ffmpeg_opt.c count for a cheatsheet? ;)
[21:51:44 CEST] <tanpi> kepstin: th thing that i noted is that i can't move forward the video on vlc. I need to wait finhish to play if I want to anyhere end. The other commands in ffmpeg wiki with -movflags +faststart at least I can get a second from the video result a 120 k file size o.O
[21:51:48 CEST] <Pennth> Not as such but I can work with it :)
[21:53:22 CEST] <Pennth> On second thought, nope, because it's not in a getopt form with equivalents. Guess I'll have to do some spading and publishing.
[22:00:45 CEST] <tanpi> since vlc can play the file i'm trying to use the vlc embedded media converter
[22:13:44 CEST] <GuiToris> furq, if I'd like to use the colorbalance filter and I'd like to apply .3 for all the shadow channels then do I have to specify them one by one : -vf colorbalance=rs=.3:gs=.3:bs=.3  or there's a way I can combine them?
[22:14:59 CEST] <tanpi> vlc converter worked :O
[23:27:58 CEST] <Stadtpirat> Hi, I try to cut an aac file to an exact length. But it's longer than I want it. This is the command I use: "ffmpeg -i audio.aac -ss 0 -t 02:12:54.98 -c copy audio-cut.aac" and this the resulting length: 02:12:55.01 Why does this happen?
[23:31:50 CEST] <kepstin> Stadtpirat: aac packets are 1024 samples long, so about 20ms ± a bit depending on sample rate. ffmpeg can't cut packets in copy mode. So that's just a rounding error.
[23:34:57 CEST] <Stadtpirat> I see, thanks.
[00:00:00 CEST] --- Thu Sep 20 2018