Recherche avancée

Sur d’autres sites (6468)

• Pointer peril

  18 octobre 2011, par Mans — Bugs, Optimisation

  Use of pointers in the C programming language is subject to a number of constraints, violation of which results in the dreaded undefined behaviour. If a situation with undefined behaviour occurs, anything is permitted to happen. The program may produce unexpected results, crash, or demons may fly out of the user’s nose.

  Some of these rules concern pointer arithmetic, addition and subtraction in which one or both operands are pointers. The C99 specification spells it out in section 6.5.6 :

  When an expression that has integer type is added to or subtracted from a pointer, the result has the type of the pointer operand. […] If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow ; otherwise, the behavior is undefined. […]

  When two pointers are subtracted, both shall point to elements of the same array object, or one past the last element of the array object ; the result is the difference of the subscripts of the two array elements.

  In simpler, if less accurate, terms, operands and results of pointer arithmetic must be within the same array object. If not, anything can happen.
  
  To see some of this undefined behaviour in action, consider the following example.

  #include <stdio.h>
  int foo(void)
  
  
  
      int a, b ;
  
      int d = &b - &a ; /* undefined */
  
      int *p = &a ;
  
      b = 0 ;
  
      p[d] = 1 ;        /* undefined */
  
      return b ;
  
  
  int main(void)
  
  
  
      printf("%d\n", foo()) ;
  
      return 0 ;
  
  
  

  This program breaks the above rules twice. Firstly, the &a - &b calculation is undefined because the pointers being subtracted do not point to elements of the same array. Most compilers will nonetheless evaluate this to the distance between the two variables on the stack. Secondly, accessing p[d] is undefined because p and p + d do not point to elements of the same array (unless the result of the first undefined expression happened to be zero).

  It might be tempting to assume that on a modern system with a single, flat address space, these operations would result in the intuitively obvious outcomes, ultimately setting b to the value 1 and returning this same value. However, undefined is undefined, and the compiler is free to do whatever it wants :

  $ gcc -O undef.c
  $ ./a.out
  0

  Even on a perfectly normal system, compiled with optimisation enabled the program behaves as though the write to p[d] were ignored. In fact, this is exactly what happened, as this test shows :

  $ gcc -O -fno-tree-pta undef.c
  $ ./a.out
  1

  Disabling the tree-pta optimisation in gcc gives us back the intuitive behaviour. PTA stands for points-to analysis, which means the compiler analyses which objects any pointers can validly access. In the example, the pointer p, having been set to &a cannot be used in a valid access to the variable b, a and b not being part of the same array. Between the assignment b = 0 and the return statement, no valid access to b takes place, whence the return value is derived to be zero. The entire function is, in fact, reduced to the assembly equivalent of a simple return 0 statement, all because we decided to violate a couple of language rules.

  While this example is obviously contrived for clarity, bugs rooted in these rules occur in real programs from time to time. My most recent encounter with one was in PARI/GP, where a somewhat more complicated incarnation of the example above can be found. Unfortunately, the maintainers of this program are not responsive to reports of such bad practices in their code :

  Undefined according to what rule ? The code is only requiring the adress space to be flat which is true on all supported platforms.

  The rule in question is, of course, the one quoted above. Since the standard makes no exception for flat address spaces, no such exception exists. Although the behaviour could be logically defined in this case, it is not, and all programs must still follow the rules. Filing bug reports against the compiler will not make them go away. As of this writing, the issue remains unresolved.

• Does PTS have to start at 0 ?

  5 juillet 2018, par stevendesu

  I’ve seen a number of questions regarding video PTS values not starting at zero, or asking how to make them start at zero. I’m aware that using ffmpeg I can do something like ffmpeg -i <video> -vf="setpts=PTS-STARTPTS" <output></output></video> to fix this kind of thing

  However it’s my understanding that PTS values don’t have to start at zero. For instance, if you join a live stream then odds are it has been going on for an hour and the PTS is already somewhere around 3600000+ but your video player faithfully displays everything just fine. Therefore I would expect there to be no problem if I intentionally created a video with a PTS value starting at, say, the current wall clock time.

  I want to send a live stream using ffmpeg, but embed the current time into the stream. This can be used both for latency calculation while the stream is live, and later to determine when the stream was originally aired. From my understanding of PTS, something as simple as this should probably work :

  ffmpeg -i video.flv -vf="setpts=RTCTIME" rtmp://<output>
  
  </output>

  When I try this, however, ffmpeg outputs the following :

  frame=   93 fps= 20 q=-1.0 Lsize=    9434kB time=535020:39:58.70 bitrate=   0.0kbits/s speed=1.35e+11x

  Note the extremely large value for "time", the bitrate (0.0kbits), and the speed (135000000000x !!!)

  At first I thought the issue might be my timebase, so I tried the following :

  ffmpeg -i video.flv -vf="settb=1/1K,setpts=RTCTIME/1K" rtmp://<output>
  
  </output>

  This puts everything in terms of milliseconds (1 PTS = 1 ms) but I had the same issue (massive time, zero bitrate, and massive speed)

  Am I misunderstanding something about PTS ? Is it not allowed to start at non-zero values ? Or am I just doing something wrong ?

  Update

  After reviewing @Gyan’s answer, I formatted my command like so :

  ffmpeg -re -i video.flv -vf="settb=1/1K, setpts=(RTCTIME-RTCSTART)/1K" -output_ts_offset $(date +%s.%N) rtmp://<output>
  
  </output>

  This way the PTS values would match up to "milliseconds since the stream started" and would be offset by the start time of the stream (theoretically making PTS = timestamp on the server)

  This looked like it was encoding better :

  frame=  590 fps=7.2 q=22.0 size=   25330kB time=00:01:21.71 bitrate=2539.5kbits/s dup=0 drop=1350 speed=   1x 

  Bitrate was now correct, time was accurate, and speed was not outrageous. The frames per second was still a bit off, though (the source video is 24 fps but it’s reporting 7.2 frames per second)

  When I tried watching the stream from the other end, the video was out of sync with the audio and played at about double normal speed for a while, then the video froze and the audio continued without it

  Furthermore, when I dumped the stream to a file (ffmpeg -i rtmp://<output> dump.mp4</output>) and look at the PTS timestamps with ffprobe (ffprobe -show_entries packet=codec_type,pts dump.mp4 | grep "video" -B 1 -A 2) the timestamps didn’t seem to show server time at all :

  ...
  
  --
  
  [PACKET]
  
  codec_type=video
  
  pts=131072
  
  [/PACKET]
  
  [PACKET]
  
  codec_type=video
  
  pts=130048
  
  [/PACKET]
  
  --
  
  [PACKET]
  
  codec_type=video
  
  pts=129536
  
  [/PACKET]
  
  [PACKET]
  
  codec_type=video
  
  pts=130560
  
  [/PACKET]
  
  --
  
  [PACKET]
  
  codec_type=video
  
  pts=131584
  
  [/PACKET]

  Is the problem just an incompatibility with RTMP ?

  Update 2

  I’ve removed the video filter and I’m now encoding like so :

  ffmpeg -re -i video.flv -output_ts_offset $(date +%s.%N) rtmp://<output>
  
  </output>

  This is encoding correctly :

  frame=  910 fps= 23 q=25.0 size=   12027kB time=00:00:38.97 bitrate=2528.2kbits/s speed=0.981x 

  In order to verify that the PTS values are correct, I’m dumping the output to a file like so :

  ffmpeg -i rtmp://<output> -copyts -write_tmcd 0 dump.mp4
  
  </output>

  I tried saving it as dump.flv (since it’s RTMP) however this threw the error :

  [flv @ 0x5600f24b4620] Audio codec mp3 not compatible with flv

  This is a bit weird since the video isn’t mp3-encoded (it’s speex) - but whatever.

  While dumping this file the following error pops up repeatedly :

  frame=    1 fps=0.0 q=0.0 size=       0kB time=00:00:09.21 bitrate=   0.0kbits/s dup=0 dr
  
  43090023 frame duplication too large, skipping
  
  43090027 frame duplication too large, skipping
  
      Last message repeated 3 times
  
  43090031 frame duplication too large, skipping
  
      Last message repeated 3 times
  
  43090035 frame duplication too large, skipping

  Playing the resulting video in VLC plays an audio stream but displays no video. I then attempt to probe this video with ffprobe to look at the video PTS values :

  ffprobe -show_entries packet=codec_type,pts dump.mp4 | grep "video" -B 1 -A 2

  This returns only a single video frame whose PTS is not large like I would expect :

  [PACKET]
  
  codec_type=video
  
  pts=1020
  
  [/PACKET]

  This has been a surprisingly difficult task

• ffmpeg : Extracted wav from mp4 video does not have equal duration as the original video

  26 juillet 2021, par John Smith

  I have a mp4 video that is 0.92 seconds, and I am trying to extract the audio of the video to a wav format. I have tried several commands (I have provided a list of some of the commands that I have tried), however, the resulting wav does not have the same duration as the original video (the resulting wav often has a duration of 0.96 seconds instead of 0.92 seconds). Ensuring that the video and audio are synchronous is crucial for what I am doing (the videos are typically videos of a person speaking, and it is important that the speech (audio) is in-sync with the mouth movements of the speaker).

  


  I find it odd that, by extracting audio from a video, the duration changes, even despite what is happening under the hood for the conversion (in terms of codecs used, etc).

  


  Some of the commands that I've tried include :

  


  ffmpeg -i <input /> -c copy -map 0:a -sample_rate 16000 <output>&#xA;&#xA;ffmpeg -i <input /> -async  1 -f wav <output>&#xA;&#xA;ffmpeg -i <input /> -vn -acodec copy <output>&#xA;&#xA;ffmpeg -i <input /> -ac 2 -f wav <output>&#xA;</output></output></output></output>

  


  Any insight would be highly appreciated.
Thanks !

  


  Edit Output of the command ffmpeg -ignore_editlist true -i 00026.mp4 output.wav

  


  ffmpeg version 2021-02-28-git-85ab9deb98-full_build-www.gyan.dev Copyright (c) 2000-2021 the FFmpeg developers
  built with gcc 10.2.0 (Rev6, Built by MSYS2 project)
  configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-lzma --enable-lib
snappy --enable-zlib --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libdav1d --enable-libzvbi --enable-librav1e --enable-libsvtav1 --en
able-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libaom --enable-libopenjpeg --enable-libvpx --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libvidstab --e
nable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-libglslang --enable-vulkan --
enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwben
c --enable-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --en
able-libsoxr --enable-chromaprint
  libavutil      56. 66.100 / 56. 66.100
  libavcodec     58.126.100 / 58.126.100
  libavformat    58. 68.100 / 58. 68.100
  libavdevice    58. 12.100 / 58. 12.100
  libavfilter     7.107.100 /  7.107.100
  libswscale      5.  8.100 /  5.  8.100
  libswresample   3.  8.100 /  3.  8.100
  libpostproc    55.  8.100 / 55.  8.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '00026.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2mp41
    encoder         : Lavf57.37.101
  Duration: 00:00:00.98, start: 0.000000, bitrate: 599 kb/s
  Stream #0:0(und): Video: mpeg4 (Simple Profile) (mp4v / 0x7634706D), yuv420p, 160x160 [SAR 1:1 DAR 1:1], 556 kb/s, 25 fps, 25 tbr, 12800 tbn, 25 tbc (default)
    Metadata:
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
  Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 16000 Hz, mono, fltp, 65 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]
Stream mapping:
  Stream #0:1 -> #0:0 (aac (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
Output #0, wav, to 'output.wav':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2mp41
    ISFT            : Lavf58.68.100
  Stream #0:0(und): Audio: pcm_s16le ([1][0][0][0] / 0x0001), 16000 Hz, mono, s16, 256 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]
      encoder         : Lavc58.126.100 pcm_s16le
size=      32kB time=00:00:00.96 bitrate= 273.7kbits/s speed= 212x
video:0kB audio:32kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.238037%