Hello, we have -f crc, but IMO 32 bit crc are a bit little for a whole file and also we use md5sum in the regression tests, so I'd propose to add a -f md5 as in attached patch.
On Sun, Sep 27, 2009 at 12:04:27PM +0200, Reimar D?ffinger wrote:
Hello, we have -f crc, but IMO 32 bit crc are a bit little for a whole file and also we use md5sum in the regression tests, so I'd propose to add a -f md5 as in attached patch.
Another crazy idea would be to do like in image2 muxer: ffmpeg -i INFILE -f checksum 1.md5 ffmpeg -i INFILE -f checksum 1.rc4 ffmpeg -i INFILE -f checksum 1.crc
On Sun, Sep 27, 2009 at 01:15:08PM +0300, Kostya wrote:
On Sun, Sep 27, 2009 at 12:04:27PM +0200, Reimar D?ffinger wrote:
Hello, we have -f crc, but IMO 32 bit crc are a bit little for a whole file and also we use md5sum in the regression tests, so I'd propose to add a -f md5 as in attached patch.
Another crazy idea would be to do like in image2 muxer: ffmpeg -i INFILE -f checksum 1.md5 ffmpeg -i INFILE -f checksum 1.rc4 ffmpeg -i INFILE -f checksum 1.crc
Output is usually to stdout, so that seems like not very useful.
Kostya <kostya.shishkov at gmail.com> writes:
On Sun, Sep 27, 2009 at 12:04:27PM +0200, Reimar D?ffinger wrote:
Hello, we have -f crc, but IMO 32 bit crc are a bit little for a whole file and also we use md5sum in the regression tests, so I'd propose to add a -f md5 as in attached patch.
Another crazy idea would be to do like in image2 muxer: ffmpeg -i INFILE -f checksum 1.md5 ffmpeg -i INFILE -f checksum 1.rc4 ffmpeg -i INFILE -f checksum 1.crc
Make it a pixel format ;-) -- M?ns Rullg?rd mans at mansr.com
M?ns Rullg?rd wrote:
Kostya <kostya.shishkov at gmail.com> writes:
On Sun, Sep 27, 2009 at 12:04:27PM +0200, Reimar D?ffinger wrote:
Hello, we have -f crc, but IMO 32 bit crc are a bit little for a whole file and also we use md5sum in the regression tests, so I'd propose to add a -f md5 as in attached patch. Another crazy idea would be to do like in image2 muxer: ffmpeg -i INFILE -f checksum 1.md5 ffmpeg -i INFILE -f checksum 1.rc4 ffmpeg -i INFILE -f checksum 1.crc
Make it a pixel format ;-)
Or a new parameter called '-hash_fmt'. -- -Mike Melanson
Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
Hello, we have -f crc, but IMO 32 bit crc are a bit little for a whole file and also we use md5sum in the regression tests, so I'd propose to add a -f md5 as in attached patch.
I like the idea. It would simplify both regression tests and FATE, as well as give our md5 code some testing. -- M?ns Rullg?rd mans at mansr.com
Reimar D?ffinger wrote:
Hello, we have -f crc, but IMO 32 bit crc are a bit little for a whole file and also we use md5sum in the regression tests, so I'd propose to add a -f md5 as in attached patch.
Thanks. I was just about to hack something up pursuant to my latest blog post on the matter[1]. But I thought I would check ffmpeg-devel since I had a feeling you might beat me to it. :) [1] http://multimedia.cx/eggs/revised-fate-test-types/ -- -Mike Melanson
On Sun, Sep 27, 2009 at 12:04:27PM +0200, Reimar D?ffinger wrote:
Hello, we have -f crc, but IMO 32 bit crc are a bit little for a whole file and also we use md5sum in the regression tests, so I'd propose to add a -f md5 as in attached patch.
why md5 instead of sha1? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates
On Sun, Sep 27, 2009 at 07:31:00PM +0200, Michael Niedermayer wrote:
On Sun, Sep 27, 2009 at 12:04:27PM +0200, Reimar D?ffinger wrote:
Hello, we have -f crc, but IMO 32 bit crc are a bit little for a whole file and also we use md5sum in the regression tests, so I'd propose to add a -f md5 as in attached patch.
why md5 instead of sha1?
Judging by previous replies, most of caring people want to have all possible checksums.
[...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
On Sun, Sep 27, 2009 at 07:31:00PM +0200, Michael Niedermayer wrote:
On Sun, Sep 27, 2009 at 12:04:27PM +0200, Reimar D?ffinger wrote:
we have -f crc, but IMO 32 bit crc are a bit little for a whole file and also we use md5sum in the regression tests, so I'd propose to add a -f md5 as in attached patch.
why md5 instead of sha1?
Because md5 makes more sense for the simple reasons that 1) we already use it in regression tests 2) a md5/md5sum binary is available anywhere, I do not know something comparable for sha 3) for security-relevant stuff they are all "useless" Which leaves me to ask: why sha1? I don't really see anything in its favour (though supporting both, is trivial, the only question would be how, I do not like any of the methods proposed so far).
On Sun, 2009-09-27 at 19:53 +0200, Reimar D?ffinger wrote:
On Sun, Sep 27, 2009 at 07:31:00PM +0200, Michael Niedermayer wrote:
why md5 instead of sha1?
2) a md5/md5sum binary is available anywhere, I do not know something comparable for sha
sha1sum, part of gnu coreutils (along with various sizes of sha2 hashes) and quite standard.
3) for security-relevant stuff they are all "useless"
AFAIK practical SHA1 security is still way above MD5.
Which leaves me to ask: why sha1? I don't really see anything in its favour (though supporting both, is trivial, the only question would be how, I do not like any of the methods proposed so far).
SHA1 is the more standard algorithm. Although SHA1 may not be recommendable for new security-relevant systems it's not yet clear exactly what will be the next "basic" hash. Why would anyone still use MD5 for anything? Only because of outdated systems that only have MD5 utilities several years after MD5 has become obsolete?
On Sun Sep 27 19:53:18 2009 Reimar D?ffinger wrote: >>> we have -f crc, but IMO 32 bit crc are a bit little for a whole file and >>> also we use md5sum in the regression tests, so I'd propose to add a -f >>> md5 as in attached patch. >> why md5 instead of sha1? > Because md5 makes more sense for the simple reasons that > 1) we already use it in regression tests > 2) a md5/md5sum binary is available anywhere, I do not know > something comparable for sha Just for the record, codec-regression.sh contains nothing suitable for NetBSD because md5sum does not exist and -r is unsupported by md5. OTOH: % gmd5sum -b .zshrc 0a4998dca23450d99f6fccee3a28d000 *.zshrc % md5 .zshrc MD5 (.zshrc) = 0a4998dca23450d99f6fccee3a28d000 % md5 -n .zshrc 0a4998dca23450d99f6fccee3a28d000 .zshrc % openssl dgst -md5 .zshrc MD5(.zshrc)= 0a4998dca23450d99f6fccee3a28d000 Michael
On Sun, Sep 27, 2009 at 11:06:57PM +0400, Michael Kostylev wrote: > > On Sun Sep 27 19:53:18 2009 > Reimar D?ffinger wrote: > > >>> we have -f crc, but IMO 32 bit crc are a bit little for a whole file and > >>> also we use md5sum in the regression tests, so I'd propose to add a -f > >>> md5 as in attached patch. > >> why md5 instead of sha1? > > Because md5 makes more sense for the simple reasons that > > 1) we already use it in regression tests > > 2) a md5/md5sum binary is available anywhere, I do not know > > something comparable for sha > > Just for the record, codec-regression.sh contains nothing suitable > for NetBSD because md5sum does not exist and -r is unsupported by md5. OTOH: > > % gmd5sum -b .zshrc > 0a4998dca23450d99f6fccee3a28d000 *.zshrc > > % md5 .zshrc > MD5 (.zshrc) = 0a4998dca23450d99f6fccee3a28d000 > > % md5 -n .zshrc > 0a4998dca23450d99f6fccee3a28d000 .zshrc > > % openssl dgst -md5 .zshrc > MD5(.zshrc)= 0a4998dca23450d99f6fccee3a28d000 So what would work reliably? Patches are welcome. Diego
Diego Biurrun <diego at biurrun.de> writes: > On Sun, Sep 27, 2009 at 11:06:57PM +0400, Michael Kostylev wrote: >> >> On Sun Sep 27 19:53:18 2009 >> Reimar D?ffinger wrote: >> >> >>> we have -f crc, but IMO 32 bit crc are a bit little for a whole file and >> >>> also we use md5sum in the regression tests, so I'd propose to add a -f >> >>> md5 as in attached patch. >> >> why md5 instead of sha1? >> > Because md5 makes more sense for the simple reasons that >> > 1) we already use it in regression tests >> > 2) a md5/md5sum binary is available anywhere, I do not know >> > something comparable for sha >> >> Just for the record, codec-regression.sh contains nothing suitable >> for NetBSD because md5sum does not exist and -r is unsupported by md5. OTOH: >> >> % gmd5sum -b .zshrc >> 0a4998dca23450d99f6fccee3a28d000 *.zshrc >> >> % md5 .zshrc >> MD5 (.zshrc) = 0a4998dca23450d99f6fccee3a28d000 >> >> % md5 -n .zshrc >> 0a4998dca23450d99f6fccee3a28d000 .zshrc >> >> % openssl dgst -md5 .zshrc >> MD5(.zshrc)= 0a4998dca23450d99f6fccee3a28d000 > > So what would work reliably? Patches are welcome. Reimar's md5 "muxer" would work fine. -- M?ns Rullg?rd mans at mansr.com
On Mon, Sep 28, 2009 at 03:17:47AM +0100, M?ns Rullg?rd wrote: > Diego Biurrun <diego at biurrun.de> writes: > > > On Sun, Sep 27, 2009 at 11:06:57PM +0400, Michael Kostylev wrote: > >> > >> On Sun Sep 27 19:53:18 2009 > >> Reimar D?ffinger wrote: > >> > >> >>> we have -f crc, but IMO 32 bit crc are a bit little for a whole file and > >> >>> also we use md5sum in the regression tests, so I'd propose to add a -f > >> >>> md5 as in attached patch. > >> >> why md5 instead of sha1? > >> > Because md5 makes more sense for the simple reasons that > >> > 1) we already use it in regression tests > >> > 2) a md5/md5sum binary is available anywhere, I do not know > >> > something comparable for sha > >> > >> Just for the record, codec-regression.sh contains nothing suitable > >> for NetBSD because md5sum does not exist and -r is unsupported by md5. OTOH: > >> > >> % gmd5sum -b .zshrc > >> 0a4998dca23450d99f6fccee3a28d000 *.zshrc > >> > >> % md5 .zshrc > >> MD5 (.zshrc) = 0a4998dca23450d99f6fccee3a28d000 > >> > >> % md5 -n .zshrc > >> 0a4998dca23450d99f6fccee3a28d000 .zshrc > >> > >> % openssl dgst -md5 .zshrc > >> MD5(.zshrc)= 0a4998dca23450d99f6fccee3a28d000 > > > > So what would work reliably? Patches are welcome. > > Reimar's md5 "muxer" would work fine. Doesn't work to test the muxers themselves. However it wouldn't be hard to write our own, in which case we could also switch to sha256 (or use both).
On Mon Sep 28 03:43:59 2009 Diego Biurrun wrote: >>>>> we have -f crc, but IMO 32 bit crc are a bit little for a whole file and >>>>> also we use md5sum in the regression tests, so I'd propose to add a -f >>>>> md5 as in attached patch. >>>> why md5 instead of sha1? >>> Because md5 makes more sense for the simple reasons that >>> 1) we already use it in regression tests >>> 2) a md5/md5sum binary is available anywhere, I do not know >>> something comparable for sha >> >> Just for the record, codec-regression.sh contains nothing suitable >> for NetBSD because md5sum does not exist and -r is unsupported by md5. OTOH: >> >> % gmd5sum -b .zshrc >> 0a4998dca23450d99f6fccee3a28d000 *.zshrc >> >> % md5 .zshrc >> MD5 (.zshrc) = 0a4998dca23450d99f6fccee3a28d000 >> >> % md5 -n .zshrc >> 0a4998dca23450d99f6fccee3a28d000 .zshrc >> >> % openssl dgst -md5 .zshrc >> MD5(.zshrc)= 0a4998dca23450d99f6fccee3a28d000 > > So what would work reliably? Patches are welcome. Attached. Michael
On Mon, Sep 28, 2009 at 02:03:44PM +0400, Michael Kostylev wrote: > > On Mon Sep 28 03:43:59 2009 > Diego Biurrun wrote: > > >>>>> we have -f crc, but IMO 32 bit crc are a bit little for a whole file and > >>>>> also we use md5sum in the regression tests, so I'd propose to add a -f > >>>>> md5 as in attached patch. > >>>> why md5 instead of sha1? > >>> Because md5 makes more sense for the simple reasons that > >>> 1) we already use it in regression tests > >>> 2) a md5/md5sum binary is available anywhere, I do not know > >>> something comparable for sha > >> > >> Just for the record, codec-regression.sh contains nothing suitable > >> for NetBSD because md5sum does not exist and -r is unsupported by md5. OTOH: > >> > >> % gmd5sum -b .zshrc > >> 0a4998dca23450d99f6fccee3a28d000 *.zshrc > >> > >> % md5 .zshrc > >> MD5 (.zshrc) = 0a4998dca23450d99f6fccee3a28d000 > >> > >> % md5 -n .zshrc > >> 0a4998dca23450d99f6fccee3a28d000 .zshrc > >> > >> % openssl dgst -md5 .zshrc > >> MD5(.zshrc)= 0a4998dca23450d99f6fccee3a28d000 > > > > So what would work reliably? Patches are welcome. > > Attached. Applied, thanks. Let's see if that fixes some of those FATE machines... Diego
On Sun, Sep 27, 2009 at 07:53:18PM +0200, Reimar D?ffinger wrote:
On Sun, Sep 27, 2009 at 07:31:00PM +0200, Michael Niedermayer wrote:
On Sun, Sep 27, 2009 at 12:04:27PM +0200, Reimar D?ffinger wrote:
we have -f crc, but IMO 32 bit crc are a bit little for a whole file and also we use md5sum in the regression tests, so I'd propose to add a -f md5 as in attached patch.
why md5 instead of sha1?
Because md5 makes more sense for the simple reasons that 1) we already use it in regression tests 2) a md5/md5sum binary is available anywhere, I do not know something comparable for sha 3) for security-relevant stuff they are all "useless"
Which leaves me to ask: why sha1? I don't really see anything in its favour
well, because someone could use it with source files under outside control. I would guess that in that case it can likely be used to return misleading values ... one could use it to detect files with duplicate content, for example ... <automatic app>ahh goatse.mkv contains the same as bible_readings_for_children.mkv so lets skip the expensive human check of content and allow it be uploaded as a new revission ... now iam not a religious person and neither one of thouse who think such content would seriously harm a child (they plain wouldnt understand it or if they are older would find it disgusting or funny but iam much more betting on disgusting here) but it still feels kinda like a very annoying thing and sure better if something like that didnt happen ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
On Sun, Sep 27, 2009 at 10:56:30PM +0200, Michael Niedermayer wrote:
On Sun, Sep 27, 2009 at 07:53:18PM +0200, Reimar D?ffinger wrote:
On Sun, Sep 27, 2009 at 07:31:00PM +0200, Michael Niedermayer wrote:
On Sun, Sep 27, 2009 at 12:04:27PM +0200, Reimar D?ffinger wrote:
we have -f crc, but IMO 32 bit crc are a bit little for a whole file and also we use md5sum in the regression tests, so I'd propose to add a -f md5 as in attached patch.
why md5 instead of sha1?
Because md5 makes more sense for the simple reasons that 1) we already use it in regression tests 2) a md5/md5sum binary is available anywhere, I do not know something comparable for sha 3) for security-relevant stuff they are all "useless"
Which leaves me to ask: why sha1? I don't really see anything in its favour
well, because someone could use it with source files under outside control. I would guess that in that case it can likely be used to return misleading values ...
For that sha256 may barely be enough, but surely not sha1. However it's not a big deal to provide both or more, the question is just how. I'd favour a one muxer per hash format approach (though possibly in the same file as for the raw formats).
On Mon, Sep 28, 2009 at 09:30:36AM +0200, Reimar D?ffinger wrote:
On Sun, Sep 27, 2009 at 10:56:30PM +0200, Michael Niedermayer wrote:
On Sun, Sep 27, 2009 at 07:53:18PM +0200, Reimar D?ffinger wrote:
On Sun, Sep 27, 2009 at 07:31:00PM +0200, Michael Niedermayer wrote:
On Sun, Sep 27, 2009 at 12:04:27PM +0200, Reimar D?ffinger wrote:
we have -f crc, but IMO 32 bit crc are a bit little for a whole file and also we use md5sum in the regression tests, so I'd propose to add a -f md5 as in attached patch.
why md5 instead of sha1?
Because md5 makes more sense for the simple reasons that 1) we already use it in regression tests 2) a md5/md5sum binary is available anywhere, I do not know something comparable for sha 3) for security-relevant stuff they are all "useless"
Which leaves me to ask: why sha1? I don't really see anything in its favour
well, because someone could use it with source files under outside control. I would guess that in that case it can likely be used to return misleading values ...
For that sha256 may barely be enough, but surely not sha1. However it's not a big deal to provide both or more, the question is just how. I'd favour a one muxer per hash format approach (though possibly in the same file as for the raw formats).
i thought a project that doesnt specialize onto hashes would be fine with a fast one and a secure one ... when it makes sense to put these in the same file then ian of course fine with that [...] -- 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
Michael Niedermayer wrote:
On Sun, Sep 27, 2009 at 12:04:27PM +0200, Reimar D?ffinger wrote:
Hello, we have -f crc, but IMO 32 bit crc are a bit little for a whole file and also we use md5sum in the regression tests, so I'd propose to add a -f md5 as in attached patch.
why md5 instead of sha1?
I knew this would degenerate into a bikeshed discussion. The good news is that whatever we decide, I'll be able to integrate it into FATE. -- -Mike Melanson
On Sun, Sep 27, 2009 at 3:04 AM, Reimar D?ffinger <Reimar.Doeffinger at gmx.de>wrote:
Hello, we have -f crc, but IMO 32 bit crc are a bit little for a whole file and also we use md5sum in the regression tests, so I'd propose to add a -f md5 as in attached patch.
Nicely done. Clean code, with a solid checksum function thats widely available. I'd like to see this checked in.
Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
Hello, we have -f crc, but IMO 32 bit crc are a bit little for a whole file and also we use md5sum in the regression tests, so I'd propose to add a -f md5 as in attached patch.
And as usual, people adding so much to the list of requirements that nothing at all got done in the end. Just apply this so we can use it. -- M?ns Rullg?rd mans at mansr.com
On Sun, May 23, 2010 at 01:38:21PM +0100, M?ns Rullg?rd wrote:
Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
Hello, we have -f crc, but IMO 32 bit crc are a bit little for a whole file and also we use md5sum in the regression tests, so I'd propose to add a -f md5 as in attached patch.
And as usual, people adding so much to the list of requirements that nothing at all got done in the end.
Just apply this so we can use it.
Applied. Attached would extend this by a framemd5 muxer in addition.
Reimar D?ffinger wrote:
On Sun, May 23, 2010 at 01:38:21PM +0100, M?ns Rullg?rd wrote:
Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
Hello, we have -f crc, but IMO 32 bit crc are a bit little for a whole file and also we use md5sum in the regression tests, so I'd propose to add a -f md5 as in attached patch. And as usual, people adding so much to the list of requirements that nothing at all got done in the end.
Just apply this so we can use it.
Applied. Attached would extend this by a framemd5 muxer in addition.
Whatever happened to the bikeshed arguments regarding whether we should also support some variant of SHA? -- -Mike Melanson
Mike Melanson <mike at multimedia.cx> writes:
Reimar D?ffinger wrote:
On Sun, May 23, 2010 at 01:38:21PM +0100, M?ns Rullg?rd wrote:
Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
Hello, we have -f crc, but IMO 32 bit crc are a bit little for a whole file and also we use md5sum in the regression tests, so I'd propose to add a -f md5 as in attached patch. And as usual, people adding so much to the list of requirements that nothing at all got done in the end.
Just apply this so we can use it. Applied. Attached would extend this by a framemd5 muxer in addition.
Whatever happened to the bikeshed arguments regarding whether we should also support some variant of SHA?
We decided to ignore them. If people want that, they can send their own patches. -- M?ns Rullg?rd mans at mansr.com
On Sun, May 23, 2010 at 04:02:38PM +0100, M?ns Rullg?rd wrote:
Mike Melanson <mike at multimedia.cx> writes:
Reimar D?ffinger wrote:
On Sun, May 23, 2010 at 01:38:21PM +0100, M?ns Rullg?rd wrote:
Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
Hello, we have -f crc, but IMO 32 bit crc are a bit little for a whole file and also we use md5sum in the regression tests, so I'd propose to add a -f md5 as in attached patch. And as usual, people adding so much to the list of requirements that nothing at all got done in the end.
Just apply this so we can use it. Applied. Attached would extend this by a framemd5 muxer in addition.
Whatever happened to the bikeshed arguments regarding whether we should also support some variant of SHA?
We decided to ignore them. If people want that, they can send their own patches.
i agree with this patch being applied i dont agree to ignoring review comments though, one should at least attempt to politely ask the person commenting first. Chances are one would quickly find a solution if the comment really went too far which it did in this case. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting.
On Sun, May 23, 2010 at 07:38:10PM +0200, Michael Niedermayer wrote:
On Sun, May 23, 2010 at 04:02:38PM +0100, M?ns Rullg?rd wrote:
Mike Melanson <mike at multimedia.cx> writes:
Reimar D?ffinger wrote:
On Sun, May 23, 2010 at 01:38:21PM +0100, M?ns Rullg?rd wrote:
Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
Hello, we have -f crc, but IMO 32 bit crc are a bit little for a whole file and also we use md5sum in the regression tests, so I'd propose to add a -f md5 as in attached patch. And as usual, people adding so much to the list of requirements that nothing at all got done in the end.
Just apply this so we can use it. Applied. Attached would extend this by a framemd5 muxer in addition.
Whatever happened to the bikeshed arguments regarding whether we should also support some variant of SHA?
We decided to ignore them. If people want that, they can send their own patches.
i agree with this patch being applied i dont agree to ignoring review comments though, one should at least attempt to politely ask the person commenting first. Chances are one would quickly find a solution if the comment really went too far which it did in this case.
It wasn't my intention to disrespect anyone by applied, just after re-reading it I just concluded that nobody really objected to the patch in itself and improvements could still be made afterwards + nobody cared enough to make any further comments in a long time.
Hi Reimar, On 5/23/10 6:28 AM, Reimar D?ffinger wrote:
On Sun, May 23, 2010 at 01:38:21PM +0100, M?ns Rullg?rd wrote:
Reimar D?ffinger<Reimar.Doeffinger at gmx.de> writes:
Hello, we have -f crc, but IMO 32 bit crc are a bit little for a whole file and also we use md5sum in the regression tests, so I'd propose to add a -f md5 as in attached patch.
And as usual, people adding so much to the list of requirements that nothing at all got done in the end.
Just apply this so we can use it.
Applied. Attached would extend this by a framemd5 muxer in addition.
Great, thanks !
Index: libavformat/md5enc.c =================================================================== --- libavformat/md5enc.c (revision 23257) +++ libavformat/md5enc.c (working copy) @@ -24,6 +24,23 @@
#define PRIVSIZE 512
+static void md5_finish(struct AVFormatContext *s, char *buf) +{ + uint8_t md5[16]; + int i, offset = strlen(buf); + av_md5_final(s->priv_data, md5); + for (i = 0; i< sizeof(md5); i++) { + snprintf(buf + offset, 3, "%02"PRIx8, md5[i]); + offset += 2; + } + buf[offset] = '\n'; + buf[offset+1] = 0;
Nitpick, but you can put_buffer(s->pb, "\n", 1); [...] Btw, I'm having hard time getting same results for: mplayer test.y4m -vo md5sum:outfile=/dev/stdout and ffmpeg -i test.y4m -f framemd5 - This is weird. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org
On Sun, May 23, 2010 at 03:30:10PM -0700, Baptiste Coudurier wrote:
+static void md5_finish(struct AVFormatContext *s, char *buf) +{ + uint8_t md5[16]; + int i, offset = strlen(buf); + av_md5_final(s->priv_data, md5); + for (i = 0; i< sizeof(md5); i++) { + snprintf(buf + offset, 3, "%02"PRIx8, md5[i]); + offset += 2; + } + buf[offset] = '\n'; + buf[offset+1] = 0;
Nitpick, but you can put_buffer(s->pb, "\n", 1);
Haven't checked if it makes a difference within the framework, but I'd prefer it if the whole data was done with a single write, can give nicer output if it is written to stdout in a multithreaded environment.
[...]
Btw, I'm having hard time getting same results for: mplayer test.y4m -vo md5sum:outfile=/dev/stdout and ffmpeg -i test.y4m -f framemd5 -
MPlayer interleaves the U and V lines when calculating the MD5. No idea if that is intentional... I suspect this should make them match: Index: libvo/vo_md5sum.c =================================================================== --- libvo/vo_md5sum.c (revision 31204) +++ libvo/vo_md5sum.c (working copy) @@ -219,6 +219,8 @@ h = h / 2; for (i=0; i<h; i++) { av_md5_update(md5_context, planeU + i * strideU, w); + } + for (i=0; i<h; i++) { av_md5_update(md5_context, planeV + i * strideV, w); } av_md5_final(md5_context, md5sum);
On 5/23/10 4:31 PM, Reimar D?ffinger wrote:
On Sun, May 23, 2010 at 03:30:10PM -0700, Baptiste Coudurier wrote:
+static void md5_finish(struct AVFormatContext *s, char *buf) +{ + uint8_t md5[16]; + int i, offset = strlen(buf); + av_md5_final(s->priv_data, md5); + for (i = 0; i< sizeof(md5); i++) { + snprintf(buf + offset, 3, "%02"PRIx8, md5[i]); + offset += 2; + } + buf[offset] = '\n'; + buf[offset+1] = 0;
Nitpick, but you can put_buffer(s->pb, "\n", 1);
Haven't checked if it makes a difference within the framework, but I'd prefer it if the whole data was done with a single write, can give nicer output if it is written to stdout in a multithreaded environment.
All right.
[...]
Btw, I'm having hard time getting same results for: mplayer test.y4m -vo md5sum:outfile=/dev/stdout and ffmpeg -i test.y4m -f framemd5 -
MPlayer interleaves the U and V lines when calculating the MD5. No idea if that is intentional... I suspect this should make them match: Index: libvo/vo_md5sum.c =================================================================== --- libvo/vo_md5sum.c (revision 31204) +++ libvo/vo_md5sum.c (working copy) @@ -219,6 +219,8 @@ h = h / 2; for (i=0; i<h; i++) { av_md5_update(md5_context, planeU + i * strideU, w); + } + for (i=0; i<h; i++) { av_md5_update(md5_context, planeV + i * strideV, w); } av_md5_final(md5_context, md5sum);
Indeed it works. This is weird, thanks. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org
Reimar D?ffinger <Reimar.Doeffinger <at> gmx.de> writes:
Index: libvo/vo_md5sum.c =================================================================== --- libvo/vo_md5sum.c (revision 31204) +++ libvo/vo_md5sum.c (working copy) @@ -219,6 +219,8 @@ h = h / 2; for (i=0; i<h; i++) { av_md5_update(md5_context, planeU + i * strideU, w); + } + for (i=0; i<h; i++) {
Please apply, this would finally allow vc1 conformance tests (and other tests to compare MPlayer and FFmpeg output). I will do the news entry on mplayerhq if needed. Carl Eugen
On 5/23/10 4:31 PM, Reimar D?ffinger wrote:
On Sun, May 23, 2010 at 03:30:10PM -0700, Baptiste Coudurier wrote:
+static void md5_finish(struct AVFormatContext *s, char *buf) +{ + uint8_t md5[16]; + int i, offset = strlen(buf); + av_md5_final(s->priv_data, md5); + for (i = 0; i< sizeof(md5); i++) { + snprintf(buf + offset, 3, "%02"PRIx8, md5[i]); + offset += 2; + } + buf[offset] = '\n'; + buf[offset+1] = 0;
Nitpick, but you can put_buffer(s->pb, "\n", 1);
Haven't checked if it makes a difference within the framework, but I'd prefer it if the whole data was done with a single write, can give nicer output if it is written to stdout in a multithreaded environment.
This is irrelevant considering put_buffer is buffered. [...] -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org
participants (11)
-
baptiste.coudurier＠gmail.com -
cehoyos＠ag.or.at -
diego＠biurrun.de -
fbarchard＠google.com -
kostya.shishkov＠gmail.com -
mans＠mansr.com -
michael.kostylev＠gmail.com -
michaelni＠gmx.at -
mike＠multimedia.cx -
Reimar.Doeffinger＠gmx.de -
uoti.urpala＠pp1.inet.fi