Again problems with lavfi/swscale
I'm experiencing problems with commands of the kind: ffplay in.avi -vfilters "slicify=20, format=FORMAT" yuv444p,yuv411p,yuv422p,monow -> crash in RENAME(hScale) rgba,argb,rgb24,bgr24,rgb555 -> crash in YUV2RGBFUNC()/LOADCHROMA yuv410p -> chroma artefacts rgb8 -> crash in PUTRGB8 Formats which work fine: yuv420p, yuvj420p, monob nv12, nv21 (with the patch by Ramiro) gray, gray16 The commands without the slicify filter work just fine, so the problem seems to depend on the slicification of the image (yes at this point is clear that we need some testing system for spotting all these problems). If someone with more experience with libswscale wants to give some hint it would be cool. Regards. -- FFmpeg = Fundamental and Frenzy Merciful Ponderous Extreme Guide
Stefano Sabatini wrote:
I'm experiencing problems with commands of the kind:
ffplay in.avi -vfilters "slicify=20, format=FORMAT"
yuv444p,yuv411p,yuv422p,monow -> crash in RENAME(hScale) rgba,argb,rgb24,bgr24,rgb555 -> crash in YUV2RGBFUNC()/LOADCHROMA yuv410p -> chroma artefacts rgb8 -> crash in PUTRGB8
This is a regression. All these works fine for me for ffmpeg r20294, libswscale r29779 and lavfi "1. 0. 1 / 1. 0. 1" (probably r5413), but I confirm the crash with the latest version. -Vitor
On date Sunday 2009-11-29 12:48:00 +0100, Vitor Sessak encoded:
Stefano Sabatini wrote:
I'm experiencing problems with commands of the kind:
ffplay in.avi -vfilters "slicify=20, format=FORMAT"
yuv444p,yuv411p,yuv422p,monow -> crash in RENAME(hScale) rgba,argb,rgb24,bgr24,rgb555 -> crash in YUV2RGBFUNC()/LOADCHROMA yuv410p -> chroma artefacts rgb8 -> crash in PUTRGB8
This is a regression. All these works fine for me for ffmpeg r20294, libswscale r29779 and lavfi "1. 0. 1 / 1. 0. 1" (probably r5413), but I confirm the crash with the latest version.
I introduced the problem when committing the new scale filter, it should be fixed now. (Yes it was a ten-liter-cola bug so I took the liberty to commit without review). Regards. -- FFmpeg = Friendly Furious MultiPurpose Erratic Guru
On Sun, Nov 29, 2009 at 02:05:08AM +0100, Stefano Sabatini wrote: [...]
seems to depend on the slicification of the image (yes at this point is clear that we need some testing system for spotting all these problems).
it was clear since years that lavfi tests are required to have a useable lavfi, its too complex and easy to break. But ive been ignored and didnt had time to write it myself it would be nice if some regression tests would be added before further lavfi work is done. The minimum filter chain to test must contain all filter pairs, that makes ~ n^2 filters in it or n^2 tests for n distinct filters. and then each filter should be individually tested against all colorspaces. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam"
On date Sunday 2009-11-29 13:15:17 +0100, Michael Niedermayer encoded:
On Sun, Nov 29, 2009 at 02:05:08AM +0100, Stefano Sabatini wrote: [...]
seems to depend on the slicification of the image (yes at this point is clear that we need some testing system for spotting all these problems).
it was clear since years that lavfi tests are required to have a useable lavfi, its too complex and easy to break. But ive been ignored and didnt had time to write it myself
it would be nice if some regression tests would be added before further lavfi work is done. The minimum filter chain to test must contain all filter pairs, that makes ~ n^2 filters in it or n^2 tests for n distinct filters.
If we have n^2 tests for each filter, then we end-up with n^3 tests, which doesn't look something we can manage already with a small number of filters, that would mean already 343 tests with the currently 7 committed filters. That's not easy to do it especially if we want to automate things, but reference files need to be validated manually, and the same for the options to be used to test the various filters (also a filter may fail with some option set and not with other ones). Also every filter addition will increase the number of tests of n^3 - (n-1)^3, which also is not reasonable. We already had had the experience of filters which only failed when used with a particular format and with a special value for slices height / input size, so I don't think that to design a system to test all the possible cases would be something achievable. Also when we consider filters with a more/less than 1 input and 1 output things get even more complicated (for example how to test when a sink fails?). A very simple alternative may be to simply implement for each filter a set of carefully handcrafted tests which replicate all the possible critical corner cases which may lead to a failure.
and then each filter should be individually tested against all colorspaces.
Not every pixel format will be in general supported, so we may manually add a list of supported formats. Even better would be to add some interface to expose the set of supported inputs (though not sure this is possible, especially considering the scale filter). The the test may run like this: $filter=foobar $filter_opts=bar:baz:blah for (pix_fmt in $supported_pix_fmts); do do_lavfi_unit "$filter-$pix_fmt" "slicify=20,format=$pix_fmt,$filter=$filter_opts" done For each of these tests we need a reference file. This shouldn't be too hard to implement, each reference file can be validated by the tester. ... And BTW, in any case I believe need a more modular test system, it should be easy to simply edit some list and test just a subset of the complete test-set. Comments are welcome, I'll start to implement part 2 since it looks the simple one. Regards. -- FFmpeg = Fundamentalist and Forgiving Mortal Peaceless Eccentric Gadget
On Sun, Dec 13, 2009 at 01:52:41AM +0100, Stefano Sabatini wrote:
On date Sunday 2009-11-29 13:15:17 +0100, Michael Niedermayer encoded:
On Sun, Nov 29, 2009 at 02:05:08AM +0100, Stefano Sabatini wrote: [...]
seems to depend on the slicification of the image (yes at this point is clear that we need some testing system for spotting all these problems).
it was clear since years that lavfi tests are required to have a useable lavfi, its too complex and easy to break. But ive been ignored and didnt had time to write it myself
it would be nice if some regression tests would be added before further lavfi work is done. The minimum filter chain to test must contain all filter pairs, that makes ~ n^2 filters in it or n^2 tests for n distinct filters.
If we have n^2 tests for each filter, then we end-up with n^3 tests,
n tests for each filter makes n^2 which is what i meant [...]
We already had had the experience of filters which only failed when used with a particular format and with a special value for slices height / input size, so I don't think that to design a system to test all the possible cases would be something achievable.
we should test a widely spread mix of things ...
Also when we consider filters with a more/less than 1 input and 1 output things get even more complicated (for example how to test when a sink fails?).
ask me when we have a sink
A very simple alternative may be to simply implement for each filter a set of carefully handcrafted tests which replicate all the possible critical corner cases which may lead to a failure.
Iam not sure if this is an alternative. Iam not even sure if what i think you talk about is what you talk about. A test filter that would feed another filter with pictures with differnt sets of permissions, sizes, pix_fmts, slice order and size, interlacing and progressive, misaligned and aligned data[], .... is surely usefull, its also easy to test as its output should always be the same (or very close for differing pix_fmts) still we need actual tests of filter interactions of actual filter chains, its not the same thing.
and then each filter should be individually tested against all colorspaces.
Not every pixel format will be in general supported, so we may manually add a list of supported formats. Even better would be to add some interface to expose the set of supported inputs (though not sure this is possible, especially considering the scale filter).
you are searching for query_formats() ? [...]
And BTW, in any case I believe need a more modular test system, it should be easy to simply edit some list and test just a subset of the complete test-set.
yes [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact
On date Sunday 2009-12-13 03:33:18 +0100, Michael Niedermayer encoded:
On Sun, Dec 13, 2009 at 01:52:41AM +0100, Stefano Sabatini wrote: [...]
and then each filter should be individually tested against all colorspaces.
Not every pixel format will be in general supported, so we may manually add a list of supported formats. Even better would be to add some interface to expose the set of supported inputs (though not sure this is possible, especially considering the scale filter).
you are searching for query_formats() ?
Well at least now I have a tool for exposing that info. BTW: make show-filter-formats; and show-filter-formats scale 100:100 make: `show-filter-formats' is up to date. input pad default [0]: yuv420p yuyv422 rgb24 bgr24 yuv422p yuv444p yuv410p yuv411p gray monow monob pal8 yuvj420p yuvj422p yuvj444p xvmcmc xvmcidct uyvy422 uyyvyy411 bgr8 bgr4 bgr4_byte rgb8 rgb4 rgb4_byte nv12 nv21 argb rgba abgr bgra gray16be gray16le yuv440p yuvj440p yuva420p vdpau_h264 vdpau_mpeg1 vdpau_mpeg2 vdpau_wmv3 vdpau_vc1 rgb48be rgb48le rgb565be rgb565le rgb555be rgb555le bgr565be bgr565le bgr555be bgr555le vaapi_moco vaapi_idct vaapi_vld yuv420p16le yuv420p16be yuv422p16le yuv422p16be yuv444p16le yuv444p16be vdpau_mpeg4 output pad default [0]: yuv420p yuyv422 rgb24 bgr24 yuv422p yuv444p yuv410p yuv411p gray monow monob pal8 yuvj420p yuvj422p yuvj444p xvmcmc xvmcidct uyvy422 uyyvyy411 bgr8 bgr4 bgr4_byte rgb8 rgb4 rgb4_byte nv12 nv21 argb rgba abgr bgra gray16be gray16le yuv440p yuvj440p yuva420p vdpau_h264 vdpau_mpeg1 vdpau_mpeg2 vdpau_wmv3 vdpau_vc1 rgb48be rgb48le rgb565be rgb565le rgb555be rgb555le bgr565be bgr565le bgr555be bgr555le vaapi_moco vaapi_idct vaapi_vld yuv420p16le yuv420p16be yuv422p16le yuv422p16be yuv444p16le yuv444p16be vdpau_mpeg4 I believe all the HW accelerated formats should be avoided, right? Also how to feed a filter with video formats for which we cannot write in output (I mean pal formats)? I'm asking since for today I run out of ideas and asking is soo easy... Regards. -- FFmpeg = Forgiving Friendly Merciless Puristic Eager Gadget
On Mon, Dec 28, 2009 at 12:58:55AM +0100, Stefano Sabatini wrote: [...]
Also how to feed a filter with video formats for which we cannot write in output (I mean pal formats)? I'm asking since for today I run out of ideas and asking is soo easy...
I think kostya had some pal output code, unless i misremember dunno what happened to it ... [..] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator
On Mon, Dec 28, 2009 at 01:18:16AM +0100, Michael Niedermayer wrote:
On Mon, Dec 28, 2009 at 12:58:55AM +0100, Stefano Sabatini wrote: [...]
Also how to feed a filter with video formats for which we cannot write in output (I mean pal formats)? I'm asking since for today I run out of ideas and asking is soo easy...
I think kostya had some pal output code, unless i misremember dunno what happened to it ...
No, I just had an idea of creating palettiser with ELBG code since it's trivial.
[..] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
On date Monday 2009-12-28 07:39:12 +0200, Kostya encoded:
On Mon, Dec 28, 2009 at 01:18:16AM +0100, Michael Niedermayer wrote:
On Mon, Dec 28, 2009 at 12:58:55AM +0100, Stefano Sabatini wrote: [...]
Also how to feed a filter with video formats for which we cannot write in output (I mean pal formats)? I'm asking since for today I run out of ideas and asking is soo easy...
I think kostya had some pal output code, unless i misremember dunno what happened to it ...
No, I just had an idea of creating palettiser with ELBG code since it's trivial.
Can you be a little more descriptive?. If it is something which I can hack-up in a week then I can try it. Regards. -- FFmpeg = Freak and Faithless Majestic Portable Explosive Ghost
On date Monday 2009-12-28 00:58:55 +0100, Stefano Sabatini encoded:
On date Sunday 2009-12-13 03:33:18 +0100, Michael Niedermayer encoded:
On Sun, Dec 13, 2009 at 01:52:41AM +0100, Stefano Sabatini wrote: [...]
and then each filter should be individually tested against all colorspaces.
Not every pixel format will be in general supported, so we may manually add a list of supported formats. Even better would be to add some interface to expose the set of supported inputs (though not sure this is possible, especially considering the scale filter).
you are searching for query_formats() ?
Well at least now I have a tool for exposing that info.
BTW: make show-filter-formats; and show-filter-formats scale 100:100 make: `show-filter-formats' is up to date. [...] I believe all the HW accelerated formats should be avoided, right?
Also how to feed a filter with video formats for which we cannot write in output (I mean pal formats)? I'm asking since for today I run out of ideas and asking is soo easy...
First implementation of the test system, with ad-hoc per-feature tests and one test for each filter/input pixel format combination, useful for testing one-input / one-output filters. BTW the ff* tools are not able to decode some of the output files, for example: stefano at geppetto ~/s/l/f/t/data> ffplay b-yuv411p-null.avi FFplay version SVN-r21003, Copyright (c) 2003-2010 Fabrice Bellard, et al. [...] [avi @ 0x97f9690]MAX_READ_SIZE:5000000 reached Input #0, avi, from 'b-yuv411p-null.avi': Duration: 00:00:02.00, start: 0.000000, bitrate: 30440 kb/s Stream #0.0: Video: Y41B / 0x42313459, 352x288, 25 fps, 25 tbr, 25 tbn, 25 tbc b-yuv411p-null.avi: could not open codecs which is somehow due to the fourCC problem I mentioned in another thread. What is still missing is a system for testing each filter/filter combination, the only problem is that in this case is difficult to find parameters which are good for every possible combination, and I don't want to be required to specify them. The best way to fix that problem seems to me to use parametric values, e.g.: scale=2/3*in_w:2/3*out_w, pad=3/2*in_w:3/2*out_w:1/4*in_w:(out_w-in_w)/2:(out_h-in_h)/2, crop=(in_w-out_w)/2:(in_h-out_h)/2in_w/2:out_h/2: but not every filter supports them (currently no-one). Ideas? Regards. -- FFmpeg = Free & Friendly Moronic Puristic Enlightened Gem
On Thu, Jan 07, 2010 at 11:36:02PM +0100, Stefano Sabatini wrote:
Ideas?
--- libavfilter-soc.orig/ffmpeg/tests/lavfi-regression.sh 2010-01-07 20:29:58.000000000 +0100 +++ libavfilter-soc/ffmpeg/tests/lavfi-regression.sh 2010-01-07 23:12:27.000000000 +0100 @@ -24,4 +24,56 @@
+get_common_elts() (
elts? Diego
On date Thursday 2010-01-07 23:51:02 +0100, Diego Biurrun encoded:
On Thu, Jan 07, 2010 at 11:36:02PM +0100, Stefano Sabatini wrote:
Ideas?
--- libavfilter-soc.orig/ffmpeg/tests/lavfi-regression.sh 2010-01-07 20:29:58.000000000 +0100 +++ libavfilter-soc/ffmpeg/tests/lavfi-regression.sh 2010-01-07 23:12:27.000000000 +0100 @@ -24,4 +24,56 @@
+get_common_elts() (
elts?
s/elts/elements/ -- FFmpeg = Fierce & Frightening Magical Puristic Elected Genius
On Thu, Jan 07, 2010 at 11:57:36PM +0100, Stefano Sabatini wrote:
On date Thursday 2010-01-07 23:51:02 +0100, Diego Biurrun encoded:
On Thu, Jan 07, 2010 at 11:36:02PM +0100, Stefano Sabatini wrote:
Ideas?
--- libavfilter-soc.orig/ffmpeg/tests/lavfi-regression.sh 2010-01-07 20:29:58.000000000 +0100 +++ libavfilter-soc/ffmpeg/tests/lavfi-regression.sh 2010-01-07 23:12:27.000000000 +0100 @@ -24,4 +24,56 @@
+get_common_elts() (
elts?
s/elts/elements/
How was anybody supposed to guess that? If at all, "elems" would be the natural shorthand for "elements". Even so, please just write it out. Diego
On Thu, Jan 07, 2010 at 11:36:02PM +0100, Stefano Sabatini wrote:
On date Monday 2009-12-28 00:58:55 +0100, Stefano Sabatini encoded:
On date Sunday 2009-12-13 03:33:18 +0100, Michael Niedermayer encoded:
On Sun, Dec 13, 2009 at 01:52:41AM +0100, Stefano Sabatini wrote: [...]
and then each filter should be individually tested against all colorspaces.
Not every pixel format will be in general supported, so we may manually add a list of supported formats. Even better would be to add some interface to expose the set of supported inputs (though not sure this is possible, especially considering the scale filter).
you are searching for query_formats() ?
Well at least now I have a tool for exposing that info.
BTW: make show-filter-formats; and show-filter-formats scale 100:100 make: `show-filter-formats' is up to date. [...] I believe all the HW accelerated formats should be avoided, right?
Also how to feed a filter with video formats for which we cannot write in output (I mean pal formats)? I'm asking since for today I run out of ideas and asking is soo easy...
First implementation of the test system, with ad-hoc per-feature tests and one test for each filter/input pixel format combination, useful for testing one-input / one-output filters.
BTW the ff* tools are not able to decode some of the output files, for example: stefano at geppetto ~/s/l/f/t/data> ffplay b-yuv411p-null.avi FFplay version SVN-r21003, Copyright (c) 2003-2010 Fabrice Bellard, et al. [...] [avi @ 0x97f9690]MAX_READ_SIZE:5000000 reached Input #0, avi, from 'b-yuv411p-null.avi': Duration: 00:00:02.00, start: 0.000000, bitrate: 30440 kb/s Stream #0.0: Video: Y41B / 0x42313459, 352x288, 25 fps, 25 tbr, 25 tbn, 25 tbc b-yuv411p-null.avi: could not open codecs
which is somehow due to the fourCC problem I mentioned in another thread.
What is still missing is a system for testing each filter/filter combination, the only problem is that in this case is difficult to find parameters which are good for every possible combination, and I don't want to be required to specify them.
The best way to fix that problem seems to me to use parametric values, e.g.: scale=2/3*in_w:2/3*out_w, pad=3/2*in_w:3/2*out_w:1/4*in_w:(out_w-in_w)/2:(out_h-in_h)/2, crop=(in_w-out_w)/2:(in_h-out_h)/2in_w/2:out_h/2:
your shell is able to replace $VAR and even to do simple math like $[2*5/3] that should be enough [...]
+# generic tests +do_lavfi "crop" "slicify=20,crop=100:100" +do_lavfi "crop_scale" "slicify=20,crop=100:100,scale=200:-1" +do_lavfi "crop_scale_pad" "slicify=20,crop=100:100,scale=200:-1,pad=400:300:50:50:red" +do_lavfi "crop_scale_vflip" "slicify=20,null,null,crop=200:200,crop=20:20,scale=200:200,scale=250:250,vflip,vflip,null,scale=200:200,crop=100:100,vflip,scale=200:200,null,vflip,crop=100:100,null" +do_lavfi "crop_vflip" "slicify=20,crop=100:100,vflip" +do_lavfi "null" "slicify=20,null" +do_lavfi "pad_pad" "slicify=20,pad=400:400:20:20:red,pad=420:420:10:10:blue" +do_lavfi "pad_vflip" "slicify=20,pad=500:400:50:50:red,vflip" +do_lavfi "scale200" "slicify=20,scale=200:200" +do_lavfi "scale500" "slicify=20,scale=500:500" +do_lavfi "vflip" "slicify=20,vflip" +do_lavfi "vflip_crop" "slicify=20,vflip,crop=100:100" +do_lavfi "vflip_pad" "slicify=20,vflip,pad=500:600:100:100" +do_lavfi "vflip_vflip" "slicify=20,vflip,vflip"
please dont use slicify=20 for all but more random also dont use avi as output but something that supports timestamps so they are tested as well (filters may change them) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator
On date Friday 2010-01-08 03:48:37 +0100, Michael Niedermayer encoded:
also dont use avi as output but something that supports timestamps so they are tested as well (filters may change them)
Both avi and nut fail with some of the pixel formats supported, maybe I'll be more lucky with mp4/mov. But I want to know if there is some way to fix them, for example for AVI there doesn't seem to be fourCC tags for some of the pixel formats we support, the same for NUT (we can maybe fix the latter extending its specs), anyway I believe we should fail if some pixel format is not supported during encoding. Any thought? Regards. -- FFmpeg = Faithless Fiendish Maxi Portable Elected Ghost
On Sat, Jan 09, 2010 at 02:58:30PM +0100, Stefano Sabatini wrote:
On date Friday 2010-01-08 03:48:37 +0100, Michael Niedermayer encoded:
also dont use avi as output but something that supports timestamps so they are tested as well (filters may change them)
Both avi and nut fail with some of the pixel formats supported, maybe I'll be more lucky with mp4/mov.
But I want to know if there is some way to fix them, for example for AVI there doesn't seem to be fourCC tags for some of the pixel formats we support, the same for NUT (we can maybe fix the latter extending its specs), anyway I believe we should fail if some pixel format is not supported during encoding.
Any thought?
read fourcc.org or M$ specs read nut4cc.txt [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes
On date Saturday 2010-01-09 15:43:34 +0100, Michael Niedermayer encoded:
On Sat, Jan 09, 2010 at 02:58:30PM +0100, Stefano Sabatini wrote:
On date Friday 2010-01-08 03:48:37 +0100, Michael Niedermayer encoded:
also dont use avi as output but something that supports timestamps so they are tested as well (filters may change them)
Both avi and nut fail with some of the pixel formats supported, maybe I'll be more lucky with mp4/mov.
But I want to know if there is some way to fix them, for example for AVI there doesn't seem to be fourCC tags for some of the pixel formats we support, the same for NUT (we can maybe fix the latter extending its specs), anyway I believe we should fail if some pixel format is not supported during encoding.
Any thought?
read fourcc.org or M$ specs
Ah, funny that I have to read a third party site for something related to a M$ standard. This reminds me of why computer tech sucks so much.
read nut4cc.txt
On Sun, Jan 10, 2010 at 01:06:48AM +0100, Stefano Sabatini wrote:
On date Saturday 2010-01-09 15:43:34 +0100, Michael Niedermayer encoded:
On Sat, Jan 09, 2010 at 02:58:30PM +0100, Stefano Sabatini wrote:
On date Friday 2010-01-08 03:48:37 +0100, Michael Niedermayer encoded:
also dont use avi as output but something that supports timestamps so they are tested as well (filters may change them)
Both avi and nut fail with some of the pixel formats supported, maybe I'll be more lucky with mp4/mov.
But I want to know if there is some way to fix them, for example for AVI there doesn't seem to be fourCC tags for some of the pixel formats we support, the same for NUT (we can maybe fix the latter extending its specs), anyway I believe we should fail if some pixel format is not supported during encoding.
Any thought?
read fourcc.org or M$ specs
Ah, funny that I have to read a third party site for something related to a M$ standard. This reminds me of why computer tech sucks so much.
read nut4cc.txt
From the mplayer/DOCS/tech/nut.txt
|the nut spec has been moved to another svn repo you can find it at: |http://svn.mplayerhq.hu/nut/docs/nut.txt?view=markup | |its future location will be in a git repository, ill update this file |here when its location changes again
The referenced page is missing.
Then I tried: http://nut-container.org/
The link to the specification leads nowhere.
I googled in search of some reference to the nut repo in vain.
Then I tried: svn list svn://svn.mplayerhq.hu/nut
and finally I got the repo.
Please fix the dangling links.
fix them yourself you have a svn account :) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle
On date Sunday 2010-01-10 02:07:13 +0100, Michael Niedermayer encoded:
On Sun, Jan 10, 2010 at 01:06:48AM +0100, Stefano Sabatini wrote: [...]
From the mplayer/DOCS/tech/nut.txt
|the nut spec has been moved to another svn repo you can find it at: |http://svn.mplayerhq.hu/nut/docs/nut.txt?view=markup | |its future location will be in a git repository, ill update this file |here when its location changes again
The referenced page is missing.
Then I tried: http://nut-container.org/
The link to the specification leads nowhere.
I googled in search of some reference to the nut repo in vain.
Then I tried: svn list svn://svn.mplayerhq.hu/nut
and finally I got the repo.
Please fix the dangling links.
fix them yourself you have a svn account :)
The mplayerhq web server cannot resolve links of the type: http://svn.mplayerhq.hu/nut/docs/FILE?view=co is that maybe related to some security problem we had some time ago? Regards. -- FFmpeg = Fundamental & Faboulous Mega Portable Excellent Geisha
On date Sunday 2010-01-10 02:27:51 +0100, Stefano Sabatini encoded:
On date Sunday 2010-01-10 02:07:13 +0100, Michael Niedermayer encoded:
On Sun, Jan 10, 2010 at 01:06:48AM +0100, Stefano Sabatini wrote: [...]
From the mplayer/DOCS/tech/nut.txt
|the nut spec has been moved to another svn repo you can find it at: |http://svn.mplayerhq.hu/nut/docs/nut.txt?view=markup | |its future location will be in a git repository, ill update this file |here when its location changes again
The referenced page is missing.
Then I tried: http://nut-container.org/
The link to the specification leads nowhere.
I googled in search of some reference to the nut repo in vain.
Then I tried: svn list svn://svn.mplayerhq.hu/nut
and finally I got the repo.
Please fix the dangling links.
fix them yourself you have a svn account :)
The mplayerhq web server cannot resolve links of the type: http://svn.mplayerhq.hu/nut/docs/FILE?view=co
Nut repo: svn://svn.mplayerhq.hu/nut homepage/index.html points to: http://svn.mplayerhq.hu/nut/docs/nut.txt?view=co In order to replace this with a link to an existing location, I need the nut spec pages to be published somewhere (and so some help from root I guess). The best bet seems to have all the nut/docs dir published on the nut-container site, another option suggested by Jai on IRC would be to create a git mirror on github / gitorious. Regards. -- FFmpeg = Fascinating and Frenzy Magnificient Prodigious EnGine
On Sat, Mar 20, 2010 at 5:59 PM, Stefano Sabatini <stefano.sabatini-lala at poste.it> wrote:
On date Sunday 2010-01-10 02:27:51 +0100, Stefano Sabatini encoded:
On date Sunday 2010-01-10 02:07:13 +0100, Michael Niedermayer encoded:
On Sun, Jan 10, 2010 at 01:06:48AM +0100, Stefano Sabatini wrote: [...]
From the mplayer/DOCS/tech/nut.txt
|the nut spec has been moved to another svn repo you can find it at: |http://svn.mplayerhq.hu/nut/docs/nut.txt?view=markup | |its future location will be in a git repository, ill update this file |here when its location changes again
The referenced page is missing.
Then I tried: http://nut-container.org/
The link to the specification leads nowhere.
I googled in search of some reference to the nut repo in vain.
Then I tried: svn list svn://svn.mplayerhq.hu/nut
and finally I got the repo.
Please fix the dangling links.
fix them yourself you have a svn account :)
The mplayerhq web server cannot resolve links of the type: http://svn.mplayerhq.hu/nut/docs/FILE?view=co
Nut repo: svn://svn.mplayerhq.hu/nut
homepage/index.html points to: http://svn.mplayerhq.hu/nut/docs/nut.txt?view=co
In order to replace this with a link to an existing location, I need the nut spec pages to be published somewhere (and so some help from root I guess).
The best bet seems to have all the nut/docs dir published on the nut-container site, another option suggested by Jai on IRC would be to create a git mirror on github / gitorious.
Of course I'd do that because I'm too lazy to setup anything elaborate, like a periodic svn export to the http server ;) -- Jai Menon
On Sat, Mar 20, 2010 at 01:29:30PM +0100, Stefano Sabatini wrote:
On date Sunday 2010-01-10 02:27:51 +0100, Stefano Sabatini encoded:
On date Sunday 2010-01-10 02:07:13 +0100, Michael Niedermayer encoded:
On Sun, Jan 10, 2010 at 01:06:48AM +0100, Stefano Sabatini wrote: [...]
From the mplayer/DOCS/tech/nut.txt
|the nut spec has been moved to another svn repo you can find it at: |http://svn.mplayerhq.hu/nut/docs/nut.txt?view=markup | |its future location will be in a git repository, ill update this file |here when its location changes again
The referenced page is missing.
Then I tried: http://nut-container.org/
The link to the specification leads nowhere.
I googled in search of some reference to the nut repo in vain.
Then I tried: svn list svn://svn.mplayerhq.hu/nut
and finally I got the repo.
Please fix the dangling links.
fix them yourself you have a svn account :)
The mplayerhq web server cannot resolve links of the type: http://svn.mplayerhq.hu/nut/docs/FILE?view=co
Nut repo: svn://svn.mplayerhq.hu/nut
homepage/index.html points to: http://svn.mplayerhq.hu/nut/docs/nut.txt?view=co
In order to replace this with a link to an existing location, I need the nut spec pages to be published somewhere (and so some help from root I guess).
The best bet seems to have all the nut/docs dir published on the nut-container site, another option suggested by Jai on IRC would be to create a git mirror on github / gitorious.
its available there: but this might not be the latest version http://www1.mplayerhq.hu/~michael/nut.txt dont hesitate to mail me if its not ill update it [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras
On date Sunday 2010-03-21 10:01:25 +0100, Michael Niedermayer encoded:
On Sat, Mar 20, 2010 at 01:29:30PM +0100, Stefano Sabatini wrote:
On date Sunday 2010-01-10 02:27:51 +0100, Stefano Sabatini encoded: [...]
The mplayerhq web server cannot resolve links of the type: http://svn.mplayerhq.hu/nut/docs/FILE?view=co
Nut repo: svn://svn.mplayerhq.hu/nut
homepage/index.html points to: http://svn.mplayerhq.hu/nut/docs/nut.txt?view=co
In order to replace this with a link to an existing location, I need the nut spec pages to be published somewhere (and so some help from root I guess).
The best bet seems to have all the nut/docs dir published on the nut-container site, another option suggested by Jai on IRC would be to create a git mirror on github / gitorious.
its available there: but this might not be the latest version http://www1.mplayerhq.hu/~michael/nut.txt
dont hesitate to mail me if its not ill update it
There is a minimal difference, see the diff in attachment. I'll link to this document, anyway it would make sense to publish all the docs dir, even better to make browsable all the content of the repo through websvn / git2web / whatever. Regards. -- FFmpeg = Fast & Fiendish Mastodontic Pitiful Erroneous Gadget
On date Sunday 2010-03-21 15:40:08 +0100, Stefano Sabatini encoded:
On date Sunday 2010-03-21 10:01:25 +0100, Michael Niedermayer encoded:
On Sat, Mar 20, 2010 at 01:29:30PM +0100, Stefano Sabatini wrote:
On date Sunday 2010-01-10 02:27:51 +0100, Stefano Sabatini encoded: [...]
The mplayerhq web server cannot resolve links of the type: http://svn.mplayerhq.hu/nut/docs/FILE?view=co
Nut repo: svn://svn.mplayerhq.hu/nut
homepage/index.html points to: http://svn.mplayerhq.hu/nut/docs/nut.txt?view=co
In order to replace this with a link to an existing location, I need the nut spec pages to be published somewhere (and so some help from root I guess).
The best bet seems to have all the nut/docs dir published on the nut-container site, another option suggested by Jai on IRC would be to create a git mirror on github / gitorious.
its available there: but this might not be the latest version http://www1.mplayerhq.hu/~michael/nut.txt
dont hesitate to mail me if its not ill update it
There is a minimal difference, see the diff in attachment.
I'll link to this document, anyway it would make sense to publish all
No I can't commit there :-(... please can someone commit the attached patch? Regards. -- FFmpeg = Friendly & Faithful MultiPurpose Empowered Guru
On Sun, Mar 21, 2010 at 03:49:59PM +0100, Stefano Sabatini wrote:
On date Sunday 2010-03-21 15:40:08 +0100, Stefano Sabatini encoded:
On date Sunday 2010-03-21 10:01:25 +0100, Michael Niedermayer encoded:
On Sat, Mar 20, 2010 at 01:29:30PM +0100, Stefano Sabatini wrote:
On date Sunday 2010-01-10 02:27:51 +0100, Stefano Sabatini encoded: [...]
The mplayerhq web server cannot resolve links of the type: http://svn.mplayerhq.hu/nut/docs/FILE?view=co
Nut repo: svn://svn.mplayerhq.hu/nut
homepage/index.html points to: http://svn.mplayerhq.hu/nut/docs/nut.txt?view=co
In order to replace this with a link to an existing location, I need the nut spec pages to be published somewhere (and so some help from root I guess).
The best bet seems to have all the nut/docs dir published on the nut-container site, another option suggested by Jai on IRC would be to create a git mirror on github / gitorious.
its available there: but this might not be the latest version http://www1.mplayerhq.hu/~michael/nut.txt
dont hesitate to mail me if its not ill update it
There is a minimal difference, see the diff in attachment.
should be fixed [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch
On date Sunday 2010-03-21 18:52:53 +0100, Michael Niedermayer encoded:
On Sun, Mar 21, 2010 at 03:49:59PM +0100, Stefano Sabatini wrote:
On date Sunday 2010-03-21 15:40:08 +0100, Stefano Sabatini encoded:
On date Sunday 2010-03-21 10:01:25 +0100, Michael Niedermayer encoded:
On Sat, Mar 20, 2010 at 01:29:30PM +0100, Stefano Sabatini wrote:
On date Sunday 2010-01-10 02:27:51 +0100, Stefano Sabatini encoded: [...]
The mplayerhq web server cannot resolve links of the type: http://svn.mplayerhq.hu/nut/docs/FILE?view=co
Nut repo: svn://svn.mplayerhq.hu/nut
homepage/index.html points to: http://svn.mplayerhq.hu/nut/docs/nut.txt?view=co
In order to replace this with a link to an existing location, I need the nut spec pages to be published somewhere (and so some help from root I guess).
The best bet seems to have all the nut/docs dir published on the nut-container site, another option suggested by Jai on IRC would be to create a git mirror on github / gitorious.
its available there: but this might not be the latest version http://www1.mplayerhq.hu/~michael/nut.txt
dont hesitate to mail me if its not ill update it
There is a minimal difference, see the diff in attachment.
should be fixed
Thanks. -- FFmpeg = Fierce and Freak Miracolous Portable Exxagerate Governor
On date Sunday 2010-03-21 15:49:59 +0100, Stefano Sabatini encoded:
On date Sunday 2010-03-21 15:40:08 +0100, Stefano Sabatini encoded:
On date Sunday 2010-03-21 10:01:25 +0100, Michael Niedermayer encoded:
On Sat, Mar 20, 2010 at 01:29:30PM +0100, Stefano Sabatini wrote:
On date Sunday 2010-01-10 02:27:51 +0100, Stefano Sabatini encoded: [...]
The mplayerhq web server cannot resolve links of the type: http://svn.mplayerhq.hu/nut/docs/FILE?view=co
Nut repo: svn://svn.mplayerhq.hu/nut
homepage/index.html points to: http://svn.mplayerhq.hu/nut/docs/nut.txt?view=co
In order to replace this with a link to an existing location, I need the nut spec pages to be published somewhere (and so some help from root I guess).
The best bet seems to have all the nut/docs dir published on the nut-container site, another option suggested by Jai on IRC would be to create a git mirror on github / gitorious.
its available there: but this might not be the latest version http://www1.mplayerhq.hu/~michael/nut.txt
dont hesitate to mail me if its not ill update it
There is a minimal difference, see the diff in attachment.
I'll link to this document, anyway it would make sense to publish all
No I can't commit there :-(... please can someone commit the attached patch?
Regards. -- FFmpeg = Friendly & Faithful MultiPurpose Empowered Guru
Index: homepage/index.html =================================================================== --- homepage/index.html (revision 664) +++ homepage/index.html (working copy) @@ -16,7 +16,7 @@
<center> - [<a href="http://svn.mplayerhq.hu/nut/docs/nut.txt?view=co">Specification</a>] + [<a href="http://www1.mplayerhq.hu/~michael/nut.txt">Specification</a>] [<a href="http://lists.mplayerhq.hu/mailman/listinfo/nut-devel">Mailing List</a>] </center>
@@ -48,7 +48,7 @@ </p>
<center> - [<a href="http://svn.mplayerhq.hu/nut/docs/nut.txt?view=co">Specification</a>] + [<a href="http://www1.mplayerhq.hu/~michael/nut.txt">Specification</a>] [<a href="http://lists.mplayerhq.hu/mailman/listinfo/nut-devel">Mailing List</a>] </center>
Ping, having a dangling link in the official page is not going to give a good impression on the casual reader... Regards. -- FFmpeg = Fierce and Fierce Maxi Prodigious Eretic Gem
On Sat, Mar 27, 2010 at 12:07:35AM +0100, Stefano Sabatini wrote:
On date Sunday 2010-03-21 15:49:59 +0100, Stefano Sabatini encoded:
On date Sunday 2010-03-21 15:40:08 +0100, Stefano Sabatini encoded:
On date Sunday 2010-03-21 10:01:25 +0100, Michael Niedermayer encoded:
On Sat, Mar 20, 2010 at 01:29:30PM +0100, Stefano Sabatini wrote:
On date Sunday 2010-01-10 02:27:51 +0100, Stefano Sabatini encoded: [...]
The mplayerhq web server cannot resolve links of the type: http://svn.mplayerhq.hu/nut/docs/FILE?view=co
Nut repo: svn://svn.mplayerhq.hu/nut
homepage/index.html points to: http://svn.mplayerhq.hu/nut/docs/nut.txt?view=co
In order to replace this with a link to an existing location, I need the nut spec pages to be published somewhere (and so some help from root I guess).
The best bet seems to have all the nut/docs dir published on the nut-container site, another option suggested by Jai on IRC would be to create a git mirror on github / gitorious.
its available there: but this might not be the latest version http://www1.mplayerhq.hu/~michael/nut.txt
dont hesitate to mail me if its not ill update it
There is a minimal difference, see the diff in attachment.
I'll link to this document, anyway it would make sense to publish all
No I can't commit there :-(... please can someone commit the attached patch?
Regards. -- FFmpeg = Friendly & Faithful MultiPurpose Empowered Guru
Index: homepage/index.html =================================================================== --- homepage/index.html (revision 664) +++ homepage/index.html (working copy) @@ -16,7 +16,7 @@
<center> - [<a href="http://svn.mplayerhq.hu/nut/docs/nut.txt?view=co">Specification</a>] + [<a href="http://www1.mplayerhq.hu/~michael/nut.txt">Specification</a>] [<a href="http://lists.mplayerhq.hu/mailman/listinfo/nut-devel">Mailing List</a>] </center>
@@ -48,7 +48,7 @@ </p>
<center> - [<a href="http://svn.mplayerhq.hu/nut/docs/nut.txt?view=co">Specification</a>] + [<a href="http://www1.mplayerhq.hu/~michael/nut.txt">Specification</a>] [<a href="http://lists.mplayerhq.hu/mailman/listinfo/nut-devel">Mailing List</a>] </center>
Ping, having a dangling link in the official page is not going to give a good impression on the casual reader...
ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus
On date Saturday 2010-03-27 03:18:36 +0100, Michael Niedermayer encoded:
On Sat, Mar 27, 2010 at 12:07:35AM +0100, Stefano Sabatini wrote: [...]
Index: homepage/index.html =================================================================== --- homepage/index.html (revision 664) +++ homepage/index.html (working copy) @@ -16,7 +16,7 @@
<center> - [<a href="http://svn.mplayerhq.hu/nut/docs/nut.txt?view=co">Specification</a>] + [<a href="http://www1.mplayerhq.hu/~michael/nut.txt">Specification</a>] [<a href="http://lists.mplayerhq.hu/mailman/listinfo/nut-devel">Mailing List</a>] </center>
@@ -48,7 +48,7 @@ </p>
<center> - [<a href="http://svn.mplayerhq.hu/nut/docs/nut.txt?view=co">Specification</a>] + [<a href="http://www1.mplayerhq.hu/~michael/nut.txt">Specification</a>] [<a href="http://lists.mplayerhq.hu/mailman/listinfo/nut-devel">Mailing List</a>] </center>
Ping, having a dangling link in the official page is not going to give a good impression on the casual reader...
ok
No commit rights... -- FFmpeg = Frenzy and Fostering Minimalistic Pacific Extended Gospel
On date Sunday 2010-03-28 00:15:51 +0100, Stefano Sabatini encoded:
On date Saturday 2010-03-27 03:18:36 +0100, Michael Niedermayer encoded:
On Sat, Mar 27, 2010 at 12:07:35AM +0100, Stefano Sabatini wrote: [...]
Index: homepage/index.html =================================================================== --- homepage/index.html (revision 664) +++ homepage/index.html (working copy) @@ -16,7 +16,7 @@
<center> - [<a href="http://svn.mplayerhq.hu/nut/docs/nut.txt?view=co">Specification</a>] + [<a href="http://www1.mplayerhq.hu/~michael/nut.txt">Specification</a>] [<a href="http://lists.mplayerhq.hu/mailman/listinfo/nut-devel">Mailing List</a>] </center>
@@ -48,7 +48,7 @@ </p>
<center> - [<a href="http://svn.mplayerhq.hu/nut/docs/nut.txt?view=co">Specification</a>] + [<a href="http://www1.mplayerhq.hu/~michael/nut.txt">Specification</a>] [<a href="http://lists.mplayerhq.hu/mailman/listinfo/nut-devel">Mailing List</a>] </center>
Ping, having a dangling link in the official page is not going to give a good impression on the casual reader...
ok
No commit rights...
Applied. -- FFmpeg = Fundamentalist and Fostering Mournful Powerful Enigmatic Generator
Stefano Sabatini <stefano.sabatini-lala at poste.it> writes:
On date Sunday 2010-03-21 15:49:59 +0100, Stefano Sabatini encoded:
- [<a href="http://svn.mplayerhq.hu/nut/docs/nut.txt?view=co">Specification</a>] + [<a href="http://www1.mplayerhq.hu/~michael/nut.txt">Specification</a>]
Ping, having a dangling link in the official page is not going to give a good impression on the casual reader...
The casual reader will probably have a brain meltdown should he encounter that text. :-) -- M?ns Rullg?rd mans at mansr.com
On Sun, Jan 10, 2010 at 5:36 AM, Stefano Sabatini <stefano.sabatini-lala at poste.it> wrote:
On date Saturday 2010-01-09 15:43:34 +0100, Michael Niedermayer encoded:
On Sat, Jan 09, 2010 at 02:58:30PM +0100, Stefano Sabatini wrote:
On date Friday 2010-01-08 03:48:37 +0100, Michael Niedermayer encoded:
also dont use avi as output but something that supports timestamps so they are tested as well (filters may change them)
Both avi and nut fail with some of the pixel formats supported, maybe I'll be more lucky with mp4/mov.
But I want to know if there is some way to fix them, for example for AVI there doesn't seem to be fourCC tags for some of the pixel formats we support, the same for NUT (we can maybe fix the latter extending its specs), anyway I believe we should fail if some pixel format is not supported during encoding.
Any thought?
read fourcc.org or M$ specs
Ah, funny that I have to read a third party site for something related to a M$ standard. This reminds me of why computer tech sucks so much.
read nut4cc.txt
From the mplayer/DOCS/tech/nut.txt
|the nut spec has been moved to another svn repo you can find it at: |http://svn.mplayerhq.hu/nut/docs/nut.txt?view=markup | |its future location will be in a git repository, ill update this file |here when its location changes again
The referenced page is missing.
Then I tried: http://nut-container.org/
The link to the specification leads nowhere.
I googled in search of some reference to the nut repo in vain.
Then I tried: svn list svn://svn.mplayerhq.hu/nut
and finally I got the repo.
Please fix the dangling links.
The links are valid, just that websvn isn't available anymore. Might I suggest pushing it to github/gitorious etc, it would be useful if people could view the documentation without having to create a checkout. -- Jai Menon
On Sun, Jan 10, 2010 at 12:08:30PM +0530, Jai Menon wrote:
On Sun, Jan 10, 2010 at 5:36 AM, Stefano Sabatini <stefano.sabatini-lala at poste.it> wrote:
On date Saturday 2010-01-09 15:43:34 +0100, Michael Niedermayer encoded:
On Sat, Jan 09, 2010 at 02:58:30PM +0100, Stefano Sabatini wrote:
On date Friday 2010-01-08 03:48:37 +0100, Michael Niedermayer encoded:
also dont use avi as output but something that supports timestamps so they are tested as well (filters may change them)
Both avi and nut fail with some of the pixel formats supported, maybe I'll be more lucky with mp4/mov.
But I want to know if there is some way to fix them, for example for AVI there doesn't seem to be fourCC tags for some of the pixel formats we support, the same for NUT (we can maybe fix the latter extending its specs), anyway I believe we should fail if some pixel format is not supported during encoding.
Any thought?
read fourcc.org or M$ specs
Ah, funny that I have to read a third party site for something related to a M$ standard. This reminds me of why computer tech sucks so much.
read nut4cc.txt
From the mplayer/DOCS/tech/nut.txt
|the nut spec has been moved to another svn repo you can find it at: |http://svn.mplayerhq.hu/nut/docs/nut.txt?view=markup | |its future location will be in a git repository, ill update this file |here when its location changes again
The referenced page is missing.
Then I tried: http://nut-container.org/
The link to the specification leads nowhere.
I googled in search of some reference to the nut repo in vain.
Then I tried: svn list svn://svn.mplayerhq.hu/nut
and finally I got the repo.
Please fix the dangling links.
The links are valid, just that websvn isn't available anymore. Might I suggest pushing it to github/gitorious etc, it would be useful if people could view the documentation without having to create a checkout.
or someone could just make a cronjob that does svn up and put that on a public http accessable directory [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf
On Sun, Jan 10, 2010 at 4:49 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
On Sun, Jan 10, 2010 at 12:08:30PM +0530, Jai Menon wrote:
On Sun, Jan 10, 2010 at 5:36 AM, Stefano Sabatini <stefano.sabatini-lala at poste.it> wrote:
On date Saturday 2010-01-09 15:43:34 +0100, Michael Niedermayer encoded:
On Sat, Jan 09, 2010 at 02:58:30PM +0100, Stefano Sabatini wrote:
On date Friday 2010-01-08 03:48:37 +0100, Michael Niedermayer encoded:
also dont use avi as output but something that supports timestamps so they are tested as well (filters may change them)
Both avi and nut fail with some of the pixel formats supported, maybe I'll be more lucky with mp4/mov.
But I want to know if there is some way to fix them, for example for AVI there doesn't seem to be fourCC tags for some of the pixel formats we support, the same for NUT (we can maybe fix the latter extending its specs), anyway I believe we should fail if some pixel format is not supported during encoding.
Any thought?
read fourcc.org or M$ specs
Ah, funny that I have to read a third party site for something related to a M$ standard. This reminds me of why computer tech sucks so much.
read nut4cc.txt
From the mplayer/DOCS/tech/nut.txt
|the nut spec has been moved to another svn repo you can find it at: |http://svn.mplayerhq.hu/nut/docs/nut.txt?view=markup | |its future location will be in a git repository, ill update this file |here when its location changes again
The referenced page is missing.
Then I tried: http://nut-container.org/
The link to the specification leads nowhere.
I googled in search of some reference to the nut repo in vain.
Then I tried: svn list svn://svn.mplayerhq.hu/nut
and finally I got the repo.
Please fix the dangling links.
The links are valid, just that websvn isn't available anymore. Might I suggest pushing it to github/gitorious etc, it would be useful if people could view the documentation without having to create a checkout.
or someone could just make a cronjob that does svn up and put that on a public http accessable directory
Sure that works too. The publically hosted git repo could be done by anyone. This however requires root at mphq's help :) -- Jai Menon
On Sun, Jan 10, 2010 at 05:01:44PM +0530, Jai Menon wrote:
On Sun, Jan 10, 2010 at 4:49 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
On Sun, Jan 10, 2010 at 12:08:30PM +0530, Jai Menon wrote:
On Sun, Jan 10, 2010 at 5:36 AM, Stefano Sabatini <stefano.sabatini-lala at poste.it> wrote:
On date Saturday 2010-01-09 15:43:34 +0100, Michael Niedermayer encoded:
On Sat, Jan 09, 2010 at 02:58:30PM +0100, Stefano Sabatini wrote:
On date Friday 2010-01-08 03:48:37 +0100, Michael Niedermayer encoded: > also dont use avi as output but something that supports timestamps so > they are tested as well (filters may change them)
Both avi and nut fail with some of the pixel formats supported, maybe I'll be more lucky with mp4/mov.
But I want to know if there is some way to fix them, for example for AVI there doesn't seem to be fourCC tags for some of the pixel formats we support, the same for NUT (we can maybe fix the latter extending its specs), anyway I believe we should fail if some pixel format is not supported during encoding.
Any thought?
read fourcc.org or M$ specs
Ah, funny that I have to read a third party site for something related to a M$ standard. This reminds me of why computer tech sucks so much.
read nut4cc.txt
From the mplayer/DOCS/tech/nut.txt
|the nut spec has been moved to another svn repo you can find it at: |http://svn.mplayerhq.hu/nut/docs/nut.txt?view=markup | |its future location will be in a git repository, ill update this file |here when its location changes again
The referenced page is missing.
Then I tried: http://nut-container.org/
The link to the specification leads nowhere.
I googled in search of some reference to the nut repo in vain.
Then I tried: svn list svn://svn.mplayerhq.hu/nut
and finally I got the repo.
Please fix the dangling links.
The links are valid, just that websvn isn't available anymore. Might I suggest pushing it to github/gitorious etc, it would be useful if people could view the documentation without having to create a checkout.
or someone could just make a cronjob that does svn up and put that on a public http accessable directory
Sure that works too. The publically hosted git repo could be done by anyone. This however requires root at mphq's help :)
no roots needed just one of many people needs to sit down and spend a few minutes i could do it but iam too busy and lack motivation actually i do have a nut.txt on www1.mplayerhq.hu/~michael but theres no cronjob updating that so it may be outdated [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope
On date Thursday 2010-01-07 23:36:02 +0100, Stefano Sabatini encoded:
On date Monday 2009-12-28 00:58:55 +0100, Stefano Sabatini encoded:
On date Sunday 2009-12-13 03:33:18 +0100, Michael Niedermayer encoded:
On Sun, Dec 13, 2009 at 01:52:41AM +0100, Stefano Sabatini wrote: [...]
and then each filter should be individually tested against all colorspaces.
Not every pixel format will be in general supported, so we may manually add a list of supported formats. Even better would be to add some interface to expose the set of supported inputs (though not sure this is possible, especially considering the scale filter).
you are searching for query_formats() ?
Well at least now I have a tool for exposing that info.
BTW: make show-filter-formats; and show-filter-formats scale 100:100 make: `show-filter-formats' is up to date. [...] I believe all the HW accelerated formats should be avoided, right?
Also how to feed a filter with video formats for which we cannot write in output (I mean pal formats)? I'm asking since for today I run out of ideas and asking is soo easy...
First implementation of the test system, with ad-hoc per-feature tests and one test for each filter/input pixel format combination, useful for testing one-input / one-output filters.
New attempt to get this stuff committed readjusted to the new modular test system. The lavfi test system implementated here has still many limitations, which I'll enumerate later, but it should be a nice start and it will already enable some stuff useful for getting lavfi integration move on. Patches implement a first series of ad-hoc per-filters tests, slicification is implicitely tested randomizing the size of the input slices. For the slices size randomization I considered to use LCG, but then I saw that a trivial date '+%N' % MOD seemed to work quite fine and is less overkill. Current limitations: * with the new modular system is possible to compute the dependancy of the tested component, and only try a test if the corresponding component has been compiled in. In the case of filters things are trickier, as a single test requires the interaction of different components (e.g.: at least the slicify, scale filter and more). Since I bypassed this mechanism, "make lavfitest" will work only if *all* the components have been compiled in. Also note that the "make lavfitest" only works when libavfilter compilation has been enabled. * the used container format (AVI) is not ideal when we have timestamps, I plan to use NUT for this, if required I'll try to do this *before* to commit the first part. Also as noted in the thread both AVI and NUT have problems with many raw pixel formats, so we need somehow to extend/fix how they deal with FourCCs. Regards. -- FFmpeg = Formidable Faithful Mastodontic Pure Exploitable Guide
On date Sunday 2010-03-07 11:18:33 +0100, Stefano Sabatini encoded:
On date Thursday 2010-01-07 23:36:02 +0100, Stefano Sabatini encoded: [...] Patches implement a first series of ad-hoc per-filters tests, slicification is implicitely tested randomizing the size of the input slices.
For the slices size randomization I considered to use LCG, but then I saw that a trivial date '+%N' % MOD seemed to work quite fine and is less overkill.
Current limitations:
* with the new modular system is possible to compute the dependancy of the tested component, and only try a test if the corresponding component has been compiled in.
In the case of filters things are trickier, as a single test requires the interaction of different components (e.g.: at least the slicify, scale filter and more).
Since I bypassed this mechanism, "make lavfitest" will work only if *all* the components have been compiled in.
Also note that the "make lavfitest" only works when libavfilter compilation has been enabled.
* the used container format (AVI) is not ideal when we have timestamps, I plan to use NUT for this, if required I'll try to do this *before* to commit the first part.
Also as noted in the thread both AVI and NUT have problems with many raw pixel formats, so we need somehow to extend/fix how they deal with FourCCs.
Updated to make it use NUT. Regards. -- FFmpeg = Fierce and Friendly Magical Portable Elected Game
On Sun, Mar 07, 2010 at 04:20:16PM +0100, Stefano Sabatini wrote:
On date Sunday 2010-03-07 11:18:33 +0100, Stefano Sabatini encoded:
On date Thursday 2010-01-07 23:36:02 +0100, Stefano Sabatini encoded: [...] Index: libavfilter-soc/ffmpeg/tests/lavfi-regression.sh =================================================================== --- libavfilter-soc.orig/ffmpeg/tests/lavfi-regression.sh 2010-03-07 16:15:22.000000000 +0100 +++ libavfilter-soc/ffmpeg/tests/lavfi-regression.sh 2010-03-07 16:16:43.000000000 +0100 @@ -20,6 +20,8 @@ vfilters=$2
if [ -n "$test" ] ; then + slicify_h=$(expr 8 + $(date +%N) % 24) + vfilters=slicify=$slicify_h,$vfilters do_video_encoding ${test_name}.nut "" "-vcodec rawvideo -vfilters $vfilters" fi }
this is a problem because its not reproduceable an LCG started from a constant would be better [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus
On date Sunday 2010-03-07 17:44:20 +0100, Michael Niedermayer encoded:
On Sun, Mar 07, 2010 at 04:20:16PM +0100, Stefano Sabatini wrote:
On date Sunday 2010-03-07 11:18:33 +0100, Stefano Sabatini encoded:
On date Thursday 2010-01-07 23:36:02 +0100, Stefano Sabatini encoded: [...] Index: libavfilter-soc/ffmpeg/tests/lavfi-regression.sh =================================================================== --- libavfilter-soc.orig/ffmpeg/tests/lavfi-regression.sh 2010-03-07 16:15:22.000000000 +0100 +++ libavfilter-soc/ffmpeg/tests/lavfi-regression.sh 2010-03-07 16:16:43.000000000 +0100 @@ -20,6 +20,8 @@ vfilters=$2
if [ -n "$test" ] ; then + slicify_h=$(expr 8 + $(date +%N) % 24) + vfilters=slicify=$slicify_h,$vfilters do_video_encoding ${test_name}.nut "" "-vcodec rawvideo -vfilters $vfilters" fi }
this is a problem because its not reproduceable
an LCG started from a constant would be better
I believed the idea was to try different slicing at every run... what am I missing? Regards. -- FFmpeg = Frenzy and Fostering Miracolous Problematic Erroneous Guru
On Mon, Mar 08, 2010 at 02:36:14AM +0100, Stefano Sabatini wrote:
On date Sunday 2010-03-07 17:44:20 +0100, Michael Niedermayer encoded:
On Sun, Mar 07, 2010 at 04:20:16PM +0100, Stefano Sabatini wrote:
On date Sunday 2010-03-07 11:18:33 +0100, Stefano Sabatini encoded:
On date Thursday 2010-01-07 23:36:02 +0100, Stefano Sabatini encoded: [...] Index: libavfilter-soc/ffmpeg/tests/lavfi-regression.sh =================================================================== --- libavfilter-soc.orig/ffmpeg/tests/lavfi-regression.sh 2010-03-07 16:15:22.000000000 +0100 +++ libavfilter-soc/ffmpeg/tests/lavfi-regression.sh 2010-03-07 16:16:43.000000000 +0100 @@ -20,6 +20,8 @@ vfilters=$2
if [ -n "$test" ] ; then + slicify_h=$(expr 8 + $(date +%N) % 24) + vfilters=slicify=$slicify_h,$vfilters do_video_encoding ${test_name}.nut "" "-vcodec rawvideo -vfilters $vfilters" fi }
this is a problem because its not reproduceable
an LCG started from a constant would be better
I believed the idea was to try different slicing at every run... what am I missing?
we dont want spurious unreproduceable failures or other way around spurious unreproduceable successes in teh test wen they should fail it makes debuging hard ...
Regards. -- FFmpeg = Frenzy and Fostering Miracolous Problematic Erroneous Guru
lavfi-regression.sh | 10 ++++++++++ 1 file changed, 10 insertions(+) b361118ffebf15ed75e0bac79f4aa27b4d20d371 randomize-lavfi-test-slice-sizes.patch Index: libavfilter-soc/ffmpeg/tests/lavfi-regression.sh =================================================================== --- libavfilter-soc.orig/ffmpeg/tests/lavfi-regression.sh 2010-03-07 16:17:19.000000000 +0100 +++ libavfilter-soc/ffmpeg/tests/lavfi-regression.sh 2010-03-08 02:29:41.000000000 +0100 @@ -14,12 +14,22 @@ rm -f "$logfile" rm -f "$benchfile"
+get_lcg() +{ + echo "65539 * $1 % (2^31-1)" | bc
where does this generator come from? and why dont you use the generator we use elsewhere in ffmpeg? also what should be used as random value is the scaled down value not the modulo something value like you do later. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 3 "Rare item" - "Common item with rare defect or maybe just a lie" "Professional" - "'Toy' made in china, not functional except as doorstop" "Experts will know" - "The seller hopes you are not an expert"
On date Monday 2010-03-08 03:17:11 +0100, Michael Niedermayer encoded:
On Mon, Mar 08, 2010 at 02:36:14AM +0100, Stefano Sabatini wrote:
On date Sunday 2010-03-07 17:44:20 +0100, Michael Niedermayer encoded:
On Sun, Mar 07, 2010 at 04:20:16PM +0100, Stefano Sabatini wrote:
On date Sunday 2010-03-07 11:18:33 +0100, Stefano Sabatini encoded:
On date Thursday 2010-01-07 23:36:02 +0100, Stefano Sabatini encoded: [...] Index: libavfilter-soc/ffmpeg/tests/lavfi-regression.sh =================================================================== --- libavfilter-soc.orig/ffmpeg/tests/lavfi-regression.sh 2010-03-07 16:15:22.000000000 +0100 +++ libavfilter-soc/ffmpeg/tests/lavfi-regression.sh 2010-03-07 16:16:43.000000000 +0100 @@ -20,6 +20,8 @@ vfilters=$2
if [ -n "$test" ] ; then + slicify_h=$(expr 8 + $(date +%N) % 24) + vfilters=slicify=$slicify_h,$vfilters do_video_encoding ${test_name}.nut "" "-vcodec rawvideo -vfilters $vfilters" fi }
this is a problem because its not reproduceable
an LCG started from a constant would be better
I believed the idea was to try different slicing at every run... what am I missing?
we dont want spurious unreproduceable failures or other way around spurious unreproduceable successes in teh test wen they should fail it makes debuging hard ...
I agree but this way we are using only a limited subset of slice values. Another solution would be to iterate a few times each test with different slice height values taken from a pseudo random sequence. Would this be OK?
Regards. -- FFmpeg = Frenzy and Fostering Miracolous Problematic Erroneous Guru
lavfi-regression.sh | 10 ++++++++++ 1 file changed, 10 insertions(+) b361118ffebf15ed75e0bac79f4aa27b4d20d371 randomize-lavfi-test-slice-sizes.patch Index: libavfilter-soc/ffmpeg/tests/lavfi-regression.sh =================================================================== --- libavfilter-soc.orig/ffmpeg/tests/lavfi-regression.sh 2010-03-07 16:17:19.000000000 +0100 +++ libavfilter-soc/ffmpeg/tests/lavfi-regression.sh 2010-03-08 02:29:41.000000000 +0100 @@ -14,12 +14,22 @@ rm -f "$logfile" rm -f "$benchfile"
+get_lcg() +{ + echo "65539 * $1 % (2^31-1)" | bc
where does this generator come from?
Uh an experiment of mine, I did some little tests on it and it looked good enough for this application.
and why dont you use the generator we use elsewhere in ffmpeg?
Do you mean av_lfg_get()? Are you suggesting that I should use a C program (lfg_get.c) for generating such a sequence?
also what should be used as random value is the scaled down value not the modulo something value like you do later.
I have to say that I lack the understanding of the theory behind, please if you can give a very short explanation, I'm looking at the code using av_lfg_get() and most of the times a modulo operation is performed. Regards. -- FFmpeg = Fiendish & Fanciful Mastering Ponderous Erroneous God
On Mon, Mar 08, 2010 at 10:40:02PM +0100, Stefano Sabatini wrote:
On date Monday 2010-03-08 03:17:11 +0100, Michael Niedermayer encoded:
On Mon, Mar 08, 2010 at 02:36:14AM +0100, Stefano Sabatini wrote:
On date Sunday 2010-03-07 17:44:20 +0100, Michael Niedermayer encoded:
On Sun, Mar 07, 2010 at 04:20:16PM +0100, Stefano Sabatini wrote:
On date Sunday 2010-03-07 11:18:33 +0100, Stefano Sabatini encoded:
On date Thursday 2010-01-07 23:36:02 +0100, Stefano Sabatini encoded: [...] Index: libavfilter-soc/ffmpeg/tests/lavfi-regression.sh =================================================================== --- libavfilter-soc.orig/ffmpeg/tests/lavfi-regression.sh 2010-03-07 16:15:22.000000000 +0100 +++ libavfilter-soc/ffmpeg/tests/lavfi-regression.sh 2010-03-07 16:16:43.000000000 +0100 @@ -20,6 +20,8 @@ vfilters=$2
if [ -n "$test" ] ; then + slicify_h=$(expr 8 + $(date +%N) % 24) + vfilters=slicify=$slicify_h,$vfilters do_video_encoding ${test_name}.nut "" "-vcodec rawvideo -vfilters $vfilters" fi }
this is a problem because its not reproduceable
an LCG started from a constant would be better
I believed the idea was to try different slicing at every run... what am I missing?
we dont want spurious unreproduceable failures or other way around spurious unreproduceable successes in teh test wen they should fail it makes debuging hard ...
I agree but this way we are using only a limited subset of slice values.
true, could we postpone resolving this though. having some regression tests is very important testing all slice sizes is not that important
Another solution would be to iterate a few times each test with different slice height values taken from a pseudo random sequence. Would this be OK?
that slows it down proportionally maybe we could add a "r" parameter to slicify to make it produce deterministic but random slice sizes that would test more than a single size for a video
Regards. -- FFmpeg = Frenzy and Fostering Miracolous Problematic Erroneous Guru
lavfi-regression.sh | 10 ++++++++++ 1 file changed, 10 insertions(+) b361118ffebf15ed75e0bac79f4aa27b4d20d371 randomize-lavfi-test-slice-sizes.patch Index: libavfilter-soc/ffmpeg/tests/lavfi-regression.sh =================================================================== --- libavfilter-soc.orig/ffmpeg/tests/lavfi-regression.sh 2010-03-07 16:17:19.000000000 +0100 +++ libavfilter-soc/ffmpeg/tests/lavfi-regression.sh 2010-03-08 02:29:41.000000000 +0100 @@ -14,12 +14,22 @@ rm -f "$logfile" rm -f "$benchfile"
+get_lcg() +{ + echo "65539 * $1 % (2^31-1)" | bc
where does this generator come from?
Uh an experiment of mine, I did some little tests on it and it looked good enough for this application.
dont try to be smarter than scientists who spend years analyzing the properties of these generators.
and why dont you use the generator we use elsewhere in ffmpeg?
Do you mean av_lfg_get()? Are you suggesting that I should use a C program (lfg_get.c) for generating such a sequence?
use this: state= state*1664525+1013904223 and dont forget to use *24 >>32, do not use %24
also what should be used as random value is the scaled down value not the modulo something value like you do later.
I have to say that I lack the understanding of the theory behind, please if you can give a very short explanation, I'm looking at the code using av_lfg_get() and most of the times a modulo operation is performed.
just use a proofen standard generator dont invent your own, someone knuth? said something like, random functions are poor random number genrators this one hits the key issue ... If you want to design a better LCG, look at some prng test programs like the diehard tests or TestU01 (note some of the soucre code [maybe debian package?] of diehard was in a very sorry state you wont get that one working correctly if its still in that condition) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
On date Monday 2010-03-08 23:02:10 +0100, Michael Niedermayer encoded:
On Mon, Mar 08, 2010 at 10:40:02PM +0100, Stefano Sabatini wrote:
On date Monday 2010-03-08 03:17:11 +0100, Michael Niedermayer encoded:
On Mon, Mar 08, 2010 at 02:36:14AM +0100, Stefano Sabatini wrote:
On date Sunday 2010-03-07 17:44:20 +0100, Michael Niedermayer encoded:
On Sun, Mar 07, 2010 at 04:20:16PM +0100, Stefano Sabatini wrote:
On date Sunday 2010-03-07 11:18:33 +0100, Stefano Sabatini encoded: > On date Thursday 2010-01-07 23:36:02 +0100, Stefano Sabatini encoded: [...] Index: libavfilter-soc/ffmpeg/tests/lavfi-regression.sh =================================================================== --- libavfilter-soc.orig/ffmpeg/tests/lavfi-regression.sh 2010-03-07 16:15:22.000000000 +0100 +++ libavfilter-soc/ffmpeg/tests/lavfi-regression.sh 2010-03-07 16:16:43.000000000 +0100 @@ -20,6 +20,8 @@ vfilters=$2
if [ -n "$test" ] ; then + slicify_h=$(expr 8 + $(date +%N) % 24) + vfilters=slicify=$slicify_h,$vfilters do_video_encoding ${test_name}.nut "" "-vcodec rawvideo -vfilters $vfilters" fi }
this is a problem because its not reproduceable
an LCG started from a constant would be better
I believed the idea was to try different slicing at every run... what am I missing?
we dont want spurious unreproduceable failures or other way around spurious unreproduceable successes in teh test wen they should fail it makes debuging hard ...
I agree but this way we are using only a limited subset of slice values.
true, could we postpone resolving this though. having some regression tests is very important testing all slice sizes is not that important
Another solution would be to iterate a few times each test with different slice height values taken from a pseudo random sequence. Would this be OK?
that slows it down proportionally maybe we could add a "r" parameter to slicify to make it produce deterministic but random slice sizes that would test more than a single size for a video
Thinking more about it, that looked like the best solution, see the attached patch (which depends on that one extending slicify which I just posted in a new thread).
Regards. -- FFmpeg = Frenzy and Fostering Miracolous Problematic Erroneous Guru
lavfi-regression.sh | 10 ++++++++++ 1 file changed, 10 insertions(+) b361118ffebf15ed75e0bac79f4aa27b4d20d371 randomize-lavfi-test-slice-sizes.patch Index: libavfilter-soc/ffmpeg/tests/lavfi-regression.sh =================================================================== --- libavfilter-soc.orig/ffmpeg/tests/lavfi-regression.sh 2010-03-07 16:17:19.000000000 +0100 +++ libavfilter-soc/ffmpeg/tests/lavfi-regression.sh 2010-03-08 02:29:41.000000000 +0100 @@ -14,12 +14,22 @@ rm -f "$logfile" rm -f "$benchfile"
+get_lcg() +{ + echo "65539 * $1 % (2^31-1)" | bc
where does this generator come from?
Uh an experiment of mine, I did some little tests on it and it looked good enough for this application.
dont try to be smarter than scientists who spend years analyzing the properties of these generators.
and why dont you use the generator we use elsewhere in ffmpeg?
Do you mean av_lfg_get()? Are you suggesting that I should use a C program (lfg_get.c) for generating such a sequence?
use this: state= state*1664525+1013904223
and dont forget to use *24 >>32, do not use %24
I came out wit this: lcg_get() { echo "($1 * 1664525 + 1013904223) % 2^32" | bc; } bc does not know shift operators.
also what should be used as random value is the scaled down value not the modulo something value like you do later.
I have to say that I lack the understanding of the theory behind, please if you can give a very short explanation, I'm looking at the code using av_lfg_get() and most of the times a modulo operation is performed.
just use a proofen standard generator dont invent your own, someone knuth? said something like, random functions are poor random number genrators this one hits the key issue ...
If you want to design a better LCG, look at some prng test programs like the diehard tests or TestU01 (note some of the soucre code [maybe debian package?] of diehard was in a very sorry state you wont get that one working correctly if its still in that condition)
Thanks for the explanation, I took a quickly study into PRNG, the one you suggest seems the same adopted/proposed in Numerical Recipes. Regards. -- FFmpeg = Furious and Fascinating Mythic Power Enlightening Genius
Stefano Sabatini <stefano.sabatini-lala at poste.it> writes:
Do you mean av_lfg_get()? Are you suggesting that I should use a C program (lfg_get.c) for generating such a sequence?
use this: state= state*1664525+1013904223
and dont forget to use *24 >>32, do not use %24
I came out wit this:
lcg_get() { echo "($1 * 1664525 + 1013904223) % 2^32" | bc; }
bc does not know shift operators.
No need for bc. Use the shell arithmetic expansion $((expression)). This knows all the standard C integer operators except ++ and --. http://www.opengroup.org/onlinepubs/000095399/utilities/xcu_chap02.html#tag_... -- M?ns Rullg?rd mans at mansr.com
On date Wednesday 2010-03-10 01:59:10 +0100, Stefano Sabatini encoded:
On date Monday 2010-03-08 23:02:10 +0100, Michael Niedermayer encoded:
On Mon, Mar 08, 2010 at 10:40:02PM +0100, Stefano Sabatini wrote:
On date Monday 2010-03-08 03:17:11 +0100, Michael Niedermayer encoded:
we dont want spurious unreproduceable failures or other way around spurious unreproduceable successes in teh test wen they should fail it makes debuging hard ...
I agree but this way we are using only a limited subset of slice values.
true, could we postpone resolving this though. having some regression tests is very important testing all slice sizes is not that important
Another solution would be to iterate a few times each test with different slice height values taken from a pseudo random sequence. Would this be OK?
that slows it down proportionally maybe we could add a "r" parameter to slicify to make it produce deterministic but random slice sizes that would test more than a single size for a video
Thinking more about it, that looked like the best solution, see the attached patch (which depends on that one extending slicify which I just posted in a new thread).
Patches updated. Regards. -- FFmpeg = Faithful & Fanciful Multipurpose Proud Ecumenical Gorilla
On Sat, Mar 13, 2010 at 01:20:01PM +0100, Stefano Sabatini wrote:
On date Wednesday 2010-03-10 01:59:10 +0100, Stefano Sabatini encoded:
On date Monday 2010-03-08 23:02:10 +0100, Michael Niedermayer encoded:
On Mon, Mar 08, 2010 at 10:40:02PM +0100, Stefano Sabatini wrote:
On date Monday 2010-03-08 03:17:11 +0100, Michael Niedermayer encoded:
we dont want spurious unreproduceable failures or other way around spurious unreproduceable successes in teh test wen they should fail it makes debuging hard ...
I agree but this way we are using only a limited subset of slice values.
true, could we postpone resolving this though. having some regression tests is very important testing all slice sizes is not that important
Another solution would be to iterate a few times each test with different slice height values taken from a pseudo random sequence. Would this be OK?
that slows it down proportionally maybe we could add a "r" parameter to slicify to make it produce deterministic but random slice sizes that would test more than a single size for a video
Thinking more about it, that looked like the best solution, see the attached patch (which depends on that one extending slicify which I just posted in a new thread).
Patches updated.
fine with me but this is more mans area of maintaince so he should ok it as well [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you really think that XML is the answer, then you definitly missunderstood the question -- Attila Kinali
On date Saturday 2010-03-13 20:30:58 +0100, Michael Niedermayer encoded:
On Sat, Mar 13, 2010 at 01:20:01PM +0100, Stefano Sabatini wrote: [...]
Patches updated.
fine with me but this is more mans area of maintaince so he should ok it as well
Mans ping... -- FFmpeg = Fanciful Fostering Meaningless Puritan Elastic Goblin
Stefano Sabatini <stefano.sabatini-lala at poste.it> writes:
On date Wednesday 2010-03-10 01:59:10 +0100, Stefano Sabatini encoded:
On date Monday 2010-03-08 23:02:10 +0100, Michael Niedermayer encoded:
On Mon, Mar 08, 2010 at 10:40:02PM +0100, Stefano Sabatini wrote:
On date Monday 2010-03-08 03:17:11 +0100, Michael Niedermayer encoded:
we dont want spurious unreproduceable failures or other way around spurious unreproduceable successes in teh test wen they should fail it makes debuging hard ...
I agree but this way we are using only a limited subset of slice values.
true, could we postpone resolving this though. having some regression tests is very important testing all slice sizes is not that important
Another solution would be to iterate a few times each test with different slice height values taken from a pseudo random sequence. Would this be OK?
that slows it down proportionally maybe we could add a "r" parameter to slicify to make it produce deterministic but random slice sizes that would test more than a single size for a video
Thinking more about it, that looked like the best solution, see the attached patch (which depends on that one extending slicify which I just posted in a new thread).
Patches updated.
Regards. -- FFmpeg = Faithful & Fanciful Multipurpose Proud Ecumenical Gorilla
Index: libavfilter-soc/ffmpeg/Makefile =================================================================== --- libavfilter-soc.orig/ffmpeg/Makefile 2010-03-13 11:45:37.000000000 +0100 +++ libavfilter-soc/ffmpeg/Makefile 2010-03-13 12:05:18.000000000 +0100 @@ -250,7 +250,18 @@ LAVF_TESTS-$(call MUXDEM,WAV) += wav LAVF_TESTS-$(call MUXDEM,YUV4MPEGPIPE) += yuv4mpeg
-LAVFI_TEST= +LAVFI_TESTS = \ +crop \ +crop_scale \ +crop_scale_vflip \ +crop_vflip \ +null \ +scale200 \ +scale500 \ +vflip \ +vflip_crop \ +vflip_vflip \ +
Please indent the continuation lines a bit.
ACODEC_TESTS := $(addprefix regtest-, $(ACODEC_TESTS) $(ACODEC_TESTS-yes)) VCODEC_TESTS := $(addprefix regtest-, $(VCODEC_TESTS) $(VCODEC_TESTS-yes)) @@ -261,8 +272,7 @@
codectest: $(CODEC_TESTS) lavftest: $(LAVF_TESTS) - -# lavfitest: $(LAVFI_TESTS) +lavfitest: $(LAVFI_TESTS)
$(ACODEC_TESTS): regtest-aref $(VCODEC_TESTS): regtest-vref Index: libavfilter-soc/ffmpeg/tests/lavfi-regression.sh =================================================================== --- libavfilter-soc.orig/ffmpeg/tests/lavfi-regression.sh 2010-03-13 11:42:05.000000000 +0100 +++ libavfilter-soc/ffmpeg/tests/lavfi-regression.sh 2010-03-13 12:05:18.000000000 +0100 @@ -20,14 +20,20 @@ vfilters=$2
if [ -n "$test" ] ; then - do_video_encoding ${test_name}.avi "" "-vcodec rawvideo -vfilters $vfilters" + do_video_encoding ${test_name}.nut "" "-vcodec rawvideo -vfilters $vfilters" fi }
-# example tests: -# do_lavfi "crop" "crop=100:100:-1:-1" -# do_lavfi "crop_scale" "crop=100:100,scale=200:-1" -# do_lavfi "scale" "scale=200:200" +do_lavfi "crop" "crop=100:100" +do_lavfi "crop_scale" "crop=100:100,scale=400:-1" +do_lavfi "crop_scale_vflip" "null,null,crop=200:200,crop=20:20,scale=200:200,scale=250:250,vflip,vflip,null,scale=200:200,crop=100:100,vflip,scale=200:200,null,vflip,crop=100:100,null" +do_lavfi "crop_vflip" "crop=100:100,vflip" +do_lavfi "null" "null" +do_lavfi "scale200" "scale=200:200" +do_lavfi "scale500" "scale=500:500" +do_lavfi "vflip" "vflip" +do_lavfi "vflip_crop" "vflip,crop=100:100" +do_lavfi "vflip_vflip" "vflip,vflip"
Looks good enough. Maybe we want to parallelise these tests later, but that can wait. -- M?ns Rullg?rd mans at mansr.com
On date Sunday 2010-03-14 23:53:52 +0000, M?ns Rullg?rd encoded:
Stefano Sabatini <stefano.sabatini-lala at poste.it> writes:
On date Wednesday 2010-03-10 01:59:10 +0100, Stefano Sabatini encoded:
On date Monday 2010-03-08 23:02:10 +0100, Michael Niedermayer encoded:
On Mon, Mar 08, 2010 at 10:40:02PM +0100, Stefano Sabatini wrote:
On date Monday 2010-03-08 03:17:11 +0100, Michael Niedermayer encoded:
we dont want spurious unreproduceable failures or other way around spurious unreproduceable successes in teh test wen they should fail it makes debuging hard ...
I agree but this way we are using only a limited subset of slice values.
true, could we postpone resolving this though. having some regression tests is very important testing all slice sizes is not that important
Another solution would be to iterate a few times each test with different slice height values taken from a pseudo random sequence. Would this be OK?
that slows it down proportionally maybe we could add a "r" parameter to slicify to make it produce deterministic but random slice sizes that would test more than a single size for a video
Thinking more about it, that looked like the best solution, see the attached patch (which depends on that one extending slicify which I just posted in a new thread).
Patches updated.
Regards. -- FFmpeg = Faithful & Fanciful Multipurpose Proud Ecumenical Gorilla
Index: libavfilter-soc/ffmpeg/Makefile =================================================================== --- libavfilter-soc.orig/ffmpeg/Makefile 2010-03-13 11:45:37.000000000 +0100 +++ libavfilter-soc/ffmpeg/Makefile 2010-03-13 12:05:18.000000000 +0100 @@ -250,7 +250,18 @@ LAVF_TESTS-$(call MUXDEM,WAV) += wav LAVF_TESTS-$(call MUXDEM,YUV4MPEGPIPE) += yuv4mpeg
-LAVFI_TEST= +LAVFI_TESTS = \ +crop \ +crop_scale \ +crop_scale_vflip \ +crop_vflip \ +null \ +scale200 \ +scale500 \ +vflip \ +vflip_crop \ +vflip_vflip \ +
Please indent the continuation lines a bit.
Now that I committed I'm not sure it's what you intended, you're free to perform cosmetics changes of course.
ACODEC_TESTS := $(addprefix regtest-, $(ACODEC_TESTS) $(ACODEC_TESTS-yes)) VCODEC_TESTS := $(addprefix regtest-, $(VCODEC_TESTS) $(VCODEC_TESTS-yes)) @@ -261,8 +272,7 @@
codectest: $(CODEC_TESTS) lavftest: $(LAVF_TESTS) - -# lavfitest: $(LAVFI_TESTS) +lavfitest: $(LAVFI_TESTS)
$(ACODEC_TESTS): regtest-aref $(VCODEC_TESTS): regtest-vref Index: libavfilter-soc/ffmpeg/tests/lavfi-regression.sh =================================================================== --- libavfilter-soc.orig/ffmpeg/tests/lavfi-regression.sh 2010-03-13 11:42:05.000000000 +0100 +++ libavfilter-soc/ffmpeg/tests/lavfi-regression.sh 2010-03-13 12:05:18.000000000 +0100 @@ -20,14 +20,20 @@ vfilters=$2
if [ -n "$test" ] ; then - do_video_encoding ${test_name}.avi "" "-vcodec rawvideo -vfilters $vfilters" + do_video_encoding ${test_name}.nut "" "-vcodec rawvideo -vfilters $vfilters" fi }
-# example tests: -# do_lavfi "crop" "crop=100:100:-1:-1" -# do_lavfi "crop_scale" "crop=100:100,scale=200:-1" -# do_lavfi "scale" "scale=200:200" +do_lavfi "crop" "crop=100:100" +do_lavfi "crop_scale" "crop=100:100,scale=400:-1" +do_lavfi "crop_scale_vflip" "null,null,crop=200:200,crop=20:20,scale=200:200,scale=250:250,vflip,vflip,null,scale=200:200,crop=100:100,vflip,scale=200:200,null,vflip,crop=100:100,null" +do_lavfi "crop_vflip" "crop=100:100,vflip" +do_lavfi "null" "null" +do_lavfi "scale200" "scale=200:200" +do_lavfi "scale500" "scale=500:500" +do_lavfi "vflip" "vflip" +do_lavfi "vflip_crop" "vflip,crop=100:100" +do_lavfi "vflip_vflip" "vflip,vflip"
Looks good enough. Maybe we want to parallelise these tests later, but that can wait.
Excellent, committed! The test system is still incomplete, I'll post the continuation as a separate thread (also I still have to fix somehow the fourCC trouble). Regards. -- FFmpeg = Fundamental Fabulous Marvellous Programmable Everlasting Gargoyle
participants (7)
-
diego＠biurrun.de -
jmenon86＠gmail.com -
kostya.shishkov＠gmail.com -
mans＠mansr.com -
michaelni＠gmx.at -
stefano.sabatini-lala＠poste.it -
vitor1001＠gmail.com