[FFmpeg-user] exact start/end extraction of an .mp4

[Tracey Jaquith]

On Sep 27, 2013, at 11:05 AM, Tracey Jaquith <tracey at archive.org> wrote:

> 
> On Sep 26, 2013, at 12:18 PM, tracey jaquith <tracey at archive.org> wrote:
> 
>> 
>> On Sep 26, 2013, at 3:12 AM, Tom Horsley <horsley1953 at gmail.com> wrote:
>> 
>>> On Wed, 25 Sep 2013 20:20:40 -0700
>>> tracey jaquith wrote:
>>> 
>>>> So start with a keyframe and GOP, but some metadata, let's say, way to instruct to a client/player "yes, but seek 2.7 seconds in to start playback", etc.
>>> 
>>> I have read that you can use -ss time before the -i inputfile
>>> to do the seek to keyframe, then -ss time again after the
>>> input file to seek to a frame exact time.
>>> 
>>> It never worked for me on screwy files with seemingly busted
>>> timing of some kind I fetched off my TiVo, but if you have
>>> clean files it would probably work for you.
>>> 
>> 
>> 
>> Thanks for the comments/feedback Tom!
>> 
>> Yes, like you, I'd previously found the results have been very unpredictable/spotty for me when using the -ss after and/or both before and after.
>> 
>> However, it *does* seem like from reading comments and posts, that if I peg the first seek (before arg) to a known keyframe time, and the 2nd "delta seek from there" (after arg), that I get reliable results.  The only thing I'm concerned with is I'm not sure how much video quality suffers from with that technique (in spot testing seems pretty close) after the first GOP is altered/output (because everything from the 2nd GOP and on can be logically copied (possible PTS changes I'd guess, but not video transcodes, etc.) I'm also not sure how efficient/fast  (imagine many minute clipping/extracts from a multi-hour video) this would be compared to mod_h264_streaming -- which seems *very* fast in practice.
>> 
>> 
>> So here's my altered "single ffmpeg pass" (in bash, where KEYFRAME1 and KEYFRAME2 are the times of known closest keyframes)
>> 
>> 	KEYFRAME1=465.221 
>> 	KEYFRAME2=471.561 
>> 	START=468 
>> 	let "END=$START+15"
>> 
>> 	START_IN=$(printf "%0.2f" $(echo $START-$KEYFRAME1)) 
>> 	DURATION=$(printf "%0.2f" $(echo $END-$START)) 
>> 
>> ffmpeg -y -ss $KEYFRAME1 -i *20*.mp4 -ss $START_IN -t $DURATION -c:a copy -movflags faststart _$(basename $(tempfile))-ffmpeg-single-pass.mp4
>> 
>> 
>> Anyone else think the 2nd GOP and on should be mostly fine, video-wise or have alternate suggestions?
>> -tracey
> 
> 
> Does anyone have an knowledge/experience or "do not enter" 8-) suggestions with setting "Selection Time" (+ "Selection Duration") in the "mvhd" mp4 atom, as well as a "SelO" atom inside a "udta" mp4 atom?
> I'm trying that now to see if I can set "seek X seconds in flag" to allow seeking midway through the first GOP (although not seeing any browser seek so far…)
> 
> (references:
> browser search "Selection Duration" from here:
> https://developer.apple.com/library/mac/documentation/QuickTime/qtff/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP40000939-CH204-32947
> 
> browser search "SelO" (as in "Selection Only") from here:
> https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP40000939-CH204-25538
> )
> 
> -tracey


The "Selection Duration" and "SelO" atoms, properly coded (best I can tell) seem to be ignored so I'm moving on...
Since I'm most interested in a "solution" for mod_h264_streaming (or a replacement to it) for this accurate start time seeking, I'm coming up with a patch to mod_h264_streaming that will:
determine frames in first GOP going "out the door" to web request that are unwanted
rewrite the moov atom (and on down) that mod_h264_streaming synthesizes to artificially make the undesired lead frames have incredibly small durations and PTS that are fractionally seconds off the desired "real start time"
do everything else as normal

In prototype, this is working as .mp4 clips in Safari, Chrome, and flash plugin for those browsers + Firefox, so I think I'm on the right track!    Thanks for listening, considering, and even the suggestions.  

I do think there is still some good cases for ffmpeg feature request to allow a new flag/arg, say, that recodes the first GOP to keyframe start at exact wanted start time and copy out the rest of the GOPs after that.  But that is up to ffmpeg community at large.

I'll github up the patch and if anyone's interested, reply and I can make it available, etc.

cheers,
-Tracey

PS: nice way to end the week 8-) -- this has been a *huge* issue for us for years and really wanted a solution ASAP for some feature rollouts coming to archive.org...