2015-04-14 1:09 GMT+08:00 wm4 :
> On Mon, 13 Apr 2015 12:02:29 +0800
> Zhang Rui wrote:
>
>> 2015-04-12 22:45 GMT+08:00 Michael Niedermayer :
>> > On Sun, Apr 12, 2015 at 12:00:18PM +0800, Zhang Rui wrote:
>> >> 2015-04-10 22:04 GMT+08:00 wm4 :
>> >> > On Fri, 10 Apr 2015 21:17:42 +0800
>> >> > Zh
On Tue, Apr 14, 2015 at 12:33:51AM +0100, Rostislav Pehlivanov wrote:
> This commit adjusts the intial offset for PNS values, introduced with commit
> f7f71b5795d708763eb0c55fe5e2cb051b2b69f4 earlier. This commit shifts the
> value in such a way that no further offsets are required in the aaccode
Hi!
I changed my test after your comments, thanks for your suggestions.=)
Now I test the codec with different parameters (sample rate and channel
layout). For every set of parameters I create new input. I still use sin but
now with double... The only other option I see is to pre-generate the
This is a simple test for the FLAC codec.
It generates an increasing tone, encodes it, decodes it back and
compares with the original one byte-by-byte.
---
configure| 2 +
doc/Makefile | 1 +
doc/examples/Makefile| 1 +
doc/examples/flac_test.c | 295 +
This commit replaces the previous hardcoded constants with both new and
previously defined macros from aac.h. This change makes it easy for anyone
reading the code to know how encoding and decoding scalefactors works. It's
also possibly a step in unifying some of the code across both the encoder
This commit adjusts the intial offset for PNS values, introduced with commit
f7f71b5795d708763eb0c55fe5e2cb051b2b69f4 earlier. This commit shifts the value
in such a way that no further offsets are required in the aaccoder.c file.
Earlier version of the PNS patch had 2 offsets in both the aaccod
This commit implements the perceptual noise substitution AAC extension. This is
a proof of concept implementation, and as such, is not enabled by default. This
is the second revision of this patch, made after some discussion via non-public
email due to a mistake. Any changes made since the first
On Thu, Dec 18, 2014 at 11:08:39AM +0100, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes ticket #4194 for me, I did not look into
> any specification.
>
> Please review, Carl Eugen
no objection from me
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
On Sun, Apr 12, 2015 at 11:30:32PM +0200, Milan Matejec wrote:
> Hi,
>
> attached is patch for encoding/decoding .ffm format. When you set a maximum
> size of feed file to too small number (I tried 20k) and try to connect to
> ffserver from very slow connection (simulated by reading 8k chunks and
Hello All,
There is ticket #4194:
https://trac.ffmpeg.org/ticket/4194
On the below link, there is already working solution:
https://ffmpeg.org/pipermail/ffmpeg-devel/2014-December/166753.html
-- next part --
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
i
Timo Rothenpieler rothenpieler.org> writes:
>
> > I have a few questions.
> > I will be grateful is someone can give an idea / reply.
> >
> > 1) On nvenc.c under libavcodec, is it possible to create more than
one
> > instance of nvenc to perform 4K 60 fps encoding using
> > nvEncodeAPICreateIns
Hello,
When setting level of HEVC in NVENC, FFmpeg gives error:
root@encoder:~# /opt/ffmpeghw/bin/ffmpeg -i /root/bunny.mp4 -aspect 16:9
-s 3840x2160 -vcodec nvenc_h265 -preset hp -fflags +genpts -vb 25000k -
minrate 25000k -maxrate 25000k -bufsize 75000k -muxrate 25000k -r 50 -an
-flush_packet
On Mon, Apr 13, 2015 at 04:36:18PM -0500, David Favor wrote:
> David Favor wrote:
> >David Favor wrote:
> >>The following command:
> >>
> >>ffmpeg -i clip.mts -c:v copy -c:a copy clip.mp4 (or clip.mov)
> >>
> >>seems to incorrectly write container values for fps + tbr which
> >>causes .mp4/.mov
On Mon, Apr 13, 2015 at 04:11:41PM -0500, David Favor wrote:
> David Favor wrote:
> >The following command:
> >
> >ffmpeg -i clip.mts -c:v copy -c:a copy clip.mp4 (or clip.mov)
> >
> >seems to incorrectly write container values for fps + tbr which
> >causes .mp4/.mov files to play with very odd
On Mon, 13 Apr 2015 16:36:18 -0500
David Favor wrote:
> > https://trac.ffmpeg.org/ticket/974 seems to be a ticket already
> > opened for this.
> This behavior isn't mentioned in the above ticket.
your problem is remuxing h264 from mpegts to mp4
that ticket is for remuxing mpeg2 from mpegts to mp
David Favor wrote:
David Favor wrote:
The following command:
ffmpeg -i clip.mts -c:v copy -c:a copy clip.mp4 (or clip.mov)
seems to incorrectly write container values for fps + tbr which
causes .mp4/.mov files to play with very odd jerky movements.
https://trac.ffmpeg.org/ticket/974 seem
David Favor wrote:
The following command:
ffmpeg -i clip.mts -c:v copy -c:a copy clip.mp4 (or clip.mov)
seems to incorrectly write container values for fps + tbr which
causes .mp4/.mov files to play with very odd jerky movements.
https://trac.ffmpeg.org/ticket/974 seems to be a ticket alr
David Favor wrote:
The following command:
ffmpeg -i clip.mts -c:v copy -c:a copy clip.mp4 (or clip.mov)
seems to incorrectly write container values for fps + tbr which
causes .mp4/.mov files to play with very odd jerky movements.
imac> avinfo clip.mts
clip.mts
length: 00:01:00.03, start
On Mon, Apr 13, 2015 at 12:46 PM, Michael Niedermayer wrote:
> On Mon, Apr 13, 2015 at 12:16:31PM -0700, Vignesh Venkatasubramanian wrote:
>> Add a missing failure check for av_malloc call.
>>
>> Signed-off-by: Vignesh Venkatasubramanian
>> ---
>> libavformat/webmdashenc.c | 6 --
>> 1 file
The following command:
ffmpeg -i clip.mts -c:v copy -c:a copy clip.mp4 (or clip.mov)
seems to incorrectly write container values for fps + tbr which
causes .mp4/.mov files to play with very odd jerky movements.
imac> avinfo clip.mts
clip.mts
length: 00:01:00.03, start: 1.433367, bitrate:
On Mon, Apr 13, 2015 at 12:16:44PM -0700, Vignesh Venkatasubramanian wrote:
> Fix potential leak in av_realloc call where the output was being
> overwritten by using a temporary variable.
>
> Signed-off-by: Vignesh Venkatasubramanian
> ---
> libavformat/webmdashenc.c | 5 +++--
> 1 file changed,
On Mon, Apr 13, 2015 at 12:16:31PM -0700, Vignesh Venkatasubramanian wrote:
> Add a missing failure check for av_malloc call.
>
> Signed-off-by: Vignesh Venkatasubramanian
> ---
> libavformat/webmdashenc.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavforma
On Mon, Apr 13, 2015 at 06:49:04PM +, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/alsdec.c | 61
> ++---
> 1 file changed, 30 insertions(+), 31 deletions(-)
LGTM
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6
Add a missing failure check for av_malloc call.
Signed-off-by: Vignesh Venkatasubramanian
---
libavformat/webmdashenc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/webmdashenc.c b/libavformat/webmdashenc.c
index c5347a9..80266f7 100644
--- a/libavformat/
Fix potential leak in av_realloc call where the output was being
overwritten by using a temporary variable.
Signed-off-by: Vignesh Venkatasubramanian
---
libavformat/webmdashenc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavformat/webmdashenc.c b/libavformat/web
Signed-off-by: Paul B Mahol
---
libavcodec/alsdec.c | 61 ++---
1 file changed, 30 insertions(+), 31 deletions(-)
diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
index bac434f..65aa7d2 100644
--- a/libavcodec/alsdec.c
+++ b/libavcodec/alsdec
Am 13.04.2015 um 12:21 schrieb Stefano Sabatini:
On date Monday 2015-04-13 12:19:36 +0200, Michael Niedermayer encoded:
On Mon, Apr 13, 2015 at 11:37:39AM +0200, Thomas Volkert wrote:
Hi,
My expenses consist of:
- 5 x t-shirt: 116,49 € (the shirts were given to our team, one
stays with me)
-
On 2015-04-13 07:57, Niklesh Lalwani wrote:
From: Niklesh
This patch attempts to use dynamic arrays to support multiple style
records. However, I am unable to get proper output with using
av_dynamic_array(). It seems I am not using this function properly.
Can anyone explain?
Signed-off-by: Nikl
On 2015-04-13 07:56, Niklesh Lalwani wrote:
From: Niklesh
This patch is a part of my qualification task to implement support for
Bold, Italic, and Underlined style records for 3GPP timed text
subtitles. I am continuing Wesley's work. This patch supports decoding
of no more than one style record
On Mon, Apr 13, 2015 at 08:27:59PM +0530, Niklesh Lalwani wrote:
> From: Niklesh
>
> This patch attempts to use dynamic arrays to support multiple style records.
> However, I am unable to get proper output with using av_dynamic_array(). It
> seems I am not using this function properly. Can anyo
Am 13.04.15 um 12:22 schrieb Stefano Sabatini:
> On date Monday 2015-04-13 12:19:21 +0200, Michael Niedermayer encoded:
>> On Fri, Apr 10, 2015 at 08:58:13PM +0200, Thilo Borgmann wrote:
>>> Hi!
>>>
>>> I'd like to request refunds for merchandise expenses at the Chemnitzer
>>> Linux Tage 2015, wher
On Mon, 13 Apr 2015 12:02:29 +0800
Zhang Rui wrote:
> 2015-04-12 22:45 GMT+08:00 Michael Niedermayer :
> > On Sun, Apr 12, 2015 at 12:00:18PM +0800, Zhang Rui wrote:
> >> 2015-04-10 22:04 GMT+08:00 wm4 :
> >> > On Fri, 10 Apr 2015 21:17:42 +0800
> >> > Zhang Rui wrote:
> >> >>
> >> >> This kind
On 2015-04-13 03:39, Petri Hintukainen wrote:
I don't know if it is a good idea to use HDMV stream types without HDMV
program registration descriptor. If this is fixed incrementally, fixing
should be started from the opposite direction:
- Using HDMV stream type requires HDMV registration descrip
On Mon, Apr 13, 2015 at 08:26:59PM +0530, Niklesh Lalwani wrote:
> From: Niklesh
>
> This patch is a part of my qualification task to implement support for Bold,
> Italic, and Underlined style records for 3GPP timed text subtitles. I am
> continuing Wesley's work. This patch supports decoding o
On 4/13/15, Nicolas George wrote:
> Le quartidi 24 germinal, an CCXXIII, Paul B Mahol a ecrit :
>> TTA muxer is impossible to write without using temporary file instead of
>> caching
>> all frames in memory.
>
> Can you shortly explain why (or give a link to where it was already done)?
http://en.
From: Niklesh
This patch attempts to use dynamic arrays to support multiple style records.
However, I am unable to get proper output with using av_dynamic_array(). It
seems I am not using this function properly. Can anyone explain?
Signed-off-by: Niklesh
---
libavcodec/movtextdec.c | 65 +
From: Niklesh
This patch is a part of my qualification task to implement support for Bold,
Italic, and Underlined style records for 3GPP timed text subtitles. I am
continuing Wesley's work. This patch supports decoding of no more than one
style record. Patch[2/2] attempts to use dynamic arrays
Thanks for the detailed answer. Needs no more clarifications. I will pursue
such questions on the user list.
Thanks
On Mon, Apr 13, 2015 at 7:09 PM, Jean First wrote:
> On Mon Apr 13 2015 15:30:03 GMT+0200 (CEST), Kamaldeep Tumkur wrote:
> > I have an mpeg4 transcoded from an mov source that ha
On Mon Apr 13 2015 15:30:03 GMT+0200 (CEST), Kamaldeep Tumkur wrote:
> I have an mpeg4 transcoded from an mov source that has the following:
>
> Stream #0:0(eng): Video: h264 (Constrained Baseline) (avc1 / 0x31637661),
> yuv420p(tv, bt709), 480x270 [SAR 1:1 DAR 16:9], 462 kb/s, 25 fps, 25 tbr,
> 12
I have an mpeg4 transcoded from an mov source that has the following:
Stream #0:0(eng): Video: h264 (Constrained Baseline) (avc1 / 0x31637661),
yuv420p(tv, bt709), 480x270 [SAR 1:1 DAR 16:9], 462 kb/s, 25 fps, 25 tbr,
12800 tbn, 50 tbc (default)
Why is tbn value so high? Why do the tbc and tbn va
Le quartidi 24 germinal, an CCXXIII, Paul B Mahol a écrit :
> TTA muxer is impossible to write without using temporary file instead of
> caching
> all frames in memory.
Can you shortly explain why (or give a link to where it was already done)?
Regards,
--
Nicolas George
signature.asc
Descr
On 4/13/15, James Almer wrote:
> Signed-off-by: James Almer
> ---
> This should be updated whenever a TTA muxer is written and commited since
> Matroska is not ideal for the format.
>
TTA muxer is impossible to write without using temporary file instead of caching
all frames in memory.
_
Ok, thank you for the info.
On Mon, Apr 13, 2015 at 5:22 PM, Kieran Kunhya wrote:
> On 13 April 2015 at 12:49, Kamaldeep Tumkur
> wrote:
> > I don't want to hide the x264 settings. If this is part of the bitstream,
> > are all decoders going to understand it? Will it be used in some way? For
>
On Mon, Apr 13, 2015 at 01:03:35PM +0200, wm4 wrote:
> YCgCo decoding works just fine. It depends on the API user what is done
> with the output. Some API users might support it, some not. Some users
> might support it under certain circumstances only.
>
> It is not the job of the decoder to print
On 13 April 2015 at 12:49, Kamaldeep Tumkur wrote:
> I don't want to hide the x264 settings. If this is part of the bitstream,
> are all decoders going to understand it? Will it be used in some way? For
> decoders that do not understand it, will it cause issues or will it be
> ignored?
It is a le
I don't want to hide the x264 settings. If this is part of the bitstream,
are all decoders going to understand it? Will it be used in some way? For
decoders that do not understand it, will it cause issues or will it be
ignored?
Thanks
On Mon, Apr 13, 2015 at 4:47 PM, Kieran Kunhya wrote:
> > Is
> Is there a way for me to remove the x264 specific metadata from the MDAT
> box of the mp4? Right now, my MDAT has the following as the first few
> bytes. Is this length accounted for as part of MDAT headers?
This data is part of the video bitstream. If you want to hide your
x264 settings please
Hello,
I have an mov file encoded as an mp4 MBR stream at 3-4 different bitrates
with x264 encoding.
Is there a way for me to remove the x264 specific metadata from the MDAT
box of the mp4? Right now, my MDAT has the following as the first few
bytes. Is this length accounted for as part of MDAT h
YCgCo decoding works just fine. It depends on the API user what is done
with the output. Some API users might support it, some not. Some users
might support it under certain circumstances only.
It is not the job of the decoder to print this message. If the API user
supports it, this message is ext
On su, 2015-04-12 at 16:40 -0700, Philip Langdale wrote:
> On Sun, 12 Apr 2015 08:13:39 + (UTC)
> Carl Eugen Hoyos wrote:
> >
> > I tested with samples from the following directories:
> > http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket598/
> > http://samples.ffmpeg.org/ffmpeg-bugs/trac/tick
wm4 googlemail.com> writes:
> GRAY12 would be something different from GRAY16 with
> bits_per_raw_sample set. The former sets MSBs to zero,
> the latter zeros LSBs.
It should not zero them, white should not be gray.
(But there is of course no difference between the two.)
Carl Eugen
__
On Mon, 13 Apr 2015 10:19:15 + (UTC)
Carl Eugen Hoyos wrote:
> Michael Niedermayer gmx.at> writes:
>
> > On Mon, Apr 13, 2015 at 09:59:57AM +, Marco Porsch wrote:
>
> > > Previously we had regular 16bit RAW that worked like a
> > > charm as input to FFmpeg. The naïve approach of upsca
On date Monday 2015-04-13 12:19:21 +0200, Michael Niedermayer encoded:
> On Fri, Apr 10, 2015 at 08:58:13PM +0200, Thilo Borgmann wrote:
> > Hi!
> >
> > I'd like to request refunds for merchandise expenses at the Chemnitzer
> > Linux Tage 2015, where we had manned a booth for FFmpeg.
> >
> > I wo
On date Monday 2015-04-13 12:19:36 +0200, Michael Niedermayer encoded:
> On Mon, Apr 13, 2015 at 11:37:39AM +0200, Thomas Volkert wrote:
> > Hi,
> >
> > My expenses consist of:
> > - 5 x t-shirt: 116,49 € (the shirts were given to our team, one
> > stays with me)
> > - 1 x tablecloth: 81,61 €
> >
On Mon, Apr 13, 2015 at 10:19:15AM +, Carl Eugen Hoyos wrote:
> Michael Niedermayer gmx.at> writes:
>
> > On Mon, Apr 13, 2015 at 09:59:57AM +, Marco Porsch wrote:
>
> > > Previously we had regular 16bit RAW that worked like a
> > > charm as input to FFmpeg. The naïve approach of upscal
On Fri, Apr 10, 2015 at 08:58:13PM +0200, Thilo Borgmann wrote:
> Hi!
>
> I'd like to request refunds for merchandise expenses at the Chemnitzer
> Linux Tage 2015, where we had manned a booth for FFmpeg.
>
> I wonder why there seems to be nothing else on the list because expenses
> were higher th
Michael Niedermayer gmx.at> writes:
> On Mon, Apr 13, 2015 at 09:59:57AM +, Marco Porsch wrote:
> > Previously we had regular 16bit RAW that worked like a
> > charm as input to FFmpeg. The naïve approach of upscaling
> > the 12bit to 16bit destroys the compression efficiency of
> > course
On Mon, Apr 13, 2015 at 11:37:39AM +0200, Thomas Volkert wrote:
> Hi,
>
> My expenses consist of:
> - 5 x t-shirt: 116,49 € (the shirts were given to our team, one
> stays with me)
> - 1 x tablecloth: 81,61 €
> - 1 x traveling: 147 €
> - no hotel costs
> ---
> total: 34
On Mon, Apr 13, 2015 at 09:59:57AM +, Marco Porsch wrote:
> Hi,
>
> our automotive cameras generate a weird kind of 12bit RAW format that I would
> like to encode using FFVHUFF. Unfortunately, the 12bit grayscale pixel format
> is not yet supported.
> Can you point me on the right track to i
On Mon, Apr 13, 2015 at 01:17:28AM -0500, Rodger Combs wrote:
> ---
> libavformat/mpeg.c | 52 +---
> 1 file changed, 37 insertions(+), 15 deletions(-)
applied
maybe you want to add a fate test for this or add a sub file to an
existing fate test
t
Hi,
our automotive cameras generate a weird kind of 12bit RAW format that I would
like to encode using FFVHUFF. Unfortunately, the 12bit grayscale pixel format
is not yet supported.
Can you point me on the right track to implement this pixel format? And will
the encoder be able to handle the 12
On Mon, Apr 13, 2015 at 04:12:28AM -0300, James Almer wrote:
> Signed-off-by: James Almer
> ---
> Now with the ref file.
>
> This should be updated whenever a TTA muxer is written and commited since
> Matroska is not ideal for the format.
>
> tests/fate/acodec.mak | 3 +++
> tests/ref/acodec/t
YCgCo decoding works just fine. It depends on the API user what is done
with the output. Some API users might support it, some not. Some users
might support it under certain circumstances only.
It is not the job of the decoder to print this message. If the API user
supports it, this message is ext
Hi,
My expenses consist of:
- 5 x t-shirt: 116,49 € (the shirts were given to our team, one stays
with me)
- 1 x tablecloth: 81,61 €
- 1 x traveling: 147 €
- no hotel costs
---
total: 345,1 €
(The invoices were sent to Stefano.)
Best regards,
Thomas.
Am 10.04.2015
On Mon, Apr 13, 2015 at 12:39:44AM -0500, Rodger Combs wrote:
> txoffer (e.g. http://tori.aoi-chan.com/ ) redirects to the same URI on your
> first request, and serves the actual file on the second. It's stupid, but
> AFAIK
> technically compliant. We'd previously see the server not handing back a
Signed-off-by: James Almer
---
Now with the ref file.
This should be updated whenever a TTA muxer is written and commited since
Matroska is not ideal for the format.
tests/fate/acodec.mak | 3 +++
tests/ref/acodec/tta | 4
2 files changed, 7 insertions(+)
create mode 100644 tests/ref/ac
Signed-off-by: James Almer
---
This should be updated whenever a TTA muxer is written and commited since
Matroska is not ideal for the format.
tests/fate/acodec.mak | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/fate/acodec.mak b/tests/fate/acodec.mak
index b7e510c..56301d3 100644
67 matches
Mail list logo
