e
time before/after each cut, so that the output segments overlap?
Thank you very much in advance,
Peter B.
(*) For example:
$ ffmpeg -i day1.ts -c copy -map 0 -copy_unknown -f segment
-segment_time 3600 out/day1-%03d.ts
# Links:
[1]
https://ffmpeg.org/ffmpeg-all.html#segment_002c-stream_
n the following information:
* start-position
* end-position
* title
Creating a separate file for each start/end/title line.
We would need such a functionality for archival preservation of
multi-content recordings.
This can be a paid request.
Thank you very much in advance,
Peter B.
#
on't make it optional, what should the format be?
>> Thus?:
>>
>> 0,v,SHA256=...
>> 1,a,SHA256=...
>> 2,s,SHA256=...
> Looks fine.
+1 from me, too :)
I guess with multiple A/V tracks it will then be like this?
0,v,SHA256=...
1,v,SHA256
btw: If you need anything to be tested, just let me know :)
Cheers!
Peter
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org
work
on newer decoders)"
[/quote]
This should be known.
However, since I hardly see any reason to prefer v1 over v3 anymore, and
considering that it's now the most widely one used, I'm happy to see it
become default.
Any objec
On 03/01/2017 03:00 PM, Jerome Martinez wrote:
> My suggestion:
> - support by the demuxer
> - for the muxer, support only if a specific explicit option is set,
> default stays AVI compatibility layer (no break in playback by old
> players).
This sounds like a very practical approach to me:
New fi
On 08/08/2014 09:22 PM, Matthias Urlichs wrote:
> We'd also benefit from the fact that Upstream tends to use FFmpeg. I'd
> hate to report some intractable codec bug which Upstream closes with
> an "it works with FFmpeg" comment
Oh, btw, just a few days ago, that's exactly what happened on kdenlive
On 08/19/2014 12:45 PM, Clément Bœsch wrote:
> See:
> http://fate.ffmpeg.org/
> http://coverage.ffmpeg.org/
The 2nd link to "coverage" (which should show the LCOV output, I guess)
seems to be broken:
I get a "404 Not Found" :(
Regards,
Pb
___
ffmpeg-dev
On 09/25/2014 10:54 PM, Carl Eugen Hoyos wrote:
> The FFv1 P frame project sounds very difficult.
I just read the description of this [1].
I was surprised to see this, because currently FFV1 already supports
GOPs > 1, and according to my tests [2], FFV1.3 already is faster *and*
smaller than h264
Hi everyone :)
This is merely a question of interest. Not a request, complaint or
trolling of any kind :)
I'm happy about any answer. I'm curious.
Would it possibly have a significant impact on coding speed of FFV1's
slicecrc option (Where a CRC is calculated for each frame slice), to use
a
Thanks for all your replies!
Now I can refer to this, when being asked "Why CRC and not ...?" :)
Kind regards,
Peter
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link ab
o know what raw/uncompressed type it is?
I would like to be able to use the hash to compare lossless conversion
of the content between different audio formats (eg vs FLAC and PCM).
Thank you very much in advance :)
Peter B.
Example:
# pcm_f32le defaults to pcm_s16le
On 08/03/2015 01:50 PM, Ronald S. Bultje wrote:
> Just different offsets and ranges. Unsigned, n bits (e.g. u8) is in the
> range [0,2^^n> (e.g. for u8, the range is [0,255] or [0,256>), where
> silence is 2^^n-1, e.g. 0x80 (128) for u8. Signed is in the range
> [-2^^n-1,2^^n-1> (e.g. s16, the most
Hello,
I've been working on FATE tests for FFV1 in the past already [1]. My
tests didn't work on all platforms and therefore never made it upstream.
I think it's better if I try to provide these new tests in smaller
chunks now :)
First of all, there are things I find inconsistent or confusing wi
On 08/30/2015 07:33 PM, Paul B Mahol wrote:
> On 8/30/15, Peter B. wrote:
>> This will produce quite a number of tests :(
>> I guess it is desired to keep the number of tests as low as necessary?
> Not at all. Just look at ffv1 coverage at coverage.ffmpeg.org
:)
I'd love t
On 08/30/2015 09:32 PM, Michael Niedermayer wrote:
>> - Target "fate-vsynth%-*" tests default to sws_flags
>> "accurate_rnd+bitexact". FFV1.3 tests have "neighbor+bitexact". Why?
> it makes more cases lossless IIRC
> the default upscaling + default downscaling is not binary identical
Roger tha
Hello,
I've read the documentation on FATE tests, and would like to add new ones.
How can I reset the FATE test data for certain targets, without having
to re-run the whole test suite?
Thank in advance,
Pb
___
ffmpeg-devel mailing list
ffmpeg-devel@ffm
.
Replaced the reference files accordingly, and ran "make fate" to verify
that they still run properly.
What do you think?
Pb
>From be1b2ee092a82fdf70ccb99eb20d70e228205182 Mon Sep 17 00:00:00 2001
From: Peter B.
Date: Mon, 31 Aug 2015 03:02:36 +0200
Subject: [PATCH] Renamed p
Am Mo, 31.08.2015, 08:31 schrieb Carl Eugen Hoyos:
> Peter B. das-werkstatt.com> writes:
>
>> Replaced the reference files accordingly
>
> This cannot be done, we want to run fate (also)
> with old sources.
Hm. Now I'm confused...
I expected old sources to use old
Am Mo, 31.08.2015, 11:22 schrieb Hendrik Leppkes:
> On Mon, Aug 31, 2015 at 11:13 AM, Peter B. wrote:
>>
>> In my case, there are files in "tests/ref/vsynth" that contain the
>> expected reference results from tests.
>>
>> If I only provide the changed
On 08/31/2015 01:44 PM, Tobias Rapp wrote:
> On 30.08.2015 21:32, Michael Niedermayer wrote:
>>> - Target "fate-vsynth%-*" tests default to sws_flags
>>> "accurate_rnd+bitexact". FFV1.3 tests have "neighbor+bitexact". Why?
>>
>> it makes more cases lossless IIRC
>> the default upscaling + defa
On 08/30/2015 09:32 PM, Michael Niedermayer wrote:
> probably, send patches
> and probably better few and small ones at once then wait and see
> in which direction reviewes go before spending too much time in some
> specific direction
For starters, I'd like to extract the FATE tests for FFV1 to it
On 09/01/2015 09:54 PM, Peter B. wrote:
> [...]
> But actually, I think it'd be best to change the FFV1 tests to match the
> ones in "lossless-video.mak", using framecrc rather than the enc_dec
> function used in "vcodec.mak".
>
> Changing that however,
This patch makes ffv1.mak work without requiring (or being included in)
vcodec.mak.
That's another step towards having a better environment for additional
FFV1 tests.
Regards,
Pb
>From 593f1551b999fbb4c4a378d0723c2140e3b469df Mon Sep 17 00:00:00 2001
From: Peter B.
Date: Tue, 1 Sep 2015
On 09/01/2015 11:40 PM, Michael Niedermayer wrote:
>> +include tests/fate/ffv1.mak
> doesnt this belong in tests/Makefile ?
I did so first, but then all the prerequisites set in vcodec.mak are not
applied, causing ffv1.mak to fail.
So in order to keep the modifications as little as possible, I jus
Previous patch worked with "make fate", but fails to build FFmpeg after
"make clean".
I've had to do fix some unclean parts of ffv1.mak.
Patch attached.
Now everything seems to be fine again.
Regards,
Pb
>From bb0b1dd72dd334d6621221e3c55d53f8cc0485b8 Mon Sep 17 00:00
On 09/02/2015 02:53 PM, Michael Niedermayer wrote:
> the include breaks out of tree builds
> mkdir delthisdir
> cd delthisdir
> ../configure
> make -j12
> /home/michael/ffmpeg/tests/fate/vcodec.mak:71: tests/fate/ffv1.mak: No such
> file or directory
> make: *** No rule to make target `tests/fate/
I've now combined my changes into one patch.
They're basically moving ffv1 tests to ffv1.mak, and making that
independent of vcodec.mak.
Hope it works now :)
Thanks and regards,
Pb
>From 5ba0e0510269e0ee591a9505fcb4654044002743 Mon Sep 17 00:00:00 2001
From: Peter B.
Date: Tue,
On 09/07/2015 09:14 PM, Michael Niedermayer wrote:
> On Thu, Sep 03, 2015 at 10:14:13PM +0200, Peter B. wrote:
>> I've now combined my changes into one patch.
>> They're basically moving ffv1 tests to ffv1.mak, and making that
>> independent of vcodec.mak.
>>
On 09/08/2015 01:46 AM, Michael Niedermayer wrote:
> On Mon, Sep 07, 2015 at 11:18:56PM +0200, Peter B. wrote:
>> Should be fixed.
>> (Getting errors with "make fate" for some fate-dxv*, with git HEAD but
>> that seems unrelated to my changes)
> this seems to loo
Hi :)
I'm having difficulties implement FFV1 lossless FATE tests in a way that
seems more appropriate.
I'd be grateful for advice how to deal with this:
I'd rather use "framecrc" instead of the "enc_dec" method used in
vodec.mak. Yet, the usage of framecrc in the tests for other lossless
codecs i
/doxygen/trunk/structAVOption.html
>From d51af4c272d3573f4c4c94dcfe93c7c45e9d7e36 Mon Sep 17 00:00:00 2001
From: Peter B
Date: Sun, 13 Sep 2015 19:04:20 +0200
Subject: [PATCH] Adding ffv1 help reference for "coder" parameter.
---
libavcodec/ffv1enc.c |1 +
1 file changed, 1 insertion(+)
diff --git a/liba
Hello again :)
I've just noticed that the output of "ffprobe -debug 1" for FFV1 files
has different labels for same parameters in different versions.
For example:
== FFV1.1:
[ffv1 @ 0x3a8ab80] ver:1 keyframe:1 coder:0 ec:0 slices:1 bps:8
== FFV1.3:
[ffv1 @ 0x31584e0] global: ver:3.4, coder:0, c
Hello again :)
I've just noticed that by default, FFV1 chooses version "0".
I thought it would be "1".
When adding "-level 1" it properly shows "ver:1".
(and a proper value for "bps")
== For example:
Source video: https://media.xiph.org/video/derf/y4m/football_422_ntsc.y4m
$ ffmpeg -i input.a
On 09/14/2015 12:25 AM, Michael Niedermayer wrote:
> the encoder chooses the lowest version that supports the requested
> features well to maximize compatibility
Thanks for the explanation.
Sounds reasonable.
If I read [1] correcly, FFV1.0 does not store "bits_per_raw_sample".
I'd be interested i
I wanted to check what happens if someone uses an invalid parameter
combination:
"-c:v ffv1 -level 1 -slices 2"
I expected an error message about invalid slice number, but the code
selected FFV1.2:
"[ffv1 @ 0x391b060] Version 2 needed for requested features but version
2 is experimental and not e
On 09/13/2015 11:48 PM, Michael Niedermayer wrote:
>> - What is "keyframe"?
> a random access point
I'm not sure what your answer means.
I understand that "A keyframe" is a random access point. The flag in
ffprobe's output seems to always be "1".
I thought it might be the same as "intra" in FFV1.3
On 09/15/2015 08:47 PM, Michael Niedermayer wrote:
> On Tue, Sep 15, 2015 at 01:31:20AM +0200, Peter B. wrote:
>> I wanted to check what happens if someone uses an invalid parameter
>> combination:
>> "-c:v ffv1 -level 1 -slices 2"
>>
>> I expected an er
On 17/05/18 12:20, Carl Eugen Hoyos wrote:
> 2018-05-10 22:50 GMT+02:00, Carl Eugen Hoyos :
>
>> Peter Bubestinger provided a C210 file where every frame starts with
>> 64 bytes of extradata (24 byte "INFO", 16 byte "RDRT", rest "FIEL").
>> Piotr confirmed that the Canopus decoder accepts files wit
s possible.
Regards,
Pb
>From bec0905cc5b896a287d8e0953c9931e41a62972d Mon Sep 17 00:00:00 2001
From: Peter B
Date: Thu, 17 Jul 2014 18:51:38 +0200
Subject: [PATCH] fate: Add test for wav Peak Envelope Chunk encoder (levl
chunk).
---
tests/fate/avformat.mak |2 ++
tests/lavf-regression.
On 07/18/2014 07:40 PM, Michael Niedermayer wrote:
> applied
Thanks!
Pb
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
41 matches
Mail list logo
