Unexpected result when discarding keyframes

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Unexpected result when discarding keyframes

jamesfowkes
We have a video conversion process using ffmpeg, for generating
low-quality previews of h264 videos.
This is partially done on a Raspberry Pi, and then uploaded to a
server where some more processing is done.

For testing purposes, I am using a PC (ffmpeg under cygwin) rather
than the raspberry pi itself.
The end results are identical on both.

Currently this process works for a particular set of videos.
We are now adding a second video source that this process does not work with.

As part of the process, we generate files that are only supposed to
have keyframes in:

ffmpeg -discard nokey -i split.mp4 -c copy -y keyframes.h264

Output from this command (for a typical representative file):

On the raspberry pi: http://0x0.st/zGzL.log
On the PC: http://0x0.st/zGz9.log

The issue I am having is that this keyframes.h264 file seems to have
non-keyframes in it at the start.
The original video has a keyframe per second at 25fps.
The created keyframe files have the first 20-25 frames of the original
video, and then the remaining keyframes.

I have determined this by getting ffmpeg to dump the frames from that
keyframe file to jpg.

This ultimately has the effect of "stretching" the first second of
footage to 20-25s when we reconstruct the video.
This is because it assumes that each frame in the uploaded video is at
1s intervals.

I have omitted the remaining steps from the upload and reconstruction
process for clarity.
I can provide details of those steps if needed.

I have upload example input and output files:
1. Representative input file: http://0x0.st/zGzp.mp4
2. Keyframes h264 file: http://0x0.st/zGzf.h264

If I use:
ffprobe -select_streams v -show_frames -show_entries frame=pict_type
-of csv 02-Asplit.mp4 | grep -n I | cut -d ':' -f 1

to get the indexes of the keyframes in the original file, ffprobe
certainly thinks that there is 1 every 25 frames:

1
26
51
76
etc...

so I am reasonably certain that the original files are OK.

For comparison, here are mp4 files and a log from a different source
that is correctly converted using the same commands:
1. Representative input file: http://0x0.st/zG-M.mp4
2. Keyframes h264 file: http://0x0.st/zG-g.h264
3. ffmpeg log: http://0x0.st/zG-l.log

Basically, my question is how can I correctly produce this "raw"
keyframes file from the given input?
I hope all the above is clear.

Thanks in advance for any assistance!
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected result when discarding keyframes

Carl Eugen Hoyos-2
Am Mo., 23. Dez. 2019 um 17:26 Uhr schrieb James Fowkes <[hidden email]>:

> ffmpeg -discard nokey -i split.mp4 -c copy -y keyframes.h264

Does it work without -c copy? I ask because I suspect discarding
cannot work reliably without decoding.

For future questions: Please post the console output in your mail,
do not use external resources and please (only) test current FFmpeg
git head, not a two-year old version.

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected result when discarding keyframes

jamesfowkes
> Does it work without -c copy? I ask because I suspect discarding
> cannot work reliably without decoding.

There are still the unexpected extra frames at the start of the video.
The file generated is closer to a "normal" video in that it has
preserved the 1s timing between keyframes.

> For future questions: Please post the console output in your mail,
> do not use external resources and please (only) test current FFmpeg
> git head, not a two-year old version.

Apologies, I didn't want to lengthen an already long and verbose post
with the console output, but yes I will do in future.
I have updated my ffmpeg build to 20191223-5b42d33 from
https://ffmpeg.zeranoe.com/builds/ and the result is the same.

I have run ffprobe against the working and non-working input files,
here is the output:

ffprobe version git-2019-12-23-5b42d33 Copyright (c) 2007-2019 the
FFmpeg developers
  built with gcc 9.2.1 (GCC) 20191125
  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-libmfx --enable-ffnvcodec
--enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec
--enable-dxva2 --enable-avisynth --enable-libopenmpt --enable-amf
  libavutil      56. 36.101 / 56. 36.101
  libavcodec     58. 65.100 / 58. 65.100
  libavformat    58. 35.101 / 58. 35.101
  libavdevice    58.  9.101 / 58.  9.101
  libavfilter     7. 69.101 /  7. 69.101
  libswscale      5.  6.100 /  5.  6.100
  libswresample   3.  6.100 /  3.  6.100
  libpostproc    55.  6.100 / 55.  6.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '2019-12-24_13-51-34.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    title           : NVT
    encoder         : Lavf57.83.100
    comment         : From NVT
  Duration: 00:00:14.93, start: 7290.494000, bitrate: 3701 kb/s
    Stream #0:0(und): Video: h264 (Baseline) (avc1 / 0x31637661),
yuvj420p(pc, bt709), 1280x720, 3700 kb/s, 14.07 fps, 14 tbr, 90k tbn,
180k tbc (default)
    Metadata:
      handler_name    : VideoHandler

and

ffprobe version git-2019-12-23-5b42d33 Copyright (c) 2007-2019 the
FFmpeg developers
  built with gcc 9.2.1 (GCC) 20191125
  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-libmfx --enable-ffnvcodec
--enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec
--enable-dxva2 --enable-avisynth --enable-libopenmpt --enable-amf
  libavutil      56. 36.101 / 56. 36.101
  libavcodec     58. 65.100 / 58. 65.100
  libavformat    58. 35.101 / 58. 35.101
  libavdevice    58.  9.101 / 58.  9.101
  libavfilter     7. 69.101 /  7. 69.101
  libswscale      5.  6.100 /  5.  6.100
  libswresample   3.  6.100 /  3.  6.100
  libpostproc    55.  6.100 / 55.  6.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '2019-12-24_13-57-25.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    title           : Unnamed
    encoder         : Lavf57.83.100
    comment         : N/A
  Duration: 00:00:14.97, start: 7665.101000, bitrate: 2815 kb/s
    Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p,
1280x720, 2812 kb/s, 25.05 fps, 50 tbr, 90k tbn, 180k tbc (default)
    Metadata:
      handler_name    : VideoHandler

Are there any clues there that might explain why one video converts
correctly and one does not?
The frame rates are different, this is expected.

> For future questions: Please post the console output in your mail,
> do not use external resources and please (only) test current FFmpeg
> git head, not a two-year old version.
>
> Carl Eugen
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected result when discarding keyframes

jamesfowkes
Further to this, I have added -vf showinfo to my command to extract the
keyframes:

ffmpeg -discard nokey -i input.mp4 -*vf showinfo* -y keyframes.h264

and found that the filter is being passed non-keyframes:

[Parsed_showinfo_0 @ 0x55ec60de6fa0] n:   1 pts:   3600 pts_time:0.04  
pos:   127530 fmt:yuv420p sar:0/1 s:1280x720 i:P *iskey:0* type:P
checksum:EBA32398 plane_checksum:[882BBFFB 3231DC1F E60E8760] mean:[151 127
131] stdev:[74.8 18.2 32.6]
[Parsed_showinfo_0 @ 0x55ec60de6fa0] n:   2 pts:   9180 pts_time:0.102  
pos:   136911 fmt:yuv420p sar:0/1 s:1280x720 i:P *iskey:0* type:P
checksum:4657EC88 plane_checksum:[EB70D587 D91D93DD E0C58315] mean:[151 127
131] stdev:[74.8 18.0 32.6]
[Parsed_showinfo_0 @ 0x55ec60de6fa0] n:   3 pts:  12600 pts_time:0.14  
pos:   146063 fmt:yuv420p sar:0/1 s:1280x720 i:P *iskey:0*type:P
checksum:6A506244 plane_checksum:[BD5CD810 8B454B0C F2103F19] mean:[151 127
131] stdev:[74.8 17.9 32.8]
[Parsed_showinfo_0 @ 0x55ec60de6fa0] n:   4 pts:  16200 pts_time:0.18  
pos:   155157 fmt:yuv420p sar:0/1 s:1280x720 i:P *iskey:0* type:P
checksum:B5C77F8B plane_checksum:[421E2037 C6D61A27 2EEA452D] mean:[151 127
131] stdev:[74.8 18.0 32.7]
[Parsed_showinfo_0 @ 0x55ec60de6fa0] n:   5 pts:  18090 pts_time:0.201  
pos:   164134 fmt:yuv420p sar:0/1 s:1280x720 i:P *iskey:0* type:P
checksum:3DF0E4B6 plane_checksum:[8A7CB7AA E5BEC0C8 F5CE6C35] mean:[151 127
131] stdev:[74.8 17.7 32.6]

... continues to the 20th frame before getting first keyframe:

[Parsed_showinfo_0 @ 0x55ec60de6fa0] n:  21 pts:  90900 pts_time:1.01  
pos:   347318 fmt:yuv420p sar:0/1 s:1280x720 i:P *iskey:1* type:I
checksum:CDA770D7 plane_checksum:[61C66960 34A37132 B0409636] mean:[151 127
131] stdev:[74.8 17.9 32.6]

... and then gets only keyframes from this point onwards.







--
Sent from: http://www.ffmpeg-archive.org/
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected result when discarding keyframes

jamesfowkes
Just in case anyone finds this in the future, the eventual solution to this
issue (for me, I don't know how applicable it is generally), was to add -ss
0 to the ffmpeg command:

ffmpeg -discard nokey -ss 0 -i input.mp4 -c copy -y keyframes.h264

I'm guessing the input stream has weird timing information or something.



--
Sent from: http://www.ffmpeg-archive.org/
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".