Re: [FFmpeg-user] dpx 16bit files to ffv1 problem with the frammd5 sum
On 20/10/2020 12:51, boecki wrote: Hello, I have some problems to encode a file from a dpx 16bit sequence to ffv1 and create a proper framemd5 checksum. The problem is like this, that the checksum from the file is different to the checksum of the dpx frames. framemd5 depends on FFmpeg selected pix_fmt for the output, and DPX 16-bit default pix_fmt is rgb48 (rgb48le or rgb48be depending on the DPX endianess) vs FFV1 16-bit default pix_fmt is gbrp16le. You need to force your framemd5 analysis to a common pix_fmt, add " -pix_fmt gbrp16le" for the DPX framemd5 or " -pix_fmt rgb48le" (or " -pix_fmt rgb48be" depending on the source DPX endianess) for the FFV1 framemd5, and you'll find the same results (I tested on a DPX 16-bit BE converted to FFV1 and I get the same framemd5 whatever the pix_fmt selected for the final comparison, i.e. in both cases you lose no frame content). ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] Avoid "not enough frames to estimate rate" message when with concat
Hello, I try to suppress or at least to have the following message once: [dpx_pipe @ 025ad0cc37c0] Stream #0: not enough frames to estimate rate; consider increasing probesize when I use a concat file (I don't have the message if I use DPX directly, with e.g. "-i %06d.dpx", but I can't use this template in my use case, file names are relatively random). I tried the following options: -probesize 2000M -analyzeduration 2000M -probesize 2000M Without success. In libavformat/utils.c I see: if (read_size >= probesize) and strcmp(ic->iformat->name, "image2")) before the log message, looks like I don't succeed to provide the probesize to "image2". I have a file test.txt containing: file test.dpx duration 0.04 file test.dpx duration 0.04 then with FFmpeg Git master: ffmpeg -f lavfi -i testsrc=size=1920x1080 -frames:v 1 test.dpx ffmpeg -f concat -i test.txt test.mkv If I repeat the test.txt file content several times (in practice, I have thousands of different files listed in the concat file), I have the warning message several times, which pollutes the logs: [dpx_pipe @ 02041aae3a00] Stream #0: not enough frames to estimate rate; consider increasing probesize Last message repeated 2 times [dpx_pipe @ 02041c529400] Stream #0: not enough frames to estimate rate; consider increasing probesize Last message repeated 3 times ... If I replace 1920x1080 with 1280x720, I don't have this warning. I use concat as this is the only method I found for providing a list of random file names when I can not use templates like "-i %06d.dpx", but if there is another method I am interested in knowing it. Jérôme ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Question about file size changes
On 18/06/2019 15:01, Moritz Barsnick wrote: I don't know why mediainfo determines different video bit rates (1817 vs. 1870), ffmpeg claims to have copied exactly the same amount of video into the target containers. I don't trust mediainfo on this. As it is not possible to compute the bitrate per stream in MTS/M2TS without parsing the whole file, MediaInfo does an estimation, and in this case the estimation is unfortunately different depending on the container used. I'll fix that in MediaInfo for at least having the same video bitrate output when one changes from MTS to M2TS (I plan to add "estimated" later when relevant so more explicit that it could be different for the same stream, but more complex in the code), so you would avoid such kind of question about the video bitrate (the question about the overall bitrate and file size change will stay though, due to the good reasons you provided). Jérôme, developer of MediaInfo. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Interlace vs. Interleaved Fields
On 9/1/2018 11:12 PM, Chris wrote: What is the difference, if any, between "Interleaved Fields" and "Interlace" as far as MediaInfo is concerned? Interlaced content can be coded in different manners: - Interleaved fields : line 0, 1, 2, 3 ... 476, 477, 478, 479 (in 1 block), similar to how progressive content is coded - Separated fields: line 0, 2 ... 476, 478, 1, 3 ... 477, 479 (2 fields in 1 block or each field in its own block) graphical display of the difference at e.g. http://www.mir.com/DMG/interl.html ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] MXF XAVC UHD video stream modified while using the -copy option
On 06/02/2018 18:09, Ronan Ricou wrote: The thing is, some video data are lost during the remux as my file is smaller than it should be. If I check with MediaInfo, the video stream bit rate, bits/(pixel*frame) value and stream size are smaller. (disclaimer: I am the main MediaInfo developer) In your case I think the video bit rate is estimated by MediaInfo from container size minus audio size minus estimated container overhead, and the difference may be due to some padding bytes in the MXF stream not copied by FFmpeg (for good reasons) and not the video stream size itself. MediaInfo is not intended to be used for such small difference check, at least by default (i.e. without scanning the whole file). An additional information about if the indicated size is computed for sure or estimated is on our ToDo-list without ETA. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Strange output of ffprobe
Le 27/10/2016 à 18:06, Анатолий Коростелев a écrit : Hello! Recently I recieved a mp4 for playing. When I tried to play this file I didn't hear any sound in some players (in ffplay sound worked). When I looked at the metadata of this file (via ffprobe), I saw the following: [...] Then I used mediainfo utility to see the metadata of the file: [...] As you can see the "Sampling rate" in mediainfo is 7 350 Hz (it's illegal value) It is not an illegal value, AAC specs authorize it. while "Sampling rate" in ffprobe is 48000 Hz. I think that the problem with the sound of this file has been caused by encoder errors/misconfiguration. But it's very strange that ffrobe always shows me 48000 Hz Sampling rate. Is this a bug or something else? 48000 Hz seems the correct one, so no FFmpeg bug but MediaInfo bug (as a first shot, issue is that there is an ES descriptor without AudioSpecificConfig element in the track header and MediaInfo does not manage correctly this case; note that this may be the reason some players does not play sound). Jérôme, developer of MediaInfo. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Source v210.mov has no interlacement info, ffv1 transcode is listed as progressive
Le 28/07/2016 à 10:38, Kieran O Leary a écrit : Hi, My input file was generated from Avid Media Composer 8. Link: https://www.dropbox.com/s/yed44wj5lq9jg8h/2fr.mov?dl=0 If I use -c copy to remux to mov or mkv, then the lack of interlacement info is maintained. When I encode with FFV1, using either MKV or MOV, the file is listed as progressive in mediainfo. However, the issue may not be specific to FFV1 as progressive values appear in mediainfo when using -c:v prores (in mov container) and libx264 in mov and mkv. The difficulty here is to define "progressive": is it how it is coded or how it should be displayed? your input is coded progressively (one v210 frame) despite the fact (you affirm it) your ingest is TFF (there is no info about it in the input file). I guess that FFmpeg considers by default that v210 is always to be displayed progressive and sets the FFV1 encoder to progressive (value 3) instead of "unknown" (value 0) in the FFV1 bitstream. You can force FFmpeg to configure the encoder with interlacement. ffmpeg -i 2fr.mov -vf "interlace=lowpass=0:scan=tff" -c:v ffv1 -level 3 out.mkv https://ffmpeg.org/ffmpeg-all.html#interlace and your FFV1 stream is coded as interlaced (with an improvement about file size) (note: the result is interlaced but looks like there is only 1 frame instead of 2, please double-check the command line; I am not a FFmpeg expert so a better command line would be appreciated) But please use it only if you are sure about your input because other people will rely on this information. [...] ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Valid number of slices for libx264 and FFV1
Le 26/04/2016 à 08:49, Kal Sze a écrit : [...] And what is the valid number of slices when encoding as FFV1 level 3? The wiki says 4, 6, 9, 12, 16, 24, or 30; but I have not seen ffmpeg complain if I try to specify something like 25 slices for a 512x424 video. Does ffmpeg just coerce the value to a valid one? FFmpeg rejects the command if you provide a "not valid" (from FFmpeg point of view) slice number (e.g. 5); In theory (if we refer to the specs), any count of slices is possible, depending of the encoder. In practice: - FFmpeg encoder tries to find a value compatible with some constraints (minimum 2 rows and 2 columns, rows count must not be > 2x columns count, columns count must not be > 2x rows count, and slices count can not be more than 64). so 25 is acceptable (5x5, OK), 26 is not (13x2 or 2x13 are the only combinations, NOK) - FFmpeg decoder accepts any slices count below 256 Note that it is slightly different than H264, slices are in macro-blocks sequence order only (no rows/cols). ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
