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

Mon May 7 03:05:02 EEST 2018

[01:47:48 CEST] <n000g> HACK THE PLANET!
[02:04:45 CEST] <TheRock> --extra-ldflags="-LC:\zlib"
[02:04:56 CEST] <TheRock> what is the windows msvc equivalent?
[02:05:03 CEST] <TheRock> LINK : warning LNK4044: unrecognized option '/LC:\zlib'; ignored
[06:00:07 CEST] <TheRock> hi guys when building ffmpeg
[06:00:09 CEST] <TheRock> strip symbols             no
[06:00:09 CEST] <TheRock> optimize for size         no
[06:00:14 CEST] <TheRock> what are the switches ?
[06:19:13 CEST] <furq> TheRock: --disable-stripping and --enable-small
[06:19:30 CEST] <furq> it's unlikely you want --enable-small
[06:34:23 CEST] <TheRock> anything bad about --enables-small?
[06:42:44 CEST] <furq> TheRock: it disables certain optimisations
[06:43:25 CEST] <TheRock> ah, i see
[06:43:37 CEST] <TheRock> right now my ffmpeg is 6-7 mb
[06:43:49 CEST] <TheRock> it would suprise me if that can go down further
[06:44:03 CEST] <furq> are you actually building for a target where it matters
[06:44:12 CEST] <TheRock> since i disabled everything and have just a few deocders enable
[06:44:30 CEST] <TheRock> the ffmpeg will be linked in a statically build project
[06:44:52 CEST] <TheRock> the single binary is already 22mb, which shouldnt grow more
[06:45:22 CEST] <TheRock> it doesnt really matter
[06:49:35 CEST] <furq> well yeah you can try --enable-small
[06:49:47 CEST] <furq> --enable-lto might help as well
[06:50:20 CEST] <furq> but obviously disabling stuff will have the biggest impact
[06:58:38 CEST] <poutine> Anyone know how it's possible to generate the rolling survey of video bitrate in x264 videos data that you always see graphed in professional QC tools?
[06:59:36 CEST] <poutine> or even a good explanation of what it usually represents? (I get a little confused with the display/decode order of things and which timeline this is affixed to usually)
[12:36:51 CEST] <fooman2011> Hello. I have problem using "av_read_frame". My problem is that when the http stream is cut for some seconds (due to lag), then the data read using av_read_frame are not complete. I don't know how to restore a correct state without a full stream restart. Could you please help me ?
[12:38:43 CEST] <BtbN> It should either die completely or not lose a single byte
[12:38:58 CEST] <BtbN> Unless it internally reconnects or something
[12:40:32 CEST] <fooman2011> my problem is that I don't know before calling "av_read_frame" if there are enought data for one frame or not
[12:42:48 CEST] <fooman2011> If there any way to know if there are enoght data without reading them from the stream ? Or maybe there is a way to complete a previous incomplete "av_read_frame"  ?
[12:43:13 CEST] <fooman2011> BtbN: You know what I mean ?
[12:43:32 CEST] <JEEB> the name of that function is anyways incorrect. it's not AVFrames, it's AVPackets.
[12:43:42 CEST] <JEEB> and not all AVPackets are random access points
[12:44:05 CEST] <fooman2011> I'm progressively write into the stream, while it is reading
[12:44:24 CEST] <JEEB> I'm not 100% sure how you end up with broken data in there but I hope you're setting an IO timeout if it's a timeout problem
[12:44:34 CEST] <JEEB> by default lavf http will never time out
[12:44:37 CEST] <JEEB> which is maybe not what you want
[12:44:56 CEST] <fooman2011> Ok let me explain the complete scenario
[12:45:24 CEST] <BtbN> av_read_frame should never give you an incomplete packet and still report success
[12:45:41 CEST] <JEEB> BtbN: I'd say "it depends on the format"
[12:45:59 CEST] <JEEB> I wouldn't make that promise for all the readers in lavf to be honest :/
[12:46:14 CEST] <JEEB> many have alright parsing
[12:46:19 CEST] <JEEB> that is true
[12:49:41 CEST] <fooman2011> I'm reading data from internet and write them into a fifo pipe. During this, I have a player that read this fifo pipe.  My problem is when there is internet lag, the data may be cut during several seconds, av_read_frame read incomplete data from the stream
[12:50:34 CEST] <JEEB> if it's just dropped data, then you need to wait for initialization data to get passed through again
[12:50:59 CEST] <fooman2011> how to wait for initialization data ?
[12:51:16 CEST] <JEEB> avcodec should do that by default for a lot of formats
[12:51:23 CEST] <JEEB> which audio/video formats are you using?
[12:51:26 CEST] <JEEB> and which container?
[12:51:41 CEST] <fooman2011> I think that i'm currently use an mp4
[12:52:16 CEST] <JEEB> ah, if that is not fragmented then the offsets might be all around the place
[12:52:20 CEST] <JEEB> if you dropped data
[12:52:32 CEST] <JEEB> which you can't really fix easily :P
[12:52:50 CEST] <JEEB> in other words, have your reader figure out if the connection went poo-poo :P
[12:53:00 CEST] <JEEB> then stop the processing if it did and re-start
[12:55:15 CEST] <fooman2011> Ok so there is no way to have a kind of "av_peek_frame" that try to read but without remove data fromt he stream ?
[12:55:31 CEST] <JEEB> I'm not sure what you would do with that?
[12:55:45 CEST] <JEEB> like, what would the peeking help you at that point?
[12:55:54 CEST] <JEEB> i might just be not understanding here, of course
[12:56:23 CEST] <JEEB> also if you don't like the alternatives in libavformat itself for reading data, you can actually register your own AVIO callbacks btw
[12:56:55 CEST] <JEEB> I have done that when I was much less experienced with windows IOStreams and it worked, so it shouldn't be mission impossible for you either
[12:57:05 CEST] <JEEB> that way you don't need to pipe stuff etc
[12:57:29 CEST] <JEEB> you have your own C functions that call whatever you want to get the data/seek/write the data
[13:29:18 CEST] <fooman2011> re
[13:29:23 CEST] <fooman2011> sorry I was away
[13:29:34 CEST] <fooman2011> in fact i'm trying to patch omxplayer
[13:29:45 CEST] <fooman2011> https://github.com/popcornmix/omxplayer/blob/master/OMXReader.cpp
[13:29:57 CEST] <fooman2011> line 515
[13:30:17 CEST] <fooman2011> When there is an internet lag, then I enter into this if
[13:30:53 CEST] <fooman2011> because of the interrupt_cb function so I have remove this one.
[13:31:08 CEST] <furq> fooman2011: fyi you should be able to use rpi hwaccel with mpv if you build ffmpeg with --enable-mmal
[13:31:23 CEST] <furq> and there's probably some stuff you need to do with mpv as well, i forget now
[13:31:49 CEST] <fooman2011> mpv ?
[13:32:55 CEST] <fooman2011> mmmh ok why not be i'm curious to understand why I have this problem
[13:33:02 CEST] <fooman2011> be => but
[13:34:04 CEST] <fooman2011> When I remove the interrupt_cb call, then omxplayer does not exit anymore, so that's a good point, but the stream goes very strange.
[13:34:27 CEST] <fooman2011> No more sound, read super fast, pause, read super fast, pause, etc...
[13:38:05 CEST] <fooman2011> do you know where it can comes from ?
[14:36:38 CEST] <tth-bis> hello
[14:37:20 CEST] <tth-bis> is there a way to grab a specific x11 window to a video file ?
[14:42:41 CEST] <klaxa> not really, but with a bit of scripting you can use xwindowinfo to get info about a window (position and geometry) and then pass that to x11grab like: ffmpeg -f x11grab -s $widthx$height -i :0.0+$x_offset,$y_offset [...]
[14:42:58 CEST] <klaxa> you can't move the window afterwards of course :S
[14:48:51 CEST] <Nethe> Hi. Guys, have a question. My ffmpeg transcoding and encoding process are in sleep mode in ps, status D. Is here someone, who could have some idea, why is it happening? The hardware is very strong, 4x Nvidia P5000, 396G ram and Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz
[14:49:17 CEST] <Nethe> As a note - I'm trying to transcode live stream from network source to network source for shaka packager.
[14:50:25 CEST] <tth-bis> klaxa: ok, i give it a try
[15:10:33 CEST] <Nethe> nobody? :)
[15:17:08 CEST] <klaxa> well D is just I/O sleep
[15:17:33 CEST] <klaxa> if any of your network streams is blocking it might get into that state?
[15:19:30 CEST] <furq> is nfs involved by any chance
[15:19:47 CEST] <JEEB> I would guess UDP multicast and multicast out since shaka packager takes in multicast
[15:20:04 CEST] <JEEB> and most broadcasters push out streams as multicasts for you to ingest
[15:20:10 CEST] <JEEB> unless it's VoD
[15:30:01 CEST] <tth-bis> klaxa: "xdotool getwindowgeometry --shell $(xdotool selectwindow)" give good parsable information about a X window
[15:54:38 CEST] <Fyr> guys, I'm trying to remux an m2ts into mp4, FFMPEG freezes in the end. -report option doesn't add anything meaningful.
[15:54:57 CEST] <Fyr> the log file and with:
[15:54:57 CEST] <Fyr> size=   29440kB time=02:13:51.35 bitrate=  30.0kbits/s speed=10.4x
[15:55:32 CEST] <Fyr> the FFMPEG is still working, utilizing a core.
[15:55:43 CEST] <JEEB> dunno, the cases I've done that it has worked, so whatever it is is most likely specific to that sample
[15:55:56 CEST] <JEEB> I've been cutting samples from my two UHD BDs as well as just remuxing random crap when needed
[15:56:06 CEST] <Fyr> is there a way to test the m2ts file?
[15:57:05 CEST] <JEEB> I think the best you can do is try to decode it. also if you are doing -movflags faststart that /will/ take a while
[15:57:14 CEST] <JEEB> since it will rewrite the whole file
[15:57:43 CEST] <Fyr> the command is:
[15:57:44 CEST] <Fyr> ffmpeg -i "bluray:F:\Downloads\Torrent\Man of Fire_[Blu-Ray]" -map 0:15 -c copy "e:\Man on Fire 2004.sup"
[15:58:00 CEST] <JEEB> oh, libbluray
[15:58:04 CEST] <JEEB> that adds another layer of "fun"
[15:58:15 CEST] <JEEB> ok, and subtitles only
[15:58:19 CEST] <JEEB> that's not mp4 :D
[15:58:55 CEST] <Fyr> I just divided the full command into two to find what's wrong.
[15:59:12 CEST] <JEEB> libbluray is useful but I'm not sure if there aren't issues in the wrapper in libavformat around it
[15:59:21 CEST] <JEEB> so it isn't 100% the same as reading m2ts from a file
[15:59:32 CEST] <JEEB> since it's actually using libbluray to do the basic IO
[15:59:52 CEST] <JEEB> (it makes sense to use it to get what's in the playlists, that I 100% agree with)
[16:00:05 CEST] <JEEB> just saying "remuxing an m2ts" generally means you're using the file protocol
[16:00:07 CEST] <JEEB> :P
[16:00:21 CEST] <JEEB> but I wouldn't be surprised if this was a problem with the "zero is not EOF" thing
[16:00:59 CEST] <JEEB> I guess I could try it with a blu-ray I have locally
[16:01:06 CEST] <JEEB> since I do have an FFmpeg built with libbluray enabled
[16:01:20 CEST] <JEEB> but first, I need a run. I've done enough for today with HDR development :P
[16:01:51 CEST] <furq> that reminds me, i should watch man on fire
[16:05:44 CEST] <JEEB> right
[16:05:45 CEST] <JEEB> http://up-cat.net/p/a777171e
[16:05:50 CEST] <JEEB> I wonder what this returns for EOF ;)
[16:06:05 CEST] <JEEB> I bet we will be finding these for a long time to come :|
[16:06:27 CEST] <JEEB> and we can't revert that change because there's o9k other changes now on top of it fixing it. so you'd have to remember to revert ALL of them
[16:07:35 CEST] <JEEB> * @return size of data read, -1 if error, 0 if EOF
[16:07:35 CEST] <JEEB> yup
[16:08:52 CEST] <JEEB> Fyr: I think I found your problem, will be sending out a patch to the mailing list
[16:09:08 CEST] <Fyr> thanks
[16:11:21 CEST] <JEEB> the whole fucking world uses zero for EOF, but asdf
[16:11:46 CEST] <JEEB> and the original reason was "but UDP has zero byte packets! they are valid! it's not EOF!"
[16:12:28 CEST] <JEEB> and instead of limiting it to UDP, the concept of 0 != was actually implemented into the whole goddamn IO framework
[16:12:36 CEST] <JEEB> granted, the documentation seemed to note that already
[16:12:39 CEST] <JEEB> but none of the code was doing that
[16:13:06 CEST] <JEEB> so of course the person implementing it was like "the documentation already says that so I'm just fixing the implementation!"
[16:15:02 CEST] <JEEB> but yea, it most likely is causing the eternal read() loop which takes a single core :P
[16:15:19 CEST] <JEEB> read() returns zero as-is from libbluray, nothing fixes it to be AVERROR_EOF
[16:15:46 CEST] <JEEB> also it sure takes a while to load up libbluray protocol's history, I want to see what prefix others have used for the thing
[16:17:23 CEST] <JEEB> ok, not too many changes since it was added
[16:17:31 CEST] <JEEB> so just lavf/bluray it is
[16:19:55 CEST] <JEEB> there, patch sent to mailing list
[16:20:56 CEST] <JEEB> Fyr: if you want to test locally https://github.com/jeeb/ffmpeg/commit/cc8e71f728ab037357baf0439c8a899ddcdfd5ef
[16:21:21 CEST] <Fyr> JEEB, remuxing the m2ts without libbluray works.
[16:21:35 CEST] <JEEB> yes, since the file protocol was fixed ages ago
[16:21:43 CEST] <JEEB> the bluray protocol was not
[16:22:20 CEST] <Fyr> guys, how do people call the programmers whose hands are attached to their asses?
[16:24:00 CEST] <Fyr> handyassed?
[16:24:06 CEST] <Fyr> asshanded?
[16:25:15 CEST] <JEEB> Fyr: anyways it'd be nice if you could verify this fixes it
[16:25:29 CEST] <JEEB> I'm pretty sure it will
[16:25:32 CEST] <JEEB> but yunno :P
[16:27:13 CEST] <Fyr> oh, the recompilation again.
[16:27:34 CEST] <JEEB> it should be a small recompile
[16:27:43 CEST] <JEEB> since it's a single line change and should only need a recompile of FFmpeg
[16:27:49 CEST] <JEEB> and of those specific files
[16:28:03 CEST] <JEEB> it should probably just re-compile that file + re-link libavformat and the command line tools
[16:46:29 CEST] <ksj> is there a built-in function for converting an AVPacket to a byte array? I can't find anything but I want to be sure before trying another way
[16:48:10 CEST] <klaxa> what about AVPacket.buf->data ?
[16:48:14 CEST] <klaxa> it's uint8_t*
[16:49:52 CEST] <ksj> klaxa: if I sent that byte array over a network, would I then lack some information for decoding?
[16:50:17 CEST] <klaxa> most likely, yes
[16:50:35 CEST] <klaxa> sounds like you want to do media streaming
[16:51:40 CEST] <ksj> yes but I need to send my encoded data through apache kafka
[16:52:36 CEST] <ksj> nd then decode on the other side
[16:52:39 CEST] <ksj> *and
[16:53:55 CEST] <klaxa> it sounds like you want custom IO and not send some AVPacket data through some network
[16:54:57 CEST] <ksj> probably, it's just that I receive these as AVPackets
[16:55:21 CEST] <klaxa> https://www.ffmpeg.org/doxygen/trunk/avio_reading_8c-example.html
[16:56:10 CEST] <ksj> thanks klaxa I'll look into it
[16:57:46 CEST] <klaxa> not sure what API you need to feed, maybe all things i said are irrelevant and your system "supports" sending AVPackets, but usually you write a packet to a stream with av_write_frame() or av_write_interleaved_frame() which takes care of correctly muxing it into the underlying container
[16:58:40 CEST] <klaxa> maybe your kafka stuff knows enough about the packets to decode them, so no idea
[17:02:06 CEST] <giaco> hello
[17:02:44 CEST] <giaco> manual says in -vsync that "With -map you can select from which stream the timestamps should be taken. You can leave either video or audio unchanged and sync the remaining stream(s) to the unchanged one." but how? Is it an ordered based decision?
[17:25:01 CEST] <JEEB> Fyr: back from my jog run. did you get to test it?
[17:25:21 CEST] <Fyr> no. =(
[17:25:33 CEST] <Fyr> I don't really want to start the recompilation.
[17:25:47 CEST] <Fyr> I've just came from my jog run.
[17:25:53 CEST] <JEEB> you only need to do FFmpeg, nothing else. and even there you don't even have to re-configure
[17:26:09 CEST] <JEEB> anyways, I guess I can test it locally :P
[17:26:45 CEST] <Fyr> magnet:?xt=urn:btih:b0320a574a735fa1f536f89b2f311064d45ea275&dn=Man%20of%20Fire_%5bBlu-Ray%5d&tr=http%3a%2f%2fbt2.t-ru.org%2fann%3fmagnet
[17:26:52 CEST] <JEEB> I have plenty of blu-rays
[17:26:56 CEST] <JEEB> and it should be the same with all
[17:27:04 CEST] <JEEB> when it hits EOF from libbluray it will go into infinite loop
[17:27:21 CEST] <Fyr> it's the bluray on which FFMPEG stammer.
[17:27:38 CEST] <JEEB> pretty sure it's global, let me try with any I have
[17:28:05 CEST] <Fyr> I've ripped and remuxed plenty of blurays.
[17:28:14 CEST] <Fyr> it's the first time it didn't work.
[17:45:37 CEST] <JEEB> Fyr: basically I'm decoding a blu-ray with libbluray and if it finishes it works :P
[17:50:05 CEST] <JEEB> ok, it finished
[17:50:13 CEST] <Fyr> (=
[17:50:49 CEST] <JEEB> and I got a LGTM on the mailing list https://patchwork.ffmpeg.org/patch/8810/
[17:54:08 CEST] <JEEB> and pushed
[00:00:00 CEST] --- Mon May  7 2018