[FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) Compression

[Jason Freets]

Hello Everyone,

My first time ever using a mailing list.

About 1 year ago, I started investigating if FFmpeg can compress lossless in two ways:

#1) 10 Bit YUV 422 r210 Original (lossless uncompressed) -> to FFV (lossless compressed) -> back to 10 Bit YUV 422 r210 (lossless uncompressed)

#2) 10 Bit RGB 444 r10k Original (lossless uncompressed) -> to FFV (lossless compressed) -> back to 10 Bit RGB 444 r10k (lossless uncompressed).

The intention here is for archiving purposes: Take my originals, compress them to FFV, and restore them in the future back to uncompressed when needed.

The results of my efforts are the two threads I started here (I am JasonCA):

http://forum.videohelp.com/threads/361133-Lossless-%2810-Bit-RGB-444%29-and-%2810-Bit-YUV-422%29-Compression-Codec-s?p=2290391&viewfull=1#post2290391

It turned out that I had great success using FFMpeg to do the following conversion:

---> 10 Bit YUV 422 r210 Original (lossless uncompressed) -> to FFV
(lossless compressed) -> back to 10 Bit YUV 422 r210 (lossless
uncompressed)

However, I could not use FFmpeg to convert the 10 Bit RGB 444 r10k files. Again, see the following link where you can see the commands issued to FFmpeg in my attempts here with r10k:

http://forum.videohelp.com/threads/361133-Lossless-%2810-Bit-RGB-444%29-and-%2810-Bit-YUV-422%29-Compression-Codec-s?p=2290391&viewfull=1#post2290391

It was advertised by Zeranoe FFmpeg that they could do both r210 and r10k. However, I didn't find this to be true, so I posted this issue on the Zeranoe FFmpeg forum:

http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=1731

I didn't get any feedback. However, I did get feedback from someone on VideoLan.org (rogerdpack) who resolved an issue with VideoLan's FFmpeg encoder:

http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=693a36b6

However, this fix is for r210. r210 didn't work with VideoLan FFmpeg but did work correctly with Zeranoe FFmpeg. By then I was using Zeranoe FFmpeg already as I gave up using VideoLan's. I've since stuck to using Zeranoe FFmpeg.

Still, this did not resolve my issue with lossless 10 Bit RGB 444 r10k compression. I am good with v210 lossless compression, but not r10k.

***Main Question***:

Is there any way I can use FFmpeg to compress in a lossless way 10 Bit RGB 444 r10k . In other words:
10 Bit RGB 444 r10k Original (lossless uncompressed) -> to FFV
(lossless compressed) -> back to 10 Bit RGB 444 r10k (lossless
uncompressed).

Despite trying (been over a year), I've never been ever to get that to work. It may not still be supported, but I thought i would ask those who would be better aware then myself.

Thanks! And since today's Christmas, Merry Christmas to all!

Jason

[Carl Eugen Hoyos]

Jason Freets <jasonslife <at> hotmail.com> writes:

> My first time ever using a mailing list.
>
> About 1 year ago, I started investigating if FFmpeg
> can compress lossless in two ways:

When I fixed your issue eleven months ago, I didn't
know how to contact you: I suggest you post all questions
(and especially all bug reports) here on the user mailing
list.

> #1) 10 Bit YUV 422 r210 Original (lossless uncompressed)
> -> to FFV (lossless compressed) -> back to 10 Bit
> YUV 422 r210 (lossless uncompressed)

I don't know much about r210 but I can assure you it is a
RGB codec...

> #2) 10 Bit RGB 444 r10k Original (lossless uncompressed)
> -> to FFV (lossless compressed) -> back to 10 Bit
> RGB 444 r10k (lossless uncompressed).

... just like r10k, they are technically nearly identical,

As said, I fixed lossless compression with ffv1 for both
r210 RGB and r10k RGB in January. If it fails for you,
please provide your command line together with the
console output here on the mailing list, please do not
use external resources (except for samples).

> By then I was using Zeranoe FFmpeg already as I
> gave up using VideoLan's.

There is some misunderstanding:
FFmpeg only provides source code (no "products"),
videolan is kindly supporting FFmpeg with their
server, meaning FFmpeg is available through the
videolan git repository (there are mirrors but
videolan is our official git archive).
Zeranoe takes the FFmpeg sources from videolan
and compiles them for the community.

> Thanks! And since today's Christmas, Merry
> Christmas to all!

Merry Christmas to you too!

Carl Eugen

[Jason Freets]

Exciting, my first reply in a mailing list ... =). See my response below ...

> Jason Freets <jasonslife <at> hotmail.com> writes:
>
> > My first time ever using a mailing list.
> >
> > About 1 year ago, I started investigating if FFmpeg
> > can compress lossless in two ways:
>
> When I fixed your issue eleven months ago, I didn't
> know how to contact you: I suggest you post all questions
> (and especially all bug reports) here on the user mailing
> list.

Yes, I didn't get a response until a few months later in my post. I therefore, stopped checking in to that specific thread. But, I saw the suggestion most recently and so I did just that. And so here I am now.

>
> > #1) 10 Bit YUV 422 r210 Original (lossless uncompressed)
> > -> to FFV (lossless compressed) -> back to 10 Bit
> > YUV 422 r210 (lossless uncompressed)
>
> I don't know much about r210 but I can assure you it is a
> RGB codec...

My mistake, I meant to write v210 (10 Bit YUV 422 v210) instead of r210 (which for all I know is made up and a typo). FFMpeg handles v210 lossless conversions flawlessly. At least in my past testing, the recent fixes and updates to FFMpeg have made v210 lossless conversions work without glitches. In the past, once in awhile I would get a glitch in a frame. However, I've most recently not had that issue.

However, I am soon to re-run the v210 conversions for verification purposes soon. When I say conversions, I mean 10 Bit from YUV 422 v210 (lossless) -> to FFV (lossless compressed) -> back to YUV 422 v210 (lossless).

Still, it was not possible to use FFMPEG to do the same with r10k (10 Bit RGB 444) such as Blackmagic or AJA codecs.

>
> > #2) 10 Bit RGB 444 r10k Original (lossless uncompressed)
> > -> to FFV (lossless compressed) -> back to 10 Bit
> > RGB 444 r10k (lossless uncompressed).
>
> ... just like r10k, they are technically nearly identical,
>
> As said, I fixed lossless compression with ffv1 for both
> r210 RGB and r10k RGB in January. If it fails for you,
> please provide your command line together with the
> console output here on the mailing list, please do not
> use external resources (except for samples).

Ok, see below:

///////////////////////////////////////////////////////////////////////////////
// FFMpeg r10k (lossless 10bit RGB 444 r10k) to FFV (compressed lossless)
///////////////////////////////////////////////////////////////////////////////

E:\ffmpeg-20141225-git-1515bfb-win64-static>ffmpeg -i "r10kOriginalFile.avi" -pi
x_fmt gbrp10le -vcodec ffv1 -coder 1 -c:a copy r10kToFFV.avi -f framemd5 -an r10
kToFFV.framemd5
ffmpeg version N-68675-g1515bfb Copyright (c) 2000-2014 the FFmpeg developers
built on Dec 24 2014 23:09:08 with gcc 4.9.2 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-av
isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
le-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --
enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-lib
modplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrw
b --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinge
r --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --en
able-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis
--enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-
libx265 --enable-libxavs --enable-libxvid --enable-decklink --enable-zlib
libavutil 54. 15.100 / 54. 15.100
libavcodec 56. 16.100 / 56. 16.100
libavformat 56. 16.101 / 56. 16.101
libavdevice 56. 3.100 / 56. 3.100
libavfilter 5. 5.101 / 5. 5.101
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100
Input #0, avi, from 'r10kOriginalFile.avi':
Duration: 00:12:30.75, start: 0.000000, bitrate: 335621 kb/s
Stream #0:0: Video: r10k (r10k / 0x6B303172), rgb48le(10 bpc), 720x486, 3356
02 kb/s, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
File 'r10kToFFV.avi' already exists. Overwrite ? [y/N] n
Not overwriting - exiting

E:\ffmpeg-20141225-git-1515bfb-win64-static>ffmpeg -i "r10kOriginalFile.avi" -pi
x_fmt gbrp10le -vcodec ffv1 -coder 1 -c:a copy r10kToFFV.avi -f framemd5 -an r10
kToFFV.framemd5
ffmpeg version N-68675-g1515bfb Copyright (c) 2000-2014 the FFmpeg developers
built on Dec 24 2014 23:09:08 with gcc 4.9.2 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-av
isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
le-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --
enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-lib
modplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrw
b --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinge
r --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --en
able-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis
--enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-
libx265 --enable-libxavs --enable-libxvid --enable-decklink --enable-zlib
libavutil 54. 15.100 / 54. 15.100
libavcodec 56. 16.100 / 56. 16.100
libavformat 56. 16.101 / 56. 16.101
libavdevice 56. 3.100 / 56. 3.100
libavfilter 5. 5.101 / 5. 5.101
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100
Input #0, avi, from 'r10kOriginalFile.avi':
Duration: 00:12:30.75, start: 0.000000, bitrate: 335621 kb/s
Stream #0:0: Video: r10k (r10k / 0x6B303172), rgb48le(10 bpc), 720x486, 3356
02 kb/s, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
Output #0, avi, to 'r10kToFFV.avi':
Metadata:
ISFT : Lavf56.16.101
Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), gbrp10le, 720x486, q=2-31, 200
kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
Metadata:
encoder : Lavc56.16.100 ffv1
Output #1, framemd5, to 'r10kToFFV.framemd5':
Metadata:
encoder : Lavf56.16.101
Stream #1:0: Video: rawvideo (RGB0 / 0x30424752), rgb48le(10 bpc), 720x486,
q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
Metadata:
encoder : Lavc56.16.100 rawvideo
Stream mapping:
Stream #0:0 -> #0:0 (r10k (native) -> ffv1 (native))
Stream #0:0 -> #1:0 (r10k (native) -> rawvideo (native))
Press [q] to stop, [?] for help
frame= 7 fps=0.0 q=0.0 q=0.0 size= 5659kB time=00:00:00.23 bitrate=198477.
frame= 16 fps= 15 q=0.0 q=0.0 size= 12930kB time=00:00:00.53 bitrate=198401.
frame= 25 fps= 16 q=0.0 q=0.0 size= 20224kB time=00:00:00.83 bitrate=198609.

< ... data omitted ...>

frame=22469 fps= 13 q=0.0 q=0.0 size=25877166kB time=00:12:29.71 bitrate=282754.
frame=22477 fps= 13 q=0.0 q=0.0 size=25885932kB time=00:12:29.98 bitrate=282750.
frame=22484 fps= 13 q=0.0 q=0.0 size=25893498kB time=00:12:30.21 bitrate=282744.
frame=22491 fps= 13 q=0.0 q=0.0 size=25901574kB time=00:12:30.44 bitrate=282744.
frame=22498 fps= 13 q=0.0 q=0.0 size=25908966kB time=00:12:30.68 bitrate=282737.
frame=22500 fps= 13 q=0.0 Lq=0.0 size=25911354kB time=00:12:30.75 bitrate=282738
.3kbits/s
video:72043001kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB mux
ing overhead: unknown

E:\ffmpeg-20141225-git-1515bfb-win64-static>


///////////////////////////////////////////////////////////////////////////////
// FFMpeg FFV (compressed lossless) back to r10k (lossless 10bit RGB 444 r10k)
// NOTE: the resulting r10k created should be like the original r10k. At least
// that is the goal.
//
// Take notice of the WARNING in the run below:
//
// "Incompatible pixel format 'gbrp10le' for codec 'r10k', auto-selecting format 'rg
// b48le'"
//
// "[swscaler @ 000000000568b8c0] full chroma interpolation for destination format '
// rgb48le' not yet implemented"
///////////////////////////////////////////////////////////////////////////////


E:\ffmpeg-20141225-git-1515bfb-win64-static>ffmpeg -i r10kToFFV.avi -pix_fmt gbr
p10le -vcodec r10k -c:a copy FFVTor10k.avi -f framemd5 -an FFVTor10k.framemd5
ffmpeg version N-68675-g1515bfb Copyright (c) 2000-2014 the FFmpeg developers
built on Dec 24 2014 23:09:08 with gcc 4.9.2 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-av
isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
le-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --
enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-lib
modplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrw
b --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinge
r --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --en
able-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis
--enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-
libx265 --enable-libxavs --enable-libxvid --enable-decklink --enable-zlib
libavutil 54. 15.100 / 54. 15.100
libavcodec 56. 16.100 / 56. 16.100
libavformat 56. 16.101 / 56. 16.101
libavdevice 56. 3.100 / 56. 3.100
libavfilter 5. 5.101 / 5. 5.101
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100
Input #0, avi, from 'r10kToFFV.avi':
Metadata:
encoder : Lavf56.16.101
Duration: 00:12:30.75, start: 0.000000, bitrate: 282738 kb/s
Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), gbrp10le, 720x486, 282746 kb/s
, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
Incompatible pixel format 'gbrp10le' for codec 'r10k', auto-selecting format 'rg
b48le'
[swscaler @ 000000000568b8c0] full chroma interpolation for destination format '
rgb48le' not yet implemented
Output #0, avi, to 'FFVTor10k.avi':
Metadata:
ISFT : Lavf56.16.101
Stream #0:0: Video: r10k (R10k / 0x6B303152), rgb48le, 720x486, q=2-31, 200
kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
Metadata:
encoder : Lavc56.16.100 r10k
Output #1, framemd5, to 'FFVTor10k.framemd5':
Metadata:
encoder : Lavf56.16.101
Stream #1:0: Video: rawvideo (G3[0][10] / 0xA003347), gbrp10le, 720x486, q=2
-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
Metadata:
encoder : Lavc56.16.100 rawvideo
Stream mapping:
Stream #0:0 -> #0:0 (ffv1 (native) -> r10k (native))
Stream #0:0 -> #1:0 (ffv1 (native) -> rawvideo (native))
Press [q] to stop, [?] for help
frame= 9 fps=0.0 q=0.0 q=0.0 size= 12307kB time=00:00:00.30 bitrate=335740.
frame= 24 fps= 23 q=0.0 q=0.0 size= 32811kB time=00:00:00.80 bitrate=335646.
frame= 35 fps= 22 q=0.0 q=0.0 size= 47846kB time=00:00:01.16 bitrate=335628.
frame= 48 fps= 23 q=0.0 q=0.0 size= 65616kB time=00:00:01.60 bitrate=335617.

< ... rest of data omitted ...>

///////////////////////////////////////////////////////////////////////////////
// end
///////////////////////////////////////////////////////////////////////////////

In the conversion from FFV1 back to r10k the following warning is reported:

"Incompatible pixel format 'gbrp10le' for codec 'r10k', auto-selecting format 'rg
b48le'
[swscaler @ 000000000568b8c0] full chroma interpolation for destination format '
rgb48le' not yet implemented"

Take note that ffmpeg -pix_fmts reports:
IO... gbrp10be 3 30
IO... gbrp10le 3 30

So I would imagine that I should be able to output back to 10 bit r10k. This doesn't seem to work.

I'd also like to point out that the resulting file that is created from my original r10k to FFV1 which resulted in the file r10kToFFV.avi that was created DOES NOT PLAY IN VLC! So what do I see when playing the r10kToFFV.avi? Video does play but it's all green (i.e. all frames as the video plays is all green). So the video plays, but there is nothing but SOLID green to watch. This is just to say that going from my original r10k to FFV1 also has issues with FFMpeg.

>
> > By then I was using Zeranoe FFmpeg already as I
> > gave up using VideoLan's.
>
> There is some misunderstanding:
> FFmpeg only provides source code (no "products"),
> videolan is kindly supporting FFmpeg with their
> server, meaning FFmpeg is available through the
> videolan git repository (there are mirrors but
> videolan is our official git archive).
> Zeranoe takes the FFmpeg sources from videolan
> and compiles them for the community.

I may be confusing the testing with their x264 product:

http://www.videolan.org/developers/x264.html

I've attempted to compress v210 using x264 as an alternative to FFMpeg. However, that's another story. FFMpeg handles v210 fine, so I'm focused currently on r10k lossless compression which is what FFMpeg doesn't seem to like (the 10bit format).

>
> > Thanks! And since today's Christmas, Merry
> > Christmas to all!
>
> Merry Christmas to you too!
>
> Carl Eugen
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Carl Eugen Hoyos]

Jason Freets <jasonslife <at> hotmail.com> writes:

> Still, it was not possible to use FFMPEG to do the
> same with r10k (10 Bit RGB 444) such as Blackmagic
> or AJA codecs.

I tested the following:

$ ffmpeg -f lavfi -i testsrc -t 10 -vcodec r210 out.avi
$ ffmpeg -i out.avi -vcodec ffv1 -pix_fmt gbrp10 -coder 1 out2.avi
$ ffmpeg -i out2.avi -vcodec r210 out3.avi

out.avi and out3.avi are identical.

Please provide the input sample for which the conversion(s)
are not lossless.

Thank you, Carl Eugen

[Jason Freets]

> Jason Freets <jasonslife <at> hotmail.com> writes:
>
> > Still, it was not possible to use FFMPEG to do the
> > same with r10k (10 Bit RGB 444) such as Blackmagic
> > or AJA codecs.
>
> I tested the following:
>
> $ ffmpeg -f lavfi -i testsrc -t 10 -vcodec r210 out.avi
> $ ffmpeg -i out.avi -vcodec ffv1 -pix_fmt gbrp10 -coder 1 out2.avi
> $ ffmpeg -i out2.avi -vcodec r210 out3.avi
>
> out.avi and out3.avi are identical.
>
> Please provide the input sample for which the conversion(s)
> are not lossless.

Here above, you are testing for r210 (FourCC: r210) :
http://wiki.multimedia.cx/?title=R210

Yet, I said FFMpeg does handle v210 (FourCC: v210) just fine:
http://wiki.multimedia.cx/?title=v210

I never mentioned r210. So, not sure why r210 in in our discussions.

We are talking about two seperate things. I'm instead talking about r10k which is (R10k, R10g):
http://wiki.multimedia.cx/?title=R10k

Based on your most recent testing, FFMpeg seems to handle r210 fine. From my testing, FFMpeg handles v210 fine too. My intention is not to discuss r210 or v210. However, what FFMpeg does not handle, is r10k. It is r10k that FFMpeg has issues with (not r210 or v210). You should re-read my last test runs in my prior email.

So the commands I used in my last email post was:

//10 Bit RGB 444 r10k lossless original -> to FFV1 (lossless compressed)
ffmpeg -i "r10kOriginalFile.avi" -pix_fmt gbrp10le -vcodec ffv1 -coder 1 -c:a copy r10kToFFV.avi -f framemd5 -an r10kToFFV.framemd5

//FFV1 (lossless compressed) -> 10 Bit RGB 444 r10k lossless original
ffmpeg -i r10kToFFV.avi -pix_fmt gbrp10le -vcodec r10k -c:a copy FFVTor10k.avi -f framemd5 -an FFVTor10k.framemd5

So again, here my goal with FFMpeg is:
10 Bit RGB 444 r10k lossless original -> FFV1 (lossless compressed) -> 10 Bit RGB 444 r10k lossless original

However, I've not been able to get FFMpeg to lossless compress and decompress r10k. This is the problem I am having.

Hopefully that helps clarify,

Cheers,

Jason =)

>
> Thank you, Carl Eugen
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Carl Eugen Hoyos]

Jason Freets <jasonslife <at> hotmail.com> writes:

> However, I've not been able to get FFMpeg to
> lossless compress and decompress r10k. This is
> the problem I am having.

There is (nearly) no difference between r10k and r210.
Please provide your input sample.
(I just sent a patch to make the output file more similar
but the difference does not affect the actual frames.)

Carl Eugen

[Jason Freets]

> Jason Freets <jasonslife <at> hotmail.com> writes:
>
> > However, I've not been able to get FFMpeg to
> > lossless compress and decompress r10k. This is
> > the problem I am having.
>
> There is (nearly) no difference between r10k and r210.
> Please provide your input sample.
> (I just sent a patch to make the output file more similar
> but the difference does not affect the actual frames.)

Please forgive me Carl ...

r210's format: XXrrrrrr rrrrgggg ggggggbb bbbbbbbb
r10k's format: rrrrrrrr rrgggggg ggggbbbb bbbbbbxx

I keep thinking of 210 as being YUV, and wasn't paying attention to the format layout despite even sending you the link's to the codec's....ha! My fault!

You are right, after reading your email, I just realized that r210 and r10k are quite similar indeed.

The sample I am using is 30 gigs. I'd have to re-create one that is much smaller. Do you have a desired file size in mind? Unless you happen to have a r10k sample, which seems like you don't.

If I did have a file, how would I sent it to you? Attach a file via email? Dropbox? Or? Again, desired file size?

Wow, really excited though!

Cheers,

Jason

>
> Carl Eugen
>
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Peter B.]

On 12/27/2014 04:02 AM, Jason Freets wrote:
> The sample I am using is 30 gigs. I'd have to re-create one that is
> much smaller.

If I understood the use case correctly, it might be sufficient if you
create a very short excerpt of your 30GB file like this:

$ ffmpeg -i {HUGE_FILE} -c copy -s {START_OFFSET} -t {DURATION}
{OUTPUT_FILE}

With "-s" you can define a start offset (in seconds), and with "-t" a
duration of the snippet (also in seconds)


For example:

$ ffmpeg -i input.avi -c copy -s 10 -t 5 output.avi


That would create a 5 second snippet, starting at offset 10s.


If the conversion issue can be reproduced with a snippet of a few
frames, you could try to set the duration to e.g. 1 second, therefore
reducing the filesize to be as small as possible.


Regards,
Pb

[Marcus Johnson]

@Carl

​How often does VLC update their ffmpeg to the standard master branch you
guys host?​

[Carl Eugen Hoyos]

Marcus Johnson <bumblebritches57 <at> gmail.com> writes:

> ​How often does VLC update their ffmpeg to the
> standard master branch you guys host?​

Sorry if I was unclear the other day:
The "master branch" of FFmpeg (to use your wording)
is hosted by videolan; it is not hosted by us, the
FFmpeg developers.
(videolan == vlc)

Carl Eugen

[Marcus Johnson]

​I see, thanks.​

[Carl Eugen Hoyos]

Peter B. <pb <at> das-werkstatt.com> writes:

> $ ffmpeg -i input.avi -c copy -s 10 -t 5 output.avi

I wanted to suggest -vframes 3 which would produce a
significantly smaller output file.

Note that you can cut avi with dd (if you don't trust
FFmpeg which makes sense if you want to test losslessness.)

But please note that the reason why r210 -> ffv1 -> r210
was not lossless in the past was a bug (or missing feature)
in the software scaler. This issue was fixed a year ago and
it has also fixed the issue with r10k.
The difference with r10k is that it is more difficult to
show that the conversion is lossless, instead of:

> r10k's format: rrrrrrrr rrgggggg ggggbbbb bbbbbbxx

FFmpeg writes:
r10k's format: rrrrrrrr rrgggggg ggggbbbb bbbbbbbb
(blue is 12 instead of 10 bits.)
The conversion is still lossless but the most significant
blue bits will be repeated as an eleventh and 12th bit
making the files not bit-identical (while the saved frames
are bit-identical) assuming xx are 0 (if they aren't 0 you
will never get identical output files).

Two patches are currently discussed to fix this issue in
the encoder (which does not affect that the output is
lossless but does affect the easiness of testing) but
you can probably test by either doing:
r10k -> ffv1 -> r10k -> ffv1 ->r10k
and comparing the two ffv1 and the last two r10k files.
You could also reencode to r210 and compare.
And you can of course use -pix_fmt gbrp10 -f framecrc to
get identical output (but this means you trust my fix for
the gbrp10 conversion).

Carl Eugen

[Jason Freets]

I'm not sure where to put the file. So, I just uploaded it to DropBox for now. Here's a link to the file:

https://www.dropbox.com/s/6ugnjlivdhdlixt/10BitRGB444_r10k_2sec.avi?dl=0

It's just a 2 second 10 Bit RGB 444 r10K file I already had sitting around. It's about 80 MB.

If you want, I could create a longer and different file too. Just let me know.

You said, "you can probably test by either doing"...does this mean you've applied the patch to the GIT repository of FFMpeg and I could actually test files? Or?

If so, I could pull it from GIT and run the compare pattern as you suggested (I have a lot of large files):

r10k -> ffv1 -> r10k -> ffv1 ->r10k

Please let me know. Either way, you have a 2 second file to play with for now. If you need additional test files, please let me know and a place to upload them if DropBox is not suitable for you. =)

Cheers,

Jason

> Subject: Re: [FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) Compression
>
> Peter B. <pb <at> das-werkstatt.com> writes:
>
> > $ ffmpeg -i input.avi -c copy -s 10 -t 5 output.avi
>
> I wanted to suggest -vframes 3 which would produce a
> significantly smaller output file.
>
> Note that you can cut avi with dd (if you don't trust
> FFmpeg which makes sense if you want to test losslessness.)
>
> But please note that the reason why r210 -> ffv1 -> r210
> was not lossless in the past was a bug (or missing feature)
> in the software scaler. This issue was fixed a year ago and
> it has also fixed the issue with r10k.
> The difference with r10k is that it is more difficult to
> show that the conversion is lossless, instead of:
>
> > r10k's format: rrrrrrrr rrgggggg ggggbbbb bbbbbbxx
>
> FFmpeg writes:
> r10k's format: rrrrrrrr rrgggggg ggggbbbb bbbbbbbb
> (blue is 12 instead of 10 bits.)
> The conversion is still lossless but the most significant
> blue bits will be repeated as an eleventh and 12th bit
> making the files not bit-identical (while the saved frames
> are bit-identical) assuming xx are 0 (if they aren't 0 you
> will never get identical output files).
>
> Two patches are currently discussed to fix this issue in
> the encoder (which does not affect that the output is
> lossless but does affect the easiness of testing) but
> you can probably test by either doing:
> r10k -> ffv1 -> r10k -> ffv1 ->r10k
> and comparing the two ffv1 and the last two r10k files.
> You could also reencode to r210 and compare.
> And you can of course use -pix_fmt gbrp10 -f framecrc to
> get identical output (but this means you trust my fix for
> the gbrp10 conversion).
>
> Carl Eugen
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Carl Eugen Hoyos]

Jason Freets <jasonslife <at> hotmail.com> writes:

> https://www.dropbox.com/s/6ugnjlivdhdlixt/10BitRGB444_r10k_2sec.avi

Thank you for the sample!

I found a second bug in the r10k code, this time the
decoder. I'll send a patch soon that allows to use
-f framecrc (or similar) on the input r10k and the
output r10k file and both show identical output.

Note that both patches do not affect the ffv1 files,
so you can use current FFmpeg to produce lossless
archive copies of r10k.

Thank you for being persistent, Carl Eugen

[Jason Freets]

> Subject: Re: [FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) Compression
>
> Jason Freets <jasonslife <at> hotmail.com> writes:
>
> > https://www.dropbox.com/s/6ugnjlivdhdlixt/10BitRGB444_r10k_2sec.avi
>
> Thank you for the sample!

No problem! =)

>
> I found a second bug in the r10k code, this time the
> decoder. I'll send a patch soon that allows to use
> -f framecrc (or similar) on the input r10k and the
> output r10k file and both show identical output.

That would be wonderful! I like the framecrc since it's quite convenient to also verify which frames are bad between the input and output. So if you are able to make that work, fantastic!

>
> Note that both patches do not affect the ffv1 files,
> so you can use current FFmpeg to produce lossless
> archive copies of r10k.

That's a good note!

However, I'd like to point out that I never had success even converting from r10k to FFV1. What I mean by this, is that after converting my original r10k to FFV1 I was never able to play the FFV1 file with, for example, VLC. If you read back to my prior posts, I was reporting that I only saw GREEN video (i.e. each frame was solid GREEN). My conclusion at the time, just a day or two, was FFMpeg just didn't deal with r10k. Yet, I realize you've made improvements since too. I have yet to try those. I will wait until you give the thumbs up! =)

>
> Thank you for being persistent, Carl Eugen
>

No no...thank you Carl! I'm glad I can do what I can to help with testing!

Cheers,

Jason

> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Carl Eugen Hoyos]

Jason Freets <jasonslife <at> hotmail.com> writes:

> I'd like to point out that I never had success
> even converting from r10k to FFV1.

Works fine here.

> What I mean by this, is that after converting my
> original r10k to FFV1 I was never able to play
> the FFV1 file with, for example, VLC.

Apart from "wrong mailing list":
Didn't you test FFplay? Or MPlayer?
Or ffmpeg -i outffv1.avi out.mov?

> My conclusion at the time, just a day or two,
> was FFMpeg just didn't deal with r10k.

This makes no sense, sorry.

> Yet, I realize you've made improvements since too.

As said, the only difference the two changes will
make is that they allow to prove the losslessness
with -f framecrc (and similar). They do not change
the archive copies you could have made before.
(But I admit it was difficult to test if the archive
copies are really lossless, this is what I usually
request from the so-called "professional" archive
solutions that apparently are never lossless but
nobody requested this so far. In any case, the
fixes were trivial.)

Carl Eugen

[Jason Freets]

> Subject: Re: [FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) Compression
>
> Jason Freets <jasonslife <at> hotmail.com> writes:
>
> > I'd like to point out that I never had success
> > even converting from r10k to FFV1.
>
> Works fine here.
>
> > What I mean by this, is that after converting my
> > original r10k to FFV1 I was never able to play
> > the FFV1 file with, for example, VLC.
>
> Apart from "wrong mailing list":
> Didn't you test FFplay? Or MPlayer?
> Or ffmpeg -i outffv1.avi out.mov?

Here's the result of what I see when playing the 10BitRGB444_r10k_2sec.avi I sent you:

https://www.dropbox.com/s/l3512t3qarkdt2i/FFPlay_Playing10BitRGB444_r10k.png?dl=0

///////////////////////////////////////////////////////////////////////////////
// FFPlay not playing r10k for me (at least on my system)
//
// Command Issued: ffplay 10BitRGB444_r10k_2sec.avi
///////////////////////////////////////////////////////////////////////////////

E:\ffmpeg-20141225-git-1515bfb-win64-static>ffplay 10BitRGB444_r10k_2sec.avi
ffplay version N-68675-g1515bfb Copyright (c) 2003-2014 the FFmpeg developers
built on Dec 24 2014 23:09:08 with gcc 4.9.2 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-av
isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
le-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --
enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-lib
modplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrw
b --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinge
r --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --en
able-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis
--enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-
libx265 --enable-libxavs --enable-libxvid --enable-decklink --enable-zlib
libavutil 54. 15.100 / 54. 15.100
libavcodec 56. 16.100 / 56. 16.100
libavformat 56. 16.101 / 56. 16.101
libavdevice 56. 3.100 / 56. 3.100
libavfilter 5. 5.101 / 5. 5.101
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100
Input #0, avi, from '10BitRGB444_r10k_2sec.avi':B sq= 0B f=0/0
Duration: 00:00:02.00, start: 0.000000, bitrate: 335755 kb/s
Stream #0:0: Video: r10k (r10k / 0x6B303172), rgb48le(10 bpc), 720x486, 3412
75 kb/s, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
14.18 M-V: 0.000 fd= 0 aq= 0KB vq= 0KB sq= 0B f=0/0
E:\ffmpeg-20141225-git-1515bfb-win64-static>

///////////////////////////////////////////////////////////////////////////////
// end
///////////////////////////////////////////////////////////////////////////////

So, no, unfortunately it hasn't worked for me using FFPlay. Unless, I am doing something wrong. The input stream is detected at r10k, so not sure why it doesn't view properly. Other non r10k videos do play fine with FFPlay.

Second, VLC also does not support playing r10k. The result of playing the test file I provided you results in the following VLC error message:

"VLC does not support the audio or video format "r10k". Unfortunately there is no way for you to fix this." So, although VLC is built upon FFMpeg, it doesn't play r10k either.

No, I have not tried MPlayer.

>
> > My conclusion at the time, just a day or two,
> > was FFMpeg just didn't deal with r10k.
>
> This makes no sense, sorry.

Hopefully it does now.

>
> > Yet, I realize you've made improvements since too.
>
> As said, the only difference the two changes will
> make is that they allow to prove the losslessness
> with -f framecrc (and similar). They do not change
> the archive copies you could have made before.
> (But I admit it was difficult to test if the archive
> copies are really lossless, this is what I usually
> request from the so-called "professional" archive
> solutions that apparently are never lossless but
> nobody requested this so far. In any case, the
> fixes were trivial.)

Exactly: "But I admit it was difficult to test if the archive copies are really lossless" ... yes, difficult to test. I've used FFMpeg for dealing with v210, but have not used FFMpeg for r10k because it just hasn't worked for me.

But again, perhaps I am doing something wrong.

Jason

>
> Carl Eugen
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Jason Freets]

I've uploaded the r10k to FFV1 file for you :

https://www.dropbox.com/s/uperxd1k60uhj5k/r10kToFFV.avi?dl=0

Below is what I used to create it:

///////////////////////////////////////////////////////////////////////////////
// r10k -> FFV1
///////////////////////////////////////////////////////////////////////////////

E:\ffmpeg-20141225-git-1515bfb-win64-static>ffmpeg -i "10BitRGB444_r10k_2sec.avi
" -pix_fmt gbrp10le -vcodec ffv1 -coder 1 -c:a copy r10kToFFV.avi -f framemd5 -a
n r10kToFFV.framemd5
ffmpeg version N-68675-g1515bfb Copyright (c) 2000-2014 the FFmpeg developers
built on Dec 24 2014 23:09:08 with gcc 4.9.2 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-av
isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
le-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --
enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-lib
modplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrw
b --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinge
r --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --en
able-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis
--enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-
libx265 --enable-libxavs --enable-libxvid --enable-decklink --enable-zlib
libavutil 54. 15.100 / 54. 15.100
libavcodec 56. 16.100 / 56. 16.100
libavformat 56. 16.101 / 56. 16.101
libavdevice 56. 3.100 / 56. 3.100
libavfilter 5. 5.101 / 5. 5.101
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100
Input #0, avi, from '10BitRGB444_r10k_2sec.avi':
Duration: 00:00:02.00, start: 0.000000, bitrate: 335755 kb/s
Stream #0:0: Video: r10k (r10k / 0x6B303172), rgb48le(10 bpc), 720x486, 3412
75 kb/s, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
Output #0, avi, to 'r10kToFFV.avi':
Metadata:
ISFT : Lavf56.16.101
Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), gbrp10le, 720x486, q=2-31, 200
kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
Metadata:
encoder : Lavc56.16.100 ffv1
Output #1, framemd5, to 'r10kToFFV.framemd5':
Metadata:
encoder : Lavf56.16.101
Stream #1:0: Video: rawvideo (RGB0 / 0x30424752), rgb48le(10 bpc), 720x486,
q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
Metadata:
encoder : Lavc56.16.100 rawvideo
Stream mapping:
Stream #0:0 -> #0:0 (r10k (native) -> ffv1 (native))
Stream #0:0 -> #1:0 (r10k (native) -> rawvideo (native))
Press [q] to stop, [?] for help
frame= 9 fps=0.0 q=0.0 q=0.0 size= 7404kB time=00:00:00.30 bitrate=201975.
frame= 18 fps= 17 q=0.0 q=0.0 size= 14777kB time=00:00:00.60 bitrate=201557.
frame= 27 fps= 17 q=0.0 q=0.0 size= 22150kB time=00:00:00.90 bitrate=201414.
frame= 36 fps= 17 q=0.0 q=0.0 size= 29514kB time=00:00:01.20 bitrate=201279.
frame= 45 fps= 17 q=0.0 q=0.0 size= 36880kB time=00:00:01.50 bitrate=201213.
frame= 54 fps= 17 q=0.0 q=0.0 size= 44241kB time=00:00:01.80 bitrate=201145.
frame= 60 fps= 16 q=0.0 Lq=0.0 size= 49151kB time=00:00:02.00 bitrate=201119
.9kbits/s
video:172162kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxin
g overhead: unknown

E:\ffmpeg-20141225-git-1515bfb-win64-static>

///////////////////////////////////////////////////////////////////////////////
// r10k -> FFV1
///////////////////////////////////////////////////////////////////////////////

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'd like to point out that I never had success
> > > even converting from r10k to FFV1.
> >
> > Works fine here.
> >
> > > What I mean by this, is that after converting my
> > > original r10k to FFV1 I was never able to play
> > > the FFV1 file with, for example, VLC.
> >
> > Apart from "wrong mailing list":
> > Didn't you test FFplay? Or MPlayer?
> > Or ffmpeg -i outffv1.avi out.mov?
>
> Here's the result of what I see when playing the 10BitRGB444_r10k_2sec.avi I sent you:
>
> https://www.dropbox.com/s/l3512t3qarkdt2i/FFPlay_Playing10BitRGB444_r10k.png?dl=0
>
> ///////////////////////////////////////////////////////////////////////////////
> // FFPlay not playing r10k for me (at least on my system)
> //
> // Command Issued: ffplay 10BitRGB444_r10k_2sec.avi
> ///////////////////////////////////////////////////////////////////////////////
>
> E:\ffmpeg-20141225-git-1515bfb-win64-static>ffplay 10BitRGB444_r10k_2sec.avi
> ffplay version N-68675-g1515bfb Copyright (c) 2003-2014 the FFmpeg developers
> built on Dec 24 2014 23:09:08 with gcc 4.9.2 (GCC)
> configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-av
> isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
> le-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --
> enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-lib
> modplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrw
> b --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinge
> r --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --en
> able-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis
> --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-
> libx265 --enable-libxavs --enable-libxvid --enable-decklink --enable-zlib
> libavutil 54. 15.100 / 54. 15.100
> libavcodec 56. 16.100 / 56. 16.100
> libavformat 56. 16.101 / 56. 16.101
> libavdevice 56. 3.100 / 56. 3.100
> libavfilter 5. 5.101 / 5. 5.101
> libswscale 3. 1.101 / 3. 1.101
> libswresample 1. 1.100 / 1. 1.100
> libpostproc 53. 3.100 / 53. 3.100
> Input #0, avi, from '10BitRGB444_r10k_2sec.avi':B sq= 0B f=0/0
> Duration: 00:00:02.00, start: 0.000000, bitrate: 335755 kb/s
> Stream #0:0: Video: r10k (r10k / 0x6B303172), rgb48le(10 bpc), 720x486, 3412
> 75 kb/s, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
> 14.18 M-V: 0.000 fd= 0 aq= 0KB vq= 0KB sq= 0B f=0/0
> E:\ffmpeg-20141225-git-1515bfb-win64-static>
>
> ///////////////////////////////////////////////////////////////////////////////
> // end
> ///////////////////////////////////////////////////////////////////////////////
>
> So, no, unfortunately it hasn't worked for me using FFPlay. Unless, I am doing something wrong. The input stream is detected at r10k, so not sure why it doesn't view properly. Other non r10k videos do play fine with FFPlay.
>
> Second, VLC also does not support playing r10k. The result of playing the test file I provided you results in the following VLC error message:
>
> "VLC does not support the audio or video format "r10k". Unfortunately there is no way for you to fix this." So, although VLC is built upon FFMpeg, it doesn't play r10k either.
>
> No, I have not tried MPlayer.
>
> >
> > > My conclusion at the time, just a day or two,
> > > was FFMpeg just didn't deal with r10k.
> >
> > This makes no sense, sorry.
>
> Hopefully it does now.
>
> >
> > > Yet, I realize you've made improvements since too.
> >
> > As said, the only difference the two changes will
> > make is that they allow to prove the losslessness
> > with -f framecrc (and similar). They do not change
> > the archive copies you could have made before.
> > (But I admit it was difficult to test if the archive
> > copies are really lossless, this is what I usually
> > request from the so-called "professional" archive
> > solutions that apparently are never lossless but
> > nobody requested this so far. In any case, the
> > fixes were trivial.)
>
> Exactly: "But I admit it was difficult to test if the archive copies are really lossless" ... yes, difficult to test. I've used FFMpeg for dealing with v210, but have not used FFMpeg for r10k because it just hasn't worked for me.
>
> But again, perhaps I am doing something wrong.
>
> Jason
>
> >
> > Carl Eugen
> >
> > _______________________________________________
> > ffmpeg-user mailing list
> > ffmpeg-***@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Carl Eugen Hoyos]

Jason Freets <jasonslife <at> hotmail.com> writes:

> I've uploaded the r10k to FFV1 file for you :
>
> https://www.dropbox.com/s/uperxd1k60uhj5k/r10kToFFV.avi?dl=0

This is a lossless copy of 10BitRGB444_r10k_2sec.avi
For playback with FFplay, you need fast hardware
(ffv1 is an archive codec, it is not optimised for
playback).
But FFplay is not the best testing application,
better use the following to test if an input file
is supported by FFmpeg:
$ ffmpeg -i input -vcodec mpeg4 -qscale 2 out.avi

Carl Eugen

[Jason Freets]

Attached is the resulting r10k to Mpeg4:

https://www.dropbox.com/s/0mdixsp5htqm2f1/r10kToMpeg4.avi?dl=0

I get the same funny colors similar to "FFPlay_Playing10BitRGB444_r10k.png" that I put up earlier on DropBox as well.

The system I am running tests on is one of the latest i7 processors running Windows 7. Otherwise, yes on slow systems, playing an FFV1 can lead to glitchy frames. Agreed.

Below is the command used to create it:

///////////////////////////////////////////////////////////////////////////////
// r10k -> Mpeg4 (FMP4)
// Input: 10BitRGB444_r10k_2sec.avi
// Output: r10kToMpeg4.avi
///////////////////////////////////////////////////////////////////////////////

E:\ffmpeg-20141225-git-1515bfb-win64-static>ffmpeg -i "10BitRGB444_r10k_2sec.avi
" -vcodec mpeg4 -qscale:v 2 r10kToMpeg4.avi
ffmpeg version N-68675-g1515bfb Copyright (c) 2000-2014 the FFmpeg developers
built on Dec 24 2014 23:09:08 with gcc 4.9.2 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-av
isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
le-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --
enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-lib
modplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrw
b --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinge
r --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --en
able-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis
--enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-
libx265 --enable-libxavs --enable-libxvid --enable-decklink --enable-zlib
libavutil 54. 15.100 / 54. 15.100
libavcodec 56. 16.100 / 56. 16.100
libavformat 56. 16.101 / 56. 16.101
libavdevice 56. 3.100 / 56. 3.100
libavfilter 5. 5.101 / 5. 5.101
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100
Input #0, avi, from '10BitRGB444_r10k_2sec.avi':
Duration: 00:00:02.00, start: 0.000000, bitrate: 335755 kb/s
Stream #0:0: Video: r10k (r10k / 0x6B303172), rgb48le(10 bpc), 720x486, 3412
75 kb/s, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
Output #0, avi, to 'r10kToMpeg4.avi':
Metadata:
ISFT : Lavf56.16.101
Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 720x486, q=2-31, 200
kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
Metadata:
encoder : Lavc56.16.100 mpeg4
Stream mapping:
Stream #0:0 -> #0:0 (r10k (native) -> mpeg4 (native))
Press [q] to stop, [?] for help
frame= 60 fps=0.0 q=2.0 Lsize= 17850kB time=00:00:02.00 bitrate=73038.9kbits
/s
video:17843kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing
overhead: 0.039150%

E:\ffmpeg-20141225-git-1515bfb-win64-static>

///////////////////////////////////////////////////////////////////////////////
// end
///////////////////////////////////////////////////////////////////////////////


> To: ffmpeg-***@ffmpeg.org
> From: ***@ag.or.at
> Date: Sun, 28 Dec 2014 01:21:13 +0000
> Subject: Re: [FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) Compression
>
> Jason Freets <jasonslife <at> hotmail.com> writes:
>
> > I've uploaded the r10k to FFV1 file for you :
> >
> > https://www.dropbox.com/s/uperxd1k60uhj5k/r10kToFFV.avi?dl=0
>
> This is a lossless copy of 10BitRGB444_r10k_2sec.avi
> For playback with FFplay, you need fast hardware
> (ffv1 is an archive codec, it is not optimised for
> playback).
> But FFplay is not the best testing application,
> better use the following to test if an input file
> is supported by FFmpeg:
> $ ffmpeg -i input -vcodec mpeg4 -qscale 2 out.avi
>
> Carl Eugen
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Carl Eugen Hoyos]

Jason Freets <jasonslife <at> hotmail.com> writes:

> I've used FFMpeg for dealing with v210, but have
> not used FFMpeg for r10k because it just hasn't
> worked for me.

r10k is supported by FFmpeg since September 2010.
The lossless copies with ffv1 are possible since
January 2014, testing the lossless ffv1 copies
will be (more easily) possible next week.

Carl Eugen

[Jason Freets]

> Subject: Re: [FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) Compression
>
> Jason Freets <jasonslife <at> hotmail.com> writes:
>
> > I've used FFMpeg for dealing with v210, but have
> > not used FFMpeg for r10k because it just hasn't
> > worked for me.
>
> r10k is supported by FFmpeg since September 2010.
> The lossless copies with ffv1 are possible since
> January 2014, testing the lossless ffv1 copies
> will be (more easily) possible next week.

No problem. I'm sure we'll come to an understanding as to why these lossless r10k to FFV1 copies seem to play on your system but not on mine. Strange. I'll continue to play with it meantime. =)

Cheers,

Jason

>
> Carl Eugen
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Carl Eugen Hoyos]

Jason Freets <jasonslife <at> hotmail.com> writes:

> Here's the result of what I see when playing the
> 10BitRGB444_r10k_2sec.avi I sent you:
>
> https://www.dropbox.com/s/l3512t3qarkdt2i/FFPlay_Playing10BitRGB444_r10k.png

If you don't like this output, please either
choose an input file that everybody can
recognize or provide the intended output.

(Nobody has reported in four years that
something is wrong when decoding r10k.)

I assumed it is correct.

Carl Eugen

[Jason Freets]

> Subject: Re: [FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) Compression
>
> Jason Freets <jasonslife <at> hotmail.com> writes:
>
> > Here's the result of what I see when playing the
> > 10BitRGB444_r10k_2sec.avi I sent you:
> >
> > https://www.dropbox.com/s/l3512t3qarkdt2i/FFPlay_Playing10BitRGB444_r10k.png
>
> If you don't like this output, please either
> choose an input file that everybody can
> recognize or provide the intended output.

Agreed, it does help if I provide a frame of reference...so very good point. The 2 second video is NTSC color bars. I figured one would be cognitive of what that may look like ;). If you were able to play the 2 second r10k file correctly, you would have noticed they are NTSC color bars. If not, then yes, you'd have no idea if what you are viewing is playing correctly or not. So a frame of reference helps in our case.

Here's a video of the "10BitRGB444_r10k_2sec.avi" file converted to a MP4 that plays correctly:

https://www.dropbox.com/s/tt1x5ntx4ahll12/10BitRGB444_r10k_to_MP4.avi?dl=0

And, here's a reference screen shot of what I see when I play it through VLC:

https://www.dropbox.com/s/lizv2oedaptj9ik/10BitRGB444_r10k_to_MP4.png?dl=0

Also, I went ahead and GIT'ed the FFMpeg repository and built in under Linux. I then re-ran the conversions that I was doing under Windows. I get the same results as shown in "FFPlay_Playing10BitRGB444_r10k.png" which I uploaded earlier (i.e that's what I see when playing the Linux converted file too: no different outcome).

So either on Linux or Windows, I still don't get a correct conversion that views correctly. So, I suppose that remains to be the mystery.

I'll try to pull from some real video (non NTSC color bars) I have and provide a sample of that too later.

Cheers,

Jason

>
> (Nobody has reported in four years that
> something is wrong when decoding r10k.)
>
> I assumed it is correct.
>
> Carl Eugen
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Jason Freets]

As promised, I said I would provide some "real video". So I've uploaded a 5 second 10 Bit RGB 444 r10k sample:

https://www.dropbox.com/s/exio9nmoxnbcyu6/10BitRGB444_r10k_5sec.avi?dl=0

I think it'll be clear when you play that if your video looks correct or not.

Thanks! =)

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:
> >
> > > Here's the result of what I see when playing the
> > > 10BitRGB444_r10k_2sec.avi I sent you:
> > >
> > > https://www.dropbox.com/s/l3512t3qarkdt2i/FFPlay_Playing10BitRGB444_r10k.png
> >
> > If you don't like this output, please either
> > choose an input file that everybody can
> > recognize or provide the intended output.
>
> Agreed, it does help if I provide a frame of reference...so very good point. The 2 second video is NTSC color bars. I figured one would be cognitive of what that may look like ;). If you were able to play the 2 second r10k file correctly, you would have noticed they are NTSC color bars. If not, then yes, you'd have no idea if what you are viewing is playing correctly or not. So a frame of reference helps in our case.
>
> Here's a video of the "10BitRGB444_r10k_2sec.avi" file converted to a MP4 that plays correctly:
>
> https://www.dropbox.com/s/tt1x5ntx4ahll12/10BitRGB444_r10k_to_MP4.avi?dl=0
>
> And, here's a reference screen shot of what I see when I play it through VLC:
>
> https://www.dropbox.com/s/lizv2oedaptj9ik/10BitRGB444_r10k_to_MP4.png?dl=0
>
> Also, I went ahead and GIT'ed the FFMpeg repository and built in under Linux. I then re-ran the conversions that I was doing under Windows. I get the same results as shown in "FFPlay_Playing10BitRGB444_r10k.png" which I uploaded earlier (i.e that's what I see when playing the Linux converted file too: no different outcome).
>
> So either on Linux or Windows, I still don't get a correct conversion that views correctly. So, I suppose that remains to be the mystery.
>
> I'll try to pull from some real video (non NTSC color bars) I have and provide a sample of that too later.
>
> Cheers,
>
> Jason
>
> >
> > (Nobody has reported in four years that
> > something is wrong when decoding r10k.)
> >
> > I assumed it is correct.
> >
> > Carl Eugen
> >
> > _______________________________________________
> > ffmpeg-user mailing list
> > ffmpeg-***@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Jason Freets]

I converted the 5sec r10k video to an Mp4 file, and then dropped it up on DropBox for you Carl:

https://www.dropbox.com/s/f0bhq9rw6cofpzf/10BitRGB444_r10k_5sec_to_MP4.avi?dl=0

Playing through FFPlay I actually see:

https://www.dropbox.com/s/ui3ix2immvmqzza/10BitRGB444_r10k_5sec.png?dl=0

It is the same even when viewing the Mp4 file. They both look the same (FFplay, VLC, ...etc).

Cheers,

Jason

///////////////////////////////////////////////////////////////////////////////
// r10k -> Mpeg4
// Input: 10BitRGB444_r10k_5sec.avi
// Output: 10BitRGB444_r10k_5sec_to_MP4.avi
// Result: Incorrect video playback
///////////////////////////////////////////////////////////////////////////////

E:\ffmpeg-20141225-git-1515bfb-win64-static>ffmpeg -i "10BitRGB444_r10k_5sec.avi
" -vcodec mpeg4 -qscale:v 2 10BitRGB444_r10k_5sec_to_MP4.avi
ffmpeg version N-68675-g1515bfb Copyright (c) 2000-2014 the FFmpeg developers
built on Dec 24 2014 23:09:08 with gcc 4.9.2 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-av
isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
le-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --
enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-lib
modplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrw
b --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinge
r --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --en
able-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis
--enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-
libx265 --enable-libxavs --enable-libxvid --enable-decklink --enable-zlib
libavutil 54. 15.100 / 54. 15.100
libavcodec 56. 16.100 / 56. 16.100
libavformat 56. 16.101 / 56. 16.101
libavdevice 56. 3.100 / 56. 3.100
libavfilter 5. 5.101 / 5. 5.101
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100
Input #0, avi, from '10BitRGB444_r10k_5sec.avi':
Metadata:
encoder : Lavf56.16.101
Duration: 00:00:05.01, start: 0.000000, bitrate: 335602 kb/s
Stream #0:0: Video: r10k (r10k / 0x6B303172), rgb48le(10 bpc), 720x486, 3378
39 kb/s, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
Output #0, avi, to '10BitRGB444_r10k_5sec_to_MP4.avi':
Metadata:
ISFT : Lavf56.16.101
Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 720x486, q=2-31, 200
kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
Metadata:
encoder : Lavc56.16.100 mpeg4
Stream mapping:
Stream #0:0 -> #0:0 (r10k (native) -> mpeg4 (native))
Press [q] to stop, [?] for help
frame= 47 fps=0.0 q=2.0 size= 22200kB time=00:00:01.56 bitrate=115967.4kbits
frame= 105 fps=105 q=2.0 size= 49690kB time=00:00:03.50 bitrate=116186.0kbits
frame= 150 fps=108 q=2.0 Lsize= 70666kB time=00:00:05.00 bitrate=115663.5kbit
s/s
video:70657kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing
overhead: 0.012949%

E:\ffmpeg-20141225-git-1515bfb-win64-static>

///////////////////////////////////////////////////////////////////////////////
// end
///////////////////////////////////////////////////////////////////////////////

> Subject: Re: [FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) Compression
>
> As promised, I said I would provide some "real video". So I've uploaded a 5 second 10 Bit RGB 444 r10k sample:
>
> https://www.dropbox.com/s/exio9nmoxnbcyu6/10BitRGB444_r10k_5sec.avi?dl=0
>
> I think it'll be clear when you play that if your video looks correct or not.
>
> Thanks! =)
>
> 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:
> > >
> > > > Here's the result of what I see when playing the
> > > > 10BitRGB444_r10k_2sec.avi I sent you:
> > > >
> > > > https://www.dropbox.com/s/l3512t3qarkdt2i/FFPlay_Playing10BitRGB444_r10k.png
> > >
> > > If you don't like this output, please either
> > > choose an input file that everybody can
> > > recognize or provide the intended output.
> >
> > Agreed, it does help if I provide a frame of reference...so very good point. The 2 second video is NTSC color bars. I figured one would be cognitive of what that may look like ;). If you were able to play the 2 second r10k file correctly, you would have noticed they are NTSC color bars. If not, then yes, you'd have no idea if what you are viewing is playing correctly or not. So a frame of reference helps in our case.
> >
> > Here's a video of the "10BitRGB444_r10k_2sec.avi" file converted to a MP4 that plays correctly:
> >
> > https://www.dropbox.com/s/tt1x5ntx4ahll12/10BitRGB444_r10k_to_MP4.avi?dl=0
> >
> > And, here's a reference screen shot of what I see when I play it through VLC:
> >
> > https://www.dropbox.com/s/lizv2oedaptj9ik/10BitRGB444_r10k_to_MP4.png?dl=0
> >
> > Also, I went ahead and GIT'ed the FFMpeg repository and built in under Linux. I then re-ran the conversions that I was doing under Windows. I get the same results as shown in "FFPlay_Playing10BitRGB444_r10k.png" which I uploaded earlier (i.e that's what I see when playing the Linux converted file too: no different outcome).
> >
> > So either on Linux or Windows, I still don't get a correct conversion that views correctly. So, I suppose that remains to be the mystery.
> >
> > I'll try to pull from some real video (non NTSC color bars) I have and provide a sample of that too later.
> >
> > Cheers,
> >
> > Jason
> >
> > >
> > > (Nobody has reported in four years that
> > > something is wrong when decoding r10k.)
> > >
> > > I assumed it is correct.
> > >
> > > Carl Eugen
> > >
> > > _______________________________________________
> > > ffmpeg-user mailing list
> > > ffmpeg-***@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> >
> > _______________________________________________
> > ffmpeg-user mailing list
> > ffmpeg-***@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Carl Eugen Hoyos]

Jason Freets <jasonslife <at> hotmail.com> writes:

> So either on Linux or Windows, I still don't get a
> correct conversion that views correctly.

Don't you agree that it would be a problem if you get
different output on Widows and Linux?

Does the software that plays the colourbars correctly
also play the following files?
http://samples.ffmpeg.org/V-codecs/R10g.mov
http://samples.ffmpeg.org/V-codecs/R10k.mov

Carl Eugen

[Jason Freets]

> Subject: Re: [FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) Compression
>
> Jason Freets <jasonslife <at> hotmail.com> writes:
>
> > So either on Linux or Windows, I still don't get a
> > correct conversion that views correctly.
>
> Don't you agree that it would be a problem if you get
> different output on Widows and Linux?

I am getting the same output on Windows and Linux: the r10k to FFV1 both play incorrectly. In other words, I am not getting different outputs....but the same output. They both play just as bad as the screenshots provided.

>
> Does the software that plays the colourbars correctly
> also play the following files?
> http://samples.ffmpeg.org/V-codecs/R10g.mov
> http://samples.ffmpeg.org/V-codecs/R10k.mov

No, I've never been able to play R10K. I've not tried R10g either.

Apparently there are different formats:

R10k (Big Endian)
R10g (Big Endian)
r10k (Little Endian)
r10g (Little Endian)

Sometimes this gets confusing like v210 (YUV) and r210 (RGB)...which is the mistake I made earlier.

I am on an Intel machine, so I am living in the Little Endian world....not that it matters as we should be able to create content for either. But, apparently there is a difference. I suppose most content (Blackmagic / AJA) is done via a Mac as they are high end codecs.

For example, I notice that the R10K (http://samples.ffmpeg.org/V-codecs/R10k.mov) is Big Endian whereas the r10k's I've been sharing with you are Little Endian.

It's just to say, I notice the FFMpeg has no r10k samples!

Cheers,

Jason

>
> Carl Eugen
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Carl Eugen Hoyos]

Jason Freets <jasonslife <at> hotmail.com> writes:

> > > So either on Linux or Windows, I still don't get a
> > > correct conversion that views correctly.
> >
> > Don't you agree that it would be a problem if you get
> > different output on Widows and Linux?
>
> I am getting the same output on Windows and Linux: the
> r10k to FFV1 both play incorrectly.

Note that if you mention ffv1 like this, some (most/all)
readers will - as I did and Peter - assume that you
believe you found an issue with ffv1.
I only realize now that you (believe you) found an issue
with r10k that has nothing to do with ffv1.

> In other words, I am not getting different outputs....
> but the same output.

As said, I am quite happy you get identical output on
Windows and Linux;-)

> They both play just as bad as the screenshots provided.

(Note that what you call "bad" is what I see when I
open the file you provided with hex editor...)

> > Does the software that plays the colourbars correctly
> > also play the following files?
> > http://samples.ffmpeg.org/V-codecs/R10g.mov
> > http://samples.ffmpeg.org/V-codecs/R10k.mov
>
> No, I've never been able to play R10K. I've not
> tried R10g either.

What software created the sample you uploaded and how
can I watch it (the way you see it)?

> Apparently there are different formats:
>
> R10k (Big Endian)
> R10g (Big Endian)
> r10k (Little Endian)
> r10g (Little Endian)

How do you know?
I am not saying you are wrong but I would like to
understand this better.

> For example, I notice that the R10K
> (http://samples.ffmpeg.org/V-codecs/R10k.mov) is
> Big Endian whereas the r10k's I've been sharing
> with you are Little Endian.

How do you know that your sample is little-endian?

> It's just to say, I notice the FFMpeg has no r10k samples!

Until now, I assumed we do have samples (and that there
is no difference between R10k and r10k).

Carl Eugen

[Moritz Barsnick]

On Sun, Dec 28, 2014 at 19:47:17 +0000, Carl Eugen Hoyos wrote:
> How do you know?
> I am not saying you are wrong but I would like to
> understand this better.

AJA _does_ seem to differentiate between R10g, R10k and r10k:
https://www.aja.com/assets/support/files/981/en/kona_pc_manual_5.0.pdf

The closest thing to a spec I could find - while AJA doesn't seem to provide any
- is this, which confusingly says it's big-endian, but shows bit orders
in both endianesses:
http://www.bitjazz.com/en/products/sheervideo/faq/formats/pixel_formats.php#r10k

Just googling,
Moritz

[Carl Eugen Hoyos]

Moritz Barsnick <barsnick <at> gmx.net> writes:

> AJA _does_ seem to differentiate between R10g, R10k and r10k:
> https://www.aja.com/assets/support/files/981/en/kona_pc_manual_5.0.pdf

On which page does this document mention R10g, R10k or r10k?

> The closest thing to a spec I could find - while AJA doesn't
> seem to provide any - is this, which confusingly says it's
> big-endian, but shows bit orders in both endianesses:
>
http://www.bitjazz.com/en/products/sheervideo/faq/formats/pixel_formats.php#r10k

This unfortunately did not help.

Thank you, Carl Eugen

[Jason Freets]

> Subject: Re: [FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) Compression> > Moritz Barsnick <barsnick <at> gmx.net> writes:
>
> > AJA _does_ seem to differentiate between R10g, R10k and r10k:
> > https://www.aja.com/assets/support/files/981/en/kona_pc_manual_5.0.pdf
>
> On which page does this document mention R10g, R10k or r10k?

AJA Document Page Number: 37 (or PDF Page: 47)
AJA Document Page Number: 50 (or PDF Page: 60)
AJA Document Page Number: 70 (or PDF Page: 80)
AJA Document Page Number: 111 (or PDF Page: 121)

> > The closest thing to a spec I could find - while AJA doesn't
> > seem to provide any - is this, which confusingly says it's
> > big-endian, but shows bit orders in both endianesses:
> >
> http://www.bitjazz.com/en/products/sheervideo/faq/formats/pixel_formats.php#r10k
>
> This unfortunately did not help.

I figured it may not. Unfortunately, there's not a whole lot of info out from AJA on their own codecs.

>
> Thank you, Carl Eugen
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Jason Freets]

> Subject: Re: [FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) Compression
>
> Jason Freets <jasonslife <at> hotmail.com> writes:
>
> > > > So either on Linux or Windows, I still don't get a
> > > > correct conversion that views correctly.
> > >
> > > Don't you agree that it would be a problem if you get
> > > different output on Widows and Linux?
> >
> > I am getting the same output on Windows and Linux: the
> > r10k to FFV1 both play incorrectly.
>
> Note that if you mention ffv1 like this, some (most/all)
> readers will - as I did and Peter - assume that you
> believe you found an issue with ffv1.
> I only realize now that you (believe you) found an issue
> with r10k that has nothing to do with ffv1.

Sorry Carl, I was simply try to say that the resulting FFV1 file generated plays exactly the same in both Windows and Linux. Here we are converting the r10k file to FFV1, and when the FFV1 plays the video doesn't look correct. Agreed, has nothing to do with FFV1. It has more to do with how the r10k is being converted over to FFV1. So yes, I'm not at all saying that there is anything wrong with FFV1.

>
> > In other words, I am not getting different outputs....
> > but the same output.
>
> As said, I am quite happy you get identical output on
> Windows and Linux;-)

Me too! It's why I tried it on both environments....I wanted to be at least certain that I was getting identical output. =)

>
> > They both play just as bad as the screenshots provided.
>
> (Note that what you call "bad" is what I see when I
> open the file you provided with hex editor...)
>
> > > Does the software that plays the colourbars correctly
> > > also play the following files?
> > > http://samples.ffmpeg.org/V-codecs/R10g.mov
> > > http://samples.ffmpeg.org/V-codecs/R10k.mov
> >
> > No, I've never been able to play R10K. I've not
> > tried R10g either.
>
> What software created the sample you uploaded and how
> can I watch it (the way you see it)?

I'd have to see how they got installed on one of my systems. They came on a DVD with AJA hardware. I'll look into that. The result is I have AJA codec's in Windows. I have content that is my own as well as received from other studios for video work.

>
> > Apparently there are different formats:
> >
> > R10k (Big Endian)
> > R10g (Big Endian)
> > r10k (Little Endian)
> > r10g (Little Endian)
>
> How do you know?
> I am not saying you are wrong but I would like to
> understand this better.

Moritz is correct, he said, "AJA _does_ seem to differentiate between R10g, R10k and r10k". If you look through the link Moritz provided, you'll see the different encoding options:
https://www.aja.com/assets/support/files/981/en/kona_pc_manual_5.0.pdf

Look on Page 60 and under "Video Subtype" you'll see:
10-bit RGB 4:4:4 – ‘R10k’
10-bit RGB 4:4:4 – ‘r10k’

So there are two ways to encode. Why? I have no idea! I figure one was for MAC and the other for Windows?

I've uploaded two new video's for you:

10BitRGB444_R10k_5sec_BE.avi:
https://www.dropbox.com/s/bbdawafqa72mwiv/10BitRGB444_R10k_5sec_BE.avi?dl=0

10BitRGB444_r10k_5sec_LE.avi
https://www.dropbox.com/s/62rfxxahbkj9nz0/10BitRGB444_r10k_5sec_LE.avi?dl=0

In the filename, BE stands for "Big Endian" and LE stands for "Little Endian".

Why?

In "R10k" I consider the uppercase to imply Big Endian.
In "r10k" I consider the lowercase to imply Little Endian.

Am I sure about this "Big Endian" and "Little Endian" thing...No. I could be wrong. But, from looking into the two differ net format's that's what I have concluded. So, I'll stick to that for now.

I also thought perhaps it has something to do with "Full Range" and "Video Range" video. But, when you look at both the r10k and R10k...the video looks identical.

Going back to what Moritz said, there's not a lot of information from AJA as to what the difference is between r10k and R10k. So that sort of adds to the confusion.

The best info I've seen on the format is the link that Mortiz also posted:
http://www.bitjazz.com/en/products/sheervideo/faq/formats/pixel_formats.php#r10k

Perhaps you can analyze it for yourself and make sense of what SheerVideo pixel format spec means? But they do show two different layouts.

So back to the 2 files I uploaded. The 2 files are the same byte size. And, the frames in the video are aligned. But the intresting thing is that FFMpeg DOES play the R10k file (10BitRGB444_R10k_5sec_BE.avi) correctly using FFPlay. However, it does NOT play the r10k file (10BitRGB444_r10k_5sec_LE.avi) correclty using FFPlay.

When running both 2 files through FFMpeg, notice that FFMpeg reports:

"r10k (r10k / 0x6B303172)" for 10BitRGB444_r10k_5sec_LE.avi

and

"r10k (R10k / 0x6B303152)" for 10BitRGB444_R10k_5sec_BE.avi

Again, FFMpeg can convert and even play (through FFPlay) 10BitRGB444_R10k_5sec_BE.avi.

>
> > For example, I notice that the R10K
> > (http://samples.ffmpeg.org/V-codecs/R10k.mov) is
> > Big Endian whereas the r10k's I've been sharing
> > with you are Little Endian.
>
> How do you know that your sample is little-endian?
>
> > It's just to say, I notice the FFMpeg has no r10k samples!
>
> Until now, I assumed we do have samples (and that there
> is no difference between R10k and r10k).

I wish that were true, but it doesn't seem that way from what I can tell.

Cheers,

Jason

>
> Carl Eugen
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Peter B.]

On 12/29/2014 04:34 AM, Jason Freets wrote:
> So yes, I'm not at all saying that there is anything wrong with FFV1.

Carl was guessing correctly - and I'm indeed happy to hear that there's
nothing wrong with FFV1 :)

Yet, I find this thread incredibly interesting.
Especially the Little/Big Endian uncertainty.


Regards,
Pb

[Jason Freets]

> Subject: Re: [FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) Compression
>
> On 12/29/2014 04:34 AM, Jason Freets wrote:
> > So yes, I'm not at all saying that there is anything wrong with FFV1.
>
> Carl was guessing correctly - and I'm indeed happy to hear that there's
> nothing wrong with FFV1 :)

I'm glad too =).

> Yet, I find this thread incredibly interesting.
> Especially the Little/Big Endian uncertainty.

Yes, agreed, it is quite interesting if not also puzzling. From the two recent files, I'm hoping Carl may be able to determine what the difference is by inspect the files somehow. One is r10k the other R10k. But, they both should view identically.

Cheers,

Jason

> Regards,
> Pb
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Carl Eugen Hoyos]

Jason Freets <jasonslife <at> hotmail.com> writes:

> 10BitRGB444_r10k_5sec_LE.avi
> https://www.dropbox.com/s/62rfxxahbkj9nz0/10BitRGB444_r10k_5sec_LE.avi?dl=0

Thank you, patch sent.

Could you confirm (again) that these files were
produced using software provided by Aja?

Thank you, Carl Eugen

[Jason Freets]

> Subject: Re: [FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) Compression
>
> Jason Freets <jasonslife <at> hotmail.com> writes:
>
> > 10BitRGB444_r10k_5sec_LE.avi
> > https://www.dropbox.com/s/62rfxxahbkj9nz0/10BitRGB444_r10k_5sec_LE.avi?dl=0
>
> Thank you, patch sent.
>
> Could you confirm (again) that these files were
> produced using software provided by Aja?

Yes, produced using AJA's Codec in Windows. In this case, "10BitRGB444_r10k_5sec_LE.avi" is produced by the AJA "r10k" codec.

Looking at the AJA document from the prior mail message:

AJA Document Page Number: 70 (or PDF Page: 80) will show the "AVI files in the following Subtypes". The two encoding options are:

10-Bit RGB 4:4:4 – 'R10k'
10-Bit RGB 4:4:4 – 'r10k'

The "10BitRGB444_r10k_5sec_LE.avi" is the result of having chosen "10-Bit RGB 4:4:4 – 'r10k'"

Cheers,

Jason

>
> Thank you, Carl Eugen
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Carl Eugen Hoyos]

Jason Freets <jasonslife <at> hotmail.com> writes:

> > Could you confirm (again) that these files were
> > produced using software provided by Aja?
>
> Yes, produced using AJA's Codec in Windows.

Thank you for the confirmation!

Could you test if the following file produced with
FFmpeg plays with the AJA codec on Windows?
$ ffmpeg -f lavfi -i testsrc -t 10 -vcodec r10k out.avi

Thanks, Carl Eugen

[Jason Freets]

> Subject: Re: [FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) Compression
>
> Jason Freets <jasonslife <at> hotmail.com> writes:
>
> > > Could you confirm (again) that these files were
> > > produced using software provided by Aja?
> >
> > Yes, produced using AJA's Codec in Windows.
>
> Thank you for the confirmation!

No problem!

>
> Could you test if the following file produced with
> FFmpeg plays with the AJA codec on Windows?
> $ ffmpeg -f lavfi -i testsrc -t 10 -vcodec r10k out.avi

Yes, I will start looking at it =) Exciting! See, Christmas is not over yet. I will take FFmpeg out for a new spin.

Cheers,

Jason

>
> Thanks, Carl Eugen
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Jason Freets]

Ok Carl, so your fix does work! Wonderful! I can now use FFPlay to view the r10k (little endian) file on PC!

Read on ...

> Subject: Re: [FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) Compression
> >
> > Could you test if the following file produced with
> > FFmpeg plays with the AJA codec on Windows?
> > $ ffmpeg -f lavfi -i testsrc -t 10 -vcodec r10k out.avi
>
> Yes, I will start looking at it =) Exciting! See, Christmas is not over yet. I will take FFmpeg out for a new spin.
>
> Cheers,
>
> Jason

However, this test actually result in a R10k (big endian) file and NOT an r10k (little endian) file.

See "r10k (R10k / 0x6B303152)" below...

////////////////////////////////////////////////////////////////////////////////
// Sample test filter -> R10k
////////////////////////////////////////////////////////////////////////////////
E:\ffmpeg-20141225-git-1515bfb-win64-static>ffmpeg -f lavfi -i testsrc -t 10 -vc
odec r10k out.avi
ffmpeg version N-68778-g5c7227b Copyright (c) 2000-2014 the FFmpeg developers
built on Dec 29 2014 22:12:54 with gcc 4.9.2 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-av
isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
le-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --
enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-lib
modplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrw
b --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinge
r --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --en
able-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis
--enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-
libx265 --enable-libxavs --enable-libxvid --enable-lzma --enable-decklink --enab
le-zlib
libavutil 54. 15.100 / 54. 15.100
libavcodec 56. 19.100 / 56. 19.100
libavformat 56. 16.102 / 56. 16.102
libavdevice 56. 3.100 / 56. 3.100
libavfilter 5. 6.100 / 5. 6.100
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100
Input #0, lavfi, from 'testsrc':
Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 320x240 [SAR 1:1
DAR 4:3], 25 tbr, 25 tbn, 25 tbc
[swscaler @ 0000000000361000] full chroma interpolation for destination format '
rgb48le' not yet implemented
Output #0, avi, to 'out.avi':
Metadata:
ISFT : Lavf56.16.102
Stream #0:0: Video: r10k (R10k / 0x6B303152), rgb48le, 320x240 [SAR 1:1 DAR
4:3], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc
Metadata:
encoder : Lavc56.19.100 r10k
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> r10k (native))
Press [q] to stop, [?] for help
frame= 250 fps=0.0 q=0.0 Lsize= 75011kB time=00:00:10.00 bitrate=61449.4kbits
/s
video:75000kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing
overhead: 0.015310%

E:\ffmpeg-20141225-git-1515bfb-win64-static>

////////////////////////////////////////////////////////////////////////////////
// End
////////////////////////////////////////////////////////////////////////////////

Aside from the test above. It would seem I can take the original r10k (little endian) file and convert that to FFV1. But, going from FFV1 back to r10k there is the issue below:

////////////////////////////////////////////////////////////////////////////////
// FFV1 -> r10k
// Has the following warning message:
// Incompatible pixel format 'gbrp10le' for codec 'r10k', auto-selecting format 'rg
// b48le'
// [swscaler @ 0000000002bfcfe0] full chroma interpolation for destination format '
// rgb48le' not yet implemented
///////////////////////////////////////////////////////////////////////////////
E:\ffmpeg-20141225-git-1515bfb-win64-static>ffmpeg -i r10kToFFV.avi -pix_fmt gbr
p10le -vcodec r10k -c:a copy FFVTor10k.avi -f framemd5 -an FFVTor10k.framemd5
ffmpeg version N-68778-g5c7227b Copyright (c) 2000-2014 the FFmpeg developers
built on Dec 29 2014 22:12:54 with gcc 4.9.2 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-av
isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
le-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --
enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-lib
modplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrw
b --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinge
r --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --en
able-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis
--enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-
libx265 --enable-libxavs --enable-libxvid --enable-lzma --enable-decklink --enab
le-zlib
libavutil 54. 15.100 / 54. 15.100
libavcodec 56. 19.100 / 56. 19.100
libavformat 56. 16.102 / 56. 16.102
libavdevice 56. 3.100 / 56. 3.100
libavfilter 5. 6.100 / 5. 6.100
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100
Input #0, avi, from 'r10kToFFV.avi':
Metadata:
encoder : Lavf56.16.102
Duration: 00:00:05.01, start: 0.000000, bitrate: 108456 kb/s
Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), gbrp10le, 720x486, 109169 kb/s
, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
Incompatible pixel format 'gbrp10le' for codec 'r10k', auto-selecting format 'rg
b48le'
[swscaler @ 0000000002bfcfe0] full chroma interpolation for destination format '
rgb48le' not yet implemented
Output #0, avi, to 'FFVTor10k.avi':
Metadata:
ISFT : Lavf56.16.102
Stream #0:0: Video: r10k (R10k / 0x6B303152), rgb48le, 720x486, q=2-31, 200
kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
Metadata:
encoder : Lavc56.19.100 r10k
Output #1, framemd5, to 'FFVTor10k.framemd5':
Metadata:
encoder : Lavf56.16.102
Stream #1:0: Video: rawvideo (G3[0][10] / 0xA003347), gbrp10le, 720x486, q=2
-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
Metadata:
encoder : Lavc56.19.100 rawvideo
Stream mapping:
Stream #0:0 -> #0:0 (ffv1 (native) -> r10k (native))
Stream #0:0 -> #1:0 (ffv1 (native) -> rawvideo (native))
Press [q] to stop, [?] for help
frame= 13 fps=0.0 q=0.0 q=0.0 size= 17775kB time=00:00:00.43 bitrate=335693.
frame= 36 fps= 35 q=0.0 q=0.0 size= 49213kB time=00:00:01.20 bitrate=335627.
frame= 59 fps= 38 q=0.0 q=0.0 size= 80652kB time=00:00:01.96 bitrate=335612.
frame= 82 fps= 40 q=0.0 q=0.0 size= 112090kB time=00:00:02.73 bitrate=335606.
frame= 105 fps= 40 q=0.0 q=0.0 size= 143528kB time=00:00:03.50 bitrate=335602.
frame= 128 fps= 41 q=0.0 q=0.0 size= 174967kB time=00:00:04.27 bitrate=335600.
frame= 150 fps= 42 q=0.0 q=0.0 size= 205038kB time=00:00:05.00 bitrate=335598.
frame= 150 fps= 42 q=0.0 Lq=0.0 size= 205040kB time=00:00:05.00 bitrate=335602
.4kbits/s
video:512578kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxin
g overhead: unknown

////////////////////////////////////////////////////////////////////////////////
// End
////////////////////////////////////////////////////////////////////////////////

So 2 questions:

1) What are your thoughts on this warning message or what does it mean:

Incompatible pixel format 'gbrp10le' for codec 'r10k', auto-selecting format 'rg
b48le'
[swscaler @ 0000000002bfcfe0] full chroma interpolation for destination format '
rgb48le' not yet implemented

2) Going from r10k -> FFV1, a framemd5 can be created. This is good. However, I'd like to be able to produce a framemd5 going back from FFV1 -> r10k. Would this be possible if the "full chroma interpolation" was implemented? Or? What's the possiblity of making this round trip (r10k -> FFV1 -> r10k) for validation purposes? Otherwise, how does one verify that the ORIGINAL r10k -> FFV1 -> results in ORIGINAL r10k?

Cheers,

Jason

>
> >
> > Thanks, Carl Eugen
> >
> > _______________________________________________
> > ffmpeg-user mailing list
> > ffmpeg-***@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Carl Eugen Hoyos]

Carl Eugen Hoyos <cehoyos <at> ag.or.at> writes:

> Could you test if the following file produced with
> FFmpeg plays with the AJA codec on Windows?
> $ ffmpeg -f lavfi -i testsrc -t 10 -vcodec r10k out.avi

I unfortunately did not understand your answer
(I am not a native English speaker.)

Does the output file play on Windows with the
AJA codec installed?

Thank you for the test, Carl Eugen

[Jason Freets]

> Subject: Re: [FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) Compression
>
> Carl Eugen Hoyos <cehoyos <at> ag.or.at> writes:
>
> > Could you test if the following file produced with
> > FFmpeg plays with the AJA codec on Windows?
> > $ ffmpeg -f lavfi -i testsrc -t 10 -vcodec r10k out.avi
>
> I unfortunately did not understand your answer
> (I am not a native English speaker.)

Ok, good to know. My guess is probably Austria?

> Does the output file play on Windows with the
> AJA codec installed?

Yes it does! So great job! =) Your fix now can play r10k (Little Endian) files in Windows on a PC using the AJA Codec.

With your fix in FFmpeg, I can now take the r10k (little endian) lossless video and convert it to FFV1 (lossless): I call that "r10kToFFV.avi).

However, there is an issue with converting the FFV1 back to the original r10k (little endian) format:

Using the command:

ffmpeg -i r10kToFFV.avi -pix_fmt gbrp10le -vcodec r10k -c:a copy FFVTor10k.avi -f framemd5 -an FFVTor10k.framemd5

Where r10kToFFV.avi is the FFV1 file (which now holds the lossless compressed r10k video) I get the warning message:

"Incompatible pixel format 'gbrp10le' for codec 'r10k', auto-selecting format 'rgb48le'
[swscaler @ 0000000002bfcfe0] full chroma interpolation for destination format 'rgb48le' not yet implemented"

You can see that in my last mail message.

The framemd5's do NOT match going from r10k -> FFV1 -> r10k. Why is that?

Cheers,

Jason

>
> Thank you for the test, Carl Eugen
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Carl Eugen Hoyos]

Jason Freets <jasonslife <at> hotmail.com> writes:

> > > Could you test if the following file produced with
> > > FFmpeg plays with the AJA codec on Windows?
> > > $ ffmpeg -f lavfi -i testsrc -t 10 -vcodec r10k out.avi
> >
> > I unfortunately did not understand your answer
> > (I am not a native English speaker.)
>
> Ok, good to know. My guess is probably Austria?

Yes, you are correct.

> > Does the output file play on Windows with the
> > AJA codec installed?
>
> Yes it does!

Thank you for testing.

> So great job! =)

This was not something I fixed, I was just curious
if the files play: I am not sure if it was ever
tested (likely not).
(And this of course makes me wonder if my question
above was maybe unclear: Was it unclear and you
just wanted to confirm that your two files that
you uploaded for me and other files that you have
play fine with FFplay but didn't before?)

> Your fix now can play r10k (Little Endian) files
> in Windows on a PC using the AJA Codec.

This may be a misunderstanding:
My fix allows you to play r10k files (with small
"r") on Linux (and Windows) with FFmpeg (and
MPlayer and vlc).

> With your fix in FFmpeg, I can now take the r10k
> (little endian) lossless video and convert it to
> FFV1 (lossless): I call that "r10kToFFV.avi).

Yes, this is correct.

> However, there is an issue with converting the
> FFV1 back to the original r10k (little endian)
> format:

This format is not supported by FFmpeg: You can
only write R10k (with capital "R").

Carl Eugen

[Jason Freets]

> Subject: Re: [FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) Compression
>
> Jason Freets <jasonslife <at> hotmail.com> writes:
>
> > > > Could you test if the following file produced with
> > > > FFmpeg plays with the AJA codec on Windows?
> > > > $ ffmpeg -f lavfi -i testsrc -t 10 -vcodec r10k out.avi
> > >
> > > I unfortunately did not understand your answer
> > > (I am not a native English speaker.)
> >
> > Ok, good to know. My guess is probably Austria?
>
> Yes, you are correct.

Well, you are doing fine =)

> > > Does the output file play on Windows with the
> > > AJA codec installed?
> >
> > Yes it does!
>
> Thank you for testing.

No problem! And thanks for your support and help with this too. We did it together.

>
> > So great job! =)
>
> This was not something I fixed, I was just curious
> if the files play: I am not sure if it was ever
> tested (likely not).

Yes, the file does play. Your fix works.

> (And this of course makes me wonder if my question
> above was maybe unclear: Was it unclear and you
> just wanted to confirm that your two files that
> you uploaded for me and other files that you have
> play fine with FFplay but didn't before?)

No, you were not unclear. The 2 files I uploaded were created by the AJA codec. Before your fix, only the r10k (Little Endian) file did not play. The R10K (Big Endian) always did play fine (before and after your fix). With your new fix, now the r10k (Little Endian) also now plays correctly using FFmpeg.

>
> > Your fix now can play r10k (Little Endian) files
> > in Windows on a PC using the AJA Codec.
>
> This may be a misunderstanding:
> My fix allows you to play r10k files (with small
> "r") on Linux (and Windows) with FFmpeg (and
> MPlayer and vlc).

Correct, it does for both Linux and Windows. I tried your fix on both Windows and Linux.

>
> > With your fix in FFmpeg, I can now take the r10k
> > (little endian) lossless video and convert it to
> > FFV1 (lossless): I call that "r10kToFFV.avi).
>
> Yes, this is correct.

Yes, agreed. So we now have r10k (Little Endian) -> to FFV1 working. Although, my point is I don't have a way to prove that converting it to FFV1 works correctly. If I can convert from r10k -> to FFV1 -> back to r10k, then I would have a way to validate the conversion process.

>
> > However, there is an issue with converting the
> > FFV1 back to the original r10k (little endian)
> > format:
>
> This format is not supported by FFmpeg: You can
> only write R10k (with capital "R").

This is what I am now trying to understand. You are saying that FFmpeg can only write R10k (Big Endian). So the question I have is if there will be a fix put in place to have FFmpeg write r10k (Little Endian)? Too hard to do? Or?

Cheers,

Jason

>
> Carl Eugen
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Carl Eugen Hoyos]

Jason Freets <jasonslife <at> hotmail.com> writes:

> No, you were not unclear. The 2 files I uploaded
> were created by the AJA codec. Before your fix,
> only the r10k (Little Endian) file did not play.
> The R10K (Big Endian) always did play fine (before
> and after your fix). With your new fix, now the
> r10k (Little Endian) also now plays correctly
> using FFmpeg.

Unfortunately, this is not what I wanted to know;-(

Any chance that you could test what I asked for?

> So the question I have is if there will be a fix
> put in place to have FFmpeg write r10k (Little
> Endian)? Too hard to do? Or?

Useless?
Or don't you agree?

Carl Eugen

[Jason Freets]

> Subject: Re: [FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) Compression
>
> Jason Freets <jasonslife <at> hotmail.com> writes:
>
> > No, you were not unclear. The 2 files I uploaded
> > were created by the AJA codec. Before your fix,
> > only the r10k (Little Endian) file did not play.
> > The R10K (Big Endian) always did play fine (before
> > and after your fix). With your new fix, now the
> > r10k (Little Endian) also now plays correctly
> > using FFmpeg.
>
> Unfortunately, this is not what I wanted to know;-(
>
> Any chance that you could test what I asked for?

I believe you wanted me to run:

ffmpeg -f lavfi -i testsrc -t 10 -vcodec r10k out.avi

Yes, this does work. It creates a R10K (Big Edian) video file. The R10K (Big Edian) video file does play.

Since the "-vcodec r10k" is a little 'r' I was expecting a "r10k" (Little Endian) video file.

To me it would be nice if:

"ffmpeg -f lavfi -i testsrc -t 10 -vcodec R10k out.avi" would output a R10k (Big Endian) video file.

and

"ffmpeg -f lavfi -i testsrc -t 10 -vcodec r10k out.avi" would output a r10k (Little Endian) video file.

That depends if the "-vcodec r10k" is case sensitive.

>
> > So the question I have is if there will be a fix
> > put in place to have FFmpeg write r10k (Little
> > Endian)? Too hard to do? Or?
>
> Useless?
> Or don't you agree?

No, it would not be useless for me. I have a lot of r10k (Little Endian) video files. I suppose it's a "nice" to have. It would make things consistent that FFmpeg can Input and Ouput both R10k and r10k. I then have a way to convert from r10k to FFV1 and back to the original r10k when needed.

If I could, I'd put it in because I would make good use of it. But, I suppose if I am the only one, then I suppose that makes it a bit useless too. However, those who use AJA would know they could use FFmpeg; that's a nice thing. So, I and others would benefit from it if and where r10k is used.

I suppose that's something for you to have to decide. Obviously, no one has complained about r10k (Little Endian) support under FFmpeg but me...haha. Obviously, I can't put it in myself. If I could, I would for everyone.

Still, I have no way to validate my conversion from r10k to FFV1? How do I know frames are not corrupt?

Cheers,

Jason

>
> Carl Eugen
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Carl Eugen Hoyos]

Jason Freets <jasonslife <at> hotmail.com> writes:

> ffmpeg -f lavfi -i testsrc -t 10 -vcodec r10k out.avi
>
> Yes, this does work. It creates a R10K (Big Edian)
> video file. The R10K (Big Edian) video file does play.

With FFplay? Or did you test another application?

> Since the "-vcodec r10k" is a little 'r' I was
> expecting a "r10k" (Little Endian) video file.

Nearly all users would find it extremely annoying if
this command line would suddenly produce different
output.

> > > So the question I have is if there will be a fix
> > > put in place to have FFmpeg write r10k (Little
> > > Endian)? Too hard to do? Or?
> >
> > Useless?
> > Or don't you agree?
>
> No, it would not be useless for me. I have a lot of
> r10k (Little Endian) video files. I suppose it's a
> "nice" to have. It would make things consistent that
> FFmpeg can Input and Ouput both R10k and r10k. I
> then have a way to convert from r10k to FFV1 and back
> to the original r10k when needed.

Why can't you simply convert to R10k?
Or do you mean the file above does not play with
applications that are not FFmpeg-based? In this
case, I would like to find out why.

Carl Eugen

[Jason Freets]

> To: ffmpeg-***@ffmpeg.org
> From: ***@ag.or.at
> Date: Tue, 30 Dec 2014 23:52:40 +0000
> Subject: Re: [FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) Compression
>
> Jason Freets <jasonslife <at> hotmail.com> writes:
>
> > ffmpeg -f lavfi -i testsrc -t 10 -vcodec r10k out.avi
> >
> > Yes, this does work. It creates a R10K (Big Edian)
> > video file. The R10K (Big Edian) video file does play.
>
> With FFplay? Or did you test another application?

////////////////////////////////////////////////////////////////////////////////
// Testing Under Linux
// Running:
// ffmpeg -f lavfi -i testsrc -t 10 -vcodec r10k out.avi
////////////////////////////////////////////////////////////////////////////////

Input #0, lavfi, from 'testsrc':
Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 320x240 [SAR 1:1 DAR 4:3], 25 tbr, 25 tbn, 25 tbc
[swscaler @ 0x3644020] full chroma interpolation for destination format 'rgb48le' not yet implemented
Output #0, avi, to 'out.avi':
Metadata:
ISFT : Lavf56.16.102
Stream #0:0: Video: r10k (R10k / 0x6B303152), rgb48le, 320x240 [SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc
Metadata:
encoder : Lavc56.19.100 r10k
////////////////////////////////////////////////////////////////////////////////
//
////////////////////////////////////////////////////////////////////////////////

The result of the above, outputs an out.avi that is R10k (Big Endian) in Linux.

Copying the out.avi file in Linux to Windows, I can then play it in Windows in two ways:
Case #1) Using FFPlay
Case #2) Using AJA Decoder

In both cases, the Linux out.avi files plays fine in Windows using both 'play' methods.

Also, by running in Windows:

ffmpeg -f lavfi -i testsrc -t 10 -vcodec r10k out.avi

In windows. I get a out.avi that is EXACTLY the same as I do in Linux.

So yes, they are consistent.

Hopefully that answers your question?

>
> > Since the "-vcodec r10k" is a little 'r' I was
> > expecting a "r10k" (Little Endian) video file.
>
> Nearly all users would find it extremely annoying if
> this command line would suddenly produce different
> output.

So the CODEC_NAME in "-vcodec CODEC_NAME" is NOT case sensitive? If it's NOT case sensative, then yes I could see that anyoing users. However, if "CODEC_NAME" is case sensitive then it would be nice if "-vcodec r10k" means r10k (Little Endian) and "-vcodec R10k" means R10k (Big Edian). I don't see that as extremely annoying since there really are 2 different codec formats: r10k and R10k. If CODEC_NAME is NOT case sensitive, then yes I suppose there is no way to distinguish between r10k and R10k using "-vcodec CODEC_NAME".

>
> > > > So the question I have is if there will be a fix
> > > > put in place to have FFmpeg write r10k (Little
> > > > Endian)? Too hard to do? Or?
> > >
> > > Useless?
> > > Or don't you agree?
> >
> > No, it would not be useless for me. I have a lot of
> > r10k (Little Endian) video files. I suppose it's a
> > "nice" to have. It would make things consistent that
> > FFmpeg can Input and Ouput both R10k and r10k. I
> > then have a way to convert from r10k to FFV1 and back
> > to the original r10k when needed.
>
> Why can't you simply convert to R10k?

Two points:

1) I can convert to R10k. However, If I am to use FFMpeg, then that seems like my only option since FFmpeg won't output r10k. It means I can NEVER go back to r10k though once I convert to FFV1 using FFmpeg.

2) I can convert from r10k to FFV1, but again, how do I PROVE that r10k files are converted correctly to FFV1? With v210, for example I could convert from v210 to FFV1 and then back to v210 and verify that the conversion was correct. I can't do this with r10k. And since I can't do that with FFmpeg, how do I prove that the r10k is converted to FFV1 is converted correctly?

> Or do you mean the file above does not play with
> applications that are not FFmpeg-based? In this
> case, I would like to find out why.

It seems to work on the small r10k test files. I'd like to try on BIG r10k files to see how it does. So, I still need to test your fixes more to really confirm. I want to be certain.

Cheers,

Jason

>
> Carl Eugen
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Carl Eugen Hoyos]

Jason Freets <jasonslife <at> hotmail.com> writes:

> I can convert to R10k. However, If I am to use
> FFMpeg, then that seems like my only option since
> FFmpeg won't output r10k. It means I can NEVER go
> back to r10k though once I convert to FFV1 using
> FFmpeg.

Why do you want to "go back" to r10k?
What is the advantage over using R10k?

> With v210, for example I could convert from v210
> to FFV1 and then back to v210 and verify that
> the conversion was correct.

How did you verify it?
Didn't you use FFmpeg and hoped that
its verification methods are correct?

If you trust the verification of FFmpeg, you can
still do:
$ ffmpeg -i input -f framecrc crc1.txt
$ ffmpeg -i input -vcodec ffv1 -pix_fmt gbrp10 -coder 1 out.avi
$ ffmpeg -i out.avi -vcodec r10k out2.avi
$ ffmpeg -i out2.avi -pix_fmt bgr48 -f framecrc crc2.txt
I would bet (not my fingers but still) that crc1.txt
and crc2.txt are identical.
But this of course does not rule out bugs and I
sincerely hope you read FFmpeg's license before
using it...

Carl Eugen

[Jason Freets]

> Subject: Re: [FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) Compression
>
> Jason Freets <jasonslife <at> hotmail.com> writes:
>
> > I can convert to R10k. However, If I am to use
> > FFMpeg, then that seems like my only option since
> > FFmpeg won't output r10k. It means I can NEVER go
> > back to r10k though once I convert to FFV1 using
> > FFmpeg.
>
> Why do you want to "go back" to r10k?
> What is the advantage over using R10k?

I have no outstanding reason outside of conveyance and for when they come already in that format. I have a lot and deal with a lot of video in r10k (not R10k). Yes, I could work with them in R10k. Actually I have both. But, the way I am looking at it (not at the code level like you do), R10k is similar to r10k. If it's easy to output to R10k, not sure why FFmpeg couldn't be made to write out r10k too since AJA supports it and since R10k is similar to it. But, I won't push it. Like I said, it's a nice to have. Perhaps from your end (at the code level) it would be much more complicated. It is what it is then.

I suppose that's a push up and change. In FFmpeg's world right now "-vcodec r10k" is considered R10k. So to me, I think FFmpeg dealing with r10k is already confusing since r10k and R10k are really different. But that's just my opinion. Thankfully no one has to listen to me ;) haha. I'm saying if r10k and R10k are different, might as well make it consistent.

> > With v210, for example I could convert from v210
> > to FFV1 and then back to v210 and verify that
> > the conversion was correct.
>
> How did you verify it?
> Didn't you use FFmpeg and hoped that
> its verification methods are correct?

Yes, using framemd5's. And, the fact that I could output FFV1 back to v210 and end up with the same v210 that I started with before passing it into FFmpeg. So that was very nice! And, very convenient.

>
> If you trust the verification of FFmpeg, you can
> still do:
> $ ffmpeg -i input -f framecrc crc1.txt
> $ ffmpeg -i input -vcodec ffv1 -pix_fmt gbrp10 -coder 1 out.avi
> $ ffmpeg -i out.avi -vcodec r10k out2.avi
> $ ffmpeg -i out2.avi -pix_fmt bgr48 -f framecrc crc2.txt
> I would bet (not my fingers but still) that crc1.txt
> and crc2.txt are identical.
> But this of course does not rule out bugs and I
> sincerely hope you read FFmpeg's license before
> using it...

I may play with that later.

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. 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. Otherwise, yes, it is a risk. And a risk is something not tolerable for me.

Cheers,

Jason

>
> Carl Eugen
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Carl Eugen Hoyos]

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.

Carl Eugen

[Jason Freets]

> 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
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Jason Freets]

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
> > ffmpeg-***@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Carl Eugen Hoyos]

Carl Eugen Hoyos <cehoyos <at> ag.or.at> writes:

> Thank you, patch sent.

The patch was merged.

Thanks for your support, Carl Eugen

[Jason Freets]

> Subject: Re: [FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) Compression
>
> Carl Eugen Hoyos <cehoyos <at> ag.or.at> writes:
>
> > Thank you, patch sent.
>
> The patch was merged.

Wow! Great! I will start taking a look at it!

>
> Thanks for your support, Carl Eugen

Thank you Carl!

Will be looking at it. =)

Cheers,

Jason

>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[Peter B.]

Dear Jason,

I haven't done much with RGB 10bit yet, but I'm working with FFV1 a lot,
so if you send me a sample and your commandlines, I could take a look.


Late Merry-Christmas to you :)
Peter

[Jason Freets]

Thanks Peter! Much appreciated!

I just sent a response back to Carl, so please see that post. It provides the command lines that I've been using.

Cheers,

Jason =)

> Date: Fri, 26 Dec 2014 21:11:14 +0100
> From: ***@das-werkstatt.com
> To: ffmpeg-***@ffmpeg.org
> Subject: Re: [FFmpeg-user] LLossless (10 Bit RGB 444) and (10 Bit YUV 422) Compression
>
> Dear Jason,
>
> I haven't done much with RGB 10bit yet, but I'm working with FFV1 a lot,
> so if you send me a sample and your commandlines, I could take a look.
>
>
> Late Merry-Christmas to you :)
> Peter
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-***@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user