Re: [FFmpeg-user] Basic dash muxing
I see, thank you. I am doing now from a .yuv video and the HLS segmentation works perfectly but I still have problems with dash. There is no error in the execution but I get less output files than expected so I did some mistake with the command options. For: ffmpeg -s:v 1920x1080 -r 25 -i inputVideo.yuv -c:a aac -c:v libx265 -f dash –seg_duration 2 out.mpd The outputs are: init-stream0.m4s, chunk-stream0-1.m4s, chunk-stream0-2.m4s, out.mpd The video is 20 seconds, for 2 second segments it should be 10 segment files at least (Plus mpd). I don't know what I am doing wrong. Thank you for your help, best regards. El 2020-03-02 18:02, Carl Eugen Hoyos escribió: Am Mo., 2. März 2020 um 15:48 Uhr schrieb Jesús Aguilar Armijo : 1.- The input video is a 20 seconds h265 encoded video from a .yuv file, is that input correct? I understand that the dash command creates segments and manifest files from a previously encoded video, so it should be correct at my understanding. It is (with above command line) unnecessary: Since you are re-encoding (-c:v libx265) any input is accepted and will be converted into h265. Theoretically, you can copy the video stream from input to output (-c:v copy) in this case the input has to be h265 encoded (if that's what you need). Carl Eugen ___ 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 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] Showinfo bug?
On 3/4/20, Mark Filipak wrote: > Is this a showinfo bug, or am I misinterpreting the results? > > For VOBs that are known to be 23.976 FPS, soft-telecined, this command: > 'ffprobe -f lavfi movie=VTS_01_1.VOB,showinfo' > reports that they're 59.94 FPS. > > The first & last lines of output show this: > "[Parsed_showinfo_1 @ 01d381f6dc80] config in time_base: 1/9, > frame_rate: 6/1001" > "Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 720x480 > [SAR 1:1 DAR 3:2], 59.94 tbr, 90k tbn, 90k tbc" > > This seems to be a rather big error, if indeed it is an error. At > question is the reliability of ff*. > I trust more ff* than you. > In contrast, as expected, 29.97 FPS, hard-telecined videos are reported > as 29.97 FPS. > "[Parsed_showinfo_1 @ 0222eeb2dc80] config in time_base: 1/9, > frame_rate: 3/1001" > "Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 720x480 > [SAR 1:1 DAR 3:2], 29.97 fps, 29.97 tbr, 90k tbn, 90k tbc". > > Please comment. I'm not particularly knowledgeable regarding ff*. > > Regards, > Mark. > ___ > 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 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] Basic dash muxing
Am Mi., 4. März 2020 um 09:13 Uhr schrieb Jesús Aguilar Armijo : > > I see, thank you. I am doing now from a .yuv video and the HLS > segmentation works perfectly but I still have problems with dash. There > is no error in the execution but I get less output files than expected > so I did some mistake with the command options. > > For: ffmpeg -s:v 1920x1080 -r 25 -i inputVideo.yuv -c:a aac -c:v libx265 > -f dash –seg_duration 2 out.mpd > The outputs are: init-stream0.m4s, chunk-stream0-1.m4s, > chunk-stream0-2.m4s, out.mpd > > The video is 20 seconds, for 2 second segments it should be 10 segment > files at least (Plus mpd). Do you get 20 seconds output if you play the resulting dash with ffplay? It is possible that you have to force keyframes for short segments. Please find out what top-posting means and avoid it here. Carl Eugen ___ 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] Showinfo bug?
On 03/04/2020 04:57 AM, Paul B Mahol wrote: On 3/4/20, Mark Filipak wrote: Is this a showinfo bug, or am I misinterpreting the results? For VOBs that are known to be 23.976 FPS, soft-telecined, this command: 'ffprobe -f lavfi movie=VTS_01_1.VOB,showinfo' reports that they're 59.94 FPS. The first & last lines of output show this: "[Parsed_showinfo_1 @ 01d381f6dc80] config in time_base: 1/9, frame_rate: 6/1001" "Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 720x480 [SAR 1:1 DAR 3:2], 59.94 tbr, 90k tbn, 90k tbc" This seems to be a rather big error, if indeed it is an error. At question is the reliability of ff*. I trust more ff* than you. Paul, I trust that your answer indicates that I'm simply misinterpreting the results. So, to what does "frame_rate: 6/1001" refer? ___ 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] Showinfo bug?
On 3/4/20, Mark Filipak wrote: > On 03/04/2020 04:57 AM, Paul B Mahol wrote: >> On 3/4/20, Mark Filipak wrote: >>> Is this a showinfo bug, or am I misinterpreting the results? >>> >>> For VOBs that are known to be 23.976 FPS, soft-telecined, this command: >>> 'ffprobe -f lavfi movie=VTS_01_1.VOB,showinfo' >>> reports that they're 59.94 FPS. >>> >>> The first & last lines of output show this: >>> "[Parsed_showinfo_1 @ 01d381f6dc80] config in time_base: 1/9, >>> frame_rate: 6/1001" >>> "Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 720x480 >>> [SAR 1:1 DAR 3:2], 59.94 tbr, 90k tbn, 90k tbc" >>> >>> This seems to be a rather big error, if indeed it is an error. At >>> question is the reliability of ff*. >>> >> >> I trust more ff* than you. > > Paul, I trust that your answer indicates that I'm simply misinterpreting > the results. > > So, to what does "frame_rate: 6/1001" refer? Can not guess without looking and exact same file. ___ 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] Showinfo bug?
Am Mi., 4. März 2020 um 11:31 Uhr schrieb Mark Filipak : > So, to what does "frame_rate: 6/1001" refer? I suspect the (minor) bug is the wording of the line showinfo prints: tbr != frame rate Otoh, properties inside the filter chain are not necessarily properties of the input file (at least not in general). Carl Eugen ___ 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] filter ffmetadata does not output all metadata and is missing in documentation
On 2020-03-04 01:51, Ulf Zibis wrote: > > Am 04.03.20 um 00:34 schrieb James Darnley: >> On 2020-03-04 00:16, James Darnley wrote: >>> It is clearly present in the input file's metadata so how is it not >>> copied into the output file? > > Even with normal transcoding "creation_time" is listed in the OUTPUT > metadata, but in the resulting output file it is missing. I think the answer to that is shown in a previous log. > $ ~/Projects/ffmpeg/ffmpeg-git-20200211-amd64-static/ffmpeg -i > 20200205_165401.mp4 -f ffmetadata 20200205_165401.meta > Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '20200205_165401.mp4': > Metadata: > major_brand : mp42 > minor_version : 0 > compatible_brands: isommp42 > creation_time : 2020-02-05T19:55:01.00Z > location: -00.7655-047.1715/ > location-eng: -00.7655-047.1715/ > com.android.version: 8.0.0 > Duration: 00:00:58.65, start: 0.00, bitrate: 17273 kb/s > Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), > yuv420p(tv, bt709), 1920x1080, 17013 kb/s, SAR 1:1 DAR 16:9, 29.99 fps, > 30 tbr, 90k tbn, 180k tbc (default) > Metadata: > creation_time : 2020-02-05T19:55:01.00Z > handler_name: VideoHandle > Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, > stereo, fltp, 256 kb/s (default) > Metadata: > creation_time : 2020-02-05T19:55:01.00Z > handler_name: SoundHandle > File '20200205_165401.meta' already exists. Overwrite? [y/N] y > Output #0, ffmetadata, to '20200205_165401.meta': > Metadata: > major_brand : mp42 > minor_version : 0 > compatible_brands: isommp42 > com.android.version: 8.0.0 > location: -00.7655-047.1715/ > location-eng: -00.7655-047.1715/ > encoder : Lavf58.38.100 > Stream mapping: > Press [q] to stop, [?] for help > size= 0kB time=-577014:32:22.77 bitrate=N/A speed=N/A > video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB > muxing overhead: unknown > Output file is empty, nothing was encoded The *other* creation time metadata is on the streams. The ffmetadata output file has no streams. Therefore it has no stream metadata I have no idea if you can change that. >> Trac ticket cause: http://trac.ffmpeg.org/ticket/1439 > That may make sense for normal transcoding, but not for: > ffmpeg -i INPUT.mp4 -f ffmetadata INPUT.meta You're probably right. >> I would say: use ffprobe to get the metadata of files. > > But how to transfer it to the output video? Modify ffmpeg to remove the line I showed before, currently in fftools/ffmpeg_opt.c at line 2608. Or get o->metadata_global_manual to be false. You seem to be able to do that with -map_metadata 0 but I thought that was the default anyway. I manually added creation_time to a file, used that as input for an ffmetadata output and sure enough, there it was. To which I said "what the flaming fuck". ___ 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] Showinfo bug?
On 03/04/2020 05:34 AM, Paul B Mahol wrote: On 3/4/20, Mark Filipak wrote: On 03/04/2020 04:57 AM, Paul B Mahol wrote: On 3/4/20, Mark Filipak wrote: Is this a showinfo bug, or am I misinterpreting the results? For VOBs that are known to be 23.976 FPS, soft-telecined, this command: 'ffprobe -f lavfi movie=VTS_01_1.VOB,showinfo' reports that they're 59.94 FPS. The first & last lines of output show this: "[Parsed_showinfo_1 @ 01d381f6dc80] config in time_base: 1/9, frame_rate: 6/1001" "Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 720x480 [SAR 1:1 DAR 3:2], 59.94 tbr, 90k tbn, 90k tbc" This seems to be a rather big error, if indeed it is an error. At question is the reliability of ff*. I trust more ff* than you. Paul, I trust that your answer indicates that I'm simply misinterpreting the results. So, to what does "frame_rate: 6/1001" refer? Can not guess without looking and exact same file. The 'file' is every 23.976 FPS, soft-telecined video I've checked. Mind you, other ff* functions report them as 29.970 FPS, for example: "Stream #0:1[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, smpte170m, progressive), 720x480 [SAR 32:27 DAR 16:9], Closed Captions, 29.97 fps, 59.94 tbr, 90k tbn, 59.94 tbc" whereas MPV reports "FPS: 29.970 (specified) 23.976 (estimated)". I have been interpreting that as meaning that ff* is reporting metadata whereas MPV is reporting the actual MPEG2 stream. 'ffprobe -f lavfi movie=VTS_01_1.VOB,showinfo' is the only ff* function that reports 6/1001. 23.976 FPS? 29.97 FPS? 59.94 FPS? What am I to believe? ___ 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] red-shift and blue-shift
Hi, is there any known workaround for making a red-shift or a blue-shift? I mean shifting the visible spectrum towards red or blue. In the middle of the spectrum this can be realized by the "hue" filter, but at the end of the spectrum I want a different behaviour. I want a shift instead of a rotation. Colors at the end of the visible spectrum must be shifted to (or from) black. Michael ___ 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] Channel mapping misery
Hi all, Trying to do create files where I can control the audio channels. (From multiple, different sources.) I’ve got it ‘sorta kinda’ working: -threads 0 -i /Volumes/Data/test/C0092.MP4 -ss 1601.809541692 -i /Volumes/Data/test/068.WAV -map 0:0 -filter_complex [0:1][1:0][1:0][1:0][1:0][1:0]amerge=inputs=6,pan=6c|c0=c0|c1=c2|c2=c3|c3=c4|c4=c5|c5=c6[a] -map [a] -c:a pcm_s24le -timecode 01:42:38:10 -metadata:s:v:0 reel_name=C0092 -c:v copy /Volumes/Data/test/C0092.mov (Full output at the bottom) This works, although Wiki says ‘With amerge all inputs must have the same sample rate and format.’ But that does not seem to be the case… (In the docs in the -map_channel section it’s encouraged to use amerge, since -map_channel cannot do conversions…) So, I don’t think my problem lies there. When I add one channel more to the previous command: (the wave file has 10 channels) -threads 0 -i /Volumes/Data/test/C0092.MP4 -ss 1601.809541692 -i /Volumes/Data/test/068.WAV -map 0:0 -filter_complex [0:1][1:0][1:0][1:0][1:0][1:0][1:0]amerge=inputs=7,pan=7c|c0=c0|c1=c2|c2=c3|c3=c4|c4=c5|c5=c6|c6=c7[a] -map [a] -c:a pcm_s24le -timecode 01:42:38:10 -metadata:s:v:0 reel_name=C0092 -c:v copy /Volumes/Data/test/C0092.mov -y This does show the pure channel mapping, but fails with: [Parsed_amerge_0 @ 0x7facfcc28b80] No channel layout for input 1 [Parsed_amerge_0 @ 0x7facfcc28b80] Input channel layouts overlap: output layout will be determined by the number of distinct input channels Assertion outlink->channel_layout == out_layout || !outlink->channel_layout failed at src/libavfilter/af_aresample.c:168 Then, adding yet another channel, the error message changes: -threads 0 -i /Volumes/Data/test/C0092.MP4 -ss 1601.809541692 -i /Volumes/Data/test/068.WAV -map 0:0 -filter_complex [0:1][1:0][1:0][1:0][1:0][1:0][1:0][1:0]amerge=inputs=8,pan=8c|c0=c0|c1=c2|c2=c3|c3=c4|c4=c5|c5=c6|c6=c7|c7=c8[a] -map [a] -c:a pcm_s24le -timecode 01:42:38:10 -metadata:s:v:0 reel_name=C0092 -c:v copy /Volumes/Data/test/C0092.mov -y [Parsed_amerge_0 @ 0x7faa63f0] No channel layout for input 1 [Parsed_amerge_0 @ 0x7faa63f0] Too many channels (max 64) [Parsed_amerge_0 @ 0x7faa63f0] Query format failed for 'Parsed_amerge_0': Invalid argument Error reinitializing filters! Failed to inject frame into filter network: Invalid argument Error while processing the decoded data for stream #1:0 Conversion failed! What am I missing here / what is the correct approach? Thanks, Bouke Working output: ffmpeg version git-2020-02-03-1c15111 Copyright (c) 2000-2020 the FFmpeg developers built with Apple clang version 11.0.0 (clang-1100.0.33.8) configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-appkit --enable-avfoundation --enable-coreimage --enable-audiotoolbox libavutil 56. 38.100 / 56. 38.100 libavcodec 58. 67.100 / 58. 67.100 libavformat58. 37.100 / 58. 37.100 libavdevice58. 9.103 / 58. 9.103 libavfilter 7. 73.100 / 7. 73.100 libswscale 5. 6.100 / 5. 6.100 libswresample 3. 6.100 / 3. 6.100 libpostproc55. 6.100 / 55. 6.100 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fb37180] st: 0 edit list: 1 Missing key frame while searching for timestamp: 1000 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fb37180] st: 0 edit list 1 Cannot find an index entry before timestamp: 1000. Guessed Channel Layout for Input Stream #0.1 : stereo Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/Volumes/Data/test/C0092.MP4': Metadata: major_brand : XAVC minor_version : 16785407 compatible_brands: XAVCmp42iso2 creation_time : 2020-01-30T13:31:25.00Z Duration: 00:00:02.40, start: 0.00, bitrate: 97881 kb/s Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 3840x2160 [SAR 1:1 DAR 16:9], 82959 kb/s, 25 fps, 25 tbr, 25k tbn, 50 tbc (default) Metadata: creation_time : 2020-01-30T13:31:25.00Z handler_name: Video Media Handler encoder : AVC Coding Stream #0:1(und): Audio: pcm_s16be (twos / 0x736F7774), 48000 Hz, stereo, s16, 1536 kb/s (default) Metadata: creation_time : 2020-01-30T13:31:25.00Z handler_name: Sound Media Handler Stream #0:2(und): Data: none (rtmd / 0x646D7472), 204 kb/s (default) Metadata: creation_time :
Re: [FFmpeg-user] red-shift and blue-shift
On 03/04/2020 05:52 AM, Michael Koch wrote: Hi, is there any known workaround for making a red-shift or a blue-shift? I mean shifting the visible spectrum towards red or blue. In the middle of the spectrum this can be realized by the "hue" filter, but at the end of the spectrum I want a different behaviour. I want a shift instead of a rotation. Colors at the end of the visible spectrum must be shifted to (or from) black. Michael You're an astronomer, aren't you, Michael? The method should be obvious. Hop into your starship. For blue shift, power toward your star cluster. For red shift, power away from it and take a picture behind you. ___ 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] What does ffmpeg consider metadata? -- revision
On 2020-03-04 01:02, Mark Filipak wrote: > Kindly disregard the last message. I don't know how 'metadata' got left > out of the command line... > > To me, metadata is such MPEG settings as 'progressive_sequence', > 'top_field_first', 'frame_pred_frame_dct', 'concealment_motion_vectors', > 'q_scale_type', > 'intra_vlc_format', 'alternate_scan', 'repeat_first_field', > 'chroma_420_type', 'progressive_frame'. > > What does ffmpeg consider metadata? All of those look like bitstream features. None of them you could change without re-encoding or a specialized tool that can parse and alter the bitstream. Metadata (as ffmpeg calls it) is tags, like artist and track details on a music file. Plus some other things, like chapters. To edit those software need only understand the container or file format. You probably cannot get the things you mentioned elevated into metadata in ffmpeg because they are only known by separate parts, namely libavcodec and libavformat. ___ 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] Channel mapping misery
Am Mi., 4. März 2020 um 12:02 Uhr schrieb Bouke / VideoToolShed : > When I add one channel more to the previous command: (the wave file has 10 > channels) > > -threads 0 -i /Volumes/Data/test/C0092.MP4 -ss 1601.809541692 -i > /Volumes/Data/test/068.WAV -map 0:0 -filter_complex > [0:1][1:0][1:0][1:0][1:0][1:0][1:0]amerge=inputs=7,pan=7c|c0=c0|c1=c2|c2=c3|c3=c4|c4=c5|c5=c6|c6=c7[a] > -map [a] -c:a pcm_s24le -timecode 01:42:38:10 -metadata:s:v:0 > reel_name=C0092 -c:v copy /Volumes/Data/test/C0092.mov -y > > This does show the pure channel mapping, but fails with: Is it possible that you provided the complete, uncut console output for the working command line but not for the one that fails for you? Carl Eugen ___ 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] filter ffmetadata does not output all metadata and is missing in documentation
Hallo Ulf, On Wed, Mar 04, 2020 at 01:51:37 +0100, Ulf Zibis wrote: > Even with normal transcoding "creation_time" is listed in the OUTPUT > metadata, but in the resulting output file it is missing. Interesting and slightly annoying fact: All metadata that is passed to encoder and muxer is listed. Yet it is up to encoder and muxer, which of these are actually used. (E.g. as far as I understand, MOV/MP4 has a limited set of what can be used.) > >> ffmpeg: dont copy creation_time as the destination file is not > >> created at that time > Linux command "mediainfo" distinguishes between "Encoded date" and > "Tagged date", don't know which is meant to be "creation_time". > In jpeg EXIF we find "DateTimeOriginal" and "DateTimeDigitized". Perhaps this could be documented somewhere, but I don't personally care, in this case. > > Trac ticket cause: http://trac.ffmpeg.org/ticket/1439 > That may make sense for normal transcoding, but not for: > ffmpeg -i INPUT.mp4 -f ffmetadata INPUT.meta In all honesty - also for some other "info" filters and muxers - information *dumping* should happen at input level, not at output. That's why ffprobe was mentioned. On the other hand, in terms of passing on to output, that's of course a different matter. At least this muxer helped you to notice that this specific metadata does *not* arrive at the output. > But how to transfer it to the output video? Since it's explicitly filtered: Have you tried adding it explicitly, from the command line? $ ffmpeg [...] -metadata creation_time=2020-03-04T10:38:45.00Z [...] Actually, a quick Google search(!) shows me that there's an option for passing it from the input: $ ffmpeg [...] -map_metadata 0:g [...] and it seems to work for me. Cheers, Moritz ___ 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] What does ffmpeg consider metadata? -- revision
On 03/04/2020 06:06 AM, James Darnley wrote: On 2020-03-04 01:02, Mark Filipak wrote: Kindly disregard the last message. I don't know how 'metadata' got left out of the command line... To me, metadata is such MPEG settings as 'progressive_sequence', 'top_field_first', 'frame_pred_frame_dct', 'concealment_motion_vectors', 'q_scale_type', 'intra_vlc_format', 'alternate_scan', 'repeat_first_field', 'chroma_420_type', 'progressive_frame'. What does ffmpeg consider metadata? All of those look like bitstream features. None of them you could change without re-encoding or a specialized tool that can parse and alter the bitstream. Metadata (as ffmpeg calls it) is tags, like artist and track details on a music file. Plus some other things, like chapters. To edit those software need only understand the container or file format. You probably cannot get the things you mentioned elevated into metadata in ffmpeg because they are only known by separate parts, namely libavcodec and libavformat. Thanks for your reply. The metadata names above are from the H.262 specification. So, what ff* is calling metadata is not that sort of metadata. That's good to know and explains why ff* reports things like 'repeat_pict' (instead of 'repeat_first_field') and 'interlace_frame' (instead of 'progressive_frame'). I've been assuming that 'repeat_pict' == 'repeat_first_field' and that 'interlace_frame' == !'progressive_frame'. Now I don't know what to conclude. Good grief. ___ 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] Channel mapping misery
> On 04 Mar 2020, at 12:06, Carl Eugen Hoyos wrote: > > Am Mi., 4. März 2020 um 12:02 Uhr schrieb Bouke / VideoToolShed > : > >> When I add one channel more to the previous command: (the wave file has 10 >> channels) >> >> -threads 0 -i /Volumes/Data/test/C0092.MP4 -ss 1601.809541692 -i >> /Volumes/Data/test/068.WAV -map 0:0 -filter_complex >> [0:1][1:0][1:0][1:0][1:0][1:0][1:0]amerge=inputs=7,pan=7c|c0=c0|c1=c2|c2=c3|c3=c4|c4=c5|c5=c6|c6=c7[a] >> -map [a] -c:a pcm_s24le -timecode 01:42:38:10 -metadata:s:v:0 >> reel_name=C0092 -c:v copy /Volumes/Data/test/C0092.mov -y >> >> This does show the pure channel mapping, but fails with: > > Is it possible that you provided the complete, uncut console output > for the working command line > but not for the one that fails for you? Hi Carl, I did, it is at the bottom. (Well, it’s not really console, it’s what Python returns. I can’t get it to run from the console. I’ll try again though.) Bouke > > Carl Eugen > ___ > 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 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] red-shift and blue-shift
On 3/4/20, Michael Koch wrote: > Hi, > > is there any known workaround for making a red-shift or a blue-shift? I > mean shifting the visible spectrum towards red or blue. In the middle of > the spectrum this can be realized by the "hue" filter, but at the end of > the spectrum I want a different behaviour. I want a shift instead of a > rotation. Colors at the end of the visible spectrum must be shifted to > (or from) black. Can't this be done with lut filters? Can you describe math behind this shifting more precisely? If possible in RGB. ___ 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] Showinfo bug?
On 3/4/20, Mark Filipak wrote: > On 03/04/2020 05:34 AM, Paul B Mahol wrote: >> On 3/4/20, Mark Filipak wrote: >>> On 03/04/2020 04:57 AM, Paul B Mahol wrote: On 3/4/20, Mark Filipak wrote: > Is this a showinfo bug, or am I misinterpreting the results? > > For VOBs that are known to be 23.976 FPS, soft-telecined, this command: > 'ffprobe -f lavfi movie=VTS_01_1.VOB,showinfo' > reports that they're 59.94 FPS. > > The first & last lines of output show this: > "[Parsed_showinfo_1 @ 01d381f6dc80] config in time_base: 1/9, > frame_rate: 6/1001" > "Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 720x480 > [SAR 1:1 DAR 3:2], 59.94 tbr, 90k tbn, 90k tbc" > > This seems to be a rather big error, if indeed it is an error. At > question is the reliability of ff*. > I trust more ff* than you. >>> >>> Paul, I trust that your answer indicates that I'm simply misinterpreting >>> the results. >>> >>> So, to what does "frame_rate: 6/1001" refer? >> >> Can not guess without looking and exact same file. > > The 'file' is every 23.976 FPS, soft-telecined video I've checked. Mind > you, other ff* functions report them as 29.970 FPS, for example: > > "Stream #0:1[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, smpte170m, > progressive), 720x480 [SAR 32:27 DAR 16:9], Closed Captions, 29.97 fps, > 59.94 tbr, 90k tbn, 59.94 tbc" > > whereas MPV reports "FPS: 29.970 (specified) 23.976 (estimated)". > > I have been interpreting that as meaning that ff* is reporting metadata > whereas MPV is reporting the actual MPEG2 stream. > > 'ffprobe -f lavfi movie=VTS_01_1.VOB,showinfo' is the only ff* function > that reports 6/1001. > > 23.976 FPS? 29.97 FPS? 59.94 FPS? What am I to believe? You should believe ffprobe output. Note that video may be VFR, and than all of this is meaningless. > ___ > 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 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] Channel mapping misery
Am Mi., 4. März 2020 um 12:23 Uhr schrieb Bouke / VideoToolShed : > > > On 04 Mar 2020, at 12:06, Carl Eugen Hoyos wrote: > > > > Am Mi., 4. März 2020 um 12:02 Uhr schrieb Bouke / VideoToolShed > > : > > > >> When I add one channel more to the previous command: (the wave file has 10 > >> channels) > >> > >> -threads 0 -i /Volumes/Data/test/C0092.MP4 -ss 1601.809541692 -i > >> /Volumes/Data/test/068.WAV -map 0:0 -filter_complex > >> [0:1][1:0][1:0][1:0][1:0][1:0][1:0]amerge=inputs=7,pan=7c|c0=c0|c1=c2|c2=c3|c3=c4|c4=c5|c5=c6|c6=c7[a] > >> -map [a] -c:a pcm_s24le -timecode 01:42:38:10 -metadata:s:v:0 > >> reel_name=C0092 -c:v copy /Volumes/Data/test/C0092.mov -y > >> > >> This does show the pure channel mapping, but fails with: > > > > Is it possible that you provided the complete, uncut console output > > for the working command line > > but not for the one that fails for you? > > I did, it is at the bottom. What is wrong with the output file? Carl Eugen ___ 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] What does ffmpeg consider metadata? -- revision
Am Mi., 4. März 2020 um 12:06 Uhr schrieb James Darnley : > All of those look like bitstream features. None of them you could > change without re-encoding or a specialized tool that can parse and > alter the bitstream. I believe this is not true anymore with the new bitstream filters (that I haven't used so far). Carl Eugen ___ 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] red-shift and blue-shift
On 03/04/2020 05:52 AM, Michael Koch wrote: Hi, is there any known workaround for making a red-shift or a blue-shift? I mean shifting the visible spectrum towards red or blue. In the middle of the spectrum this can be realized by the "hue" filter, but at the end of the spectrum I want a different behaviour. I want a shift instead of a rotation. Colors at the end of the visible spectrum must be shifted to (or from) black. Michael Hey, Michael, (seriously this time), can't you diddle luminance at the same time as hue? ___ 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] Channel mapping misery
> On 04 Mar 2020, at 12:06, Carl Eugen Hoyos wrote: > > Am Mi., 4. März 2020 um 12:02 Uhr schrieb Bouke / VideoToolShed > : > >> When I add one channel more to the previous command: (the wave file has 10 >> channels) >> >> -threads 0 -i /Volumes/Data/test/C0092.MP4 -ss 1601.809541692 -i >> /Volumes/Data/test/068.WAV -map 0:0 -filter_complex >> [0:1][1:0][1:0][1:0][1:0][1:0][1:0]amerge=inputs=7,pan=7c|c0=c0|c1=c2|c2=c3|c3=c4|c4=c5|c5=c6|c6=c7[a] >> -map [a] -c:a pcm_s24le -timecode 01:42:38:10 -metadata:s:v:0 >> reel_name=C0092 -c:v copy /Volumes/Data/test/C0092.mov -y >> >> This does show the pure channel mapping, but fails with: > > Is it possible that you provided the complete, uncut console output > for the working command line > but not for the one that fails for you? Ok, again from the console: (This obviously works) bouke@Boukes-iMac ~ % /Applications/ffmpeg -threads 0 -i /Volumes/Data/test/C0092.MP4 -ss 1601.809541692 -i /Volumes/Data/test/068.WAV -map 0:0 -filter_complex "[0:1][1:0][1:0][1:0][1:0][1:0]amerge=inputs=6,pan=6c|c0=c0|c1=c2|c2=c3|c3=c4|c4=c5|c5=c6[a]" -map "[a]" -c:a pcm_s24le -timecode 01:42:38:10 -metadata:s:v:0 reel_name=C0092 -c:v copy /Volumes/Data/test/C0092.mov -y ffmpeg version git-2020-02-03-1c15111 Copyright (c) 2000-2020 the FFmpeg developers built with Apple clang version 11.0.0 (clang-1100.0.33.8) configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-appkit --enable-avfoundation --enable-coreimage --enable-audiotoolbox libavutil 56. 38.100 / 56. 38.100 libavcodec 58. 67.100 / 58. 67.100 libavformat58. 37.100 / 58. 37.100 libavdevice58. 9.103 / 58. 9.103 libavfilter 7. 73.100 / 7. 73.100 libswscale 5. 6.100 / 5. 6.100 libswresample 3. 6.100 / 3. 6.100 libpostproc55. 6.100 / 55. 6.100 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fddf6004e00] st: 0 edit list: 1 Missing key frame while searching for timestamp: 1000 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fddf6004e00] st: 0 edit list 1 Cannot find an index entry before timestamp: 1000. Guessed Channel Layout for Input Stream #0.1 : stereo Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/Volumes/Data/test/C0092.MP4': Metadata: major_brand : XAVC minor_version : 16785407 compatible_brands: XAVCmp42iso2 creation_time : 2020-01-30T13:31:25.00Z Duration: 00:00:02.40, start: 0.00, bitrate: 97881 kb/s Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 3840x2160 [SAR 1:1 DAR 16:9], 82959 kb/s, 25 fps, 25 tbr, 25k tbn, 50 tbc (default) Metadata: creation_time : 2020-01-30T13:31:25.00Z handler_name: Video Media Handler encoder : AVC Coding Stream #0:1(und): Audio: pcm_s16be (twos / 0x736F7774), 48000 Hz, stereo, s16, 1536 kb/s (default) Metadata: creation_time : 2020-01-30T13:31:25.00Z handler_name: Sound Media Handler Stream #0:2(und): Data: none (rtmd / 0x646D7472), 204 kb/s (default) Metadata: creation_time : 2020-01-30T13:31:25.00Z handler_name: Timed Metadata Media Handler timecode: 01:42:38:10 Input #1, wav, from '/Volumes/Data/test/068.WAV': Metadata: comment : sSPEED=025.000-ND : sTAKE=068 : sUBITS=$ : sSWVER=5.01.8149 : sSCENE=MixPre : sFILENAME=MixPre-068.WAV : sTAPE=200130 : sCIRCLED=FALSE : sTRK1=MixL : sTRK2=MixR : sTRK3=Track 1 : sTRK4=Track 2 : sTRK5=Track 3 : sTRK6=Track 4 : sTRK7=Track 5 : sTRK8=Track 6 : sTRK9 encoded_by : SoundDev: MixPre-10 II TJ0019225 originator_reference: USSDVTJ001922501520013072A000201 date: 2020-01-30 creation_time : 07:02:20 time_reference : 2468718515 coding_history : A=PCM,F=48000,W=24,M=multi,R=48000,T=10 Ch;Ambisonics=off : Duration: 00:49:41.90, bitrate: 11520 kb/s Stream #1:0: Audio: pcm_s24le ([1][0][0][0] / 0x0001), 48000 Hz, 10 channels, s32 (24 bit), 11520 kb/s Stream mapping: Str
Re: [FFmpeg-user] Showinfo bug?
On 03/04/2020 06:42 AM, Paul B Mahol wrote: On 3/4/20, Mark Filipak wrote: On 03/04/2020 05:34 AM, Paul B Mahol wrote: On 3/4/20, Mark Filipak wrote: On 03/04/2020 04:57 AM, Paul B Mahol wrote: On 3/4/20, Mark Filipak wrote: Is this a showinfo bug, or am I misinterpreting the results? For VOBs that are known to be 23.976 FPS, soft-telecined, this command: 'ffprobe -f lavfi movie=VTS_01_1.VOB,showinfo' reports that they're 59.94 FPS. The first & last lines of output show this: "[Parsed_showinfo_1 @ 01d381f6dc80] config in time_base: 1/9, frame_rate: 6/1001" "Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 720x480 [SAR 1:1 DAR 3:2], 59.94 tbr, 90k tbn, 90k tbc" This seems to be a rather big error, if indeed it is an error. At question is the reliability of ff*. I trust more ff* than you. Paul, I trust that your answer indicates that I'm simply misinterpreting the results. So, to what does "frame_rate: 6/1001" refer? Can not guess without looking and exact same file. The 'file' is every 23.976 FPS, soft-telecined video I've checked. Mind you, other ff* functions report them as 29.970 FPS, for example: "Stream #0:1[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, smpte170m, progressive), 720x480 [SAR 32:27 DAR 16:9], Closed Captions, 29.97 fps, 59.94 tbr, 90k tbn, 59.94 tbc" whereas MPV reports "FPS: 29.970 (specified) 23.976 (estimated)". I have been interpreting that as meaning that ff* is reporting metadata whereas MPV is reporting the actual MPEG2 stream. 'ffprobe -f lavfi movie=VTS_01_1.VOB,showinfo' is the only ff* function that reports 6/1001. 23.976 FPS? 29.97 FPS? 59.94 FPS? What am I to believe? You should believe ffprobe output. Note that video may be VFR, and than all of this is meaningless. It's not VFR. ffprobe reports 29.97 FPS, but I'm pretty sure the stream is actually 23.976 FPS (soft-telecined) as reported by MPV. ___ 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] red-shift and blue-shift
Am 04.03.2020 um 12:37 schrieb Paul B Mahol: On 3/4/20, Michael Koch wrote: Hi, is there any known workaround for making a red-shift or a blue-shift? I mean shifting the visible spectrum towards red or blue. In the middle of the spectrum this can be realized by the "hue" filter, but at the end of the spectrum I want a different behaviour. I want a shift instead of a rotation. Colors at the end of the visible spectrum must be shifted to (or from) black. Can't this be done with lut filters? sure, that's possible but I haven't yet found a suitable software for creating this kind of LUT. Can you describe math behind this shifting more precisely? If possible in RGB. I'll try to figure out the math. Michael ___ 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] Showinfo bug?
On 3/4/20, Mark Filipak wrote: > On 03/04/2020 06:42 AM, Paul B Mahol wrote: >> On 3/4/20, Mark Filipak wrote: >>> On 03/04/2020 05:34 AM, Paul B Mahol wrote: On 3/4/20, Mark Filipak wrote: > On 03/04/2020 04:57 AM, Paul B Mahol wrote: >> On 3/4/20, Mark Filipak wrote: >>> Is this a showinfo bug, or am I misinterpreting the results? >>> >>> For VOBs that are known to be 23.976 FPS, soft-telecined, this >>> command: >>> 'ffprobe -f lavfi movie=VTS_01_1.VOB,showinfo' >>> reports that they're 59.94 FPS. >>> >>> The first & last lines of output show this: >>> "[Parsed_showinfo_1 @ 01d381f6dc80] config in time_base: 1/9, >>> frame_rate: 6/1001" >>> "Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, >>> 720x480 >>> [SAR 1:1 DAR 3:2], 59.94 tbr, 90k tbn, 90k tbc" >>> >>> This seems to be a rather big error, if indeed it is an error. At >>> question is the reliability of ff*. >>> >> >> I trust more ff* than you. > > Paul, I trust that your answer indicates that I'm simply > misinterpreting > the results. > > So, to what does "frame_rate: 6/1001" refer? Can not guess without looking and exact same file. >>> >>> The 'file' is every 23.976 FPS, soft-telecined video I've checked. Mind >>> you, other ff* functions report them as 29.970 FPS, for example: >>> >>> "Stream #0:1[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, smpte170m, >>> progressive), 720x480 [SAR 32:27 DAR 16:9], Closed Captions, 29.97 fps, >>> 59.94 tbr, 90k tbn, 59.94 tbc" >>> >>> whereas MPV reports "FPS: 29.970 (specified) 23.976 (estimated)". >>> >>> I have been interpreting that as meaning that ff* is reporting metadata >>> whereas MPV is reporting the actual MPEG2 stream. >>> >>> 'ffprobe -f lavfi movie=VTS_01_1.VOB,showinfo' is the only ff* function >>> that reports 6/1001. >>> >>> 23.976 FPS? 29.97 FPS? 59.94 FPS? What am I to believe? >> >> You should believe ffprobe output. Note that video may be VFR, and >> than all of this is meaningless. > > It's not VFR. ffprobe reports 29.97 FPS, but I'm pretty sure the stream > is actually 23.976 FPS (soft-telecined) as reported by MPV. It is 29.97 after soft telecined being applied. > > ___ > 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 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] Showinfo bug?
On 03/04/2020 06:51 AM, Paul B Mahol wrote: On 3/4/20, Mark Filipak wrote: On 03/04/2020 06:42 AM, Paul B Mahol wrote: On 3/4/20, Mark Filipak wrote: On 03/04/2020 05:34 AM, Paul B Mahol wrote: On 3/4/20, Mark Filipak wrote: On 03/04/2020 04:57 AM, Paul B Mahol wrote: On 3/4/20, Mark Filipak wrote: Is this a showinfo bug, or am I misinterpreting the results? For VOBs that are known to be 23.976 FPS, soft-telecined, this command: 'ffprobe -f lavfi movie=VTS_01_1.VOB,showinfo' reports that they're 59.94 FPS. The first & last lines of output show this: "[Parsed_showinfo_1 @ 01d381f6dc80] config in time_base: 1/9, frame_rate: 6/1001" "Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 720x480 [SAR 1:1 DAR 3:2], 59.94 tbr, 90k tbn, 90k tbc" This seems to be a rather big error, if indeed it is an error. At question is the reliability of ff*. I trust more ff* than you. Paul, I trust that your answer indicates that I'm simply misinterpreting the results. So, to what does "frame_rate: 6/1001" refer? Can not guess without looking and exact same file. The 'file' is every 23.976 FPS, soft-telecined video I've checked. Mind you, other ff* functions report them as 29.970 FPS, for example: "Stream #0:1[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, smpte170m, progressive), 720x480 [SAR 32:27 DAR 16:9], Closed Captions, 29.97 fps, 59.94 tbr, 90k tbn, 59.94 tbc" whereas MPV reports "FPS: 29.970 (specified) 23.976 (estimated)". I have been interpreting that as meaning that ff* is reporting metadata whereas MPV is reporting the actual MPEG2 stream. 'ffprobe -f lavfi movie=VTS_01_1.VOB,showinfo' is the only ff* function that reports 6/1001. 23.976 FPS? 29.97 FPS? 59.94 FPS? What am I to believe? You should believe ffprobe output. Note that video may be VFR, and than all of this is meaningless. It's not VFR. ffprobe reports 29.97 FPS, but I'm pretty sure the stream is actually 23.976 FPS (soft-telecined) as reported by MPV. It is 29.97 after soft telecined being applied. Yes, I know. To confirm (to be sure) I have 2 choices: 1, Believe that MPV is reporting what I *think* it's reporting, or 2, Read the metadata (that should show soft telecining) but I'm not sure that I can rely on ff* to report metadata because ff* seems to have it's own definition of what metadata is (and it's different from what is defined as metadata in H.262). ___ 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] red-shift and blue-shift
Am 04.03.2020 um 12:44 schrieb Mark Filipak: On 03/04/2020 05:52 AM, Michael Koch wrote: Hi, is there any known workaround for making a red-shift or a blue-shift? I mean shifting the visible spectrum towards red or blue. In the middle of the spectrum this can be realized by the "hue" filter, but at the end of the spectrum I want a different behaviour. I want a shift instead of a rotation. Colors at the end of the visible spectrum must be shifted to (or from) black. Michael Hey, Michael, (seriously this time), can't you diddle luminance at the same time as hue? As far as I know, there is no filter for decreasing the luminance as a function of hue. Although a complicated workaround with "geq" filter might be possible. I'll try to figure it out. Michael ___ 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] How to compress .MOV file compatible to Canon camera
Am 04.03.20 um 04:51 schrieb Tom Sparks: On 04/03/2020, Ulf Zibis wrote: Anyway, isn't x264 part of ffmpeg? To me it looks it is: https://www.ffmpeg.org/ffmpeg-codecs.html#libx264_002c-libx264rgb no, x264 is done by the VLC community Following your argumentation, ffmpeg should not document any of x264 options and instead refer to videolan docs. But ffmpeg does document it. So on which rules most of x264 options and its values are documented and some are not even listed (e.g. most of obviously implemented x264 profiles and levels)? see https://www.videolan.org/developers/x264.html Unfortunately the documentation there is even much less verbose than on ffmpeg. (Or does anyone know a link to a complete documentation?) -Ulf ___ 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] red-shift and blue-shift
On 03/04/2020 07:05 AM, Michael Koch wrote: Am 04.03.2020 um 12:44 schrieb Mark Filipak: On 03/04/2020 05:52 AM, Michael Koch wrote: Hi, is there any known workaround for making a red-shift or a blue-shift? I mean shifting the visible spectrum towards red or blue. In the middle of the spectrum this can be realized by the "hue" filter, but at the end of the spectrum I want a different behaviour. I want a shift instead of a rotation. Colors at the end of the visible spectrum must be shifted to (or from) black. Michael Hey, Michael, (seriously this time), can't you diddle luminance at the same time as hue? As far as I know, there is no filter for decreasing the luminance as a function of hue. Although a complicated workaround with "geq" filter might be possible. I'll try to figure it out. Michael Seems to me you need a passband filter with Gaussian roll-offs. ___ 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] How to compress .MOV file compatible to Canon camera
Am 01.03.20 um 09:56 schrieb Paul B Mahol: On 3/1/20, Moritz Barsnick wrote: Well, the wiki claims: If you want your videos to have highest compatibility with ancient devices (e.g., old Android phones): -profile:v baseline -level 3.0 and regarding iOS compatability of these options: "All devices" Is the wiki page really that far off? (Yes, I can actually confirm that I have issues playing this file, but I haven't figured out why.) Wrong pixel format and encoder variant? Pixel format is the same (yuv 420) but, encoder variant seems different: Canon original: Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuvj420p(pc, smpte170m/bt709/bt709), 1280x720, 22763 kb/s, 29.97 fps, 29.97 tbr, 30k tbn, 60k tbc (default) FFMPEG: Video: h264 (libx264) (avc1 / 0x31637661), vj420p(pc), 1280x720, q=-1--1, 29.97 fps, 30k tbn, 29.97 tbc (default) So the question is, if and how I can force ffmpeg to use a compatible encoding variant. -Ulf ___ 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] red-shift and blue-shift
I suspect you could do this with a lookup table; consider the lut3d filter. How you'd build the lookup table would be another matter. P On Wednesday, 4 March 2020, 12:05:16 GMT, Michael Koch wrote: Am 04.03.2020 um 12:44 schrieb Mark Filipak: > On 03/04/2020 05:52 AM, Michael Koch wrote: >> Hi, >> >> is there any known workaround for making a red-shift or a blue-shift? >> I mean shifting the visible spectrum towards red or blue. In the >> middle of the spectrum this can be realized by the "hue" filter, but >> at the end of the spectrum I want a different behaviour. I want a >> shift instead of a rotation. Colors at the end of the visible >> spectrum must be shifted to (or from) black. >> >> Michael > > Hey, Michael, (seriously this time), can't you diddle luminance at the > same time as hue? As far as I know, there is no filter for decreasing the luminance as a function of hue. Although a complicated workaround with "geq" filter might be possible. I'll try to figure it out. Michael ___ 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 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] FPGAs
I thought further and decided to redo my FPGA presentation with better analogies. I hope you enjoy it. Starting with the basics: Logic gates come in 2 flavors: AND and OR; and it's from them, alone, that all other digital elements are made. FSMs (finite state machines) are complex combinations of logic gates that execute (i.e., change state) sequentially. A particular FSM's sequence is determined by 2 things: 1, external input conditions, and 2, the FSM's current state. CPU core units (code cracker, execution unit, cache controller, etc.) are special-purpose FSMs. You can visualize an FSM as a player piano and a CPU core as a group of player pianos. Microcodes: Microcodes are 'piano roll' sequences that 'play' CPU core unit 'pianos'. Machine codes: Machine codes cause the microcode 'piano rolls' to be switched en masse: As each particular machine code arrives at the CPU, all the microcode 'piano rolls' are switched to the rolls that, given the current state of the CPU's execution unit, are appropriate for 'playing' that particular machine code's 'tune'. It's that switching that makes CPU core units different from ordinary FSMs. The only CPU core unit 'piano' that doesn't change its 'tune' is the code cracker. The code cracker's microcode 'piano roll' never changes because the code cracker is the 'piano' that switches the 'piano rolls' of the other 'pianos', and how it accomplishes that never changes. What does change is the identification of the new, replacement 'piano roll' that's swapped in. That identification is embedded in the machine code. Thusly, CPUs differ from fixed sequential machines: CPUs self-modify. Note that the self-modifying is not permanent but persists solely for the current machine code cycle, then changes for the next machine code. The code cracker can do this because of fields embedded in machine codes and the execution unit's current state. Machine codes: All programs must be converted to machine codes prior to arriving at the CPU. They can be converted in advance (e.g., "compiled", such as written in 'C') or converted on the fly (e.g., "interpreted", such as written in Python). Thusly, programs are layers removed from machine code and machine code is layers removed from microcode. Returning to the basics, FPGAs are collections of uncommitted logic gates that can be configured to make anything that can be made with logic gates. In addition to a sea of gates, some FPGAs contain hand crafted (compact) peripherals (e.g., SPI, HDMI) and even CPUs (e.g., ARM). SoS (software-on-silicon) vendors, such as NGCodec, design the particular configurations that turn FPGAs into dedicated chips that perform specific tasks such as processing video streams. The designs can be in the form of, 1, 'hard-wired' FSMs (difficult design, longer development, later to the market, but wicked fast), or 2, additions to an on-chip CPU (easier design, shorter development, sooner to the market, but slower). Of course, processing video streams can be done in a computer's CPU. That's what ffmpeg does. ___ 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] FPGAs
On 3/4/20, Mark Filipak wrote: > I thought further and decided to redo my FPGA presentation with better > analogies. I hope you enjoy it. > > Starting with the basics: Logic gates come in 2 flavors: AND and OR; and > it's from them, alone, that all other digital elements are made. > > FSMs (finite state machines) are complex combinations of logic gates > that execute (i.e., change state) sequentially. A particular FSM's > sequence is determined by 2 things: 1, external input conditions, and 2, > the FSM's current state. > > CPU core units (code cracker, execution unit, cache controller, etc.) > are special-purpose FSMs. You can visualize an FSM as a player piano and > a CPU core as a group of player pianos. > > Microcodes: Microcodes are 'piano roll' sequences that 'play' CPU core > unit 'pianos'. > > Machine codes: Machine codes cause the microcode 'piano rolls' to be > switched en masse: As each particular machine code arrives at the CPU, > all the microcode 'piano rolls' are switched to the rolls that, given > the current state of the CPU's execution unit, are appropriate for > 'playing' that particular machine code's 'tune'. It's that switching > that makes CPU core units different from ordinary FSMs. > > The only CPU core unit 'piano' that doesn't change its 'tune' is the > code cracker. The code cracker's microcode 'piano roll' never changes > because the code cracker is the 'piano' that switches the 'piano rolls' > of the other 'pianos', and how it accomplishes that never changes. What > does change is the identification of the new, replacement 'piano roll' > that's swapped in. That identification is embedded in the machine code. > > Thusly, CPUs differ from fixed sequential machines: CPUs self-modify. > Note that the self-modifying is not permanent but persists solely for > the current machine code cycle, then changes for the next machine code. > The code cracker can do this because of fields embedded in machine codes > and the execution unit's current state. > > Machine codes: All programs must be converted to machine codes prior to > arriving at the CPU. They can be converted in advance (e.g., "compiled", > such as written in 'C') or converted on the fly (e.g., "interpreted", > such as written in Python). > > Thusly, programs are layers removed from machine code and machine code > is layers removed from microcode. > > Returning to the basics, FPGAs are collections of uncommitted logic > gates that can be configured to make anything that can be made with > logic gates. In addition to a sea of gates, some FPGAs contain hand > crafted (compact) peripherals (e.g., SPI, HDMI) and even CPUs (e.g., ARM). > > SoS (software-on-silicon) vendors, such as NGCodec, design the > particular configurations that turn FPGAs into dedicated chips that > perform specific tasks such as processing video streams. The designs can > be in the form of, 1, 'hard-wired' FSMs (difficult design, longer > development, later to the market, but wicked fast), or 2, additions to > an on-chip CPU (easier design, shorter development, sooner to the > market, but slower). > > Of course, processing video streams can be done in a computer's CPU. > That's what ffmpeg does. Not 100% correct. ___ 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] FPGAs
On 3/4/2020 7:39 AM, Paul B Mahol wrote: Not 100% correct. Which part? (And does it need to be, anyway? Analogies often aren't but still get the points across.) z! ___ 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] FPGAs
On 3/4/20, Carl Zwanzig wrote: > On 3/4/2020 7:39 AM, Paul B Mahol wrote: >> Not 100% correct. > > Which part? (And does it need to be, anyway? Analogies often aren't but > still get the points across.) CPU and GPU... > > z! > ___ > 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 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] How to compress .MOV file compatible to Canon camera
Am Mi., 4. März 2020 um 13:12 Uhr schrieb Ulf Zibis : > > > Am 04.03.20 um 04:51 schrieb Tom Sparks: > > On 04/03/2020, Ulf Zibis wrote: > >> Anyway, isn't x264 part of ffmpeg? > >> > >> To me it looks it is: > >> https://www.ffmpeg.org/ffmpeg-codecs.html#libx264_002c-libx264rgb > > no, x264 is done by the VLC community > Following your argumentation, ffmpeg should not document any of x264 > options Correct. > and instead refer to videolan docs. Actually the x264 docs - which is exactly what above link does. Note that this is not necessarily true for level and profile, these are documented in (many) general places like Wikipedia's x264 article. > But ffmpeg does document it. It shouldn't in general and I guess it doesn't (There are of course options of FFmpeg's libx264 wrapper that are unrelated to the x264 documentation.) > So on which rules most of x264 options and its values are documented and > some are not even listed (e.g. most of obviously implemented x264 > profiles and levels)? > > > see https://www.videolan.org/developers/x264.html > Unfortunately the documentation there is even much less verbose than on > ffmpeg. > (Or does anyone know a link to a complete documentation?) You provided a link above. Carl Eugen ___ 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] FPGAs
On 03/04/2020 11:14 AM, Paul B Mahol wrote: On 3/4/20, Carl Zwanzig wrote: On 3/4/2020 7:39 AM, Paul B Mahol wrote: Not 100% correct. Which part? (And does it need to be, anyway? Analogies often aren't but still get the points across.) CPU and GPU... Hi, and thanks for the criticism, I don't mention GPUs because I don't know whether CUDA cores, for example, are actually processors. These days marketing trumps engineering and there's a lot of notions that can't be taken seriously. Just because a thing has 'core' in its name, is it really a core? Do you know, Paul? ___ 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] FPGAs
On 3/4/20, Mark Filipak wrote: > On 03/04/2020 11:14 AM, Paul B Mahol wrote: >> On 3/4/20, Carl Zwanzig wrote: >>> On 3/4/2020 7:39 AM, Paul B Mahol wrote: Not 100% correct. >>> >>> Which part? (And does it need to be, anyway? Analogies often aren't but >>> still get the points across.) >> >> CPU and GPU... > > Hi, and thanks for the criticism, > > I don't mention GPUs because I don't know whether CUDA cores, for > example, are actually processors. These days marketing trumps > engineering and there's a lot of notions that can't be taken seriously. > Just because a thing has 'core' in its name, is it really a core? You lost me right there after mentioning CUDA cores. > > Do you know, Paul? > ___ > 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 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] FPGAs
On 03/04/2020 04:51 PM, Paul B Mahol wrote: On 3/4/20, Mark Filipak wrote: On 03/04/2020 11:14 AM, Paul B Mahol wrote: On 3/4/20, Carl Zwanzig wrote: On 3/4/2020 7:39 AM, Paul B Mahol wrote: Not 100% correct. Which part? (And does it need to be, anyway? Analogies often aren't but still get the points across.) CPU and GPU... Hi, and thanks for the criticism, I don't mention GPUs because I don't know whether CUDA cores, for example, are actually processors. These days marketing trumps engineering and there's a lot of notions that can't be taken seriously. Just because a thing has 'core' in its name, is it really a core? You lost me right there after mentioning CUDA cores. Oh, sorry Paul. When I question whether CUDA cores are processors, I'm questioning what CUDA is at a rather deep level. If a CUDA core is not actually a core, it can still be a processor, right? But if I go further and say that I don't know whether CUDA is even a processor, I'm making a very basic statement that I don't know anything about CUDA, eh? Regarding whether "CUDA core" is simply a marketing label, I'm just being snarky. Do you understand, or is your difficulty that you don't know/haven't heard of CUDA cores? Regards. ___ 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] FPGAs
On 3/4/20, Mark Filipak wrote: > On 03/04/2020 04:51 PM, Paul B Mahol wrote: >> On 3/4/20, Mark Filipak wrote: >>> On 03/04/2020 11:14 AM, Paul B Mahol wrote: On 3/4/20, Carl Zwanzig wrote: > On 3/4/2020 7:39 AM, Paul B Mahol wrote: >> Not 100% correct. > > Which part? (And does it need to be, anyway? Analogies often aren't but > still get the points across.) CPU and GPU... >>> >>> Hi, and thanks for the criticism, >>> >>> I don't mention GPUs because I don't know whether CUDA cores, for >>> example, are actually processors. These days marketing trumps >>> engineering and there's a lot of notions that can't be taken seriously. >>> Just because a thing has 'core' in its name, is it really a core? >> >> You lost me right there after mentioning CUDA cores. > > Oh, sorry Paul. > > When I question whether CUDA cores are processors, I'm questioning what > CUDA is at a rather deep level. If a CUDA core is not actually a core, > it can still be a processor, right? But if I go further and say that I > don't know whether CUDA is even a processor, I'm making a very basic > statement that I don't know anything about CUDA, eh? > > Regarding whether "CUDA core" is simply a marketing label, I'm just > being snarky. > > Do you understand, or is your difficulty that you don't know/haven't > heard of CUDA cores? > There are GPUs that are not CUDA last time I checked facts. ___ 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] FPGAs
On 03/04/2020 05:02 PM, Paul B Mahol wrote: On 3/4/20, Mark Filipak wrote: On 03/04/2020 04:51 PM, Paul B Mahol wrote: On 3/4/20, Mark Filipak wrote: On 03/04/2020 11:14 AM, Paul B Mahol wrote: On 3/4/20, Carl Zwanzig wrote: On 3/4/2020 7:39 AM, Paul B Mahol wrote: Not 100% correct. Which part? (And does it need to be, anyway? Analogies often aren't but still get the points across.) CPU and GPU... Hi, and thanks for the criticism, I don't mention GPUs because I don't know whether CUDA cores, for example, are actually processors. These days marketing trumps engineering and there's a lot of notions that can't be taken seriously. Just because a thing has 'core' in its name, is it really a core? You lost me right there after mentioning CUDA cores. Oh, sorry Paul. When I question whether CUDA cores are processors, I'm questioning what CUDA is at a rather deep level. If a CUDA core is not actually a core, it can still be a processor, right? But if I go further and say that I don't know whether CUDA is even a processor, I'm making a very basic statement that I don't know anything about CUDA, eh? Regarding whether "CUDA core" is simply a marketing label, I'm just being snarky. Do you understand, or is your difficulty that you don't know/haven't heard of CUDA cores? There are GPUs that are not CUDA last time I checked facts. Okay, that's true, and so ... (?) ___ 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] FPGAs
On 3/4/20, Mark Filipak wrote: > > > On 03/04/2020 05:02 PM, Paul B Mahol wrote: >> On 3/4/20, Mark Filipak wrote: >>> On 03/04/2020 04:51 PM, Paul B Mahol wrote: On 3/4/20, Mark Filipak wrote: > On 03/04/2020 11:14 AM, Paul B Mahol wrote: >> On 3/4/20, Carl Zwanzig wrote: >>> On 3/4/2020 7:39 AM, Paul B Mahol wrote: Not 100% correct. >>> >>> Which part? (And does it need to be, anyway? Analogies often aren't >>> but >>> still get the points across.) >> >> CPU and GPU... > > Hi, and thanks for the criticism, > > I don't mention GPUs because I don't know whether CUDA cores, for > example, are actually processors. These days marketing trumps > engineering and there's a lot of notions that can't be taken seriously. > Just because a thing has 'core' in its name, is it really a core? You lost me right there after mentioning CUDA cores. >>> >>> Oh, sorry Paul. >>> >>> When I question whether CUDA cores are processors, I'm questioning what >>> CUDA is at a rather deep level. If a CUDA core is not actually a core, >>> it can still be a processor, right? But if I go further and say that I >>> don't know whether CUDA is even a processor, I'm making a very basic >>> statement that I don't know anything about CUDA, eh? >>> >>> Regarding whether "CUDA core" is simply a marketing label, I'm just >>> being snarky. >>> >>> Do you understand, or is your difficulty that you don't know/haven't >>> heard of CUDA cores? >>> >> >> There are GPUs that are not CUDA last time I checked facts. > > Okay, that's true, and so ... (?) Still supported via other means like OpenCL. > ___ > 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 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] FPGAs
On 03/04/2020 05:12 PM, Paul B Mahol wrote: On 3/4/20, Mark Filipak wrote: On 03/04/2020 05:02 PM, Paul B Mahol wrote: On 3/4/20, Mark Filipak wrote: On 03/04/2020 04:51 PM, Paul B Mahol wrote: On 3/4/20, Mark Filipak wrote: On 03/04/2020 11:14 AM, Paul B Mahol wrote: On 3/4/20, Carl Zwanzig wrote: On 3/4/2020 7:39 AM, Paul B Mahol wrote: Not 100% correct. Which part? (And does it need to be, anyway? Analogies often aren't but still get the points across.) CPU and GPU... Hi, and thanks for the criticism, I don't mention GPUs because I don't know whether CUDA cores, for example, are actually processors. These days marketing trumps engineering and there's a lot of notions that can't be taken seriously. Just because a thing has 'core' in its name, is it really a core? You lost me right there after mentioning CUDA cores. Oh, sorry Paul. When I question whether CUDA cores are processors, I'm questioning what CUDA is at a rather deep level. If a CUDA core is not actually a core, it can still be a processor, right? But if I go further and say that I don't know whether CUDA is even a processor, I'm making a very basic statement that I don't know anything about CUDA, eh? Regarding whether "CUDA core" is simply a marketing label, I'm just being snarky. Do you understand, or is your difficulty that you don't know/haven't heard of CUDA cores? There are GPUs that are not CUDA last time I checked facts. Okay, that's true, and so ... (?) Still supported via other means like OpenCL. I'll take your word for it, and so ... (?) ___ 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] filter ffmetadata does not output all metadata and is missing in documentation
Am 04.03.20 um 12:10 schrieb Moritz Barsnick: Hallo Ulf, On Wed, Mar 04, 2020 at 01:51:37 +0100, Ulf Zibis wrote: Even with normal transcoding "creation_time" is listed in the OUTPUT metadata, but in the resulting output file it is missing. Interesting and slightly annoying fact: All metadata that is passed to encoder and muxer is listed. Yet it is up to encoder and muxer, which of these are actually used. (E.g. as far as I understand, MOV/MP4 has a limited set of what can be used.) Unfortunately, the "officials" have a different oppinion: https://trac.ffmpeg.org/ticket/8553#comment:1 ffmpeg: dont copy creation_time as the destination file is not created at that time Linux command "mediainfo" distinguishes between "Encoded date" and "Tagged date", don't know which is meant to be "creation_time". In jpeg EXIF we find "DateTimeOriginal" and "DateTimeDigitized". Perhaps this could be documented somewhere, but I don't personally care, in this case. I have added a comment here: https://trac.ffmpeg.org/ticket/1439#comment:2 Trac ticket cause: http://trac.ffmpeg.org/ticket/1439 That may make sense for normal transcoding, but not for: ffmpeg -i INPUT.mp4 -f ffmetadata INPUT.meta In all honesty - also for some other "info" filters and muxers - information *dumping* should happen at input level, not at output. That's why ffprobe was mentioned. On the other hand, in terms of passing on to output, that's of course a different matter. At least this muxer helped you to notice that this specific metadata does *not* arrive at the output. But how to transfer it to the output video? Since it's explicitly filtered: Have you tried adding it explicitly, from the command line? $ ffmpeg [...] -metadata creation_time=2020-03-04T10:38:45.00Z [...] No, but I guess it will work. Anyway I was looking for a "automatic" solution. Actually, a quick Google search(!) shows me that there's an option for passing it from the input: $ ffmpeg [...] -map_metadata 0:g [...] and it seems to work for me. Which is the same than "-map_metadata 0". But here I was talking about the example from https://ffmpeg.org/ffmpeg-formats.html#Metadata-1 : ffmpeg -i INPUT -f ffmetadata FFMETADATAFILE ffmpeg -i INPUT -i FFMETADATAFILE -map_metadata 1 -codec copy OUTPUT ... which doesn't work for complete metadata. -Ulf ___ 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] filter ffmetadata does not output all metadata and is missing in documentation
Am 04.03.20 um 00:16 schrieb James Darnley: On 2020-03-03 23:07, Ulf Zibis wrote: $ ~/Projects/ffmpeg/ffmpeg-git-20200211-amd64-static/ffmpeg -i 20200205_165401.mp4 -f ffmetadata 20200205_165401.meta Output #0, ffmetadata, to '20200205_165401.meta': Metadata: major_brand : mp42 minor_version : 0 compatible_brands: isommp42 com.android.version: 8.0.0 location: -00.7655-047.1715/ location-eng: -00.7655-047.1715/ encoder : Lavf58.38.100 Stream mapping: Press [q] to stop, [?] for help It is clearly present in the input file's metadata so how is it not copied into the output file? I have opened a ticket. you may comment on it: https://trac.ffmpeg.org/ticket/8553#ticket -Ulf ___ 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] filter ffmetadata does not output all metadata and is missing in documentation
Am 04.03.20 um 11:41 schrieb James Darnley: On 2020-03-04 01:51, Ulf Zibis wrote: But how to transfer it to the output video? Modify ffmpeg to remove the line I showed before, currently in fftools/ffmpeg_opt.c at line 2608. Or get o->metadata_global_manual to be false. You seem to be able to do that with -map_metadata 0 but I thought that was the default anyway. I manually added creation_time to a file, used that as input for an ffmetadata output and sure enough, there it was. To which I said "what the flaming fuck". Another workaround is: ffmpeg -i INPUT.mp4 -map_metadata 0 -f ffmetadata INPUT.meta -Ulf ___ 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".
