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

[burek]

[03:10:55 CEST] <Cracki> FishPencil, ask it
[03:11:19 CEST] <Cracki> perhaps I'll direct you to a more fitting channel
[04:14:06 CEST] <furq> is showwavespic on a 90 minute audio file supposed to use all my ram
[04:14:10 CEST] <furq> because it does
[04:16:52 CEST] <Cracki> I'm browsing https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/avf_showwaves.c
[04:19:00 CEST] <Cracki> possibly it caches all samples relevant to the frame...
[04:19:11 CEST] <Cracki> seems it was made for realtime display, so short windows
[04:19:12 CEST] <furq> yeah that sounds like lavfi
[14:42:05 CEST] <MrScoumoune> Hi how can i reencode a video for 720p, actualy i have try this but didn't work ffmpeg -i myvid.mp4(or other) -s hd720 -c:v libx264 -preset superfast -strict -2 myvid.mp4
[14:42:26 CEST] <MrScoumoune> i have multi format and other scale
[14:52:56 CEST] <MrScoumoune> any have idea ?
[15:04:08 CEST] <MrScoumoune> ffmpeg -i myvid.mp4(or other) -crf 18 -c:v libx264 -preset superfast -strict -2 myvid.mp4
[16:10:02 CEST] <_cfr> Hello, I'm trying to convert the audio track of .ts (mpegts) segments without changing their container (or video). I use -copyts -muxdelay 0 -max_delay 0 but at the ends of *some* segments, I can hear a weird cracking noise. Does anyone have any idea what can cause that or how to fix it? Thank you!
[16:50:41 CEST] <pi--> On linux `apt install ffmpeg` gives 3.2.12-1~deb9u1, on OSX I have 4.0.1.
[16:50:56 CEST] <pi--> Is there any particular reason?
[16:51:08 CEST] <pi--> How to get the latest on Linux?
[16:53:45 CEST] <JEEB> I mean, with debian/ubuntu you get the latest that was around a few months before the release of a distro
[16:53:59 CEST] <JEEB> unless you're on the rolling version if they have one
[16:54:10 CEST] <JEEB> for newer stuff you have to build yourself
[16:54:15 CEST] <JEEB> also macos has no official packages
[16:54:29 CEST] <JEEB> so that's just some rolling stuff made by whomever is maintaining homebrew
[16:55:24 CEST] <DHE> that's what distros with fixed releases do. they have the version at the moment of the release (or more like slightly behind) and then pulling in fixes
[16:55:44 CEST] <DHE> the idea is that scripts you write won't break from patching (even automatic patching) because of a version change
[17:22:38 CEST] <st-gourichon-fid> Hello. I'm trying to figure out the importance of a "Non-monotonous DTS in output stream " when copying streams.
[17:23:01 CEST] <st-gourichon-fid> I see in https://github.com/FFmpeg/FFmpeg/blob/b955a33314d4707f3c90c75d7c319d2020ec111a/fftools/ffmpeg.c#L782 that it's in write_packet.
[17:23:44 CEST] <st-gourichon-fid> pi--, have you read https://trac.ffmpeg.org/wiki/CompilationGuide#Linux ?
[17:25:53 CEST] <st-gourichon-fid> I guess the "non-monotonous DTS" only affects a decoder, and perhaps even most modern decoder in PCs don't actually care?
[17:26:54 CEST] <JEEB> it means whatever you're feeding has borked timestamps and the muxer might output garbage
[17:27:13 CEST] <JEEB> and yes, unfortunately various stuff can read broken stuff
[17:30:05 CEST] <st-gourichon-fid> Stream comes from an IP camera and appears to decode well.  I guess it's those class of bugs that never get fixed because in most cases it doesn't cause too much damage?
[17:36:25 CEST] <pi--> This is a weird problem.
[17:36:55 CEST] <pi--> `ffmpeg  -i $SRC_AUDIO  -i $SRC_VIDEO  -acodec aac  -cutoff 22000  -vcodec copy  -map 0:a:0  -map 1:v:0  -shortest  -ab 384k  $DST`
[17:38:09 CEST] <pi--> In the ffmpeg output,
[17:38:12 CEST] <pi-->     Metadata:
[17:38:12 CEST] <pi-->       handler_name    : VideoHandler
[17:38:12 CEST] <pi--> File '/var/tmp/cue_embedder/2018-08-25--15-28-16--322216/merged.mp4' already exists. Overwrite ? [y/N] Not overwriting - exiting
[17:38:47 CEST] <pi--> Now $DST a.k.a. '/var/tmp/cue_embedder/2018-08-25--15-28-16--322216/merged.mp4' doesn't exist before the call!
[17:38:58 CEST] <pi--> Is this syntax somehow creating it twice?
[17:39:11 CEST] <pi--> And maybe only doing it on old ffmpeg
[18:34:21 CEST] <MrScoumoune> any know is it possible to convert is hd 720p ? i cant
[18:54:10 CEST] <BtbN> What?
[18:57:42 CEST] <DHE> you want to downscale a video to 720p?
[19:44:14 CEST] <st-gourichon-fid> Do I understand right that DTS was introduced in older times (80s ?) where a decoder was dedicated hardware with tight constraints, thus the DTS field was important to tell it when to allocate resources to decoding, while current software play actually care about timestamps?
[19:44:42 CEST] <st-gourichon-fid> Hm let's fix it
[19:44:55 CEST] <st-gourichon-fid> Do I understand right that DTS was introduced in older times (80s ?) where a decoder was dedicated hardware with tight constraints, thus the DTS field was important to tell it when to allocate resources to decoding, while current software players actually don't care about timestamps, only presentation time stamp is important?
[19:47:10 CEST] <kepstin> at the very least, modern decoders don't really care about dts as long as the frames are provided in dts order
[20:07:51 CEST] <MrScoumoune> YEA
[20:07:55 CEST] <MrScoumoune> i have try many cmd
[20:07:58 CEST] <MrScoumoune> dont work
[20:08:01 CEST] <MrScoumoune> properly
[20:08:07 CEST] <MrScoumoune> ith scale kepping
[20:08:35 CEST] <MrScoumoune> ffmpeg -i vid-2-R.mp4 -preset slow -codec:a aac -b:a 128k -map_metadata -1 -map 0 -codec:v libx264 -pix_fmt yuv420p -b:v 2500k -minrate 1500k -maxrate 4000k -bufsize 5000k  -vf scale=-1:720 intro-720p.mp4
[20:08:38 CEST] <MrScoumoune> ffmpeg -i vid-2-R.mp4 -preset slow -codec:a libfdk_aac -b:a 128k -codec:v libx264 -pix_fmt yuv420p -b:v 2500k -minrate 1500k -maxrate 4000k -bufsize 5000k -vf scale=-1:720 intro-720p.mp4
[20:08:40 CEST] <MrScoumoune> and OTHER
[20:09:01 CEST] <MrScoumoune> that work for 1 vids on 100.
[21:09:54 CEST] <st-gourichon-fid> Complete message from FFmpeg about DTS suggests that it fixes DTS on-the-fly.  This is a capture from IP camera.  And indeed, playing the resulting capture file no longer show this message.
[21:10:28 CEST] <st-gourichon-fid> If file appears to play okay, without artifact or out-of-order frames, I guess we can consider that the stream is fixed.  What else can happen?
[21:10:50 CEST] <st-gourichon-fid> "file" = the output of the FFmpeg instance that captured RTP and wrote a container file.
[21:11:01 CEST] <JEEB> it 100% depends on the muxing code and if it does the right thing
[21:11:05 CEST] <JEEB> (For your broken input)
[21:11:17 CEST] <JEEB> and it might even depend on the muxer that gets fed with those broken timestamps
[21:14:03 CEST] <st-gourichon-fid> Well, RTP feeds a broken feed to FFmpeg which says "Non-monotonous DTS in output stream 0:0; previous: 13712, current: 8932; changing to 13713. This may result in incorrect timestamps in the output file.".
[21:14:16 CEST] <JEEB> yes
[21:14:17 CEST] <st-gourichon-fid> Is it safe to add flag -fflags +igndts?
[21:14:24 CEST] <JEEB> why would you even
[21:14:41 CEST] <JEEB> just keep it in your mind that the input DTS goes bonkers
[21:14:55 CEST] <st-gourichon-fid> Okay. I expect no actual trouble.
[21:15:06 CEST] <JEEB> so you either fix it or know that with your exact set of paramaters it might be currently working out OK
[21:15:36 CEST] <JEEB> (or there's a bug in the DTS reading code of FFmpeg, but I would be less surprised by the stream just being bonkers)
[21:15:44 CEST] <JEEB> *of FFmpeg's RTP protocol thing
[21:16:41 CEST] <st-gourichon-fid> Video will be reencoded later for playing to network clients.  If the reencoder happens to be okay with the broken input stream, the output stream should be okay regarding DTS issue, right?  I understood that PTS are important, and these don't cause issue in those streams.
[21:17:04 CEST] <JEEB> I can't promise you anything really
[21:17:13 CEST] <JEEB> if the +1 DTS is OK then things are OK, if it isn't then derp
[21:17:23 CEST] <st-gourichon-fid> Okay, thanks. :-)
[21:17:38 CEST] <st-gourichon-fid> I don't expect promises, rather things like "beware of case X and Y, there lie dragons".
[21:19:33 CEST] <JEEB> also I hope you've checked if you actually get a PTS from the RTP stream itself
[21:30:03 CEST] <st-gourichon-fid> I can check that.
[21:30:42 CEST] <st-gourichon-fid> I have not checked in the stream itself, but I have observed some jitter in messages shown by FFmpeg during capture, so I guess this jitter comes from the PTS.
[21:54:05 CEST] <st-gourichon-fid> Hmm, wireshark cannot tell. RTP timestamp is neither DTS nor PTS. These are buried in stream payload.
[21:54:33 CEST] <JEEB> yea
[21:54:47 CEST] <JEEB> I just took a look at rtpdec.c and it just calls per-format parsers
[21:54:52 CEST] <JEEB> sounds like a "fun format"
[21:57:24 CEST] <feedbackmonitor> Hey, I am working on a video recorded by my camera in h264 with MOV as a container. The majority of footage is at 60 fps but some was accidentally done at 24 fps so wanted to re-encode the 24 to match the project. Someone here suggested ffv1, but that output is just too large for my machine to handle. Is there a middle ground to better match the original footage sizes?
[22:05:02 CEST] <atomnuker> rtp has a clock, and that's about all the procotol has, for dts you need more signalling provided by the payload
[22:05:39 CEST] <st-gourichon-fid> Perhaps my DTS issue is just FFmpeg doing funny things from the RTP timestamps? From glance at wireshark capture, the RTP timestamp is monotonic.
[23:11:22 CEST] <st-gourichon-fid> Strange behavior.
[23:11:45 CEST] <st-gourichon-fid> A stream that plays fine with VLC and mplayer.
[23:12:00 CEST] <st-gourichon-fid> ffplay plays it fine, too, but just does not stop at end.
[23:12:17 CEST] <JEEB> if it's UDP the default for that is that there's no timeout
[23:12:41 CEST] <st-gourichon-fid> Sorry, I mean playing the file after capture was completed.
[23:12:56 CEST] <st-gourichon-fid> The file has a finite length but ffplay does not end after it played all file.
[23:13:15 CEST] <st-gourichon-fid> For example, a 20 second file shows counter continuing:
[23:13:17 CEST] <st-gourichon-fid>   63.07 A-V: -0.004 fd=   1 aq=    0KB vq=    0KB sq=    0B f=4/4
[23:13:34 CEST] <JEEB> file protocol last I knew should work unless you've enabled the follow stuff with a timeout of X seconds
[23:14:22 CEST] <st-gourichon-fid> ffplay file://complete_path_ has same behaviour.
[23:14:40 CEST] <st-gourichon-fid> "follow stuff" -> can't find info on the net.
[23:15:56 CEST] <JEEB> well if you're not setting AVOptions for that it's not on by defualt :P
[23:16:29 CEST] <JEEB> libavformat/file.c:    { "follow", "Follow a file as it is being written", offsetof(FileContext, follow), AV_OPT_TYPE_INT, { .i64 = 0 }, 0,
[23:16:32 CEST] <JEEB> 1, AV_OPT_FLAG_DECODING_PARAM },
[23:17:33 CEST] <st-gourichon-fid> I don't want to follow (like unix tail command).
[23:17:41 CEST] <JEEB> well as I said
[23:17:44 CEST] <JEEB> it's not on by default :P
[23:17:53 CEST] <st-gourichon-fid> Just observed that playing a random ogg file has same behavior: ffplay does not exit at end.
[23:18:03 CEST] <JEEB> so it is very weird if a file doesn't EOF properly
[23:18:23 CEST] <JEEB> I haven't seen the behavior in even very recent FFmpeg revisions with MPEG-TS input from a file, for example
[23:18:31 CEST] <st-gourichon-fid> On Ubuntu 18.04 AMD64, version 7:3.4.4-0ubuntu0.18.0
[23:19:07 CEST] <JEEB> sorry, no idea. no reason for me to go back to anything that old
[23:19:15 CEST] <st-gourichon-fid> Sorry :-)
[23:19:16 CEST] <JEEB> although I've used versions from sept last year just fine too :P
[23:19:34 CEST] <JEEB> the big zero != EOF change is from after 3.4, too
[23:19:49 CEST] <JEEB> unless Ubuntu did like Arch and for some reason back-ported that change which then broke plenty of API clients
[23:34:23 CEST] <st-gourichon-fid> Okay, let's assume that it's just my current FFmpeg binaries that smoke too much.
[23:34:29 CEST] Action: st-gourichon-fid builds FFmpeg from git master
[23:36:03 CEST] <JEEB> yeh, you can run the ffmpeg.c from the build dir just fine for decoding testing
[23:36:10 CEST] <JEEB> `./ffmpeg -version` etc
[23:36:27 CEST] <st-gourichon-fid> Yes
[23:37:40 CEST] <st-gourichon-fid> Actually, I have made a script that automatically calls configure with arguments for automatic out-of-source build tree and install tree.  Very easy.
[23:37:44 CEST] <st-gourichon-fid> to use
[23:38:44 CEST] <st-gourichon-fid> Same result.
[23:39:13 CEST] <JEEB> would be interesting to see a sample of such, because I haven't seen file AVIO not sending the EOF signal
[23:39:19 CEST] <JEEB> be it on windows or *nix
[23:39:56 CEST] <JEEB> unless the file's duration is over 9000 and the player/decoder is trying to get to that point
[23:40:06 CEST] <JEEB> can't do much more with just guessing, though :P
[23:41:59 CEST] <st-gourichon-fid> Actually, any file I throw at ffplay does not end.
[23:42:00 CEST] <st-gourichon-fid> E.g.
[23:42:01 CEST] <st-gourichon-fid> wget -S https://upload.wikimedia.org/wikipedia/commons/7/79/Example_of_flats_in_music.ogg
[23:44:52 CEST] <st-gourichon-fid> Will go to sleep. All this is on my dev machine. We might meet again if this causes trouble on the machine that will run ffmpeg for production.
[23:46:32 CEST] <st-gourichon-fid> Thank you for all your feedback. :-)
[00:00:00 CEST] --- Sun Aug 26 2018