Re: [FFmpeg-devel] [PATCH]Fix pnm encoding with bpc set
On 25.08.2014, at 19:33, Christophe Gisquet christophe.gisq...@gmail.com wrote: Hi, 2014-08-25 6:41 GMT+02:00 Reimar Döffinger reimar.doeffin...@gmx.de: The colorspace is supposed to be authoritative. If it says 16 bit, then showing it as 16 bit must work properly. The only intention of bits_per_raw_sample is to indicate that there is no point in storing some of the lower bits if you have the option. ie, actually writing a smaller bitdepth, like what was achieved for ppm by my patch and Carl Eugen's ? I find this very inconvenient for 2 things: - you force an additional roundtrip to 16bps when going eg 12bps to 12bps, while forcing 16bps just moves the scaling from the decoder to outside (ok that's one additional copy) There is no round trip really just an additional shift on reading and writing. - you need to maintain different buffers for predictive codecs (ie both the encoder and the decoder), one being what is actually coded, and the other for the output of the decoder/input of the encoder (though it is not an actual full copy and can just be done in coding units eg MB) Currently no relevant codecs use 12 bits, which is the reason why 9 and 10 bits exist as separate formats while 12 bits does not. For simple formats, doing a val = (val 4) | (val 12) before each store is completely acceptable. Amd for reference frames you certainly do not need an actual full copy, that would be silly, you just need to add a shift after each load. I don't think I can have time both for convincing you and CE of this, then implement fixes everywhere needed, then introduce incompatible APIs, so just read this as a statement of my opinion, and let's close the subject. I have understood this line of thought is futile. I don't have a particular opinion on what the design should be, I am just describing how it was intended. That can be solved by a common function if necessary, alternatively a 12 bit colorspace could be added, but the cost/benefit is questionable. I think at this point they all have in common sample storage rounded to the upper bytecount and raw_bits is indicative of what they hold. Adding them is just going to make the scalers more tentacular. But my opinion of moving the scaling from the decoder to a specialized function also does this. There is the additional issue that it (just like changing the meaning of raw bits) will require each application to add support for it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain
On Tue, Aug 26, 2014 at 11:16:24AM +0200, Clément Bœsch wrote: On Tue, Aug 26, 2014 at 01:42:17AM +0200, Michael Niedermayer wrote: From: Andreas Cadhalpun andreas.cadhal...@googlemail.com --- LICENSE.md |1 + tests/Makefile |2 +- tests/flower.pnm | Bin 0 - 196623 bytes tests/lena.pnm | 109 tests/ref/fate/force_key_frames|8 +- tests/ref/fate/sub2video | 100 - tests/ref/seek/vsynth2-asv1| 40 +- tests/ref/seek/vsynth2-asv2| 40 +- tests/ref/seek/vsynth2-ffv1| 40 +- tests/ref/seek/vsynth2-flashsv | 40 +- tests/ref/seek/vsynth2-flv | 40 +- tests/ref/seek/vsynth2-h261| 40 +- tests/ref/seek/vsynth2-h263| 40 +- tests/ref/seek/vsynth2-h263p | 40 +- tests/ref/seek/vsynth2-huffyuv | 40 +- tests/ref/seek/vsynth2-jpegls | 40 +- tests/ref/seek/vsynth2-ljpeg | 40 +- tests/ref/seek/vsynth2-mjpeg | 40 +- tests/ref/seek/vsynth2-mpeg1 | 40 +- tests/ref/seek/vsynth2-mpeg1b | 40 +- tests/ref/seek/vsynth2-mpeg2-422 | 40 +- tests/ref/seek/vsynth2-mpeg2-idct-int | 40 +- tests/ref/seek/vsynth2-mpeg2-ilace | 40 +- tests/ref/seek/vsynth2-mpeg2-ivlc-qprd | 40 +- tests/ref/seek/vsynth2-mpeg2-thread| 40 +- tests/ref/seek/vsynth2-mpeg2-thread-ivlc | 40 +- tests/ref/seek/vsynth2-mpeg4 | 48 ++-- tests/ref/seek/vsynth2-mpeg4-adap | 40 +- tests/ref/seek/vsynth2-mpeg4-adv | 40 +- tests/ref/seek/vsynth2-mpeg4-error | 40 +- tests/ref/seek/vsynth2-mpeg4-nr| 40 +- tests/ref/seek/vsynth2-mpeg4-nsse | 40 +- tests/ref/seek/vsynth2-mpeg4-qpel | 40 +- tests/ref/seek/vsynth2-mpeg4-qprd | 40 +- tests/ref/seek/vsynth2-mpeg4-rc| 40 +- tests/ref/seek/vsynth2-mpeg4-thread| 40 +- tests/ref/seek/vsynth2-msmpeg4 | 40 +- tests/ref/seek/vsynth2-msmpeg4v2 | 40 +- tests/ref/seek/vsynth2-roqvideo|2 +- tests/ref/seek/vsynth2-rv10| 55 +++--- tests/ref/seek/vsynth2-rv20| 54 +++--- tests/ref/seek/vsynth2-snow| 40 +- tests/ref/seek/vsynth2-snow-ll | 40 +- tests/ref/seek/vsynth2-svq1| 48 ++-- tests/ref/seek/vsynth2-wmv1| 40 +- tests/ref/seek/vsynth2-wmv2| 40 +- tests/ref/vsynth/vsynth2-amv |8 +- tests/ref/vsynth/vsynth2-asv1 |8 +- tests/ref/vsynth/vsynth2-asv2 |8 +- tests/ref/vsynth/vsynth2-avui |4 +- tests/ref/vsynth/vsynth2-cljr |6 +- tests/ref/vsynth/vsynth2-dnxhd-1080i |6 +- tests/ref/vsynth/vsynth2-dnxhd-720p|6 +- tests/ref/vsynth/vsynth2-dnxhd-720p-10bit |6 +- tests/ref/vsynth/vsynth2-dnxhd-720p-rd |6 +- tests/ref/vsynth/vsynth2-dv|6 +- tests/ref/vsynth/vsynth2-dv-411|6 +- tests/ref/vsynth/vsynth2-dv-50 |6 +- tests/ref/vsynth/vsynth2-ffv1 |6 +- tests/ref/vsynth/vsynth2-ffv1.0|6 +- tests/ref/vsynth/vsynth2-ffvhuff |6 +- tests/ref/vsynth/vsynth2-ffvhuff420p12 |8 +- tests/ref/vsynth/vsynth2-ffvhuff422p10left |8 +- tests/ref/vsynth/vsynth2-ffvhuff444|8 +- tests/ref/vsynth/vsynth2-ffvhuff444p16 |8 +- tests/ref/vsynth/vsynth2-flashsv |8 +- tests/ref/vsynth/vsynth2-flashsv2 |8 +- tests/ref/vsynth/vsynth2-flv |8 +- tests/ref/vsynth/vsynth2-h261 |8 +- tests/ref/vsynth/vsynth2-h261-trellis |8 +- tests/ref/vsynth/vsynth2-h263 |8 +- tests/ref/vsynth/vsynth2-h263-obmc |8 +- tests/ref/vsynth/vsynth2-h263p |8 +- tests/ref/vsynth/vsynth2-huffyuv |6 +- tests/ref/vsynth/vsynth2-huffyuvbgr24 |8 +- tests/ref/vsynth/vsynth2-huffyuvbgra |8 +- tests/ref/vsynth/vsynth2-jpeg2000 |8 +- tests/ref/vsynth/vsynth2-jpeg2000-97 |8 +- tests/ref/vsynth/vsynth2-jpegls
Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain
On Tue, Aug 26, 2014 at 01:52:19PM +0200, Michael Niedermayer wrote: [...] I'm fine with the patch, even though Lena has a special meaning in video processing... yep, i wonder if this is the best solution after sleepng over it. the lena image is well known, also people know how girls look, people will recognize artiacts easily in it. Noone would easily notice if a flower has a different color tone or some spots. So it may be better to actually try to keep using lena Yes. Also, the picture is really under fair use in FFmpeg… See also https://en.wikipedia.org/wiki/File:Lenna.png#Fair_use_for_Playboy In that light ive posted a naive patch that just downloads lena.pnm if its missing, a 3rd alternative to that would be to move it to the fate suite as andreas initially suggested. It's really insane to wget this in a code that worked without access to the net. The wget is unexpected here. Also, this is probably not going to help for the package since the goal is to run the tests depending on the picture. [...] -- Clément B. pgpuKcBf3EEeE.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain
On 26.08.2014 14:11, Clément Bœsch wrote: On Tue, Aug 26, 2014 at 01:52:19PM +0200, Michael Niedermayer wrote: [...] I'm fine with the patch, even though Lena has a special meaning in video processing... yep, i wonder if this is the best solution after sleepng over it. the lena image is well known, also people know how girls look, people will recognize artiacts easily in it. Noone would easily notice if a flower has a different color tone or some spots. So it may be better to actually try to keep using lena Yes. Also, the picture is really under fair use in FFmpeg… See also https://en.wikipedia.org/wiki/File:Lenna.png#Fair_use_for_Playboy Yes, it falls under fair use for FFmpeg. But Debian only accepts files with a DFSG-free license [1], which lena.pnm lacks. In that light ive posted a naive patch that just downloads lena.pnm if its missing, a 3rd alternative to that would be to move it to the fate suite as andreas initially suggested. It's really insane to wget this in a code that worked without access to the net. The wget is unexpected here. Also, this is probably not going to help for the package since the goal is to run the tests depending on the picture. Downloading lena.pnm won't work for example on Debian's build daemons, which don't allow access to the internet during package build. Moving this file to the external fate samples would be fine, because these test are not run, when building the Debian package, anyway. Best regards, Andreas 1: https://www.debian.org/social_contract#guidelines ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain
On Tue, Aug 26, 2014 at 02:32:00PM +0200, Clément Bœsch wrote: On Tue, Aug 26, 2014 at 02:27:45PM +0200, Michael Niedermayer wrote: On Tue, Aug 26, 2014 at 02:22:08PM +0200, Andreas Cadhalpun wrote: On 26.08.2014 14:11, Clément Bœsch wrote: On Tue, Aug 26, 2014 at 01:52:19PM +0200, Michael Niedermayer wrote: [...] I'm fine with the patch, even though Lena has a special meaning in video processing... yep, i wonder if this is the best solution after sleepng over it. the lena image is well known, also people know how girls look, people will recognize artiacts easily in it. Noone would easily notice if a flower has a different color tone or some spots. So it may be better to actually try to keep using lena Yes. Also, the picture is really under fair use in FFmpeg… See also https://en.wikipedia.org/wiki/File:Lenna.png#Fair_use_for_Playboy Yes, it falls under fair use for FFmpeg. But Debian only accepts files with a DFSG-free license [1], which lena.pnm lacks. In that light ive posted a naive patch that just downloads lena.pnm if its missing, a 3rd alternative to that would be to move it to the fate suite as andreas initially suggested. It's really insane to wget this in a code that worked without access to the net. The wget is unexpected here. Also, this is probably not going to help for the package since the goal is to run the tests depending on the picture. Downloading lena.pnm won't work for example on Debian's build daemons, which don't allow access to the internet during package build. the build daemons run make fate ? because the download should only happen when the file is needed and its only needed for the tests make fate works without samples. Also, if I'm offline and use git clean, I can't run make anymore even if i still have the samples in a dedicated directory. Last, it adds a wget dependency. the idea was to add the download rule to the makefile as in the patch but leave lena.pnm in git. That way debian could simply drop the file and still have working make test (when there is net access) either way, i suggest that until we have a consensus, andreas should probably pick any of the solutions for debian so theres no delay on the debian side [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Adds support for setting aq_mode in libvpx encoder
On Tue, Aug 26, 2014 at 03:39:26AM +0200, Michael Niedermayer wrote: On Mon, Aug 25, 2014 at 05:17:39PM -0700, Deb Mukherjee wrote: Sets aq_mode in the [0, 3] range for the libvpx encode wrapper. 0: none 1: variance aq 2: complexity aq 3: cyclic refresh aq --- doc/encoders.texi | 5 - libavcodec/libvpxenc.c | 9 + 2 files changed, 13 insertions(+), 1 deletion(-) breaks build: libavcodec/libvpxenc.c:127:6: error: ‘VP9E_SET_AQ_MODE’ undeclared here (not in a function) libavcodec/libvpxenc.c:127:5: error: array index in initializer not of integer type libavcodec/libvpxenc.c:127:5: error: (near initialization for ‘ctlidstr’) make: *** [libavcodec/libvpxenc.o] Error 1 james configure patch fixed this [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain
On 26.08.2014 14:39, Michael Niedermayer wrote: On Tue, Aug 26, 2014 at 02:32:00PM +0200, Clément Bœsch wrote: On Tue, Aug 26, 2014 at 02:27:45PM +0200, Michael Niedermayer wrote: On Tue, Aug 26, 2014 at 02:22:08PM +0200, Andreas Cadhalpun wrote: On 26.08.2014 14:11, Clément Bœsch wrote: On Tue, Aug 26, 2014 at 01:52:19PM +0200, Michael Niedermayer wrote: [...] I'm fine with the patch, even though Lena has a special meaning in video processing... yep, i wonder if this is the best solution after sleepng over it. the lena image is well known, also people know how girls look, people will recognize artiacts easily in it. Noone would easily notice if a flower has a different color tone or some spots. So it may be better to actually try to keep using lena Yes. Also, the picture is really under fair use in FFmpeg… See also https://en.wikipedia.org/wiki/File:Lenna.png#Fair_use_for_Playboy Yes, it falls under fair use for FFmpeg. But Debian only accepts files with a DFSG-free license [1], which lena.pnm lacks. In that light ive posted a naive patch that just downloads lena.pnm if its missing, a 3rd alternative to that would be to move it to the fate suite as andreas initially suggested. It's really insane to wget this in a code that worked without access to the net. The wget is unexpected here. Also, this is probably not going to help for the package since the goal is to run the tests depending on the picture. Downloading lena.pnm won't work for example on Debian's build daemons, which don't allow access to the internet during package build. the build daemons run make fate ? because the download should only happen when the file is needed and its only needed for the tests make fate works without samples. Also, if I'm offline and use git clean, I can't run make anymore even if i still have the samples in a dedicated directory. Last, it adds a wget dependency. the idea was to add the download rule to the makefile as in the patch but leave lena.pnm in git. That way debian could simply drop the file and still have working make test (when there is net access) That would be bad, because it would work, when I test it (with internet access), but then fail on the build daemons. Also it's better not having to repack, because then anyone can verify that the Debian tarball matches the signatures for the original one. either way, i suggest that until we have a consensus, andreas should probably pick any of the solutions for debian so theres no delay on the debian side I would prefer having a solution applied in ffmpeg.git first. If the lena.pnm image is considered better for testing, then it should be added to the fate samples for download, which are anyway used by most developers. As long as it is not in the distributed tarball it is no problem. If having an example image in the tarball is important, the flower.pnm (or any other free image) can be added, even if no test needs it. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: Ensure cues_end is initialized
div name=BB10 id=BB10_response_div dir=auto contenteditable=true style=width:100%;background:quot;#ffquot;; font-size: initial;font-family:quot;Calibriquot;,quot;Slate Proquot;,quot;sans-serifquot;;color:#1f497d;br style=display:initial/div div name=BB10 id=response_div_spacer dir=auto contenteditable=true style=width:100%;background:quot;#ffquot;; font-size: initial;font-family:quot;Calibriquot;,quot;Slate Proquot;,quot;sans-serifquot;;color:#1f497d;br style=display:initial/div div id=_signaturePlaceholder name=BB10 dir=auto contenteditable=true style=font-size: initial;font-family:quot;Calibriquot;,quot;Slate Proquot;,quot;sans-serifquot;;color:#1f497d;/div table id=_bb10TempSeparator width=100% style=background-color:white; border-spacing:0px; contenteditable=false trtd/tdtd id=_separatorInternal rowspan=2 style=text-align:center span id=_bb10TempSeparatorText style=background-color:white; color:#0073BC;font-size:smaller;font-family:quot;Slate Proquot;nbsp; Original Message nbsp;/span /td/tr tr td colspan=2div style=border:none;border-top:solid #0073BC 1.0pt; /td/tr/table table width=100% style=background-color:white;border-spacing:0px; trtd id=_persistentHeaderContainer colspan=2 div id=_persistentHeader style=font-size: smaller;font-family:quot;Tahomaquot;,quot;BB Alpha Sansquot;,quot;Slate Proquot;,quot;sans-serifquot;; div id=From bFrom: /bReimar Döffinger/divdiv id=Sent bSent: /bTuesday, 26 August 2014 08:31/divdiv id=To bTo: /bFFmpeg development discussions and patches/divdiv id=ReplyTo bReply To: /bFFmpeg development discussions and patches/divdiv id=Subject bSubject: /bRe: [FFmpeg-devel] [PATCH] lavf/matroskadec: Ensure cues_end is initialized/div/div/td/tr/tablediv id=_persistentHeaderEnd style=border:none;border-top:solid #babcd1 1pt;/divbrdiv name=BB10 dir=auto id=_originalContentbr/br/On 25.08.2014, at 18:15, Vignesh Venkatasubramanian lt;vigne...@google.comgt; wrote:br/br/gt; avio_seek(matroska-gt;ctx-gt;pb, before_pos, SEEK_SET);br/gt; +if (cues_start == -1 || cues_end == -1) return -1;br/br/Shouldnapos;t this use something more descriptive than -1?br/___br/ffmpeg-devel mailing listbr/ffmpeg-devel@ffmpeg.orgbr/http://ffmpeg.org/mailman/listinfo/ffmpeg-develbr/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain
On 26.08.2014 14:40, Nicolas George wrote: Also: aimlin /tmp $ apt-get source libav /dev/null aimlin /tmp $ ls -l libav-10.4/tests/lena.pnm -rw-r--r-- 1 cigaes cigaes 196668 Aug 17 16:31 libav-10.4/tests/lena.pnm (Of course it does not prove anything beyond the fact that people do not really care about such tiny licensing details, which is good. Unless someone actually raised the issue as an objection to FFmpeg in Debian?) People actually do care: https://bugs.debian.org/758442 I would have filed a similar bug against Debian's Libav package, but I didn't want to give an excuse for a flamewar. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain
On 8/26/2014 12:42 AM, Michael Niedermayer wrote: [...] tests/lena.pnm | 109 I'm sorry but this is beyond stupid. We can't use the defacto DSP testing image because it is not *FREE* enough for Debian? It is utterly asinine to remove it because Debian doesn't want to distribute Lena with source deb. They can remove it themselves. As for the Debian build daemon, it has no internet access anyway, and a asynth and vsynth only run is of dubious value. Muh freedums, I tell ya whut. P.S. Maybe someone should inform the Debian guys of all the hundred(s) of patents that FFmpeg implements as well. ;) - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain
On 26.08.2014 16:15, Derek Buitenhuis wrote: On 8/26/2014 12:42 AM, Michael Niedermayer wrote: [...] tests/lena.pnm | 109 I'm sorry but this is beyond stupid. I don't think so. We can't use the defacto DSP testing image because it is not *FREE* enough for Debian? It is utterly asinine to remove it because Debian doesn't want to distribute Lena with source deb. They can remove it themselves. You could still use it, just like all the other samples which need to be downloaded with 'make fate-rsync'. Why do you think it necessary to ship this sample in the FFmpeg source tarball, while all others aren't there, already. As for the Debian build daemon, it has no internet access anyway, and a asynth and vsynth only run is of dubious value. It is quite useful, e.g. it detected that gcc-4.9 broke FFmpeg's flac support [1]. Muh freedums, I tell ya whut. P.S. Maybe someone should inform the Debian guys of all the hundred(s) of patents that FFmpeg implements as well. ;) Patents are a different issue and no DFSG criterion. Best regards, Andreas 1: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60902 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain
On 8/26/2014 3:47 PM, Andreas Cadhalpun wrote: We can't use the defacto DSP testing image because it is not *FREE* enough for Debian? It is utterly asinine to remove it because Debian doesn't want to distribute Lena with source deb. They can remove it themselves. You could still use it, just like all the other samples which need to be downloaded with 'make fate-rsync'. Why do you think it necessary to ship this sample in the FFmpeg source tarball, while all others aren't there, already. As for the Debian build daemon, it has no internet access anyway, and a asynth and vsynth only run is of dubious value. It is quite useful, e.g. it detected that gcc-4.9 broke FFmpeg's flac support [1]. These two conflict. Either we distribute it with the tarball, or Debian's build daemon doesn't run the tests. Freetards gonna freetard I guess... - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain
On 26.08.2014 16:50, Derek Buitenhuis wrote: On 8/26/2014 3:47 PM, Andreas Cadhalpun wrote: We can't use the defacto DSP testing image because it is not *FREE* enough for Debian? It is utterly asinine to remove it because Debian doesn't want to distribute Lena with source deb. They can remove it themselves. You could still use it, just like all the other samples which need to be downloaded with 'make fate-rsync'. Why do you think it necessary to ship this sample in the FFmpeg source tarball, while all others aren't there, already. As for the Debian build daemon, it has no internet access anyway, and a asynth and vsynth only run is of dubious value. It is quite useful, e.g. it detected that gcc-4.9 broke FFmpeg's flac support [1]. These two conflict. Either we distribute it with the tarball, or Debian's build daemon doesn't run the tests. All the other tests that don't need lena.pnm still can be run, e.g. the acodec-flac test, which is quite useful. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] fate: Add basic tests for WebM Dash Manifest
On Mon, Aug 25, 2014 at 4:35 PM, Lou Logan l...@lrcd.com wrote: On Mon, 25 Aug 2014 16:26:16 -0700, Vignesh Venkatasubramanian wrote: i sent the files associated with this fate test as a tarball to this mailing list and got a reply saying message is awaiting moderator approval because the attachment is 500kb. could you please check? The samples were submitted to the mailing list, but I rejected the message with a note to provide links to the files instead of attaching them due to the file sizes. Please check to see if the message was marked as spam. sorry. i did not get that email. it's not in my spam folder either. anyway, here is a link to the tarball: https://drive.google.com/file/d/0Bx8Q1nhO9b6MdjducEZyUks5VHc/edit?usp=sharing could you please unpack the files into vp8/ directory in fate samples suite? thanks. Although this is a high volume list (in my opinion), I thought 5 MB was too big for a single email message; especially with our number of subscribers I did not believe it would be appreciated by many readers. Current size limit per message is 550 kb. This of course can be changed if desired and can be discussed in another message or in #ffmpeg-devel. Lou ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Vignesh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain
On 26/08/14 9:39 AM, Michael Niedermayer wrote: either way, i suggest that until we have a consensus, andreas should probably pick any of the solutions for debian so theres no delay on the debian side How is this a problem for Debian? lena.pnm is also available on Libav's git tree and it doesn't seem to be an issue for them. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain
Hi, On 26.08.2014 18:26, James Almer wrote: On 26/08/14 9:39 AM, Michael Niedermayer wrote: either way, i suggest that until we have a consensus, andreas should probably pick any of the solutions for debian so theres no delay on the debian side How is this a problem for Debian? lena.pnm is also available on Libav's git tree and it doesn't seem to be an issue for them. It seems nobody noticed this so far. It is hard to detect, because nowhere in the source is mentioned that tests/lena.pnm is not licensed under LPGL-2.1+, so one assumes it is. I only noticed this, after seeing a similar bug filed for a different package [1]. Of course, this should also be fixed in the Debian Libav package. Best regards, Andreas 1: https://bugs.debian.org/758442 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] fate: Add basic tests for WebM Dash Manifest
On Tue, Aug 26, 2014 at 08:26:10AM -0700, Vignesh Venkatasubramanian wrote: On Mon, Aug 25, 2014 at 4:35 PM, Lou Logan l...@lrcd.com wrote: On Mon, 25 Aug 2014 16:26:16 -0700, Vignesh Venkatasubramanian wrote: i sent the files associated with this fate test as a tarball to this mailing list and got a reply saying message is awaiting moderator approval because the attachment is 500kb. could you please check? The samples were submitted to the mailing list, but I rejected the message with a note to provide links to the files instead of attaching them due to the file sizes. Please check to see if the message was marked as spam. sorry. i did not get that email. it's not in my spam folder either. anyway, here is a link to the tarball: https://drive.google.com/file/d/0Bx8Q1nhO9b6MdjducEZyUks5VHc/edit?usp=sharing could you please unpack the files into vp8/ directory in fate samples suite? thanks. done [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Adds support for constant quality mode in VP9.
Changes in the parameter mapping for libvpx to support the constant
quality mode in VP9. The assumption in the patch is that if crf is
provided but bitrate is 0, then the 'constant quality' mode of VP9
is used. However if both are present, the 'constrained quality' mode
is used as before.
---
libavcodec/libvpxenc.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 830a793..3a36855 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -300,10 +300,15 @@ static av_cold int vpx_init(AVCodecContext *avctx,
enccfg.g_pass = VPX_RC_ONE_PASS;
if (avctx-rc_min_rate == avctx-rc_max_rate
-avctx-rc_min_rate == avctx-bit_rate avctx-bit_rate)
+avctx-rc_min_rate == avctx-bit_rate avctx-bit_rate) {
enccfg.rc_end_usage = VPX_CBR;
-else if (ctx-crf)
+} else if (ctx-crf = 0) {
enccfg.rc_end_usage = VPX_CQ;
+#if CONFIG_LIBVPX_VP9_ENCODER
+if (!avctx-bit_rate avctx-codec_id == AV_CODEC_ID_VP9)
+enccfg.rc_end_usage = VPX_Q;
+#endif
+}
if (avctx-bit_rate) {
enccfg.rc_target_bitrate = av_rescale_rnd(avctx-bit_rate, 1, 1000,
@@ -311,7 +316,11 @@ static av_cold int vpx_init(AVCodecContext *avctx,
} else {
if (enccfg.rc_end_usage == VPX_CQ) {
enccfg.rc_target_bitrate = 100;
+#if CONFIG_LIBVPX_VP9_ENCODER
+} else if (enccfg.rc_end_usage != VPX_Q) {
+#else
} else {
+#endif
avctx-bit_rate = enccfg.rc_target_bitrate * 1000;
av_log(avctx, AV_LOG_WARNING,
Neither bitrate nor constrained quality specified, using
default bitrate of %dkbit/sec\n,
@@ -324,7 +333,7 @@ static av_cold int vpx_init(AVCodecContext *avctx,
if (avctx-qmax = 0)
enccfg.rc_max_quantizer = avctx-qmax;
-if (enccfg.rc_end_usage == VPX_CQ) {
+if (enccfg.rc_end_usage == VPX_CQ || enccfg.rc_end_usage == VPX_Q) {
if (ctx-crf enccfg.rc_min_quantizer || ctx-crf
enccfg.rc_max_quantizer) {
av_log(avctx, AV_LOG_ERROR,
CQ level must be between minimum and maximum quantizer
value (%d-%d)\n,
@@ -430,7 +439,8 @@ static av_cold int vpx_init(AVCodecContext *avctx,
if (avctx-codec_id == AV_CODEC_ID_VP8)
codecctl_int(avctx, VP8E_SET_TOKEN_PARTITIONS,
av_log2(avctx-slices));
codecctl_int(avctx, VP8E_SET_STATIC_THRESHOLD, avctx-mb_threshold);
-codecctl_int(avctx, VP8E_SET_CQ_LEVEL, ctx-crf);
+if (ctx-crf = 0)
+codecctl_int(avctx, VP8E_SET_CQ_LEVEL, ctx-crf);
if (ctx-max_intra_rate = 0)
codecctl_int(avctx, VP8E_SET_MAX_INTRA_BITRATE_PCT,
ctx-max_intra_rate);
@@ -775,7 +785,7 @@ static int vp8_encode(AVCodecContext *avctx, AVPacket *pkt,
by the bool decoder, meaning that partitions can be
decoded even \
though earlier partitions have been lost. Note that
intra predicition \
is still done over the partition boundary.,
0, AV_OPT_TYPE_CONST, {.i64 = VPX_ERROR_RESILIENT_PARTITIONS}, 0, 0, VE, er},
\
-{ crf, Select the quality for constant quality mode,
offsetof(VP8Context, crf), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 63, VE }, \
+{ crf, Select the quality for constant quality mode,
offsetof(VP8Context, crf), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 63, VE }, \
#define LEGACY_OPTIONS \
{speed, , offsetof(VP8Context, cpu_used), AV_OPT_TYPE_INT, {.i64 = 1},
-16, 16, VE}, \
--
2.1.0.rc2.206.gedb03e5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libx264: fix -b_qfactor and -chromaoffset
Hi,
On 2014-08-25 01:24, Michael Niedermayer wrote:
On Sat, Aug 23, 2014 at 08:59:41PM +0800, Hii wrote:
Currently -b_qfactor and -chromaoffset have no effect in libx264,
the attached patch is an attempt to fix the issue.
Move the corresponding lines after x264_param_default_preset() to
prevent them being overwritten by it, make the two parameters
functional.
Also make b_qfactor changeable by x264's tunings after the move.
(feel free to edit the commit message as I am not a native English
speaker.)
libx264.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
affb26a7840db085fb82ac8e24e5fe5770774113
0001-libx264-fix-b_qfactor-and-chromaoffset.patch
From d8597d3f708c21deae40b21754173763c5a13658 Mon Sep 17 00:00:00 2001
From: Hii hiiragi...@gmail.com
Date: Sat, 23 Aug 2014 17:08:02 +0800
Subject: [PATCH] libx264: fix -b_qfactor and -chromaoffset
---
libavcodec/libx264.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 7793581..8aff14d 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -371,8 +371,6 @@ static av_cold int X264_init(AVCodecContext *avctx)
x4-params.b_deblocking_filter = avctx-flags
CODEC_FLAG_LOOP_FILTER;
-x4-params.rc.f_pb_factor = avctx-b_quant_factor;
-x4-params.analyse.i_chroma_qp_offset = avctx-chromaoffset;
if (x4-preset || x4-tune)
if (x264_param_default_preset(x4-params, x4-preset,
x4-tune) 0) {
int i;
@@ -430,6 +428,9 @@ static av_cold int X264_init(AVCodecContext *avctx)
if (avctx-i_quant_factor 0)
x4-params.rc.f_ip_factor = 1 /
fabs(avctx-i_quant_factor);
+if (avctx-b_quant_factor 0)
+x4-params.rc.f_pb_factor = avctx-b_quant_factor;
+x4-params.analyse.i_chroma_qp_offset = avctx-chromaoffset;
i think this would unconditionally override i_chroma_qp_offset
from x264_param_default_preset()
all others are only overridde when explicitly set by the user
Here's another try.
From 402a0d7752891f1682c30deab2d7052ce35b7303 Mon Sep 17 00:00:00 2001
From: Hii hiiragi...@gmail.com
Date: Tue, 26 Aug 2014 14:55:14 +0800
Subject: [PATCH] libx264: fix -b_qfactor and -chromaoffset
---
libavcodec/libx264.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 7793581..8830f59 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -371,8 +371,6 @@ static av_cold int X264_init(AVCodecContext *avctx)
x4-params.b_deblocking_filter = avctx-flags
CODEC_FLAG_LOOP_FILTER;
-x4-params.rc.f_pb_factor = avctx-b_quant_factor;
-x4-params.analyse.i_chroma_qp_offset = avctx-chromaoffset;
if (x4-preset || x4-tune)
if (x264_param_default_preset(x4-params, x4-preset, x4-tune) 0) {
int i;
@@ -430,6 +428,10 @@ static av_cold int X264_init(AVCodecContext *avctx)
if (avctx-i_quant_factor 0)
x4-params.rc.f_ip_factor = 1 / fabs(avctx-i_quant_factor);
+if (avctx-b_quant_factor 0)
+x4-params.rc.f_pb_factor = avctx-b_quant_factor;
+if (avctx-chromaoffset)
+x4-params.analyse.i_chroma_qp_offset = avctx-chromaoffset;
if (avctx-me_method == ME_EPZS)
x4-params.analyse.i_me_method = X264_ME_DIA;
@@ -827,6 +829,7 @@ static const AVCodecDefault x264_defaults[] = {
{ flags2, 0 },
{ g,-1 },
{ i_qfactor,-1 },
+{ b_qfactor,-1 },
{ qmin, -1 },
{ qmax, -1 },
{ qdiff,-1 },
--
1.9.0.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain
On 26.08.2014 19:45, Michael Niedermayer wrote: On Tue, Aug 26, 2014 at 07:28:13PM +0200, Michael Niedermayer wrote: On Tue, Aug 26, 2014 at 01:42:17AM +0200, Michael Niedermayer wrote: From: Andreas Cadhalpun andreas.cadhal...@googlemail.com in absence of any better ideas or pictures i intend to apply this soon of course if people object to this then we can also leave lena and document that its used under fair use and may or may not be public domain GPL compatible Why do you think it might be public domain or GPL compatible? It's quite clear that it is copyrighted and since it is from 1972, the copyright didn't expire yet. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libx264: fix -b_qfactor and -chromaoffset
On Tue, Aug 26, 2014 at 02:58:32PM +0800, Hii wrote:
Hi,
On 2014-08-25 01:24, Michael Niedermayer wrote:
On Sat, Aug 23, 2014 at 08:59:41PM +0800, Hii wrote:
Currently -b_qfactor and -chromaoffset have no effect in libx264,
the attached patch is an attempt to fix the issue.
Move the corresponding lines after x264_param_default_preset() to
prevent them being overwritten by it, make the two parameters
functional.
Also make b_qfactor changeable by x264's tunings after the move.
(feel free to edit the commit message as I am not a native
English speaker.)
libx264.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
affb26a7840db085fb82ac8e24e5fe5770774113
0001-libx264-fix-b_qfactor-and-chromaoffset.patch
From d8597d3f708c21deae40b21754173763c5a13658 Mon Sep 17 00:00:00 2001
From: Hii hiiragi...@gmail.com
Date: Sat, 23 Aug 2014 17:08:02 +0800
Subject: [PATCH] libx264: fix -b_qfactor and -chromaoffset
---
libavcodec/libx264.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 7793581..8aff14d 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -371,8 +371,6 @@ static av_cold int X264_init(AVCodecContext *avctx)
x4-params.b_deblocking_filter = avctx-flags
CODEC_FLAG_LOOP_FILTER;
-x4-params.rc.f_pb_factor = avctx-b_quant_factor;
-x4-params.analyse.i_chroma_qp_offset = avctx-chromaoffset;
if (x4-preset || x4-tune)
if (x264_param_default_preset(x4-params, x4-preset,
x4-tune) 0) {
int i;
@@ -430,6 +428,9 @@ static av_cold int X264_init(AVCodecContext *avctx)
if (avctx-i_quant_factor 0)
x4-params.rc.f_ip_factor = 1 /
fabs(avctx-i_quant_factor);
+if (avctx-b_quant_factor 0)
+x4-params.rc.f_pb_factor = avctx-b_quant_factor;
+x4-params.analyse.i_chroma_qp_offset = avctx-chromaoffset;
i think this would unconditionally override i_chroma_qp_offset
from x264_param_default_preset()
all others are only overridde when explicitly set by the user
Here's another try.
libx264.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
20824b7c002625f609c6d6a76de27e0910e2a70e
0001-libx264-fix-b_qfactor-and-chromaoffset.patch
From 402a0d7752891f1682c30deab2d7052ce35b7303 Mon Sep 17 00:00:00 2001
From: Hii hiiragi...@gmail.com
Date: Tue, 26 Aug 2014 14:55:14 +0800
Subject: [PATCH] libx264: fix -b_qfactor and -chromaoffset
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tests: switch to a test image that is under public domain
On Tue, Aug 26, 2014 at 08:12:58PM +0200, Andreas Cadhalpun wrote: On 26.08.2014 19:45, Michael Niedermayer wrote: On Tue, Aug 26, 2014 at 07:28:13PM +0200, Michael Niedermayer wrote: On Tue, Aug 26, 2014 at 01:42:17AM +0200, Michael Niedermayer wrote: From: Andreas Cadhalpun andreas.cadhal...@googlemail.com in absence of any better ideas or pictures i intend to apply this soon of course if people object to this then we can also leave lena and document that its used under fair use and may or may not be public domain GPL compatible Why do you think it might be public domain or GPL compatible? It's quite clear that it is copyrighted and since it is from 1972, the copyright didn't expire yet. IANAL [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Adds support for constant quality mode in VP9.
On Tue, Aug 26, 2014 at 10:30 AM, Deb Mukherjee debar...@google.com wrote:
Changes in the parameter mapping for libvpx to support the constant
quality mode in VP9. The assumption in the patch is that if crf is
provided but bitrate is 0, then the 'constant quality' mode of VP9
is used. However if both are present, the 'constrained quality' mode
is used as before.
---
libavcodec/libvpxenc.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 830a793..3a36855 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -300,10 +300,15 @@ static av_cold int vpx_init(AVCodecContext *avctx,
enccfg.g_pass = VPX_RC_ONE_PASS;
if (avctx-rc_min_rate == avctx-rc_max_rate
-avctx-rc_min_rate == avctx-bit_rate avctx-bit_rate)
+avctx-rc_min_rate == avctx-bit_rate avctx-bit_rate) {
enccfg.rc_end_usage = VPX_CBR;
-else if (ctx-crf)
+} else if (ctx-crf = 0) {
enccfg.rc_end_usage = VPX_CQ;
+#if CONFIG_LIBVPX_VP9_ENCODER
+if (!avctx-bit_rate avctx-codec_id == AV_CODEC_ID_VP9)
+enccfg.rc_end_usage = VPX_Q;
+#endif
+}
if (avctx-bit_rate) {
enccfg.rc_target_bitrate = av_rescale_rnd(avctx-bit_rate, 1, 1000,
@@ -311,7 +316,11 @@ static av_cold int vpx_init(AVCodecContext *avctx,
} else {
if (enccfg.rc_end_usage == VPX_CQ) {
enccfg.rc_target_bitrate = 100;
+#if CONFIG_LIBVPX_VP9_ENCODER
+} else if (enccfg.rc_end_usage != VPX_Q) {
you could bring this up a level and avoid the '#else'
+#else
} else {
+#endif
avctx-bit_rate = enccfg.rc_target_bitrate * 1000;
av_log(avctx, AV_LOG_WARNING,
Neither bitrate nor constrained quality specified, using
default bitrate of %dkbit/sec\n,
@@ -324,7 +333,7 @@ static av_cold int vpx_init(AVCodecContext *avctx,
if (avctx-qmax = 0)
enccfg.rc_max_quantizer = avctx-qmax;
-if (enccfg.rc_end_usage == VPX_CQ) {
+if (enccfg.rc_end_usage == VPX_CQ || enccfg.rc_end_usage == VPX_Q) {
This still needs to be if def'd.
if (ctx-crf enccfg.rc_min_quantizer || ctx-crf
enccfg.rc_max_quantizer) {
av_log(avctx, AV_LOG_ERROR,
CQ level must be between minimum and maximum
quantizer value (%d-%d)\n,
@@ -430,7 +439,8 @@ static av_cold int vpx_init(AVCodecContext *avctx,
if (avctx-codec_id == AV_CODEC_ID_VP8)
codecctl_int(avctx, VP8E_SET_TOKEN_PARTITIONS,
av_log2(avctx-slices));
codecctl_int(avctx, VP8E_SET_STATIC_THRESHOLD, avctx-mb_threshold);
-codecctl_int(avctx, VP8E_SET_CQ_LEVEL, ctx-crf);
+if (ctx-crf = 0)
+codecctl_int(avctx, VP8E_SET_CQ_LEVEL, ctx-crf);
if (ctx-max_intra_rate = 0)
codecctl_int(avctx, VP8E_SET_MAX_INTRA_BITRATE_PCT,
ctx-max_intra_rate);
@@ -775,7 +785,7 @@ static int vp8_encode(AVCodecContext *avctx, AVPacket
*pkt,
by the bool decoder, meaning that partitions can
be decoded even \
though earlier partitions have been lost. Note
that intra predicition \
is still done over the partition boundary.,
0, AV_OPT_TYPE_CONST, {.i64 = VPX_ERROR_RESILIENT_PARTITIONS}, 0, 0, VE,
er}, \
-{ crf, Select the quality for constant quality mode,
offsetof(VP8Context, crf), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 63, VE }, \
+{ crf, Select the quality for constant quality mode,
offsetof(VP8Context, crf), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 63, VE }, \
#define LEGACY_OPTIONS \
{speed, , offsetof(VP8Context, cpu_used), AV_OPT_TYPE_INT, {.i64 =
1}, -16, 16, VE}, \
--
2.1.0.rc2.206.gedb03e5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/rtpdec_h261: sanity checks
On Tue, Aug 26, 2014 at 02:23:00PM +0200, Thomas Volkert wrote: From: ThomasVolkert tho...@homer-conferencing.com --- libavformat/rtpdec_h261.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) made commit message a bit more verbose applied thanks [...] -- 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 signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Adds support for setting aq_mode in libvpx encoder
On 25/08/14 9:17 PM, Deb Mukherjee wrote: Sets aq_mode in the [0, 3] range for the libvpx encode wrapper. 0: none 1: variance aq 2: complexity aq 3: cyclic refresh aq --- doc/encoders.texi | 5 - libavcodec/libvpxenc.c | 9 + 2 files changed, 13 insertions(+), 1 deletion(-) LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add a license to the LESS file
On 26.08.2014 21:38, db0company wrote: --- LICENSE.txt | 21 + src/less/style.less |6 -- 2 files changed, 25 insertions(+), 2 deletions(-) create mode 100644 LICENSE.txt Thanks. diff --git a/LICENSE.txt b/LICENSE.txt new file mode 100644 index 000..c5983d2 --- /dev/null +++ b/LICENSE.txt @@ -0,0 +1,21 @@ +The MIT License (MIT) + +Copyright (c) 2014 Barbara Lepage + +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the Software), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in all +copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE +SOFTWARE. diff --git a/src/less/style.less b/src/less/style.less index 6a26684..5d6d03d 100644 --- a/src/less/style.less +++ b/src/less/style.less @@ -1,5 +1,7 @@ -// Author: db0 (db0comp...@gmail.com, http://db0.fr/) - +/*! + * Copyright 2014. Barbara Lepage (db0comp...@gmail.com, http://db0.fr/) + * Licensed under MIT (https://github.com/FFmpeg/web/blob/master/LICENSE.txt) + */ // * // // COLORS A similar notice should be added to src/css_credit to comply with this license, when distributing the style.min.css. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavdevice/v4l2: fix of crash caused by assert
On Wed, Aug 13, 2014 at 07:04:01PM +0400, Dmitry Volyntsev wrote: From: Dmitry Volyntsev xeioexcept...@gmail.com s-buffers_queued constantly decremented and not incremented in case of (s-frame_size 0 buf.bytesused != s-frame_size) condition (caught on long run capture of Logitech C310) can you explain why this happens ? where do this misatching bufs come from ? why is droping them correct ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add a license to the LESS file
On Tue, Aug 26, 2014 at 12:38 PM, db0company db0comp...@gmail.com wrote: --- LICENSE.txt | 21 + src/less/style.less |6 -- 2 files changed, 25 insertions(+), 2 deletions(-) create mode 100644 LICENSE.txt diff --git a/LICENSE.txt b/LICENSE.txt new file mode 100644 index 000..c5983d2 --- /dev/null +++ b/LICENSE.txt @@ -0,0 +1,21 @@ +The MIT License (MIT) + +Copyright (c) 2014 Barbara Lepage + +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the Software), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in all +copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE +SOFTWARE. You should make it clear that only style.less is covered in this license, not anything else. [...] Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] bktr: Fix Fabrice's name
Signed-off-by: Timothy Gu timothyg...@gmail.com --- libavdevice/bktr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavdevice/bktr.c b/libavdevice/bktr.c index d09d452..52d090c 100644 --- a/libavdevice/bktr.c +++ b/libavdevice/bktr.c @@ -3,7 +3,7 @@ * Copyright (c) 2002 Steve O'Hara-Smith * based on * Linux video grab interface - * Copyright (c) 2000,2001 Gerard Lantau + * Copyright (c) 2000, 2001 Fabrice Bellard * and * simple_grab.c Copyright (c) 1999 Roger Hardiman * ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Improved AC3 decoder level support (heavy drc, dialnorm)
On Tue, Aug 26, 2014 at 07:16:06PM -0400, Jean-Francois Thibert wrote: Added support for AC3 heavy dynamic range compression used to restrict the output range and added a setting to specify the output target level and use the dialog normalization field to apply it in the digital domain. do you have a testcase/sample to test this ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: dont warn about d10_channelcount being ignored if its not set
On Fri, Aug 22, 2014 at 10:58:41PM +0200, Michael Niedermayer wrote: Signed-off-by: Michael Niedermayer michae...@gmx.at --- libavformat/mxfenc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/mp3enc: don't abort if audio packets can't be buffered
Instead skip the picture streams and flush the queued audio packets.
Should address ticket #3851.
Signed-off-by: James Almer jamr...@gmail.com
---
This is more a workaround than a fix to the issue, with the intent of
not aborting the entire muxing process just because a picture couldn't
be written to the id3v2 tag.
libavformat/mp3enc.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavformat/mp3enc.c b/libavformat/mp3enc.c
index c0270c2..7e6b2e1 100644
--- a/libavformat/mp3enc.c
+++ b/libavformat/mp3enc.c
@@ -421,8 +421,12 @@ static int mp3_write_packet(AVFormatContext *s, AVPacket
*pkt)
/* buffer audio packets until we get all the pictures */
AVPacketList *pktl = av_mallocz(sizeof(*pktl));
int ret;
-if (!pktl)
-return AVERROR(ENOMEM);
+if (!pktl) {
+av_log(s, AV_LOG_WARNING, Not enough memory to buffer audio.
Skipping picture streams\n);
+mp3-pics_to_write = 0;
+mp3_queue_flush(s);
+return mp3_write_audio_packet(s, pkt);
+}
ret = av_copy_packet(pktl-pkt, pkt);
if (ret 0) {
--
1.8.5.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Improved AC3 decoder level support (heavy drc, dialnorm)
On Tue, Aug 26, 2014 at 7:40 PM, Michael Niedermayer michae...@gmx.at wrote: do you have a testcase/sample to test this ? I don't have any specific sample but this can be tested with any broadcast or most disc source using AC3 audio. I just tried with the Broadway-5.1 clip from samples.mplayerhq.hu/A-codecs/AC3 and it contains both types of DRC and can be decoded in multiple modes ./ffmpeg -heavy_compr 1 -target_level -20 -i Broadway-5.1.ac3 -acodec pcm_s16le -ac 2 BroadwayHeavyDRC.wav ./ffmpeg -drc_scale 1 -target_level -31 -i Broadway-5.1.ac3 -acodec pcm_s16le -ac 2 BroadwayLightDRC.wav ./ffmpeg -drc_scale 0 -target_level -31 -i Broadway-5.1.ac3 -acodec pcm_s16le -ac 2 BroadwayNoDRC.wav ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/libwebpenc: use WebPMemoryWriterClear()
WebPMemoryWriterClear() must be used instead of free() when libwebp ABI version is 0x0202. Signed-off-by: James Almer jamr...@gmail.com --- Untested. Latest stable libwebp release (0.4.1) is still 0x0202. libavcodec/libwebpenc.c | 4 1 file changed, 4 insertions(+) diff --git a/libavcodec/libwebpenc.c b/libavcodec/libwebpenc.c index 5283da5..4f213bc 100644 --- a/libavcodec/libwebpenc.c +++ b/libavcodec/libwebpenc.c @@ -231,7 +231,11 @@ static int libwebp_encode_frame(AVCodecContext *avctx, AVPacket *pkt, *got_packet = 1; end: +#if (WEBP_ENCODER_ABI_VERSION 0x0202) +WebPMemoryWriterClear(mw); +#else free(mw.mem); /* must use free() according to libwebp documentation */ +#endif WebPPictureFree(pic); av_freep(pic); av_frame_free(alt_frame); -- 1.8.5.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
