Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

[Andy Furniss]

Mark Thompson wrote:

On 20/09/17 17:10, Andy Furniss wrote:

Mark Thompson wrote:

On 19/09/17 22:21, Andy Furniss wrote:



That point being around 7k frames it will run out of something.

[AVHWFramesContext @ 0x31ed880] Failed to create surface from DRM object: 2 
(resource allocation failed).
[Parsed_hwmap_0 @ 0x3114c40] Failed to map frame: -5.

I see that memory is reducing before this although I still have spare - is this 
the same issue you explained on users WRT leaking on decode?


Yeah, I also run out of ... something ... at around 7200 frames.  It's not fds 
or memory.  I don't think it's the buffer problem (which, incidentally, should 
finally be fixable sensibly in libva2 soon), because that ended up manifesting 
as leaking memory.  It's also not a problem for Intel (I've already been 
running that for a long time to test).  Maybe some other sort of handle on the 
Mesa side?  I'll investigate further tomorrow.


Leo has fixed the leak.


Yep, checked with the updated Mesa postproc patches + libva2 fixes and it all 
looks good now.  (And colours are even correct, yay!  I still need to look into 
why the default comes out wrong with the postproc bits for that on Intel...)


One thing that comes out in testing the patches WRT postproc is that for 
deinterlace 1080i25 -> 1080p50 there is an issue with the surface size 
being 1088.
This means the result gets scaled to 1088. It is possible to put scale 
after to get 1080, but this seems sub-optimal, costs about 8% perf and 
hypothetical quality issue (not that I could see it).


Apparently vaapi_scale does things differently and the driver is set for 
that way, so changing in the driver will break scale.


AFAICT this is orthogonal to the 1080/1088 encode issue discussed long 
ago where ffmpeg is doing the right thing, that should be fixable in the 
driver.


This case can be demonstrated with 1920x1080 nv12 hwupload -> deint -> 
hwdownload, so no chance for h26x cropping info being used.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

[Andy Furniss]

Mark Thompson wrote:

On 19/09/17 22:21, Andy Furniss wrote:



That point being around 7k frames it will run out of something.

[AVHWFramesContext @ 0x31ed880] Failed to create surface from DRM object: 2 
(resource allocation failed).
[Parsed_hwmap_0 @ 0x3114c40] Failed to map frame: -5.

I see that memory is reducing before this although I still have spare - is this 
the same issue you explained on users WRT leaking on decode?


Yeah, I also run out of ... something ... at around 7200 frames.  It's not fds 
or memory.  I don't think it's the buffer problem (which, incidentally, should 
finally be fixable sensibly in libva2 soon), because that ended up manifesting 
as leaking memory.  It's also not a problem for Intel (I've already been 
running that for a long time to test).  Maybe some other sort of handle on the 
Mesa side?  I'll investigate further tomorrow.


Leo has fixed the leak.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

[Andy Furniss]

Mark Thompson wrote:

On 15/09/17 00:15, Andy Furniss wrote:

Andy Furniss wrote:

Mark Thompson wrote:

---
Now sets the trusted packet flag; otherwise unchanged.


   configure|   1 +
   libavdevice/Makefile |   1 +
   libavdevice/alldevices.c |   1 +
   libavdevice/kmsgrab.c| 455 
+++
   4 files changed, 458 insertions(+)
   create mode 100644 libavdevice/kmsgrab.c

diff --git a/configure b/configure
index 6581c53c1a..76a7591ceb 100755
--- a/configure
+++ b/configure
@@ -3040,6 +3040,7 @@ gdigrab_indev_select="bmp_decoder"
   iec61883_indev_deps="libiec61883"
   jack_indev_deps="jack"
   jack_indev_deps_any="sem_timedwait dispatch_dispatch_h"
+kmsgrab_indev_deps="libdrm"


Doesn't get built for me = doesn't show up as indev after configure anything 
special needed?


Never mind I found --enable-libdrm (had tried --enable-kmsgrab)


I assume you're going to try AMD + Mesa + VAAPI.

VAAPI_DISABLE_INTERLACE=1 ./ffmpeg_g -y -format bgr0 -device /dev/dri/card1 -f 
kmsgrab -i - -vsync 0 -init_hw_device vaapi=v:/dev/dri/renderD129 
-filter_hw_device v -vf 'hwmap,scale_vaapi=w=1920:h=1080:format=nv12' -c:v 
h264_vaapi -profile 578 -bf 0 out.mp4

Three Mesa issues I had to get around:

* Device derivation doesn't work because the Mesa driver doesn't want to 
initialise on the DRM master device for some reason; making the matching device 
separately does work.
* Against current git, you need to reapply the VAAPI_DISABLE_INTERLACE patch 
and use it - if not, the colour conversion just barfs because it wants 
interlaced surfaces.
* The postproc scaler seems to only write the luma plane when converting from 
RGB - this is also visible when uploading normal RGB images, so just a bug 
somewhere.

With that, it works to record the screen in greyscale...

I have some other Mesa stuff to do queued up (libva2 with VAAPI export for EGL 
import on AMD), so I'll pursue these further soonish.


Leo just posted a patchset on the mesa list that makes vaapi work better 
with this and postproc generally.


You don't need the env with those and kmsgrab is now working for me - up 
to a point ...


That point being around 7k frames it will run out of something.

[AVHWFramesContext @ 0x31ed880] Failed to create surface from DRM 
object: 2 (resource allocation failed).

[Parsed_hwmap_0 @ 0x3114c40] Failed to map frame: -5.

I see that memory is reducing before this although I still have spare - 
is this the same issue you explained on users WRT leaking on decode?

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

[Andy Furniss]

Mark Thompson wrote:

On 15/09/17 00:15, Andy Furniss wrote:

Andy Furniss wrote:

Mark Thompson wrote:

---
Now sets the trusted packet flag; otherwise unchanged.


   configure|   1 +
   libavdevice/Makefile |   1 +
   libavdevice/alldevices.c |   1 +
   libavdevice/kmsgrab.c| 455 
+++
   4 files changed, 458 insertions(+)
   create mode 100644 libavdevice/kmsgrab.c

diff --git a/configure b/configure
index 6581c53c1a..76a7591ceb 100755
--- a/configure
+++ b/configure
@@ -3040,6 +3040,7 @@ gdigrab_indev_select="bmp_decoder"
   iec61883_indev_deps="libiec61883"
   jack_indev_deps="jack"
   jack_indev_deps_any="sem_timedwait dispatch_dispatch_h"
+kmsgrab_indev_deps="libdrm"


Doesn't get built for me = doesn't show up as indev after configure anything 
special needed?


Never mind I found --enable-libdrm (had tried --enable-kmsgrab)


I assume you're going to try AMD + Mesa + VAAPI.

VAAPI_DISABLE_INTERLACE=1 ./ffmpeg_g -y -format bgr0 -device /dev/dri/card1 -f 
kmsgrab -i - -vsync 0 -init_hw_device vaapi=v:/dev/dri/renderD129 
-filter_hw_device v -vf 'hwmap,scale_vaapi=w=1920:h=1080:format=nv12' -c:v 
h264_vaapi -profile 578 -bf 0 out.mp4

Three Mesa issues I had to get around:

* Device derivation doesn't work because the Mesa driver doesn't want to 
initialise on the DRM master device for some reason; making the matching device 
separately does work.
* Against current git, you need to reapply the VAAPI_DISABLE_INTERLACE patch 
and use it - if not, the colour conversion just barfs because it wants 
interlaced surfaces.
* The postproc scaler seems to only write the luma plane when converting from 
RGB - this is also visible when uploading normal RGB images, so just a bug 
somewhere.

With that, it works to record the screen in greyscale...

I have some other Mesa stuff to do queued up (libva2 with VAAPI export for EGL 
import on AMD), so I'll pursue these further soonish.


Thanks for the info, as it happens I am running some testing patches 
from Leo currently that fix up postproc deinterlace now the env is gone.


I'll point Leo at this mail and test this evening.




- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

[Andy Furniss]

Andy Furniss wrote:

Mark Thompson wrote:

---
Now sets the trusted packet flag; otherwise unchanged.


  configure|   1 +
  libavdevice/Makefile |   1 +
  libavdevice/alldevices.c |   1 +
  libavdevice/kmsgrab.c| 455 
+++

  4 files changed, 458 insertions(+)
  create mode 100644 libavdevice/kmsgrab.c

diff --git a/configure b/configure
index 6581c53c1a..76a7591ceb 100755
--- a/configure
+++ b/configure
@@ -3040,6 +3040,7 @@ gdigrab_indev_select="bmp_decoder"
  iec61883_indev_deps="libiec61883"
  jack_indev_deps="jack"
  jack_indev_deps_any="sem_timedwait dispatch_dispatch_h"
+kmsgrab_indev_deps="libdrm"


Doesn't get built for me = doesn't show up as indev after configure 
anything special needed?


Never mind I found --enable-libdrm (had tried --enable-kmsgrab)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber

[Andy Furniss]

Mark Thompson wrote:

---
Now sets the trusted packet flag; otherwise unchanged.


  configure|   1 +
  libavdevice/Makefile |   1 +
  libavdevice/alldevices.c |   1 +
  libavdevice/kmsgrab.c| 455 +++
  4 files changed, 458 insertions(+)
  create mode 100644 libavdevice/kmsgrab.c

diff --git a/configure b/configure
index 6581c53c1a..76a7591ceb 100755
--- a/configure
+++ b/configure
@@ -3040,6 +3040,7 @@ gdigrab_indev_select="bmp_decoder"
  iec61883_indev_deps="libiec61883"
  jack_indev_deps="jack"
  jack_indev_deps_any="sem_timedwait dispatch_dispatch_h"
+kmsgrab_indev_deps="libdrm"


Doesn't get built for me = doesn't show up as indev after configure 
anything special needed?


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v14] avformat/dashdec: add dash demuxer base version

[Andy Furniss]

Steven Liu wrote:

2017-04-11 22:27 GMT+08:00 Andy Furniss <adf.li...@gmail.com>:


Steven Liu wrote:


ffmpeg need a dash demuxer for demux the dash formats base on
https://github.com/samsamsam-iptvplayer/exteplayer3/blob/mas
ter/tmp/ffmpeg/patches/3.2.2/01_add_dash_demux.patch

TODO: 1. support multi bitrate dash



v14 fixed: 1. fix bug: TLS connection was non-properly terminated
2.

fix bug: No trailing CRLF found in HTTP header



Thanks.

They are pretty much gone now, though I did see one TLS out of
about 3 hours running (3.84s chunks)

Another user who is testing the same live stream saw eight TLS @
0xae75700" referring to TLS packets of unexpected length. over a 3
hour run.

One issue that I guess is not really a bug, but on a live stream
you really need to have your clock either spot on or slow.

Ok, so maybe I should run ntpd "properly" - though not running it
does offer a workaround of setting clock back a bit (the stream mpd
below has a 10 minute buffer).

This issue = even if set my clock with ntpd -q only a small amount
of too fast drift will lead to (after a couple of hours)

[https @ 0x365e580] HTTP error 404 Not Found [dash @ 0x3657360]
Failed to open fragment of playlist 0

ntpd -q showed I was 0.2 sec fast at that point - for the purpose
of testing just setting one sec fast will quickly start getting
404s which are not retried, so break the stream.

I notice there is a time url in the mpd - but even if that were
used initially vs clock, I still think drift would break things.


Here's the .mpd (same as link I gave before - pasting as I suspect
it's geo restricted).



The result is: you want to say: use the UTCTimeing's value, if it
show in mpd file, do i misunderstand you?


Not really - though it seems to be what firefox does.

As things stand it could be bad in the sense that I couldn't work around
clock drift if that were used vs system time.

Whatever clock is used to calculate initial filename, maybe it would be
safer if ffmpeg either backed away a bit from getting the very latest
chunk, or if it could react to getting a 404 on a live stream in a way
that didn't loose the chunk - which in this case would likely be there a
fraction of a second later.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v14] avformat/dashdec: add dash demuxer base version

[Andy Furniss]

Steven Liu wrote:

ffmpeg need a dash demuxer for demux the dash formats base on
https://github.com/samsamsam-iptvplayer/exteplayer3/blob/master/tmp/ffmpeg/patches/3.2.2/01_add_dash_demux.patch

 TODO: 1. support multi bitrate dash



v14 fixed: 1. fix bug: TLS connection was non-properly terminated 2.
fix bug: No trailing CRLF found in HTTP header


Thanks.

They are pretty much gone now, though I did see one TLS out of about 3
hours running (3.84s chunks)

Another user who is testing the same live stream saw eight
TLS @ 0xae75700" referring to TLS packets of unexpected length.
over a 3 hour run.

One issue that I guess is not really a bug, but on a live stream you
really need to have your clock either spot on or slow.

Ok, so maybe I should run ntpd "properly" - though not running it does
offer a workaround of setting clock back a bit (the stream mpd below has
a 10 minute buffer).

This issue = even if set my clock with ntpd -q only a small amount of
too fast drift will lead to (after a couple of hours)

[https @ 0x365e580] HTTP error 404 Not Found
[dash @ 0x3657360] Failed to open fragment of playlist 0

ntpd -q showed I was 0.2 sec fast at that point - for the purpose of
testing just setting one sec fast will quickly start getting 404s which
are not retried, so break the stream.

I notice there is a time url in the mpd - but even if that were used
initially vs clock, I still think drift would break things.


Here's the .mpd (same as link I gave before - pasting as I suspect it's
geo restricted).


xmlns:dvb="urn:dvb:dash-extensions:2014-1" 
profiles="urn:dvb:dash:profile:dvb-dash:2014,urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014" 
minBufferTime="PT2.034S" maxSegmentDuration="PT3.84S" 
timeShiftBufferDepth="PT10M" minimumUpdatePeriod="PT1H" 
availabilityStartTime="1970-01-01T00:01:00Z" 
publishTime="2017-02-01T15:13:36Z">









Radio 3 lossless
BBC Research and Development
British Broadcasting Corporation 
2017


value="http://time.akamai.com/?iso"/>


id="1" codecs="flac" audioSamplingRate="48000" lang="eng" 
mimeType="audio/mp4">
schemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011" 
value="2"/>
value="main"/>
duration="184320" media="$RepresentationID$/$Number%06d$.m4s" 
initialization="$RepresentationID$/IS.mp4" startNumber="1" 
presentationTimeOffset="0"/>





value="1" 
dvb:reportingUrl="http://rdmedia.bbc.co.uk/dash/errorreporting/reporterror.php; 
dvb:probability="50"/>



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v13] avformat/dashdec: add dash demuxer base version

[Andy Furniss]

Steven Liu wrote:


v13 fixed:
1. fix bug: cannot play:
http://dash.edgesuite.net/akamai/bbb_30fps/bbb_30fps.mpd


Great things seem to be working OK now.

Is it possible to choose streams?

There are some logging nits on the mpds I've tested.

http logs per chunk

No trailing CRLF found in HTTP header.

https additionally logs

The TLS connection was non-properly terminated.

With a live stream plus -loglevel verbose there is "too much"

I don't know if this url will work outside the UK.

ffmpeg -loglevel verbose -i 
https://vs-dash-ww-rd-live.bbcfmt.hs.llnwd.net/al/lossless/client_manifest.mpd 
-f null -
ffmpeg version N-85386-gd14a1bd Copyright (c) 2000-2017 the FFmpeg 
developers

  built with gcc 5.3.0 (GCC)
  configuration: --prefix=/usr --disable-doc --enable-gpl --enable-omx 
--enable-opencl --enable-libvpx --enable-libx265 --enable-libmp3lame 
--enable-libx264 --enable-gnutls --enable-libxml2

  libavutil  55. 60.100 / 55. 60.100
  libavcodec 57. 92.100 / 57. 92.100
  libavformat57. 72.100 / 57. 72.100
  libavdevice57.  7.100 / 57.  7.100
  libavfilter 6. 84.100 /  6. 84.100
  libswscale  4.  7.100 /  4.  7.100
  libswresample   2.  8.100 /  2.  8.100
  libpostproc54.  6.100 / 54.  6.100
[dash @ 0x22bd320] DASH request for url 
'https://vs-dash-ww-rd-live.bbcfmt.hs.llnwd.net/al/lossless/A1/IS.mp4', 
offset 0, playlist 0

[https @ 0x27aeb60] No trailing CRLF found in HTTP header.
[tls @ 0x22c5860] The TLS connection was non-properly terminated.
[dash @ 0x22bd320] Could not read complete fragment.
[dash @ 0x22bd320] DASH request for url 
'https://vs-dash-ww-rd-live.bbcfmt.hs.llnwd.net/al/lossless/A1/388460817.m4s', 
offset 0, playlist 0

[https @ 0x22c4b20] No trailing CRLF found in HTTP header.
Input #0, dash, from 
'https://vs-dash-ww-rd-live.bbcfmt.hs.llnwd.net/al/lossless/client_manifest.mpd':

  Duration: N/A, start: 1491689537.28, bitrate: N/A
  Program 0
Stream #0:0: Audio: flac (fLaC / 0x43614C66), 48000 Hz, stereo, s16
Stream mapping:
  Stream #0:0 -> #0:0 (flac (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
[graph_0_in_0_0 @ 0x27cd920] tb:1/48000 samplefmt:s16 samplerate:48000 
chlayout:0x3

Output #0, null, to 'pipe:':
  Metadata:
encoder : Lavf57.72.100
Stream #0:0: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
Metadata:
  encoder : Lavc57.92.100 pcm_s16le
[tls @ 0x22c58a0] The TLS connection was non-properly terminated.
[dash @ 0x22bd320] new fragment: min[388460661] max[388460817], playlist 0
Last message repeated 2253 times
[dash @ 0x22bd320] DASH request for url 
'https://vs-dash-ww-rd-live.bbcfmt.hs.llnwd.net/al/lossless/A1/388460818.m4s', 
offset 0, playlist 0

[https @ 0x27d0660] No trailing CRLF found in HTTP header.
[tls @ 0x27d7f80] The TLS connection was non-properly terminated.
[dash @ 0x22bd320] new fragment: min[388460661] max[388460818], playlist 0
Last message repeated 652 times
[dash @ 0x22bd320] new fragment: min[388460662] max[388460818], playlist 0
Last message repeated 2804 times
[dash @ 0x22bd320] DASH request for url 
'https://vs-dash-ww-rd-live.bbcfmt.hs.llnwd.net/al/lossless/A1/388460819.m4s', 
offset 0, playlist 0

[https @ 0x27d0660] No trailing CRLF found in HTTP header.
[tls @ 0x27d7f80] The TLS connection was non-properly terminated.
[dash @ 0x22bd320] new fragment: min[388460662] max[388460819], playlist 0
Last message repeated 809 times
[dash @ 0x22bd320] new fragment: min[388460663] max[388460819], playlist 0
Last message repeated 1868 times
[dash @ 0x22bd320] DASH request for url 
'https://vs-dash-ww-rd-live.bbcfmt.hs.llnwd.net/al/lossless/A1/388460820.m4s', 
offset 0, playlist 0

[https @ 0x2da3a40] No trailing CRLF found in HTTP header.
[tls @ 0x2850500] The TLS connection was non-properly terminated.
[dash @ 0x22bd320] new fragment: min[388460663] max[388460820], playlist 0
Last message repeated 661 times
[dash @ 0x22bd320] new fragment: min[388460664] max[388460820], playlist 0
Last message repeated 2803 times
[dash @ 0x22bd320] DASH request for url 
'https://vs-dash-ww-rd-live.bbcfmt.hs.llnwd.net/al/lossless/A1/388460821.m4s', 
offset 0, playlist 0

[https @ 0x27d0660] No trailing CRLF found in HTTP header.
size=N/A time=00:00:15.07 bitrate=N/A speed= 1.1x
video:0kB audio:2826kB subtitle:0kB other streams:0kB global headers:0kB 
muxing overhead: unknown
Input file #0 
(https://vs-dash-ww-rd-live.bbcfmt.hs.llnwd.net/al/lossless/client_manifest.mpd):
  Input stream #0:0 (audio): 161 packets read (1184205 bytes); 158 
frames decoded (728064 samples);

  Total: 161 packets (1184205 bytes) demuxed
Output file #0 (pipe:):
  Output stream #0:0 (audio): 157 frames encoded (723456 samples); 157 
packets muxed (2893824 bytes);

  Total: 157 packets (2893824 bytes) muxed

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v12] avformat/dashdec: add dash demuxer base version

[Andy Furniss]

Steven Liu wrote:

ffmpeg need a dash demuxer for demux the dash formats
base on
https://github.com/samsamsam-iptvplayer/exteplayer3/blob/master/tmp/ffmpeg/patches/3.2.2/01_add_dash_demux.patch


Just a user, this will be a good feature.

This patch doesn't seem to work with say -

http://dash.edgesuite.net/akamai/bbb_30fps/bbb_30fps.mpd

Of course that base url is ./ - but I can change that or I can
grab the content and make a local setup to match.

Either way this doesn't seem to replace $Number$ properly/in time so I
get an error.

ffmpeg -loglevel debug  -i bbb_30fps-mod.mpd -f null -
ffmpeg version N-85325-g9c7ee37 Copyright (c) 2000-2017 the FFmpeg 
developers

  built with gcc 5.3.0 (GCC)
  configuration: --prefix=/usr --disable-doc --enable-gpl --enable-omx 
--enable-opencl --enable-libvpx --enable-libx265 --enable-libmp3lame 
--enable-libx264 --enable-gnutls --enable-libxml2

  libavutil  55. 60.100 / 55. 60.100
  libavcodec 57. 92.100 / 57. 92.100
  libavformat57. 72.100 / 57. 72.100
  libavdevice57.  7.100 / 57.  7.100
  libavfilter 6. 84.100 /  6. 84.100
  libswscale  4.  7.100 /  4.  7.100
  libswresample   2.  8.100 /  2.  8.100
  libpostproc54.  6.100 / 54.  6.100
Splitting the commandline.
Reading option '-loglevel' ... matched as option 'loglevel' (set logging 
level) with argument 'debug'.
Reading option '-i' ... matched as input url with argument 
'bbb_30fps-mod.mpd'.
Reading option '-f' ... matched as option 'f' (force format) with 
argument 'null'.

Reading option '-' ... matched as output url.
Finished splitting the commandline.
Parsing a group of options: global .
Applying option loglevel (set logging level) with argument debug.
Successfully parsed a group of options.
Parsing a group of options: input url bbb_30fps-mod.mpd.
Successfully parsed a group of options.
Opening an input file: bbb_30fps-mod.mpd.
[file @ 0x2ce4b80] Setting default whitelist 'file,crypto'
[dash @ 0x2ce4320] Format dash probed with size=2048 and score=100
[dash @ 0x2ce4320] rep_idx[0]
[dash @ 0x2ce4320] rep_count[0]
[dash @ 0x2ce4320] Invalid segment filename template 
http://dash.edgesuite.net/akamai/bbb_30fps/bbb_30fps_1024x576_2500k/bbb_30fps_1024x576_2500k_$Number$.m4v

Last message repeated 5 times
[dash @ 0x2ce4320] Error when loading first fragment, playlist 0
[AVIOContext @ 0x2cecec0] Statistics: 3101 bytes read, 0 seeks
bbb_30fps-mod.mpd: Invalid data found when processing input

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavfilter/af_ambisonic.c Added File for Ambisonic Filter

[Andy Furniss]

Paul B Mahol wrote:

On 3/11/17, Andy Furniss <adf.li...@gmail.com> wrote:

Sanchit Sinha wrote:

libavfilter/af_ambisonic.c | 139



+w=(float *)(*(in->extended_data)+itr);
+x=(float *)(*(in->extended_data+1)+itr);
+y=(float *)(*(in->extended_data+2)+itr);
+
+*lf = root8 * (2*(*w)+*x+*y);
+*lb = root8 * (2*(*w)-*x+*y);
+*rb = root8 * (2*(*w)-*x-*y);
+*rf = root8 * (2*(*w)+*x-*y);


Seems a bit misleading to call something ambisonic if all it will
do is 2d, so partial b-format to (square?) 4 channel.

Why not be more specific in the name so the limitation is clear.


This is just for qualification task. Later filter willl be extended.

It will not be applied as is in tree.


Ahh, OK.

A complicated subject.

Sanchit, in case you don't know, some of the people who were around at
the birth of ambisonics, plus ambdec author can be found on the list -

https://mail.music.vt.edu/mailman/listinfo/sursound




___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavfilter/af_ambisonic.c Added File for Ambisonic Filter

[Andy Furniss]

Sanchit Sinha wrote:

libavfilter/af_ambisonic.c | 139



+w=(float *)(*(in->extended_data)+itr);
+x=(float *)(*(in->extended_data+1)+itr);
+y=(float *)(*(in->extended_data+2)+itr);
+
+*lf = root8 * (2*(*w)+*x+*y);
+*lb = root8 * (2*(*w)-*x+*y);
+*rb = root8 * (2*(*w)-*x-*y);
+*rf = root8 * (2*(*w)+*x-*y);


Seems a bit misleading to call something ambisonic if all it will
do is 2d, so partial b-format to (square?) 4 channel.

Why not be more specific in the name so the limitation is clear.


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix chroma positioning for 4:2:0 pixel format

[Andy Furniss]

Andy Furniss wrote:


Another possible issue which I haven't fully investigated =

This doesn't obey setfield, which makes me think that maybe it's
only working by luck on tff input.


Ugh, ignore that bit as I don't think it should matter as long as
the filter always sees weaved frames.


A quick test with bff does seem wrong, but my bff sample may be to
blame and I don't have any "real" bff with the "right content" to test.


I guess the sample I looked at is flawed, will have to find more.



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix chroma positioning for 4:2:0 pixel format

[Andy Furniss]

Andy Furniss wrote:

Michael Niedermayer wrote:

On Mon, Feb 06, 2017 at 05:14:14PM +0200, Maksym Veremeyenko wrote:

Hi,

Attached patch fixes chroma positioning during scaling interlaced 4:2:0.

On a first iteration default context value been overwritten by new
value and not been update on next iterations for fields. This mean
that vertical chroma position remain 128 for field#0 and field#1
instead of *64* and *192*.

Attached patch use local variable for storing this intermediate
value of chroma vertical position not modifying default context
value.

--
Maksym Veremeyenko




  vf_scale.c |9 +
  1 file changed, 5 insertions(+), 4 deletions(-)
6a3a3966939dd87c45a8e124b0364da30b02728b
0001-Fix-chroma-positioning-for-4-2-0-pixel-format.patch
 From 912ecf538b6b2f7a8df4afdfed2d34052162335c Mon Sep 17 00:00:00 2001
From: Maksym Veremeyenko <ve...@m1.tv>
Date: Mon, 6 Feb 2017 17:03:17 +0200
Subject: [PATCH] Fix chroma positioning for 4:2:0 pixel format


applied

thx


Nice, testing wise it raises a question to how swscale should work by
default with interl=1 and 420 to rgb (maybe other cases as well).

In summary this patch will appear to fail with a test like.

ffmpeg -i 420-interlaced.ts -ss 11.2 -vf scale=interl=1 -vframes 1 out.png

Will look just as broken as before the patch. The addition of -

-sws_flags +accurate_rnd

fixes it, adding +full_chroma_int looks better still.


Another possible issue which I haven't fully investigated =

This doesn't obey setfield, which makes me think that maybe it's
only working by luck on tff input.

A quick test with bff does seem wrong, but my bff sample may be to
blame and I don't have any "real" bff with the "right content" to test.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix chroma positioning for 4:2:0 pixel format

[Andy Furniss]

Michael Niedermayer wrote:

On Mon, Feb 06, 2017 at 05:14:14PM +0200, Maksym Veremeyenko wrote:

Hi,

Attached patch fixes chroma positioning during scaling interlaced 4:2:0.

On a first iteration default context value been overwritten by new
value and not been update on next iterations for fields. This mean
that vertical chroma position remain 128 for field#0 and field#1
instead of *64* and *192*.

Attached patch use local variable for storing this intermediate
value of chroma vertical position not modifying default context
value.

--
Maksym Veremeyenko




  vf_scale.c |9 +
  1 file changed, 5 insertions(+), 4 deletions(-)
6a3a3966939dd87c45a8e124b0364da30b02728b  
0001-Fix-chroma-positioning-for-4-2-0-pixel-format.patch
 From 912ecf538b6b2f7a8df4afdfed2d34052162335c Mon Sep 17 00:00:00 2001
From: Maksym Veremeyenko 
Date: Mon, 6 Feb 2017 17:03:17 +0200
Subject: [PATCH] Fix chroma positioning for 4:2:0 pixel format


applied

thx


Nice, testing wise it raises a question to how swscale should work by
default with interl=1 and 420 to rgb (maybe other cases as well).

In summary this patch will appear to fail with a test like.

ffmpeg -i 420-interlaced.ts -ss 11.2 -vf scale=interl=1 -vframes 1 out.png

Will look just as broken as before the patch. The addition of -

-sws_flags +accurate_rnd

fixes it, adding +full_chroma_int looks better still.


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Video decoding error asks me to upload video to non-existing site ftp://upload.ffmpeg.org/incoming/

[Andy Furniss]

DogFilm wrote:

I am still waitinng for an upload facility. Please send me an email so I
can follow this.


You have a gmail address so I guess you have google drive.

Assuming you have the free version then upload size limit is too small
for 1.6 gig.

You could upload in two parts and post the 2 links.

To split the file without ffmpeg use dd eg.

dd if=FFMPEG-DESTROY_20170103.mp4 of=part-one bs=1M count=800

and

dd if=FFMPEG-DESTROY_20170103.mp4 of=part-two bs=1M skip=800

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Video decoding error asks me to upload video to non-existing site ftp://upload.ffmpeg.org/incoming/

[Andy Furniss]

DogFilm wrote:

OK, please tell me a place where I can upload 1.6 GB video file and i will
do it, thanks!


"It is quite a normal
video downloaded from a public media library"

Link?

Maybe you can reproduce with a cut down by dd version?

free google drive IIRC has 1 gig upload limit, if you really need to 
upload the whole thing you could chop it in two.




On Tue, Jan 31, 2017 at 1:00 PM, Paul B Mahol  wrote:


On 1/31/17, DogFilm  wrote:

Hi,

I have a video here that will make ffmpeg hang and eat all CPU without
doing any actual work and produces a lot of errors. It is quite a normal
video downloaded from a public media library, nothing special.

The error message asks me to upload the file to
ftp://upload.ffmpeg.org/incoming/ and report here about that error.
Unfortunately that ftp server does not seem to exist.

Where should I upload that ffmpeg-killer-video?


Anywhere from where it can be easily downloadable.



Also should I file the missing ftp server as a bug?


Nope.



Thanks for your attention,
have a nice day,
John
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] HTTP: optimize forward seek performance

[Andy Furniss]

Steinar H. Gunderson wrote:

On Thu, Jan 12, 2017 at 04:59:33PM +, Andy Furniss wrote:

I've seen plenty of "legal" shrinks looking at tcpdumps - usually the
app is throttling it's read speed.


You're not really allowed to shrink by more than you've received, though,
are you? Typically the buffer going down is just that the app hasn't read all
the data from the socket -- but that's a different case.


Correct - I was probably being over pedantic about one statement in the
context of buffer sizes.


The point of the “no-shrink” rule is that once you've advertised a window to
the sender, the sender should be allowed to send that much data with no ack,


Yes.


without keeping a copy, and without worrying it might get lost. If you could
shrink the window, that guarantee would disappear.


Not so sure about this bit = when the ack comes it may well inform that
a re-transmit is needed.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] HTTP: optimize forward seek performance

[Andy Furniss]

Joel Cunningham wrote:


According TCP RFCs, a receiver is not allowed to decrease the window,


Not sure that's true.

It's certainly possible to do it illegally, on a linux box tcp will log
a message something like heresy  shrank window.
That IME is where some middle box is "interfearing".

I've seen plenty of "legal" shrinks looking at tcpdumps - usually the
app is throttling it's read speed.

Just had a look between two Linux boxes on my lan and

wget --limit-rate=10k will do to see shrinking advertised window by
receiver using tcpdump.


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] HTTP: optimize forward seek performance

[Andy Furniss]

Joel Cunningham wrote:

Hi,

I’ve been working on optimizing HTTP forward seek performance for ffmpeg and 
would like to contribute this patch into mainline ffmpeg.  Please see the below 
patch for an explanation of the issue and proposed fix.  I have provided 
evidence of the current performance issue and my sample MP4 so others can 
reproduce and observe the behavior.

Files are located in Dropbox here: 
https://www.dropbox.com/sh/4q4ru8isdv22joj/AABU3XyXmgLMiEFqucf1LdZ3a?dl=0

GRMT0003.MP4 - test video file
mac-ffplay-baseline.pcapng - wireshark capture of ffplay (49abd) playing the 
above test file on MacOS 10.12.2 from a remote NGINX server
mac-ffplay-optimize-patch.pcapng - same ffplay setup but with patch applied
ffplay_output.log - console output of ffplay with patch (loglevel debug)

I’m happy to discuss this issue further if the below description doesn’t fully 
communicate the issue.

Thanks,

Joel

 From 89a3ed8aab9168313b4f7e83c00857f9b715ba4e Mon Sep 17 00:00:00 2001
From: Joel Cunningham 
Date: Wed, 11 Jan 2017 13:55:02 -0600
Subject: [PATCH] HTTP: optimize forward seek performance

This commit optimizes HTTP forward seeks by advancing the stream on
the current connection when the seek amount is within the current
TCP window rather than closing the connection and opening a new one.
This improves performance because with TCP flow control, a window's
worth of data is always either in the local socket buffer already or
in-flight from the sender.


Not saying there is anything wrong with this patch but this statement
doesn't seem quite right.

I may be wrong, but IIRC what's in flight + buffer will also depend on
the state of the senders congestion control window.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavfi: Add VAAPI deinterlacer

[Andy Furniss]

Mark Thompson wrote:

On 08/01/17 20:48, Andy Furniss wrote:

Mark Thompson wrote:


To offer a bit more information about this:

It is adding a filter to dinterlace video on the GPU using VAAPI.
This works on both Intel (i965) and AMD (mesa)


Not so sure about the working with AMD/mesa bit. On git it doesn't for
me and I kind of didn't expect it to with the enc needing an env to
disable interlaced buffers to work normally.


VAAPI decode-deinterlace-download works perfectly with the filter for me 
running mesa git on Polaris (I was testing with an older version, but I updated 
and rebuilt just now to check).

With the default settings VAAPI encode is not so good - the encoder runs but 
the output is broken (looks like two separate luma fields and chroma is just 
random).


Yea, that's "normal" output for the encoder without 
VAAPI_DISABLE_INTERLACE=1 now.



With VAAPI_DISABLE_INTERLACE=1 set the first example will produce output
(with -bf 0), but it won't be de-interlaced. With the env 0 I am in
locking vce/gpu territory.


Setting VAAPI_DISABLE_INTERLACE=1 makes the encoder output sensible, but also 
disables the deinterlacer.  (I have to set this normally to make it work.)


Yea when the env was first introduced it was only needed for transcode - 
but then (IIRC) noveau needed some change and now it's always needed.



Everything there succeeds with no errors or hangs, it's just the output that 
isn't as desired.


Maybe the download examples will work - not time to test yet.


Based on my experience, I think they will.  Still helpful if you can check with 
your setup, though :)


Yes, all the download + sw encode examples work, but I notice that I am 
only getting frame rate.

The temporal de-interlacer used via mpv will output field rate.


TBH mesa vaapi temporal de-int had issues from day 1 (vdpau calling
same code doesn't)

It's good this is going in though - I am soon opening a bug about the
"crappiness" of the env (breaks mpv --vo=vaapi) and it adds another case.


Thanks,

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavfi: Add VAAPI deinterlacer

[Andy Furniss]

Mark Thompson wrote:


To offer a bit more information about this:

It is adding a filter to dinterlace video on the GPU using VAAPI.
This works on both Intel (i965) and AMD (mesa)


Not so sure about the working with AMD/mesa bit. On git it doesn't for
me and I kind of didn't expect it to with the enc needing an env to
disable interlaced buffers to work normally.

With VAAPI_DISABLE_INTERLACE=1 set the first example will produce output
(with -bf 0), but it won't be de-interlaced. With the env 0 I am in
locking vce/gpu territory.

Maybe the download examples will work - not time to test yet.


TBH mesa vaapi temporal de-int had issues from day 1 (vdpau calling
same code doesn't)

It's good this is going in though - I am soon opening a bug about the
"crappiness" of the env (breaks mpv --vo=vaapi) and it adds another case.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] lavc/vaapi_encode_h264: fix poc incorrect issue after meeting idr frame.

[Andy Furniss]

Mark Thompson wrote:

On 14/11/16 07:11, Jun Zhao wrote:

V2 : - Change the last_idr_frame filed location based on Mark code review.
  - Modify the commit message to actually explain the problem.

 From a1bf2b021effd36f8297b331855a282d775f2a44 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Fri, 11 Nov 2016 14:53:49 +0800
Subject: [PATCH v2] lavc/vaapi_encode_h264: fix poc incorrect issue after
  meeting idr frame.

when meeting IDR frame, vaapi_encode_h264 poc number don't reset, now fix
this issue based on h264 spec. Some decoder don't care this case, but this
fix will enhance the encoder action. Before this fix, poc number is
negative in some case.

Reviewed-by: Jun Zhao 
Signed-off-by: Wang, Yi A 


Applied as 
.


Oh, nice, and thanks for getting all the other patches in ffmpeg.

On AMD this does fix the negative pocs issue, but there may still be
another, as I mentioned on mesa dev, -g 30 makes an IDR followed by 30
P frames. I assume the IDR should be included in the count?



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavd/xcbgrab: do not try to create refcounted packets.

[Andy Furniss]

Nicolas George wrote:

The framework will allocate a buffer and copy the data to it,
that takes time. But it avoids constently creating and
destroyng the shared memory segment, and that saves more time.

On my setup,
from ~200 to ~300 FPS at full screen (1920×1200),
from ~1400 to ~3300 at smaller size (640×480),
similar to legacy x11grab.


Nice, thanks for doing this.

Beats legacy by a couple of fps on my old CPU and combined
with nv12 conversion makes the difference between being able
to do 1080p60 and not.


Plus, shared memory segments are a scarce resource,
allocating potentially many is a bad idea.

Note: if the application were to drop all references to the
buffer before the next call to av_read_frame(), then passing
the shared memory segment as a refcounted buffer would be
even more efficient, but it is hard to guarantee, and it does
not happen with the ffmpeg command-line tool. Using a small
number of preallocated buffers and resorting to a copy when
the pool is exhausted would be a solution to get the better
of both worlds.


Next 2160p60 :-) only joking, though for those with GPUs that do
shader BGR0 -> 420 CSC I guess it could make a difference - but then
in that case it would be even better if they could avoid  having to
copy over and back all together.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSoC] [PATCH 2/2] mlpenc: Working MLP/TrueHD encoder

[Andy Furniss]

Jai Luthra wrote:

On Sat, Sep 17, 2016 at 05:07:28PM +0100, Andy Furniss wrote:

Nice work, this is just a sort of related question really from a
user who hasn't taken any notice of TrueHD for a few years.

Last I looked I couldn't find much in the way of specs for TrueHD
and noticed that the Decoder didn't have anything related to
dynamic range control.

Is there more info about now?

IIRC testing decoder - (depending on content) for downmix or 2
channel sub stream the absence of DRC was a bit of a show stopper
in that full range can be way too much. The AC3 version of course
did have DRC meta and ffmpeg would correctly fully apply it for
downmix, so for a stereo listener like me AC3 = good, TrueHD (or
DTS) = bad.


The proprietary suite for TrueHD does support dynamic range
compression, but I'm unsure if (and where) the metadata for DRC is
present in the bitstream.

The bitstream isn't fully reversed yet, just enough to get things
working. I think this is a very useful feature for downmixed
substream to sound good, so I'll try to figure it out in my spare
time.


Thanks, it would be really good if the meta could be found even just for
the the decoder. I guess it would be a lot more complex for encode anyway.

I notice we both use the term downmix, maybe that's not quite the right
thing to say WRT substreams. I mean that in the sense that THD
substreams are AIUI the base and the higher channel counts are derived.
Which means the stereo mix can be different from what a downmix would
make. I've got a 7.1 speaker check sample somewhere and the stereo
substream has all the speakers at the same level, which is a nice
feature.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSoC] [PATCH 2/2] mlpenc: Working MLP/TrueHD encoder

[Andy Furniss]

Jai Luthra wrote:

* Multichannel support for TrueHD is experimental

There should be downmix substreams present for 2+ channel
bitstreams, but ffmpeg decoder doesn't need it. Will add support for
this soon.


Nice work, this is just a sort of related question really from a user
who hasn't taken any notice of TrueHD for a few years.

Last I looked I couldn't find much in the way of specs for TrueHD and
noticed that the Decoder didn't have anything related to dynamic range
control.

Is there more info about now?

IIRC testing decoder - (depending on content) for downmix or 2 channel
sub stream the absence of DRC was a bit of a show stopper in that full
range can be way too much. The AC3 version of course did have DRC meta
and ffmpeg would correctly fully apply it for downmix, so for a stereo
listener like me AC3 = good, TrueHD (or DTS) = bad.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Andy Furniss]

Andy Furniss wrote:


I do know that I have really grabbed and encoded 1080p60 with my AMD
h/w and including nv12 conversion gives a sane looking result -

gst-launch-1.0 -f ximagesrc use-damage=0 startx=0 starty=0 endx=1919
 endy=1079 num-buffers=1000 ! queue ! videoconvert !
video/x-raw,framerate=100/1,format=NV12  ! fakesink Setting pipeline
to PAUSED ... Pipeline is live and does not need PREROLL ... Setting
pipeline to PLAYING ... New clock: GstSystemClock Got EOS from
element "pipeline0". Execution ended after 0:00:14.419928745 Setting
pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline
to NULL ... Freeing pipeline ...

1000/14.419928745 = 69.3


Over the weekend I looked at the CSC aspect of this without using
x11grab = benching bgr0 on tmpfs to nv12 and managed with a bit of luck
to get ffmpeg to beat gstreamer.

Starting point gstreamer bgr0 to nv12 = 70fps, to I420 68fps.

ffmpeg benched using -f null as -f rawvideo to ram or /dev/null is
slower and I suspect/hope for my intended usage = vaapi upload -f null
will be more representative, but of course I don't know that.

ffmpeg -f rawvideo -s 1920x1080 -pix_fmt bgr0  -i /mnt/ramdisk/out.bgr0 
-pix_fmt nv12 -f null -


=41 fps, yuv420p = 66fps

So yuv420p is close to gstreamer but nv12 is poor.

By chance I wondered how much worse it would be if I used -sws_flags as
I have done in the past. Result it was faster, it turns out that
+full_chroma_inp takes yuv420p from 66 to 84fps and nv12 to 47fps.

The reason being that with no flags time is spent in bgr32toUV_half_c
with flag above I don't use that and see various sse in use like
ff_rgbatoUV_sse2.

nv12 is still too slow though. Looking with sysprof I see that time
is spent in yuv2nv12cX_c.

Seemed slow when remembering yuv420p -> nv12 conversions from the past
so I benched 1080p yuv420p -> nv12 and got > 500fps. Doing this didn't
use yuv2nv12cX_c at all so I got to make a new command line -

ffmpeg -f rawvideo -s 1920x1080 -pix_fmt bgr0  -i /mnt/ramdisk/out.bgr0 
-vf scale=flags=+full_chroma_inp,format=yuv420p,format=nv12 -f null -


= 78fps, nice.

So at least I can beat gstreamer on CSC now. Testing the new commandline
with x11grab gets me close to gst using the legacy x11grab = 65 fps.

libxcb x11grab is 52 fps though, so it would be good if that can be 
fixed up.





___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Andy Furniss]

Andy Furniss wrote:

Nicolas George wrote:



I had an inkling that it was about the packet -> frame conversion,
but it seems rawdec does the right thing in this particular case.
Still, I suggest you add a quick debug av_log() in
libavcodec/rawdec.c to check that need_copy is false.


I shall have go later this evening.


I did as below and for both -f null - and -f rawvideo -y /dev/null it 
says false.


diff --git a/libavcodec/rawdec.c b/libavcodec/rawdec.c
index 1259577..28a8fd0 100644
--- a/libavcodec/rawdec.c
+++ b/libavcodec/rawdec.c
@@ -248,10 +248,13 @@ static int raw_decode(AVCodecContext *avctx, void 
*data, int *got_frame,
 if ((res = av_image_check_size(avctx->width, avctx->height, 0, 
avctx)) < 0)

 return res;

-if (need_copy)
+if (need_copy) {
 frame->buf[0] = av_buffer_alloc(FFMAX(context->frame_size, 
buf_size));

-else
+av_log(NULL, AV_LOG_ERROR, "ADF need_copy = true\n");
+} else {
 frame->buf[0] = av_buffer_ref(avpkt->buf);
+av_log(NULL, AV_LOG_ERROR, "ADF need_copy = false\n");
+}
 if (!frame->buf[0])
 return AVERROR(ENOMEM);

@@ -341,6 +344,7 @@ static int raw_decode(AVCodecContext *avctx, void 
*data, int *got_frame,


 buf = dst;
 } else if (need_copy) {
+av_log(NULL, AV_LOG_ERROR, "ADF need_copy2 = true\n");
 memcpy(frame->buf[0]->data, buf, buf_size);
 buf = frame->buf[0]->data;
 }


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Andy Furniss]

Sven C. Dack wrote:


I'd be more interested in grabbing the desktop synchronous to the
display refresh rate at this point. 60Hz is a key mark, going above
it not so much. What would be the next mark anyway? 100Hz?


That would be good - I am in a different situation to you though, in
that my h/w won't currently take RGB anyway. Benching bgr0 is just a
starting point. With nv12 conversion I can't do 60fps with ffmpeg but
can with gstreamer.

As for monitors  - there are plenty that do 144Hz marketed at gamers and
even at 60Hz there's increasing use of 1440p and 2160p screens to consider.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Andy Furniss]

Nicolas George wrote:

Le quintidi 25 fructidor, an CCXXIV, Andy Furniss a écrit :

Looking into this more with sysprof it seems with this test
gstreamer is twice as fast because it doesn't copy from shm but
ffmpeg does.

Of course I may be misunderstanding, but >90% load according to
sysprof is __memcpy_sse2_unaligned.


Can you detect what call to memcpy() in the ffmpeg code is
responsible for this?


Not with sysprof unfortunately.


I had an inkling that it was about the packet -> frame conversion,
but it seems rawdec does the right thing in this particular case.
Still, I suggest you add a quick debug av_log() in
libavcodec/rawdec.c to check that need_copy is false.


I shall have go later this evening.


Also, did you have a look at my last mail on the topic:
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/199156.html
about the speed difference between xcb and xlib?


I did and thanks for taking an interest - as I don't really know much
about the code I thought that one was more for Carl Eugen :-)

But yes I get the version I am currently testing is unsafe - just it
seems to be more like gstreamer in using XShmGetImage so I thought the
sysprofs would be easier to compare.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Andy Furniss]

Andy Furniss wrote:


With gstreamer 1080p I can get around 350 fps testing like -

gst-launch-1.0 -f ximagesrc use-damage=0 startx=0 starty=0 endx=1919
 endy=1079 num-buffers=5000 ! queue ! videoconvert !
video/x-raw,framerate=500/1,format=BGRx ! fakesink Setting pipeline
to PAUSED ... Pipeline is live and does not need PREROLL ... Setting
pipeline to PLAYING ... New clock: GstSystemClock Got EOS from
element "pipeline0". Execution ended after 0:00:14.205120141 Setting
pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline
to NULL ... Freeing pipeline ...

5000/14.205120141 = 351.98

Of course I don't know if that's "real" as such.


Looking into this more with sysprof it seems with this test gstreamer is
twice as fast because it doesn't copy from shm but ffmpeg does.

Of course I may be misunderstanding, but >90% load according to sysprof
is __memcpy_sse2_unaligned.

ffmpeg is not using xcb for this test and like this both ffmpeg and
gstreamer are using XShmGetImage.

With gstreamer all calls to __memcpy_sse2_unaligned are from X
with ffmpeg half are from X and half ffmpeg.

OK I think, maybe the test was flawed, so I changed fakesink to filesink
location=/mnt/ramdisk/out.bgr0 where ramdisk is tmpfs. Sure enough it's
slower = 188fps which is more like ffmpeg (179 fps with -f null -).

Unfortunately if I force ffmpeg to really output to tmpfs using
-f rawvideo -y /mnt/ramdisk/out.bgr0 I only get 68fps so I am still slower.

FWIW -f rawvideo -y /dev/null gives 90fps.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Andy Furniss]

Sven C. Dack wrote:

On 08/09/16 15:17, Andy Furniss wrote:

Carl Eugen Hoyos wrote:

2016-09-08 12:01 GMT+02:00 Andy Furniss <adf.li...@gmail.com>:


I don't know what it is about x11grab/CSC with ffmpeg, but
on my old CPU gstreamer is twice as fast.


x11grab or xcb?


I guess xcb as I don't --enable anything related with configure.


In case it got mistaken...

The following is what gives the 100 fp/s (with a GTX 960):
$ ffmpeg -f x11grab -framerate 200 -s hd1080 -i :0.0 -c:v hevc_nvenc -y
test.mkv

The mentioned 100 fp/s refers to the HEVS/H.265 hardware encoder
(nvenc). X11grab is here only the input device.

Without the encoder does it give me 160 fp/s:
$ ffmpeg -f x11grab -s hd1080 -framerate 500 -i :0.0 -f null -

Different sizes then give different results:

- For hd720 is it 200 fp/s (with nvenc) and 420 fp/s (without nvenc).
- For hd480 is it 460 fp/s (with nvenc) and 890 fp/s (without nvenc).

Can you compare gstreamer to those numbers?


With gstreamer 1080p I can get around 350 fps testing like -

gst-launch-1.0 -f ximagesrc use-damage=0 startx=0 starty=0 endx=1919 
endy=1079 num-buffers=5000 ! queue ! videoconvert ! 
video/x-raw,framerate=500/1,format=BGRx ! fakesink

Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:14.205120141
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

5000/14.205120141 = 351.98

Of course I don't know if that's "real" as such.

I do know that I have really grabbed and encoded 1080p60 with my AMD h/w
and including nv12 conversion gives a sane looking result -

gst-launch-1.0 -f ximagesrc use-damage=0 startx=0 starty=0 endx=1919 
endy=1079 num-buffers=1000 ! queue ! videoconvert ! 
video/x-raw,framerate=100/1,format=NV12  ! fakesink

Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:14.419928745
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

1000/14.419928745 = 69.3

I also tried (fake) 2160p and got around 90fps BGRx and 17 nv12.

My PC is old = Phenom II x4 965 3.4GHz Cpus, 1333 ram.


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Andy Furniss]

Carl Eugen Hoyos wrote:

2016-09-08 19:16 GMT+02:00 Andy Furniss <adf.li...@gmail.com>:


It is a bit faster


xcb is slower?


Yes (unless I am mixing things up)

--disable-libxcb --enable-x11grab is faster than autodetect

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Andy Furniss]

Carl Eugen Hoyos wrote:

2016-09-08 16:17 GMT+02:00 Andy Furniss <adf.li...@gmail.com>:

Carl Eugen Hoyos wrote:


2016-09-08 12:01 GMT+02:00 Andy Furniss <adf.li...@gmail.com>:


I don't know what it is about x11grab/CSC with ffmpeg, but
on my old CPU gstreamer is twice as fast.


x11grab or xcb?


I guess xcb as I don't --enable anything related with configure.


Then please test if this is a regression over x11grab, use:
configure --disable-libxcb --enable-x11grab --enable-gpl

(It is very likely that nobody ever tested.)


It is a bit faster, comparing results I posted on users to new build -

(vsync 2 for consistency as that's how the old tests were done
it isn't really needed/makes no difference for -f null but was used
as I previously also tested -f rawvideo -y /dev/null and when
using -framerate with that it is essential).

xcb -> x11grab.

ffmpeg -vsync 2 -framerate 200 -f x11grab -s 1920x1080 -i :0.0 -vframes 
1000 -f null -


138 -> 179 fps

ffmpeg -vsync 2 -framerate 200 -f x11grab -s 1920x1080 -i :0.0 -vframes 
1000 -pix_fmt yuv420p -f null -


47 -> 56 fps

ffmpeg -vsync 2 -framerate 200 -f x11grab -s 1920x1080 -i :0.0 -vframes 
1000 -pix_fmt nv12 -f null -


33 -> 37 fps



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Andy Furniss]

Carl Eugen Hoyos wrote:

2016-09-08 12:01 GMT+02:00 Andy Furniss <adf.li...@gmail.com>:


I don't know what it is about x11grab/CSC with ffmpeg, but
on my old CPU gstreamer is twice as fast.


x11grab or xcb?


I guess xcb as I don't --enable anything related with configure.


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Andy Furniss]

Sven C. Dack wrote:


It is not an issue. x11grab produces BGR0 and nvenc can handle it
with the patch. It's giving me 100fp/s (up from 47fp/s) with a
1920x1080 monitor. I'd imagine people with 4K displays will be happy,
too, although they will have to live with lower speeds of perhaps 30
fp/s. Would be interesting to know how it performs on 4K though.


Maybe

xrandr --output   --fb 3840x2160 --panning 3840x2160

I don't know what it is about x11grab/CSC with ffmpeg, but on my
old CPU gstreamer is twice as fast.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Performance of P010LE/BE pixel convertion

[Andy Furniss]

Ali KIZIL wrote:


frame=  603 fps= 41 q=-0.0 Lsize=14654712kB time=00:00:10.30


Random thoughts from benching ffmpeg but not with nvenc.

For short tests fps may read low as (IME) it takes time converge with
reality.

Maybe use time ffmpeg   as a double check.

-f null on my old box is faster than -y /dev/null.

Slight chance forcing CPUs to perf will do better than cpufreq on_demand.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

[Andy Furniss]

Davinder Singh wrote:

On Tue, Aug 23, 2016 at 5:38 AM Andy Furniss <adf.li...@gmail.com>
wrote:


[...]

Nice I can see the edges are better than the last version.

The doc/filters.texi hunk doesn't apply to git master.

I was going to post some comparisons with mcfps tonight, but I'll
need to redo them to see what's changed.


I am testing with a somewhat artificial sample in that it's a framerate
de-interlace + scale down of a 1080i master, though it is "real" in the
sense that I may want to repair similar files where people have produced
a juddery mess by using yadif=0.

It's very fast and my old (2010 Panasonic plasma) TV can't interpolate
it without artifacting in a few places, it can interpolate a field rate
version flawlessly and both mcfps and minterpolate do a lot better with
a 50fps master version -> 100fps, though they are still not perfect.

As well as being fast it has overlays of varying opacity and some
repeating patterns just to make things even harder.

Some observations while trying to get the best result - given the number
of options only a small subset could be tested:

aobmc vs ombc, vsbmc 0 or 1 = no real difference.

Any me method other than epzs had far too many artifacts to be used.

Raising search_param to 48 or 64 or 128 just causes new artifacts.

Reducing mb_size causes new artifacts.

bilat vs bidir - similar but bilat has some artifacts on a still shot
near the end of the defaults sample uploaded. bidir sometimes has green
near the top of the screen.

There are of course many small artifacts, to be seen by slowmo/framestep
for both minterpolate and mcfps. Viewing fullspeed mcfps artifacts less
on the car when it touches the edges than minterpolate. Frame stepping
shows mcfps doesn't blend/blur as much on really fast moving background
as minterpolate does.

Included in the link below (which is a tar to stop google drive making
terrible low quality/fps previews) are the 25fps master file, mcfps
interpolation to 50fps, minterpolate with default options and
minterpolate with defaults + bidir.

https://drive.google.com/file/d/0BxP5-S1t9VEEM2VrTzlVdGZURVk/view?usp=sharing
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSoC] Motion Interpolation

[Andy Furniss]

Davinder Singh wrote:

On Wed, Jun 1, 2016 at 4:13 AM Davinder Singh  wrote:


[...]



final patch attached. please review.

this includes bug fixes and various other improvements. also added filter
docs.


Nice I can see the edges are better than the last version.

The doc/filters.texi hunk doesn't apply to git master.

I was going to post some comparisons with mcfps tonight, but I'll need 
to redo them to see what's changed.



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] h264_qsv decoder speed

[Andy Furniss]

Mark Thompson wrote:

On 17/08/16 20:47, Chao Liu wrote:

Hi there,
I compared h264_qsv decoder from ffmpeg to intel media sdk sample_decode.
There is pretty big speed gap. I wonder whether I did sth. wrong or there
are really some problems with ffmpeg's implementation..

The test video was captured from a 3MP(2048x1536) camera. The commands I
used:
-  ffmpeg -c:v h264_qsv -async_depth 10 -i test.h264 -c:v rawvideo -f null
/dev/null
-  sample_decode h264 -i test.h264
Both uses 100% cpu (a full core). ffmpeg got 170FPS. sample_decode got
370FPS.

I haven't got time debugging into this. Sending this out to see whether you
guys might have sth. in mind..


I think in both cases your speed bound must be on something other than the 
decode, because the hardware goes a lot faster than either of those for me.  
Perhaps you are downloading the all of the output frames to normal memory in 
order to write them to a null device output, and one of the cases is doing that 
less efficiently somehow?


Only tested with AMD UVD, but unless you use -pix_fmt nv12 you will also 
get cpu load from ffmpeg doing nv12 -> yuv420p conversion.




Using vaapi on a low-power Haswell mobile chip (i.e. the same Quick Sync 
hardware that libmfx uses) decodes a single 2048x1536 stream at around 800fps 
with less than 50% CPU for me.

- Mark


(My command to compare is:

./ffmpeg_g -vaapi_device /dev/dri/renderD128 -hwaccel vaapi 
-hwaccel_output_format vaapi -i input.mp4 -an -vf 'format=nv12|vaapi,hwupload' 
-f null -


Oh nice, I always wondered if there was a way to bench without copy back.



The nasty filtering there is contrived to do nothing, even with the inconvenient stream 
reinitialisation.  I think libmfx might also work somehow with "-c:v h264_qsv 
-hwaccel qsv", but I'm not sure and I don't have anything to try it on right now.)


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] ffmpeg_vdpau: Re-add ability to ignore level check

[Andy Furniss]

Michael Niedermayer wrote:

On Tue, Jun 07, 2016 at 07:51:18PM +0100, Mark Thompson wrote:

Fixes ticket 5286.

Uses the global -hwaccel_lax_profile_check option (may be misnamed
for this purpose, but it has the right spirit).
---
Only compile tested (no hardware).

Maybe -hwaccel_lax_profile_check should be renamed to something a bit more 
general - it was named for the specific VAAPI case, but this is really the same 
type of issue.  (-hwaccel_ignore_capabilities or something like that?)

  ffmpeg_vdpau.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)


is anyone against applying this ?


From the POV of a user I still think as noted in trac -

https://trac.ffmpeg.org/ticket/5286

That it would be better if ffmpeg didn't silently fall back to s/w dec
without saying so. Which could include ... use -hwaccel_lax_profile_check
to override.


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avfilter/vf_bwdif: add x86 SIMD

[Andy Furniss]

Thomas Mundt wrote:

This new patch adds x86 SIMD support up to 12 bit. Please comment.


Not much use I guess, but on sse2 8 bit content it tests OK = faster +
md5sum the same as without the patch.

Are you considering going further with this?

Being sharper than yadif/preserving weave is nice, but for some SD
(viewing scaled up) yadif wins on moving low angle diagonals, which end
up stepped.

From memory when testing intel h/w deint it did a nice motion adaptive
deint of the same scene without steps. The possible difference being 
that its "bob"

also did some sort of edge detection/interpolation.

https://drive.google.com/file/d/0BxP5-S1t9VEEUUR0QnVYRU8yczQ/view?usp=sharing

the scene in question, bwdif jaggies the cue when at a shallow angle.

The algorithm used by the h/w I tested. p259

https://01.org/sites/default/files/documentation/intel_os_gfx_prm_vol7_-_3d-media-gpgpu_0.pdf
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Motion interpolation in libavfilter

[Andy Furniss]

compn wrote:

On Tue, 8 Mar 2016 09:26:22 +0100
Paul B Mahol  wrote:


On 3/8/16, Subhashish Pradhan  wrote:

Hello,

I am Subhashish Pradhan, a CS undergrad from India. I want to take
up the project "Motion interpolation in libavfilter" for GSoC 2016
and I'd like to understand the goals for this project.


Goals are already written on wiki, if you have more specific
questions ask them.


the goals on the wiki for motion interpolation in libavfilter are here:
https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016#Motioninterpolationinlibavfilter


"Expected results: State of the art frame interpolation in the 
libavfilter" !!!


So what's considered state of the art in 2016?

It's years ago, but I've read of some pretty complicated methods for 
doing this.


Maybe random old PHD papers like below are misleading but what is 
someone expected to do in a summer?


http://www.blivdatalog.dk/forskning/Publikationer/tekniske_rapporter/2007/07-03.pdf

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add nnedi filter

[Andy Furniss]

Paul B Mahol wrote:

On 1/30/16, Andy Furniss <adf.li...@gmail.com> wrote:

Paul B Mahol wrote:

Hi,

3rd version attached!


It seems that now bff/tff flags on input are correctly followed
and output is good, but it can't be overridden by field=bf or
field=tf both give correct output.

For raw video though, they are honored and are still the wrong way
round.


Could you test attached patch?

Apply on top of last one.


This seems good - tested af bf and tf all work as expected.

You're going to hate me though, because I've noticed something else.

It seems to affect all versions of the patch with fields - only fields
affected, framerate output is the same length as input.

There is a frame missing somewhere (haven't had time to look if it's
first or last).

Testing with y4m input and output I noticed by chance that yadif=1 is a
frame larger (file size).

with ffprobe it seems yadif=1 is correct in the sense that -

ffprobe -show_frames in.y4m | grep "\[FRAME" | wc -l

339

ffprobe -show_frames out-yadif1.y4m | grep "\[FRAME" | wc -l

678

ffprobe -show_frames out-nnedi.y4m | grep "\[FRAME" | wc -l

677

The "frame= xxx" command line output also shows the difference.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add nnedi filter

[Andy Furniss]

Paul B Mahol wrote:

On 1/30/16, Andy Furniss <adf.li...@gmail.com> wrote:

Paul B Mahol wrote:

On 1/30/16, Andy Furniss <adf.li...@gmail.com> wrote:

Paul B Mahol wrote:

Hi,

3rd version attached!


It seems that now bff/tff flags on input are correctly followed
and output is good, but it can't be overridden by field=bf or
field=tf both give correct output.

For raw video though, they are honored and are still the wrong way
round.


Could you test attached patch?

Apply on top of last one.


This seems good - tested af bf and tf all work as expected.

You're going to hate me though, because I've noticed something else.


Better any fedback, then none.



It seems to affect all versions of the patch with fields - only fields
affected, framerate output is the same length as input.

There is a frame missing somewhere (haven't had time to look if it's
first or last).


Last one.



Testing with y4m input and output I noticed by chance that yadif=1 is a
frame larger (file size).

with ffprobe it seems yadif=1 is correct in the sense that -

ffprobe -show_frames in.y4m | grep "\[FRAME" | wc -l

339

ffprobe -show_frames out-yadif1.y4m | grep "\[FRAME" | wc -l

678

ffprobe -show_frames out-nnedi.y4m | grep "\[FRAME" | wc -l

677

The "frame= xxx" command line output also shows the difference.


Should be fixed in 4th version attached.


Yes, v4 looks good to me.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add nnedi filter

[Andy Furniss]

Paul B Mahol wrote:

Hi,

3rd version attached!


It seems that now bff/tff flags on input are correctly followed and
output is good, but it can't be overridden by field=bf or field=tf both
give correct output.

For raw video though, they are honored and are still the wrong way round.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add nnedi filter

[Andy Furniss]

Paul B Mahol wrote:

Hi,

2nd version attached.


Nice - fields support :-)

I think bf and tf are the wrong way round.

ie. ffmpeg -i something-tff -vf nnedi  :field=tf gives wrong output 
on same file field=bf looks correct.


idet confirms input is tff (which I knew anyway)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add nnedi filter

[Andy Furniss]

Paul B Mahol wrote:

On 1/24/16, Andy Furniss <adf.li...@gmail.com> wrote:

Michael Niedermayer wrote:

On Sat, Jan 23, 2016 at 07:53:59PM +0100, Paul B Mahol wrote:

Hi,

patch attached.



configure|1 libavfilter/Makefile |
1 libavfilter/allfilters.c |1 libavfilter/vf_nnedi.c   |
939 +++ 4 files
changed, 942 insertions(+)
fd0161c6e14c0f39f4fc344c1737713691a13f1d
0001-avfilter-add-nnedi-filter.patch From
a41c741bb4d3146661e629552d750638a0bdc87c Mon Sep 17 00:00:00
2001 From: Paul B Mahol <one...@gmail.com> Date: Sat, 23 Jan
2016 17:15:53 +0100 Subject: [PATCH] avfilter: add nnedi
filter

Port of nnedi3 vapoursynth filter.


nice


Agree - but there's apparently no field parameter + will the
required bin file be included?


I forgot field parameter and other things.

No, bin file will not be included, it is few megabytes.


OK, so maybe (if easily possible) it would be more user friendly to
mention it when it errors out due to not having one. I know it's named
in help - just a thought.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH][RFC] avcodec: disallow hwaccel with frame threads

[Andy Furniss]

wm4 wrote:

On Wed, 20 Jan 2016 00:42:18 + Andy Furniss <adf.li...@gmail.com>
wrote:


Hendrik Leppkes wrote:


I do not agree that it should be a warning. As outlined in
the commit message and this thread, there are serious flaws
with frame threading and hwaccel.


I'm fine with it being an error, but since it is an API change,
it should follow the usual deprecation period to allow
downstream users time to fix it. Meanwhile it can be a warning
so that people notice the problem.


Its fundamentally broken, and making it a warning would
re-introduce known crashes. So no.


So are the flaws in ffmpeg or particular drivers?

It does seem a shame perf wise, I've been testing my AMD UVD
decode recently and for 500 UHD frames in a really high bitrate
h264 file it's like -

ffmpeg threaded = 16 sec.

ffmpeg single thread = 20 sec.


With or without hwaccel?


Both are with hwaccel. ffmpeg 2.8.4 cli

Admittedly a very concocted benchmark with a very high bitrate sample.

I know on normal x264 stuff my CPU could beat GPU anyway as the copy
back seems to hurt quite a lot/UVD is for playing.

For future GPUs that will do hevc I guess it could be more relevant.


gstreamer vaapi 14 sec.

gstreamer omx 10 sec.

the omx is a faster as the others do nv12 -> I420 on cpu (AFAICT)

Maybe -threads 1 hurts perf by limiting the format conversion as
well?

Is there a way to get whatever the h/w spits out (nv12) directly?
Trying to ask for nv12 seemed to get a double conversion.


Both vdpau and vaapi can retrieve image data as nv12.


With ffmpeg cli?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH][RFC] avcodec: disallow hwaccel with frame threads

[Andy Furniss]

wm4 wrote:

On Wed, 20 Jan 2016 09:59:12 + Andy Furniss <adf.li...@gmail.com>
wrote:


wm4 wrote:

On Wed, 20 Jan 2016 00:42:18 +0000 Andy Furniss
<adf.li...@gmail.com> wrote:


Hendrik Leppkes wrote:


I do not agree that it should be a warning. As outlined
in the commit message and this thread, there are serious
flaws with frame threading and hwaccel.


I'm fine with it being an error, but since it is an API
change, it should follow the usual deprecation period to
allow downstream users time to fix it. Meanwhile it can be
a warning so that people notice the problem.


Its fundamentally broken, and making it a warning would
re-introduce known crashes. So no.


So are the flaws in ffmpeg or particular drivers?

It does seem a shame perf wise, I've been testing my AMD UVD
decode recently and for 500 UHD frames in a really high
bitrate h264 file it's like -

ffmpeg threaded = 16 sec.

ffmpeg single thread = 20 sec.


With or without hwaccel?


Both are with hwaccel. ffmpeg 2.8.4 cli

Admittedly a very concocted benchmark with a very high bitrate
sample.

I know on normal x264 stuff my CPU could beat GPU anyway as the
copy back seems to hurt quite a lot/UVD is for playing.

For future GPUs that will do hevc I guess it could be more
relevant.


gstreamer vaapi 14 sec.

gstreamer omx 10 sec.

the omx is a faster as the others do nv12 -> I420 on cpu
(AFAICT)

Maybe -threads 1 hurts perf by limiting the format conversion
as well?

Is there a way to get whatever the h/w spits out (nv12)
directly? Trying to ask for nv12 seemed to get a double
conversion.


Both vdpau and vaapi can retrieve image data as nv12.


With ffmpeg cli?


ffmpeg cli doesn't support vaapi.


I know, but it does do vdpau: so to restate my question in a clearer way -

Is it possible with ffmpeg cli -hwaccel vdpau to avoid nv12 -> I420
conversion?


With what hardware was this? What were the command lines you used?


GPU is AMD R9285 TONGA (drivers are still new/experemental) but results
for this test seem consistent.

Rest of system is older Phenom II x4 3.4GHz (cpufreq forced for tests).
Mobo is PCIE 2.0 *Gig ram @ 1333.

Here's a paste I made a few days ago - includes s/w test (which by
chance for this sample comes out the same as multithread h/w) You can
see from the time cpu use output I really do get h/w decode as requested.

andy [vce-tests]$ time ffmpeg -hwaccel vdpau -i 
/mnt/ramdisk/x264-otc-2160p60-220M.mkv -f rawvideo /mnt/ramdisk/raw

ffmpeg version 2.8.4 Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 5.3.0 (GCC)
  configuration: --prefix=/usr --enable-gpl --enable-version3 
--enable-nonfree --disable-static --enable-shared --disable-debug 
--enable-libass --enable-libfdk-aac --enable-libfreetype 
--enable-libmp3lame --enable-libopus --enable-libtheora 
--enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 
--enable-x11grab --docdir=/usr/share/doc/ffmpeg-2.8.4

  libavutil  54. 31.100 / 54. 31.100
  libavcodec 56. 60.100 / 56. 60.100
  libavformat56. 40.101 / 56. 40.101
  libavdevice56.  4.100 / 56.  4.100
  libavfilter 5. 40.101 /  5. 40.101
  libswscale  3.  1.101 /  3.  1.101
  libswresample   1.  2.101 /  1.  2.101
  libpostproc53.  3.100 / 53.  3.100
Input #0, matroska,webm, from '/mnt/ramdisk/x264-otc-2160p60-220M.mkv':
  Metadata:
ENCODER : Lavf57.19.100
  Duration: 00:00:08.33, start: 0.00, bitrate: 218593 kb/s
Stream #0:0: Video: h264 (High), yuv420p, 3840x2160 [SAR 1:1 DAR 
16:9], 60 fps, 60 tbr, 1k tbn, 120 tbc (default)

Metadata:
  ENCODER : Lavc57.16.101 libx264
  DURATION: 00:00:08.33400
Output #0, rawvideo, to '/mnt/ramdisk/raw':
  Metadata:
encoder : Lavf56.40.101
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 
3840x2160 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 60 fps, 60 tbn, 60 tbc 
(default)

Metadata:
  DURATION: 00:00:08.33400
  encoder : Lavc56.60.100 rawvideo
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> rawvideo (native))
Press [q] to stop, [?] for help
frame=  500 fps= 30 q=-0.0 Lsize= 6075000kB time=00:00:08.33 
bitrate=5971968.2kbits/s
video:6075000kB audio:0kB subtitle:0kB other streams:0kB global 
headers:0kB muxing overhead: 0.00%


real0m16.958s
user0m7.333s
sys 0m3.062s
andy [vce-tests]$ rm /mnt/ramdisk/raw
andy [vce-tests]$
andy [vce-tests]$
andy [vce-tests]$
andy [vce-tests]$ time ffmpeg -threads 1 -hwaccel vdpau -i 
/mnt/ramdisk/x264-otc-2160p60-220M.mkv -f rawvideo /mnt/ramdisk/raw

ffmpeg version 2.8.4 Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 5.3.0 (GCC)
  configuration: --prefix=/usr --enable-gpl --enable-version3 
--enable-nonfree --disable-static --enable-shared --disable-debug 
--enable-libass --enable-libfdk-aac --enable-libfreetype 
--enable-libmp3lame --enable-libopus --enable-libtheora 
--enable-libvorbis --enable-libvpx --enable-libx264 --

Re: [FFmpeg-devel] [PATCH][RFC] avcodec: disallow hwaccel with frame threads

[Andy Furniss]

Hendrik Leppkes wrote:

On Wed, Jan 20, 2016 at 12:13 PM, Andy Furniss <adf.li...@gmail.com> wrote:

wm4 wrote:


On Wed, 20 Jan 2016 09:59:12 +0000 Andy Furniss <adf.li...@gmail.com>
wrote:


wm4 wrote:


On Wed, 20 Jan 2016 00:42:18 + Andy Furniss
<adf.li...@gmail.com> wrote:


Hendrik Leppkes wrote:


I do not agree that it should be a warning. As outlined
in the commit message and this thread, there are serious
flaws with frame threading and hwaccel.



I'm fine with it being an error, but since it is an API
change, it should follow the usual deprecation period to
allow downstream users time to fix it. Meanwhile it can be
a warning so that people notice the problem.



Its fundamentally broken, and making it a warning would
re-introduce known crashes. So no.



So are the flaws in ffmpeg or particular drivers?

It does seem a shame perf wise, I've been testing my AMD UVD
decode recently and for 500 UHD frames in a really high
bitrate h264 file it's like -

ffmpeg threaded = 16 sec.

ffmpeg single thread = 20 sec.



With or without hwaccel?



Both are with hwaccel. ffmpeg 2.8.4 cli

Admittedly a very concocted benchmark with a very high bitrate
sample.

I know on normal x264 stuff my CPU could beat GPU anyway as the
copy back seems to hurt quite a lot/UVD is for playing.

For future GPUs that will do hevc I guess it could be more
relevant.


gstreamer vaapi 14 sec.

gstreamer omx 10 sec.

the omx is a faster as the others do nv12 -> I420 on cpu
(AFAICT)

Maybe -threads 1 hurts perf by limiting the format conversion
as well?

Is there a way to get whatever the h/w spits out (nv12)
directly? Trying to ask for nv12 seemed to get a double
conversion.



Both vdpau and vaapi can retrieve image data as nv12.



With ffmpeg cli?



ffmpeg cli doesn't support vaapi.



I know, but it does do vdpau: so to restate my question in a clearer way -

Is it possible with ffmpeg cli -hwaccel vdpau to avoid nv12 -> I420
conversion?


With what hardware was this? What were the command lines you used?



GPU is AMD R9285 TONGA (drivers are still new/experemental) but results
for this test seem consistent.

Rest of system is older Phenom II x4 3.4GHz (cpufreq forced for tests).
Mobo is PCIE 2.0 *Gig ram @ 1333.

Here's a paste I made a few days ago - includes s/w test (which by
chance for this sample comes out the same as multithread h/w) You can
see from the time cpu use output I really do get h/w decode as requested.


If you would run with verbose logging (-loglevel verbose), you would
get information which format the vdpau code uses to retrieve the data,
as well as clear confirmation that it uses hwaccel.


Thanks, I don't see input format, but I guess the graph 0 ... line is
saying that something is being converted to yuv420p.

So back to one of my questions - how to avoid this?

If I specify -pix_fmt nv12 I just get a double conversion.

ffmpeg -loglevel verbose -threads 1 -hwaccel vdpau -i 
/mnt/ramdisk/x264-otc-2160p60-220M.mkv -f rawvideo /mnt/ramdisk/raw


ffmpeg version N-77817-gd3fe2e0 Copyright (c) 2000-2016 the FFmpeg 
developers

  built with gcc 5.3.0 (GCC)
  configuration: --prefix=/usr --disable-doc --enable-gpl 
--enable-libvpx --enable-libx265 --enable-libdcadec --enable-libmp3lame 
--enable-libx264

  libavutil  55. 13.100 / 55. 13.100
  libavcodec 57. 22.100 / 57. 22.100
  libavformat57. 21.101 / 57. 21.101
  libavdevice57.  0.100 / 57.  0.100
  libavfilter 6. 23.100 /  6. 23.100
  libswscale  4.  0.100 /  4.  0.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc54.  0.100 / 54.  0.100
Input #0, matroska,webm, from '/mnt/ramdisk/x264-otc-2160p60-220M.mkv':
  Metadata:
ENCODER : Lavf57.19.100
  Duration: 00:00:08.33, start: 0.00, bitrate: 218593 kb/s
Stream #0:0: Video: h264 (High), 5 reference frames, yuv420p, 
3840x2160 [SAR 1:1 DAR 16:9], 60 fps, 60 tbr, 1k tbn, 120 tbc (default)

Metadata:
  ENCODER : Lavc57.16.101 libx264
  DURATION: 00:00:08.33400
[graph 0 input from stream 0:0 @ 0x347b100] w:3840 h:2160 pixfmt:yuv420p 
tb:1/1000 fr:60/1 sar:1/1 sws_param:flags=2

Output #0, rawvideo, to '/mnt/ramdisk/raw':
  Metadata:
encoder : Lavf57.21.101
Stream #0:0: Video: rawvideo, 1 reference frame (I420 / 
0x30323449), yuv420p, 3840x2160 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 60 
fps, 60 tbn, 60 tbc (default)

Metadata:
  DURATION: 00:00:08.33400
  encoder : Lavc57.22.100 rawvideo
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> rawvideo (native))
Press [q] to stop, [?] for help
Using VDPAU -- G3DVL VDPAU Driver Shared Library version 1.0 -- on X11 
display :0.0, to decode input stream #0:0.



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH][RFC] avcodec: disallow hwaccel with frame threads

[Andy Furniss]

Hendrik Leppkes wrote:


I do not agree that it should be a warning. As outlined in the
commit message and this thread, there are serious flaws with
frame threading and hwaccel.


I'm fine with it being an error, but since it is an API change, it
should follow the usual deprecation period to allow downstream
users time to fix it. Meanwhile it can be a warning so that people
notice the problem.


Its fundamentally broken, and making it a warning would re-introduce
known crashes. So no.


So are the flaws in ffmpeg or particular drivers?

It does seem a shame perf wise, I've been testing my AMD UVD decode
recently and for 500 UHD frames in a really high bitrate h264 file it's
like -

ffmpeg threaded = 16 sec.

ffmpeg single thread = 20 sec.

gstreamer vaapi 14 sec.

gstreamer omx 10 sec.

the omx is a faster as the others do nv12 -> I420 on cpu (AFAICT)

Maybe -threads 1 hurts perf by limiting the format conversion as well?

Is there a way to get whatever the h/w spits out (nv12) directly? Trying
to ask for nv12 seemed to get a double conversion.


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Does FFplay support HEVC interlaced bitstream display?

[Andy Furniss]

Fan Yingming wrote:

Hi, everyone.

I noticed that HEVC support interlaced field encoding, but FFplay
didn't support HEVC interlaced bitstream display.

We know FFplay play h264 interlaced bitstream perfectly.

I'd like to know if FFplay support HEVC interlaced bitstream
display. And will FFmpeg support that?


I don't think so.

It is possible to play hevc interlaced with ffmpeg via mpv but you'll
have to set up your own filter chain and possibly adjust for field order.

I've done it on a homemade (libx265) test. libx265 only takes a certain
field order and expects fields, plus interlaced support is (was) flagged
as experimental. It did seem to work though, it was a while ago so this
is just a paste from notes on the playback side - basically you need to
weave the fields that the decoder outputs as weaved frames is what other
decoders output.

mpv -fs --vf=lavfi=[tinterlace=merge,setsar=1/1,yadif=1] hevc-interl-5M.mkv

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Does FFplay support HEVC interlaced bitstream display?

[Andy Furniss]

Hendrik Leppkes wrote:

On Tue, Dec 1, 2015 at 1:36 PM, wm4 <nfx...@googlemail.com> wrote:

On Tue, 1 Dec 2015 12:12:13 +0000 Andy Furniss
<adf.li...@gmail.com> wrote:


Fan Yingming wrote:

Hi, everyone.

I noticed that HEVC support interlaced field encoding, but
FFplay didn't support HEVC interlaced bitstream display.

We know FFplay play h264 interlaced bitstream perfectly.

I'd like to know if FFplay support HEVC interlaced bitstream
display. And will FFmpeg support that?


I don't think so.

It is possible to play hevc interlaced with ffmpeg via mpv but
you'll have to set up your own filter chain and possibly adjust
for field order.

I've done it on a homemade (libx265) test. libx265 only takes a
certain field order and expects fields, plus interlaced support
is (was) flagged as experimental. It did seem to work though, it
was a while ago so this is just a paste from notes on the
playback side - basically you need to weave the fields that the
decoder outputs as weaved frames is what other decoders output.

mpv -fs --vf=lavfi=[tinterlace=merge,setsar=1/1,yadif=1]
hevc-interl-5M.mkv


Exactly the same (without the lavfi wrapper of course) should work
on ffplay.


Yea, I guess, just posting what I new worked for me.



So does this mean the HEVC decoder outputs separate fields only?
This is really odd, although I can understand why.


The reason for that is that HEVC doesn't actually have any
interlaced coding tools, just some metadata to flag a stream as
interlaced. So an interlaced stream is just a stream of half-height
frames at twice the fps.

I thought there was a patch to assemble them back into frames,
though. Maybe it was never applied.


With very recent mpv/ffmpeg my test still outputs fields.

On the "just metadata" comment - you do have to feed (IIRC) top field
first so I would hope there is some spatial handling of the bobbing in
there somewhere, but then "my hope" may not match with reality :-)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Does FFplay support HEVC interlaced bitstream display?

[Andy Furniss]

Andy Furniss wrote:


On the "just metadata" comment - you do have to feed (IIRC) top field
first so I would hope there is some spatial handling of the bobbing in
there somewhere, but then "my hope" may not match with reality :-)


Of course I am thinking of libx265 here - maybe the spec says nothing.


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH][RFC] avcodec: disallow hwaccel with frame threads

[Andy Furniss]

Hendrik Leppkes wrote:

On Thu, Oct 22, 2015 at 11:27 AM, Wang Bin 
wrote:

VLC is using frame threading with hwaccel


Then they should fix their usage, its broken by design, as explained
in detail my post earlier in this thread.


Seems ffmpeg cli does the same by default - OK so users can specify
-threads 1 if they use -hwaccel vdpau.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add framerate video filter

[Andy Furniss]

Andy Furniss wrote:


I've just done a quick test converting 25i to 30i and the il way is
worse than yadif.

Of course it's just one test with a compressed SD sample which I
then deint and scale with mpv to see on an HD monitor.


I repeated with a better quality 40mbit HD 1080i30 x264 version of
parkrun this time going down to i25. The il version looks quite broken
motion wise compared to yadif.

https://drive.google.com/file/d/0BxP5-S1t9VEETEducUEzLXhaOWc/view?usp=sharing

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add framerate video filter

[Andy Furniss]

Robert Krüger wrote:

On Mon, Aug 31, 2015 at 12:51 PM, Andy Furniss <adf.li...@gmail.com>
wrote:


Andy Furniss wrote:

I've just done a quick test converting 25i to 30i and the il way
is

worse than yadif.

Of course it's just one test with a compressed SD sample which I
then deint and scale with mpv to see on an HD monitor.



I repeated with a better quality 40mbit HD 1080i30 x264 version of
parkrun this time going down to i25. The il version looks quite
broken motion wise compared to yadif.


https://drive.google.com/file/d/0BxP5-S1t9VEETEducUEzLXhaOWc/view?usp=sharing







Looking at the file with VLC and yadif deinterlacing turned on it looks

fine to me. Is this the il sample or the yadif one?


Sorry should have said - it's the master for if you want to recreate the
test - as I am processing to y4m the results are a bit big to up/down load.

The commands used were the same as posted for the snooker test except
that this time I was going from 30i to 25i, so fps=25 for il and fps=50
for the yadif.


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add framerate video filter

[Andy Furniss]

Robert Krüger wrote:


OK, thanks for the sample. It is a very good sample for
interlacing/deinterlacing or also frame interpolation tests (e.g.
for testing mc_fps). Is is rights-free?


I made that some time ago from masters (so you can probably do better!)

The rights on the masters are "free" AFAIK the details being somewhere
on the server containing the masters =

ftp://vqeg.its.bldrdoc.gov/HDTV/

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add framerate video filter

[Andy Furniss]

Carl Eugen Hoyos wrote:

Robert Krüger krueger at lesspain.de writes:


The only other thing I noticed was that the stream seams to be
marked as interlaced when it comes out of the first il filter,
which causes warnings like these:

[Parsed_framerate_1  at  0x7fa4e3426080] Interlaced frame found -
the output will not be correct.


This sounds like an issue to me but we probably need an option for il
to disable changing the interlaced flag if another usecase for the
filter was found.


Isn't fields being marked as interlaced correct though?

I mean it's not progressive video that is produced, as each field is
offset by one line and anything that could process correctly, still
needs to know whether a field is top or bottom.

I don't know whether the framerate filter can handle fields or not, if
it can, there should be code that takes account of top/bottom. If there
isn't that code then I guess it really does need de-interlaced
progressive full height frames as input.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add framerate video filter

[Andy Furniss]

Paul B Mahol wrote:

On 8/30/15, Andy Furniss adf.li...@gmail.com wrote:



Oh, il stacks the fields, I was thinking of the filter that just
produces fields like mplayer tfields=0 (I never can remember what the
ffmpeg filter that does the same is called).


separatefields


Thanks, I have a mental block on remembering that for some reason.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add framerate video filter

[Andy Furniss]

Robert Krüger wrote:

On Sun, Aug 30, 2015 at 1:45 PM, Andy Furniss adf.li...@gmail.com
wrote:


Carl Eugen Hoyos wrote:


Robert Krüger krueger at lesspain.de writes:

The only other thing I noticed was that the stream seams to be

marked as interlaced when it comes out of the first il filter,
which causes warnings like these:

[Parsed_framerate_1  at  0x7fa4e3426080] Interlaced frame
found - the output will not be correct.



This sounds like an issue to me but we probably need an option
for il to disable changing the interlaced flag if another usecase
for the filter was found.



Isn't fields being marked as interlaced correct though?

I mean it's not progressive video that is produced, as each field
is offset by one line and anything that could process correctly,
still needs to know whether a field is top or bottom.

I don't know whether the framerate filter can handle fields or not,
if it can, there should be code that takes account of top/bottom.
If there isn't that code then I guess it really does need
de-interlaced progressive full height frames as input.



I guess the point is that the signal can be viewed as progressive
after the il filter in deinterleave mode as it has the fields stacked
on top of each other in each half of the picture. I thought that's
the whole point of il, to apply filters that were not written with
interlacing in mind and by this trick (deinterleave, process each
field like a progressive picture, reinterleave) get some things done
that would not be possible otherwise. Of course that's not really
true with respect to picture timing but all progressive spatial
filters should work using this approach (not taking into account
potential quality side effects that the broadcast guys know best). I
think the il filter signaling a progressive picture after
deinterleaving would be more correct than signaling interlaced but if
there is no consensus, it could let the user decide this using an
option.


Yea, I was getting il confused with what tfields (mplayer) or
separatefields would produce.

The thing about using il, though, is that the frame interpolater is
working with images twice as far apart temporally as it would be with
de-interlaced.

I've just done a quick test converting 25i to 30i and the il way is
worse than yadif.

Of course it's just one test with a compressed SD sample which I then
deint and scale with mpv to see on an HD monitor.

If you want to try, I did with this small snooker sample -

https://drive.google.com/file/d/0BxP5-S1t9VEEUUR0QnVYRU8yczQ/view?usp=sharing

ffmpeg -i ~/snooker-short.ts -an -sn -vf 
il=l=d:c=d,framerate=fps=30,il=l=i:c=i il-snk-30i.y4m


ffmpeg -i ~/snooker-short.ts -an -sn -vf 
yadif=1,framerate=fps=60,interlace=scan=tff:lowpass=0 ya-snk-30i.y4m


mpv -fs -vf=lavfi=[yadif=1] ...

The motion on the cue especially, is far better on the latter.
Field stepping with mpv [.] shows the blurring on everything is 
tighter on the latter.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add framerate video filter

[Andy Furniss]

Andy Furniss wrote:

Carl Eugen Hoyos wrote:

Robert Krüger krueger at lesspain.de writes:


The only other thing I noticed was that the stream seams to be
marked as interlaced when it comes out of the first il filter,
which causes warnings like these:

[Parsed_framerate_1  at  0x7fa4e3426080] Interlaced frame found
- the output will not be correct.


This sounds like an issue to me but we probably need an option for
il to disable changing the interlaced flag if another usecase for
the filter was found.


Isn't fields being marked as interlaced correct though?

I mean it's not progressive video that is produced, as each field is
offset by one line and anything that could process correctly, still
needs to know whether a field is top or bottom.

I don't know whether the framerate filter can handle fields or not,
if it can, there should be code that takes account of top/bottom. If
there isn't that code then I guess it really does need de-interlaced
progressive full height frames as input.


Oh, il stacks the fields, I was thinking of the filter that just
produces fields like mplayer tfields=0 (I never can remember what the
ffmpeg filter that does the same is called).

Still seems a bit of a strange way to use the framerate filter - but I
haven't tested vs yadif.


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add framerate video filter

[Andy Furniss]

Andy Furniss wrote:


mpv -fs -vf=lavfi=[yadif=1] ...


While playing with a bff file I just noticed that only works by luck.

It seems mpv doesn't read field order from .y4m so if it's bff you need

mpv -fs -vf=lavfi=[setfield=bff,yadif=1] ...


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/vc1dec: Re-order init to avoid initting hwaccel too early

[Andy Furniss]

Philip Langdale wrote:

At least for vdpau, the hwaccel init code tries to check the video
profile and ensure that there is a matching vdpau profile available.

If it can't find a match, it will fail to initialise.


I recently noticed this - that it silently falls back to s/w in my test
case.

For me the check (which no players seem to do) is also an issue as I
need H264 5.2 - which doesn't seem to exist in the libvdpau world.

By luck if I blindly hack mesa to say 52 it works - but that's possibly
not exactly safe for all - the AMD code works AFAICT because of defaults
in case statements setting things to high.

Maybe ffmpeg which seems alone in checking, should allow h264 52 in the
case that vdpau offers 51.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Dolby Digital dynamic range compression (drc_scale) is now 0 by default

[Andy Furniss]

Michael Niedermayer wrote:

Apologies for the slightly out of place response. I've only just
subscribed after reading the rest of this thread via the archive.

I'm with KieranK the exception should be full range for those that can
stand it.

Maybe I am not best placed to comment as I mixdown to 2ch, but while
people here argue that full range is better quality, I would agree a
bit, but unfortunately many movies are mixed in such a way that in order
to hear the dialogue the loud bits become way way too loud for comfort.

The argument that DTS/AAC/TrueHD decs don't do it IMHO is invalid as in
the latter two cases at least this is only due to incomplete (and from
my pov sometimes therefore unusable) implementations.


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel