2019-03-11 19:53 GMT+01:00, Ulf Zibis :
>
> Am 11.03.19 um 11:58 schrieb Carl Eugen Hoyos:
>>> Is native vs. x264 encoder something different?
>> The native (FFmpeg-internal) encoders may be a little less
>> sophisticated than x264 (and they don't know a special
>> adaptive interlaced setting
Am 11.03.19 um 11:58 schrieb Carl Eugen Hoyos:
> So our suspicion after visual inspection was right.
Yes, indeed.
>> So I buyed the DVD now. Except that it has 3 audio tracks to choose and
>> the VHS head switching artefacts are missing, it unfortunately has the
>> equal bad quality than my DVD
2019-02-21 11:31 GMT+01:00, Ulf Zibis :
>
> Am 21.02.19 um 01:41 schrieb Carl Eugen Hoyos:
>> 2019-02-04 23:29 GMT+01:00, Ulf Zibis :
>>> Now I've checked the files with mediainfo:
>>> - The vob file is stated as interlaced top first. (I know, this does
>>> nothing say about the content, only the
Am 21.02.19 um 01:41 schrieb Carl Eugen Hoyos:
> 2019-02-04 23:29 GMT+01:00, Ulf Zibis :
>> Now I've checked the files with mediainfo:
>> - The vob file is stated as interlaced top first. (I know, this does
>> nothing say about the content, only the flag is evaluated.)
> Doesn't FFmpeg also
2019-02-04 23:29 GMT+01:00, Ulf Zibis :
>
> Am 04.02.19 um 01:00 schrieb Carl Eugen Hoyos:
>> 2019-02-03 21:16 GMT+01:00, Ulf Zibis :
>>> Am 03.02.19 um 21:06 schrieb Carl Zwanzig:
It's a shortening of "Top Field First" (TFF). With interlaced video
you have a choice of whether the top or
Am 04.02.19 um 01:00 schrieb Carl Eugen Hoyos:
> 2019-02-03 21:16 GMT+01:00, Ulf Zibis :
>> Am 03.02.19 um 21:06 schrieb Carl Zwanzig:
>>> It's a shortening of "Top Field First" (TFF). With interlaced video
>>> you have a choice of whether the top or bottom field (odd numbered
>>> lines/even
2019-02-03 21:16 GMT+01:00, Ulf Zibis :
>
> Am 03.02.19 um 21:06 schrieb Carl Zwanzig:
>> It's a shortening of "Top Field First" (TFF). With interlaced video
>> you have a choice of whether the top or bottom field (odd numbered
>> lines/even numbered lines) comes before the other in the digital
Ulf Zibis wrote:
>Does the 'p' in yuv420p mean "progressive"?
No, it means "planar". Best regards, Reto
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
Am 03.02.19 um 21:06 schrieb Carl Zwanzig:
> It's a shortening of "Top Field First" (TFF). With interlaced video
> you have a choice of whether the top or bottom field (odd numbered
> lines/even numbered lines) comes before the other in the digital stream.
I know this, but Carl Eugen said, that
Am 03.02.19 um 16:52 schrieb Ulf Zibis:
> Hi Carl Eugen,
>
> For me it's ok to close that discussion here. You did a lot of effort to
> explain me many details, much thanks for that. I can live with the
> remaining unclarity.
But could you please tell me the meaning of "top first" in ffprobe
On 2/3/2019 11:58 AM, Ulf Zibis wrote:
But could you please tell me the meaning of "top first" in ffprobe
output of the vob file, which is missing after transcoding to mp4.
It's a shortening of "Top Field First" (TFF). With interlaced video you have
a choice of whether the top or bottom field
Am 03.02.19 um 17:17 schrieb Carl Eugen Hoyos:
> They do not look like comb artefacts as caused by interlaced
> recording to me.
Thanks, here I respect your experience with video material I don't have.
But these artefacts must have to do with horizontal motion, as they
don't appear in "normal"
2019-02-03 11:58 GMT+01:00, Ulf Zibis :
>
> Am 01.02.19 um 20:00 schrieb Carl Eugen Hoyos:
>>> But for the rest of the video, I'm wondering that I nowhere notice such
>>> dropouts. IIRC I read, that the film was produced with a budget of
>>> 20.000 DM, which IMHO is not enough for a 76 min.
Am 03.02.19 um 16:47 schrieb Carl Eugen Hoyos:
> 2019-02-03 16:31 GMT+01:00, Ulf Zibis :
>
>> Also I'm missing even few celluloid dropouts in the whole video.
> But this does not rule out progressive digital video.
There was no digital video in 1982.
-Ulf
Hi Carl Eugen,
Am 03.02.19 um 14:06 schrieb Carl Eugen Hoyos:
>>> Second:
>>> libx264 does support interlaced encoding (but not field
> (It appears as if you didn't read this sentence: It does not
> mean "you can feed anything into libx264, it will somehow
> deal with it", it means "libx264 does
2019-02-03 16:31 GMT+01:00, Ulf Zibis :
> Also I'm missing even few celluloid dropouts in the whole video.
But this does not rule out progressive digital video.
Carl Eugen
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
Am 03.02.19 um 13:56 schrieb Carl Eugen Hoyos:
>> Otherwise I can't explain the comb artefacts at some
>> areas.
> I don't really see them, I see many artefacts.
I have marked what I interpret as comb artefacts in the attachment.
Also I'm missing even few celluloid dropouts in the whole video.
2019-02-02 21:22 GMT+01:00, Ulf Zibis :
>
> Am 02.02.19 um 02:18 schrieb Carl Eugen Hoyos:
>> Second:
>> libx264 does support interlaced encoding (but not field
(It appears as if you didn't read this sentence: It does not
mean "you can feed anything into libx264, it will somehow
deal with it",
2019-02-02 20:32 GMT+01:00, Ulf Zibis :
>
> Am 02.02.19 um 19:27 schrieb Ulf Zibis:
>> But if I have a interlaced encoded stream with interlaced content, I
>> guess only both steps at same time ensure to get a progressive stream
>> with good visual quality.
>
> For this case I see 2 options.
2019-02-02 19:27 GMT+01:00, Ulf Zibis :
>
> Am 02.02.19 um 18:38 schrieb Carl Eugen Hoyos:
>> 2019-02-01 23:46 GMT+01:00, Ulf Zibis :
>>> Am 30.01.19 um 15:08 schrieb Carl Eugen Hoyos:
Without interpolation, this is what all video players do if you disable
all de-interlacing.
The
2019-02-03 11:58 GMT+01:00, Ulf Zibis :
>
> Am 01.02.19 um 20:00 schrieb Carl Eugen Hoyos:
>>> But for the rest of the video, I'm wondering that I nowhere notice such
>>> dropouts. IIRC I read, that the film was produced with a budget of
>>> 20.000 DM, which IMHO is not enough for a 76 min.
Am 01.02.19 um 20:00 schrieb Carl Eugen Hoyos:
>> But for the rest of the video, I'm wondering that I nowhere notice such
>> dropouts. IIRC I read, that the film was produced with a budget of
>> 20.000 DM, which IMHO is not enough for a 76 min. celluloid film.
>>
>> Additionally in the turning
Am 11.01.19 um 01:47 schrieb Carl Eugen Hoyos:
> 2019-01-11 0:39 GMT+01:00, Ulf Zibis :
>
>> can anybody explain me the data of ffprobe, I don't find enough hints in
>> the docu. E.g.:
>> $ ffprobe CYD_copy.vob
>> Input #0, mpeg, from 'CYD_copy.vob':
>> Duration: 01:16:20.74, start: 0.50,
Hi Moritz,
Am 02.02.19 um 22:29 schrieb Moritz Barsnick:
> You can always "up-convert" your colorspace before cropping, and
> "down-convert" afterwards:
> $ ffmpeg [...] -vf format=yuv444p,crop=h=1:...,format=yuv420p [...]
> or something like this.
Much thank for this hack ... it works!
For the
On Sat, Feb 02, 2019 at 21:22:03 +0100, Ulf Zibis wrote:
> Does that mean, it makes *sense to file a bug* to have single line
> processing with crop in the future? I would burn for that.
You can always "up-convert" your colorspace before cropping, and
"down-convert" afterwards:
$ ffmpeg [...] -vf
Am 02.02.19 um 02:18 schrieb Carl Eugen Hoyos:
>> I meant, if libx264 does a re-encoding from interlaced
>> encoding to progressive encoding?
> libx264 does not encode "from interlaced encoding"
> because it cannot know if the source was encoded
> interlaced or progressive.
With "interlaced
Am 02.02.19 um 19:27 schrieb Ulf Zibis:
> But if I have a interlaced encoded stream with interlaced content, I
> guess only both steps at same time ensure to get a progressive stream
> with good visual quality.
For this case I see 2 options. Assume we have a 25 fps top first
interlaced encoded
Am 02.02.19 um 18:38 schrieb Carl Eugen Hoyos:
> 2019-02-01 23:46 GMT+01:00, Ulf Zibis :
>> Am 30.01.19 um 15:08 schrieb Carl Eugen Hoyos:
>>> Without interpolation, this is what all video players do if you disable
>>> all de-interlacing.
>>> The problem is what kind of "interpolation" you use,
2019-02-01 23:46 GMT+01:00, Ulf Zibis :
>
> Am 30.01.19 um 15:08 schrieb Carl Eugen Hoyos:
>> Without interpolation, this is what all video players do if you disable
>> all de-interlacing.
>> The problem is what kind of "interpolation" you use, this is called
>> de-interlacing, an endless number
Sorry for top posting, I can’t figure out how to preserve the formatting while
editing from the bottom with this Yahoo Mail mobile editor...
“OK, my understandig was, "de-interlacing" means to re-encode from
interlaced to progressive _and_ do some interpolation or whatever stuff.”
Not entirely
2019-02-02 0:43 GMT+01:00, Ulf Zibis :
>
> Am 01.02.19 um 23:25 schrieb Carl Eugen Hoyos:
>> 2019-02-01 23:14 GMT+01:00, Ulf Zibis :
>>> So now I understand (hopefully). My main interest was is to know,
>>> if my video is _encoded_ interlaced or not, and I still don't know it :-(
>> Debugging
Am 01.02.19 um 20:00 schrieb Carl Eugen Hoyos:
> Yes, this is correct, yadif is able to nicely remove the interlace
> artefacts but I believe it leads to even more distortions in the
> rest of the video.
This matches to my experience. The best result I got was simply using
the atadenoise filter.
Am 01.02.19 um 23:25 schrieb Carl Eugen Hoyos:
> 2019-02-01 23:14 GMT+01:00, Ulf Zibis :
>> So now I understand (hopefully). My main interest was is to know,
>> if my video is _encoded_ interlaced or not, and I still don't know it :-(
> Debugging mpegvideo.c shows the video is encoded interlaced.
Am 30.01.19 um 15:08 schrieb Carl Eugen Hoyos:
> Without interpolation, this is what all video players do if you disable
> all de-interlacing.
> The problem is what kind of "interpolation" you use, this is called
> de-interlacing, an endless number of algorithms exist.
OK, my understandig was,
2019-02-01 23:14 GMT+01:00, Ulf Zibis :
> Am 31.01.19 um 13:48 schrieb Carl Eugen Hoyos:
>> DVD recorders can only produce interlaced files if the input
>> was interlaced, in this specific case, a file with progressive
>> content was produced (from progressive original).
>>
>> (Above of course
Hi,
again to my initial question ...
Am 31.01.19 um 13:48 schrieb Carl Eugen Hoyos:
> DVD recorders can only produce interlaced files if the input
> was interlaced, in this specific case, a file with progressive
> content was produced (from progressive original).
>
> (Above of course only
2019-02-01 19:40 GMT+01:00, Ulf Zibis :
> Am 31.01.19 um 00:18 schrieb Carl Eugen Hoyos:
>> This masterpiece (make sure you don't miss the imdb comment)
>> was most likely made with a film camera that knew nothing about
>> interlacing.
>
> I'm sure this is true at least for the opening credits,
Hi again,
Am 31.01.19 um 00:18 schrieb Carl Eugen Hoyos:
> This masterpiece (make sure you don't miss the imdb comment)
> was most likely made with a film camera that knew nothing about
> interlacing.
I'm sure this is true at least for the opening credits, as there are
flashing dropouts, typical
2019-01-31 6:46 GMT+01:00, Carl Zwanzig :
> On 1/30/2019 12:23 PM, Carl Eugen Hoyos wrote:
>> this is not about the "signal" that is of
>> course interlaced for analog PAL but the content that
>> may of may not be interlaced (and the idet filter only
>> looks at the content and nothing in FFmpeg
On 1/30/2019 12:23 PM, Carl Eugen Hoyos wrote:
this is not about the "signal" that is of
course interlaced for analog PAL but the content that
may of may not be interlaced (and the idet filter only
looks at the content and nothing in FFmpeg is able to
look at an analog video signal).
Agreed.
2019-01-31 0:20 GMT+01:00, Lou Logan :
> On Mon, Jan 28, 2019, at 6:58 PM, Carl Eugen Hoyos wrote:
>>
>> (So apparently the next sentence is wrong and Lou
>> does offer release support - but unfortunately only
>> to you because he closed ticket #7697 this week
>> explaining there is no release
2019-01-31 0:18 GMT+01:00, Carl Eugen Hoyos :
> 2019-01-30 23:55 GMT+01:00, Ulf Zibis :
>
>> here you find the rip from dvd::rip and the result from ffmpeg:
>> https://c.1und1.de/@519472591769967166/-XGssZrBRCiT0J4xQUU1LA
>
> This masterpiece (make sure you don't miss the imdb comment)
> was most
On Mon, Jan 28, 2019, at 6:58 PM, Carl Eugen Hoyos wrote:
>
> (So apparently the next sentence is wrong and Lou
> does offer release support - but unfortunately only
> to you because he closed ticket #7697 this week
> explaining there is no release support...)
I don't quite follow your paragraph,
2019-01-30 23:55 GMT+01:00, Ulf Zibis :
> here you find the rip from dvd::rip and the result from ffmpeg:
> https://c.1und1.de/@519472591769967166/-XGssZrBRCiT0J4xQUU1LA
This masterpiece (make sure you don't miss the imdb comment)
was most likely made with a film camera that knew nothing about
Hi,
here you find the rip from dvd::rip and the result from ffmpeg:
https://c.1und1.de/@519472591769967166/-XGssZrBRCiT0J4xQUU1LA
I'm curious, what you find out,
Ulf
Am 29.01.19 um 21:47 schrieb Carl Eugen Hoyos:
> 2019-01-29 20:50 GMT+01:00, Ulf Zibis :
>> If you want I could upload a 6 min.
2019-01-30 18:27 GMT+01:00, Carl Zwanzig :
> On 1/30/2019 6:12 AM, Carl Eugen Hoyos wrote:
>> You may have forgotten that while the vertical resolution is kept,
>> horizontal resolution is reduced significantly for VHS, likely
>> confusing the algorithm for detection of interlaced content.
>
>
On 1/30/2019 6:12 AM, Carl Eugen Hoyos wrote:
You may have forgotten that while the vertical resolution is kept,
horizontal resolution is reduced significantly for VHS, likely
confusing the algorithm for detection of interlaced content.
Exactly, VHS only has bandwidth of ~3MHz, so a horizontal
2019-01-29 20:50 GMT+01:00, Ulf Zibis :
> My understanding is, that a VHS cassette player always
> provides a fully interlaced analogue stream (50 half-frames
> per sec. for PAL).
You may have forgotten that while the vertical resolution is kept,
horizontal resolution is reduced significantly
2019-01-30 1:26 GMT+01:00, Ulf Zibis :
> In my POV deinterlacing ("classic") is to buffer and optionally somehow
> interpolate the content of the "before half-frame" and add it to the
> current half-frame, so the display content only changes *25 times per
> sec.*. But with the method I outlined,
Hi Carl Eugen,
Am 29.01.19 um 22:14 schrieb Carl Eugen Hoyos:
>
> Are you both sure that the DVD recorder is able to record something
> from analog signal that can be de-interlaced? I am curious...
Do you ask if it is possible/thinkable, that the resulting DVD contains
an already de-interlaced
Am 29.01.19 um 02:31 schrieb Ulf Zibis:
> Am 29.01.19 um 01:32 schrieb Moritz Barsnick:
>> On Mon, Jan 28, 2019 at 22:52:38 +0100, Ulf Zibis wrote:
LEDs and LCDs would give you headaches if they displayed alternating
lines, as the "afterglow" effect of CRTs, retaining the line's
Moin Moritz,
Am 29.01.19 um 21:48 schrieb Moritz Barsnick:
>> My explanation is, that the original VHS was marked with copy
>> protection, so the DVD recorder by legal reasons has to sustain the
>> copy protection by creating an intentionally corrupted DVD file
>> system (which is not readable
On 1/29/2019 1:16 PM, Eric Wilde wrote:
My understanding of at least one VHS protection scheme was to record
the video with the horizontal/vertical sync pulses set very low to the
threshold for detection. The idea was that, if you made a copy, which
was lossy, the copy would not have detectable
At 09:48 PM 1/29/2019 +0100, you wrote:
> My explanation is, that the original VHS was marked with copy
> protection, so the DVD recorder by legal reasons has to sustain the
> copy protection by creating an intentionally corrupted DVD file
> system (which is not readable from a computer) and
2019-01-29 21:48 GMT+01:00, Moritz Barsnick :
> Moin Ulf,
>
> On Tue, Jan 29, 2019 at 20:50:25 +0100, Ulf Zibis wrote:
>
>> My understanding is, that a VHS cassette player always provides a fully
>> interlaced analogue stream (50 half-frames per sec. for PAL).
>
> Originally coming from the analog
Moin Ulf,
On Tue, Jan 29, 2019 at 20:50:25 +0100, Ulf Zibis wrote:
> My understanding is, that a VHS cassette player always provides a fully
> interlaced analogue stream (50 half-frames per sec. for PAL).
Originally coming from the analog world, I can confirm that this is
true.
> With this a
2019-01-29 20:50 GMT+01:00, Ulf Zibis :
> If you want I could upload a 6 min. chunk with 300 MB.
Just post a link, there are issues with 10G samples
(that could not easily be made smaller).
Carl Eugen
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
Hi Carl Eugen,
thanks again for your patience.
Am 29.01.19 um 04:58 schrieb Carl Eugen Hoyos:
>
> (So apparently the next sentence is wrong and Lou
> does offer release support - but unfortunately only
> to you because he closed ticket #7697 this week
> explaining there is no release support...)
2019-01-29 2:16 GMT+01:00, Ulf Zibis :
> Hi Carl Eugen,
>
> Am 19.01.19 um 14:02 schrieb Carl Eugen Hoyos:
>>> $ ffmpeg -i CYD_copy.vob -vf idet -f null -
>>> ffmpeg version 4.1-static https://johnvansickle.com/ffmpeg/ Copyright
>> Not supported here!
>>
>>> (c) 2000-2018 the FFmpeg developers
Am 29.01.19 um 01:32 schrieb Moritz Barsnick:
> On Mon, Jan 28, 2019 at 22:52:38 +0100, Ulf Zibis wrote:
>>> LEDs and LCDs would give you headaches if they displayed alternating lines,
>>> as the "afterglow" effect of CRTs, retaining the line's content, is not
>>> present.
>> If each 2nd line
Hi Carl Eugen,
Am 19.01.19 um 14:02 schrieb Carl Eugen Hoyos:
>> $ ffmpeg -i CYD_copy.vob -vf idet -f null -
>> ffmpeg version 4.1-static https://johnvansickle.com/ffmpeg/ Copyright
> Not supported here!
>
>> (c) 2000-2018 the FFmpeg developers
>> built with gcc 6.3.0 (Debian 6.3.0-18+deb9u1)
On Mon, Jan 28, 2019 at 22:52:38 +0100, Ulf Zibis wrote:
> > LEDs and LCDs would give you headaches if they displayed alternating lines,
> > as the "afterglow" effect of CRTs, retaining the line's content, is not
> > present.
>
> If each 2nd line would be empty (black) you may be right, but if
Am 19.01.19 um 23:29 schrieb Carl Eugen Hoyos:
> (I don't see this email)
What you mean by that?
> This deinterlacing method is called "weave", this is not what CRT's
> do (as Moritz explained), most people do not like the results.
> (Although some do!)
This method results in a 25 fps stream,
Am 19.01.19 um 17:30 schrieb Moritz Barsnick:
>> Well, but the software player could send 50 frames per second with
>> alternately updating only each 2nd top/bottom line.
> It could. But if the display is anything else than an old CRT, it will first
> deinterlace internally.
Why should it do
> On Fri, Jan 18, 2019 at 18:19:05 +0100, Ulf Zibis wrote:
>> > (It is simply not possible, you can only send frames to your
>> > driver / display.)
>> Well, but the software player could send 50 frames per second with
>> alternately updating only each 2nd top/bottom line.
(I don't see this
On Fri, Jan 18, 2019 at 18:19:05 +0100, Ulf Zibis wrote:
> > (It is simply not possible, you can only send frames to your
> > driver / display.)
> Well, but the software player could send 50 frames per second with
> alternately updating only each 2nd top/bottom line.
It could. But if the display
2019-01-18 18:19 GMT+01:00, Ulf Zibis :
> $ ffmpeg -i CYD_copy.vob -vf idet -f null -
> ffmpeg version 4.1-static https://johnvansickle.com/ffmpeg/ Copyright
Not supported here!
> (c) 2000-2018 the FFmpeg developers
> built with gcc 6.3.0 (Debian 6.3.0-18+deb9u1) 20170516
> [.]
Not ok!
Hi,
Am 18.01.19 um 16:44 schrieb Carl Eugen Hoyos:
> One possibility is to add "-f null -".
Thanks!
from the original dvd::rip chunks I get:
===
$ ffmpeg -i
Hi,
Am 18.01.19 um 16:44 schrieb Carl Eugen Hoyos:
>> You may be right. Technically I don't see an obstacle for a software
>> player to feed the video display buffer with 50 half-frames per second,
>> as most displays refresh rate is at least 50 per sec.
> I do though.
> (It is simply not
2019-01-18 15:58 GMT+01:00, Ulf Zibis :
> Am 15.01.19 um 12:54 schrieb Carl Eugen Hoyos:
>>> tbn
>> This is the container timebase, 90k for mpeg streams.
> For what stands 90k? For 90,000 milli seconds?
It stands for a timebase of 1/9
>>> Is it 1/9 second?
>> I suspect
Hi again,
Am 15.01.19 um 12:54 schrieb Carl Eugen Hoyos:
>> tbn
> This is the container timebase, 90k for mpeg streams.
For what stands 90k? For 90,000 milli seconds?
>>> It stands for a timebase of 1/9
>> Is it 1/9 second?
> I suspect timebase is a fraction and has no unit
2019-01-15 3:13 GMT+01:00, Ulf Zibis :
> Am 13.01.19 um 00:25 schrieb Carl Eugen Hoyos:
> tbn
This is the container timebase, 90k for mpeg streams.
>>> For what stands 90k? For 90,000 milli seconds?
>> It stands for a timebase of 1/9
>
> Is it 1/9 second?
I suspect timebase is a
Hi,
Am 13.01.19 um 00:25 schrieb Carl Eugen Hoyos:
tbn
>>> This is the container timebase, 90k for mpeg streams.
>> For what stands 90k? For 90,000 milli seconds?
> It stands for a timebase of 1/9
Is it 1/9 second?
> which is the timebase
> for all mpeg streams (and cannot be
2019-01-12 22:32 GMT+01:00, Ulf Zibis :
> Am 11.01.19 um 01:47 schrieb Carl Eugen Hoyos:
>> 2019-01-11 0:39 GMT+01:00, Ulf Zibis :
>>
>>> tbn
>> This is the container timebase, 90k for mpeg streams.
>
> For what stands 90k? For 90,000 milli seconds?
It stands for a timebase of 1/9 which is
Thanks Carl Eugen ...
Am 11.01.19 um 01:47 schrieb Carl Eugen Hoyos:
> 2019-01-11 0:39 GMT+01:00, Ulf Zibis :
>
>> tbn
> This is the container timebase, 90k for mpeg streams.
For what stands 90k? For 90,000 milli seconds?
>> -movflags +faststart -c copy CYD_copy.vob
> Sadly, output option
2019-01-11 0:39 GMT+01:00, Ulf Zibis :
> can anybody explain me the data of ffprobe, I don't find enough hints in
> the docu. E.g.:
> $ ffprobe CYD_copy.vob
> Input #0, mpeg, from 'CYD_copy.vob':
> Duration: 01:16:20.74, start: 0.50, bitrate: 7068 kb/s
> Stream #0:0[0x80]: Audio: ac3,
Hi,
can anybody explain me the data of ffprobe, I don't find enough hints in
the docu. E.g.:
$ ffprobe CYD_copy.vob
Input #0, mpeg, from 'CYD_copy.vob':
Duration: 01:16:20.74, start: 0.50, bitrate: 7068 kb/s
Stream #0:0[0x80]: Audio: ac3, 48000 Hz, stereo, fltp, 256 kb/s
Stream
77 matches
Mail list logo
