Hello Carl, I want to first thank you Carl for your efforts and help with getting ***partial*** support for AJA 10 Bit RGB 444 r10k (little r). You helped to move this along! So thank you! I owe that to you. This is support for r10k and NOT R10k since we see there is a difference.
However, I also realize we are no longer going to get anywhere in resolving this the way I would like. I can see your reluctance, Carl, to want to resolve this problem. I have little patience when there is an apparent problem, others see the problem and understand it, but then do not care or act to resolve it. That aside, for now, I have a resolution for my problems: after lengthy discussions with a fellow engineer, he will make modifications to FFmpeg on my behalf so I can both encode and decode true r10k (Little Endian). He said this would be easy for him to do. For now these will be personal modifications so I can continue moving forward on my own in the next few months. The realization is that FFmpeg has a bug that no one seems to really want to resolve: FFmpeg associates R10k as being r10k syntactically. This is obviously inconsistent and incorrect. Here, the syntax under FFmpeg to encode or decode R10k (Big Endian) is to use the "-vcodec r10k". So syntactically FFmpeg is specifying the encode/decode R10k codec with "r10k" syntax, which is FFmpeg's problem in their choice of syntax. Because of that, it does not leave room for adding in r10k (Little Endian) into FFmpeg as they would conflict. It would be nice if FFmpeg can do both: use "-vcodec r10k" for FourCC "r10k" Little Endian. And use "-vcodec R10k" for FourCC "R10k" Big Endian. Then EVERYONE is happy! FFmpeg ***could*** be made to do both. But first you have to correct the mistake in having chosen "-vcodec r10k" as a means to encode/decode R10k. This, FFmpeg seems reluctant to do. And, it is disappointing. Sure, yes, it would be a change. Yes, some users would complain. But, it would make FFmpeg a bit more consistent. When a user wants R10k (Big Endian), they use "-vcodec R10k". When they want r10k (Little Endian), they can use "-vcodec r10k". This is nice! It provides support for both ends. And it goes along with the FourCC identifier. Instead, FFmpeg made a mistake. Instead of fixing it, the choice is to ignore support for r10k (Little Endian) codec. This conflict is really the problem with FFmpeg and their choices. To me, it is clearer if the syntax would be corrected to be "-vcodec R10k" when people want to encode or decode Big Endian R10k. Why? Again, because FourCC defines R10k as that: R10k. Internally, FFmpeg correctly encodes and decodes R10k (Big Endian). But the syntax to encode or decode R10k in my book is incorrect as the user must supply "-vcodec r10k" to make that happen. So when I use r10k, I really get R10k (Big Endian). Very annoying! Not only annoying, but really not correct either. Bad choice FFmpeg. Again to repeat my point, so when someone uses FFmpeg and want's to encode or decode R10k, what syntax do they use? They use "-vcodec r10k", which to be honest is quite dumb and incorrect. Why? Because wheny they use "-vcodec r10k" they don't get r10k (Little Endian), they actually get R10k (Big Endian). In the world of FourCC there is a difference! Not sure how to be any clearer on this. r10k and R10k are NOT the same. I've provided AJA video samples to prove my point too. Carl realizes this is true. For the community, I may then later have him (my engineer) submit his modification to FFmpeg for future considerations. I'd like to first talk with him more to see what modifications he would have to make to FFmpeg to fix this bug with FFmpeg. Either way, for now, I will have a way forward. To that end, I am now happy. For those in the future who may read this, if other users would like r10k (Little Endian) support under FFmpeg, they can then email me. Again, this is support for AJA 10 Bit RGB 444 Lossless r10k (Little Endian). Cheers, Jason > Subject: Re: [FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) > Compression > > > Subject: Re: [FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) > > Compression > > > > Jason Freets <jasonslife <at> hotmail.com> writes: > > > > > I wouldn't use FFmpeg if I didn't trust it =). For > > > v210, I've proven it to myself and use FFV1 a lot. > > > For r10k, it's still not there yet. > > > > I should add here that while ffv1 is a complicated > > codec, r10k (like v210) is so trivial that you can > > be sure there is no issue after a short test. > > (I don't know how to prove that ffv1 does what you > > want, I don't even know if it can be proven.) > > > > > Making progress though. For this reason, I keep > > > everything in original r10k format. I won't > > > convert r10k files to FFV1 until I have a way to > > > verify the conversion is done properly. > > > > I showed you a way. > > Hello Carl, > > When running the following: > > ffmpeg -i r10kToFFV.avi -pix_fmt gbrp10le -vcodec r10k -c:a copy > FFVTor10k.avi -f framemd5 -an FFVTor10k.framemd5 > > ffmpeg -i "FFVTor10k.avi" -f framemd5 output.framemd5 > > Why is "FFVTor10k.framemd5" not the same as "output.framemd5"? I would expect > both "FFVTor10k.framemd5" and "output.framemd5" to be equal. Yet, they are > not. > > Ideas? > > Thanks, > > Jason > > > > > Carl Eugen > > > > _______________________________________________ > > ffmpeg-user mailing list > > [email protected] > > http://ffmpeg.org/mailman/listinfo/ffmpeg-user > > _______________________________________________ > ffmpeg-user mailing list > [email protected] > http://ffmpeg.org/mailman/listinfo/ffmpeg-user _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user
