[FFmpeg-devel] hashing audio streams beyond pcm_s16le

w 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 hash

Re: [FFmpeg-devel] FFV1 slicecrc: "hashxx" instead of "CRC" for speed?

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

[FFmpeg-devel] FFV1 slicecrc: "hashxx" instead of "CRC" for speed?

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

[FFmpeg-devel] Feature request: Segment using info from textfile?

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. # Links

[FFmpeg-devel] Feature request: "overlap" option for segment muxer?

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_005fsegment_002

Re: [FFmpeg-devel] [PATCH] avcodec/ffv1enc: Use version 3 by default (CRCs by default)

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 objections? K

Re: [FFmpeg-devel] [PATCH v2 3/3] avformat/hashenc: add streamhash muxer

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

Re: [FFmpeg-devel] [PATCH v2 3/3] avformat/hashenc: add streamhash muxer

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=... 2,a,S

Re: [FFmpeg-devel] [PATCH]lavc/v210dec: Skip Canopus C210 extradata

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

Re: [FFmpeg-devel] [PATCH]lavf/matroska: Support codec id V_FFV1 for FFV1.

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

Re: [FFmpeg-devel] FFV1: Invalid parameter combination triggers FFV1.2

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

Re: [FFmpeg-devel] ffprobe -debug 1: Output for FFV1 inconsistent

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

[FFmpeg-devel] FFV1: Invalid parameter combination triggers FFV1.2

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

Re: [FFmpeg-devel] FFV1: version 0 vs 1?

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

[FFmpeg-devel] FATE: testing lossless video differently

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

[FFmpeg-devel] [PATCH] Adding ffv1 help reference for "coder" parameter.

runk/structAVOption.html >From d51af4c272d3573f4c4c94dcfe93c7c45e9d7e36 Mon Sep 17 00:00:00 2001 From: Peter B <p...@das-werkstatt.com> 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(+

[FFmpeg-devel] FFV1: version 0 vs 1?

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

[FFmpeg-devel] ffprobe -debug 1: Output for FFV1 inconsistent

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,

Re: [FFmpeg-devel] [PATCH] Extract FFV1 FATE tests to own Makefile, 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

Re: [FFmpeg-devel] [PATCH] Extract FFV1 FATE tests to own Makefile, independent of vcodec.mak

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. >> >> H

Re: [FFmpeg-devel] [PATCH] Extract FFV1 FATE tests to own Makefile, independent of vcodec.mak

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. <p...@das-werksta

Re: [FFmpeg-devel] Adding FATE tests for FFV1 - revisited

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

[FFmpeg-devel] [PATCH 2/2] Changed FFV1 tests to work independet of vcodec.mak

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. <p...@das-werkstatt.com

Re: [FFmpeg-devel] [PATCH 1/2] Extract FFV1 FATE tests to own Makefile

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, makes

Re: [FFmpeg-devel] [PATCH 1/2] Extract FFV1 FATE tests to own Makefile

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

Re: [FFmpeg-devel] [PATCH 2/2] Changed FFV1 tests to work independet of vcodec.mak

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:0

Re: [FFmpeg-devel] Adding FATE tests for FFV1 - revisited

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 +

Re: [FFmpeg-devel] [PATCH] Cleaning existing FFV1 tests

Am Mo, 31.08.2015, 11:22 schrieb Hendrik Leppkes: > On Mon, Aug 31, 2015 at 11:13 AM, Peter B. <p...@das-werkstatt.com> wrote: >> >> In my case, there are files in "tests/ref/vsynth" that contain the >> expected reference results from tests. >> >>

Re: [FFmpeg-devel] [PATCH] Cleaning existing FFV1 tests

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 us

Re: [FFmpeg-devel] Adding FATE tests for FFV1 - revisited

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 that. The way

Re: [FFmpeg-devel] Adding FATE tests for FFV1 - revisited

On 08/30/2015 07:33 PM, Paul B Mahol wrote: On 8/30/15, Peter B. p...@das-werkstatt.com 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 to add

[FFmpeg-devel] Clean/reset FATE test data?

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] Adding FATE tests for FFV1 - revisited

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

Re: [FFmpeg-devel] [PATCH] Cleaning existing FFV1 tests

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. p...@das-werkstatt.com Date: Mon, 31 Aug 2015 03:02:36 +0200 Subject: [PATCH] Renamed pix_fmts wording in test

Re: [FFmpeg-devel] Matroska and PCM variants, error in encoding?

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

Re: [FFmpeg-devel] Please help update tasks and mentor/backups for OPW

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

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

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-devel

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

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

[FFmpeg-devel] [PATCH] fate: Add test for wav Peak Envelope Chunk encoder (levl, chunk).

, Pb From bec0905cc5b896a287d8e0953c9931e41a62972d Mon Sep 17 00:00:00 2001 From: Peter B p...@das-werkstatt.com 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