Re: [FFmpeg-user] [ffmpeg-user] Transcode to high bitrate of Dolby TrueHD or DTS-HD Master

[Marcus Johnson]

I see, thanks for the info.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

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

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

Re: [FFmpeg-user] [ffmpeg-user] Transcode to high bitrate of Dolby TrueHD or DTS-HD Master

[Xuebing Wang]

On Mon, 2015-01-05 at 18:45 -0500, Marcus Johnson wrote:
> Wait, by HBR are you referring to DTS-HD HBR? because the DTS decoder
> doesn't support really anything beyond Core (aka old fashioned dts)

I may be wrong, I think the *precise* definition of IEC 61937 HBR is
(IEC 60598 frame rates at above 192kHz).
* Every IEC 60598 frame consists of 2 subframes (besides IEC 61937 uses
subframe to carry 16-bits of samples).
* Thus, bitrate = 192k * 2 subframes * 16 bits = 6.144Mbps

This conforms to the definition that >6.144Mbps bitrate is HBR. 

In order to get audio stream passing HDMI (there are logics inside HDMI
hardware), there are 2 ways:
-- For non-HBR (below 192k IEC 60598 frame rate), HDMI logic (hardware)
encodes audio stream (input: normal PCM, output HDMI Audio Sample
Packet).
-- For HBR, by HDMI passthrough (passthrough above encoding done by
hardware) (and encoding is supposedly done by ff_spdif_muxer), and this
is what I am trying to verify.

But, my HDMI receiver only supports TrueHD, DTS-HD Master via HDMI
interface.

But, it seems Dolby Digital Plus (E-AC3), (supports up to 15
full-bandwidth audio channels at a maximum bitrate of 6.144
Mbit/s)(quote from wikipedia), thus it is NOT HBR.

Thanks.

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


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] [ffmpeg-user] Transcode to high bitrate of Dolby TrueHD or DTS-HD Master

[Marcus Johnson]

Wait, by HBR are you referring to DTS-HD HBR? because the DTS decoder
doesn't support really anything beyond Core (aka old fashioned dts)
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] [ffmpeg-user] Transcode to high bitrate of Dolby TrueHD or DTS-HD Master

[Xuebing Wang]

On Mon, 2015-01-05 at 22:20 +0100, Moritz Barsnick wrote:
> On Tue, Jan 06, 2015 at 04:38:47 +0800, Xuebing Wang wrote:
> > >> bitrate audio (e.g. max 24.5 Mbps for 5.1 channels, 192k sampling
> > >> rate, 24 bits, 5.1 channels) (i: still attain the video stream, ii,
> > >> audio only)?
> > Thanks Andy. Any idea what is the command line to resample TrueHD from 
> > like 640kbps to HBR (>6.144Mbps)?
> 
> I think you are confusing the terms of resampling and re-encoding. I
> think you mean changing the bit rate (by re-encoding).
> 
> You can indeed resample from 48k to 192k. But why would you want to
> increase the bit rate from the original TrueHD stream? The quality
> won't increase from this.
> 
> Compatibility?

Thanks. I do not care much about the quality. I am trying to verify
streaming HBR (high bit rate) audio via HDMI (aka HDMI passthrough, HBR
audio streams need to go through ff_spdif_muxer, implemented in
libavformat/spdifenc.c).


> 
> FWIW, the audio sample rate is controlled by "-ar", the bit rate by
> "-b:a".
> 
> Confused,
> Moritz
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] [ffmpeg-user] Transcode to high bitrate of Dolby TrueHD or DTS-HD Master

[Moritz Barsnick]

On Tue, Jan 06, 2015 at 04:38:47 +0800, Xuebing Wang wrote:
> >> bitrate audio (e.g. max 24.5 Mbps for 5.1 channels, 192k sampling
> >> rate, 24 bits, 5.1 channels) (i: still attain the video stream, ii,
> >> audio only)?
> Thanks Andy. Any idea what is the command line to resample TrueHD from 
> like 640kbps to HBR (>6.144Mbps)?

I think you are confusing the terms of resampling and re-encoding. I
think you mean changing the bit rate (by re-encoding).

You can indeed resample from 48k to 192k. But why would you want to
increase the bit rate from the original TrueHD stream? The quality
won't increase from this.

Compatibility?

FWIW, the audio sample rate is controlled by "-ar", the bit rate by
"-b:a".

Confused,
Moritz
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] [ffmpeg-user] Transcode to high bitrate of Dolby TrueHD or DTS-HD Master

[Marcus Johnson]

What? TrueHD is lossless, therefore it's bitrate is variable, and higher
than 640kbps...
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] [ffmpeg-user] Transcode to high bitrate of Dolby TrueHD or DTS-HD Master

[Xuebing Wang]

On 01/06/2015 03:53 AM, Andy Furniss wrote:

Xuebing Wang wrote:

Hi community,

ffmpeg options are a bit daunting for me. Can anyone teach me how to
transcode to high bitrate of Dolby TrueHD or DTS-HD Master?

I download testing samples from here:
http://www.demo-world.eu/2d-demo-trailers-hd/

Cavalcade (Lossless) (DTS-HD MA 5.1), ffplay can play it with no
problem, ffplay shows its audio bitrate is 1536 kb/s.

Can someone teach me how to transcode this .m2ts file to high
bitrate audio (e.g. max 24.5 Mbps for 5.1 channels, 192k sampling
rate, 24 bits, 5.1 channels) (i: still attain the video stream, ii,
audio only)?


There isn't support for DTS-HD MA currently. ffmpeg/play will use the
normal DTS core.

TrueHD is supported, though I think you will get full dynamic range,
which is not ideal. The same seems to be true for DTS.


Thanks Andy. Any idea what is the command line to resample TrueHD from 
like 640kbps to HBR (>6.144Mbps)?



___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user



--
Thanks,
Xuebing Wang

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] [ffmpeg-user] Transcode to high bitrate of Dolby TrueHD or DTS-HD Master

[Andy Furniss]

Xuebing Wang wrote:

Hi community,

ffmpeg options are a bit daunting for me. Can anyone teach me how to
transcode to high bitrate of Dolby TrueHD or DTS-HD Master?

I download testing samples from here:
http://www.demo-world.eu/2d-demo-trailers-hd/

Cavalcade (Lossless) (DTS-HD MA 5.1), ffplay can play it with no
problem, ffplay shows its audio bitrate is 1536 kb/s.

Can someone teach me how to transcode this .m2ts file to high
bitrate audio (e.g. max 24.5 Mbps for 5.1 channels, 192k sampling
rate, 24 bits, 5.1 channels) (i: still attain the video stream, ii,
audio only)?


There isn't support for DTS-HD MA currently. ffmpeg/play will use the
normal DTS core.

TrueHD is supported, though I think you will get full dynamic range,
which is not ideal. The same seems to be true for DTS.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[FFmpeg-user] ffmpeg 2.5 "Bohr" - MPEG-DASH support

[Bogdan ioan Gabor]

Hi,
I'm a newbie, so my question can sound stupid, but...
I’m wondering if with the new feature of ffmpeg 2.5, MPEG-DASH fragmenting 
muxer, I’ll beable to segment an mp4 live stream, in order to display it on an 
HTML5 page,using the video tag.I tried to find any useful information on how I 
should useMPEG-DASH fragmenting muxer, but with no luck.
Thank you
Bogdan Ioan Gabor

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Fastest lossless codec and settings.

[Claudiu Rad]

On 1/5/2015 3:20 PM, Zsolt wrote:

2015-01-03 16:45 GMT+01:00 Peter B. :



Which resolution are you planning to capture?



I was just trying to capture the whole desktop. (1920*1200)


that's HUGE for your CPU.
you either need a really fast CPU to encode that (even lossless), and/or 
really fast drives, the generated bitrate is huge especially in 
uncompressed form, possibly only SSDs will do in a sustained way (it 
also depends on your framerate of course).


maybe you should think about resizing this to something more manageable 
if your hardware is modest. 960x600 for example would be 1/4 of the 
bitrate in uncompressed and should be manageable by a HDD. maybe even 
lossless codecs will start to work.


i would experiment with the input scaling starting from something like 
480x300, increase from there and see at which point the bottlenecks 
start and why.
also the scaling may take some CPU, it may be interesting to measure 
that separately in order to find out what exactly happens.


bottom line, personally i think you either have to encode to lower 
resolution or change your hardware. but please post results if you find 
solutions.



___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

--
Claudiu

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Fastest lossless codec and settings.

[Zsolt]

2015-01-03 16:45 GMT+01:00 Peter B. :

>
>
> Which resolution are you planning to capture?
>


I was just trying to capture the whole desktop. (1920*1200)
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Extracting I P B frames from a mpg video

[Rohit]

Thank you so much
Moritz Barsnick... You made my day... God bless you...That worked great for
me...

M S Rohit B.E, M.Tech,
Assistant Professor,
Dept of Computer Science & Engineering,
Jain Institute of Technology,
Davanagere.
9663861707

On Mon, Jan 5, 2015 at 3:54 PM, Moritz Barsnick [via FFmpeg-users] <
ml-node+s933282n4668752...@n4.nabble.com> wrote:

> Hi Rohit,
>
> On Sun, Jan 04, 2015 at 23:46:26 -0800, Rohit wrote:
> > ffmpeg -i delta.mpg -vf select="eq(pict_type\,PICT_TYPE_I)" -s 400x300
> -f image2 frame.mpg-%03d.tif
>
> You should always show us the complete, uncut output of your command.
>
> > which should extract all the I frames(as per -vf
> > select="eq(pict_type\,PICT_TYPE_I)" ) in the input file. But I got 197
> > frames instead of 17 from this command and it looked like command has
> just
> > shown me all the frames.
>
> There's a Wiki entry covering this:
>
> https://trac.ffmpeg.org/wiki/Create%20a%20thumbnail%20image%20every%20X%20seconds%20of%20the%20video
>
> And though it doesn't explain why, it does hint that you need to use:
> -vsync vfr
>
> This works for me.
>
> I believe the image2 muxer automatically assumes the same frame rate as
> the input (i.e. automatically chooses "-vsync cfr"). Since you are
> dropping all none-I-frames, it interpolates the missing frames to
> produce the correct rate. BTW, I get less frames than the (my) source
> video, because the muxers stops creating output at the last input
> I-frame.
>
> Another BTW: The value PICT_TYPE_I, which is also used in the Wiki
> entry, does not correspond to the documentation which says:
>
> > ‘pict_type (video only)’
> >
> > The type of the filtered frame. It can assume one of the following
> values:
> >
> > ‘I’
> > ‘P’
> > ‘B’
> > ‘S’
> > ‘SI’
> > ‘SP’
> > ‘BI’
>
> But the source (libavfilter/f_select.c) tells me that the prefix
> PICT_TYPE_ is also accepted.
>
> Moritz
> ___
> ffmpeg-user mailing list
> [hidden email] 
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
>
> --
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://ffmpeg-users.933282.n4.nabble.com/Extracting-I-P-B-frames-from-a-mpg-video-tp4668751p4668752.html
>  To unsubscribe from Extracting I P B frames from a mpg video, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://ffmpeg-users.933282.n4.nabble.com/Extracting-I-P-B-frames-from-a-mpg-video-tp4668751p4668755.html
Sent from the FFmpeg-users mailing list archive at Nabble.com.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] select scene and skip 2 seconds?

[Clément Bœsch]

On Mon, Jan 05, 2015 at 12:12:47PM +0100, Robert Nagy wrote:
> I want to generate some thumbnails for a video library.
> 
> Currently I'm using:
> 
> -frames:v 1 -filter:v "select=gt(scene\,0.5)" thumb.png
> 
> Which almost works. The problem is that I'd like the thumbnail to be taken
> 2 seconds after the scene change have been detected.
> 
> Is there a way to achieve that?

With two steps, and a bit ugly, but you can do something like this:

  eval $(ffprobe -v error -select_streams v:0 -show_entries 
frame=best_effort_timestamp_time -of flat=s=_ -f lavfi 
"movie=in.mov,scale=640:-1,select='gt(scene,0.5)',trim=end_frame=1")

And then something like:
  ffmpeg -i in.mov -ss $[$frames_frame_0_best_effort_timestamp_time+2] 
-frames:v 1 thumb.png

(note: this last command will only work with a shell that supports float
arithmetic.)

-- 
Clément B.


pgpkv5mze0HI0.pgp
Description: PGP signature
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[FFmpeg-user] select scene and skip 2 seconds?

[Robert Nagy]

I want to generate some thumbnails for a video library.

Currently I'm using:

-frames:v 1 -filter:v "select=gt(scene\,0.5)" thumb.png

Which almost works. The problem is that I'd like the thumbnail to be taken
2 seconds after the scene change have been detected.

Is there a way to achieve that?
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Extracting I P B frames from a mpg video

[Moritz Barsnick]

Hi Rohit,

On Sun, Jan 04, 2015 at 23:46:26 -0800, Rohit wrote:
> ffmpeg -i delta.mpg -vf select="eq(pict_type\,PICT_TYPE_I)" -s 400x300 -f 
> image2 frame.mpg-%03d.tif

You should always show us the complete, uncut output of your command.

> which should extract all the I frames(as per -vf
> select="eq(pict_type\,PICT_TYPE_I)" ) in the input file. But I got 197
> frames instead of 17 from this command and it looked like command has just
> shown me all the frames.

There's a Wiki entry covering this:
https://trac.ffmpeg.org/wiki/Create%20a%20thumbnail%20image%20every%20X%20seconds%20of%20the%20video

And though it doesn't explain why, it does hint that you need to use:
-vsync vfr

This works for me.

I believe the image2 muxer automatically assumes the same frame rate as
the input (i.e. automatically chooses "-vsync cfr"). Since you are
dropping all none-I-frames, it interpolates the missing frames to
produce the correct rate. BTW, I get less frames than the (my) source
video, because the muxers stops creating output at the last input
I-frame.

Another BTW: The value PICT_TYPE_I, which is also used in the Wiki
entry, does not correspond to the documentation which says:

> ‘pict_type (video only)’
>
> The type of the filtered frame. It can assume one of the following values:
>
> ‘I’
> ‘P’
> ‘B’
> ‘S’
> ‘SI’
> ‘SP’
> ‘BI’

But the source (libavfilter/f_select.c) tells me that the prefix
PICT_TYPE_ is also accepted.

Moritz
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user