Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

liq_cue_in cueing-in too far? #1291

Closed
Warblefly opened this issue Jul 19, 2020 · 23 comments
Closed

liq_cue_in cueing-in too far? #1291

Warblefly opened this issue Jul 19, 2020 · 23 comments
Assignees
@toots
Labels
bug
Milestone
1.4.3

Comments

@Warblefly
Copy link

Thank you for reading this.

Tracks in my m3u8 playlist using the "annotate" protocol and liq_cue_in seem to cue in too far when liq_cue_in is quite lengthy e.g. more than 1.0 seconds.

The system has been very stable for a long time. Running 1.4.3 pre-release has this trouble, though.

For tracks with very short, or zero, values of liq_cue_in, there isn't a problem.

FFmpeg is being used, I believe in all cases, to decode the files. They are of different codecs e.g. one exhibiting this problem is an MP3, another is an AAC file. All are encapsulated in Matroska.

Would you like some example files and an m3u8 playlist to trigger the problem?
@toots toots added this to the 1.4.3 milestone Jul 23, 2020
@toots
Copy link
Member

toots commented Jul 23, 2020

Thanks for the report. I'll look at it shortly.

@toots toots self-assigned this Jul 23, 2020
@toots toots added the bug label Jul 23, 2020
@Warblefly
Copy link
Author

I must beg forgiveness -- please don't investigate this yet. I've just put together the playlist I promised, and it seems my in-cue automatic detection system wasn't correctly marking the start of tracks with a fade-in. This may well NOT be a bug in your code, and I'm sorry to have troubled you with it.

I also compiled your test code for Version 2 (needed to use a slightly earlier version of your FFmpeg plugin) and it is running smoothly using the .liq file that ran earlier in Version 1.4.3 with one change:

This line gives an error (I've deleted it without trouble):
set("decoder.file_decoders", ["META","WAV","AIFF","MIDI","IMAGE","FFMPEG","FLAC","AAC","MP4","OGG","MAD"])

Liquidsoap complained that "decoder.file_decoders" doesn't exist.

@Warblefly
Copy link
Author

Regrettably, I may have been correct. On checking the playlist and comparing the files in an audio editor, my liq_cue_in markers were correctly instructing the playback system to start the track from, or before, the correct time.

I have recently switched to re-wrapping all my music files, using the original codecs and sample-rates, in Matroska, rather than re-encoding each and every track as a high bit-rate AAC at a single sample rate.

I wonder how liq_cue_in is determined by Liquidsoap? I should learn more Ocaml.

@toots
Copy link
Member

toots commented Jul 24, 2020

Hi! No problem, we're all experimenting. There are a couple more bugs related to crossfade duration so I strongly suspect something is up with it.

Is there any chance you would be able to isolate a simple example that I could use to reproduce the issue? If needed, you could send me the file at toots@rastageeks.org.

Thanks!

@toots
Copy link
Member

toots commented Jul 25, 2020

Hi!

We just fixed #1074 that was a crossfade-related bug. Any chance you could try with the latest v1.4.3-pre-release branch? You can either use opam pin mechanism or one of the build that should appear shortly at: https://github.com/savonet/liquidsoap/releases/tag/v1.4.3-pre-release

Thanks!

@Warblefly
Copy link
Author

Warblefly commented Jul 25, 2020 via email

@toots
Copy link
Member

toots commented Jul 26, 2020

Great! I just pushed another commit related to cross-fade. Make sur you test the latest v1.4.3-pre-release. Thanks!!

@Warblefly
Copy link
Author

Warblefly commented Jul 26, 2020 via email

@Warblefly
Copy link
Author

Warblefly commented Jul 26, 2020 via email

toots added a commit that referenced this issue Jul 26, 2020
@toots
Fix seek implementation in FFMPEG decoder. Fixes: #1291
4349470
@toots
Copy link
Member

toots commented Jul 26, 2020

Fixed in 4349470, changes backported to ffmpeg-copy for inclusion into master

@toots toots closed this as completed Jul 26, 2020
@Warblefly
Copy link
Author

Warblefly commented Jul 26, 2020 via email

@toots
Copy link
Member

toots commented Jul 26, 2020

Yeah, thanks for reporting, I'm happy we caught this one.

@Warblefly
Copy link
Author

Warblefly commented Jul 26, 2020 via email

@toots
Copy link
Member

toots commented Jul 27, 2020

Thanks for double checking and for the example, this will be greatly useful. I'll give this another pass shortly.

@toots toots reopened this Jul 27, 2020
@toots
Copy link
Member

toots commented Jul 28, 2020

I found out your issue. First, a little technical context, based on https://stackoverflow.com/questions/31854406/precise-seeking-with-ffmpeg/31856130#31856130:

There is no frame-exact or audio-sample-exact seeking in ffmpeg, that's an application-level problem. The reason is quite simple: libavformat does the seeking, and it doesn't know what's inside the packets that individual demuxers return. It just has a blob of data with timestamp X and duration Y. It doesn't know anything about that data, you'd have to decode the data to do anything meaningful with it, which is libavcodec, not libvformat.

So, to answer your questions: av_seek_frame seeks to packet boundaries, AVSEEK_FLAG_BACKWARD means the packet will be strictly before the given ts; for audio, that means that the packet will most likely contain your timestamp. However, this is not always the case, because some demuxers seek based on an index, and not each packet may have an index entry. You may have to call av_read_frame() several times before you get to the packet that contains your specified timestamp after the seek.

Other than you calling avcodec_flush(), libavcodec doesn't know anything about seeking, so the output of the next call to avcodec_decode_audio4 will start at the start of the input packet. For sample-specific seeking, applications have to chop off leading samples themselves.

What this means is that, if you ask ffmpeg to seek to a given timestamp, it will reach to the closest frame to that time stamp.

Each format and encapsulation container can result in different frame size, leading to imprecise seek. Indeed, if I remux your files in a m4a container without changing the data, using: ffmpeg -i /path/to/file.mka -c copy /path/to/file.m4a, the resulting file seeks fine.

I have to think about what to do. There is a programatic solution to your problem, but I have to wonder how complex it is to implement for us. Meanwhile, I'd suggest remuxing your files on the fly using protocols. I'm happy to explain how to do so.

@toots
Copy link
Member

toots commented Jul 28, 2020 •
edited
Loading

Ok, fixed for real with c8ea4a2 in v1.4.3-pre-release and c5ccc40 in ffmpeg-copy

@toots toots closed this as completed Jul 28, 2020
@Warblefly
Copy link
Author

Warblefly commented Jul 28, 2020 via email •
edited
Loading

@toots
Copy link
Member

toots commented Jul 28, 2020

Cool! Please note that you will need to use ocaml-ffmpeg on branch v0.4.3, which will be released with this release.

@Warblefly
Copy link
Author

Warblefly commented Jul 28, 2020 via email

@Warblefly
Copy link
Author

Certainly, the test case has no audible problems, compared to the earlier missed timings.

I'm running the full playlist to see what happens. I've so far heard no clipped introductions.

Whilst I would have been happy to rewrap into a format where there are smaller frames, this is a most generous solution (seriously, most people would just edit the audio, cutting off the front) but it means I'm able to run a music stream with one less codec to cascade through — and fully automated track start/end detection.

Thank you once more.
JW

@toots
Copy link
Member

toots commented Jul 29, 2020

Yeah, radio automation is all we strive for! Happy to have fixed this one, hoping to release the final 1.4.3 version shortly..

@Warblefly
Copy link
Author

Confirming: so far, having listened to the output for several dozen hours while writing news, I've noticed no cut-off track beginnings.

Thank you for sorting this.

Will be delighted to test 2.0 when you believe it's ready.
with best wishes,
John

@toots
Copy link
Member

toots commented Aug 2, 2020

Awesome super happy to hear that. 2.0 should come some time soon :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@toots toots

Labels
bug
Projects
None yet
Milestone
1.4.3
Development

No branches or pull requests
2 participants
@toots @Warblefly