Re: [FFmpeg-user] Meaning of ffprobe output

2019-01-29 Thread Eric Wilde

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 additionally a
> corrupted vob stream, which is detected and forbidden to copy by
> legal DVD copy software.

This seems far fetched ("weit hergeholt"), at least in terms of
creating mixed progressive/interlaced content. Broken file systems and
streams: Yes, often.


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 sync pulses and the
picture would appear scrambled.

I'm not sure how a DVD recorder would detect this, as opposed to a
VHS recording that was just of poor quality.  But, if you suspect that
to be the case, you could certainly confirm it with a scope on the
output of the VHS player.  For reference, a VHS tape of good quality
should give you typical voltage levels.

   Eric


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

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Keeping A/V sync during telecine

2017-12-31 Thread Eric Wilde

At 06:14 PM 12/30/2017 +, Phil Rhodes wrote:
Ordinarily, one would assume that a file marked as being 29.97fps should 
be played at 24000/1001fps.


I can give you all kinds of examples of video content that switches
frame rates on the fly, often back and forth.  Typically, one sees
the beginning segment (i.e. the titles) in one frame rate and then
the actual content switches to another.  At the end, the frame rate
switches back (i.e. the credits).

I even have a set of DVDs with NTSC content on them that were sold
in the UK.  They are marked as PAL.  The first few frames are PAL
and then the content switches to NTSC.  I'm guessing that nobody at
the DVD producer was crazy enough to attempt scan converting it.
I'm not sure how a European DVD player handles the switch but any of
the video players that I use (e.g. mplayer, vlc) handle it and all
of the frame rate changes just fine (not to mention the frame size
changes).  Plus, ffmpeg was sure able to process this content and
anything else that has frame rate changes -- with no loss of audio
sync.

Telecine, in my opinion, was just somebody's misguided attempt to
turn film into video, with a standard frame rate.  Maybe at the
time, it was necessary.  But, given that video players seem to be
perfectly capable of switching frame rates on the fly, a rather
pointless exercise.  Not to mention a complete pain for anyone who
is trying to "fix" such a video at this moment in time.

Eric


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

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] 2 pass CBR or VBR not really fixing the bitrate?

2017-07-29 Thread Eric Wilde

At 12:37 AM 7/30/2017 +0200, Moritz Barsnick wrote:

Are you talking audio? Yes, libmp3lame hits the target bitrate (be it
ABR or CBR) pretty much spot on. But Manuel obviously asked about
video:


Yes, you're right.  I completely missed that, since CBR makes no sense
to me, for video.  As you said, the goal of two pass encoding is to hit
an average bitrate -- which ffmpeg does quite well.

I'm not sure why you'd try to force the codec to have no variations
from the average bit rate because that's not how it works.  Lower bit
counts on frames that don't need a lot of bits (e.g. all black) make
up for higher bit counts on frames that do need a lot of bits (e.g.
motion).  The first pass basically encodes the frames with no limits
and writes their bit counts to the pass file.  The second pass can
then alter how much more it compresses high bit count frames (than the
first pass did) so that it hits the target bit rate.  The average is
all that matters.

But, I'm stating the obvious.  And, I'm probably still missing the
point.  So, I'll clam up and let wiser souls jump in.

   Eric


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

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] 2 pass CBR or VBR not really fixing the bitrate?

2017-07-29 Thread Eric Wilde

At 10:51 PM 7/29/2017 +0200, Moritz Barsnick wrote:

Have you tried using the identical video encoding settings for pass 1
and pass 2? I seem to recall that that is important.


Interesting that you say that.  I use "-an" for the first pass and then
"-codec:a libmp3lame -b:a 128k" for the second pass when doing two-pass
recording, and it works fine.  My impression was that audio was
irrelevant for the first pass, since you were only building a set of
compression guide data for the video compressor to use in pass two.

> Can anyone post an example of a case in which ffmpeg really gets CBR or 
say 110% VBR?


I can't, but I can point out that ffmpeg mostly does ABR, not CBR.


The parameters above work for me.  I tried VBR and could never get audio
that was synchronized properly with the video, using LAME.  Since 128k,
CBR gives acceptable sound, to my ear, and good compression, I wasn't
about to lose sleep over it.  There's too many other reasons why the
audio doesn't synchronize with the video.  I didn't need a self-inflicted
one.

The bitrate is pegged at 128 Kbps (according to MediaInfo) with this set
of parameters.

 Eric


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

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Quick (I hope) CLI question

2017-07-24 Thread Eric Wilde

At 04:24 PM 7/24/2017 -0400, you wrote:

I want to preserve formatting for audio and video and apply
normalization to the audio - in batch. Surely there must be a way to script
this.




Here's the code that I use for both boosting and companding.  If $Compressor
is 1, it makes up parameters for mencoder.  If $Compressor is not 1, it
makes up parameters for ffmpeg.

#
# If the user wants the input volume boosted by a fixed amount, just set
# the boost volume to that amount.
#
if [ ${FixedBoost} -ne 0 ]; then
BoostVol=${FixedBoost}
#
# Otherwise, if the user wants the input volume boosted so that the peak is
# near 0dB, we need to figure out how much boost is necessary.
#
else
#
# Note that we must use ffmpeg to detect the volume of the input file
# because ffprobe doesn't offer this feature.  So, even if the
# compressor being used is mencoder, ffmpeg is still required to use
# this feature.  Also, we look at the first 300 seconds (five minutes)
# of the input file to get an accurate picture of the maximum volume.
# This takes about 20-30 seconds but gives a much better idea of what
# the maximum volume really is.
#
# Once we have a boost volume amount, we can apply it with the volume
# filter
#
if [[ ${AudioBoost} -ne 0 && -x ${CompressFFMpeg} ]]; then
BoostVol=`${CompressFFMpeg} -i $2 -af "volumedetect" -to 300 
-nostats -f null -y /dev/null 2>&1 | grep -e '^\\[Parsed.*max_volume' | sed 
's/^.*max_volume:\\s-\\([0-9\\.]*\\).*$/\\1/g'`


BoostTrue=`echo "${BoostVol} > 1" | bc`
if [ ${BoostTrue} -ne 0 ]; then
BoostVol=`echo "scale=1; ${BoostVol} - 1" | bc`
else
BoostVol=0
fi
else
BoostVol=0
fi
fi
 .
 .
 .
#
# If we are boosting the audio, set the audio filter to boost it by the
# amount that we pre-calculated.  Note that this has no effect on dynamic
# range, it just makes everything louder.
#
BoostTrue=`echo "${BoostVol} > 0" | bc`
if [ $BoostTrue -ne 0 ]; then
if [ $Compressor == 1 ]; then
AudioFilter="-af volume=+${BoostVol}dB"
else
AudioFilter="-af volume=${BoostVol}dB"
fi
fi
#
# If we are normalizing the audio, set the audio filter to lessen the
# dynamic range.
#
# For mencoder, the volume normalization filter seems to work well (having
# tried it on quite a bit of recorded TV, which has much too high dynamic
# range in many cases).
#
# For ffmpeg, the compand filter with the parameters shown seems to work
# well also.  Here's the note from tugshank at forum.videohelp.com:
#
#  -af "aformat=channel_layouts=stereo,
#compand=0 0:1 1:-90/-900 -70/-70 -30/-9 0/-3:6:0:0:0"
#
#  channel_layouts=stereo forces mono to stereo, just in case
#
#  compander (compressor/expander):
#
#   attack - 0
#   release - 1
#   -90 dB in, infinity out
#   -70 dB in, -70 dB out
#   -30 dB in, -9 dB out
#   0 dB in, -3 dB out,
#   soft knee 6
#   0 dB makeup gain
#   input level 0 dB
#   lookahead 0.
#
#  Specifically made for 'whisper+explosion' scenes.
#
# For publishing video, EBU R128 is currently the preferred standard.  To
# use EBU R128, one must build ffmpeg with libebur128.  Normally, this
# isn't the default so you must use "--enable-libebur128" when you run
# configure.  Then, the "loudnorm" audio filter can be used, as in
# "-af loudnorm".  To figure out if loudnorm is available, use the
# following:
#
#  ffmpeg -filters 2>/dev/null | grep loudnorm
#
if [ ${AudioNorm} -ne 0 ]; then
if [ $Compressor == 1 ]; then
AudioFilter="-af volnorm=2:0.75"
else
AudioFilter="-af \"aformat=channel_layouts=stereo,compand=0 0:1 
1:-90/-900 -70/-70 -30/-9 0/-3:6:0:0:0\""

fi
fi


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

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Seeking for a method to remove sections of a video

2017-06-19 Thread Eric Wilde

At 05:24 PM 6/19/2017 +0200, you wrote:

On Mon, Jun 19, 2017 at 17:28:06 +0300, anat...@kazanfieldhockey.ru wrote:
> Do you know that mplayer has -edlout option:
> -edlout  (EDL only)
>  Creates a new file and writes edit decision list (EDL) records to that
> file.

Recently (Sep 19, 2016), ffmpeg gained support for MP4 (or MOV?) "edit
lists". I.e. ffmpeg will take those into consideration when
transcoding. I haven't yet found a tool though which creates those edit
lists - that tool would be helpful for you (the original poster).


This is good news.  I have never been able to get the EDL feature of
mencoder to work.  The cuts are either too early or too late, when
applied to the original material that they were derived from.  If,
after endless fiddling with them (i.e. change the offset and
re-encode the input file, which is swell when it's an hour or two
long video), you finally get the cuts in the right place, the sound
is broken.

I spent a lot of time on this and finally gave up.

Not only that, but if you use mplayer to try to build the EDL, it is
like trying to swat a fly with a sledge hammer.  There is no way to
accurately position the cut to within a frame, here or there, so it's
just the luck of the draw.

Currently, since nothing works on Linux, I transcode the original
MPEG stream to an AVI stream using ffmpeg and then edit it on Windoze
using VirtualDub.  I know that this means re-encoding it twice, since
the cuts invariably never fall on a key frame, but Virtual Dub's
MPEG2 converter seems to lose it on large recorded videos such as an
hour's worth of HiDef TV (although it works fine for MPEG2 from
DVDs).  So, not the most optimal of solutions but this is the only
one I've found to be workable and reliable, so far.

It would be great if you figured out a better solution.

 Eric


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

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] VOBs With Different Audio Delays

2016-08-13 Thread Eric Wilde

There exists a class of DVD files that have multiple VOB files within them,
that are encoded with different audio stream delays.  Now, it may be that
this is done intentionally, in order to make ripping of these DVDs
difficult, but I am more of the opinion that incompetence is the likely
cause.  My main reason for thinking this is that these files are often
found in DVD sets that contain multiple episodes and the broken files
typically comprise only a few episodes, with all of the others being OK.

Be that as it may, these files play fine with whatever player you choose
to use, if the VOB files are played sequentially, one file after another
(i.e. what takes place when your favorite player opens the DVD itself or an
ISO image of it).

However, problems abound when one tries to convert or compress these files
using ffmpeg.  Picture this.  The first VOB requires an audio delay of
500ms (about 15 frames at the typical frame rate) for the audio and video
to sync properly.  However, the second VOB requires no audio delay.

If you process the two VOBs concatenated together and supply a 500ms delay,
the first half of the resultant file plays in sync, while the second half
does not.  If you conversely process the two VOBs concatenated together and
supply no delay, the first half of the resultant file plays out of sync,
while the second is in sync.

Processing the two VOBs separately and supplying a 500ms delay for the
first and no delay for the second produces two resultant files that will
play perfectly on their own but are once again broken when concatenated
together.

The less-than-obvious solution is to rip the audio track off the first VOB,
use some audio editor to insert 500ms (15 frames) of emptiness (i.e. no
sound) and then recombine the sound with the VOB as it is processed to
produce an output file with 15 frames of hard audio delay.  When this
separately-produced resultant file is concatenated with a separately-
produced file from the second VOB, one gets a file that is synched for its
entire length.

In other words, it is possible to fix the problem.  But, my opinion of
tools is that they should be designed to solve problems, not make three
new ones in the process (i.e. splitting audio/video; editing audio;
recombining audio/video -- or four, if you include processing the two
VOBs separately).

It would be so simple for ffmpeg to just bang 15 empty audio frames over
to the audio compressor before it started processing the actual audio
stream, thereby creating the hard offset.  If the audio were out of sync
the other way, it would be likewise simple for ffmpeg to bang 15 frames of
blank video over to the video compressor before it started processing the
actual video stream, thereby creating a hard delay.  Then, when the second
VOB was processed, everything would go together smoothly.

Does anybody know of a command line option to do this (I may have missed
it in my search for a solution)?  Or, what do we think about making this an
enhancement request?

Note that I have never seen a set of VOBs that are broken in any way other
than what I've described (i.e. some amount of non-zero audio delay for the
first VOB and a zero audio delay for the second).  In fact, one could
postulate that VOBs that were broken in any manner other than a fixed audio
delay on the first VOB would not play properly under any circumstances and
would have to be fixed by the DVD creator.  This leads me to believe that
there is only one problem to solve here and it is that of inserting 1 to n
empty audio frames at the beginning of the output stream.

Thanks for your consideration.

 Eric

Sent from my   Oh, wait, my dog has both my gold iWatches.


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

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".