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

[burek]

[04:02:52 CET] <memfrob> 'low errbody! Quick question. What difference is there between native and external libraries/codecs besides the fact that one is internal and other is external?
[04:03:58 CET] <memfrob> There is a difference in file size (re-encoded via ffmpeg) when comparing internal vs. external as well as slightly different algorithm?
[04:04:16 CET] <memfrob> question mark because I don't know for sure.
[04:05:35 CET] <pink_mist> absolutely different algorithms
[04:05:52 CET] <pink_mist> otherwise there wouldn't be a point to link to the external one
[04:06:33 CET] <pink_mist> whether the external one has a better algorithm or not probably is a case by case thing
[04:06:51 CET] <memfrob> how can internal be "true" to the real codec then if it uses a different algorithm?
[04:07:26 CET] <pink_mist> because the codec isn't defined by the implementation (whether external or internal)
[04:08:27 CET] <memfrob> does ffmpeg have an internal x264 codec or only external?
[04:09:10 CET] <memfrob> pink_mist, you're a really knowledgeable guy with this stuff, your help is very appreciated.
[04:09:22 CET] <pink_mist> I'm really not that knowledgeable
[04:09:26 CET] <pink_mist> but I try
[04:10:24 CET] <memfrob> i think it does because -c:v x264 works but -c:v x265 does not work
[04:10:45 CET] <pink_mist> x264 is a specific implementation of h.264 ... and I think there are other alternative implementations that ffmpeg can use, but I don't know if any of them are internal ... either way, the x264 implementation is one of if not the best h.264 implemenations that exist
[04:10:49 CET] <memfrob> (x265 must have lib before it, and lib* means external if i have that right)
[04:11:17 CET] <pink_mist> x264 is also external
[04:11:37 CET] <Hello71> modern video formats have very broad specifications, there are many ways to implement encoders
[04:11:39 CET] <memfrob> ah, so just because lib is not there before it, doesn't mean it's internal.
[04:11:47 CET] <pink_mist> yeah
[04:12:06 CET] <memfrob> Hello71, would you say that's a good thing or a bad thing?
[04:12:09 CET] <Hello71> the first mp3 encoders were complete garbage
[04:12:33 CET] <Hello71> which is part of the reason why some people still think that lossless is always better
[04:12:46 CET] <memfrob> lame is good for what it does -- i know it's not the point
[04:14:12 CET] <Hello71> lame is great but its first release was 5 years after the mp3 format itself
[04:14:18 CET] <kepstin> well, the point is that lame is *much* better than the initial mp3 encoders, in part because it uses different algorithms for parts of the encoding.
[04:15:00 CET] <kepstin> since for many codecs, you can implement the encoder in different ways as long as a reference decoder (or a decoder written to the specification) can decode it.
[04:15:29 CET] <memfrob> so perhaps if the specs weren't so broad, those first 5 years wouldn't have been such a mess?
[04:15:33 CET] <memfrob> similar to the ACPI spec..
[04:15:48 CET] <Hello71> unfortunately, people only recently re-realized that it's good for the encoding to be open, but the decoding should be bit-exact
[04:15:56 CET] <memfrob> interesting how linux and windows both handle power management completely different :P
[04:16:12 CET] <kepstin> if the encoder had been specified rather than the format/decoder, we'd have been stuck with a bad format until someone made a completely new different format
[04:16:12 CET] <Hello71> not really, backwards compatibility is important
[04:16:16 CET] <kepstin> instead, mp3 got better
[04:16:34 CET] <Hello71> this is the time of portable mp3 players
[04:16:46 CET] <Hello71> it would be impossible to popularize if you needed to upgrade every year to play new files
[04:17:02 CET] <Hello71> er, this was the time
[04:17:03 CET] <memfrob> Hello71, that's where commercializing comes into play.
[04:17:15 CET] <kepstin> heh, my first mp3 player (it was an iriver 128mb flash player) actually supported vorbis.
[04:17:42 CET] <memfrob> businesses help prevent legacy APIs that are total crap to continue being used everywhere.
[04:17:57 CET] <Hello71> hm... I thought lame was better than libvorbis
[04:18:23 CET] <memfrob> hold on... what i meant was.. businesses allow crappy APIs to continue being crap, and shove it down everyone's throat.
[04:19:16 CET] <Hello71> memfrob: in general, external libraries are called libx in ffmpeg
[04:20:22 CET] <kepstin> external libraries (encoders and decoders) are used typically when there are no internal encoder/decoder in ffmpeg, or when there is an internal encoder/decoder but it's missing features or lacking in performance compared to an external library.
[04:20:31 CET] <memfrob> backwards compatibility isn't always a good thing, look at BIOS and x86.
[04:20:46 CET] <memfrob> 1980s and still going! and not in a good way!
[04:22:13 CET] <memfrob> Hello71, so I was half right about the libx thing
[04:22:21 CET] <memfrob> not _always_ but in general.
[04:23:10 CET] <kepstin> i think they always are, but in some cases there's aliases that allow the name without lib to work; and if the external library is the only encoder, you can just say the codec name and ffmpeg will pick the only available encoder.
[04:23:30 CET] <memfrob> wouldn't it be best to fix that? i'm sure it'd take like 5 minutes to go through the code and remove all the codecs that do not start with "lib" and point to internal libraries.
[04:24:03 CET] <kepstin> (this confused some people recently - "opus" used to select libopus, but an internal opus encoder was added recently so you have to say "libopus" to get the external one now)
[04:24:09 CET] <memfrob> see!!!!
[04:24:47 CET] <memfrob> kepstin should get commit rights if he doesn't already :P
[04:25:04 CET] <kepstin> don't really need them, I have a few patches in already...
[04:25:41 CET] <kepstin> but anyways, the thing where it selects an available encoder when someone uses a codec name is intentional, and would break backwards compat if it was changed, so :/
[04:25:50 CET] <kepstin> (still not recommended tho)
[04:26:23 CET] <memfrob> in that case, using x265 should select libx265, not say "no codec: x265"
[04:26:31 CET] <kepstin> x265 isn't a codec
[04:26:39 CET] <kepstin> the codec name in ffmpeg for that is 'hevc', iirc
[04:26:46 CET] <memfrob> x264 is a codec though..?
[04:26:50 CET] <pink_mist> no
[04:26:58 CET] <memfrob> ok well why the heck does x264 work but x265 doesn't?
[04:26:59 CET] <kepstin> x264 is an *encoder implementation*
[04:27:09 CET] <kepstin> must be an alias for x264, i dunno why :/
[04:27:36 CET] <pink_mist> I don't know why either, but it's still neither internal, nor the name of a codec; it's just an implementation of a codec
[04:28:10 CET] <pink_mist> afaik the best implementation of that codec
[04:28:42 CET] <memfrob> does anything else even code h.265 besides x265?
[04:29:00 CET] <memfrob> *encode
[04:29:04 CET] <kepstin> there's reference and closed-source and hardware encoders for h265/hevc
[04:29:10 CET] <pink_mist> some graphics cards can have hardware encoding capability for hevc I believe
[04:29:13 CET] <pink_mist> yeah
[04:29:17 CET] <pink_mist> and ffmpeg can use those
[04:29:44 CET] <memfrob> oh yeah that's right! that's why using gpu-accel h.265 encoding will be different than using x265 directly
[04:29:56 CET] <kepstin> it's not gpu-accel, it's hardware encoder
[04:30:17 CET] <memfrob> hardware encoder provides gpu acceleration capability.
[04:30:35 CET] <kepstin> it's not accelleration, that implies that an existing software implementation is made faster
[04:30:42 CET] <kepstin> rather, it's a completely different encoder implementation
[04:31:01 CET] <pink_mist> memfrob: it doesn't accelerate the x265 implementation; it's just its own (likely shitty) implementation, that'll likely be fast
[04:31:08 CET] <memfrob> i didn't think it was _that_ different
[04:31:25 CET] <memfrob> but jeeze, so it's completely unrelated to x265
[04:31:30 CET] <pink_mist> yes
[04:31:37 CET] <kepstin> the hardware encoder is just a black box on the gpu die, you send it raw frames, it gives you back encoded frames.
[04:31:39 CET] <memfrob> does that mean you can encode h.265 movies without the x265 codec even installed?
[04:31:59 CET] <Hello71> you can use the reference implementation...
[04:32:08 CET] <kepstin> nobody's patient enough for that ;)
[04:32:12 CET] <Hello71> (although nobody does except for testing purposes)
[04:32:33 CET] <memfrob> patient enough for what?
[04:32:49 CET] <kepstin> patient enough to wait for the reference (research) encoder implementation to finish encoding something
[04:33:18 CET] <memfrob> i'm a bit lost, does that statement have anything to do with using a hardware encoder without x265 on the system?
[04:33:51 CET] <kepstin> the reference encoder is a different software encoder that you could use instead of x265
[04:33:58 CET] <kepstin> even without a hardware encoder
[04:34:21 CET] <memfrob> i'm talking about using the hardware encoder. there still needs to be a layer that talks to the GPU driver to tell it to encode something.
[04:34:37 CET] <memfrob> (for AMD cards this is called VCE)
[04:36:05 CET] <memfrob> oh, i see.. ffmpeg has vaapi support which does that.
[04:36:24 CET] <memfrob> vaapi is completely separate from x265 -- vaapi comes from mesa
[04:36:54 CET] <memfrob> https://trac.ffmpeg.org/wiki/Hardware/VAAPI -- this answers that question
[04:38:45 CET] <memfrob> am i talking too much? i had a very lonely christmas.
[05:10:49 CET] <memfrob> Mom!! FFmpeg is lying to me! Stream mapping:
[05:10:49 CET] <memfrob>   Stream #0:0 -> #0:0 (h264 (native) -> h264 (h264_amf))
[05:11:09 CET] <klaxa> native decoder
[05:11:11 CET] <klaxa> not lying
[05:11:13 CET] <memfrob> ohh
[05:11:16 CET] <memfrob> DEcoder
[05:11:56 CET] <klaxa> :)
[05:12:27 CET] <memfrob> so ffmpeg can have native decoders without native encoders, that's interesting.
[05:13:06 CET] <memfrob> i'm deducting from that, that it's easier to write decoders than encoders.
[05:13:23 CET] <pink_mist> much, usually
[05:14:01 CET] <memfrob> i'm testing out h264_amf in windows -- non-AMD cards should be able to play this back right?
[05:19:12 CET] <klaxa> h264 is h264, it shouldn't matter which encoder produced it
[06:15:12 CET] <memfrob> people say the hardware encoders are kinda goofy, if it's ok to the naked eye, why is that... a problem?
[06:15:31 CET] <memfrob> (minus licensing/proprietary/royalty crap)
[06:17:19 CET] <memfrob> i don't even think you guys care so much about that. fedora for example doesn't even have ffmpeg in it's own repos.
[07:08:35 CET] <mixfix41> hmm looking into this audio forwarding with ssh socat and pulse, on my regular desktop ffplay is known to stutter a bit song or video, but if i play it on the same processor as a raspberry 2 then the file will play smoothly as if i was using vlc on t he desktop
[07:09:43 CET] <mixfix41> interesting
[07:09:53 CET] <mixfix41> and firefox and programs play good anyway
[07:10:08 CET] <mixfix41> so it is narrowed to programs also mplayer and ffplay
[07:10:15 CET] <mixfix41> maybe ill have to try ou t more desktops
[07:41:53 CET] <memfrob> "regular desktop" "but if i play it on the same processor as a raspberry 2" ... your desktop has the same processor as the rpi 2?
[07:43:21 CET] <memfrob> mixfix41, x86 and ARM handle floating point differently, as well as the distribution on the rpi 2 has differences in it besides it being compiled for arm.
[07:44:01 CET] <memfrob> different versions of ffmpeg perhaps, or pulse, etc. as well as a different kernel audio driver.
[07:59:17 CET] <mixfix41> it could be a pulse issue , its just so present with the x86 it stutters a little bit but its bearable listening to this
[08:00:18 CET] <mixfix41> just a funny thought since if it were mplayer and ffplay playing good just that would be with the other applications
[08:01:09 CET] <mixfix41> though the raspberry also especially i think if i play it from the chromebook the issues vary also
[08:01:36 CET] <mixfix41> though the chromebook is wifi even yet the processor is stronger than the rasp
[08:01:53 CET] <mixfix41> though the processing doesnt really take much al beit
[08:03:19 CET] <memfrob> one more "though" out of you, mister!!!
[12:45:21 CET] <th3_v0ice> Is there a way to force the muxer to write the packets to the output even if the new packet PTS is less then the old packets PTS?
[12:46:54 CET] <JEEB> umm
[12:47:04 CET] <JEEB> that sounds completely normal with b-frames f.ex.
[12:47:14 CET] <JEEB> just make sure your DTS is <= PTS at all times
[12:47:35 CET] <th3_v0ice> JEEB: Sorry, I mean DTS
[12:47:52 CET] <JEEB> 100% depends on the muxer
[12:48:03 CET] <JEEB> if the muxer is telling you to f off, then you can't really do much about that
[12:48:11 CET] <JEEB> also if possible, just fix timestamps on your side :P
[12:48:17 CET] <th3_v0ice> For some UDP input, server is basically cycling the timestamps.
[12:48:38 CET] <th3_v0ice> But after some period I will end up with a number that is bigger then INT64_MAX.
[12:48:49 CET] <th3_v0ice> What can I do in that case? Close and reopen the output context?
[12:48:58 CET] <JEEB> larger than INT64_MAX?
[12:49:10 CET] <th3_v0ice> Continuous UDP streaming.
[12:49:15 CET] <JEEB> even with MPEG-TS that takes QUITE the while
[12:49:20 CET] <JEEB> with 90k time base
[12:49:42 CET] <JEEB> because 33 bits is 26.5 hours
[12:50:05 CET] <th3_v0ice> Ok, but what to do when it happens?
[12:50:29 CET] <JEEB> if that really does happen, use a container where that can happen and I think in the packet signal a discontinuity
[12:51:20 CET] <th3_v0ice> Does MPEG-TS support that?
[12:51:53 CET] <JEEB> I'd say yes. also https://www.ffmpeg.org/doxygen/trunk/group__lavf__decoding.html seems to recommend avformat_flush in that case too
[12:52:14 CET] <JEEB> ah no
[12:52:23 CET] <JEEB> that's for input AVFormat contexts :)
[12:53:22 CET] <th3_v0ice> Well the input cycling is done by the server that is delivering the packets.
[12:53:40 CET] <th3_v0ice> So my best bet is to signal a packet discontinuity? How can I do that?
[12:57:33 CET] <th3_v0ice> Its interesting that there is live_flv demuxer which supports packet discontinuity, but there is no such thing documented in the muxers.
[14:19:43 CET] <tommy``> guys i've a software that allow to trim video with a specific command but i think it's not compatible with last ffmpeg version (i think)
[14:19:50 CET] <tommy``> the lines is: '"#{encbin}" -ss #{startt} -sn -i "#{inpath}/#{input}" -vframes #{lenf} "#{prefix}/#{output}[#{startf}-#{endf}]-%05d.jpg"'
[14:20:01 CET] <tommy``> i would like to change some parameters and save in .mp4
[14:20:14 CET] <tommy``> i know that to trim video i've to use something like "ffmpeg -i input.mp4 -ss 01:10:27 -to 02:18:51 -c:v copy -c:a copy output.mp4
[14:20:30 CET] <tommy``> but i dunno how to change the syntax before
[14:22:55 CET] <tommy``> the tokens are: https://paste.ofcode.org/gVVvuf2kBvJsvLrA7dXWzP
[14:27:04 CET] <Blacker47> tommy``, i can't help, but the syntax above will output selected frames recompressed to single jpeg-files (for every frame). i will not say it is itself "trimming". even if there is second step to put single images to a new video together it is not the best idea to recompress it twice.
[14:27:36 CET] <tommy``> i've deleted that all the sintax between the ' '
[14:28:04 CET] <tommy``> without any specific syntax ffmpeg trim and made about 40 .jpg
[14:32:22 CET] <Blacker47> tommy``, there is no one way to "trim" video files in ffmpeg. no idea why your software stops to work but it is not because you have to change the syntax to the bottom example. you have to stop using your software or contact the maintainer for a fix. the bottom syntax btw. will have problems if you want to trim your videos frame-wise but it is encoded with P,B-frames, because of the "copy" ffmpeg can cut only on I-frames then...
[14:32:46 CET] <tommy``> oh ok
[14:33:10 CET] <tommy``> i'm alazing the plugin that allow that and checking how ffmpeg works in it
[14:33:53 CET] <tommy``> Blacker47 https://github.com/TypesettingTools/Aegisub-Motion/wiki/Trim-Configuration#writing-a-custom-command I'm reading here now
[15:16:01 CET] <hans_> i'm trying to cut out a very specific part of a longer video, but the first video frame on the cut out version first appear 2 seconds into the audio cut out, any idea why? here's the command i'm using: ffmpeg -i "in.mkv" -c:v copy -c:a copy  -ss 00:11:32 -t 10.8 -y test.mkv
[15:16:54 CET] <hans_> (in the source, video frames are present for the 2 seconds that they're not present in the result)
[15:17:22 CET] <hans_> when trying to view the result in VLC, the first 2 seconds are just audio.
[15:18:42 CET] <hans_> well, "ffmpeg version git-2017-12-25-613f789", guess i could try updating
[15:24:05 CET] <hans_> updated to "ffmpeg version N-92820-gd702600350 built with gcc 8.2.1 (GCC) 20181201", same issue.
[15:48:08 CET] <pron> hey any ideas why my overlayed watermark png is stretched out and how to fix it?
[15:50:41 CET] <hans_> https://ffmpeg.org/bugreports.html is talking about connecting via FTP to upload.ffmpeg.org , but upload.ffmpeg.org resolves to 88.191.250.119 , and 88.191.250.119 isn't responding on port 21
[15:51:14 CET] <hans_> (and port 21 is the default port for FTP, and https://ffmpeg.org/bugreports.html doesn't say anything about using a non-standard port to connect)
[16:13:02 CET] <hans_> i added the video cutting issue to the bugtracker - https://trac.ffmpeg.org/ticket/7640
[16:37:56 CET] <klaxa> cutting with copy is only possible at keyframes
[16:38:06 CET] <klaxa> this is not a bug but an inherent property of how video encoding works
[21:38:06 CET] <octet> I am trying to convert embedded SSA/ASS subs to external SRT subs for a group of video files. here is the command I have: https://pastebin.com/u3eHYssS . How can I make it look like the original subs? At the moment, it outputs to boldface and size 3 which is quite large compared to the original ASS/SSA subtitles
[21:42:02 CET] <Mavrik> eh?
[21:42:42 CET] <octet> size 36* <font face="Open Sans Semibold" size="36"><b>Blah Blah</b></font>
[21:58:58 CET] <pikapika> Hi
[21:59:24 CET] <pikapika> Is there a way to make certain types of changes 'in place' in a file, ie without separate input and output file?
[21:59:33 CET] <pikapika> Changes such as editing meta data etc
[22:01:43 CET] <durandal_1707> no
[22:28:26 CET] <dingwat> Is there an option similar to -pattern_type glob for ffplay? I have a directory of png frames I'd like to play but they're named by date rather than sequentially
[23:53:17 CET] <fantastictoys> when i convert from flac to opus, i find that my file has been truncated
[00:00:00 CET] --- Fri Dec 28 2018