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

[burek]

[00:46:16 CEST] <phear> hey how's it going guys
[00:48:29 CEST] <phear> how do i cut a video to an undetermined time
[00:48:35 CEST] <phear> like let's say from 3 minutes onto the end
[00:48:39 CEST] <phear> but the end time isn't known
[00:49:53 CEST] <furq> by finding out how long the video is first
[00:49:59 CEST] <phear> oh okay
[00:50:06 CEST] <phear> so ffmpeg can't find it out for you
[00:50:26 CEST] <phear> sick
[00:51:00 CEST] <phear> technology isn't there yet i guess
[00:53:29 CEST] <furq> http://vpaste.net/683yS
[00:59:00 CEST] <votz> phear: What happens if you use -t 999999999999999999
[00:59:19 CEST] <votz> -ss <startOffset> -t 99999999999999999999999
[00:59:39 CEST] <phear> i could imagine my cpu catches on fire
[00:59:40 CEST] <furq> he's asking how to get the startoffset
[00:59:57 CEST] <furq> also what would probably happen is that it would give you an option out of range error
[01:00:00 CEST] <votz> ah -- I misunerstood.
[01:00:10 CEST] <votz> Thanks for the correction furq.
[01:01:25 CEST] <furq> i was slightly wrong
[01:01:34 CEST] <furq> it still breaks if you pass anything above 2147483647 but it doesn't throw an error
[01:01:47 CEST] <furq> it just treats it as 0
[01:30:09 CEST] <phear> wait, how do I split a video from one timestamp to the other?
[01:31:22 CEST] <phear> I thought ffmpeg -i largefile.mp4 -sameq -ss 00:00:00 -t 00:50:00 smallfile.mp4 was the proper format, but if I start at 20:00 it just splits to 50:00 minutes after that, not from 20:00 to 50:00
[01:36:24 CEST] <furq> -to
[01:36:29 CEST] <furq> also -sameq hasn't been an option for years
[01:36:43 CEST] <furq> if you want to cut without reencoding then use -c copy, but that will prevent you from getting exact cuts
[01:37:08 CEST] <phear> ooh alright, to command is very helpful
[01:38:37 CEST] <phear> and yeah my bad i'm not using sameq, i just copy pasted this similar version because mine is formatted in a subprocess call in a python script
[01:40:18 CEST] <phear> this is working very nice now :D
[03:46:27 CEST] <triger___> 1. open ffmpeg through read data at the beginning of a video 2. close ffmpeg
[03:48:23 CEST] <triger___> question: how do I open ffmpeg to restore the close state so that I can seek to the video position last closed.
[03:52:25 CEST] <ffmpeguser> How can I cut a video after 10% of it passes and replace the remaining 90% time with another video
[04:03:50 CEST] <beauty> My process as follow:
[04:03:59 CEST] <beauty> 1. open ffmpeg using data from the beginning of a video
[04:04:05 CEST] <beauty> 2. decode some data
[04:04:10 CEST] <beauty> 3. close ffmpeg
[04:04:16 CEST] <beauty> 4. open ffmpeg using data from the beginning of a video
[04:04:20 CEST] <beauty> 5. decode some data from the lase closed position
[04:04:24 CEST] <beauty> 6. close ffmpeg
[04:04:30 CEST] <beauty> 7. repeat
[04:04:34 CEST] <beauty> Now,I know how to do the 5st step(using av_seek_frame). But I dont know how to do the 1st step effectively.So how?
[04:06:46 CEST] <tiger__> anybody here?
[04:07:19 CEST] <ffmpeguser> How can I cut a video after 10% of it passes and replace the remaining 90% time with another video?
[04:24:58 CEST] <kepstin> ffmpeguser: the ffmpeg command-line tool can't deal with % of length, so you'll first have to figure out how long your videos are, then use e.g. the -t input option to cut them to length and the concat filter to combine them.
[07:45:23 CEST] <IamTrying> How to convert MP4 files to WebM? where i have 90 files and i want them to get converted with one command line.
[07:55:45 CEST] <IamTrying> Guys, i had one proposal. For decades FFmpeg sucks for GUI people in OSX, Windows, not for Linux users as they are heros. Why not make FFMpeg Web interface with NodeJS built in on it? when a OSX or Windows user downloads it we open an local index.html file in the browser and do all the submission to ffmpeg via nodeJS?
[08:02:01 CEST] <tdr> IamTrying,  Because then someome would have to 'own' it, be responsible for handling all the feature requests, gripes, bugs or alleged bugs, and/or noise about it
[08:02:53 CEST] <IamTrying> tdr: i dont want that part, its hell handing and maintaining it. i love the way like "write once and hide forever"
[08:15:44 CEST] <tdr> IamTrying, once its releases, it will be wanted.
[09:15:50 CEST] <mrelcee> tdr: meh.  osx has so many ffmpeg front ends...
[09:16:42 CEST] <tdr> mrelcee, cli user here, i didnt even look. i know lots of people have made simple pages to control ffmpeg/mplayer/etc tho, figured there were some alive
[09:17:39 CEST] <mrelcee> i built scripts with perl to do my ffmpeg encoding.   on my osx laptop and on my freebsd server.    life is good
[09:18:14 CEST] <tdr> oh its good, so long as you can read your own perl ;)
[09:18:49 CEST] <mrelcee> it's readable with comments saying wtf i was thinking, and not loaded down with objects that read like arcane incantations.  :)
[09:19:16 CEST] <tdr> very honest, i'd validate that
[09:20:18 CEST] <mrelcee> everyone picks on perl. :)
[09:21:07 CEST] <tdr> mrelcee, had it not made my eyes bleed before, i wouldnt.  although my ksh/bash arrays can be just as "smooth" looking
[09:22:17 CEST] <furq> what are you doing with ffmpeg that necessitates more than an sh script
[09:23:08 CEST] <mrelcee> traversing directories, converting everything it can find to h.265.   and I hate sh scripting.  ;).  i'd rather eat bees than debug sh scripts..
[09:24:29 CEST] <mrelcee> of course it has to tell if a file is already h265 so it doesn't redo it.     this script traverses my /zfs/television.  and /zfs/movies folders looking for victims to squish every night..
[09:26:32 CEST] <mrelcee> did it need perl? prolly not but it was easier for me.   Only the most basic scripts i do in sh.       it's my hammer...
[09:27:07 CEST] <furq> i mean that sounds like maybe four lines of sh
[09:27:21 CEST] <furq> maybe more if you want to use whatever the freebsd equivalent of inotifywait is
[09:28:28 CEST] <mrelcee> i'd love to see a 4 liner that does it all
[09:34:03 CEST] <furq> http://vpaste.net/JUk66
[09:34:10 CEST] <furq> that's arguably four
[09:34:34 CEST] <furq> ignoring how inefficient that is
[09:34:49 CEST] <furq> actually you can drop the set -e
[09:35:38 CEST] <mrelcee> heheheh.  eyes bleeding!
[09:35:54 CEST] <furq> i mean most of that is ffprobe's fault
[09:36:10 CEST] <mrelcee> fair enough.   if you can read that..   more power to ya
[09:37:08 CEST] <furq> that argument would hold more weight if you weren't comparing it to perl
[09:37:16 CEST] <mrelcee> sigh
[09:37:43 CEST] <mrelcee> show us on the doll where perl touched you
[09:37:56 CEST] <furq> i can't not pick on perl now
[09:37:58 CEST] <furq> that would make you a liar
[09:41:38 CEST] <mrelcee> I guess it boils down to it's my playground and I'll write my tools as a see fit. :).   what i've got I can accomodate changes to if I need without disecting a one-liner.   I do logging and report errors if something goes wrong.   i kinda geeked out on it.   and I enjoyed writing it..  so pick away. :)
[09:42:25 CEST] <furq> http://vpaste.net/Lu93k
[09:42:33 CEST] <furq> i would probably actually write it like that, but then it would be more than four lines
[09:43:01 CEST] <furq> as shell scripts go that one is incredibly readable if you ignore the ffprobe nonsense
[09:43:19 CEST] <furq> i've written way worse
[09:44:10 CEST] <mrelcee> that isnt' bad
[09:47:13 CEST] <furq> http://vpaste.net/dIgao
[09:47:15 CEST] <furq> it could be much worse
[09:50:10 CEST] <furq> that is actually not that bad if you ignore the awk script embedded in a heredoc
[09:50:15 CEST] <furq> which just fundamentally makes me unhappy
[09:57:09 CEST] <mrelcee> well your sh script is more efficient than what I did.    but they both take up the same sized sector on a hard drive..  and run just as fast.   that's one of the cool things about unix, there's more than one way to do any task..
[10:53:07 CEST] <Funnynot> Hi, I'm trying to split an audio file with this command: "$ffmpeg -i your_audio_file.mp3 -acodec copy -t 00:30:00 -ss 00:00:00 half_hour_split.mp3" and was wondering if "-ss 00:00:00" is required since seeking will start by default from the beginning, right?
[11:48:34 CEST] <sybariten> hello! Image sequence to video question
[11:49:10 CEST] <sybariten> can ffmpeg ever use numbering that is not zero-paddeD?    image1.jpg image2.jpg image3.jpg .... image45.jpg image 46.jpg .... image 132.jpg image133.jpg  etc etc
[11:49:32 CEST] <sybariten> or do i need to make the filenames to equal length, with zeroes?
[11:56:42 CEST] <MR-2> Hi! I'm tring to fetch a webbvtt subtitle from a .m3u8 input put the output i'm getting is only a single segment. How can i solve that?
[12:12:09 CEST] <MR-2> nvm i figured how i'm gonna fix it
[12:41:34 CEST] <kepstin> sybariten: that should work fine with the pattern 'image%d.jpg'
[12:44:01 CEST] <User45232> Hi! Did someone know a way to create mpeg-ts files from a avi/mkv-file? including .hmt .nts and .thm files?
[12:53:26 CEST] <evildead> hello all
[12:54:47 CEST] <evildead> i would like to keep my gps metadata but ffmpeg drop it, i try to add the "-map_metadata 0:s:0" option to keep all global metadata but it doesnt work, any idea ?
[12:55:10 CEST] <evildead> sorry i add "-map_metadata 0" for global :)
[12:57:39 CEST] <evildead> i use version: 2.8.6-1ubuntu2
[13:22:41 CEST] <Spring> is there any reason that a h264 or VP9 video wouldn't play in Android?
[13:23:35 CEST] <Spring> I have a video element that contains both mp4 and webm sources and testing on an Android virtualization it fails to play. Whereas on iOS it plays fine.
[13:24:59 CEST] <BtbN> You might be using some features that the device does not support
[13:25:07 CEST] <BtbN> a lot of cheap devices can barely play h264 main
[13:25:13 CEST] <BtbN> some are even restricted to baseline
[13:25:31 CEST] <BtbN> And such a device most definitely also can't play VP9
[13:30:48 CEST] <Spring> BtbN, was wondering about that, but on iOS it plays fine, plus it's not an actual device but virtualized (AFAIK) so I'm not sure it's emulating the device specs.
[13:31:38 CEST] <BtbN> a virtualized iOS device?
[13:32:01 CEST] <Spring> BtbN, I'm using this site: https://appetize.io/demo
[13:32:38 CEST] <ritsuka> I guess that's the iOS simulator
[13:33:01 CEST] <ritsuka> it just uses whatever is available on mac os to play video, so you better test on a real device
[13:33:03 CEST] <BtbN> that's some browser mockup I'd guess
[13:35:10 CEST] <Spring> ritsuka, does it? Was under the impression it would use what was available on iOS, since it's some instance of it.
[13:37:46 CEST] <ritsuka> it's a "simulator", not an emulator, it's the iOS software running on a mac, so some things are different (you don't have the iPhone gpu and hardware video decoder).
[13:39:03 CEST] <Spring> sad panda
[13:42:14 CEST] <BtbN> it's not something running on a mac. It's running in a browser.
[13:48:26 CEST] <ritsuka> it a screencast of an actual iOS simulator
[13:55:56 CEST] <diffuse> I've been using the ffmpeg C api to convert audio files to pcm, then outputting the pcm with a wave header to disk
[13:56:02 CEST] <Spring> if a source video contains alpha transparency information it should be supported when transcoded with libvpx, right? Someone just PM'd me a question.
[13:56:36 CEST] <diffuse> The resulting file does have a WAVE header, but the size field in the header is always ffffffffff
[14:17:13 CEST] <sybariten> kepstin: thank you, it did!!
[14:18:14 CEST] <kepstin> diffuse: the ffmpeg wav muxer has to seek back to the start of the file to update the size header when it's done writing
[14:27:18 CEST] <conkis> how to ignore audio stream on failure ? when -codec copy
[14:29:43 CEST] <Spring> honestly would like to know the same thing, not sure it's possible
[14:30:02 CEST] <Spring> apart from using ffprobe to check there's an audio stream to begin with
[14:30:27 CEST] <Spring> or doing a slient test encode first and seeing if that errors
[14:42:09 CEST] <conkis> it should be possible somehow
[14:55:23 CEST] <diffuse> kepstin: what routine does this?
[14:56:08 CEST] <diffuse> kepstin: is it write_trailer?
[14:57:21 CEST] <diffuse> Well, I will forego asking dumb questions, let me test it....
[15:00:45 CEST] <kepstin> Spring: regarding vpx transparency, I believe it should work as long as you use vp8, not vp9, and make sure the pixel format going into the encoder is yuva420p
[15:01:47 CEST] <Spring> kepstin, I saw someone comment that ffmpeg added support for VP9 alpha a few months ago, is that correct?
[15:01:49 CEST] <Spring> https://github.com/FFmpeg/FFmpeg/commit/acca56d9629b7fc158ce188190d22314c3d92c39
[15:02:58 CEST] <Spring> unfortunately I don't have any source with alpha atm to test it
[15:03:18 CEST] <kepstin> Spring: no idea, it's not in the build I have anyways.
[15:03:48 CEST] <Spring> I may have to send them a follow-up PM in that case
[15:06:36 CEST] <diffuse> kepstin: that test didnt work out for me, can you point me in the write direction regarding updating the header after its done writing?
[15:06:39 CEST] <Spring> actually, no. Just converted a transparent PNG and it display fine.
[15:06:44 CEST] <Spring> *displays
[15:06:58 CEST] <Spring> presumably it would work with alpha video
[17:39:36 CEST] <noob> good day, anyone know how to use ffmpeg.exe to extract h264 nalu from *.mp4 file and save them per frame%d.dat file?
[17:40:31 CEST] <noob> I've tried something like ffmpeg -i {some mp4 file} -vcodec copy -bsf h264_mp4toannexb -an -f {rawvideo|h264|whatever} out%d.h264 but it outputs a single file not muliple frame files.
[17:42:26 CEST] <TwinTailed> I am getting "[libx264 @ 01d88500] non-strictly-monotonic PTS" and an invalid value for DTS (-2147483648)
[17:42:35 CEST] <TwinTailed> how can i fix that?
[17:49:19 CEST] <TwinTailed> no one replied to my mailing list either :/
[17:56:02 CEST] <TwinTailed> ok, can someone explain me this?
[17:56:03 CEST] <TwinTailed> The timestamps (pts, dts) must be set to correct values in the stream's timebase (unless the output format is flagged with the AVFMT_NOTIMESTAMPS flag, then they can be set to AV_NOPTS_VALUE). The dts for subsequent packets in one stream must be strictly increasing (unless the output format is flagged with the AVFMT_TS_NONSTRICT, then they merely have to be nondecreasing). duration) should also be
[17:56:03 CEST] <TwinTailed> set if known.
[18:09:06 CEST] <DHE> data going into the encoders need to be strictly increasing PTS values. data going into the file containers need to be strictly increasing DTS values.
[18:09:46 CEST] <DHE> assuming sane inputs to the encoder, it should output packets in DTS order allowing them to be simply written to the AVFormatContext
[18:10:27 CEST] <TwinTailed> DHE: DTS is set to 0
[18:10:28 CEST] <TwinTailed> always
[18:11:04 CEST] <DHE> what codec?
[18:11:09 CEST] <TwinTailed> H264
[18:11:22 CEST] <Mavrik> DHE, we explained all that to him yesterday and somehow it didn't stick :)
[18:11:35 CEST] <DHE> Mavrik: I saw the conversation but glazed over it...
[18:11:47 CEST] <DHE> so I'm starting over here
[18:12:14 CEST] <TwinTailed> You explained, but you didn't give me a fix, you told me that the decoder/encoder should take care of that
[18:12:47 CEST] <Mavrik> DHE, ok :)
[18:13:15 CEST] <DHE> I said the input to the encoder needs to have proper PTS values, in which case the magic just sorta happens
[18:14:59 CEST] <TwinTailed> I just want to know why DTS is always 0
[18:18:03 CEST] <TwinTailed> I have tried the deprecated decode/encode functions, same problem
[18:18:21 CEST] <BtbN> so the dts coming out of libx264 is allways 0?
[18:18:41 CEST] <BtbN> that can only mean you're giving it invalid input timestamps
[18:20:24 CEST] <TwinTailed> BtbN: I am using av_packet_init, then passing it to avcodec_send_packet
[18:20:38 CEST] <TwinTailed> Any extra step i should take
[18:20:42 CEST] <TwinTailed> ?
[18:21:25 CEST] <BtbN> you are sending packets to libx264?
[18:21:54 CEST] <TwinTailed> yes?
[18:22:04 CEST] <BtbN> it's an encoder, you send it frames and get packets.
[18:22:54 CEST] <TwinTailed> I did a avcodec_find_decoder() for the input stream
[18:23:37 CEST] <Mavrik> did you actually take a look at encoding examples in docs directory? :)
[18:23:57 CEST] <TwinTailed> Mavrik: yes
[18:24:04 CEST] <TwinTailed> transcoding.c and remux.c
[18:27:25 CEST] <TwinTailed> BtbN: How do i give correct input timestamps?
[18:28:04 CEST] <BtbN> by setting the correct pts on the input frame, which you usually just get like that from the decoder.
[18:28:37 CEST] <TwinTailed> if not, i should use Frame->pts = av_frame_get_best_effort_timestamp
[18:28:38 CEST] <TwinTailed> ?
[18:29:26 CEST] <BtbN> Why would there not be a propper timestamp in the first place?
[18:31:24 CEST] <TwinTailed> it worked :)
[18:31:43 CEST] <TwinTailed> BtbN: I had to use these lines before decoding:
[18:31:57 CEST] <TwinTailed> pkts->pts = av_rescale_q_rnd(pkts->pts, ps->streams[stream_index]->time_base, ps2->streams[stream_index]->time_base, AV_ROUND_NEAR_INF|AV_ROUND_PASS_MINMAX);
[18:31:58 CEST] <TwinTailed>             pkts->dts = av_rescale_q_rnd(pkts->dts, ps->streams[stream_index]->time_base, ps2->streams[stream_index]->time_base, AV_ROUND_NEAR_INF|AV_ROUND_PASS_MINMAX);
[18:31:58 CEST] <TwinTailed>             pkts->duration = av_rescale_q(pkts->duration, ps->streams[stream_index]->time_base, ps->streams[stream_index]->time_base);
[18:32:11 CEST] <TwinTailed> then before encoding, using the line i told u about: Frame->pts = av_frame_get_best_effort_timestamp
[18:34:51 CEST] <TwinTailed> BtbN: Is there a way to set the major brand from iso?
[18:35:14 CEST] <TwinTailed> to ftypmp42 for example
[19:35:05 CEST] <bazzy> I'm using a small patch to FFMPEG to allow a particular streaming support previously unavailable. What does it mean if `ffplay` performs perfectly, but `ffmpeg` blurts out "[abuffer @ 0x2103600] Unable to parse option value "(null)" as sample format" and quits
[19:36:27 CEST] <bazzy> For some reason, ffplay has no problem setting the sample format automatically to fltp, but in this case, even manually specifying on the command line seems to fail (I've tried it before/after/both of input file)
[20:22:51 CEST] <diffuse> can av_bitstream_filter_filter be used to take a buffer fill of PCM audio and convert it to WAV?
[20:27:06 CEST] <durandal_1707> diffuse: why? What you need?
[20:29:10 CEST] <diffuse> I have most of what i need working, i can take an audio file and generate headerless pcm, which i need, then i also want to take that headerless pcm and create a WAV out of it
[20:29:20 CEST] <diffuse> the pcm -> wav conversion is where i am stuck
[20:37:32 CEST] <kepstin> diffuse: this is going back to that issue you were having with the length field?
[20:37:52 CEST] <kepstin> the wav muxer in libavformat writes the length in the write_trailer function, assuming the output is seekable
[20:38:19 CEST] <diffuse> yes
[20:42:21 CEST] <diffuse> i have a buffer, char *pcm, int pcmLength.
[20:42:40 CEST] <diffuse> All i want is just to put a wav header on there, i see avformat_write_header and av_write_trailer
[20:44:20 CEST] <kepstin> you can just "write a wav header" with libavformat; you'll have to set up an output context, write header, write packets to it, write trailer.
[20:44:25 CEST] <kepstin> you can't just*
[20:45:07 CEST] <diffuse> that's what i've done
[20:45:13 CEST] <diffuse> but totally incorrectly
[20:46:25 CEST] <kepstin> diffuse: I assume you're referencing something like doc/examples/muxing.c for this (that does audio+video, you can probably get away with something simpler...)
[20:46:41 CEST] <diffuse> i've looked at a ton of docs
[20:50:13 CEST] <diffuse> i guess in my mind
[20:50:32 CEST] <diffuse> i could have take my char *pcm and pcmLength, setup an avio context
[20:50:51 CEST] <diffuse> err
[20:53:30 CEST] <kepstin> to be honest, if the only thing you're using ffmpeg for is writing raw pcm audio to a wav file, it's probably a bit overkill. the wave header itself is ridiculously simple (unless you have to deal with >=4gb files)
[20:54:01 CEST] <diffuse> Yeah, I have some code to write it in myself
[20:54:10 CEST] <diffuse> this isnt the only thing im used ffmpeg for
[20:54:11 CEST] <kepstin> all of the extra abstractions in ffmpeg to make wav behave the same as the other more complex formats ffmpeg supports makes it harder to use :)
[20:54:58 CEST] <diffuse> I'd prefer making all my code use ffmpeg, but i am getting to the point where might just create the header myself and write it in
[20:55:48 CEST] <kepstin> but yeah, the code for writing pcm audio to wav in ffmpeg is basically the same as the code to e.g. write opus audio to mkv
[20:56:31 CEST] <kepstin> aside from if you're sufficiently clever you can probably skip the "pcm_s16le" encoder and make up "pre-encoded" packets to hand directly to the muxer
[20:58:50 CEST] <diffuse> link?
[21:06:25 CEST] <ChocolateArmpits> Does "-f null -" simply read the file with the specified streams ?
[21:07:58 CEST] <kepstin> ChocolateArmpits: I assume you're talking about a command like "ffmpeg -i somemediafile -f null -" ?
[21:08:26 CEST] <kepstin> ChocolateArmpits: that will read the full input file, decoding all the media, then throw it out, writing nothing to stdout.
[21:16:26 CEST] <ChocolateArmpits> kepstin: hmm so adding -codec copy would make it read the stream only without decoding ?
[21:17:00 CEST] <ChocolateArmpits> Interestingly -f null encodes video frames in wrapped_avframes so I guess no decoding takes place there ?
[21:17:12 CEST] <kepstin> ChocolateArmpits: I assume so; I think the "null" muxer accepts every codec.
[21:17:28 CEST] <ChocolateArmpits> Well it says
[21:17:29 CEST] <ChocolateArmpits> Stream #0:1 -> #0:1 (mp3 (native) -> pcm_s16le (native))
[21:17:36 CEST] <ChocolateArmpits> so the audio does get transcoded
[21:17:44 CEST] <c_14> wrapped_avframes are decoded
[21:17:52 CEST] <c_14> They're an internal (more efficient) representation of rawvideo
[21:18:02 CEST] <ChocolateArmpits> oh ok good to know
[21:18:46 CEST] <ChocolateArmpits> Is there any performance difference between "-f null - " vs "-f nut -y NUL" (on windows) ?
[21:19:35 CEST] <ChocolateArmpits> I tried testing but drive caching ruins the test
[21:19:49 CEST] <furq> why would drive caching affect it
[21:19:55 CEST] <furq> nothing's being written to disk in either case
[21:20:25 CEST] <c_14> -f nut -y NUL has muxing overhead -f null shouldn't
[21:21:01 CEST] <ChocolateArmpits> Well in my experience parts of files are read faster after those have been read before
[21:21:16 CEST] <ChocolateArmpits> RAID 0 setup where that happened
[21:21:35 CEST] <furq> you can just generate an input file
[21:21:40 CEST] <furq> -f lavfi -i smptebars or something
[21:21:54 CEST] <ChocolateArmpits> but the framerate is fixed
[21:22:00 CEST] <ChocolateArmpits> I would like to saturate it
[21:22:35 CEST] <furq> -i smptebars=s=3840x2160:r=120
[21:22:38 CEST] <ChocolateArmpits> Anyways, if there's less overhead then it should be faster
[21:29:03 CEST] <garth> Is the in-loop deblock filter (on either x264 or x265) being performed during decoding when ffmpeg is use to re-encode video? (specifically I'm doing x264/x265 to x265 encoding)
[21:30:25 CEST] <ChocolateArmpits> I would figure yes, I think you can tune decoding settings to turn it off
[21:33:55 CEST] <garth> any idea how (or where to look). I've been searching and all I'm finding is to change the value for the encoder
[21:37:05 CEST] <kepstin> garth: I don't think you can switch it on the decoder; the encoder signals whether to use it or not (if you use the wrong setting, predictions won't work because the decoded video won't match)
[21:37:28 CEST] <ChocolateArmpits> There's "deblock" input parameter
[21:37:34 CEST] <ChocolateArmpits> "Set loop filter parameters, in alpha:beta form."
[21:38:05 CEST] <ChocolateArmpits> As far as I understand if you lower it too much it may render the picture with very little or no deblocking
[21:38:52 CEST] <kepstin> well, if  you *can* override it, and do, the only thing it'll do is lower the quality/accuracy of the decoded video :/
[21:39:27 CEST] <ChocolateArmpits> x264 encoder has "no-deblock" parameter, wonder if that translates to the decoder ffmpeg uses
[21:40:18 CEST] <kepstin> ChocolateArmpits: like I said to garth, the encoder signals in the stream what deblock settings the decoder should be using.
[21:40:41 CEST] <ChocolateArmpits> yeah
[21:41:35 CEST] <kepstin> if the decoder uses the wrongs settings, the picture will be noticably wrong, especially on predicted frames, since the predictions are based on the picture *after deblocking is applied*
[21:47:04 CEST] <garth> interesting. I was asking since whatever I do, the output stream always have noticeably less details then the input stream, even if I re-encode to the same codec using the same (or even better options, as read from mediainfo). I know there's loss of quality of each encode, but with similar/better options I should still reach something close, which I'm not. I was thinking maybe the decoding of the
[21:47:04 CEST] <garth> re-encode deblock (which blurs a bit the image if I understand it right), and then during playback the deblock happens a second time making it even more blurry
[21:48:00 CEST] <ChocolateArmpits> What's the starting bitrate for your video?
[21:48:02 CEST] <garth> Looking into that parameter, I remember seeing that some players allowed to override the deblock value during playback, and it made me wonder if I could prevent the deblock from happening during re-encode so as to lower the loss of quality
[21:50:08 CEST] <kepstin> garth: depends a lot on the input video and what you mean by "same or better options", and what those options actually are...
[21:50:32 CEST] <garth> I've tried it with greatly varying starting quality. From a x264 at 800kbit/s, up to 6000kbit/s, and similarly with x265 streams, even some high CRF ones
[21:50:42 CEST] <kepstin> like, if your original is a -crf 18 encode, and you re-encode it with -crf 18, you will probably need really good eyese to tell the difference
[21:51:34 CEST] <garth> this was for 720p video
[21:52:20 CEST] <kepstin> but yeah, if your source stream plays back correctly in mpv, and the re-encoded/transcoded video looks less sharp, then the problem is with the settings being used on the encoder when re-encoding the video
[21:52:56 CEST] <garth> kepstin: that's the thing. In my tests, I've put in the exact same options as the input video had (according to mediainfo), even increased the CRF quality (so decreased the value), or put in higher bitrate (for bitrate encoded, keeping the same # passes), and I'm still seeing a notable difference in the output video
[21:53:21 CEST] <kepstin> since the video that's passed to the encoder inside ffmpeg is *exactly the same* as the video shown on your screen with a player
[21:53:39 CEST] <kepstin> so it's up to the encoder to decide what to do on the re-encode to make it look as close as possible
[21:55:10 CEST] <kepstin> with lossy codecs there will *always* be a generation loss, but it can be minimized by using extremely high quality settings on the transcode.
[21:55:44 CEST] <JEEB> &9
[21:56:02 CEST] <kepstin> why are you even trying to re-encode a video with "the same quality settings" anyways? just stream-copy it :/
[21:57:10 CEST] <ChocolateArmpits> He might be hardsubbing it, no ?
[22:01:02 CEST] <garth> My goal is to  re-encoding to save space & make it slightly easier to play on my htpc (main playback machine). So I'm moving all my x264 video to x265, and also some of the x265 to a slightly lower quality x265, sometimes also downscaling the higher quality video. Now with all this I expected loss of quality, but looking at the result, I find it degraded a bit too much. After trying out a lot of options
[22:01:02 CEST] <garth> to try and raise the quality, I finally decided to try re-encoding with the same options as the input had (just to see if I was doing something wrong or there's something else in play). This is when I discovered that re-encoding keeping the same encoding options as the initial video had, I am still losing quite a lot of details to what look like blur
[22:01:23 CEST] <garth> (not hard subbing, I hate that)
[22:01:55 CEST] <kepstin> h.265 is the opposite of "making it slightly easier to play", although it can in theory save space
[22:02:35 CEST] <kepstin> garth: one thing to check - is the source videos 10bit? if so, re-encoding with the "same settings" using an 8-bit x264 is not actually anywhere close to the same settings ;)
[22:02:55 CEST] <garth> I should have clarified. The 'make it slightly easier to play' is for video that is already in x265 (I've noticed that some options made my htpc struggle too much, so I'm lowering those so it will play better)
[22:03:47 CEST] <garth> I've tried with both 8 & 10 bit sources, encoded to the same bit-ness
[22:04:32 CEST] <garth> so 8->8 or 10->10
[22:05:06 CEST] <kepstin> but yeah, to rule out other issues, try doing a re-encode with 8-bit x264, "-c:v libx264 -crf 18" and no other options, and verify that it has minimal/barely noticable quality reduction.
[22:05:40 CEST] <furq> garth: what x265 preset are you using
[22:05:41 CEST] <kepstin> (it should generate a significantly bigger output on most videos, that's ok)
[22:05:44 CEST] <garth> The difference of image quality looks to me like a blur upon a blur (but I'm not expert). Hence the question on the deblock parameter
[22:06:02 CEST] <kepstin> garth: it would also be helpful if you provide an example of the degredation you're seeing
[22:06:44 CEST] <kepstin> (although comparing individual frames on paused video doesn't really provide an accurate comparison, but better than nothing)
[22:07:05 CEST] <garth> furq:  I tend not to specify a preset, but like I had said, I put in as options all the parameters I'm seeing in mediainfo for the input video while doing my testing
[22:08:09 CEST] <garth> kepstin: I haven't kept any of the test video so far, but I could generate some (as soon as my cpu frees up from what it's doing now)
[22:08:32 CEST] <kepstin> garth: in general, you should not attempt to copy options (it'll never really work on lossy codecs), but rather pick a set of options that give quality acceptable to you and use them consistently.
[22:08:35 CEST] <furq> that's not really a worthwhile thing to do in general, but even less so going between x264 and x265
[22:08:45 CEST] <furq> a lot of the options don't map directly and also x265 has a bunch of new options
[22:09:06 CEST] <kepstin> which with x264/x26 should consist of "pick a preset that's as slow as you can stand, and pick a crf that has high enough quality, and don't touch anything else"
[22:09:32 CEST] <furq> but yeah if you're using -preset medium (the default iirc) then there's not usually an appreciable difference in quality compared to x264 veryslow
[22:10:39 CEST] <furq> i guess it makes sense if you really trust that the original encoder has analysed the source and picked precisely optimised settings
[22:11:09 CEST] <furq> but i don't have that high an opinion of people who encode things
[22:11:22 CEST] <furq> s/makes sense/makes some sense/
[22:15:10 CEST] <garth> furq: I get what you're saying. It's just that right now I'm trying to find out why I'm loosing so much details. My testing led me to try using the same encoding options as the input file had; which I'm expecting will give me a mostly similar video, but what I'm seeing is a loss of quality that seems too high
[22:15:54 CEST] <furq> i would not expect it to do that if you're going between codecs
[22:16:07 CEST] <garth> in the testing, I'm using the same codec
[22:16:41 CEST] <kepstin> and i'm saying "using the same settings in no way guarantees a re-encode will look the same", so please try with e.g. libx264 -crf 18 and no other options, to verify that it's not something other than the re-encode itself that's losing quality.
[22:17:34 CEST] <furq> if you think that the in-loop deblocker is causing issues then you can verify it by converting to rawvideo
[22:17:39 CEST] <furq> i doubt it is though
[22:17:57 CEST] <kepstin> well, if it was the in-loop deblocker, playing the source video would already look blurry
[22:18:25 CEST] <furq> if you're using ffmpeg's h264 decoder then yeah
[22:18:36 CEST] <furq> also probably if you're using any other decoder
[22:19:49 CEST] <kepstin> like, depending on the cause of the loss of sharpness, it might be that tweaking the settings on the deblocker on the re-encode could help reduce the issue.
[22:21:01 CEST] <kepstin> (using e.g. "-tune film" does that, iirc)
[22:21:46 CEST] <kepstin> that also tweaks the psy-rd stuff, which could reduce smearing on high-motion things
[22:21:52 CEST] <garth> (I'm doing a re-encode right now with what kepstin suggested)
[22:22:06 CEST] <kepstin> (since i haven't seen any examples of what you're talking about, so I don't know what options might help)
[22:24:18 CEST] <nick0> Hi, I'm getting "Assertion index == 0 || ie[-1].timestamp < timestamp failed at libavformat/utils.c:1922" trying to resample some audio, what does that error indicate? I'm not touching any timestamps and not encoding any audio, just decoding and resampling so I'm at a bit of a loss where to look
[22:24:28 CEST] <garth> but seeing what kepstin & furq are saying, this goes back to the original question I had. During a re-encode, does ffmpeg deblock the decoded video before passing it to the encoder? I'm asking because doing so would explain everything (since the encoding will be telling the player to deblock something that has already been deblocked)
[22:25:42 CEST] <kepstin> garth: ffmpeg does not additional deblocking outside of that required as part of the codec's decoding process. THe video fed to the next encoder is exactly the same as what would be shown on the screen with a player.
[22:26:08 CEST] <kepstin> (unless you use additional filters or options specified manually)
[22:26:24 CEST] <furq> yeah there's no way to turn that off because the decoded video would look wrong
[22:27:02 CEST] <furq> in-loop deblocking is a fundamental part of how h264 works
[22:29:00 CEST] <garth> no additional filters
[22:29:20 CEST] <kepstin> garth: if the original video looks fine when played with a player using ffmpeg to decode - e.g. mpv, vlc - then the in-loop deblocker is *not the problem*
[23:33:31 CEST] <garth> ok, so maybe part of the issue was that I was using an older version on the encoding machine. While doing what kepstin suggested, I saw much better result on this machine then what I had before
[23:34:49 CEST] <garth> (I didn't even realized that the encoding machine wasn't getting updated like it should)
[23:37:38 CEST] <garth> I'm still seeing a bit of deterioration with the x265->x265 encode, could someone please confirm that it is normal: source http://picpaste.com/0daec31f3475bcbc24ab55ac57f6c02a.png (x265 900kbit/s 2 pass), re-encode: http://picpaste.com/b1e20f81be47644c9cbef3d30c719dd2.png (libx265 -crf 18)
[23:38:40 CEST] <garth> what's easiest to spot is the guy's right hand and his cheek (really appreciate the second opinion)
[23:52:19 CEST] <iive> garth: i'm not sure -crf is libx265 options.
[23:53:23 CEST] <garth> iive: I shortened that, I meant: -x265-params crf=18
[23:55:12 CEST] <iive> oh, ok then. no other ideas
[23:55:31 CEST] <iive> does it output statistic for the qp used?
[23:59:28 CEST] <ChefBrad> anyone alive around here by chance
[00:00:00 CEST] --- Sat Sep 24 2016