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
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 h
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 term
Steven Liu wrote:
2017-04-11 22:27 GMT+08:00 Andy Furniss :
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
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 insert
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
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
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
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
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
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
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
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 captur
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 does
Davinder Singh wrote:
On Tue, Aug 23, 2016 at 5:38 AM Andy Furniss
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 t
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 faste
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. Wo
Carl Eugen Hoyos wrote:
2016-09-08 12:01 GMT+02:00 Andy Furniss :
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
Carl Eugen Hoyos wrote:
2016-09-08 16:17 GMT+02:00 Andy Furniss :
Carl Eugen Hoyos wrote:
2016-09-08 12:01 GMT+02:00 Andy Furniss :
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'
Carl Eugen Hoyos wrote:
2016-09-08 19:16 GMT+02:00 Andy Furniss :
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
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 :
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 --enabl
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
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
sy
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
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 sh
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
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 a
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 notice
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
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, b
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_chec
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 th
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
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
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
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,
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 real
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
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
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
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 see
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
Paul B Mahol wrote:
On 3/11/17, Andy Furniss 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 * (
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 speci
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 s
Hendrik Leppkes wrote:
On Tue, Dec 1, 2015 at 1:36 PM, wm4 wrote:
On Tue, 1 Dec 2015 12:12:13 + Andy Furniss
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 F
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 -
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
wm4 wrote:
On Wed, 20 Jan 2016 00:42:18 + Andy Furniss
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 sin
wm4 wrote:
On Wed, 20 Jan 2016 09:59:12 + Andy Furniss
wrote:
wm4 wrote:
On Wed, 20 Jan 2016 00:42:18 + Andy Furniss
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
Hendrik Leppkes wrote:
On Wed, Jan 20, 2016 at 12:13 PM, Andy Furniss wrote:
wm4 wrote:
On Wed, 20 Jan 2016 09:59:12 + Andy Furniss
wrote:
wm4 wrote:
On Wed, 20 Jan 2016 00:42:18 + Andy Furniss
wrote:
Hendrik Leppkes wrote:
I do not agree that it should be a warning. As
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
++
Paul B Mahol wrote:
On 1/24/16, Andy Furniss 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
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)
___
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.
Paul B Mahol wrote:
On 1/30/16, Andy Furniss 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, the
Paul B Mahol wrote:
On 1/30/16, Andy Furniss wrote:
Paul B Mahol wrote:
On 1/30/16, Andy Furniss 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
fie
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.
Fo
Carl Eugen Hoyos wrote:
Robert Krüger 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_10x7fa4e3426080] Interlaced frame found -
the output
Andy Furniss wrote:
Carl Eugen Hoyos wrote:
Robert Krüger 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_10x7fa4e3426080] Interla
Paul B Mahol wrote:
On 8/30/15, Andy Furniss 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
Robert Krüger wrote:
On Sun, Aug 30, 2015 at 1:45 PM, Andy Furniss
wrote:
Carl Eugen Hoyos wrote:
Robert Krüger 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 l
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=b
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
Robert Krüger wrote:
On Mon, Aug 31, 2015 at 12:51 PM, Andy Furniss
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
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" A
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 2c
67 matches
Mail list logo