[FFmpeg-trac] #6682(undetermined:new): hstack repeats input frames
FFmpeg
trac at avcodec.org
Sat Sep 23 00:46:58 EEST 2017
#6682: hstack repeats input frames
-------------------------------------+-------------------------------------
Reporter: damonmaria | Owner:
Type: defect | Status: new
Priority: normal | Component:
Version: git-master | undetermined
Keywords: hstack | Resolution:
Blocking: | Blocked By:
Analyzed by developer: 0 | Reproduced by developer: 0
-------------------------------------+-------------------------------------
Comment (by damonmaria):
cehoyos: I'm not certain what you're asking for. If it's the command line
and console when I saved the RTSP streams to file like the files I've been
using above then it's:
{{{
$ ffmpeg -i "rtsp://root:root@192.168.13.104/axis-
media/media.amp?camera=1" -c:v copy -map 0:0 -t 10 -metadata
title="rtsp://root:root@192.168.13.104/axis-media/media.amp?camera=1"
2017-09-22T231000-1.mp4
ffmpeg version 3.3.4-1~16.04.york0 Copyright (c) 2000-2017 the FFmpeg
developers
built with gcc 5.4.0 (Ubuntu 5.4.0-6ubuntu1~16.04.4) 20160609
configuration: --prefix=/usr --extra-version='1~16.04.york0'
--toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu
--incdir=/usr/include/x86_64-linux-gnu --enable-gpl --disable-stripping
--enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa
--enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca
--enable-libcdio --enable-libflite --enable-libfontconfig --enable-
libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-
libmp3lame --enable-libopenjpeg --enable-libopenmpt --enable-libopus
--enable-libpulse --enable-librubberband --enable-libshine --enable-
libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-
libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-
libwavpack --enable-libwebp --enable-libx265 --enable-libxvid --enable-
libzmq --enable-libzvbi --enable-omx --enable-openal --enable-opengl
--enable-sdl2 --enable-libdc1394 --enable-libiec61883 --enable-chromaprint
--enable-frei0r --enable-libopencv --enable-libx264 --enable-shared
libavutil 55. 58.100 / 55. 58.100
libavcodec 57. 89.100 / 57. 89.100
libavformat 57. 71.100 / 57. 71.100
libavdevice 57. 6.100 / 57. 6.100
libavfilter 6. 82.100 / 6. 82.100
libavresample 3. 5. 0 / 3. 5. 0
libswscale 4. 6.100 / 4. 6.100
libswresample 2. 7.100 / 2. 7.100
libpostproc 54. 5.100 / 54. 5.100
Input #0, rtsp, from 'rtsp://root:root@192.168.13.104/axis-
media/media.amp?camera=1':
Metadata:
title : Session streamed with GStreamer
comment : rtsp-server
Duration: N/A, start: 0.249978, bitrate: N/A
Stream #0:0: Video: h264 (Main), yuvj420p(pc, bt709, progressive),
800x600 [SAR 1:1 DAR 4:3], 4 fps, 4 tbr, 90k tbn, 180k tbc
Output #0, mp4, to '2017-09-22T231000-1.mp4':
Metadata:
comment : rtsp-server
title : rtsp://root:root@192.168.13.104/axis-
media/media.amp?camera=1
encoder : Lavf57.71.100
Stream #0:0: Video: h264 (Main) ([33][0][0][0] / 0x0021), yuvj420p(pc,
bt709, progressive), 800x600 [SAR 1:1 DAR 4:3], q=2-31, 4 fps, 4 tbr, 90k
tbn, 90k tbc
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
[mp4 @ 0x916602e20] Timestamps are unset in a packet for stream 0. This is
deprecated and will stop working in the future. Fix your code to set the
timestamps properly
[mp4 @ 0x916602e20] Non-monotonous DTS in output stream 0:0; previous: 0,
current: 0; changing to 1. This may result in incorrect timestamps in the
output file.
frame= 42 fps= 11 q=-1.0 Lsize= 249kB time=00:00:10.00 bitrate=
204.3kbits/s speed=2.67x
video:248kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 0.541773%
}}}
I've been recording videos with a script so haven't noticed the warning
about "Timestamps are unset" and "Non-monotonous DTS in output stream
0:0". I don't remember them from when I was testing the script. Does that
point to a problem? As I said above, I have Wireshark'ed the RTP and RTCP
packets and they contain random starting, monotonic sequence numbers, and
the Sender Reports contain NTP timestamps matching the pts in the RTP
stream.
Note: my testing previous to this has been on my dev machine using the git
master version of ffmpeg. I've been dumping the videos from the machine
the camera is connected to which is (now, just upgraded) ffmpeg 3.3.4.
Also note, the videos I used above were recorded with 3.3.3. I could
compile ffmpeg from a git clone on the camera machine too if you would
prefer.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/6682#comment:9>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list