Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > New and alternative video codecs

Reply
 
Thread Tools Search this Thread Display Modes
Old 13th December 2017, 12:08   #61  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Quote:
Originally Posted by poisondeathray View Post
I'm not getting bit for bit identical the same result.... Very slightly different bitrate and differences on a 10bit422 source . Anyone else ?
I don't think it meant to be bit identical. You can ask this question David on github.
SDK and GoPro codec are not necessarily 100% the same.
Decoder should be the same I think.
I would not trust ffms2 at this point.

Last edited by kolak; 13th December 2017 at 12:12.
kolak is offline   Reply With Quote
Old 13th December 2017, 12:11   #62  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Quote:
Originally Posted by poisondeathray View Post
I know it's work in progress, but it's supposed to be standardized STMPE VC5 , so results so be more consistent IMO . I don't know a thing about writing code. I can't even spel properly . I can only help by making observations and test
STMPE VC5 is actually different to SDK and GoPro codec, even in codec structure. Not much but it's different. I assume this was enforced by SMPTE during whole process to make it "better".
kolak is offline   Reply With Quote
Old 13th December 2017, 12:13   #63  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
Are the encoders deterministic in the first place? (i.e. encode twice with very same encoder gets same result?)
sneaker_ger is offline   Reply With Quote
Old 13th December 2017, 12:14   #64  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Quote:
Originally Posted by WorBry View Post
The actual results obtained with that one 1080/30p HD-AVC.mp4 (8-bit 4:2:0) source clip (795 frames)

Code:
Bitrate of Cineform avi encode (Mb/s) - no audio

                   Native           VFW
Filmscan 2          327             326
Filmscan 1          239             239
High                169             168                  
Medium              133             133
Low                 122             122
Same frame count in all cases. I didn't record the actual file sizes (in bytes).

Edit: And just for reference, same source clip transcoded to Cineform.avi with DaVinci Resolve 14.1 (at Full 'Data' levels), which uses a different terminology for the quality levels, just to confuse matters:

Code:
Bitrate Mb/s

Best (= Film Scan 2)          332
High (= Film Scan 1)          242
Medium (= High)               172
Low (= Medium)                135
Least (= Low)                 124
Same frame count (795)
Resolve uses RGB pipe, so it will probably never be the same.
As I said- I don't think you should expect bit identical encodes (definitely not from Resolve).
kolak is offline   Reply With Quote
Old 13th December 2017, 12:15   #65  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Quote:
Originally Posted by sneaker_ger View Post
Are the encoders deterministic in the first place? (i.e. encode twice with very same encoder gets same result?)
Within the same implementation I think they are.
kolak is offline   Reply With Quote
Old 13th December 2017, 12:23   #66  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
Found something interesting.
Native encode in single threaded mode: identical results to vfw 9.2.1 (compared 4 frames).
Native encode in multi threaded mode: only 1st frame is identical. Looks like temporal dithering behaving differently.
shekh is offline   Reply With Quote
Old 13th December 2017, 12:36   #67  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Maybe it's the number of threads which is set differently for 2 encodes (codec uses some setting, SDK other).
Even if it's different I don't think it's a problem at all.
kolak is offline   Reply With Quote
Old 13th December 2017, 12:54   #68  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
I think vfw codec is using single-threaded method because there is no standard way to run vfw encoder asynchronously.
shekh is offline   Reply With Quote
Old 13th December 2017, 15:26   #69  |  Link
WorBry
Registered User
 
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
Quote:
Originally Posted by kolak View Post
Maybe it's the number of threads which is set differently for 2 encodes (codec uses some setting, SDK other).
In that 'quick test' I did the native encoder was set for multi-threading.

Quote:
Originally Posted by kolak View Post
Even if it's different I don't think it's a problem at all.
I'm inclined to think the same. IIRC, a year or so back when I did some tests comparing available Cineform transcoders, the results obtained with Adobe Media Encoder (file sizes, quality metrics) were different still.
__________________
Nostalgia's not what it used to be
WorBry is offline   Reply With Quote
Old 24th December 2017, 09:43   #70  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 697
Has anyone tried to compile Cineform codecs?
I read the article on Hitfilm, I downloaded the codecs. Unfortunately, GCC doesn't want to compile.
How do I set parameters for encoder testcfhd.exe?
Code:
usage: cfhd.exe [switches] or <filname.MOV|MP4|AVI>
          -D = decoder tester
          -E = encoder tester
ffmpeg.exe -i 111.tiff -f yuv4mpegpipe -vframes 1 -pix_fmt yuv420p - | testcfhd.exe -E=-
https://hitfilm.com/forum/discussion...ly-open-source
Jamaika is offline   Reply With Quote
Old 24th December 2017, 12:24   #71  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
The code was intended for Visual Studio. I compiled with GCC but had to correct few small things.
shekh is offline   Reply With Quote
Old 25th December 2017, 12:04   #72  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Quote:
Originally Posted by Jamaika View Post
Has anyone tried to compile Cineform codecs?
I read the article on Hitfilm, I downloaded the codecs. Unfortunately, GCC doesn't want to compile.
How do I set parameters for encoder testcfhd.exe?
Code:
usage: cfhd.exe [switches] or <filname.MOV|MP4|AVI>
          -D = decoder tester
          -E = encoder tester
ffmpeg.exe -i 111.tiff -f yuv4mpegpipe -vframes 1 -pix_fmt yuv420p - | testcfhd.exe -E=-
https://hitfilm.com/forum/discussion...ly-open-source
This is not how this app works.
It's very simple test app which you can simulate encoding or decoding. There is no piping support. Read description.
kolak is offline   Reply With Quote
Old 25th December 2017, 15:30   #73  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 697
Unfortunately, I see it. What is this free software for?

PS Different developers call the test app. The simple test is for jpegxr and jpegls.
Jamaika is offline   Reply With Quote
Old 25th December 2017, 16:00   #74  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
It's not a software. It's SDK which you can use to add Cineform import/export you your own app.
kolak is offline   Reply With Quote
Old 25th January 2018, 13:50   #75  |  Link
Midzuki
Unavailable
 
Midzuki's Avatar
 
Join Date: Mar 2009
Location: offline
Posts: 1,480
For what it's worth...

https://trac.ffmpeg.org/ticket/6863
Midzuki is offline   Reply With Quote
Old 26th January 2018, 16:00   #76  |  Link
dipje
Registered User
 
Join Date: Oct 2014
Posts: 268
That's the same ticket that has existed from the start.

FFmpeg-maintainers response is still the same and expected (and correct to be honest): "we welcome a patch" but they don't actively make stuff. They fix bugs, they don't do completely new implementations.
So it's up to someone to make it and submit a patch.

And most people don't want to go near it since it apparently isn't a 'neat' library or it doesn't compile on a lot of stuff.

Shame though, would be nice... But most people don't have the (free) time or the knowledge to work on this.
dipje is offline   Reply With Quote
Old 26th January 2018, 16:27   #77  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
Quote:
Originally Posted by dipje View Post
they don't actively make stuff. They fix bugs, they don't do completely new implementations.
The Cineform implementation in FFmpeg right now was created by a FFmpeg maintainer, as have the majority of others in FFmpeg, so not sure where you are coming from.

But the fact remains that open-source development works on a simple concept: You need someone motivated to work on something. Integrating some external SDK is usually not much fun.

There is actually a GSoC task listed to improve the existing decoder both in missing features/bugs and speed, maybe a student will be interested in picking that up.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 23:36.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.