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. |
8th January 2019, 07:31 | #21 | Link | |
Registered User
Join Date: Dec 2018
Posts: 21
|
Quote:
So my output files (from the code I used in #14) for a UHD/HDR to HD/SDR are approximately 2-3GB in size. This is unusually low compared to the output files I get from Handbrake (HEVC/CRF18/Slow) with a normal HD Blu Ray rip (same file). Is FFmpeg compressing more heavily than Handbrake? Edit: also, I tried using the code you provided with no luck. CMD said it wasn't a command. Again, new to FFmpeg and trying to understand each command and its structure. Last edited by EmKayVe; 8th January 2019 at 18:01. |
|
22nd February 2019, 16:42 | #23 | Link | ||||
Registered User
Join Date: Mar 2006
Posts: 1,049
|
Quote:
Usually LFE is ignored during downmixing (Dolby recommendation - personally i think this is due high risk of over-ranging but sane amount of LFE should be fine). Personally i use private down-mix: for more than 5.1 to 5.1 scheme (critical feedback appreciated - didn't found anything on this topic - also Dolby documentation not very helpful) Quote:
Quote:
or quite interesting HRTF based downmixed (main intention is headphone listening for example on your portable audio device 7.1 to 2.0@HRTF: Quote:
Last edited by tebasuna51; 31st October 2019 at 11:03. |
||||
22nd February 2019, 16:50 | #24 | Link | |
Registered User
Join Date: Mar 2006
Posts: 1,049
|
Quote:
https://superuser.com/questions/1140...-existing-file However you may wish to add additional metadata info (for example language descriptor) about this sub. It can be done like this: Code:
-map 1? -c:s copy -metadata:s:s:0 language=eng |
|
22nd February 2019, 16:54 | #25 | Link | ||
Registered User
Join Date: Mar 2006
Posts: 1,049
|
Quote:
for example my command line (script) may look like this: Quote:
Last edited by tebasuna51; 31st October 2019 at 11:02. |
||
8th March 2019, 03:24 | #26 | Link | |
Registered User
Join Date: Dec 2018
Posts: 21
|
Thanks pandy, here is my code:
Quote:
Last edited by tebasuna51; 31st October 2019 at 11:01. |
|
30th October 2019, 20:09 | #27 | Link | |
Registered User
Join Date: Dec 2018
Posts: 21
|
I tried the following code which I added in the code for burning the 3rd English sub track. The code is invalid. Can anyone provide a fix?
Quote:
Last edited by tebasuna51; 31st October 2019 at 11:00. Reason: code -> quote |
|
30th October 2019, 20:41 | #28 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
You added "-map 3?" which should map all tracks from the 4th input file yet provided only a single input file ("-i G:\Videos\ffmpeg\video.mkv").
https://trac.ffmpeg.org/wiki/Map When you receive errors: post the (complete) log so we can read the error messages. |
31st October 2019, 09:57 | #29 | Link |
Registered User
Join Date: Oct 2001
Location: Germany
Posts: 7,259
|
Code:
-map 3? -c:s copy Code:
-c:s:2 copy -> best read the wiki sneaker linked to,... For 'burning in' subtitles instead of remuxing them you need to use a filter, see: https://trac.ffmpeg.org/wiki/HowToBu...itlesIntoVideo Last edited by Selur; 31st October 2019 at 10:00. |
31st October 2019, 12:08 | #30 | Link | |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
Quote:
Code:
-map 0:s:2 -c:s:0 copy https://ffmpeg.org/ffmpeg.html#Stream-specifiers-1 Last edited by sneaker_ger; 31st October 2019 at 12:10. |
|
4th January 2020, 21:56 | #32 | Link |
Registered User
Join Date: Dec 2018
Posts: 21
|
Please help me with this code. Here is what I'm trying to do. I want an ouput file at H265, SDR, 1080p, mp4, with both a AC3 audio and AAC audio track to choose from. Since it is MP4, the 3rd subtitle track has to be "burned" in. The file is an MKV, UHD Blu Ray rip with HDR.
Code:
ffmpeg.exe -i E:\ffmpeg\input.mkv -vf zscale=t=linear:npl=100,format=gbrpf32le,zscale=p=bt709,tonemap=tonemap=hable:desat=2,zscale=t=bt709:m=bt709:r=tv,format=yuv420p,zscale=s=1920x1080 -map 0:v:0 -map 0:a:0 -map 0:a:0 -c:a:0 ac3 -c:a:1 aac -ac:a:1 2 -c:v libx265 -crf 20 -preset slow E:\ffmpeg\output.mp4 Last edited by EmKayVe; 4th January 2020 at 22:09. Reason: Mistake |
11th January 2020, 01:05 | #33 | Link |
Registered User
Join Date: Feb 2009
Location: USA
Posts: 676
|
Can anyone give me a reason why I should not trust/rely on Frame types provided by ffprobe? I have no reason to doubt it but I just want to be sure before I invest more time into what I'm doing.
I'm currently working on a method to batch analyse/split a file into chunks to accelerate VP9 encoding and despite reading such nonsense as ffmpeg cutting to the nearest keyframe (when -codec copy is used) I've had instances where a segment begins with corrupted (i.e non keyframe) frames. I could probably try -ss / -to but that would still require knowing where to cut ahead of time so the cuts were accurate and didn't include waste/unneeded frames. So I figure either way I'm looking at dumping every source files frame types with ffprobe so I can get the needed timecodes. Unless someone knows a better way. Also I'm little unclear on how its cutting range works.. Let's say I've got an I frame dead on at timecode 600. Should I be targeting the non-I frame directly preceding it as the segment_time to cut at? I'm unsure if I'm just getting lucky and ffmpeg is compensating for something when I tell it to cut a given timecode and it happens to come out clean. The primary goal here is to cut clean, with no corrupt or repeated frames between any of the segments, and without re-encoding anything. Personally I don't need to do this because my workflow involves exporting to MagicYUV lossless AVI files, and I could probably just split those after the fact (and without a problem) with minimal difference in time losses due to cutting operations. But it would be nice to produce something I can share with others that might actually be helpful, and sometimes I might want to bypass my workflow and just work on a given source directly. EDIT: 1/10/20 7:53pm Well this is interesting. Here is a given set of frames. a keyframe, with a frame proceeding and preceeding it. The source is an MKV from a bluray I own, ripped to MKV with MakeMKV. It plays fine looks fine, etc. Code:
[FRAME] pkt_pts_time=825.283000 pkt_pos=3031059095 pict_type=B coded_picture_number=19788 [/FRAME] [FRAME] pkt_pts_time=825.325000 pkt_pos=3030754047 pict_type=I coded_picture_number=19786 [/FRAME] [FRAME] pkt_pts_time=825.366000 pkt_pos=3031301614 pict_type=B coded_picture_number=19790 [/FRAME] Code:
ffmpeg -i "input.mkv" -an -f segment -segment_times 825.283000 -reset_timestamps 1 -codec copy -map 0:0 "Input-test%03d.mkv" If I change the output container to MP4, leaving everything else unchanged, the result changed slightly. Vdub2 and WMP preview it fine, but VLC shows corruption at the start of the file. what in the lol is this ? Is there something about file containers I am overlooking that would explain this? I can't tell if I've got a good cut or not. I know VLC can be a little finnicky too... Even more puzzling is if I open both the MKV and MP4 with JRiver Media Center 26 (not sure what its using other than LAV) both play fine with no corruption. I can convert the segment mkv to AVI (FMP4 and magicyuv) and it also shows no corruption in Vdub2, WMP, (VLC/FMP4 it won't play Magicyuv), etc even though the source MKV did... so I am guessing this is some weird decoding issue with players. Last edited by osgZach; 11th January 2020 at 03:13. Reason: clarification of some things |
11th January 2020, 12:02 | #34 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
Looks like open GOP. The order in the text that ffprobe outputs is in display order (pts time). But notice how the coded_picture_number of the first B frame is higher than the one of the I frame. That means the B frame likely references said I frame (and/or a frame before that).
Bottom line is: not every I frame is a good split point. Not even every I frame that can be seeked to is a good one. Usually you want IDR frames for splitting. |
11th January 2020, 20:44 | #35 | Link |
Registered User
Join Date: Feb 2009
Location: USA
Posts: 676
|
yeah funny that, I noticed that when I was trying to ascertain what actual frame I was viewing within Vdub, I assumed coded_picture_number meant something else and I was wrong.
I managed to find this discussion.. which didn't seem too promising in results for differentiating an IDR from other I Frames https://video.stackexchange.com/ques...-frames-output edit: Did another stats dump to confirm it just lists every I frame as a keyframe. I also limited it to outputting I frames only. Which lead me to see this Code:
[FRAME] key_frame=1 pkt_pts_time=1149.565000 pkt_pos=4213181483 pict_type=I coded_picture_number=4893 [/FRAME] [FRAME] key_frame=1 pkt_pts_time=1150.358000 pkt_pos=4216099860 pict_type=I coded_picture_number=4894 [/FRAME] Last edited by osgZach; 11th January 2020 at 22:54. |
12th January 2020, 00:35 | #37 | Link |
Registered User
Join Date: Feb 2009
Location: USA
Posts: 676
|
Alright, thanks for your feedback. I'll do some more testing with other blu ray sourced files, since that is the primary intended purpose. Hopefully this behavior will stay consistent across all kinds of stuff. I've got some VC-1 discs I should also test with too.
edit: I'm going to go with the aforementioned strategy of looking for groups of 2 or more consecutive iframes to target for cutting, but as an addendum I am still seeing weird as hell behavior which I will now relate my frustrations about. I found a group of 4 consecutive iframes and started making test chunks, moving backwards in an attempt to try and find out where ffmpeg is actually deciding to cut (is it inclusive of the target specified or not). So I got all the way back to the first iframe in the bunch, specified its timecode and cut it. Got corruption in VLC, got corruption in Vdub... OK, that's really weird...because if it was cutting the frame before the target it should still be clean, and if its cutting the frame after, it should still be clean since its an I-Frame also and its coded picture number is sequential..... I repeated the test and switched the container from MKV to MP4 like I did in an earlier post. Corruption in VLC - NO corruption in Vdub, no corruption in Vivaldi (chromium), Firefox, WMP; I even checked in Vegas Pro 15. so I took it further and I encoded that chunk to a VP9 webm. It came out clean. vivaldi plays it fine. VLC plays it fine. (wth???) WMP plays it fine. firefox plays it fine. OK so what about the original MKV which showed corruption? VLC shows corruption may be a weird playback buffer issue idk.. Vdub corruption, WMP no corruption. I also encoded this file to VP9 webm. Vdub, Vivaldi, Firefox, VLC all show no corruption. As a final test I took the same MKV that showed corrupt, and again encoded it to MagicYUV M8Y0. Vdub/WMP show no corruption. (again VLC won't play this codec) The only conclusions I can come to is A) all these applications have inconsistent decoder behavior, even the same decoder maybe using different revisions? or B) the first I-Frame in the bunch is coded picture number 14444, the frame before it is a B frame, coded picture number 14446 And this harkens back to the first problem about out of order references, so as a sanity check - the first iframe in a group of iframes should never be used as a target? Because behavior is just too unpredictable even if ffmpeg seems to handle it properly itself. I wanna rip my hair out Last edited by osgZach; 12th January 2020 at 01:46. |
12th January 2020, 09:20 | #38 | Link | |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
Quote:
(All in display order.) |
|
12th January 2020, 16:56 | #39 | Link |
Registered User
Join Date: May 2016
Posts: 197
|
I wonder whether the SPS and PPS in these tracks (we are talking about H.264 here, aren't we?) change in-band. In such instances, FFmpeg does not make sure that every frame that it flags as keyframe actually has the right parameter sets in front of it. Use mkvmerge (preferably the latest continuous build as there has been a commit pertaining to this feature) to remux the transport stream from the BluRay as it inserts the correct SPS and PPS in such scenarios. (Remuxing a file already in mkv (or mp4) won't change anything.)
|
12th January 2020, 20:33 | #40 | Link | ||
Registered User
Join Date: Feb 2009
Location: USA
Posts: 676
|
Quote:
Quote:
But it'll be an interesting chore to get done and compare the results from. And yes they're H.264 At any rate, something more applicable to general files (a game recording or other unknown source), would still be nice to have as a tool I suspect. I appreciate all the assistance thus far. Last edited by osgZach; 12th January 2020 at 20:39. |
||
Thread Tools | Search this Thread |
Display Modes | |
|
|